ゼロトラストセキュリティ: ゼロトラストが重要な理由 (アクセス以外の面でも)

抽象的な

ここ数年のネットワークおよびアプリケーションアクセスにおける主要なテーマの 1 つは、「ゼロトラスト」の概念でした。本稿では、ゼロトラストの核心が、アクセスだけでなくサイバーセキュリティの分野全体に広く適用できる、一連の単純な信念によって特徴付けられることを示します。

このホワイトペーパーでは、ゼロトラストに関する幅広い概念を網羅するフレームワークを提示し、それらを、今日のアプリケーションセキュリティビジネスリーダーの動機となっている既存のビジネス背景に関連付けます。最後に、この論文では、現在の脅威と新たな脅威に対処するツールとセキュリティ実装の原動力となるゼロトラスト信念体系の特徴を説明します。このゼロトラスト信念体系については、後続の論文で焦点を当てます。

このホワイトペーパーの目標は 2 つあります。1 つ目は、アプリケーションビジネスリーダーが採用すべきセキュリティの考え方を伝えること、2 つ目は、今後のホワイトペーパーで拡張するセキュリティ担当者向けのフレームワークを紹介することです。

ZTS: テクノロジーではなく原則から始める

「ゼロトラスト」という用語は、さまざまな抽象化レイヤーにおけるさまざまな概念に関連付けられています。特定のソリューションアーキテクチャとして使用される場合もありますし、特定のテクノロジを適用するための規定として使用される場合もあります。また、製品の特性を指す場合もあります。私たちは、ゼロトラストセキュリティとは本質的に考え方、つまり信念体系であり、そこからテクニックや戦術が生まれ、特定のテクノロジーを活用し、幅広いセキュリティ脅威に対処するために適用できると考えています。

ゼロトラストセキュリティ (ZTS) の基盤となる信念体系は、何年も前に「多層防御」から始まったセキュリティの考え方の進化における次のステップとして考えることができます。多層防御は、単一の防御スクリーンでは侵入される可能性は小さいながらも実際にあるが、主要資産に対する保護層を増やすことでその可能性を減らし、攻撃者の攻撃速度を低下させると同時に、攻撃を成功させるために攻撃者により多くのリソースを使わせるという考えに基づいています。

ゼロトラストとは、この考え方を次の 3 つの側面で成熟させたものです。

まず、保護の前提を、アプリケーションへのアクセスを制御する単純な「フィルター」のセットから、あらゆるシステムトランザクションに状況に応じて適用される、より資産に適した保護のセットへと進化させます。各取引の考え方は次のことを理解することです。誰が誰に対してどのような行動をとろうとしているのか。「who」と「whom」は、システム内の任意のコンポーネント、またはシステムを使用する任意のコンポーネントであり、人間、自動化されたもの、またはコードの一部である可能性があります。アイデンティティの概念は、 whoとwhomにとって重要であり、アイデンティティに付与される権限の概念は、何ができるかを成文化するために使用されます。
第二に、セキュリティ決定の評価は静的かつ絶対的なものではなく、観察された動作に照らして継続的に再評価される、より動的かつ適応的なものであると考えています。各トランザクションの処理（やり取りを許可するか、ブロックするか、さらなる信頼を築くかなど）に関する決定では、より広範なビジネスコンテキスト、特にリスクと報酬のトレードオフも考慮する必要があります。
最後に、どんなに多くの保護層が提供されていても、十分な動機または幸運な敵対者は保護を突破するか回避することを前提としています。したがって、あらゆる侵害をタイムリーに検出し、悪用の試みを軽減することも、全体的な戦略の重要な部分でなければなりません。

この進化は、部分的には時間と経験の結果ですが、他の 2 つのアプリケーションセキュリティトレンドの合流によってますます推進されています。具体的には、今日のアプリケーションアーキテクチャでは、アプリケーションの脆弱性、特にアプリケーションインフラストラクチャの「内部」からの脅威の潜在的な空間が大幅に拡大しており、今日の攻撃者の高度化によって悪用される可能性が高まっています。幸いなことに、セキュリティツールの同時進歩により、特に最新のデータ収集および分析機能と組み合わせて使用すると、防御戦略の主要コンポーネントを実際に実装できるようになりました。

