ゼロトラストセキュリティ：ゼロトラストが重要な理由（アクセス制御だけではない、その価値）

概要

ここ数年、ネットワークおよびアプリケーションへのアクセスにおける主要なテーマの1つとなっているのが、「ゼロトラスト」という概念です。本稿では、ゼロトラストの本質が、アクセスだけでなくサイバーセキュリティ分野全般に広く適用できる、少数のシンプルな考え方によって特徴付けられることを示します。

本稿では、ゼロトラストをめぐる幅広い概念を包括するフレームワークを提示し、今日のアプリケーションセキュリティ事業のリーダーが取り組みを進める動機となっている既存のビジネス環境との関連性を示します。最後に、現在および新たに生じつつある脅威に対処するツールやセキュリティ実装の原動力となる、ゼロトラストの信念体系の特徴を明らかにします。これらのツールと実装については、続編で詳しく取り上げます。

本書の目的は2つあります。第1に、アプリケーションビジネスのリーダーが持つべきセキュリティの考え方を伝えること、第2に、今後のホワイトペーパーでさらに詳しく取り上げる、セキュリティ実務担当者向けのフレームワークを紹介することです。

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

「ゼロトラスト」という用語は、さまざまな抽象度で異なる概念と関連付けられています。特定のソリューションアーキテクチャを指す場合もあれば、特定のテクノロジーの適用を求める指針や、製品の特性を指す場合もあります。F5は、ゼロトラストセキュリティの本質はマインドセット、すなわち信念体系にあると考えています。そこから生まれる手法や戦術に特定のテクノロジーを活用することで、幅広いセキュリティ脅威への対処に応用できます。

ゼロトラストセキュリティ（ZTS）の根底にある考え方は、何年も前に「多層防御」から始まったセキュリティに対する意識の進化における、次の段階と捉えることができます。多層防御は、個々の防御策には小さいながらも現実に突破される可能性がある一方、重要な資産を保護する層を増やすことでその可能性を低減し、攻撃者の進行を遅らせるとともに、攻撃を成功させるためにより多くのリソースを費やさせる、という考え方に基づいています。

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

  • 第1に、保護の前提を、アプリケーションへのアクセスを制御する単純な「フィルター」の集合から、あらゆるシステムトランザクションに対してコンテキストに応じて適用される、資産により適した一連の保護へと進化させます。各トランザクションでは、次の点を把握するという考え方が基本となります。すなわち、誰が、誰に対してどのような操作を試みているかということです。ここでいう「誰が」と「誰に」は、人間、自動化された主体、コードのいずれであっても、システム内のコンポーネントまたはシステムを利用するコンポーネントを指します。誰が、誰にを定めるうえではアイデンティティの概念が重要であり、アイデンティティに付与された権限の概念によって、何が実行可能かを明文化します。
  • 第2に、セキュリティ上の意思決定に関する評価を、静的かつ絶対的なものではなく、より動的で適応性の高いものとして捉えます。そのため、観察された動作に照らして継続的に再評価します。各トランザクションをどのように処理するか（インタラクションを許可するか、ブロックするか、信頼度をさらに高めるかなど）を決定する際には、より広範なビジネスコンテキスト、特にリスクとリターンのトレードオフも考慮する必要があります。
  • 最後に、保護を何層設けても、十分な動機を持つ攻撃者や運に恵まれた攻撃者は、保護を突破するか回避することを前提としています。したがって、侵害を速やかに検知し、エクスプロイトの試みを緩和することも、全体的な戦略の重要な要素でなければなりません。

この進化は、時間の経過と経験の蓄積による部分もありますが、近年では、アプリケーションセキュリティに関する別の2つのトレンドが重なり合うことで、ますます加速しています。具体的には、今日のアプリケーションアーキテクチャによって、潜在的な脆弱性の範囲が大幅に広がっています。特に、アプリケーションインフラストラクチャの「内部」から生じる脅威は、高度化する今日の攻撃者に悪用される可能性があります。幸い、セキュリティツールも同時に進歩しており、特に最新のデータ収集・分析機能と組み合わせることで、防御戦略の主要な要素を実用的に導入できるようになりました。

この序論の残りでは、ゼロトラストセキュリティに対するF5のアプローチの枠組みと、その適用範囲の概要を示します。続く各セクションでは、問題提起と、ゼロトラストに対する現代の他のアプローチとの関係を詳しく説明したうえで、ソリューション技術の選択と適用の指針となる中核的な考え方、すなわち「なぜ」について考察します。今後のホワイトペーパーでは、ゼロトラスト成熟度モデルに関連して、認証、アクセス制御、AI支援型分析などの特定の技術に求められる要件、すなわち「どのように」を掘り下げます。

ZTS：「なぜ」から始める

