ゼロトラスト
Zero Trust ・ ぜろとらすと
「境界の内側は安全」という前提を捨て、すべての要求を資源の手前で毎回確かめるセキュリティモデル。
✦ 30秒で試す — 航海社員の端末を、社外の見知らぬ端末と同じように疑ってかかる入口の門の確認をもっと厳しくすると、PC から届く資源は？予想してみる概要
ゼロトラストは、「社内ネットワークの内側にいるなら信頼してよい」という前提を捨て、すべてのアクセスを要求のたびに確かめるセキュリティモデルです。標語は “Never trust, always verify”（決して信頼せず、常に検証する）。ネットワーク上の「場所」を信頼の根拠にせず、要求が来るたびに「誰が（ユーザーの認証）」「何から（端末が会社の管理下にあり健全か）」「何に対して（資源ごとの認可）」を確かめ、通してよいかをその場で決めます。
特定の製品や単一の技術の名前ではなく、設計の考え方である点に注意が必要です。「ゼロトラスト製品」と銘打った製品は数多くありますが、中身は既存の技術の組み合わせです。本人を確かめる IdP（認証基盤）、端末の状態を把握する端末管理、資源の手前で要求を受け止めるリバースプロキシ型のアクセスプロキシ、ネットワークを細かく区切る仕組みなどを組み合わせ、「信頼を場所ではなく、アイデンティティとその時の状況に結びつける」という原則を実現します。
リモートワークとクラウドが当たり前になり、社員は自宅やカフェから、社外のデータセンターにある業務システムへ直接つなぐようになりました。「社内」という場所そのものが曖昧になった現在、ゼロトラストは企業のセキュリティ設計の標準的な考え方になりつつあります。
なぜ生まれたか
従来のセキュリティは「境界防御」、しばしば「城と堀」に喩えられるモデルでした。ファイアウォールと VPN で社内ネットワークの境界を固め、境界を越えて中に入った通信は信頼する。守るべき資産がすべて社内のサーバ室にあり、社員が社内の席で働いていた時代には、門を1か所に集めるこの設計は合理的でした。
しかし境界防御には構造的な弱点があります。検証は入口の1回だけで、内側は素通しなのです。フィッシングやマルウェアで社員の端末が1台乗っ取られると、その端末は正規の社員として入口をすでに通っているので、内側のどのサーバにも話しかけられます。侵入者が内側で足場を広げていく「ラテラルムーブメント（横移動）」に対して、境界の門は何もできません。悪意ある内部の人にも同じく無力です。さらにクラウドとリモートワークの普及で、守るべき資産も働く人も境界の外へ出ていき、「内側」という前提そのものが崩れました。
この問題意識を、2010年に Forrester Research の John Kindervag が「ゼロトラスト」として定式化しました。Google は2009年に受けた大規模な侵入（Operation Aurora）を契機の一つとして社内の設計を見直し、その実装 BeyondCorp を2014年から論文で公開しました。BeyondCorp は「社内ネットワークにいることに特別な意味を持たせない。社内からでもカフェからでも、同じ検証を経て同じようにアクセスする」を全社規模で実現し、社員が業務に VPN を使わなくてもよい状態を作ったことで大きな影響を与えました。2020年には米国の NIST が SP 800-207 としてアーキテクチャを標準文書にまとめ、構成要素に共通の名前を与えています。
詳細
境界型とゼロトラストの対比
両者の違いは「検証がどこで・何回行われるか」に集約されます。
境界防御では門は外壁に1つだけで、そこを通った要求は内側で「信頼済み」として扱われます。乗っ取られた端末も、持ち主が正規の社員である以上は門を通っているので、内側のどの資源にも届きます。ゼロトラストでは信頼ゾーンという考えそのものをなくし、各資源の手前に検証点を置きます。同じ端末からの要求でも、資源ごとに本人・端末・権限を確かめられるので、届くのはその人に許された資源だけになります。被害を権限の範囲に閉じ込めるという意味で、ゼロトラストは最小権限の原則をネットワークへのアクセスにまで広げたものと捉えられます。
設計者の立場で確かめてください。営業の佐藤さんの PC が乗っ取られていた、という想定で、社内の構成図に「検証の門」を置いていきます。門を置くたびにその PC からの要求が流れ直し、届いてしまう資源が朱に、守られた資源が金に塗り分けられます。外壁の門を外しても何も変わらないこと、端末の異常を検知したときに境界型とゼロトラストで結果が分かれることにも注目してください。
あなたは社内システムの設計者です。営業の佐藤さんの PC が乗っ取られていたと分かりました。いまは境界型で、門は外壁（VPN）の1つだけ。朱の資源が、その PC から届いてしまう範囲です。左の検証の門をつかんで、資源の前に置いてみてください。
構成要素 — ポリシー決定点（PDP）とポリシー適用点（PEP）
NIST SP 800-207 は、ゼロトラストの仕組みを「決める役」と「止める役」に分けて名前を付けています。**ポリシー決定点（PDP: Policy Decision Point）**は、この要求を通してよいかを判断する頭脳です。判断の材料として、IdP からは本人とその所属・役割を、端末管理からは端末の状態（会社の管理下か、OS やパッチは新しいか、ディスクは暗号化されているか）を、ログや脅威情報からは普段と違う振る舞いがないかを受け取ります。**ポリシー適用点（PEP: Policy Enforcement Point）**は、資源の手前で要求を受け止め、PDP の判断どおりに通したり止めたりする門番です。上の部品の「検証の門」が PEP にあたります。
決める役と止める役を分けるのは、判断のルールを1か所で管理しながら、門番は資源の数だけ置けるようにするためです。PEP の奥、門番と資源のあいだには、どうしても「そこまで来た要求は確かめ済み」とみなす区間が残ります。NIST はこれを暗黙の信頼ゾーンと呼び、できるだけ資源の近くまで門番を寄せて、この区間を小さくすることを求めています。境界型は、この暗黙の信頼ゾーンが社内ネットワーク全体に広がっている状態だと言い換えられます。
人がブラウザから業務アプリを使う場面では、PEP はアクセスプロキシ（Identity-Aware Proxy などと呼ばれます）として資源の手前に立ちます。1回の要求の流れを追うと次のようになります。
業務アプリ自身はインターネットに直接さらされず、アクセスプロキシの奥にだけ置かれます。社内からのアクセスも同じプロキシを通るので、「社内にいるから」という理由で検証が省かれることはありません。SSO でログインは1回で済んでも、PEP での判断は要求のたびに行われる、という二重構造が要点です。
何を検証するのか — アイデンティティ・端末・状況
ゼロトラストの検証は「正しいパスワードか」より広い概念です。第一にユーザーのアイデンティティで、MFA（多要素認証）による本人確認が事実上の前提になります。第二に端末の健全性で、会社が管理する端末か、OS やパッチは新しいか、ディスクは暗号化されているか、端末を監視する EDR（Endpoint Detection and Response）が異常を報告していないかを確かめます。第三に状況で、アクセス元の地域・時刻・普段の行動からの逸脱を評価し、リスクが高ければ追加の認証を求めたり拒否したりします。
大切なのは、これが「ログインの1回」ではなく継続的な判断である点です。セッションの途中でも、端末がポリシー違反になったり、IdP でアカウントが止められたりすれば、次の要求から通さなくなります。上の部品で、端末の異常を検知した瞬間に資源の前の門がすべて閉じたのはこのためです。一方、入口で1回だけ確かめる VPN では、接続が続く限り、その後の要求は確かめられません。
もう一つ見落としやすいのは、ゼロトラストでも本来の権限の範囲には届くことです。乗っ取られた端末が正規の社員のセッションを持っていれば、本人・端末・権限の検証を通ってしまう要求は必ず残ります。だから権限の範囲そのものを小さく保つ最小権限の原則と、RBAC などで役割ごとに権限を整理することが、ゼロトラストと組になります。
サービス間にも適用する — mTLS とマイクロセグメンテーション
ゼロトラストは人のアクセスに限りません。マイクロサービス構成では、サービス同士の通信も「同じクラスタ内だから信頼する」のではなく、mTLS（相互TLS）で双方が証明書を示し合い、呼び出しのたびに相手のサービスを確かめます。部品の顧客DBの門が、PC からの直接の接続を止め、顧客管理アプリからの呼び出しだけを通したのはこの考え方です。Kubernetes 上では、サービスメッシュ（Istio など）が各サービスの横に置いたサイドカーのプロキシで mTLS と認可を肩代わりし、アプリのコードを変えずにサービス間の PEP を実現します。
ネットワーク自体も、大きな1枚の社内LANではなく、ワークロード単位の細かい区画に分け、区画間の通信を明示的な許可制にします。これをマイクロセグメンテーションと呼びます。ファイアウォールのルールを細かくする方法もあれば、サービスメッシュのようにアイデンティティで許可を書く方法もあります。狙いはどちらも、侵害の影響を小さな区画に閉じ込めることです。
落とし穴とトレードオフ
ゼロトラストは検証を1か所に集めるのではなく、判断の頭脳（PDP）と本人の台帳（IdP）に依存を集めます。IdP が止まれば全社の業務が止まり、IdP の管理者アカウントが奪われれば、すべての門が開きます。IdP と PDP は最も守るべき資産であり、冗長化と管理者権限の厳格な分離が欠かせません。要求ごとに判断するぶん遅延も増えるので、判断結果を短時間だけキャッシュするなど、安全性と速さの折り合いを付ける設計が要ります。
また、門の外に取り残された資源が弱点になります。古い業務システムがアクセスプロキシに対応できずに、VPN の内側に残り続ける、というのはよくある姿です。上の部品で、門のない資源にだけ要求が素通しで届いたのと同じ構図で、移行の途中ほどこの「取り残し」を把握しておく必要があります。
移行は一夜にできない
ゼロトラストの導入でよくある誤解は、「製品を買えば移行できる」というものです。実際には、全ユーザー・全端末・全アプリケーションの棚卸し、IdP への認証の統合、アプリケーションごとのアクセスポリシーの定義という地道な作業の積み重ねで、既存システムを動かしながらの移行は年単位のプロジェクトになります。現実的な進め方は、まず認証の IdP への統合と MFA の全面適用から始め、重要度の高いアプリケーションから順にアクセスプロキシ経由へ切り替え、VPN への依存を少しずつ減らしていく段階的なやり方です。境界防御を今日すぐ捨てる必要はありません。「境界の内側だから安全」という暗黙の前提に頼った箇所を、一つずつ明示的な検証に置き換えていくこと自体が、ゼロトラストへの移行です。
試問
あなたは社内システムの設計者です。営業の佐藤さんの PC が乗っ取られていたと分かりました。画面の社内ネットワークの構成図には、外壁の門（VPN）と6つの資源（勤怠・顧客管理は佐藤さんに権限があり、経理・ソースコード・人事・顧客DB は権限がない）があり、「検証の門」をつかんで資源の手前に置くと、その PC からの要求がどこまで届くかが塗り分けられます。置いた門は押すと外せ、「端末の異常を検知する」も押せます。
あなたは社内システムの設計者です。営業の佐藤さんの PC が乗っ取られていたと分かりました。いまは境界型で、門は外壁（VPN）の1つだけ。朱の資源が、その PC から届いてしまう範囲です。左の検証の門をつかんで、資源の前に置いてみてください。