この紹介の残りの部分では、ゼロトラストセキュリティへのアプローチのフレームワークとその範囲の概要を説明します。そこから、次のセクションでは、問題ステートメントと、ゼロトラストに対する他の現代的なアプローチとの関係について詳しく説明し、ソリューションテクノロジの選択とその適用を導くべき中核となる信念 (「なぜ」) について説明します。今後の論文では、ゼロトラスト成熟モデルに関連する認証、アクセス制御、AI 支援分析などの特定のテクノロジーに課される要件である「方法」について詳しく説明します。

ZTS: それはなぜから始まります

サイモン・シネックの「Start with Why」アプローチは、下の図 1 に示すように、ZTS フレームワークを伝えるための効果的なツールです。このグラフィックは、ZTS が対処する脅威のクラスから始めて、使用されるセキュリティメソッドを詳細に調べ、最後にすべてを共通の原則に絞り込むという形で、外側から内側へと見ることができます。あるいは、中核となる信念を北極星として、内側から外側への視点で捉えることもできます。そこから適切なツールやテクニックが生まれ、幅広い脅威に対処できるようになります。

図 1 - ゼロトラストセキュリティ: 信念体系、ツール、利点。

後のセクションでは、この図の各同心円層について詳しく説明しますが、簡単に説明すると次のようになります。

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

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の導入
  サービスとしてのソフトウェア (SaaS) は、プライベートデータセンターでのアプリケーションの調達、展開、保守にかかる負担を大幅に軽減するため、ビジネス運用アプリケーションにとって有利です。
6. マイクロサービスアーキテクチャ
  チームはマイクロサービスを使用して、市場投入までの時間を短縮しながら継続的な配信を実現します。
7. 分散アプリケーションコンポーネント
  組織は、サービスの機能を開発または提供するための最適なツールを提供するインフラストラクチャでマイクロサービスを実行することで効率性を実現します。レガシーワークフローの最近の拡張は、レガシー要素と通信する必要がある最新のアプリケーションアーキテクチャを使用して行われ、多くの場合、これら 2 つは異なるインフラストラクチャ上で実行されます。
8. オープンAPI
  さまざまなサービスのエコシステムは、企業がすべてのサービスを独自に開発するよりも効率的です。
9. サードパーティとのネットワーク接続
  企業は、暗号化されたトンネルを使用してパートナー、ベンダー、販売代理店と相互に接続し、ビジネスプロセスを自動化および合理化します。

セキュリティリスクの増大
1. 攻撃対象領域の拡大
  サードパーティのソフトウェアやオープンソースライブラリを使用すると、サプライチェーン攻撃の機会が生まれ、外部で開発されたソフトウェアの脆弱性がすべて継承されます。契約開発者は、機能を期限通りに完成させることに意欲的であり、セキュリティは彼らの懸念事項ではありません。さらに、ソフトウェアを納品してプロジェクトを終了した後、社内のチームがコードを調べてセキュリティホールを見つけるのは困難で時間がかかります。アジャイルスプリントは機能の提供に非常に効率的ですが、開発速度が速くなると、詳細なセキュリティ監査とテストに十分な時間が取れなくなります。他のマイクロサービスと通信する機能を持つ脆弱なマイクロサービスが 1 つあると、システム全体のセキュリティリスクが増大します。
  相互接続されたビジネスは業務効率を向上させますが、深刻な結果として、いずれかのビジネスにセキュリティ上の欠陥があると、すべてのビジネスに影響を及ぼすことになります。攻撃者は最も弱いリンクを見つけて、残りのリンクに拡散します。 SaaS プラットフォームまたはクラウドインフラストラクチャの脆弱性やセキュリティの欠陥は、追加の攻撃ベクトルとなり、責任共有モデルによって早期検出と修復が複雑になる可能性があります。
2. アーキテクチャの複雑さの増大
  さまざまなアーキテクチャを使用して開発され、複数のインフラストラクチャに展開される分散アプリケーション要素には、異なるセキュリティとコンプライアンスのニーズがあります。このため、セキュリティチームにとって、エンタープライズアプリケーションとデータを保護し、規制コンプライアンス要件を満たすための適切なメカニズムを設計および導入することが複雑になります。