以下の図1に示すように、Simon Sinekの「Start with Why」アプローチは、ZTSフレームワークを説明するうえで効果的な手段です。この図は、ZTSが対処する脅威の種類を起点に、使用するセキュリティ手法を掘り下げ、最終的に共通原則へと集約する「外から内へ」の視点で見ることができます。また、基本理念を指針として、そこから適切なツールや手法を導き出し、それらによって幅広い脅威への対処を可能にする「内から外へ」の視点で見ることもできます。

図1：ゼロトラストセキュリティの信念体系、ツール、メリット

後のセクションでは、この図の各同心円状のレイヤーについて詳しく説明しますが、概要は次のとおりです。

  • 中核となる考え方は、ユースケースを次のように捉えることに基づいています。
    「誰が、誰に対して、何（アクション）を試みているのか？」
    • 「誰が」誰に「何をするのか」を明らかにするため、誰に明示的に検証あらゆる身元証明を行います。
    • 「誰が」を確立したら、最小権限の原則を使用して、「何を」実行できるかを制限します。
    • 継続的に評価と再評価を行い、「誰が、何を、誰に」の3つの要素すべてについて「誰が、何を、誰に」ポリシーの制約に照らした検証を継続します。
    • 常に侵害や不正アクセスが発生することを前提とします。リスクとリターンの分析（認証における不正の可能性を、誤って取引を承認した場合のビジネスへの影響で重み付けしたもの）に基づき、アクション（何を誰にWhom）が事前に定めた許容可能な安全性のしきい値を超える場合に介入できるよう備えてください。
  • 使用する手法は次のとおりです。
    • 認証とアクセス制御により、一定の信頼度で「誰か」を特定し、そのアイデンティティに対して、特定の「誰を」対象に、どの「操作」を許可するかに応じて権限を制限します。Whom target.
    • 可視化と機械学習を活用した分析により、各トランザクションの全体的なコンテキスト（誰が誰に何を行っているか）を継続的に観察し、評価します。
    • リスクを考慮した自動修復。リスクとリターンの水準が指定された許容しきい値を超えた場合に、トランザクションに介入します。
  • 幅広いサイバー攻撃に対処 するために、以下の手法を適用します。
    • 従来型の攻撃（改ざんやデータ流出など）には、IDの侵害や権限昇格を検知し、認証とアクセス制御の手法を用いて、ポリシーにより「誰が」「何を」実行できるかを制限することで対処できます。
    • 可用性を狙う攻撃／DDoS攻撃 -- 認証とアクセス制御をリスク認識型の修復策と組み合わせることで、これらの攻撃に対処します。たとえば、認証されていない、または認証が不十分な攻撃者がリソースを大量に消費するトランザクションを試みた場合、そのアクセスをブロック（またはレート制限）します。
    • 高度な脅威（例：ランサムウェアやサプライチェーン攻撃）-- リスクを考慮した修復と組み合わせて、誰が誰に何をしているかという行動の変化や異常を検出することで、これらの脅威に対処できます。

ZTSの適用範囲

ゼロトラストセキュリティは、アプリケーション、インフラストラクチャ、デリバリースタック全体に包括的に適用し、開発パイプライン全体を対象とする必要があります。具体的には、以下を含める必要があります。

  • アプリケーションとインフラストラクチャの「上から下まで」すべてを網羅するスタック
    • サーバー、ネットワークインターフェイスカード、コプロセッサ、システムボードコンポーネントを含むハードウェアコンピューティング基盤
    • ハードウェア用の低レイヤーファームウェアおよびBIOS。
    • ハイパーバイザーやランタイムエグゼクティブなど、最下層のオペレーティングシステム。
    • アプリケーションレベル／コンテナのオペレーティングシステム。
    • 商用またはオープンソースの、外部から取り込まれたサードパーティ製アプリケーションコンポーネント。
    • 社内で開発した、または個別に開発したアプリケーションソフトウェア。
  • 完全な「左から右」のアプリケーションデリバリースタック
    • 各「トップツーボトム」スタック要素の継続的な保守とアップグレードに使用されるサプライチェーン。
    • ファイアウォール、ロードバランサー、APIゲートウェイ、イングレス／エグレス／メッシュコントローラー、インライン不正対策デバイスなど、あらゆるインラインのアプリケーションデリバリーコンポーネント。
    • Domain Name System（DNS）リゾルバーなど、トラフィック処理に間接的な影響を与えるアプリケーションデリバリーコンポーネント、またはセキュリティ情報イベント管理（SIEM）ソリューションやフェデレーションIDサービスなど、メタデータを間接的に受信するアプリケーションデリバリーコンポーネント。

従来、ゼロトラストでは、Dev、DevOps、DevSecOps、SREといった役割で表されることの多い、アプリケーション開発およびデリバリーチームに重点が置かれてきました。ここでこの点に触れる主な目的は、より広い視点を示すことです。ゼロトラストへの包括的なアプローチには、従来は対象とされてこなかった役割やインフラストラクチャに加え、サプライチェーンの調達戦略などの追加ワークフローも含めることが理想的です。

