ゼロトラストセキュリティ：ゼロトラストが重要な理由（そして単なるアクセスにとどまらない理由）

要約

ここ数年、ネットワークやアプリケーションのアクセスにおける主要なテーマの1つが「ゼロトラスト」という概念です。このホワイトペーパーでは、ゼロトラストがその核心において、アクセスだけでなく、より広くサイバーセキュリティ分野全体に適用できるいくつかのシンプルな考え方を特徴としていることを説明します。

このホワイトペーパーでは、ゼロトラストに関する幅広い概念を包含するフレームワークを提示し、それらの概念を今日のアプリケーションセキュリティのビジネスリーダーを動かしている現在のビジネスの状況と関連付けます。最後に、ゼロトラストの考え方の体系が持つ特徴、つまり現在と将来の脅威に対処するためのツールとセキュリティの実装の原動力について説明します。これについては、後続のホワイトペーパーで詳しく取り上げる予定です。

このホワイトペーパーの目的は2つあります。1つは、アプリケーションビジネスリーダーが持つべきセキュリティの考え方を伝えること、もう1つは、今後のホワイトペーパーで説明するセキュリティ担当者のためのフレームワークを紹介することです。

ZTS：技術ではなく、原則から始める

「ゼロトラスト」という用語は、抽象度の異なるさまざまな概念と関連付けられています。あるときは特定のソリューションアーキテクチャを指し、あるときは特定の技術を適用するための規定を指し、またあるときは製品の特性を指します。私たちは、ゼロトラストセキュリティの核心は信念、つまり考え方の一体系であり、そこから技術や戦術が生まれ、特定の技術を活用することで、広範なセキュリティ脅威に対処することができると考えています。

ゼロトラストセキュリティ（ZTS）の根底にある考え方の体系は、数年前の「多層防御」から始まったセキュリティの考え方の進化における次のステップと見なすことができます。多層防御は、単一の防護層はわずかではあるが実際に破られる可能性があるが、重要な資産の保護層を増やすことでその可能性を減らし、攻撃者の動きを鈍らせ、攻撃を成功させるために多くのリソースを使わざるを得なくするという考え方に基づいています。

ゼロトラストは、この考え方を次の3つの点で進化させたものです。

まず、対策の前提を、アプリケーションへのアクセスを制限する単純な「フィルタ」のセットから、文脈に応じてあらゆるシステムトランザクションに適用される、より資産に適した対策のセットへと発展させます。各トランザクションの考え方は、Who（誰が）、What Action（どのようなアクションを）、Whom（誰に対して）行おうとしているかを理解することです。この「Who（誰が）」と「Whom（誰に対して）」は、システム内のあらゆるコンポーネントや、システムを使用する人間や自動化されたコード、またはその一部である可能性があります。Who（誰が）とWhom（誰に対して）についてはIDの概念が鍵となり、IDに付与された権限の概念は、What（どのようなアクションを）実行できるかを体系化するために使用されます。
次に、セキュリティ判断の評価は静的で絶対的なものではなく、観察された動作に照らして評価を継続的に繰り返し行う、より動的で適応的なものであると考えます。各トランザクションの処理に関する意思決定、つまりやり取りを許可するか、ブロックするか、さらに確実性を高めるかなどは、より広いビジネスコンテキスト、特にリスクとリターンのトレードオフも考慮しなければなりません。
最後に、何重もの防御を施したとしても、十分な動機を持つ攻撃者や幸運な攻撃者が防御を破る、あるいは回避することは当然であると考えます。したがって、侵害をタイムリーに検知し、悪用しようとする試みを軽減することも重要な要素として戦略全体に組み込まなければなりません。

この考え方の進化は、時間と経験の結果であるとも言えますが、他の2つのアプリケーションセキュリティの傾向が重なることで、ますます強められています。特に今日のアプリケーションアーキテクチャは、とりわけアプリケーションインフラストラクチャの「内部」からの脅威に対して、アプリケーションの脆弱性をより大きく開いている可能性があり、これを今日のますます巧妙化する攻撃者が悪用する恐れがあります。しかし幸いなことに、セキュリティツール、特に最新のデータ収集・分析機能と組み合わせて使用することで、防御戦略の主要なコンポーネントを実用化することが可能になりました。

この導入的なホワイトペーパーの後半では、ゼロトラストセキュリティに対する当社のアプローチのフレームワークとその範囲について概要を説明します。次のセクションでは、問題提起とゼロトラストへの他の新しいアプローチとの関係について説明し、ソリューション技術とそのアプリケーションの選択の指針となる主要な考え方、つまり「Why（なぜ）」について説明します。今後のホワイトペーパーでは、ゼロトラスト成熟度モデルに関連する認証、アクセス制御、AI支援分析などの特定の技術に課される要件である「How（どのように）」を掘り下げていく予定です。

ZTS：Why（なぜ）から始める

Simon Sinek氏の「Wｈｙから始めよう」というアプローチは、以下の図1に示すように、ZTSのフレームワークを伝えるのに効果的なツールです。この図は、外側から内側への視点で考えると、ZTSが対応する脅威の種類から始まり、使用するセキュリティ手法へと掘り下げ、最終的にすべてを共通の原則に集約することができます。また、内側から外側への視点で考えると、北極星のように常に同じ方向へと導く核となる考え方から始まり、そこから適切なツールや手法が生まれ、さまざまな脅威に対処できるようになります。

図1：ゼロトラストセキュリティ：考え方の体系、ツール、メリット。

後のセクションでこの図の同心円の各層について掘り下げていきますが、ここで簡単に説明します。

