具体的な適用手順

適用プロセス

ゼロトラストアーキテクチャは、中長期的に運営する政府情報システムを堅牢にするための考え方である。従って、「ゼロトラストアーキテクチャの適用」は一過性なプロジェクトではなく、ましてや単一のソリューションを導入したことで完了するものでもない。政府情報システムにおける特定の目標を特定の期間で実行するプロジェクト・サイクルを繰り返すことで成熟度をあげる行為が、ゼロトラストアーキテクチャの適用といえる。そのサイクルは図３‑１の通りになる。なお、本章では図３‑１に従い各プロセスを説明するが、プロセスはどこから開始しても良い。また、同様のプロセスが存在している場合には既存のプロセスで代替しても問題はない。

体制の構築

適切なゼロトラストアーキテクチャの考え方を政府情報システムへ適用するには、十分な体制が必要不可欠である。当該体制を実現するために招集する対象は、業務フローの流れなどについて最も理解が深いであろう業務担当者や開発者はもちろんのこと、監視業務等の運用や保守担当者も含まなければならない。業務、開発、運用は情報システムの運営という観点では排他的ではなく、相互に調整し最適解を見つけることが重要である。この最適解は、運用にあわせ業務フローを見直すことも含める。

また、それぞれのステークホルダー間の責任範囲を明確化し、責任分界点を設けることが望ましい。

リソースや業務フローの識別・特定プロセス

システム上のリソースと業務フローを識別・特定する。この際に、機密性・完全性・可用性などの観点から、リソースと業務フローに関する特性も分析の対象とすると、後続するプロセスでより活用しやすい。

なお、リソース識別時の粒度は、当該組織の過去の施策と現状、あるいは保護したい対象に応じて異なる。例えば、対象をデバイス上で直接動作するソフトウェアまでを対象とするか、あるいはサービスやソフトウェアが再帰的に依存するライブラリやモジュールまでを対象とするか、を判断する必要がある。

スコープの決定プロセス

リソースや業務フローに対する攻撃経路、脅威、リスクを、脅威モデリングなどによりスコープを特定する。先述したプロセスで分析した内容から影響度を算出し、それに応じた優先度や対応内容・粒度を検討する。

例えば、ユーザの身元確認・当人認証に高いリスクがあるのであれば、全利用者を対象にした多要素認証の必須化や、信頼できるIDプロバイダとのシングルサインオンの推進などが施策の候補に挙がる。あるいは、テレワークを前提とした中でネットワークに対するガバナンスを強化したい場合は、SDN（Software Defined Network）やSASE（Secure Access Service Edge）といったソリューションを全業務デバイスに導入するといった施策が考えられる。

実装・導入の推進プロセス

前項で定めたスコープをもとに施策を進めるが、変化する業務環境やセキュリティにあわせ、設計・開発・テスト・成果物のリリースといった一連の流れをより高頻度に行える状態にすべきである。

その場合、手動による変更は柔軟性が高いものの、頻繁な変更には向かない。構成をコード化し、変更のリリースを自動化することが望ましい。

観測プロセス

利用者のアカウントの動作、デバイスの状態、ネットワークなど、リソースに関する観測をする。観測は、ログの収集や分析、パフォーマンスの監視、アラート通知などが含まれる。SOCが利用するSIEM（Security Information and Event Management）を通して行われるケースもあれば、それぞれのログからアクセス制御ポリシーによって評価されることもありえる。どのように行うかは、採用した技術やソリューションにより異なるが、監視結果に応じてどのようなアクションを起こすか、といったような観測の目的を明確化することが重要である。

評価及び改善プロセス

取り組んだ内容の有効性を評価し、次のサイクルに活用する洞察を得る。それによりゼロトラストアーキテクチャの考え方を適用したシステムの成熟度の向上が期待できる。

一方、評価方法については留意すべきである。増え続ける脆弱性や業務の変更を受け、システムの変更を頻繁に実施可能な状態にすることが望ましいのは先述した。その場合、従来の半年や年次の内部監査等の人的リソースに依存した評価方法は、システム変更の頻度・速度に比較すると十分ではないことが懸念される。そのため、CSPM（Cloud Security Posture Management）などの活用で、受動的な評価を自動化し、補強することが望ましい。独立組織による疑似攻撃による脆弱性の検証をおこなうレッドチーム演習のような能動的な評価も定期的に実施することが望ましい。

適用における留意事項

ゼロトラストアーキテクチャを適用するには、適用プロセス内で実施する内容に留意しなければならない。

運用・保守体制を確保する

成熟度にもよるが、概念図における外部システムを含む各種コンポーネントやデータは、複数の組織外の担当者によって共有されることが予想される。運用・保守の対象はそれらコンポーネントやデータも含む。そのため、システムの運用担当者のリソース確保のため、ステークホルダーとの事前調整と合意が重要になる。当然、観測の結果、セキュリティインシデントなどが検出されるなどの場合も想定し、非定常的な事態を想定した連絡体制と協同体制も構築すべきである。

運用の設計と実装を初期段階から想定した適用プロセスを進める

上述した通り、ゼロトラストアーキテクチャの考え方が適用されたシステムでは、運用が複雑になることが予想される。ゼロトラストアーキテクチャ適用の目的はシステムの継続的な価値創出であり、既存実務とゼロトラストアーキテクチャ適用後の実務とのギャップを埋めることが重要である。政府情報システムが達成したい目標や、利用者の利便性を保つためにも、適用プロセスの初期段階から、運用の設計・実装も同時に実行しなければならない。そうすることにより、修正の機会をより多く得られ、またスムーズな実稼働フェーズへの移行を実現できる。

