ゼロ・トラストとは何か？

ゼロトラストは、場所に基づく信頼を継続的な検証に置き換えます。境界モデルでは、ネットワーク内のあらゆるものをデフォルトで信頼できるものとみなしていましたが、ゼロトラストでは、実際の発信元や、そのユーザーが1時間前にどのような権限を付与されていたかに関わらず、すべてのリクエストを、あたかも信頼できない場所から発信されたものとして評価します。.

実際には、3つの考え方がこのモデルを特徴づけています：

• 暗黙の信頼はない. ネットワーク上の位置だけでは何の意味も持たず、ファイアウォールの内側にあるという事実だけでは、そのリクエストが正当であるという証拠にはなりません。.
• 継続的な検証. 信頼性は、ログイン時に一度確立されてセッション中ずっと維持されるのではなく、リクエストごとに評価されます。.
• 最小権限の原則. アクセス権限は、特定のリクエストに必要な範囲に限定され、それを超えて拡張されることはありません。.

ゼロトラストは、組織が購入できるような製品ではありません。. これは、アイデンティティ、デバイス、ネットワーク、アプリケーション、データといった各レイヤーのいずれかに属する単一の技術というよりも、これらすべてを網羅する戦略である。これを製品として提示するベンダーは、概して、そのアーキテクチャを構成する単一のコンポーネントについて説明しているに過ぎない。.

この用語自体は1994年にさかのぼり、スティーブン・ポール・マーシュがスターリング大学で計算機上の信頼に関する博士論文の中でこの言葉を用いたのが始まりである。 2010年、フォレスターのアナリストであるジョン・キンダーヴァグが「No More Chewy Centers: Introducing the Zero Trust Model of Information Security」を発表し、信頼そのものが脆弱性であると主張したことで、この概念はセキュリティ分野の主流となった。2009年に開始されたGoogleの「BeyondCorp」プロジェクトは、最初期の大規模な実装事例の一つである。.

NIST SP 800-207では、あらゆるゼロトラストアーキテクチャが満たさなければならない7つの原則が定義されています。.

1. すべてのデータソースとコンピューティングサービスはリソースです. データベース、アプリケーション、SaaSサービス、IoTデバイス、ユーザーのワークステーションはすべて保護が必要であり、設置場所や重要度の認識の如何にかかわらず、例外は認められません。.
2. ネットワークの場所にかかわらず、すべての通信は安全に保護されています. 内部ネットワークを通過するトラフィックは、パブリックインターネットから到着するトラフィックと同じ基準で認証および暗号化されます。.
3. アクセス権はセッションごとに付与されます. 信頼性は当該セッションに対して評価されるものであり、次のセッションに引き継がれることはないため、あるリソースへのアクセスが許可されたとしても、別のリソースへのアクセスが許可されることを意味するものではない。.
4. アクセスは動的ポリシーによって決定されます. 意思決定においては、静的なルールセットに基づいて判断を下すのではなく、クライアントの識別情報、アプリケーションの状態、資産の状態、および行動や環境に関する属性が考慮されます。.
5. 同社は、すべての資産のセキュリティ状態を監視している. デフォルトでは、どの資産も信頼されず、デバイスの完全性は継続的に測定され、その測定結果がアクセス許可の判断に反映されるようになっています。.
6. 認証と認可は動的に行われ、アクセス前に厳格に適用されます. 検証は、セッションの開始時に一度だけ行われる「ゲート」としてではなく、「許可」「スキャン」「適応」「再評価」という一連のプロセスが継続的に繰り返されるサイクルとして機能します。.
7. 企業は可能な限り多くの情報を収集し、それを活用してセキュリティ態勢を強化している. アセット、インフラ、通信から収集されたテレメトリデータは、アクセスを管理するポリシーに反映されます。.

さらに、3つの要素からなるより簡潔な枠組みも広く普及しています。それは、「明示的に検証する」「侵害を前提とする」「最小権限の原則を徹底する」というものです。この表現はMicrosoftに由来するものであり、要約としてはかなり有効ですが、SP 800-207が実際に規定している内容とは異なります。したがって、NISTの基準に基づいて体制を構築する組織は、上記の7つの原則に従って構築すべきです。.

すべてのアクセス要求は、基盤となるスタックを誰が構築したかに関係なく、一貫した手順に従ってリアルタイムで傍受され、処理されます。