問題提起

CIOとCISOにとって、ビジネスの加速を支援するための情報技術のモダナイゼーションは、最優先事項の1つです。また、両者は企業のリスクガバナンスにおいても重要な役割を担っています。その目標は、ビジネスリスクを最小限に抑えながら、新たなデジタル体験によって顧客満足度を高め、サードパーティとのデジタル接続を通じて業務効率を向上させ、従業員が場所を問わず生産性を発揮できるようビジネスを支援することです。そのため、CIOとCISOの組織には、俊敏性を高めるために従業員が最新のテクノロジー、アーキテクチャ、ベストプラクティスを自由に活用できるようにする一方で、損失リスクを防ぐため、同じ従業員に適切なセキュリティ対策を講じさせ、人々の行動、アクセスする情報、使用するテクノロジーに対する統制を確立することが求められます。

組織は、市場やマクロ経済の状況、消費者行動、サプライチェーンの変化、およびセキュリティ上の危険に関連するリスクを把握し、管理する必要があります。リスクを正確に評価し、迅速に緩和策を講じる能力は、企業の競争優位性につながります。本書では、知的財産の喪失、業務プロセスの中断、個人を特定できる情報の漏えい、規制当局による罰金などを引き起こす可能性がある、セキュリティ上の危険に伴うリスクに焦点を当てます。セキュリティリスクは、検討対象となる状況について、以下の側面を評価することで算出できます。

  1. 関連する資産の価値
    トランザクションに関わる資産の重要度は、それぞれ異なります。たとえば、個人を特定できる情報で構成されるデータベースは、企業が製造した製品を取り扱う小売店舗の一覧を格納したデータベースよりも価値が高くなります。セキュリティチームとITチームは、決定論的なプロセスを使用して、資産の「価値」を表すスコアで分類した全資産のインベントリを作成できます。
  2. 侵害の影響
    侵害の性質によって、それに伴う影響が決まります。たとえば、個人を特定できる情報を含むデータストアでは、情報が密かに窃取された場合の影響は、データストアの可用性が損なわれた場合よりもはるかに大きくなります。やや曖昧ではあるものの、さまざまな種類の侵害を列挙し、それぞれに「影響」スコアを割り当てることができます。
  3. 侵害の可能性
    トランザクションが資産の侵害につながる確率は、そのトランザクションに伴うリスクを評価するうえで、最も確定的でない要因です。人間だけでは必要な観測規模に対応できないため、組織は機械学習と人工知能を活用し、侵害確率の算出に対する信頼度を高めています。

現在の課題は、すべてのトランザクションに伴うリスクをほぼリアルタイムで算出し、侵害が発生した場合に想定される影響を抑えるため、適切な緩和措置を講じることです。

問題の把握

ビジネスの加速を求める声に応じて新たな手法が導入される一方で、サイバーセキュリティリスクが増大しています。以下では、この点について詳しく説明します。