3. 資金が豊富で、やる気があり、熟練したハッカー
  2010 年の「オーロラ作戦」から 2020 年の「ソーラーゲート」まで、大きな被害をもたらしてから初めて発見される高度なサイバー攻撃が 10 年間続きました。侵害は、高度な訓練を受けたセキュリティチームが運営する最高のセキュリティテクノロジーを備えた組織で発生しました。攻撃者は、検出されるまで長期間にわたってこれらの組織の IT インフラストラクチャに潜伏していました。 IT チームとセキュリティチームがサイバー攻撃を阻止するための規制を遵守するために最善を尽くしたにもかかわらず、知的財産が盗まれ、個人を特定できる情報が盗まれ、業務運営が中断され、組織がランサムウェアの人質に取られる事態が発生しました。

米国政府の指令

米国のさまざまな連邦、州、地方政府機関、および複数の米国企業に対する執拗なサイバー攻撃の集中砲火を受けて、ジョー・バイデン大統領は2021年5月12日に国家のサイバーセキュリティの改善に関する大統領令を発令した。この命令の重要な要素の 1 つは、政府機関がサイバー攻撃に備えるためにゼロトラストの原則を使用することです。バイデン政権はこの命令に従い、2022年1月26日に行政管理予算局（OMB）から行政部門および行政機関の長宛てに覚書を出した。 OMB からのこの覚書は、「ますます高度化され、執拗になる脅威キャンペーンに対する政府の防御を強化するために、政府機関が 2024 年度末までに特定のサイバーセキュリティ基準と目標を満たすことを義務付ける連邦ゼロトラストアーキテクチャ (ZTA) 戦略を規定しています。」¹ 大統領令とOMB覚書はどちらも、2020年8月に発行された米国国立標準技術研究所（NIST）の出版物SP 800-207に記載されているゼロトラストアーキテクチャに言及しており、政府機関にそれに従うことを義務付けています。

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

政府機関や民間部門の思想的リーダーたちは、ゼロトラストアーキテクチャを説明し、それを最も効果的に導入する方法に関するアドバイスを提供する論文を発表しています。これらの論文に含まれるアイデアを以下に要約します。これらの論文に含まれるアイデアや提案の重要な本質は、すべてのトランザクションを検査して誰が誰に対してどのようなアクションを試みているかを評価し、それに関連するリスクの計算に基づいてトランザクションを許可するか拒否するかをリアルタイムで決定することであることに注意してください。

国立標準技術研究所 (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) は「ゼロトラストセキュリティモデルの採用」という論文の中で、サイバーセキュリティチームにゼロトラストセキュリティモデルを採用するようアドバイスするガイダンスを発行しました。⁴ 国防情報システム局 (DISA) と国家安全保障局の合同ゼロトラストエンジニアリングチームの専門家が、国防総省 (DOD) ゼロトラストリファレンスアーキテクチャを作成しました。⁵ 著者は、ゼロトラストの採用の必要性を次のように述べています。「国防総省内外でのデータ侵害によって明らかになった脆弱性は、十分な情報に基づいたリスクベースの意思決定を促進する、新しくより堅牢なサイバーセキュリティモデルの必要性を証明している。」⁶

このリファレンスアーキテクチャは、NIST SP 800-207 ゼロトラストアーキテクチャドキュメントで定義されている抽象化に基づいて推奨事項を作成します。このドキュメントでは、高レベルの運用モデルを紹介し、その要素について詳しく説明します。また、高レベルの成熟度モデルと、ゼロトラストの原則をさまざまな関心領域に適用するための機能のマッピングも含まれています。これらのドキュメントを総合的に活用することで、組織は現状を評価し、計画を立てることができます。

ゼロトラスト原則によるリスクとガバナンスの管理

「侵害を想定する」姿勢を持ち、ゼロトラストの原則に従うことは、組織のリスク管理とガバナンスの実践に役立ちます。トランザクションに関与するアクターの「継続的な監視」と「明示的な検証」というゼロトラスト原則により、組織はすべてのアクターとその活動に対して動的なリスクスコアを構築できます。これは、既存のセキュリティプログラムを強化するために「継続的適応型リスクおよび信頼性評価」(CARTA) 方法論を使用するというガートナーの推奨と一致しています。リソースへの最小限の権限アクセスのみを許可するという原則を採用すると、侵害が発生した場合でも損失のリスクが軽減されます。継続的な監視と明示的な検証によって生成された情報は、コンプライアンスレポートの生成にも役立ちます。

マインドセットの詳細