このアプローチの核となる考え方は、使用事例を次の枠組みで捉えることに基づいています。
「Who（誰が）、What（どのようなアクションを）、Whom（誰に対して）行おうとしているか？」
- Who（誰が）とWhom（誰に対して）を確定するために、IDの証明を明示的に検証します。
- Who（誰が）を確定した後、最小権限の原則を使用してWhat（どのようなアクションを）行えるかを限定します。
- Who（誰が）、What（どのようなアクションを）、Whom（誰に対して）の3つの要素すべての継続的な評価を繰り返し行い、ポリシーによる制限に対して引き続き検証します。
- 常に違反や侵害が発生することを想定します。リスク/リターン分析（認証における不正行為の可能性を、誤ったトランザクション承認によるビジネスへの影響で重み付けしたもの）に基づき、アクション（What（どのようなアクションを）、Whom（誰に対して））が事前に決めた許容安全しきい値を超えた場合に介入できるように準備しておきます。
使用する手法は、次のとおりです。
- 認証とアクセス制御：Who（誰が）をある程度の信頼度で判定し、Whom（誰に対して）の特定のターゲットに対してそのIDでWhat（どのようなアクションを）許可するかという権限を制限します。
- 可視化とML支援分析：各トランザクションの完全なコンテキストであるWho（誰が）、What（どのようなアクションを）、Whom（誰に対して）行っているかを観察し、継続的に評価します。
- リスク認識型の自動修復：リスクとリターンのレベルが指定した許容しきい値を超えた場合に、トランザクションに介入します。
これらの手法を応用することで、次のようなさまざまなサイバー攻撃に対処できます。
- 改ざん、データ流出などの従来型の攻撃：これらの攻撃は、IDの侵害や権限の昇格を検出し、認証とアクセス制御の手法を使用して、ポリシーによってWho（誰が）、What（どのようなアクションを）行えるかを制限することで対処します。
- 可用性/DDoS攻撃：これらの攻撃は、認証およびアクセス制御とリスク認識型の修復を組み合わせて対処します。例えば、リソースを大量に消費するトランザクションを行おうとする未認証の攻撃者または認証の不十分な攻撃者に対してアクセスをブロック（またはレートを制限）します。
- ランサムウェア、サプライチェーン攻撃などの高度な脅威：これらの攻撃は、Who（誰が）、What（どのようなアクションを）、Whom（誰に対して）行っているかという動作の変化や異常を検出し、リスク認識型の修復と組み合わせることで対処できます。

ZTSの範囲

ゼロトラストセキュリティは、アプリケーション、インフラストラクチャ、デリバリのすべてのスタックにわたり包括的に拡張し、開発パイプライン全体をカバーするものであるべきです。具体的には、次のものが含まれます。

アプリケーションとインフラストラクチャの「上から下まで」の完全なスタック
- サーバー、ネットワークインターフェースカード、コプロセッサ、システムボードコンポーネントなどのハードウェアコンピューティング基板
- ハードウェアのための下層のファームウェアとBIOS。
- ハイパーバイザーやランタイムエグゼクティブなど、最下層のオペレーティングシステム。
- アプリケーションレベル/コンテナのオペレーティングシステム。
- インポートされた、商用またはオープンソースのサードパーティ製アプリケーションコンポーネント。
- 自社開発またはカスタムメイドのアプリケーションソフトウェア。
「左から右まで」の完全なアプリケーションデリバリスタック
- 「上から下まで」の各スタック要素の継続的なメンテナンスとアップグレードに使用されるサプライチェーン。
- ファイアウォール、ロードバランサ、APIゲートウェイ、イングレス/エグレス/メッシュコントローラ、インライン詐欺軽減デバイスなど、インラインのアプリケーションデリバリコンポーネント。
- ドメインネームシステム（DNS）リゾルバなどの間接的にトラフィック処理に影響を与えるアプリケーションデリバリコンポーネントや、セキュリティ情報イベント管理（SIEM）ソリューションや統合IDサービスなどの間接的にメタデータを受信するアプリケーションデリバリコンポーネント。

従来、ゼロトラストの焦点はアプリケーション開発およびデリバリチームに向けられ、多くの場合、Dev、DevOps、DevSecOps、およびSREのペルソナとして捉えられてきました。私たちはこれをより大きな視野で捉えます。すなわち、ゼロトラストへの包括的なアプローチには、理想的には、従来と異なるペルソナやインフラストラクチャ、さらにサプライチェーンの調達戦略などのワークフローが含まれるべきであるということです。

問題提起

CIOやCISOにとっての最重要課題の1つは、情報技術をモダナイズし、ビジネスの加速に貢献することです。また、彼らは企業のリスクガバナンスにおいても重要な役割を担っています。彼らの目標は、ビジネスリスクを最小限に抑えながら、新しいデジタルエクスペリエンスで顧客を満足させ、サードパーティとのデジタル接続によって業務効率を向上させ、従業員がどこにいても生産的に働けるようにすることです。このため、CIOとCISOは、従業員が最新のテクノロジ、アーキテクチャ、ベストプラクティスをアジャイルに活用できるようにすると同時に、各従業員に適切なセキュリティ対策を講じ、従業員の行動、アクセスする情報、使用する技術に対する管理を確立し、損失を防ぐことが求められています。

組織は、市場やマクロ経済状況の変化、消費者行動、サプライチェーン、セキュリティ上の問題点に関連するリスクを理解し、抑制する必要があります。リスクを正確に評価し、迅速に緩和策を講じることができれば、ビジネスにおいて競争優位に立つことができます。このホワイトペーパーでは、特に知的財産の損失、ビジネスプロセスの中断、個人情報の損失、規制当局からの罰金などにつながりかねないセキュリティ上の問題点のリスクに焦点を当てます。セキュリティリスクを算出するには、考慮すべき状況について以下の点を評価します。

対象となる資産の価値
トランザクションの対象となる資産は、重要性のレベルがそれぞれ異なります。例えば、個人情報を含むデータベースは、その企業が製造した製品を扱う小売店の所在地のリストを含むデータベースよりも価値が高くなります。セキュリティチームとITチームは決定論的プロセスを使用して、資産の「価値」を表すスコアで分類された、すべての資産のインベントリを作成することが可能です。

