「何も信頼しないゼロトラスト」 その“仕組み自体”はどこまで信頼できる？――防げる脅威、防げない脅威：導入後に残る7つの脅威（1/2 ページ）

ゼロトラストアーキテクチャ（ZTA）は、従来の境界型防御では防ぎ切れない脅威への対策として有効ですが、万能ではありません。本稿では、ZTAで防げる脅威と防げない脅威、その対策を解説します。

[石塚 健太郎（A10ネットワークス）, 編集：遠藤文康，＠IT]

　「ゼロトラストアーキテクチャ」（ZTA）を導入することで、従来の境界型防御では十分に対処できなかった脅威への対応が可能になります。しかし、ZTAだけで全てのサイバー攻撃を防げるわけではありません。ZTAを導入することで攻撃面が増える側面も考慮しなければなりません。本稿では、ZTAで防げる脅威を振り返るとともに、導入後も残るセキュリティリスクと、その防御手段について解説します。

ゼロトラストアーキテクチャで防げる脅威

　まずZTAがどのような脅威を防御できるのかについて振り返ります。

　ZTAは、「組織内のネットワークだから安全」「一度認証されたから安全」といった暗黙の信頼を排除し、ユーザーや端末、アクセス先のリソース、その時点での状況などを継続的に評価しながらアクセスを制御するセキュリティの考え方です。

　ZTAを定義した文書である「NIST SP 800-207」では、ネットワーク上の場所だけを理由に信頼を与えるのではなく、リソースへのアクセスをセッション単位で判断し、必要最小限の権限を付与することを基本原則としています。ユーザーだけでなく端末の状態や行動、周囲の環境などもアクセス可否の判断材料とし、認証・認可を継続的に評価することを重視しています。

　ZTAが特に効果を発揮するのは、従来の境界型ネットワークで問題となってきた、攻撃者による侵入後の自由な活動を抑制する場面です。

　例えば、VPN機器の脆弱（ぜいじゃく）性などを突かれて組織内のネットワークに侵入された場合です。一般ユーザーの認証情報が窃取されても、そのアカウントに必要最小限のアクセス権しか与えられていなければ、攻撃者が組織内の重要なリソースへ自由にアクセスすることを抑制できます。あるリソースへのアクセスが許可されたとしても、それによって他のリソースへのアクセスまで自動的に許可されるわけではありません。

　端末についても同様です。例えば支給端末だから安全と固定的に判断するのではなく、端末のセキュリティ状態などを確認し、リスクが高まっていればアクセスを拒否するといった制御が可能になります。

　従ってZTAの強みは、「不正アクセス」「盗まれた認証情報の悪用」「過剰な権限付与」「侵害された端末からのアクセス」「侵入後の横展開」など、本来許可されるべきでない主体（ユーザー、アプリや端末）がリソースへ到達するリスクを低減することです。

　ただしZTAは、あらゆるサイバー攻撃を防ぐ“万能な仕組み”ではありません。ここからはZTAを導入しても防げない脅威と、その対策を見ていきましょう。

ゼロトラスト導入後にも考慮すべき7つの脅威

　NISTはSP 800-207において、ZTAを導入した後にも考慮すべき7つの脅威を明示しています。

1．ZTAのアクセス判断を行う仕組みそのものへの攻撃

　ZTAでは主体からのアクセス要求に対し、ポリシーエンジン（PE）がアクセスを許可するかどうかを判断し、「ポリシーアドミニストレーター」（PA）がその判断を実行に移し、「ポリシー実行ポイント」（PEP：Policy Enforcement Point）が実際のアクセス制御（アクセスの許可・拒否）を行います。PEやPAが侵害されたり、ポリシーが不正に変更されたりすると、本来拒否すべきアクセスが許可される可能性があります。すなわち、ZTAを実現するための基盤そのものが、新たな守るべき重要資産になるということです。

　IDを管理するIDaaSが攻撃を受けてセッションがハイジャックされたり、アクセス制御ポイントの脆弱性が突かれて攻撃されたりするといった攻撃の実例もあります。

2．DoSやネットワーク障害による可用性への脅威

　事業活動を妨害するだけであれば、ZTAの仕組みに侵入する必要もなく、「サービス拒否攻撃／分散型サービス拒否攻撃」（DoS／DDoS攻撃）によって機能を無力化するだけで十分です。PE、PA、PEPやアクセス先のリソースがDoS／DDoS攻撃やネットワーク障害によって利用できなくなると、ユーザーの認証やポリシーが正しくても、正規ユーザーはサービスを利用できなくなります。そのため、ゼロトラストによるアクセス制御とは別に、DDoS対策、システムや回線の冗長化、障害時の切り替えなど、サービスを継続するための可用性対策が必要となります。