図2：ビジネス上のプレッシャーが新たな慣行を促し、リスクを増大させる
  1. ビジネス加速への要求
    1. デジタルエクスペリエンス
      消費者のデジタルエクスペリエンスに対する欲求は尽きることがなく、複数のプラットフォーム（PC、タブレット、携帯電話）で頻繁な改善を求めています。
    2. コネクテッドビジネス
      デジタルビジネスプロセスには、パートナー、ベンダー、販売代理店、および他社が提供するサービスとの接続が必要です。
    3. モバイルワークフォース
      業務を効率的に遂行するには、従業員がどこからでも業務アプリケーションにアクセスできる必要があります。
  2. ビジネスニーズに対応するための実践方法
    1. アジャイル開発手法
      企業は、プロジェクトの期限内の完了を重視する逐次的なウォーターフォール型アプローチから、顧客満足度を重視し、段階的かつ反復的に進めるアジャイル開発アプローチへと移行しました。
    2. 既製ソフトウェアの利用
      新たなデジタル体験をできるだけ迅速に提供するため、開発者は同業の開発者がオープンソースとして公開したコードを再利用します。
    3. 契約開発
      契約開発者に業務を委託することで、企業は必要に応じて人員を拡充できます。
    4. クラウドインフラストラクチャの利用
      クラウドの俊敏性、柔軟性、拡張性、使いやすさにより、開発者は必要なインフラストラクチャをオンデマンドで確保できます。
    5. SaaSの導入
      Software as a Service（SaaS）は、プライベートデータセンターで業務アプリケーションを調達、導入、保守する際の大きな負担を軽減できるため、こうしたアプリケーションに適しています。
    6. マイクロサービスアーキテクチャ
      チームはマイクロサービスを活用し、市場投入までの時間を短縮しながら継続的デリバリーを実現します。
    7. 分散型アプリケーションコンポーネント
      組織は、サービス機能の開発や提供に最適なツールを備えたインフラストラクチャ上でマイクロサービスを実行することで、効率を高めています。従来のワークフローに対する最近の拡張には、レガシー要素との通信が必要なモダンアプリケーションアーキテクチャが使用されており、多くの場合、両者は異なるインフラストラクチャ上で稼働します。
    8. オープンAPI
      企業がすべてのサービスを自社で開発するよりも、多様なサービスで構成されるエコシステムを活用する方が効率的です。
    9. サードパーティとのネットワーク接続
      企業は、パートナー、ベンダー、販売代理店との間で暗号化トンネルを使用して相互接続し、ビジネスプロセスを自動化、効率化します。
  3. セキュリティリスクの増大
    1. 攻撃対象領域の拡大
      サードパーティ製ソフトウェアやオープンソースライブラリを使用すると、サプライチェーン攻撃の機会が生じるほか、外部で開発されたソフトウェアの脆弱性もすべて引き継ぐことになります。契約開発者は機能を期限内に完成させることを優先するため、セキュリティには関与しない場合があります。また、ソフトウェアの納品後に契約開発者がプロジェクトを離れると、社内チームがコードを精査してセキュリティ上の欠陥を見つけることは難しく、多くの時間を要します。アジャイルスプリントは機能を効率的に提供できますが、開発速度が上がることで、詳細なセキュリティ監査やテストに十分な時間を割けなくなります。他のマイクロサービスと通信できるマイクロサービスが1つでも脆弱であれば、システム全体のセキュリティリスクが高まります。相互接続された企業は業務効率を向上させる一方、いずれか1社のセキュリティ上の欠陥が全社に影響するという深刻な結果を招く可能性があります。攻撃者は最も脆弱な箇所を見つけ、そこから他の企業へと侵害を拡大します。SaaSプラットフォームやクラウドインフラストラクチャの脆弱性またはセキュリティ上の不備は、新たな攻撃経路となります。また、責任共有モデルによって、早期の検知と修復が複雑になる可能性があります。
    2. アーキテクチャの複雑化
      さまざまなアーキテクチャを使用して開発され、複数のインフラストラクチャに展開される分散型アプリケーションの各要素では、セキュリティとコンプライアンスの要件が異なります。そのため、セキュリティチームがエンタープライズアプリケーションとデータを保護するための適切な仕組みを設計・導入し、規制要件を満たすことが複雑になります。
    3. 潤沢な資金、高い意欲、優れたスキルを持つハッカー
      2010年のOperation Auroraから2020年のSolargateまでの10年間、高度なサイバー攻撃は、甚大な被害をもたらした後に初めて発覚する状況が続きました。最高水準のセキュリティテクノロジーを導入し、高度な訓練を受けたセキュリティチームが運用する組織でも、侵害が発生しました。攻撃者は、検知されるまで長期間にわたり、こうした組織のITインフラストラクチャ内に潜伏していました。ITチームとセキュリティチームが、サイバー攻撃を防ぐために策定された規制の遵守にとどまらない対策を講じていたにもかかわらず、知的財産や個人を特定できる情報が盗まれ、事業運営が妨害され、組織がランサムウェアの人質となりました。

米国政府の指令

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

Zero trust architectureと成熟度モデル

政府機関や民間部門のオピニオンリーダーは、ゼロトラストアーキテクチャの理解に役立ち、その最適な導入方法について助言する文書を公開しています。以下では、これらの文書に記載された考え方を要約します。これらの文書に示された考え方や提言の核心は、すべてのトランザクションを検証し、誰が、どのような操作を、誰に対して実行しようとしているのかを評価したうえで、関連するリスクを算出し、その結果に基づいてトランザクションを許可するか拒否するかをリアルタイムで判断することです。

米国国立標準技術研究所（NIST）：Zero trust architecture

NISTチームは、論文「NIST SP 800-207」でゼロトラストの原則を列挙し、抽象的なゼロトラストアーキテクチャ（ZTA）を定義しています。2 さらに、ゼロトラストのアプローチのバリエーションについて論じ、抽象アーキテクチャを導入するさまざまな方法を説明しています。

この文書で取り上げられている主要な抽象概念は、相互に連携するポリシー決定ポイント（PDP）とポリシー適用ポイント（PEP）です。ポリシー決定ポイントは、ポリシーエンジン（PE）とポリシー管理者（PA）で構成されます。ポリシーエンジンは、信頼アルゴリズムを使用して、サブジェクトにリソースへのアクセスを許可するかどうかを決定します。この決定はポリシー管理者によって実行されます。ポリシー管理者はポリシー適用ポイントと通信し、新しいセッションを許可または拒否するほか、既存のセッションを変更または終了します。また、この文書では、信頼アルゴリズムのバリエーション、ゼロトラスト環境のネットワークコンポーネント、さまざまなユースケースや導入シナリオについても説明しています。最後に、実装者が脅威を認識し、ゼロトラストアーキテクチャのコンポーネントを保護するための適切な対策を講じられるよう、攻撃者がゼロトラストアーキテクチャを妨害する手法についても考察しています。