侵害の影響
侵害の性質によって、その影響度が決まります。例えば、個人情報を含むデータストアの情報がステルス攻撃を受けた場合の影響は、データストアの可用性が損なわれた場合よりもはるかに大きくなります。あいまいな場合もありますが、さまざまな種類の侵害をリストアップし、それらに「影響度」のスコアを割り当てることが可能です。

侵害の可能性
あるトランザクションが資産の侵害につながる確率は、トランザクションに関連するリスクを評価する上で最も決定論的でない要素です。必要となる観察の規模に人間で対応することはできないため、組織は機械学習と人工知能を採用し、侵害の確率の計算の信頼度を高めています。

このような状況下において、すべてのトランザクションに関連するリスクをほぼリアルタイムで計算し、適切な緩和策を講じて潜在的な侵害の影響を抑制することが課題となっています。

問題の認識

ビジネスを加速させるというニーズは、サイバーセキュリティのリスクを悪化させる新たな慣行につながります。この点について、以下で詳しく説明します。

図2：ビジネスにおけるプレッシャーが新しい慣行を生み出し、それがリスクの増大につながる。

ビジネスを加速させるというニーズ
1. デジタルエクスペリエンス
  デジタルエクスペリエンスに対する消費者の要望はとどまることがなく、複数のプラットフォーム（PC、タブレット、携帯電話）で次々と改善されることを求めています。
2. 接続されたビジネス
  デジタルビジネスプロセスは、パートナー、ベンダー、販売代理店、さらには他の企業が提供するサービスと接続されている必要があります。
3. モバイルワーカー
  実行効率を高めるためには、従業員がどこからでもビジネスアプリケーションにアクセスできることが必要です。

ビジネスニーズに対応するための実践
1. アジャイルな開発手法
  企業は、タイムリーなプロジェクトデリバリを重視する逐次的なウォーターフォール手法から、顧客満足度を強く意識した漸進的で反復的なアジャイル開発手法に切り替えています。
2. 既成のソフトウェアの利用
  新しいデジタルエクスペリエンスをできるだけ早く提供するために、開発者は業界の開発者らがオープンソースで公開しているコードを再利用しています。
3. 受託開発
  受託開発業者に業務を外部委託することで、オンデマンドで労働力を拡大できます。
4. クラウドインフラストラクチャの利用
  クラウドの俊敏性、柔軟性、拡張性とその使いやすさにより、開発者は必要なインフラストラクチャをオンデマンドで入手できます。
5. SaaSの採用
  Software as a Service（SaaS）により、業務用アプリケーションの調達、導入、保守をプライベートデータセンターで行うという大きな負担が軽減されるため、SaaSは業務用アプリケーションにとって有利です。
6. マイクロサービスアーキテクチャ
  チームはマイクロサービスを活用して市場投入までの期間を短縮し、継続的なデリバリを実現できます。
7. 分散型のアプリケーションコンポーネント
  組織は、サービスの機能を開発または提供するための最適なツールを備えたインフラストラクチャでマイクロサービスを実行することにより、効率化を実現します。近年、レガシーワークフローの拡張が最新のアプリケーションアーキテクチャを使用して行われています。これらのアーキテクチャはレガシー要素と通信できる必要がありますが、多くの場合、両者は異なるインフラストラクチャ上で実行されています。
8. オープンAPI
  企業がすべてのサービスを独自に開発するよりも、さまざまなサービスからなるエコシステムを利用するほうが効率的です。
9. サードパーティとのネットワーク接続
  企業は、暗号化されたトンネルを使用してパートナー、ベンダー、販売代理店と相互に接続し、ビジネスプロセスの自動化と合理化を進めています。

セキュリティリスクの拡大
1. 攻撃対象の拡大
  サードパーティ製ソフトウェアやオープンソースライブラリの使用は、サプライチェーン攻撃のチャンスを与え、外部で開発されたソフトウェアの脆弱性はすべて継承されます。受託開発業者の目標は、期限内に機能を完成させることであり、セキュリティは気にしません。さらに、彼らがソフトウェアを納品してプロジェクトから抜けた後で、社内のチームがコードを調べてセキュリティホールを見つけることは難しく、時間がかかります。短距離走のようなアジャイルな進め方は、機能を提供するには非常に効率的ですが、開発の速度が上がることで、詳細なセキュリティ監査やテストを行う時間はあまりとれなくなります。1つの脆弱なマイクロサービスが、他のマイクロサービスとやり取りできることで、システム全体のセキュリティリスクが高まります。
  相互接続されたビジネスは業務効率を高めますが、その結果として深刻なのは、どれか1つのセキュリティホールがそれらすべてに影響を及ぼすことです。攻撃者は、最も脆弱なリンクを見つけ、残りのリンクを介して拡散します。SaaSプラットフォームやクラウドインフラストラクチャの脆弱性やセキュリティの不備は、新たな攻撃ベクトルとなり、共有責任モデルでは早期検出と修復が困難になる可能性があります。
2. アーキテクチャの複雑化
  多様なアーキテクチャを使用して開発され、複数のインフラストラクチャに展開された分散型のアプリケーション要素は、それぞれセキュリティとコンプライアンスのニーズが異なります。このため、セキュリティチームが企業のアプリケーションとデータを保護するために適切なメカニズムを設計・導入し、規制のコンプライアンス要件を満たすことが難しくなります。
