Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
「ゼロトラスト」という言葉は、いまや多くのセキュリティ製品の枕詞として使われています。しかし実装の現場では、「VPNを廃止してZTNAを導入しただけ」で取り組みが止まっていたり、「責任共有モデルは理解しているが、自社の責任範囲を具体的なコントロールへ落とし込めていない」といったケースも少なくありません。
責任共有モデルが「どこからが利用者の責任か」という守るべき領域を定義するのに対し、ゼロトラストはその自社責任の領域を「どう守るか」を定義する設計原則です。つまりゼロトラストは、特定の製品名ではなく、クラウド環境における責任範囲を具体的な防御策へ変換するための考え方です。
クラウドセキュリティの成否は、この2つを設計段階で具体的なコントロールへ翻訳できるかどうかに大きく左右されます。
本記事は、クラウドセキュリティアーキテクチャを設計するセキュリティアーキテクトやCISO、IAMやネットワーク設計を担うSRE・プラットフォームエンジニアを主な読者としています。
具体的には、NIST SP 800-207が定義するゼロトラストの原則を出発点として、責任共有モデルにおけるIaaS・PaaS・SaaS・コンテナの責任境界、最小権限とCIEM、マイクロセグメンテーション、さらに「設計した権限が実際にどのように利用されているか」をランタイムで検証する考え方までを解説します。本番環境へ展開する前に押さえるべき実践的な指針として整理していきます。
1. 責任共有モデルの再確認 — 「自社の責任範囲」を正確に引く
まずは、「クラウドセキュリティとは？責任共有モデル」で扱った責任共有モデルを、サービス形態別の境界という解像度で捉え直します。
1-1. 基礎からの接続 — 本記事が扱う範囲
責任共有モデルの基本、すなわちクラウド事業者が物理層・仮想化基盤を担い、利用者がOS・アプリケーション・構成・データ・アクセス権限を担うという線引きは、基礎記事「クラウドセキュリティとは？責任共有モデル」で解説しています。
本記事ではその前提を踏まえ、「自社責任の範囲を、サービス形態ごとにどこまで具体化すべきか」「ゼロトラストという原則を、どのように実装コントロールへ翻訳するか」という、実装前の設計レベルに踏み込みます。
1-2. IaaS／PaaS／SaaS／コンテナで変わる責任境界
責任の境界は、「クラウドを使っている」という一語では決まりません。利用するサービス形態によって、利用者が守るべき層は変わります。同じAWSでも、EC2（IaaS）、Lambda（PaaS）、Kubernetes（EKS）では、利用者が担う責任範囲が異なります。
注目すべきは、どのサービス形態でも「構成・IAM・ネットワーク・データ」は一貫して利用者責任に残る点です。マネージド度が上がるほどOSやランタイムの管理は事業者へ移りますが、「誰が何にアクセスできるか」「データをどう守るか」は、基本的に利用者側の責任として残ります。
ゼロトラストがアイデンティティを中心に据えるのは、このためです。利用者責任として残るIAM・ネットワーク・データ保護を、どのような設計思想で統制するのか。その答えがゼロトラストです。
1-3. 「設定は利用者責任」がもたらす構成リスク
責任境界がどう動いても、構成設定は多くの場合、利用者側に残ります。つまり、責任共有モデルを正しく理解することは、「構成ミスは事業者ではなく自社が防ぐ必要がある」という認識に直結します。
この構成リスクを継続検知する仕組みがCSPMであり、コード段階で予防する仕組みがIaCセキュリティです。CSPMの全体像は「CSPMとは？クラウド構成ミスを未然に防ぐSecurity Posture Managementの全体像」で、コード段階の予防は「IaCセキュリティとPolicy as Codeとは？コード段階で構成ミスを防ぐ実装ガイド」で扱っています。
本記事では、その前提となる概念としてのゼロトラストを掘り下げます。
2. ゼロトラストとは何か — 原則であって製品ではない
ゼロトラストとは何か。NISTの定義に立ち返って整理し、よくある誤解を解いていきます。
2-1. NIST SP 800-207が示すゼロトラストの考え方
ゼロトラストは、米NISTがSP 800-207（Zero Trust Architecture）で体系化した設計原則です。中核にあるのは、「ネットワークの内側だから信頼する」という暗黙の前提を捨て、すべてのアクセス要求を都度検証するという考え方です。
NISTは7つの基本理念（tenets）を提示していますが、本記事では実装設計の観点から、次の3つに整理して解説します。
- 明示的に検証する（Verify Explicitly）：すべてのアクセスを、ID・デバイス・コンテキスト（場所・時刻・ふるまい）に基づいて毎回検証する。一度認証したら信頼し続ける、という前提をやめる。
- 最小権限（Least Privilege）：必要最小限の権限を、必要な時間だけ付与する。恒久的な広域権限を排除する。
- 侵害を前提とする（Assume Breach）：すでに侵入されている前提で、爆発半径を最小化する。マイクロセグメンテーションと継続監視により横展開を封じる。
2-2. 「境界防御」からの脱却とアイデンティティ中心設計
従来の境界防御（ペリメタモデル）は、「社内ネットワーク＝信頼、社外＝非信頼」という前提で、ファイアウォールに守りを集中させる考え方でした。しかし、クラウド・リモートワーク・SaaSの普及により、「社内／社外」という境界そのものが曖昧になり、この前提は崩れています。
ゼロトラストでは、信頼の単位がネットワーク境界からアイデンティティ（ID）へ移ります。「どこからアクセスしているか」ではなく、「誰が・何の権限で・どのコンテキストでアクセスしているか」が制御の基軸になります。
これがアイデンティティ中心設計（Identity-First Security）であり、クラウドにおけるIAM／CIEMの重要性が高まっている背景です。
2-3. よくある誤解 — 「ゼロトラスト製品を入れれば完成」ではない
ゼロトラストをめぐる最大の誤解は、「特定の製品を導入すれば達成できる」というものです。ZTNA（Zero Trust Network Access）製品やIDプロバイダは重要な構成要素ですが、それ単体でゼロトラストが完成するわけではありません。
ゼロトラストは、IAM・ネットワーク・ワークロード・データ・監視といった複数レイヤにまたがる設計原則です。「明示的検証・最小権限・侵害前提」を各レイヤのコントロールへ落とし込む継続的な取り組みだと捉える必要があります。
出発点になるのは、「自社のどのレイヤに、どの原則を、どのコントロールで適用するか」を設計段階でマッピングすることです。
3. クラウドにおけるゼロトラストの実装
ゼロトラスト原則を、実際のクラウドコントロールへどう翻訳するか。鍵になるのは、アイデンティティ、ネットワーク、ワークロード、データの4つのレイヤです。
3-1. アイデンティティ（IAM・MFA・条件付きアクセス）
最も基盤となるのがIDレイヤです。ここで実装すべき主なコントロールは次のとおりです。
- 強力な認証：MFAの全面適用、FIDO2準拠の認証（パスキー等）、ルートアカウントのMFA必須化。
- 条件付きアクセス：デバイス姿勢・場所・リスクスコアに基づく動的なアクセス可否判定。
- 一時的権限：恒久キーを排し、STS／OIDCフェデレーション／Workload Identityによる短命クレデンシャルへ移行。
クラウドでは、人間のユーザーだけでなく、サービスアカウント・ロール・ワークロードIDが急速に増えます。これらすべてが「検証対象のアイデンティティ」です。人間以外のID（Non-Human Identity）の管理は、ゼロトラスト実装における大きな難所になります。
3-2. ネットワーク（マイクロセグメンテーション・ZTNA）
ネットワークレイヤでは、「侵害を前提に横展開を封じる」原則を実装します。
- マイクロセグメンテーション：ワークロード単位で通信を最小化し、侵害が起きても隣のワークロードへ広がらないようにする。KubernetesではNetworkPolicy、クラウドではセキュリティグループやサービスメッシュで実現する。
- ZTNA：VPNの「接続したら内部ネットワーク全体にアクセスできる」モデルを廃し、アプリケーション単位でアクセスを仲介する。
- デフォルト拒否：通信は明示的に許可したものだけを通す。Kubernetesでは一般に、NetworkPolicyを定義しない限り通信が許可されるため、default-denyを最初に敷くことが重要になる。ただし、挙動はCNI実装やingress／egressの指定により異なる。
3-3. ワークロード（最小権限・実行時検証）
ワークロードレイヤでは、コンテナ・関数・VMが「許可された振る舞いだけを行う」状態を設計します。
- 最小権限のワークロードID：Podや関数に紐づくロールの権限を、実際に必要なAPIだけに絞る。
- イミュータブルなワークロード：本番コンテナでのshell起動・パッケージ追加・ファイル書き換えを禁止し、想定外の挙動を異常として扱える状態にする。
- 実行時検証：設計上の最小権限が本番で守られているかを、ランタイムで継続検証する。
3-4. データ（暗号化・分類・アクセス監査）
データレイヤでは、「アクセスできる状態か」だけでなく、「実際にアクセスされたか」を統制します。保存時・転送時の暗号化、データ分類に基づくアクセス制御、アクセスの監査ログ化が基本コントロールです。
ゼロトラストの「明示的検証」は、データアクセスのログとふるまい分析にまで適用されて初めて実効性を持ちます。
4. 最小権限とCIEM — 「付与した権限」と「実際に使う権限」のギャップを埋める
4つのレイヤのなかでも、クラウド環境で最も運用負荷が高く、ゼロトラスト実装の成否を左右するのが、アイデンティティと権限管理です。そこで本章では、ゼロトラストの中核である最小権限を、クラウド権限管理（CIEM）の視点で掘り下げます。
なお最小権限は、IAM設計、RBAC／ABAC、JIT（一時的権限）、PAM、CIEMといった複数の仕組みの組み合わせで実現されます。CIEMはそのなかでも、規模が増すほど手作業では破綻しやすい「実効権限の可視化と最小権限化」を支える重要な運用技術です。
4-1. 過剰権限はなぜ生まれるのか（権限クリープ）
最小権限は原則としては単純ですが、実装は困難です。理由は「権限クリープ（Privilege Creep）」、つまり権限は時間とともに増える一方で、削減されにくいからです。
- 開発・検証時に付与した広域権限が、そのまま本番運用に残る。
- 「とりあえず動かす」ために * を含むポリシーを付け、後で絞り込まれない。
- 退職者・廃止サービスのロールやキーが残置される。
- ロール継承・ポリシー合成の結果、実効権限が把握困難になる。
クラウドでは、数千〜数万のIDとロールが存在することも珍しくありません。それぞれの「実効権限」は、複数ポリシーの合成、継承、リソースベースポリシーの相互作用で決まります。規模が大きくなるほど、手作業で最小権限を維持することは難しくなります。
4-2. CIEM（Cloud Infrastructure Entitlement Management）の役割
CIEMは、この「権限の設計と実態のギャップ」を埋めるためのカテゴリです。クラウド上のID・ロール・権限を可視化し、過剰権限・未使用権限・到達可能性を分析して、最小権限化を支援します。
現在のCNAPPでは、CIEMがCSPM／CWPPと並ぶ主要構成要素として統合されることが一般的です。ゼロトラストの「最小権限」原則を運用へ落とし込む実装層として、CIEMは重要な役割を担います。CNAPP全体での位置づけは「CNAPPとは何か？」を参照してください。
4-3. 「付与された権限」と「実際に使われた権限」の差分
CIEMは、IAMポリシーなどの構成情報だけでも、実効権限の可視化、未使用権限の検出、権限昇格パスの分析といった多くのリスクを明らかにできます。
そのうえで、最小権限化を実使用ベースで一段進める鍵になるのが、「付与された権限」と「実際に使われた権限」の差分を取ることです。あるロールに100の権限が付与されていても、本番で実際に呼ばれているAPIが5つだけなら、残り95は削減候補になります。
この「実使用」の情報は、構成情報だけからは得られません。ランタイムでのAPI呼び出しを観測する必要があります。
設計時の最小権限を、ランタイムの実使用データで継続的に磨き込む。この往復が、権限クリープに抗う現実的な方法の一つです。ランタイム観測の仕組みは「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」に集約しています。
では、この設計と実使用データの循環を、組織の運用としてどう定着させるのか。続いて、その実践を見ていきます。
5. ゼロトラストを「運用」に乗せるために
設計したゼロトラストを運用に乗せるには、段階的な適用と継続的な検証が欠かせません。
5-1. 一気に全適用しない — 重要資産から段階適用する
ゼロトラストを全システムへ一斉適用しようとすると、業務影響と工数が膨大になり、取り組みが頓挫しやすくなります。現実的なのは、保護価値の高い資産から段階的に適用する進め方です。たとえば、機密データ、本番クリティカルパス、特権アクセスなどを優先対象にします。
- 資産とフローの可視化：何を守るか、誰がどこにアクセスしているかを棚卸しをする。
- 重要資産への適用：最小権限・MFA・マイクロセグメンテーションを優先資産から実装する。
- 継続検証への移行：適用したコントロールが本番で機能しているかをランタイムで監視し、逸脱を検知する。
5-2. 設計した最小権限が「実際に守られているか」を検証する
ゼロトラストの設計は、本番で守られていなければ意味を持ちません。「最小権限ポリシーを書いた」ことと、「本番でそれが守られている」ことは別問題です。設計と実態の乖離は、緊急対応時の手動変更、ドリフト、例外設定の恒久化などから常に生じます。
そこで必要になるのが、設計したコントロールの「実行時検証」です。
たとえば、最小権限のはずのロールが普段と異なるAPIを叩き始めた、default-denyのはずのPodが外部通信を開始した、イミュータブルなはずのコンテナでshellが起動した。こうした「設計からの逸脱」をランタイムで捉えることで、ゼロトラストは静的な設計図から動的な防御線になります。
ただし、ランタイム検証は設計そのものを置き換えるものではありません。あくまで、設計どおりに運用されているかを確認する補完手段です。堅牢な設計があってはじめて、ランタイム検証は「逸脱」を意味あるかたちで検知できます。
5-3. ランタイムでのID相関と振る舞い分析
ゼロトラストの「明示的検証」と「侵害前提」を運用で実現するうえで重要になるのが、ランタイムでのID相関と振る舞い分析です。
実際に使われた認証情報、操作履歴、プロセス、通信を関連付けて分析することで、「正規の権限を使った不正」を検知できます。たとえば、漏洩したキーによる正規API呼び出しのように、構成検査だけでは見抜きにくい攻撃も対象になります。
この領域はCDR（Cloud Detection and Response）が担います。検知後の対応フローを含めた全体像は「CDRとは｜クラウドを守るリアルタイム防御とSysdigのアプローチ」を、ランタイム検知の技術詳細は「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」を参照してください。
では、ここまで述べてきた設計・権限管理・ランタイム検証を統合的に実現する仕組みとして、Sysdigのアプローチを見てみましょう。
6. Sysdigによるゼロトラスト実装
ここからは、これまで述べてきた設計原則を具体的な機能として実装する例として、Sysdigがゼロトラストの各レイヤをどのように支援するかを概観します。
6-1. CIEMによる権限可視化と最小権限化
Sysdig SecureのCIEMは、AWS／Azure／GCPのID・ロール・権限を可視化し、合成・継承後の実効権限を分析します。90日以上未使用の権限やアクセスキー、過剰な iam:PassRole、権限昇格パスなどを検出し、実使用に基づく最小権限ポリシーの検討を支援します。
これにより、「付与された権限」を「実際に必要な権限」へ継続的に近づける運用が可能になります。マルチクラウドの権限リスクを共通の観点で管理できる点も、基礎記事で触れたマルチクラウドのセキュリティギャップに対する有効なアプローチです。
6-2. Runtime Identity Correlationによる実行時検証
Sysdigの特徴の一つは、設計した権限・ネットワーク・ワークロードの制御が本番で守られているかを、FalcoをベースにしたeBPF／Syscallレベルの観測で継続的に検証できる点にあります。
実際に使われた認証情報と操作履歴を関連付けるRuntime Identity Correlationにより、漏洩クレデンシャルを使った正規権限内の不正や、設計からの逸脱を検知しやすくなります。
これは、ゼロトラストの「明示的検証」「侵害前提」を、静的な設計だけでなく動的な運用として成立させるための仕組みです。検知の技術的な仕組みとノイズ削減の考え方は「コンテナランタイムセキュリティとは？」に集約しています。
6-3. 設計と運用のギャップを継続検出する
ここまでCIEMとRuntime Identity Correlationを中心に述べてきましたが、Sysdigの価値は単一レイヤの機能だけではなく、複数レイヤを横断して相関できる点にあります。
Sysdig Secureは、IaC・CSPM（設計・構成）、CIEM（権限）、CDR／ランタイム検知（実態）といった、ゼロトラストの各レイヤを支える機能を同一のCNAPPプラットフォーム上で相関させます。
これにより、「コードに書いたゼロトラスト設計」と「本番で実際に起きていること」のギャップ、すなわちドリフト・権限クリープ・設計逸脱を継続的に可視化できます。
ゼロトラストを「導入して終わり」にせず、設計と運用の往復で磨き続けることが、Sysdigが支援する実装像です。
7. まとめ — ゼロトラストは設計し、ランタイムで検証し続ける
本記事で見てきたように、責任共有モデルは「守るべき領域」を定義します。一方でゼロトラストは、その領域を「どう守るか」を定義する設計原則です。
構成・IAM・ネットワーク・データは、サービス形態を問わず利用者責任として残ります。ゼロトラストはこれらを、「明示的検証・最小権限・侵害前提」という原則で統制するための考え方です。特定の製品を導入すれば完成するものではありません。
実装は、アイデンティティ・ネットワーク・ワークロード・データの各レイヤに原則を翻訳することから始まります。とりわけ最小権限は、権限クリープという構造的な力に抗う必要があり、CIEMによる「付与された権限」と「実際に使われた権限」の差分管理が鍵になります。
そして、設計したコントロールは、本番で守られているかをランタイムで継続検証して初めて、静的な設計図から動的な防御線へと変わります。
Plan段階で重要なのは、ゼロトラストを抽象的なスローガンで終わらせず、各レイヤの具体的コントロールへマッピングし、重要資産から段階適用し、実態をランタイムで検証する前提を最初から組み込むことです。
設計と運用の往復こそが、ゼロトラストを実効的な防御として機能させます。
次のステップ
CIEMによる過剰権限の可視化と、Runtime Identity Correlationによる実行時検証をデモで確認してください。デモのお申し込みを受け付けています。