Cybersecurity and Infrastructure Security Agency（CISA）：ゼロトラスト成熟度モデル

Cybersecurity and Infrastructure Security Agency（CISA）の有識者は、政府機関によるゼロトラスト計画の策定を支援するため、ゼロトラスト成熟度モデル（https://www.cisa.gov/zero-trust-maturity-model）を公開しました。3このモデルは、NIST SP 800-207で説明されている抽象的なゼロトラストアーキテクチャを基礎としています。著者らは5つの領域を特定し、各領域でゼロトラストの原則に従って着実に前進することを組織に推奨しています。5つの領域は、（i）アイデンティティ、（ii）デバイス、（iii）ネットワーク、（iv）アプリケーションワークロード、（v）データです。また、各領域で可視化と分析、および自動化とオーケストレーションを活用することを推奨しています。

この文書では、前述したゼロトラストの5つの基本的な柱すべてを対象とする概略的な成熟度モデルを示したうえで、各領域を詳しく掘り下げています。組織はこの成熟度モデルを活用して現状を把握し、最適な状態に向けて段階的に進む方針を策定できます。

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

SolarWinds攻撃の発覚を受け、米国家安全保障局（NSA）は論文「ゼロトラストセキュリティモデルの採用」で、サイバーセキュリティチームにゼロトラストセキュリティモデルの採用を推奨するガイダンスを発行しました。4 国防情報システム局（DISA）と国家安全保障局による合同ゼロトラストエンジニアリングチームの専門家が、国防総省（DOD）のゼロトラストリファレンスアーキテクチャを策定しました。5 策定者は、ゼロトラストを採用する必要性について次のように述べています。「DOD内外のデータ侵害によって明らかになった脆弱性は、十分な情報に基づくリスクベースの意思決定を可能にする、新たな、より堅牢なサイバーセキュリティモデルが必要であることを示しています。」6

このリファレンスアーキテクチャの推奨事項は、NIST SP 800-207のゼロトラストアーキテクチャ文書で定義された抽象概念に基づいています。同文書では、上位レベルの運用モデルを提示し、その構成要素を詳しく説明しています。また、上位レベルの成熟度モデルと、さまざまな対象領域にゼロトラストの原則を適用するための機能マッピングも含まれています。これらの文書を総合的に活用することで、組織は現状を評価し、計画を策定できます。

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

「侵害を前提とする」姿勢を持ち、ゼロトラストの原則に従うことは、組織のリスク管理とガバナンスの取り組みに役立ちます。取引に関与する主体を「継続的に監視」し、「明示的に検証」するというゼロトラストの原則により、組織はすべての主体とその活動について動的なリスクスコアを算出できます。これは、既存のセキュリティプログラムを強化するために「継続的かつ適応型のリスクおよび信頼の評価」（CARTA）手法を使用するというGartnerの推奨事項に沿ったものです。リソースへのアクセスを最小権限に限定するという原則を採用することで、侵害が発生した場合でも損失のリスクを軽減できます。継続的な監視と明示的な検証によって生成される情報は、コンプライアンスレポートの作成にも役立ちます。

マインドセットの詳細

このセクションでは、企業がゼロトラストセキュリティのために採用すべきツールや設計に関する戦略と意思決定の原動力となるマインドセット、すなわち信念体系や「なぜ」に焦点を当てます。実際、現在のゼロトラストソリューションで用いられているあらゆる手法と要素技術の根拠は、4つのシンプルな基本原則に集約できます。まずこれらの原則を列挙し、続いて、アプリケーション開発ライフサイクルというより広い文脈でどのように適用できるかを説明します。具体的には、設計段階で事前にこれらの原則をどう考慮するかに加え、アプリケーションのデプロイ時や実行時に運用面でどう考慮するかを取り上げます。

ゼロトラストの運用原則

ゼロトラストソリューションの本質を、システム上のやり取りにおける信頼、つまり「誰が、何を、誰に対して行っているのか」を確立することだと捉えると、そのやり取りに適したレベルの信頼を確立するプロセスは、4つの要素に分けられます。

明示的に検証