1. ある対象者がアクセスを要求する リソースに対して。ここでいう「対象」とは、人物、サービスアカウント、ワークロード、またはAIエージェントを指す場合があります。.
2. 信号が収集される, 、これには、身元、デバイスの状態、位置情報、時刻、過去の行動、および脅威インテリジェンスなどが含まれます。.
3. ポリシーエンジンがリクエストを評価します 組織の方針に反すること、および算出されたリスクスコア。.
4. 決定が下され、執行される, 、アクセスを許可したり、拒否したり、あるいは追加の認証要素を用いて認証を強化したりすること。.
5. このセッションは監視されています, 、これにより、リスクの変化に応じて再評価が行われ、セッションがまだ開いている間にアクセス権を取り消すことが可能になります。.

この最後のステップこそが、ゼロトラストをそれ以前のモデルと区別する点です。なぜなら、境界セキュリティは境界で一度判断を下し、その結果を受け入れるのに対し、ゼロトラストはセッションが継続する限り評価を続けます。.

この違いを理解する最もわかりやすい方法は、VPNが境界を拡張するのに対し、ゼロトラストは境界そのものを完全に撤廃する、という点です。.

ユーザーが従来のVPNを介して接続すると、そのユーザーは企業ネットワークに接続され、接続時に一度行われる認証だけで、ネットワークレベルでの広範なアクセス権限が付与されます。そのネットワーク位置からアクセス可能なものはすべて、そのユーザーだけでなく、その認証情報を盗み出した者なら誰でもアクセスできてしまいます。.

ゼロトラストでは、ネットワーク全体ではなく個々のリソースへのアクセスが許可されるため、あるアプリケーションへのアクセス権限は他のリソースには及ばない。各リクエストは、その時点のリスク状況に基づいて再評価される。.

2020年8月に発行されたNIST特別刊行物800-207は、多くの組織がシステム構築の指針としている参照アーキテクチャである。この文書では、アクセス決定を行い、それを適用するコンポーネントと、その決定の根拠となるデータソースとの間に、明確な区別が設けられている。.

3つの主要な論理コンポーネント

ポリシーエンジン（PE）。. 以下に説明する入力情報に基づいてエンタープライズポリシーを評価し、信頼アルゴリズムを適用した上で、アクセスを許可、拒否、または取り消すことで、アクセスに関する決定を行います。.

保険契約管理担当者（PA）. その決定を実行するために、通信経路を開くか閉じるかを行い、対象がリソースにアクセスするために使用する認証情報またはトークンを発行する。PEとPAは合わせて、NISTが「ポリシー決定点」と呼ぶものを構成する。.

ポリシー適用ポイント（PEP）. リクエストパス内に配置され、ポリシー決定ポイントで決定された内容を適用することで、対象とリソース間の接続を確立、監視、および終了させます。.

ポリシーエンジンにデータを供給するデータソース

以下は、ポリシーエンジンが評価するシグナルを提供するものであり、それ自体が決定を行うわけではありません：

• ID管理システム. アカウント、IDレコード、ロール、属性、および権限。.
• データアクセスポリシー. 誰が、どのような条件下で、どのリソースにアクセスできるかを定めるルール。.
• 継続的な診断と緩和措置. アセットのインベントリおよびデバイスの状態。.
• 脅威インテリジェンス. 新たに発見された攻撃や脆弱性に関する内部および外部の指標。.
• アクティビティログとSIEM. 集約されたテレメトリデータを用いて、時間の経過とともにポリシーを最適化する。.
• 業界のコンプライアンス体制. 企業が遵守する義務を負う規制上の要件。.
• PKI. サブジェクトおよびリソースに対する証明書の発行と検証。.

実装の際、チームはこの境界線を曖昧にしてしまうことがよくあります。つまり、ID管理システムや脅威フィードを、あたかもそれらがアクセス決定を行っているかのように扱ってしまうのです。しかし、NISTモデルでは、これらのシステムは、実際に決定を行うポリシーエンジンへの入力情報を提供するに過ぎません。この区別は、ベンダーがアーキテクチャのどの部分を実際にカバーしているかを評価する際に、最も重要になります。.

概念として、「ゼロトラスト」は極めて単純明快です。つまり、対象者を検証し、その要求を承認するまでは、誰をも信頼せず、いかなる行動も許可しないというものです。 しかし、多くの組織が導入の段階で足踏みしてしまうのは、ゼロトラストがアイデンティティ、ネットワーク、エンドポイント、アプリケーション、データのすべてに同時に影響を及ぼす一方で、これら5つすべてを一度に解決するための予算や組織内での影響力を兼ね備えたセキュリティチームはほとんどないためです。そこで、どこから着手すべきかという現実的な問題が生じますが、その答えはほぼ常に「アイデンティティ」です。.