アクセス制御の評価タイミングをアクセス要求時に限定しない

ゼロトラストアーキテクチャでは、アクセス制御ポリシーによる「評価」と、その評価結果を実際のアクセス制御として反映する「施行」が、それぞれ独立したアクションとなる。したがって、特定のタイミングでは評価を有効化するが施行はしない、といった状態が成立しうる。アクセス制御の施行前に業務への影響を検証する必要があれば、その状態を設定可能なソリューションを導入あるいは実装をするべきである。

また、アクセス制御の評価と施行の対象は、まだアクセスが確立されていないアクセス要求のみに限定されず、確立済みのアクセスも含まれる。ブラウザでの利用を考えると、セッション・ハイジャックは依然として存在する脅威になるからである。したがって、アクセスが確立された後も継続的にアクセス制御の対象になる。アクセス制御の手法は特性に応じて選択される。

アクセス評価の結果を施行する箇所が、アクセス元のリソースか、アクセス先のリソースか、あるいはアクセス元とアクセス先の中間にあるプロキシのようなリソースが実施するかについては、業務フローやシステム構成によって変わる。識別されたリソースや業務フローの特性に応じた構成を設計段階から検討すべきである。

例えば、複雑な業務フローと権限設定を前提とするアプリケーションがあるとする。この場合、利用者の権限は業務に依存する傾向があるため、権限管理をアプリケーション（アクセス先）に集約するケースも考えられる。つまり、アクセス制御の施行箇所がアクセス先になる。

一方、アクセス制御がアクセス元で施行されるケースも考えられる。例えば、モダンなネットワークソリューション（SASE, SDN等）のデバイス・エージェントは、ネットワークトラフィックをデバイス上で評価し制御を施行するものもある。評価内容を示すポリシーは当該ソリューションの集中管理機能からエージェントに配布され、アクセス制御の評価・施行機能からは独立している。

また、アクセス制御の評価と試行が同じ箇所になることもありえる。例として、物理的なファイアウォール機器がある。これは、同一の機器にネットワークルールを設定でき、それに基づいてネットワーク制御が行われる。

アクセス制御の評価および施行方法については、業務におけるアクセス制御のあるべき姿、ステークホルダー間の責任分界点、導入予定あるいは導入済みソリューション・実装の仕様にあわせて、構成を検討する必要がある。

技術標準による相互互換性を確保する

業務の現場において、様々な業務特有の独自性があることは否定できない。しかし、業務をシステムとして実装あるいはソリューションを導入する際には、既に標準化されたデータフォーマットや実装方式がある場合は、それらに従い、再定義することを避けるべきである。もし、どうしても独自に実装するのであれば、それによって発生するメリット・デメリットを注意深く検討するべきある。

技術標準に従わない場合、他のソリューションやサービス、あるいはそれらが提供するAPIとの連携が困難になる恐れがある。それはつまり、システム化の難易度および運用の複雑性が増し、人的リソースを含めた各種コストが上がることを意味する。

また、セキュリティ観点でも、例えば、暗号化や署名といったものを独自実装した場合、多人数によるアルゴリズムのチェックや、万が一それに問題があった際のパッチ作成が困難になり、結果的にセキュリティリスクが高まる恐れがある。パッチ作成が可能であったとしても、特別なものになるため、通常よりコストが上がることが想定され、また、ベンダーロックインのリスクも高まる。

本来の政府情報システムが提供したかった価値に制限がかかる可能性があるため、技術標準による相互互換性の確保は重要である。特定の用途で独自の実装要件が必要なケースはありえるが、同時にそういったケースは本ガイドラインを適用する政府情報システムおよび業務システムにおいては稀であると想定する。

利用者の問い合わせ対応を強化する

ゼロトラストアーキテクチャ概念図で示した通り、一連の業務フロー内で複数のアクセスが行われる。実際の業務を執行する利用者には、サーバ間のアクセスやデバイスからアプリケーションへのアクセスについては、ブラックボックス的になる。そのことから、利用者が想定していない動作に直面しても、どこで問題に陥っているかが認知されにくい。したがって、利用者の負担が増えると予想される。例えば、パッチを一定期間内に適用していないデバイスにリスクがあるとしてアクセスを拒否した場合、本人の直接的な操作に起因しないため、即座に本人がパッチ適用をするアクションに繋がらない恐れがある。本人が原因と対処方法を実行できることが理想的だが、サービス間がAPIを使う機械的なデータ連携をするフロー内で拒否あるいは意図しない挙動が起こった際は難しい。

そのため、エンドユーザから問い合わせへの一次対応を受け持つ部門が必要になることが予想されるが、その部門もユーザからの問い合わせから問題になったアクセス要求をトレース・特定し、適時、問題発生個所を所管する部門に連携することになると思われる。問い合わせ時の対応についても、設計段階から準備しておくべきである。担当部門の窓口を伝え利用者自身で問い合わせてもらうか、一次対応部門から連携するなどの方式が考えられる。

また、ユーザの画面に特定の問題を示すエラーコードや、トレースを容易にするためのアクセス要求識別子、簡易的なメッセージを表示するなど、エンドユーザの問い合わせ負荷や問い合わせ対応者の調査、対応者間の連携を円滑にする手法を想定すべきである。あるいは、その情報を自動提供できるような問い合わせ機能を提供することを検討するべきである。