その名が示すとおり、ゼロトラストの基本姿勢は「無条件に信頼せず、常に検証する」ことです。したがって、システム内のあらゆるアクター、つまりシステム上のやり取りにおける「誰が」と「誰に」は、以下を実行できなければなりません。

  1. システムが、航空会社の予約システムにおける匿名ブラウザーのように、匿名IDを送信元または宛先とするやり取りを許可する場合は、「匿名」IDという特殊なケースも含め、自身のIDを証明できること。それ以外のすべてのIDについて、アクターは、システムが受け入れる名前空間で、自身が誰であるかを示せる必要があります。
  2. アクターが表明したアイデンティティについて、補足的な「証明」を受け取り、検証します（匿名ではないアイデンティティが表明された場合）。「証明」の性質（パスワード、証明書、行動など）やその強度はさまざまですが、システムは、その表明に対する一定の信頼度を判定できなければなりません。単純なシステムでは、証明の信頼度を「はい／いいえ」の二値で判断する場合があります。一方、より高度なシステムでは、リスクとリターンに基づくポリシーの一部として明示的に参照できる数値の信頼度スコアを使用する場合があります。また、システムは、能動的なチャレンジへの応答や、アクターの行動の受動的な観察など、ほかの手段によって信頼度を高めたり低めたりすることもあります。
  3. 過去の行動との比較に基づいて現在の行動に関するコンテキスト情報を追加し、証明されたアイデンティティに対する信頼度を評価、調整します。たとえば、アイデンティティの「証拠」に対する信頼度を高めたり低めたりするために、システムはアクターの過去および現在の位置情報、ハードウェアプラットフォーム、IPアドレス、レピュテーションなど、アクターに関する履歴メタデータを保持する場合があります。

さらに、「明示的に検証する」という原則は、アイデンティティだけでなく、トランザクションの「What（何を行うか）」に当たるアクションにも適用できます。一般的なユースケースとして、データベースクエリを実行するAPIなど、アクションがAPI呼び出しとして表される場合があります。この例では、「明示的に検証する」という原則を使用して、APIを呼び出すアクターのアイデンティティに対する信頼度を確保するだけでなく、APIに渡されたパラメーターが適切な制約に準拠していることを確認するなど、APIアクションが正しく使用されているかどうかも検証できます。

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

最小権限

トランザクションに参加するアクターについて許容可能なレベルの「信頼度」が確立されると、ゼロトラストのアプローチでは、そのアクター（通常はリクエスト元、すなわち「誰が」）に対し、そのシステムで意図された処理を実行するために必要な最小限の権限のみを付与することが求められます。この原則は「ポジティブセキュリティモデル」とも呼ばれる考え方を具体化したものです。このアプローチでは、デフォルトですべての操作を許可せず、システムの運用に必要な場合に限って特定の権限を付与します。たとえば、予約システムでは匿名ユーザーにフライトスケジュールの閲覧を許可しても、アプリケーションの設計要件に従い、フライトの予約は許可しない場合があります。

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

最小権限を実装するうえで重要なのは、事前に十分検討し、状況に応じてよりきめ細かく適用することです。7  具体的には、すべてのアクターまたは特定のアクタークラスに一律の権限セットを適用するのではなく、成熟したゼロトラスト実装では、試行されているアクションが 何か をより細かく把握する必要があります。たとえば、非常に大まかな粒度では「ファイルシステムへのアクセス」という権限を付与できますが、「ファイルシステムの読み取り」とすれば、実際に必要な権限をより厳密に指定でき、ポジティブセキュリティモデルを高い精度で実装できます。

最後に、最小権限をより高度に実装する場合、アクターに付与される権限を絶対的なものではなく、認証によって得られた信頼度に基づくものと捉えることで、成熟した「明示的な検証」の実装と連携できます。したがって、証明されたアイデンティティ（誰）の信頼度が最低しきい値を満たす場合にのみ権限が付与されます。このしきい値は、試行されるアクションごとに設定されます。たとえば、システムのシャットダウンなど、特に影響の大きいアクションでは、アクターが管理者であるという信頼度が90%以上であることが求められる場合があります。この例で、シャットダウンが試行された時点でシステムによるアイデンティティの信頼度が80%にとどまる場合、システムはそのアクションを許可する前に追加の検証を要求し、証明されたアイデンティティの信頼度スコアを引き上げます。

継続的に評価

明示的な検証と最小権限は重要な概念です。しかし、「継続的な評価」の原則は、次のような観点から、これらの原則を継続的に評価する必要があることを示しています。

  1. すべてのトランザクションを検証し、権限を確認する必要があります。つまり、「ユーザーセッションの最初のトランザクション」や「Dockerコンテナのワークロードを介して開始されたトランザクション」など、一部のトランザクションだけを検査対象としてはなりません。これは自明に思えるかもしれませんが、設計上の不備や可視性の欠如により、すべてのトランザクションを検証していないゼロトラスト実装は少なくありません。この領域でよく見られる問題は、ゼロトラストを外部のアクターにのみ適用し、内部のアクターには適用していないこと、またはゼロトラストによる判定が長期間にわたって有効であり続けると想定していること、あるいはその両方に起因します。
  2. 評価における主要な要素、すなわちアクターのアイデンティティに対する信頼度と、そのアクターに許可される権限は、動的であり、変化し得るものとして捉える必要があります。たとえば、アイデンティティに対する信頼度は、観測された振る舞いやサイドバンドメタデータに基づいて時間の経過とともに増減する可能性があるため、信頼度に基づくポリシーも、信頼度の変化に応じて動的に調整する必要があります。また、以前にポリシーによって付与された権限のしきい値が後に取り消されたり、特定のアクションに必要な最低信頼度が変更されたりする場合もあります。ポリシー変更の時間尺度は、人による運用プロセスに応じて緩やかに変化する場合もあれば、自動化されたガバナンスエージェントによって迅速に変化する場合もありますが、システムはこうした変更に動的に対応し、適用できる必要があります。