3. 資金があり、強い動機があり、スキルの高いハッカー
  2010年のオーロラ作戦から2020年のSolargateまで、この10年間は、大きな被害をもたらした後で高度なサイバー攻撃が検出される例が続きました。それらの侵害は、最高のセキュリティ技術を備え、高度に訓練されたセキュリティチームが運用する組織で発生しています。攻撃者は検出されるまで、これらの組織のITインフラストラクチャに長期間にわたって潜んでいました。知的財産が盗まれ、個人情報が盗まれ、業務が中断され、組織はランサムウェアの人質となりました。たとえITチームとセキュリティチームがサイバー攻撃を阻止するために設計された規制を遵守する以上のことをしていても、です。

米国の政府指令

米国連邦、州、地方政府のさまざまな機関や複数の米国企業に対する執拗なサイバー攻撃の嵐を受け、ジョーバイデン大統領は2021年5月12日、国家のサイバーセキュリティの向上に関する大統領令を発令しました。この大統領令の重要な要素の1つが、政府機関がゼロトラストの原則に従いサイバー攻撃に備えることです。バイデン政権はこの大統領令に続き、2022年1月26日に行政機関の長に向けた行政管理予算局（OMB）からの覚書を発表しました。このOMBからの覚書では、「連邦政府のゼロトラストアーキテクチャ（ZTA）戦略を定め、ますます高度化・持続化する脅威キャンペーンに対する政府の防御策を強化するため、2024会計年度（FY）末までに特定のサイバーセキュリティ基準および目標を達成するよう各機関に求めています。」¹大統領令とOMBの覚書はいずれも、2020年8月に発行された米国国立標準技術研究所（NIST）のSP 800-207に記載されているゼロトラストアーキテクチャを指し、これに準拠するように政府機関に求めています。

ゼロトラストアーキテクチャと成熟度モデル

政府機関や民間企業のオピニオンリーダーらが、ゼロトラストアーキテクチャについて説明し、採用する最善の方法について助言する文書を発表しています。これらの文書に含まれるアイデアを以下に要約します。これらの文書のアイデアや提案の重要な本質は、すべてのトランザクションを調査してWho（誰が）、What Action（どのようなアクションを）、Whom（誰に対して）行おうとしているかを評価し、そのトランザクションに関連して算出されたリスクに基づいて、トランザクションを許可するか否かをリアルタイムで決定することであることに留意してください。

米国国立標準技術研究所（NIST）：ゼロトラストアーキテクチャ

NISTチームは、その文書NIST SP 800-207において、ゼロトラストの信条を列挙し、抽象的なゼロトラストアーキテクチャ（ZTA）を定義しています。²さらに、ゼロトラストアプローチのバリエーションを挙げ、抽象的なアーキテクチャを展開するさまざまな方法について説明しています。

この文書で説明されている主要な抽象概念は、互いに連動するポリシー決定ポイント（PDP）とポリシー実施ポイント（PEP）です。ポリシー決定ポイントは、ポリシーエンジン（PE）とポリシー管理者（PA）で構成されています。ポリシーエンジンは、信頼アルゴリズムを用いて、対象者にリソースへのアクセスを許可すべきかどうかの決定を行います。この決定はポリシー管理者によって実行され、ポリシー管理者はポリシー実施ポイントと通信して、新しいセッションの許可・不許可、既存のセッションの修正・終了を行います。さらに、信頼アルゴリズムのバリエーション、ゼロトラスト環境のためのネットワークコンポーネント、さまざまな使用事例や展開シナリオについても論じています。最後に、実装者が脅威を認識し、ゼロトラストアーキテクチャのコンポーネントを保護するために適切な手段を講じることができるように、攻撃者によるゼロトラストアーキテクチャの妨害方法について考察しています。

サイバーセキュリティインフラストラクチャセキュリティ庁（CISA）：ゼロトラスト成熟度モデル

ゼロトラスト計画の策定を支援する目的で、サイバーセキュリティインフラストラクチャセキュリティ庁（CISA）のオピニオンリーダーらは、ゼロトラスト成熟度モデルを発表しました。³このモデルは、NIST SP 800-207文書に記載されている抽象的なゼロトラストアーキテクチャをベースにしています。著者らは、5つの領域を特定し、組織が各領域でゼロトラストの原則に従って着実に推進していくよう推奨しています。その領域とは、（i）ID、（ii）デバイス、（iii）ネットワーク、（iv）アプリケーションのワークロード、（v）データです。また、5つの領域それぞれについて、可視化と分析、自動化とオーケストレーションの活用を推奨しています。

この文書では、前述したゼロトラストの5つの基本的な柱すべてについて、高度な成熟度モデルを示し、さらに各領域を深く掘り下げています。組織は、この成熟度モデルを用いて現状を把握し、最適な状態に向けた反復的なプロセスを設定できます。

米国国防総省（DOD）：ゼロトラストリファレンスアーキテクチャ

Solar Winds攻撃の発覚後、米国家安全保障局（NSA）は、文書「Embracing a Zero Trust Security Model（ゼロトラストセキュリティモデルの導入）」で、サイバーセキュリティチームにゼロトラストセキュリティモデルを採用するよう助言するガイダンスを発表しました。⁴米国国防情報システム局（DISA）と米国家安全保障局のゼロトラストエンジニアリングチームの専門家らは、米国国防総省（DOD）ゼロトラストリファレンスアーキテクチャについて記し⁵、ゼロトラストを採用する必要性を次のように表現しています。「DOD内外のデータ侵害によって露呈した脆弱性は、十分な情報に基づいたリスクベースの意思決定を促進する、新しく、より堅牢なサイバーセキュリティモデルの必要性を示しています。」⁶

このリファレンスアーキテクチャは、ゼロトラストアーキテクチャに関するNIST SP 800-207文書で定義された抽象概念に基づいた推奨事項を示しています。この文書では、高度な運用モデルを提示し、その要素を詳細に説明しています。また、高度な成熟度モデルと、ゼロトラストの原則をさまざまな分野に適用するための機能の対応付けも説明しています。これらの文書は、組織が現状を評価し、計画を立案するのに役立ちます。