3．認証情報の窃取と内部不正

　ZTAは盗まれた認証情報による被害範囲を限定することには有効ですが、正規アカウントにもともと認められている操作まで自動的に不正と判断できるわけではありません。悪意のある内部関係者についても同様です。従って、多要素認証（MFA）だけでなく、「最小権限の徹底」「認証後のセッション監視」「ユーザーの行動分析」「情報漏えい対策（DLP）」などを組み合わせ、認証されたユーザーだからという理由だけで安全と判断しない仕組みが必要になります。

4．ネットワークやシステムの可視性の不足

　ZTAでは適切なアクセス判断を行うためにさまざまな監視情報を利用しますが、通信が暗号化されていたりすると全ての通信内容を直接確認できるとは限りません。暗号化されている通信の可視化も含め、認証ログ、端末から得られる情報、ネットワークの通信情報、アプリケーションログなどを組み合わせることによってアクセス判断や異常検知に必要な可視性を確保することが重要です。

5．ZTAが収集・蓄積する情報そのものへの攻撃

　ZTAで収集・蓄積されるアクセス制御ポリシー、アクセスログ、端末情報、ネットワーク構成などの情報は、攻撃者にとっても「誰を侵害すれば、どのリソースへ到達できるか」を把握するために価値の高い情報です。そのため、ZTAの管理情報や監視情報そのものを重要な情報資産として扱い、厳格なアクセス制御や監視を行わなければなりません。

6．特定のデータ形式やベンダーへの過度な依存

　ZTAの実現には、ユーザー認証、端末情報、脅威情報、ログ、ポリシーなど、さまざまな情報を連携させる必要があります。これらが特定ベンダー独自の機能やAPI、データ形式に強く依存すると、重大な障害や脆弱性が発生した際にも、他の製品やサービスへ容易に切り替えられない可能性があります。これに対処するため、製品のセキュリティ機能だけでなく、他製品との相互運用性、移行にかかるコスト、サプライチェーンリスク、将来的に別製品へ移行できるかという出口戦略まで考慮する必要があります。

7．AIなど人間以外の主体をZTAの管理に利用することによるリスク

　自動化されたZTAの運用を目指してAI（人工知能）やソフトウェアエージェントにポリシー変更などの権限を与えると、誤判断や認証情報の窃取に加え、AIに不正な動作を実行させるためのプロンプトインジェクションなどによって意図しない動作へ誘導されてしまう可能性も考慮する必要があります。AIによる自動化を利用する場合でも、必要最小限の権限しか与えない、操作内容を記録する、重要な変更には人間による承認を必要とするといった仕組みが重要になります。

ゼロトラストだけでは防げないセキュリティリスク

　上記に挙げたNISTが示している7つの脅威だけが、ZTA導入後に残るリスクではないという点にも注意が必要です。

　例えば、正規ユーザーが認証・認可され、PEPを正常に通過したとしても、そのユーザーからリソースへ送られたリクエストが安全とは限りません。ユーザーや端末がアプリケーションと通信するやりとりに「SQLインジェクション」「コマンドインジェクション」「クロスサイトスクリプティング（XSS）」「サーバサイドリクエストフォージェリ（SSRF）」「APIの悪用」「悪意のあるファイル」「生成AIに対するプロンプトインジェクション」などが含まれると、正しいユーザーが正規の手順でアクセスしている状態でも攻撃が成立する可能性があります。

　つまり、ZTAが実現する「特定の主体に対するリソースへのアクセス許可」と、アクセス許可後に発生する「その主体から送られたリクエストを安全に処理できる」ことは別の問題であることを認識する必要があります。

　このような脅威に包括的に対処するためには、ZTA導入後もエンドポイントセキュリティ、脆弱性管理、セキュアコーディング、WAF（Webアプリケーションファイアウォール）／WAAP（WebアプリケーションおよびAPIの保護）、APIセキュリティ、IPS/IDS（不正侵入防御/検知システム）、NDR（ネットワーク脅威検知・対応ソリューション）、DLP（データ損失防止）、AIセキュリティ、DDoS対策などを組み合わせることが必要になります。

　ZTAはサイバーセキュリティ全体を置き換えるものではありません。既存のセキュリティ対策と組み合わせることで、初めて包括的な防御につながります。