侵害を前提とする

最後の原則は、健全な警戒心を背景に、攻撃者は非常に強い動機を持っているという想定に基づいています。具体的には、「すでに侵害されていると想定する」ことが前提です。ここで「侵害」とは、「完全な知識と実行能力があれば拒否すべきだったにもかかわらず、許可されたトランザクション」と定義されます。この見逃しの根本原因としては、知識が不完全であること（例：不正な認証情報を検出できず、認証で誤って高い信頼度スコアが付与される）、実装上の制約（例：「ネットワーク接続を開く」という権限はあるものの、接続先ネットワークの地理的位置に基づいて区別できないなど、付与する権限を十分に細かく指定できない）、ゼロトラストの実装が不完全であること（例：社内で使用する脆弱なオープンソースコンポーネントにゼロトラストを適用していない）などが考えられます。

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

この原則の実装方法は、他の原則よりも多岐にわたりますが、一般的には次のような形で現れます。

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

ポリシーベースの調整を採用する場合は、利用可能な静的ポリシーツールを使用して調整を適用できます。ポリシーベースの調整の例としては、トランザクション単位のアクセス制御権限を制限する（つまり、誰が何を誰に行うことを許可するかを制限する）方法や、特定のアクター（またはアクターのクラス）が特定のアクションを実行する際の「証明基準」をより厳格にする（つまり、MFAまたはより高い信頼度スコアを要求する）方法があります。

一方、追加の「バックストップ」レイヤーを使用するアプローチを選択した場合、この戦略はきめ細かく実装することも、大まかに実装することもできます。最もきめ細かな戦略は、特定のリスク対リターン比を上回るトランザクションだけを正確にブロックすることです。ただし、実装時に追加の分析が必要となる場合、この方法によって許可対象の一部のトランザクションに許容できないレベルの遅延が生じる可能性もあります。代わりに、該当するアクターによる今後のトランザクションをサンドボックス化したり、そのアクターによるシステムの利用を全面的に禁止したりするなど、より大まかな戦略も使用できます。極端なケースでは、ファイルI/Oの停止など、さらに大まかな緩和策が適切な場合もあります。

もちろん、ほかの条件が同じであれば、一般に、よりきめ細かなバックストップ緩和策が望まれます。しかし、利用可能なソリューション技術の制約に応じてトレードオフが必要になることも多く、通常は、粗粒度のバックストップでも、何も設けないよりは有効です。たとえば、ランサムウェアの疑いがある動作を防ぐための粗粒度の対応としてファイルI/Oを無効にする場合、何も対処しなければファイルシステムがランサムウェアによって暗号化されると想定されるのであれば、その対応による副作用が生じても、アクターがシステム内で野放しに動作し続けるよりは望ましい可能性があります。

ゼロトラスト：実際には運用開始前から始まる

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

これらの基礎要素の中核では、システムの動作間で望まれる、または意図される相互作用を捉えるとともに、逸脱を検知して対処するための十分な可視性と制御を確保する必要があります。意図される相互作用に基づき、各主体（何をするか）が各対象（誰が）に対して実行する一連の望ましいアクション（誰に）を定義します。ただし、シナリオや環境によっては、意図される相互作用のパターンが不明な場合もあります。その場合、組織は可視性をさらに高めることで、適切な一連の相互作用を「発見」し、8 それをポリシーとして体系化できます。

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

以下に、設計プロセスに組み込むべき基本的な検討事項を大きなカテゴリー別に示します。さらに、各要点について検討すべき具体的な質問も掘り下げて提示します。

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

これらの質問を明確に投げかけることで、ゼロトラストを実現するための基盤にどのようなギャップがあるかを把握しやすくなります。多くの場合、設計の早い段階で質問するだけでも、追加の設計作業を最小限に抑えながらギャップを解消できます。また、ギャップが残る可能性がある場合でも、それを認識することで、セキュリティ対策をさらに強化すべき箇所を判断したり、脅威にさらされやすい領域を特定したりできます。

このようなセキュア開発分析を事前に行うことは、ゼロトラストの考え方において極めて重要です。しかし、現在のゼロトラストでは、初期設計の後に起こることに多くの関心が向けられており、ほとんどの企業も、ゼロトラストにおける設計後の側面を主に重視しています。一方、設計段階でゼロトラストを効果的に実装するための要件を慎重に検討しておけば、アプリケーションのデプロイ後に「穴をふさぐ」ために必要となる、はるかに大規模な追加作業を回避できます。

緩和策の考慮事項：適時性、偽陽性／偽陰性、リスク