ゼロトラストの原則に基づくリスクとガバナンスの管理

「侵害を前提とする」姿勢を持ち、ゼロトラストの原則に従うことは、組織のリスク管理とガバナンスの実践に役立ちます。トランザクションにかかわる行為者の「継続的な監視」と「明示的な検証」というゼロトラストの原則に従うことで、組織はすべての行為者とその活動に対する動的なリスクスコアを構築できます。これは、既存のセキュリティプログラムを強化するためにGartnerが使用を推奨している「Continuous Adaptive Risk and Trust Assessment」（CARTA）手法と一致します。リソースへのアクセスは最小権限しか認めないという原則を採用することで、侵害された場合でも損失のリスクを低減できます。また、継続的な監視と明示的な検証によって生成された情報は、コンプライアンスレポートの作成にも利用できます。

考え方の詳細

このセクションでは、ゼロトラストセキュリティのために企業が採用すべきツールや設計に関する戦略や決定の動機となる考え方として、考え方の体系の「Why（なぜ）」に焦点を当てます。実際、今日のゼロトラストソリューションで採用されているすべての手法と要素技術の原動力は、4つの単純な主要原則に集約することができます。このセクションでは、これらの原則を挙げ、それらをアプリケーション開発の広範なライフサイクルに適用する方法、つまり、設計段階でこれらの原則を前もって検討する方法と、アプリケーションの展開や実行時に運用する方法について説明します。

ゼロトラストの運用の原則

ゼロトラストソリューションが、基本的にシステム間のやり取り、すなわち「Who（誰が）、What（どのようなアクションを）、Whom（誰に対して）行っているか」に対する信頼性を構築するものと理解すると、やり取りに適した信頼レベルの構築は、4つの要素に分けることができます。

明示的に検証する

その名が示すように、ゼロトラストの考え方は、「盲目的に信用せず、常に検証する」というものです。したがって、システム内のあらゆる行為者、すなわちシステムのやり取りにおけるWho（誰が）とWhom（誰に対して）は、次のことができなければなりません。

航空会社予約システムの匿名のブラウザのように、システムが「匿名」のIDを発信元とする、または匿名のIDを宛先とするやり取りを許可する場合、匿名のIDの特殊なケースを含め、そのIDを証明する。その他のすべてのIDについて、行為者は、システムが受け入れる名前空間で、自分がWho（誰）であるかを表明できなければなりません。
行為者の証明済みIDの担保となる「証明」を受け取り、検証する（匿名でない証明済みIDの場合）。「証明」にはパスワード、証明書、行動などさまざまあり、その証明の強度も異なりますが、システムはその証明に対するある程度の信頼度を確認できなければなりません。単純なシステムでは、証明の信頼度を「はい/いいえ」の二値で表す場合もありますが、より高度なシステムでは、リスク/リターンに基づくポリシーの一部として明示的に参照できる信頼度スコア値が使用されます。また、能動的なチャレンジへの応答や行為者の行動の受動的な観察など、他の手段を使用することで信頼度を増減できることにも注意してください。
現在の行動を過去の行動と比較して得られる追加的なコンテキスト情報に基づき、証明されたIDの信頼度を評価し、調整する。例えば、システムは、行為者の過去と現在の位置情報、ハードウェアプラットフォーム、IPアドレス、評判など、行為者に関する履歴メタデータを維持し、IDの「証明」の信頼度を増減させる目的で使用できます。

さらに、明示的に検証するという原則は、IDだけでなく、アクション、つまりトランザクションの内容にも適用することができます。よくある使用事例は、データベースクエリを行うAPIなど、アクションがAPIコールとして表現されている場合です。この例では、明示的に検証するという原則は、APIを呼び出す行為者の身元を確認するためだけでなく、APIに渡されたパラメータが適切な制約に適合しているかどうかを確認するなど、APIアクションの使用の正しさを検証するためにも使用できます。

成熟したゼロトラストの考え方では、「証明」が絶対的なものであることはほとんどありません。ID認証情報が盗まれたり、デバイスが侵害される可能性があり、APIパラメータの制約も不完全であることが多くなります。したがって、ゼロトラストのコンテキストにおける「信頼度」という用語は、証明されたIDまたはトランザクションパラメータが正当である可能性がどれだけ高いかを示すものと解釈されるべきです。「信頼度」のレベルは、トランザクションを許可するか、ブロックするか、あるいはさらに検査するかを決定する際の重要な要素の1つですが、唯一の要素と見なされるべきではありません。

最小権限

トランザクションに関係する行為者について許容可能なレベルの「信頼度」が確立されると、ゼロトラストアプローチでは、行為者（通常は、要求元、「Who（誰が）」）にそのシステムで達成するように設計されていることを行うための必要最小限の権限セットのみを付与することを求めます。この原則は、「ポジティブセキュリティモデル」とも呼ばれるものを具体化したもので、デフォルトですべてのアクションを禁止し、システム運用に必要な特定の権限のみを付与するアプローチです。例えば、ある予約システムでは、匿名ユーザーがフライトスケジュールを閲覧することはできても、アプリケーションの設計要件に従って、匿名ユーザーがフライトを予約することは許可されません。

これらの権限は、個々の行為者に適用されることも、行為者のクラスに適用されることもあります。一般的に、アプリケーション利用者は人間の行為者または人間の代理として用意されたプロキシであり、「匿名ユーザー」、「顧客」、「パートナー」、「従業員」などのクラスに分類されます。信頼度の低いクラスの行為者は、通常、低い信頼度しきい値で認証をパスできますが、アクセスできるAPIは少数のより機密性の低いAPIに限られます。アプリケーション内の特定のサービスやコンテナなど、アプリケーションやそのインフラストラクチャの内部の行為者については、多くの場合、「コンテナおよびのみがデータベースにアクセス可能、のみがオブジェクトストアに書き込み可能、およびは読み取りが可能」など、権限がさらにカスタマイズされています。