ゼロトラストに関するあらゆる判断は、結局のところ「この対象が自称する本人であるかどうか」、そして「現時点でこのアクセス権を持つべきかどうか」という単一の問いに帰着します。 セグメンテーションや暗号化ではこの問いに答えることはできず、デバイスの状態確認は問題を絞り込むことはできても解決には至らないため、これを解決できる唯一の制御手段はアイデンティティのみとなります。アイデンティティが脆弱な場合、下流にあるすべての制御は、検証されていない前提に基づいた決定を忠実に実行することになってしまいます。.

アイデンティティは、次の3つの場面で重要な役割を果たします：

• 認証. 対象を以下の方法で確認する フィッシング対策手法 盗まれたり、再利用されたり、ソーシャルエンジニアリングの標的になったりする可能性のある共有秘密鍵とは異なり、.
• 承認. 検証対象者がどのような情報にアクセスできるかを、以下に基づいて決定する 管理対象の役割 長年にわたる役割の変化を通じて蓄積されてきたアクセス権ではなく、.
• 継続的評価. リスクの兆候に変化が生じた場合は両方を再評価し、その兆候が正当な理由となる場合にはアクセス権を取り消す。.

ここには、ある不快な帰結が潜んでいます。それは、定義したことのない「最小権限の原則」を強制することはできず、また、現在誰が何にアクセスできるかを把握せずに「最小権限の原則」を定義することもできない、ということです。ほとんどの組織は、この質問に確信を持って答えることができません。だからこそ、 アイデンティティガバナンス ゼロトラスト・プログラムの初期段階に導入すべきであり、後の段階で行うべきではない。.

IDおよびアクセス管理 ゼロトラストアーキテクチャに不可欠なコンポーネントを提供します。.

とりわけ、他のどの要件よりも過小評価されがちな要件が2つあります。.

認証はフィッシング攻撃に耐性を持たなければならない。. ワンタイムパスワードに基づくMFA SMSや電子メールによる通知は、セキュリティ水準を引き上げる一方で、そのギャップを埋めることはできません。というのも、中間者攻撃やMFA疲労を誘発する攻撃により、プッシュ通知やOTP方式が一定頻度で無効化されてしまうからです。. FIDO2 およびデバイス固有のパスキー 認証情報をデバイスとオリジンの両方に紐付けることで、攻撃を単に遅らせるのではなく、実際に阻止する仕組みとなります。RSAは、これが業界の共通認識となるはるか以前から、FIDOアライアンスの理事およびエンタープライズ・ワーキンググループの共同議長として、この主張を続けてきました。.

クラウドが利用できない場合でも、Accessは正常に動作し続けなければなりません。. すべてのアクセス決定をクラウドのポリシーエンジンを経由させるアーキテクチャは、設計上、単一障害点をもたらしており、そのサービスにアクセスできなくなると、誰も作業ができなくなってしまいます。オンプレミス、ハイブリッド、エアギャップ、あるいは常時可用性が求められる環境で運用している組織にとって、サービス停止が単なる不便ではなく業務上の影響を伴う場合、これは不適切なトレードオフと言えます。 ゼロトラストは、組織をオフラインに陥らせる要因を集中させるのではなく、その数を減らすべきものです。だからこそ、オフラインおよびオンプレミスでの適用経路こそが、こうした環境においてこのモデルを耐障害性のあるものにしているのです。.

組織がゼロトラストの導入を決定した時点で、本格的な取り組みが始まります。これは数年単位のプログラムとして進められ、成果を上げている組織は、すべてを同時に試みるのではなく、作業を段階的に進める傾向があります。.

1. インベントリの識別情報、リソース、および現在のアクセス状況. 最小権限の原則は、基準が不明確な状態では適用できないため、まずは、サービスアカウント、外部委託業者、マシンIDを含め、現在誰が、どのリソースにアクセスできるのかを明確にすることから始めましょう。.

2. まずは認証を強化する. 最も重要なアクセスパスにフィッシング対策機能を備えた多要素認証（MFA）を導入することで、投入した労力あたりのリスク低減効果が最大となり、これは今後述べる対策のほとんどにとって必須の条件となります。.

3. アクセスポリシーを定義し、実施する. 役割やビジネス上の要件を明確なポリシーに落とし込み、既存の広範なアクセス権限を撤廃し、適用範囲が明確でレビュー可能なアクセス権限に置き換える。.

4. アクセスに関する決定に背景情報を加える. リスクベースの認証を導入することで、リスクの低いリクエストは問題なく通過させつつ、異常なリクエストには認証の要求を行ったりブロックしたりすることが可能になります。これは、ユーザーがプログラムを迂回する方法を見つけられないようにするためでもあります。.

