攻撃者はどこまで到達できるのか？

インターネットからのテストは、通常の社内アカウントによる検証とは異なる問いに答えるものです。どのシナリオを対象とし、開始時点でどのような権限を持つかは、共同で定めます。この起点となる条件から、許可される範囲を導き出します。システム、アドレス、アイデンティティは文書化し、共用サービスや第三者システムには特に注意を払います。こうした計画により、責任の所在が不明確なために、調査が付与された承認の範囲を意図せず超えてしまうことを防ぎます。

運用条件も準備の一部です。窓口担当者、テスト時間帯、中止基準をあらかじめ定めます。システムへの変更、負荷テスト、その他踏み込んだ対応は、すべてのペネトレーションテストに暗黙のうちに含まれるものではありません。これらは、合意した手順に明示的に合致している必要があります。結果には、実際の起点となった条件と検証したバージョンを明記します。これにより結果の解釈が容易になります。既存の管理者権限がある状態で観察された脆弱性は、権限のない起点から得られた証跡とは異なる意味を持ちます。

ネットワークセグメンテーションだけでは、すべてのアクセス手段を説明することはできません。ユーザーアカウント、サービスアカウント、管理経路は、システム間に別の接続を生み出す可能性があります。そのため検証では、承認された範囲内で、技術的な境界とロールが意図したモデルを実際に実現しているかを確認します。個々の設定ミスは、その影響との関連の中で評価します。検出結果は、貴社の環境にとってなぜ重要なのか、また実証されたアクセスにどのような前提条件があるのかを示すものです。

IaaS環境では、これに加えて事業者との境界線も考慮する必要があります。顧客が責任を負うリソースや設定は検証の対象となり得ますが、それによって共用のプラットフォームサービスが自動的に承認されたことになるわけではありません。検証の前に、必要な権利と要件を確認します。関連する拠点やアプリケーションも影響を受ける場合があります。そのため計画段階では、クラウド担当者とインフラ担当者を連携させ、テストの内容を関係者が把握できる状態に保ちながら、その影響を合意した範囲内で管理できるようにします。

結果では、確定した検出結果、留意事項、検証対象外の範囲を明確に区別します。証跡には、必要な前提条件と観察された影響を記載します。証跡は、不必要に機微なデータを収集することなく、評価を可能にするものでなければなりません。経営層と技術チームには、それぞれに適した形式で提供します。特に重要な観察結果は、合意した報告経路を通じて伝えます。これにより、ペネトレーションテストは単なる技術的な通知の出力にとどまらず、責任者がどの対策を優先して実施すべきかを判断できるものとなります。

是正には、アイデンティティ管理、ネットワーク運用、アプリケーション運用など複数のチームが関わることがあります。そのため提言は、それぞれの依存関係も踏まえて協議します。リテストは合意した変更後のバージョンに焦点を当て、具体的な証跡が依然として再現できるかを記録します。適切かつ明確に定義された目標については、Result as a Serviceによる成功報酬型の取り決めも可能です。その場合も、許可されたテスト範囲は引き続き拘束力を持ち、経済的なインセンティブによって拡大されることはありません。