このセクションでは、企業がゼロトラストセキュリティのために採用すべきツールと設計に関する戦略と意思決定の動機となる考え方、つまり信念体系、「なぜ」に焦点を当てます。実際、今日のゼロトラストソリューションで採用されているすべての方法とコンポーネントテクノロジーの原動力は、4 つのシンプルな主要原則に集約できます。このセクションでは、まずこれらの原則を列挙し、次にアプリケーション開発ライフサイクルのより広いコンテキスト内でこれらの原則をどのように適用できるかについて説明します。つまり、設計フェーズで事前にこれらの原則を考慮する方法と、アプリケーションの展開/実行時に運用上どのように考慮するかについて説明します。

ゼロトラスト運用原則

ゼロトラストソリューションが、基本的にシステムのインタラクションにおける信頼を構築するものであると理解されている場合 (「誰が誰に対して何をしているのか?」)、インタラクションに適したレベルの信頼の構築は、4 つの要素に分解できます。

明示的に検証する

名前が示すように、ゼロトラストの考え方は「盲目的に信頼するのではなく、常に検証する」というものです。したがって、システム内のすべてのアクター (システムの相互作用におけるWhoとWhom ) は、次のことができる必要があります。

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

さらに、明示的に検証するという原則は、アイデンティティだけでなく、アクション（トランザクションの内容）にも適用できます。一般的な使用例としては、データベースクエリを実行する API など、アクションが API 呼び出しとして表現される場合が挙げられます。この例では、明示的な検証の原則を使用して、API を呼び出すアクターの ID に自信を持つだけでなく、API に渡されるパラメーターが適切な制約に準拠しているかどうかを確認するなど、API アクションの使用の正確性も確認できます。

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

最小権限

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

これらの権限は、個々のアクターに適用される場合もあれば、アクターのクラスに適用される場合もあります。通常、アプリケーションの消費者は人間のアクターまたは人間の代理人であり、「匿名ユーザー」、「顧客」、「パートナー」、「従業員」などのクラスにグループ化されます。信頼性の低いアクターのクラスでは、通常、認証に合格するために必要な信頼しきい値が低くなりますが、アクセスできる API も少なく、機密性も低くなります。アプリケーションまたはそのインフラストラクチャの内部アクター (アプリケーション内の特定のサービスやコンテナーなど) には、多くの場合、よりカスタマイズされた権限があります。たとえば、「コンテナー <X> と <Y> のみがデータベースにアクセスでき、<X> のみがオブジェクトストアに書き込むことができますが、<Y> と <Z> はそこから読み取ることができます。」などです。

最小権限の実装に関する重要な考慮事項は、事前に検討して、よりカスタマイズされた方法でそれを適用するように努めることです。⁷ 具体的には、すべてのアクターまたはアクターのクラスに一般的な権限セットを適用するのではなく、成熟したゼロトラスト実装では、試行されているアクションをより詳細に把握する必要があります。たとえば、非常に粗い粒度では、「ファイルシステムアクセス」に権限が付与される可能性がありますが、「ファイルシステムの読み取り」は実際に必要な権限のより厳密な仕様であり、ポジティブセキュリティモデルの高品質な実装を実現します。

最後に、最小権限のより洗練された実施形態は、アクターの承認された権限を絶対的なものとしてではなく、認証によって提供される信頼性に基づくものとして見なすことで、「明示的な検証」の成熟した実装と組み合わせて機能することができます。したがって、権限は、証明された ID ( Who ) の信頼性が最小しきい値を満たしている場合にのみ付与され、しきい値は試行されるアクションに固有のものになります。たとえば、特に影響力のあるアクション (システムのシャットダウンなど) では、実行者が管理者であるという信頼度が 90% 以上必要になる場合があります。この例では、シャットダウンが試行されたときにシステムの ID に対する信頼度が 80% しかない場合、システムはアクションを許可する前に、証明された ID の信頼スコアを高めるために追加の検証を必要とします。

継続的に評価する

明示的な検証と最小権限は重要な概念ですが、継続的な評価の原則は、次の意味でこれらの原則を継続的に評価する必要があるという事実を捉えています。