最小権限の実装で考慮すべき重要な点は、先見性を持ってよりカスタマイズした方法で適用するよう努めることです。⁷具体的には、成熟したゼロトラストの実装では、すべての行為者または行為者のクラスに対して汎用的な権限セットを適用するのではなく、What（どのような）アクションが試みられるかをより詳細に把握する必要があります。例えば、大まかには「ファイルシステムへのアクセス権」を付与する場合でも、より厳しく指定すれば本当に必要な権限は「ファイルシステムの読み取り」である場合、厳しく指定することでポジティブセキュリティモデルを高品質で実装することができます。

最後に、ある行為者に許可した権限を絶対的なものではなく、認証がもたらす信頼度に基づくものと考えることで、最小権限のより高度な実施を、成熟した「明示的な検証」の実施と連動させることができます。この場合、証明された身元（Who（誰））に対する信頼度が最小限のしきい値を満たす場合にのみ権限が付与されます。このしきい値は、試みようとしているアクションに固有のものです。例えば、特に影響の大きいアクション（システムのシャットダウンなど）で、行為者が管理者である信頼度が90％以上である必要があるとします。この例では、シャットダウンが試みられたときにIDに対するシステムの信頼度が80％しかない場合、システムはアクションを許可する前に、証明されたIDに対する信頼度スコアを高めるために追加の検証を要求します。

継続的に評価する

明示的な検証や最小権限は重要な概念ですが、継続的に評価するという原則は、それらの原則が次のような意味で継続的に評価されなければならないという事実を示しています。

すべてのトランザクションは、検証と権限の対象でなければなりません。言い換えれば、「ユーザーセッションの最初のトランザクション」や「Dockerコンテナのワークロードを介して開始されたトランザクション」など、一部のトランザクションだけが検査の対象となるようなことがあってはならないのです。これは自明のことに聞こえるかもしれませんが、多くのゼロトラスト実装は、設計が不適切であったり可視性が欠如していたりするために、すべてのトランザクションを検証していません。この領域でよく見られる欠陥は、ゼロトラストを外部の行為者にのみ適用し、内部の行為者には適用していないことや、ゼロトラストの判断が長期間にわたってそのまま正しいと仮定していることから生じます。
評価における重要な要素である、行為者のIDに対する信頼度とその行為者に許可される権限は、動的で変化しやすいものと見なす必要があります。例えば、IDの信頼度は、観察された行動やサイドバンドメタデータに基づいて、時間の経過とともに増減する可能性があり、したがって信頼度に基づくポリシーも、信頼度の変化に動的に対応する必要があります。さらに、以前にポリシーによって指定された権限のしきい値が後で取り消されたり、あるアクションに必要な最小限の信頼度が変更されたりすることもあります。ポリシーの変更のタイムスケールはさまざまであり、ゆっくりと（人間の運用プロセスのタイムスケールで）変更されることもあれば、より頻繁に（自動化されたガバナンスエージェントを通じて）変更されることもありますが、システムはそれらの変更に動的に対応し、従うことができる必要があります。

侵害を想定する

最後の原則は、健全なパラノイアを背景に、強い動機を持つ攻撃者を想定することに根ざしています。具体的には、「侵害されたと想定する」という前提であり、ここでの「侵害」とは、「（完全な情報と実装により）拒否されるはずのトランザクションが許可されたこと」と定義されます。この逸脱の根本原因としては、情報が不完全であったこと（例：未検出の不正な認証情報に由来する認証により高い信頼度スコアが誤って得られた場合）、実装の限界（例：権限として「オープンネットワーク接続」が付与されているが、ネットワーク接続先の位置情報に基づいて識別する能力がないなど、付与される権限が十分に詳細に指定されていない場合）、ゼロトラストの実装が不完全であったこと（例：内部で使用されるオープンソースの脆弱なコンポーネントにゼロトラストを適用していない場合）などが考えられます。

したがって、ゼロトラストの考え方は、そのような侵害の影響を最善の方法で管理/最小化することにも対応しなければなりません。

この原則の実施方法は、他の原則よりも多様ですが、一般的には次のようになります。

まず、技術的にはポリシーによって許可されるが疑わしいトランザクションを特定します。「疑わしい」とは、多くの場合、コンテキストに大きく左右されますが、一般的な解釈は次のとおりです。（a）過去に観察された行動と大きく異なる異常なトランザクション。（b）個々のトランザクションは正常だがまとまると異常なトランザクション群。例えば、1つのファイルの読み書きは一般的であっても、1秒間に1000ファイルのレートで読み書きすることは異常である可能性があります。（c）望ましくない、以前は見られなかったシステムへの影響と相関する動作。例えば、特定のトランザクションがTORノードへのネットワーク接続を開く場合やシステムのCPU負荷を大幅に増加させる場合などです。
次に、完全に自動化されたワークフロー、あるいは人間が制御するワークフローとMLが支援するワークフローのハイブリッドで、より詳細な分析を行い、それらのトランザクションが無効かどうかを判断します。これらのトランザクションが無効であると判断された場合、緩和策を適用します。これは、一般的なポリシーの更新という形をとることも、追加の緩和策として、他のポリシー主導の緩和策の「最終手段」という形をとることもできます。

ポリシーに基づく調整を選択した場合、その調整は、利用可能な静的ポリシーツールのいずれかを利用して適用できます。ポリシーベースの調整の例としては、トランザクション単位のアクセス制御権限を制限すること（つまり、Who（誰が）、What（どのようなアクションを）、Whom（誰に対して）行うことを許可しないこと）、あるいは、行為者（または行為者のクラス）が特定の行為を行うためにはより厳しい「証明基準」を適用すること（つまり、MFAまたはより高い信頼度スコアを要求すること）などが考えられます。