5. セグメントのリソース. 侵害されたセッションがアクセスできる範囲を制限することで、制御が失敗した「場合」ではなく「その瞬間」における影響範囲を限定することができる。.

6. 監視、確認、および取り消し. 権限の見直しは、予定通りに実施する必要があります。なぜなら、見直しを経ずに権限が蓄積され続けると、最終的には、そのプログラムが防止しようとしていた「権限の肥大化」を招いてしまうからです。.

ここでは、ペースよりも順序の方が重要です。なぜなら、その基盤となる管理された識別情報なしにセグメンテーションを適用すると、ネットワークは適切に分割されるものの、依然として過度に特権化されたアカウントが保護されたままになってしまうからです。.

組織が「ゼロトラスト」を完全に達成したり、到達したりすることは決してありません。組織は、自らのセキュリティ態勢を継続的に評価し、あらゆるアクセスに関する決定を見直さなければなりません。.

ユーザーの操作上の障壁. 過度な検証は、回避策やシャドーIT、ヘルプデスクへの問い合わせ件数の増加を招きますが、実際にはアクセシビリティとセキュリティを互いに犠牲にし合う必要はありません。リスクベースの認証では、すべての人に一律の障壁を設けるのではなく、個々のリクエストがもたらすリスクに応じて認証の厳しさを調整します。.

レガシーシステム. 現代の認証基準より前に開発されたアプリケーションは、ゲートウェイやプロキシを利用するか、あるいは完全に置き換えない限り、多くの場合、システムに参加することができません。そのため、これはほとんどのプログラムにおいて最大の障壁となり、計画段階では最も見過ごされがちな要素となっています。.

可用性の依存関係. アクセス制御の決定を単一のクラウドサービスに集中させると、新たな重大な依存関係が生まれます。もしポリシーエンジンにアクセスできなくなれば、誰もがすべてのサービスから締め出されてしまいます。サービスがダウンした場合、認証処理がどうなるのか、各ベンダーに直接確認してみる価値があります。.

組織の範囲. ゼロトラストは、アイデンティティ、ネットワーク、エンドポイント、アプリケーション、データの各チームにまたがっているため、ある機能のみで運用されるプログラムは、その機能の境界で停滞しがちです。.

ベンダーの混同. ゼロトラストを実現する単一の製品は存在しないため、ベンダーを評価する際には、実際にどのようなアーキテクチャ構成要素を提供しているかを基準とすべきであり、「ゼロトラスト・プラットフォーム」という表現は、購入すべきカテゴリーというよりは、検証すべき主張として捉える方が適切である。.

IDデータの無秩序な拡散. アイデンティティは静的な問題というよりは、増え続けるデータの問題であり、権限はほとんどのチームが手作業で確認できる速度よりも速く蓄積されていきます。この時点で、自動化と分析はもはや「任意」の選択肢ではなくなります。.

ゼロトラストは、いくつかの規制対象環境において、ベストプラクティスから必須要件へと移行しました。.

• エグゼクティブオーダー14028 指示する 米国の連邦民間機関 ゼロトラストアーキテクチャの実現に向けて。.
• CISA ゼロトラスト成熟度モデル 連邦政府機関が成熟度を報告するための枠組みを提供しており、その枠組みは「アイデンティティ」、「デバイス」、「ネットワーク」、「アプリケーションおよびワークロード」、「データ」という5つの柱に基づいて構成されています。.
• 米国防総省のゼロトラスト戦略 防衛部門におけるゼロトラストの取り組みを定めている。.
• CMMC 2.0 防衛産業基盤全体において、アクセス制御および多要素認証（MFA）の要件を課している。.
• DORAとNIS2 以下に対して、アクセス制御、耐障害性、および業務継続性の要件を課す EUの金融サービス また、本文中に「ゼロトラスト」という用語が登場するか否かにかかわらず、ゼロトラストの原則に合致する重要インフラ。.

これらすべてにおいて、アイデンティティは柱あるいは管理要素の一つとして位置づけられており、監査人が真っ先に証拠の提示を求める箇所であると同時に、組織がそれを提示できる準備が最も整っていない箇所でもあります。.

レジリエンス要件とクラウド専用アーキテクチャの間には相反する側面もあり、これらについては早い段階で慎重に検討しておく価値がある。DORAに基づく事業継続性の要件や、防衛・重要インフラ分野における常時可用性の義務は、ベンダーのサービスにアクセスできなくなっただけで機能しなくなるようなアクセスモデルでは、満たすことが困難である。.