【要点抽出】Zero Trust Maturity Model
EO14028の第3条で命じられたゼロトラストアーキテクチャの採用に向けて、OMBやCISAからドキュメントが出ています。
今回はその中でもCISAのZero Trust Maturity Model(以下、ZTMM)を読みます。
何の本?
EO14028の第3条を受けてOMBがゼロトラストの実施要件を定めたM-22-09を発行しました。
あわせてCISAからゼロトラストの成熟度モデルが示され、段階的なレベルアップの指針が示された形です。
本書は2021年8月に初版が作られましたが、その後、2023年8月にRFCのフィードバックを反映した形で第2版が出ています。
構成は?
章立ては以下の通りです。
1~4.は前置きなので今回は割愛し、本noteでは5.のみ読んでいきます。
Introduction
Current Environment
What Is Zero Trust?
Challenges in Zero Trust Adoption
Zero Trust Maturity Model
5.1 Identity
5.2 Devices
5.3 Networks
5.4 Applications and Workloads
5.5 Data
5.6 Cross-Cutting CapabilitiesReferences
CISA Resources
本書の日本語訳
内容に入る前に、本書は二本松さんが日本語訳を書かれています。
今回の学習にあたり参考にさせて頂きました。
https://qualias.net/zero-trust-maturity-model-version2/
ゼロトラスト成熟度モデル
本書はOMB M-22-09のnoteで書いたゼロトラストを支える5本柱に沿って成熟度が定義されています。
各柱に4段階の成熟度が定められており、Traditional→Initial→Advanced→Optimalとレベルアップします。
レベルアップは柱ごとに別々に進めてよく、最終的にOptimalに近づくにつれてお互いが統合されるので、自然と低いところを引っ張り上げざるを得ない仕組みになっているようです。
なお、InitialはZTMMのVer2から加わったそうです。
加えて、5本柱に横串を通す形で「 可視化と分析」「自動化とオーケストレーション」「ガバナンス」という3つの横断機能が書かれています。
これらは5本柱をしっかり成長させると自然と実現される内容のように見えましたので、本noteでは割愛します。
本書には成熟度モデルのサマリ表があります。
しかし、私はサマリ表だけ見てもナルホドとはなりませんでした。
ですので、より詳述している5.1~5.6を読み込んで改めて自分の言葉でまとめてみました。一通りまとめた後で改めてサマリ表を見ると「同じこと言ってる」となるのですが、やはり中身が分からないとイメージが掴めないですね。
全体的に「何も管理・可視化できていない」から「網羅的に・自動的に・継続的に管理や可視化ができている、かつ、それらが連携してアクセス制御や脅威への対処に繋がる」へのステップアップを示していると感じました。
ここからは、5本柱の成熟度の詳細を見ていきます。
1.Identity
アイデンティティに関しては、以下4つの成熟度を測る観点があります。
(1)強力な認証を採用しているか(Authentication)
Traditional:パスワードまたはMFAを用いている
Initial:パスワードを用いたMFAを利用している
Advanced:フィッシング耐性のあるMFAを利用している(FIDO2、PIVなど)
Optimal:フィッシング耐性のあるMFAを利用して継続的にアイデンティティを検証する
#例えば1分間非アクティブなら再認証、など細かい認証要求のイメージと理解
(2)アイデンティティ管理の仕組みを組織全体で統合しているか(Identity Stores)
Traditional:オンプレのID管理の仕組みのみである
#オンプレだからダメというよりも、限定的な範囲のIDのみ管理してるイメージと思われるInitial:オンプレと外部(クラウドなど)のID管理の仕組みを使っているが、SSOなどの統合は最小限のみ
Advanced:Initialの成熟度に比べて、SSOなどを用いた統合が進んだ状態
Optimal:全ての環境や登場人物について、完全にSSOなどを用いた統合が完了
(3)なりすましなどのアイデンティティリスクに対して確認しているか(Risk Assessments)
Traditional:「限定的な判断」しかしていない
Initial:なりすましなどのアイデンティティリスクに対して手作業による分析や静的なルールを使って監視
Advanced:いくつかの自動分析や動的ルールを使って監視
Optimal:自動分析と動的ルールを使って継続的に監視し、リアルタイムな判断につなげる
(4)きめ細やかな認可制御を行っているか(Access Management)
Traditional:特権・非特権アカウントともに、永続的なアクセスを認めており、見直すタイミングは定期レビュー程度である
Initial:特権アクセスを含め、自動で期限切れとなる仕組みでアクセス可能な期間を制御している
Advanced:アクセスの必要性やセッションの単位で、求めるアクションやリソースごとに認可制御を行う
Optimal:Advancedの成熟度に比べて、より細かい認可の粒度(アクセスの都度のチェックなど)を自動化により実現
#Advancedとの違いはあまり読み取れず
2.Devices
デバイスとは、各省庁が保有する機器のみならず、関係者が持ち込むBYODも含みます。また、オンプレのIT機器に加えて、クラウド移行後に扱う仮想リソース(コンテナやストレージ、仮想NW、AIモデルなど)も含みます。
以下4つの成熟度を測る観点があります。
(1)脆弱性管理と連携してデバイスのコンプライアンス準拠状況を評価しているか(Policy Enforcement & Compliance Monitoring)
Traditional:コンプライアンス準拠評価は限定的。アクセス制御との連携や脆弱性管理はできていない
Initial:デバイスの自己申告による特性情報は受け取るが、アクセス制御との連携は限定的
Advanced:ほとんどのデバイスに対してコンプライアンス準拠評価を行う。リソースへの初回アクセス時のみデバイスの状態を考慮する
Optimal:デバイスに対して継続的にコンプライアンス準拠評価を行い、脆弱性管理と統合する
#コンプライアンス=対象機器が組織が認める状態(パッチレベル、バージョン、設定等)にあるかの確認
(2)網羅的な資産の洗い出しを行いサプライチェーンリスクを管理しているか(Asset & Supply Chain Risk Management)
Traditional:組織全体で資産管理をしないまま、バラバラに新たなデバイスやサービスを取得している
Initial:全ての物理的なデバイスと一部の仮想デバイスを把握し、政府の勧告に従って管理ポリシーやベースラインを持つ
Advanced:組織全体のデバイスについての「包括的なエンタープライズビュー」の開発に取り組む
#あまりイメージがわかない。どのベンダから、どんな第三者評価を受けたデバイスを扱っているかを一目で見れる仕組み作りか?Optimal:全てのデバイスを(ほぼ)リアルタイムに把握し、サプライチェーンの障害に耐えられる仕組みを自動化する
(3)デバイスのリスクを分析し、リソースへのアクセス制御に役立てているか(Resource Access)
Traditional:リソースにアクセスするデバイスの情報は気にしない(基準がない)
Initial:一部のデバイスの特性をアクセス制御に役立てる
Advanced:リソースへの初回アクセスを制御する際にデバイスの情報を役立てる
Optimal:リソースへのアクセスを制御する際に、リアルタイムのデバイスの情報を役立てる
(4)脅威保護の仕組みを導入し、リソースへのアクセス制御やコンプライアンス監視と連携しているか(Device Threat Protection)
Traditional:一部のデバイスに脅威保護機能を手動で導入する
Initial:デバイスに対して自動的な仕組みで脅威保護機能を展開するが、アクセス制御やコンプライアンス監視との連携は限定的
Advanced:脅威保護機能とアクセス制御やコンプライアンス監視との連携するために「統合ソリューション」に各機能をまとめはじめる
Optimal:全てのデバイスに対して脅威保護、アクセス制御、コンプライアンス監視が連携できる「統合ソリューション」を利用している
3.Networks
以下4つの成熟度を測る観点があります。
(1)ネットワークセグメンテーションを細分化し、動的に管理しているか(Network Segmentation)
Traditional:ざっくりしたセグメンテーションしかしていない
Initial:重要なワークロードを分離する、サービス単位での相互接続を行うなど、セグメンテーションの細分化を開始する
Advanced:エンドポイントやアプリケーション単位の細かなセグメンテーションがNWのより広い範囲に適用される
Optimal:マイクロセグメンテーション・マイクロペリメータが全体に適用され、必要な時のみ・必要な範囲での接続が動的に提供される
(2)アプリケーションへの通信制御を動的に行っているか(Network Traffic Management)
Traditional:手動管理された静的ルールを用いて通信制御を行う。通信要件のレビューも手作業で行う
Initial:全てのアプリケーションに対し、静的ルールを用いて通信制御を行う。各アプリケーションの通信要件を「アプリケーション・プロファイル」で管理し、手動でプロファイルを定期監査する
Advanced:動的なルールを用いて通信制御を行う。ルールは、自動化されたアプリケーション・プロファイルにより、リスク認識や対応に応じて決められる
Optimal:継続的に変更される動的なルールを用いて通信制御を行う。ルールは、アプリケーション・プロファイルに加え、ミッションの重要性やリスクによって決められる
#アプリケーション・プロファイルが何か分からないが、アプリケーションごとのネットワーク要件集的なものと想像
(3)トラフィックを暗号化し、セキュアに鍵を管理しているか(Traffic Encryption)
Traditional:暗号化は最小限。暗号鍵は手動で適当に管理される
Initial:内部および外部アプリケーションの通信暗号化や鍵管理ポリシーの策定を開始する
Advanced:Initialの取り組みが全面的に完了。加えて「cryptographic agility」の組み込みを開始する
Optimal:鍵管理の際に最小特権の原則を実施し、「cryptographic agility」の組み込みが広がっている
#cryptographic agilityは、環境の大幅な変更などを伴わずに新たな暗号アルゴリズムに切り替えやすくする設計
(4)ネットワークにレジリエンスを組み込んでいるか(Network Resilience)
Traditional:個々のアプリケーションにあわせたバラバラのネットワーク設計。レジリエンスの仕組みは限定的
Initial:追加アプリケーションの可用性要件を管理し、レジリエンスの仕組みを拡張するために、ネットワーク機能の構成を開始する
Advanced:大半のアプリケーションの可用性要件とレジリエンスの仕組みを動的に管理する
Optimal:すべてのワークロードに対し、可用性要件の変化に対応できるレジリエンスの仕組みを提供する
#Initialはよく分からないが、要はレジリエンスを提供する範囲が徐々に広がると理解
4.Applications and Workloads
以下5つの成熟度を測る観点があります。
(1)アプリケーションへのアクセスを継続的・多面的に認可しているか(Application Access)
Traditional:静的な属性情報をもとに、アプリケーション内部で認可制御を行う
Initial:コンテキスト情報を用いた認可機能の実装を開始する
Advanced:より多くのコンテキスト情報と強制的な有効期限を用いて、アクセスを自動的に制御する
Optimal:リアルタイムに得た情報を用いて、継続的に認可制御を行う
#コンテキストとは、アクセス元の場所、時間、ユーザ属性などの「文脈」的な情報であり、ABACに用いられる属性の理解
(2)アプリケーションを狙った脅威から保護しているか(Application Threat Protections)
Traditional:既知の脅威に対する汎用的な保護。アプリケーションの処理に応じた監視(アプリケーションワークフローとの統合)は最小限。
Initial:重要なアプリケーションの処理内容と監視機能が連携し、既知の脅威に加えて一部のアプリケーション固有の脅威から保護する
Advanced:すべてのアプリケーションの処理内容と監視機能が連携し、一部のアプリケーション固有の脅威や標的型脅威から保護する
Optimal:高度な脅威防御を用いて、アプリケーションにあわせた高度な攻撃から保護する
#高度な脅威防御=「コンテンツ認識型の防御」らしいがイメージつかず
(3)アプリケーションをインターネットごしに利用可能か(Accessible Applications)
Traditional:重要なアプリケーションへのアクセスはVPNなどの閉域接続のみ
Initial:重要なアプリケーションの一部の機能をインターネットごしに利用できる
Advanced:重要なアプリケーションのほとんどをインターネットごしに利用できる
Optimal:すべてのアプリケーションをインターネットごしに利用できる
(4)アプリケーションの開発や展開をセキュアに行っているか(Secure Application Development and Deployment Workflow)
Traditional:堅牢でないコードデプロイの仕組みと、その場限りの開発、テスト、本番環境を持つ
Initial:CI/CDパイプラインによるコードデプロイの仕組みと、アクセス制御を行った開発、テスト、本番環境を持つ
Advanced:開発担当者が本番環境にアクセスできないよう権限分離している
Optimal:Immutableな技術を用いることで、デプロイ環境への管理者アクセスを削除する。また、コードデプロイを自動化する
(5)アプリケーションのセキュリティテストを行っているか(Application Security Testing)
Traditional:デプロイ前に手動テストを行う
Initial:デプロイ前に専門家による手動テストを含む、静的テストと動的テストを行う
Advanced:定期的な動的テストを開発・デプロイプロセスに組み込む
Optimal:ソフトウェアのライフサイクル全般にわたり、日常的に自動化したテストを行う
#Optimalだけ見ると手動診断は不要に見えるが、ツール診断だけでは見つけられない脆弱性があるので併用と理解
5.Data
以下5つの成熟度を測る観点があります。
(1)データのインベントリ管理を行い、データ流出防止に活用しているか(Data Inventory Management)
Traditional:手動によるデータインベントリの作成
Initial:自動によるデータインベントリの作成
Advanced:トラッキングにより自動で組織全体のデータインベントリを作る。静的なラベルに基づいたDLP戦略を採用する
Optimal:データインベントリを継続的に維持し、データ漏洩を動的にブロックする
(2)データを分類し、ラベリングしているか(Data Categorization)
Traditional:限定的、場当たり的なデータ分類を行う
Initial:ラベルを定義した上で、手動によるデータ分類を行う
Advanced:一部のデータの分類とラベリングを自動化する
Optimal:全てのデータの分類とラベリングを自動化する
(3)過去のデータを含め、データに高い可用性を確保しているか(Data Availability)
Traditional:データはオンプレ環境にあり、過去のデータはオフサイトバックアップに保存する
Initial:データはクラウドなどの高可用性の環境にあり、オンプレミスのデータも残存する
Advanced:ほとんどのデータがはクラウドなどの高可用性の環境にあり、過去のデータにもアクセス可能
Optimal:ユーザのニーズやデータの種類に応じて可用性を動的に最適化する
#普段はS3に保存するが、一定期間を過ぎた古いデータはS3 Glacierみたいなイメージか?
(4)データへのアクセス制御をきめ細かく行っているか(Data Access)
Traditional:静的なアクセス制御を行う
Initial:最小権限の原則にもとづいた自動的なアクセス制御に取り組む
Advanced:ユーザの情報以外にデバイスやデータの種類など様々な属性をもとに有効期限付きのアクセス権を与える
Optimal:継続的に、動的に必要最小限のアクセス権を与える
(5)データの暗号化とセキュアな鍵管理ができているか(Data Encryption)
Traditional:データの暗号化は最小限のみ。暗号鍵の管理は場当たり的である
Initial:全ての通信中のデータと一部の保管データを暗号化。安全に鍵管理を行うためのポリシーと仕組みを作り始める
Advanced:可能な限り全ての通信中のデータと保管データを暗号化。 cryptographic agilityを取り入れ始める
Optimal:使用中のデータを暗号化。 cryptographic agilityにより標準化された最新の暗号技術を用いる
おまけ
本書のサマリ表の日本語訳は二本松さんが既に作られていますが、5.1~5.6に定められる5本柱+3つの横断機能に対する詳細な成熟度の日本語訳を作りましたので置いておきます。
まとめは以上です。
2024年度末までのゼロトラスト移行は、2023年現在で間に合わないかもという話を聞きます。ZTMM v2.0からInitialが加わったのも、各省庁がいきなりゼロトラスト対応を求められて戸惑っている様子が反映されたのかな…と想像しました。
***はじめての方へ***
これは何のnoteだ?と思われた方はこちらをご覧ください。
これまでにまとめたガイドライン類の一覧はこちら