一方、「最終手段」の追加層を使用するアプローチを選択した場合、この戦略はさまざまな粒度で実装することができます。最も粒度の細かい戦略は、特定のリスク/リターン比率を超えるトランザクションのみを正確にブロックすることですが、これにより追加の分析が必要になると、許可されるトランザクションの一部で許容できないレベルのレイテンシが生じる可能性もあります。一方、その行為者からの今後のトランザクションをサンドボックスに入れる、その行為者をシステムから完全に排除するなど、より粒度の粗い戦略を使用することもできます。極端なケースでは、ファイルI/Oのシャットダウンなど、より粗い緩和方法が適切な場合もあります。

もちろん、他の条件がすべて同じであれば、最終手段としての緩和策は細かい方が一般的に望ましいと言えます。しかし、多くの場合、利用可能なソリューションテクノロジの制約に基づくトレードオフが生じ、最終手段がないより、粗くてもある方が良いということになります。例えば、ランサムウェアの疑いがあればそれを阻止するために、ファイルI/Oを無効にするという粒度の粗い対策をとる場合、その行為者がチェックされずにシステム内で動作を続け、対策を講じなかった結果としてランサムウェアによってファイルシステムが暗号化されることを考えると、この対策による副作用の方が望ましいでしょう。

ゼロトラスト：それは運用の前から始まっている

ゼロトラストを使用した安全なアプリケーション開発の最良の出発点は、当然のことながら、開発の最初の段階です。ゼロトラストの原則を運用するための基本的な原則を、アプリケーション開発プロセスの設計段階で組み込むべきです。したがって、CI/CDパイプラインに統合された運用可能なゼロトラストソリューションのいかなる議論もこれらの基本的な要素の理解から始めなければならず、これらの要素は設計の検討事項として最優先される必要があります。

これらの基本的な要素の中核は、システム動作のやり取りの望ましい/意図された動作を、逸脱を検出してそれに対処するための十分な可視性および制御性と組み合わせて捉える必要があります。意図されたやり取りは、各行為者（Who（誰が））が各ターゲット（Whom（誰に対して））に対して行う望ましい一連のアクション（What（どのようなアクションを））を定義するために使用されます。とはいえ、意図するやり取りのパターンが不明なシナリオや環境もあるでしょう。そのような場合、組織は、より深く可視化することで、適切な一連のやり取りを「検出」し⁸、それをポリシーに成文化することができます。

例えば、今日のZTNAソリューションでは、アプリケーションの外部APIに対するID駆動型のアクセス制御に重点を置いていますが、これらのソリューションでは認証APIに対する可視性と制御性が必要です。また、クラウドワークロード保護プラットフォーム（CWPP）のコンテキストでは、侵害されたコンテナワークロードを検出するには、各コンテナが実行するアクションを可視化する必要があり、さらにリアルタイムで修復する必要がある場合は、リアルタイムで可視化する必要があります。

以下は、設計プロセスに含めるべき基本的な検討事項に関する「バケット」の概要を示したもので、さらに掘り下げて、それぞれの重要なポイントについて考えるための具体的な質問も示しています。

システムのブラックボックス化したインターフェース（入力と出力）は何ですか？
- アプリケーションとのやり取りを行うのは、管理者、認証ユーザー、非認証ユーザー、パートナーなど、どのクラスのユーザーですか？また、彼らは何をする必要がありますか？
- すべての通信は定義されたAPIを経由しますか？または、「生の」ネットワーク通信やデータベースやオブジェクトストアなどのデータストアを経由した通信がありますか？
  - API通信の場合、どのユーザーがAPIとやり取りできるかや、その際の制約（パラメータ制約やレート制限など）について、APIはどの程度定義されていますか？
  - ネットワーク通信の場合、送信するデータはすべて暗号化されますか？
  - 「生の」データインターフェースがある場合（例えば、オブジェクトストアやデータベースを介してクライアントとアプリケーションが情報を共有する場合）、誰が、いつ、どの情報にアクセスしたかを追跡するための監査ログがありますか？
同様に、内部の「ホワイトボックス」レベルで、外部から提供されるサービスを含め、アプリケーション全体を構成するコンポーネントサービスは何ですか？また、それらはどのように通信していますか？
- これらのサービスはどのように通信しますか？使用されるAPIは何ですか？そしてこれらのやり取りにはどのような制約（役割、アクセス制御、レート制限、パラメータなど）がありますか？
  - APIの形式とその制約、通信の暗号化についても、上記と同様の質問が考えられます。
  - 「内部」（例えば、ワークロード間/コンテナ間）の通信は、共有メモリやファイルシステムベースのインターフェースを使用する可能性が高く、そのようなインターフェースを特定する必要があります。
ブラックボックス化したインターフェースや内部通信経路へのアクセスを制限するために、システムでどのような制御メカニズムを利用できますか？
- 誰が、どのような役割で、特定のAPIを呼び出すことができるかと、そのポリシーに違反した場合に何が起こるかを示したポリシーはありますか？同様に、無効なパラメータや速すぎるレートでの呼び出しなど、APIの不正使用を検出して緩和する手段はありますか？これらのポリシーを、他のシステムからのコンテキストベースの情報に基づいて動的に更新できますか？
- 同様に、ファイルシステム、オブジェクトストア、データベーステーブルなど、他の形式のワークロード間通信を、誰がどのファイル/ストア/テーブルにアクセスできるかという視点から制約し、それらのリソースの不正使用を防ぐポリシーはありますか（例：「SELECT * from 」）？
- ブラックボックス化したインターフェースや内部通信経路へのアクセスを制限するために、システムでどのような可視性（ダッシュボード、ログ、統計情報）を利用できますか？
  - 誰がどのタイミングでどのAPIを起動したかを特定できますか？そのデータは保存されますか？保持される場合、その期間はどのくらいですか？そのデータはどれくらいの速さで（リアルタイム、毎時など）利用可能になりますか？データはどのように利用できますか？つまり、非構造化ファイルのログか、セキュリティイベントやインシデント管理（SEIM）サービスに送信できる構造化されたJavaScript Object Notation（JSON）か、またはビッグデータのデータベーステーブルに記録されますか？
  - 他の通信経路（メモリ、ファイル、オブジェクト、データベース）については同じ質問に対してどのような回答になりますか？誰が何を行いますか？そのデータはどのように公開されますか？