すべての取引は検証と特権の対象となります。言い換えれば、「ユーザーセッションの最初のトランザクション」や「Docker コンテナワークロードによって開始されたトランザクション」など、トランザクションのサブセットのみが検査の対象となるべきではありません。これは自明のように聞こえるかもしれませんが、多くのゼロトラスト実装では、設計が不十分であるか可視性の欠如により、すべてのトランザクションが検証されません。この分野でよくある欠点は、ゼロトラストを外部のアクターにのみ適用し、内部のアクターには適用しないこと、および/またはゼロトラストの判定が長期間にわたって真実であると想定することから生じます。
評価における重要な要素、つまり行為者のアイデンティティに対する信頼性とその行為者に認められる権利は、動的かつ変化するものとして捉えられなければならない。たとえば、アイデンティティに対する信頼度は、観察された動作やサイドバンドメタデータに基づいて時間の経過とともに増加したり減少したりすることがあり、したがって、信頼度に基づくポリシーは、変化する信頼度に合わせて動的に調整する必要があります。さらに、以前にポリシーによって付与された権限しきい値が少し後に取り消されたり、何らかのアクションに必要な最小限の信頼度が変更されたりする可能性があります。ポリシー変更のタイムスケールはさまざまですが、ゆっくりと変化する可能性（人間の運用プロセスのタイムスケール）もあれば、急速に変化する可能性（自動化されたガバナンスエージェント経由）もあります。システムは、それらの変更に動的に対応し、それを尊重できる必要があります。

違反を想定する

最後の原則は、健全な妄想を背景に、非常に意欲的な敵対者がいるという推定に基づいています。具体的には、「違反があったと仮定する」という前提があり、「違反」は「（完全な認識と実行があれば）拒否されるべきだったが、代わりに許可された取引」と定義されています。このエスケープの根本的な原因は、不完全な知識（例：検出されていない不正な資格情報に起因する認証からの誤った高い信頼スコア）である可能性があり、または実装の制限（例：付与された権限の細分性が十分に高くない、たとえば「オープンネットワーク接続」を権限として持っているが、ネットワークの宛先の地理的位置に基づいて区別する機能がない）である可能性があり、またはゼロトラストの不完全な実装（例：内部で使用される脆弱なオープンソースコンポーネントにゼロトラストを適用していない）が原因である可能性があります。

したがって、ゼロトラストの考え方では、このような侵害の影響を最適に管理/最小限に抑える方法にも取り組む必要があります。

この原則の実装は他の原則よりも多岐にわたりますが、一般的には次のように表されます。

まず、ポリシーによって技術的には許可されているものの、疑わしい取引を特定します。「疑わしい」というのは多くの場合、状況によって大きく異なりますが、一般的な解釈は、(a) 過去に観察された動作とは大きく異なる異常なトランザクション、(b) 個々には正常だが全体としては異常なトランザクションのグループ (たとえば、ファイルの読み取りと書き込みは一般的だが、1 秒あたり 1,000 ファイルの読み取りと書き込みの速度は異常である)、または (c) 望ましくない、かつこれまでに見られなかったシステムへの影響と相関するアクション (たとえば、特定のトランザクションが TOR ノードへのネットワーク接続を開いたり、システムの CPU 負荷を大幅に増加させたりするパターン) です。
次に、完全に自動化されたワークフロー、または人間が制御するワークフローと ML が支援するワークフローのハイブリッドのいずれかで、より詳細な分析を実行し、それらのトランザクションが無効かどうかを判断します。これらのトランザクションが無効であると判断された場合は、軽減策を適用します。これは、一般的なポリシーの更新の形をとることも、追加の緩和策として、他のポリシー主導の緩和策に対する「バックストップ」の形をとることもできます。

ポリシーベースの調整を使用するアプローチを選択した場合は、利用可能な静的ポリシーツールのいずれかを活用して調整を適用できます。ポリシーベースの調整の例としては、トランザクション粒度のアクセス制御権限を制限する（つまり、誰が誰に対して何を実行できるかを許可しない）ことや、代わりにアクター（またはアクターのクラス）が特定のアクションを実行するために、より厳格な「証明基準」を適用する（つまり、MFA またはより高い信頼スコアを要求する）ことが挙げられます。

代わりに、追加の「バックストップ」レイヤーを使用するアプローチを選択した場合、この戦略は細粒度または粗粒度のいずれかとして実装することもできます。最もきめ細かな戦略は、特定のリスクと報酬の比率を超えるトランザクションのみを正確にブロックすることですが、実装で追加の分析が必要な場合、このソリューションでは、許可されたトランザクションの一部に許容できないレベルのレイテンシが追加される可能性もあります。代わりに、そのアクターの将来のトランザクションをサンドボックス化したり、システムからアクターを完全に禁止したりするなど、より粒度の粗い戦略を使用することもできます。極端な場合には、ファイル I/O をシャットダウンするなど、さらに大まかな緩和方法が適切な場合もあります。

