Forrester ZTXとは:ゼロトラストを実践する7つの領域と対策例
Section titled “Forrester ZTXとは:ゼロトラストを実践する7つの領域と対策例”ゼロトラストを実践するには、利用者の認証だけでなく、端末、ネットワーク、アプリケーション、データを含めた仕組みを考える必要があります。
Forrester ResearchのZero Trust eXtended(ZTX)Ecosystemは、ゼロトラストの考え方を、具体的な技術の選定・実装・運用に結び付けるためのフレームワークです。 セキュリティ対策を7つの主要領域に整理し、領域を連携させて重要な資源へのアクセスを制御します。
この記事は、添付資料の『The Forrester Wave™: Zero Trust eXtended Ecosystem Platform Providers, Q3 2020』(2020年9月24日)とForresterの公開解説を基に、ZTXの考え方を紹介します。対策例と導入手順は、理解を助けるために整理した実践例であり、レポートの逐語訳やForresterが定めた必須チェックリストではありません。2020年の製品評価を、現在の製品ランキングとして扱うこともありません。
ZTXは何のためのフレームワークか
Section titled “ZTXは何のためのフレームワークか”ゼロトラストでは、「社内ネットワークにいる」「一度ログインした」という理由だけで、その後のアクセスを無条件に信頼しません。アクセス対象、利用者の権限、端末の状態などを確認し、必要な範囲だけ許可します。
しかし、この考え方だけでは「どこから着手し、どの対策を組み合わせるか」が分かりにくい場合があります。ZTXは、実装に必要な領域を整理することで、次のような判断を助けます。
- 自社で保護すべきデータと、それを利用する人・端末・システムを把握する。
- 既存の対策を整理し、不足している機能や連携を見つける。
- 目的に合う製品やサービスを選ぶ。
- ログの分析結果をアクセス制御やインシデント対応につなげる。
- 事業やシステムの変化に合わせて、継続的に改善する。
ZTXは、特定の製品を購入すれば完成するものではありません。導入した製品が、共通の目的に向けて情報を共有し、実際の制御に結び付くことが重要です。
ゼロトラストを実装する7つの主要領域
Section titled “ゼロトラストを実装する7つの主要領域”以下の7つは、ZTXの主要な構成要素です。「7つの要件」と説明されることもありますが、ここでは実装・運用を考えるための領域として整理します。
| 領域 | 日本語での意味 | 主な確認事項 |
|---|---|---|
| Identity Security | 人・IDのセキュリティ | 誰がアクセスするのか。何を許可するのか |
| Device Security | 端末のセキュリティ | どの端末からアクセスするのか。安全な状態か |
| Network Security | ネットワークのセキュリティ | どの通信を許可するのか。侵害の拡大を防げるか |
| Workload/Application Security | ワークロード・アプリケーションのセキュリティ | どのシステムが動作し、誰と通信するのか |
| Data Security | データのセキュリティ | 何を保護するのか。誰がどう利用できるのか |
| Security Visibility and Analytics | セキュリティの可視化・分析 | 何が起きているのか。異常やリスクを把握できるか |
| Security Automation and Orchestration | セキュリティの自動化・連携 | 検知したリスクに対して、どのように対応するのか |
レポートでは、人・IDの領域を「people/identity security」や「people/workforce security」、アプリケーションの領域を「workload security」などと表記しています。また、データの領域の英語表記は Data Security です。
人、端末、ネットワーク、ワークロード、データを保護対象として整理し、可視化・分析と自動化・連携でそれらを横断的に支える、と考えると理解しやすくなります。
1. Identity Security:人・IDのセキュリティ
Section titled “1. Identity Security:人・IDのセキュリティ”利用者の本人確認と、アクセス権限の管理を行う領域です。 正しい利用者であっても、業務に不要な権限は与えません。
対象には、従業員、委託先、管理者などが含まれます。サービスやプログラムが使うIDも管理が必要であり、ワークロードの領域とも関係します。
対策例:
- IDを一元管理し、入社・異動・退職に合わせて権限を更新する。
- 多要素認証(MFA)を導入し、可能な範囲でパスキーなどのフィッシング耐性のある認証を使う。
- シングルサインオン(SSO)により、認証とアクセス方針を統一する。
- 職務に応じた最小権限を付与し、定期的に権限を棚卸しする。
- 管理者権限を通常業務の権限と分け、特権アクセス管理(PAM)で利用時間や操作を管理する。
- 端末の状態や不審なログインなどに応じて、追加認証、アクセス拒否、セッション失効を行う。
例えば、経理担当者には経理システムの必要な機能だけを許可し、人事情報やシステム管理機能へのアクセスは許可しません。
2. Device Security:端末のセキュリティ
Section titled “2. Device Security:端末のセキュリティ”アクセス元の端末を把握し、その状態をアクセス判断に反映する領域です。 正しいIDでも、マルウェアに感染した端末からのアクセスは危険です。
対策例:
- PC、スマートフォン、業務用端末などを台帳で管理する。
- MDM/UEM(端末管理)で設定、OS更新、紛失時の処置を管理する。
- EDR(端末の脅威検知・対応)を導入し、不審な動作の検知や端末の隔離を行う。
- OSやソフトウェアの脆弱性を修正する。
- ディスク暗号化、画面ロック、不要な管理者権限の削除を行う。
- 管理対象か、更新済みか、セキュリティ機能が有効かを確認し、条件を満たさない端末のアクセスを制限する。
例えば、会社が管理する更新済みPCには業務システムへのアクセスを許可し、未管理の個人PCには機密データのダウンロードを許可しない設計にします。
3. Network Security:ネットワークのセキュリティ
Section titled “3. Network Security:ネットワークのセキュリティ”必要な通信だけを許可し、侵害された場所から他のシステムへ攻撃が広がることを抑える領域です。
対策例:
- システム間の通信を可視化し、必要な通信経路を定義する。
- マイクロセグメンテーションで、アプリケーションやワークロード単位の通信を制限する。
- ファイアウォールやクラウドの通信制御で、不要な接続を拒否する。
- ZTNA(ゼロトラスト・ネットワーク・アクセス)で、利用者に必要なアプリケーションへのアクセスを許可する。
- TLSなどで通信を暗号化する。
- DNSや外部向け通信を監視し、不審な接続やデータ持ち出しを検知・制限する。
例えば、Webサーバーから必要なアプリケーションへの通信だけを許可し、他の業務サーバーや管理画面へ自由に接続できないようにします。
ネットワークの分割や暗号化だけでゼロトラストが完成するわけではありません。IDや端末の状態、アプリケーション側の権限確認とも組み合わせます。
4. Workload/Application Security:ワークロード・アプリケーションのセキュリティ
Section titled “4. Workload/Application Security:ワークロード・アプリケーションのセキュリティ”実行中のシステムと、そのアクセスや通信を保護する領域です。 ワークロードには、仮想マシン、コンテナ、サーバーレス関数などが含まれます。
対策例:
- アプリケーション、サービス、実行環境の所有者と依存関係を把握する。
- サービスごとにIDを付与し、アクセス先と権限を限定する。
- 短期間だけ有効な認証情報やシークレット管理を使い、共有パスワードやコード内の鍵を減らす。
- 必要に応じてmTLSでサービス間を相互認証し、別途、許可する操作を制御する。
- アプリケーションの各機能で認可を確認し、他人のデータへのアクセスを防ぐ。
- 脆弱性診断、依存ライブラリやコンテナイメージの検査、実行時の監視を行う。
- WAFやAPIゲートウェイなどを補助的に使い、不正なリクエストを制限する。
例えば、帳票作成サービスには必要なデータの参照だけを許可し、顧客情報の変更や他のデータベースへのアクセスは許可しません。
5. Data Security:データのセキュリティ
Section titled “5. Data Security:データのセキュリティ”データの所在と重要度を把握し、利用・保存・共有を適切に制御する領域です。 アクセスする人だけでなく、保護するデータそのものに注目します。
対策例:
- 個人情報、認証情報、機密文書などの所在と所有者を把握する。
- データを分類し、分類に応じた閲覧・変更・共有の権限を定める。
- 保存時と転送時に暗号化し、暗号鍵の利用権限も管理する。
- DLP(情報漏えい防止)で、不適切な送信や持ち出しを検知・制限する。
- SaaSやストレージの公開設定、外部共有、ダウンロード権限を確認する。
- 業務に不要なデータを収集・保存せず、保持期間を定めて削除する。
- データの利用履歴を監査し、バックアップと復元確認で破壊や改ざんにも備える。
例えば、顧客情報を閲覧できる担当者でも、全件の一括ダウンロードや外部への共有には別の権限・承認を必要とします。
暗号化していても、復号できるアカウントが侵害されれば情報は漏れる可能性があります。権限管理と監視を併用する必要があります。
6. Security Visibility and Analytics:セキュリティの可視化・分析
Section titled “6. Security Visibility and Analytics:セキュリティの可視化・分析”複数の領域から情報を集め、リスクを判断する領域です。 ログを保存するだけでなく、異常の検知や制御の判断に使います。
対策例:
- 認証、端末、ネットワーク、アプリケーション、データアクセスのログを集約する。
- SIEM(セキュリティ情報・イベント管理)で、複数のイベントを関連付けて分析する。
- 利用者や端末の通常の行動と比較し、異常を検知する。
- 不審なログインの後の大量ダウンロードなど、連続する行動を検知する。
- 資産情報や権限情報を組み合わせ、影響範囲と優先度を判断する。
- ログの欠落、時刻のずれ、改ざんを防ぎ、検知ルールを継続的に調整する。
例えば、IDの不審な利用と端末の感染検知が重なった場合、単独の通知より高い優先度で調査します。収集するログにも個人情報が含まれるため、閲覧権限と保持期間を管理します。
7. Security Automation and Orchestration:セキュリティの自動化・連携
Section titled “7. Security Automation and Orchestration:セキュリティの自動化・連携”分析結果を、複数のシステムを使った対応につなげる領域です。 自動化は個々の作業を自動実行すること、オーケストレーションは複数の処置を順序や条件に沿って連携させることです。
対策例:
- SOAR(セキュリティ対応の自動化・連携)などで、対応手順を実行する。
- EDRの検知を受けて、端末の隔離やアクセス制限を行う。
- 侵害が疑われるアカウントのセッションを失効させ、再認証を求める。
- チケット作成、担当者通知、証拠の収集を自動化する。
- 高い影響がある処置には承認を組み込み、段階的に自動化する。
- 処置の結果を確認し、誤検知時の解除や復旧の手順も用意する。
例えば、「不審なログインを検知 → 端末とアクセス履歴を確認 → 条件に応じてセッション失効 → 担当者へ通知」という処理を連携させます。
7つの領域を連携させる具体例
Section titled “7つの領域を連携させる具体例”従業員が社外から顧客情報を扱うアプリケーションにアクセスする場面を考えます。
| 段階 | 主な領域 | 実装例 |
|---|---|---|
| 利用者を確認する | Identity | MFAで認証し、業務上必要な権限を確認する |
| 端末の状態を確認する | Device | 管理対象で、更新とセキュリティ機能の条件を満たすか確認する |
| 接続先を限定する | Network | 必要なアプリケーションへの接続だけを許可する |
| 操作を制御する | Workload/Application | アプリケーションが、利用者ごとの許可された操作を確認する |
| データの利用を制御する | Data | 顧客情報の閲覧範囲やダウンロードを制限する |
| 利用状況を分析する | Visibility and Analytics | 認証とデータアクセスのログを関連付け、不審な行動を検知する |
| リスクに応じて対応する | Automation and Orchestration | 追加認証、セッション失効、端末隔離、担当者通知などを実行する |
これは理解のための例です。各領域は、この順番で一度だけ動くものではなく、アクセス中のリスクの変化にも対応します。
追加の評価観点:管理性、API、将来像
Section titled “追加の評価観点:管理性、API、将来像”2020年のForrester Waveレポートでは、7つの主要領域に加え、次の3項目が「Current offering(提供機能)」の評価項目に含まれています。これらは7領域を追加で増やすという意味ではなく、仕組みを運用・連携・発展させられるかを評価する観点として読むと役立ちます。
Manageability and Usability:管理性と使いやすさ
Section titled “Manageability and Usability:管理性と使いやすさ”高機能でも、設定や日常運用が難しければ、誤設定や利用者による回避につながります。
対策・確認例:
- 管理画面でポリシー、資産、アラートを把握できるようにする。
- 管理者の役割を分け、設定変更に承認と監査ログを設ける。
- ポリシーを小さな範囲で試し、影響を確認してから適用する。
- SSOや使いやすい認証で、利用者の負担を減らす。
- 正当なアクセスが拒否された場合の説明、問い合わせ、復旧の流れを用意する。
API:システム連携のためのインターフェース
Section titled “API:システム連携のためのインターフェース”APIは、ID管理、端末管理、ログ分析、対応システムなどを連携させる基盤です。製品にAPIがあるだけでなく、必要な情報の取得や処置が実行できるかを確認します。
対策・確認例:
- 端末リスクの取得、セッション失効、ポリシー変更などのAPIを確認する。
- ドキュメント、対応する連携先、イベント通知、利用制限を確認する。
- APIの認証情報を安全に保管し、権限と有効期間を限定する。
- 再試行、重複実行の防止、監査ログを設計する。
- 連携が停止した場合のアクセス判断と手動対応を決める。
アプリケーション自身が提供するAPIの保護は、ワークロード・アプリケーションの領域にも関係します。
Future State of Zero Trust Infrastructure:ゼロトラスト基盤の将来像
Section titled “Future State of Zero Trust Infrastructure:ゼロトラスト基盤の将来像”これは2020年版で追加された評価項目です。自社で活用する際には、今の機能だけでなく、将来のシステム構成や運用の変化に対応できるかという観点で検討できます。
対策・確認例:
- オンプレミス、クラウド、SaaSを含む将来の構成を描く。
- 新しいアプリケーションや働き方を追加した際の制御方法を考える。
- 既存の対策を活かして、段階的に導入できるかを確認する。
- 製品の連携方針、拡張性、ロードマップ、移行方法を確認する。
- コスト、人員、運用負荷、障害時の業務継続を含めて計画する。
自社でZTXを活用する進め方
Section titled “自社でZTXを活用する進め方”次は、7領域を実務で使うための進め方の例です。
- 守る対象を決める。 重要なデータと業務、その所有者を特定する。
- アクセスと通信を把握する。 誰が、どの端末・アプリケーションを使って、何にアクセスしているかを整理する。
- 7領域で現状を確認する。 既存の対策、未対応の部分、情報連携の不足を整理する。
- 優先度を付けて小さく実装する。 管理者アクセスや重要な業務など、リスクの高い対象から始める。
- 検知から対応までを確認する。 ログが届くか、異常を検知できるか、アクセス制限が実行されるかを検証する。
- 効果と負担を測って改善する。 不要な権限、検知・対応に要する時間、誤検知、問い合わせ、運用負荷を確認する。
各対策には責任者、適用範囲、例外、確認方法を定めます。7つの欄に製品名を埋めることよりも、必要なアクセスだけを許可し、リスクを把握して対応できる状態を作ることが目的です。
- Forrester Research, Chase Cunningham, The Forrester Wave™: Zero Trust eXtended Ecosystem Platform Providers, Q3 2020, September 24, 2020(添付資料)。7領域、追加評価項目、プラットフォーム連携と段階的導入の考え方を参照。
- Forrester: The Tao Of Zero Trust — ZTXの目的と継続的な実装に関する一次資料。
- Portnox: What is a Zero Trust Extended Framework — 関連する解説。
- Cisco Japan Blog: ゼロトラスト考察 – The Forrester Wave™: Zero Trust eXtended Ecosystem Platform Providers, Q3 2020 — 2020年版レポートの日本語解説。