- 通信経路の他に、リソースの過剰利用や過剰消費を防ぐために、どのような制御や可視性が提供されていますか？
  - CPU、メモリ、帯域幅、ポッドスケーリングなど、リソースの消費に関する指標を可視化できますか？その場合、どの程度の粒度で、そのデータはどの程度消費できますか？
  - ワークロードごとのメモリ/CPU/ファイルIOの制限、プロセス生成システムコールの追跡、ポッドのスケールアップ/スケールアウトの制限、他のサービスを呼び出すAPIのレート制限など、リソースの消費に関する制御や逸脱を防止する手段はありますか？

緩和策の検討事項：適時性、偽陽性/偽陰性、リスク

この考え方の前提である「侵害の想定」によって具体化されているように、セキュリティ担当者は、強い動機を持つ攻撃者が悪質なトランザクション、すなわち完璧な世界であればポリシールールに従っているが許可されるべきではない、Who（誰が）、What（どのようなアクションを）、Whom（誰に対して）行うかの実例をうまく実行させることを想定しなければなりません。このような場合、前の「侵害を想定する」のセクションで説明したように、通常はトランザクションのパターンの観察とシステムの副作用に基づいて、このようなケースを発見できる効果的な「最終手段」のメカニズムを備えることが焦点になります。

しかし、IDの概念と同様に、特定のトランザクションが悪質かどうかに関する情報は決して完全ではありません。したがって、IDの場合と同様に、理想的なゼロトラストソリューションは、トランザクションの正当性に対する「信頼度」スコアを報告する必要があります。例えば、あるデーモンが通常の10倍のファイルレートで10秒間読み書きするのを検出した場合、（悪意のある）信頼度スコアは70％になり、レートが100倍で1分以上継続するのを検出した場合は、信頼度が95％になるかもしれません。この例では、今後のファイル書き込みを禁止するという修復措置を講じた場合、誤った反応、つまり「誤検出」となる可能性があります（それぞれ30％または5％の確率）。したがって、修復するかどうかの判断は、誤検出のリスクと、悪質である可能性のある動作を許可した場合の潜在的な影響を考慮する必要があります。

この例でポイントとなるのは、ユーザーが認識できる形で修復措置を講じるかどうかの判断は、実際にはビジネス上の意思決定であり、疑わしい行動に関するすべてのリスク、コスト、リターンを考慮すべきであることです。トランザクションの煩雑さが増大すると、価値を得られなくなる確率が高まりますが、介入しない、つまり煩雑さを増大させないという選択は、侵害のリスクを生みます。したがって、このような場合に措置を講じる（または講じない）という意思決定は、次の3つの要素に基づく関数になります。

悪質な可能性のあるトランザクションの継続を許容する場合のリスクは何ですか？
このリスクは、銀行資金の移動など直接的に金銭に関係するものである場合も、運用コスト（重要な記録が暗号化されて身代金を要求されるなど）やブランディングコスト（Webサイトの改ざんなど）といった間接的なコストである場合もあります。また、個人顧客データの流出など、法的コストやコンプライアンスに関するコストが発生する場合もあります。本質的に、リスクの割り当てはガバナンスの問題であり、優れたガバナンスはアプリケーションのリスクの理解につながり、リスクを定量化します。

修復措置を講じることで、どのような副作用がありますか？
副作用は、（a）増大する煩雑さと（b）ブラストゾーンという観点で表すことができます。煩雑さとは、正当なトランザクションの処理がどの程度難しくなるかを示し、その範囲は多少不便になる程度（例えば認証のレベルが追加される）から不可能なもの（そのトランザクションが許可されない）まであります。ブラストゾーンは、他の独立したトランザクションにも影響するかどうかと、影響する場合はその規模を示します。例えば、特定のユーザーをブロックするとそのユーザーのみに影響しますが、ロギングサービスを停止することは、すべてのユーザーとトランザクションの監査の可能性に影響します。

そのトランザクションが悪質であるという信頼度はどの程度ですか？
信頼度を高めるには、通常、より多くのデータポイントを収集し、より多くのデータソース間で相関をとる必要があり、いずれも時間がかかるため、実際には、「措置を決定するまでに監視すべき時間」とのトレードオフとして考えます。

したがって、ゼロトラスト戦略では侵害は発生するという事実を前提としなければなりませんが、周到なアプローチでは、許可されているが疑わしいトランザクションの是正について、リスク/リターンアプローチを採用します。このトレードオフでは、さまざまなアプリケーショントランザクションのリスクレベルと、修復措置を適用した場合の結果を理解し、リスクレベルが期待されるビジネス上のリターンを上回る場合にのみ、修復措置を適用することになります。

¹ https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf

² https://csrc.nist.gov/publications/detail/sp/800-207/final

³ https://www.cisa.gov/zero-trust-maturity-model

⁴ https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF

⁵ https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf

⁶ https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf

⁷ 後述するように、設計段階から事前の検討が始まります。

⁸ または、少なくともシステムが必要としていると考えられる「適切と思われる」一連のやり取り。観察から得られた一連のやり取りが不完全であったり、何らかの既存のリスクが存在したりするリスクは常にあります。したがって、設計段階で事前に検討する必要があります。