もちろん、他の条件が同じであれば、より細かい粒度のバックストップ緩和策が一般的に望ましいです。ただし、利用可能なソリューションテクノロジの制約に基づいてトレードオフを行う必要がある場合が多く、通常は、バックストップがないよりも粗粒度のバックストップの方が優れています。たとえば、疑わしいランサムウェアを防ぐための大まかな対応がファイル I/O を無効にすることである場合でも、その対応の副作用は、何もしないことの結果としてランサムウェアで暗号化されたファイルシステムになることを前提として、攻撃者がシステム内でチェックされずに操作を継続できるようにするという代替策よりも好ましい可能性があります。

ゼロトラスト: それは運用前に本当に始まります

ゼロトラストを使用した安全なアプリケーション開発の最適な出発点は、当然ながら、最初です。ゼロトラスト原則を運用可能にする基本原則は、アプリケーション開発プロセスの設計フェーズに組み込む必要があります。したがって、CI/CD パイプラインに統合された運用上のゼロトラストソリューションに関する議論は、第一級の設計上の考慮事項となるこれらの基本要素を理解することから始める必要があります。

これらの基本要素の中核は、システム動作の相互作用の望ましい/意図された動作を捉え、逸脱を検出して対処するための十分な可視性と制御を組み合わせる必要があります。意図された相互作用は、各アクター ( Who ) の各ターゲット ( Whom ) に対する望ましい一連のアクション ( What ) を定義するために使用されます。ただし、意図されたインタラクションパターンが不明なシナリオや環境も存在する可能性があります。このような場合、組織はより深い可視性を活用して、適切なインタラクションのセットを「発見」することができます。⁸それを政策として成文化することができます。

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

以下は、設計プロセスの一部となるべき基本的な考慮事項に関連する高レベルの「バケット」のリストです。さらに、各主要ポイントについて検討すべき具体的な質問を提供するためのドリルダウンも含まれています。

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

これらの質問を明確にすることで、ゼロトラストを実現するための基盤のどこにギャップが存在するかを発見するのに役立ちます。多くの場合、設計の早い段階で単に質問するだけで、追加の設計作業を最小限に抑えてギャップに対処できるようになります。また、ギャップが残る可能性がある場合は、そのギャップを認識するだけで、セキュリティの重点をさらに集中させたり、脆弱な脅威の表面を特定したりするのに役立ちます。

このような事前の安全な開発分析を行うことは、ゼロトラストの考え方の重要な部分です。しかし、この事実にもかかわらず、今日のゼロトラストの焦点の多くは、初期設計後に何が起こるかということにあり、ほとんどの企業の焦点の大部分は、ゼロトラストの設計後の側面に集中しています。ただし、設計段階でゼロトラストを効果的に実装するための要件について慎重に検討することで、アプリケーションの展開後に「穴を塞ぐ」ために必要な、はるかに大きな段階的な作業を防ぐことができます。

緩和策の検討: 適時性、誤検知/誤検知、リスク

「侵害を想定する」という考え方を体現しているように、セキュリティ担当者は、十分な動機を持つ敵対者が悪意のあるトランザクション（誰が誰に何をするかという、ポリシールールを満たしているものの、理想的な世界では許可されるべきではないインスタンス）を実行することを想定する必要があります。このような場合、焦点は、前述の「侵害を想定する」セクションで説明したように、通常はトランザクションのパターンとシステムの副作用の観察に基づいて、そのようなケースを見つけることができる効果的な「バックストップ」メカニズムを持つことに移ります。

しかし、アイデンティティの概念と同様に、特定のトランザクションが悪意のあるものかどうかの知識は決して完璧ではありません。したがって、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/2月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

⁷ 前述の考慮は、後述するように設計段階から始まります。

⁸ または、少なくとも、システムが要求していると思われる「適切だと考えられる」一連のインタラクションです。観察から得られた一連の相互作用が不完全であったり、何らかの既存のリスクがあったりするリスクが常に存在します。したがって、設計において事前に考慮することが常に望ましいです。