この考え方の前提である「侵害を前提とする」が示すように、セキュリティ担当者は、十分な動機を持つ攻撃者が悪意のあるトランザクションを実行し得ると想定する必要があります。これは、「誰が誰に何をするか」という観点ではポリシールールを満たしていても、理想的には許可されるべきではなかったトランザクションです。このような場合は、前述の「侵害を前提とする」セクションで説明したように、通常はトランザクションのパターンやシステムへの副作用を観察し、該当するケースを検出できる効果的な「最後の砦」となる仕組みに重点を移します。

しかし、アイデンティティの概念と同様に、特定のトランザクションが悪意のあるものかどうかを完全に把握することはできません。そのため、理想的なゼロトラストソリューションでは、アイデンティティの場合と同じく、トランザクションの正当性に関する「信頼度」スコアを提示する必要があります。たとえば、デーモンによるファイルの読み書きが通常の10倍の頻度で10秒間続いた場合、悪意があることの信頼度は70%となる可能性があります。一方、その頻度が100倍に増え、1分間継続した場合、信頼度は95%に上昇する可能性があります。この例では、以後のファイル書き込みを抑止するという修復措置を講じても、それが誤った対応、すなわち「誤検知」である可能性が依然として30%または5%残ります。したがって、修復措置を講じるかどうかを判断する際は、誤検知のリスクと、悪意がある可能性のある動作を許可することで生じ得る影響を比較検討する必要があります。

この例が示しているのは、ユーザーが認識できる是正措置を講じるかどうかの判断は、実際には、不審なアクティビティに伴うあらゆるリスク、コスト、利益を考慮したビジネス上の判断であるという点です。トランザクションに追加の障壁を設けると、期待する価値を得られない可能性が高まります。一方、介入せず、障壁も追加しなければ、侵害のリスクが生じます。したがって、このような場合に措置を講じるかどうかは、次の3つの要素によって決まります。

  1. 悪意がある可能性のあるトランザクションの継続を許可することには、どのようなリスクがあるでしょうか？
    このリスクには、銀行資金の送金などの直接的な金銭的損失のほか、重要な記録が暗号化され、身代金を要求されるといった運用上の間接コストや、Webサイトの改ざんなどによるブランド上の間接コストが考えられます。また、顧客の個人データの漏えいなどにより、法的コストやコンプライアンス上のコストが発生する可能性もあります。つまり、リスクの評価はガバナンス上の課題であり、適切なガバナンスには、アプリケーションに関するリスクを把握し、定量化することが求められます。
  2. 是正措置を講じることで、どのような副作用が生じるでしょうか？
    副作用は、（a）生じるフリクションと（b）影響範囲という2つの観点で表すことができます。フリクションとは、正当なトランザクションの実行がどの程度困難になるかを指します。多少不便になる場合（例：認証手順が1段階増える）から、実行できなくなる場合（トランザクション自体が許可されない）まであります。影響範囲とは、ほかの独立したトランザクションにも影響が及ぶかどうか、また及ぶ場合はその数を指します。たとえば、特定のユーザーをブロックした場合、影響を受けるのはそのユーザーだけですが、ログ記録サービスを停止すると、すべてのユーザーとトランザクションの監査可能性に影響します。
  3. そのトランザクションが悪意のあるものだという判断の確度はどの程度でしょうか？
    確度を高めるには通常、より多くのデータポイントを収集し、より多くのデータソース間で相関分析を行う必要があります。どちらにも時間がかかるため、実際には多くの場合、「対応を決定するまで、どのくらい監視を続けるべきか」というトレードオフになります。

したがって、ゼロトラスト戦略では侵害が発生するという事実を受け入れる必要がありますが、許可されているものの疑わしいトランザクションへの対処については、リスクと利益を比較衡量する慎重なアプローチが求められます。この比較衡量では、アプリケーションの各種トランザクションのリスクレベルと、対処を実施した場合の影響を考慮し、リスクレベルが期待されるビジネス上の利益を上回る場合にのみ対処を実施します。

1 https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
2 https://csrc.nist.gov/publications/detail/sp/800-207/final
3 https://www.cisa.gov/zero-trust-maturity-model
4 https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF
5 https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf
6 https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf
7 この事前検討は、後述するように設計段階から始まります。
8 少なくとも、システムに必要と思われる一連の「適切と考えられる」インタラクションを指します。観察から導き出されたインタラクションの集合には、漏れがある可能性や、既存のリスクが含まれている可能性が常にあります。そのため、設計段階で事前に検討することが常に望まれます。

公開日：2022年5月4日

F5とつながる

実行環境を問わず、あらゆるアプリケーションとAPIを提供し、保護します
F5は、現代のデジタルビジネスが運用される複雑な環境全体で、アプリケーションとAPIの高速性、可用性、セキュリティを維持します。F5 Application Delivery and Security Platformの詳細はこちらをご覧ください。
F5とつながる