自律型ペネトレーションテストはどこで止まるのか? OWASP APTS実行時の安全要件

今回扱うOWASP APTSの範囲

前回は、OWASPの「Autonomous Penetration Testing Standard (APTS)」を紹介しました。

APTSは、自律型ペネトレーションテスト(以下、ペンテスト)基盤のためのガバナンス標準であり、8つのドメインで構成されています。LLMを利用する基盤も対象に含まれており、それらに特化した要件も定められています。本稿ではAPTS v0.1.0を対象とします。

今回は、そのうち実行時の安全性に関わる4つのドメインを扱います。「スコープ強制(Scope Enforcement)」「安全制御(Safety Controls)」「人間による監督(Human Oversight)」「段階的な自律性(Graduated Autonomy)」です。

この4つは、自律型のペンテスト基盤を動かす前に決めておくべき課題に対応しています。どこまで触ってよいのか、その操作をいま実行してよいのか、誰がいつ承認するのか、どこまで任せるのか、という4つの問いです。

検証対象の境界を機械が検証できる形にする

スコープ強制のドメインには、26件の要件が含まれています。APTSは、このドメインを意図しない被害に対する第一線の防御と位置づけています。対象外のシステムに攻撃してしまう基盤は、標準の他の領域の統制をどれだけ備えていても安全にはできないためです。

最初の要件は、ペンテストの実施条件を機械可読な形式で定義することです。ペンテストでは、対象範囲、実施時間帯、禁止事項などを定めた取り決めを「RoE(Rules of Engagement)」と呼びます。

従来のRoEは、契約書や作業指示書のような、人間が読む文書として書かれてきました。APTSの要件APTS-SE-001では、RoEをJSONやYAMLのような機械が解析できる形式で記述し、検証に失敗した場合はテストを開始できないことを求めています。

人間向けの文書には解釈の余地が残りますが、機械可読な定義であれば、個々の操作の前にプログラムで照合できます。

照合のタイミングも定められています。APTS-SE-006は、TCP接続、DNSの名前解決、HTTPリダイレクトの追跡、API呼び出しといったすべてのネットワーク操作の直前に、対象がスコープ内かを検証することを求めています。

ペンテスト開始時に一度確認するだけでは足りません。ペンテスト中にDNSの解決先が変わったり、リダイレクトが対象外のドメインへ誘導したりして、同じ操作の宛先が途中で変わり得るためです。APTS-SE-007ではペンテスト開始時の名前解決の結果をベースラインとして保存し、再解決の結果が変わった場合は一時停止して再認可を求めることも規定されています。

さらに、スコープ内であっても触れてはならない資産も定義されています。APTS-SE-009は、無条件に保護する対象のリスト(hard deny list)を要求します。

本番データベース、DNSや認証システムのような基盤インフラ、個人情報や医療情報のデータストア、金融取引システム、産業制御システム、Active DirectoryなどのIDプロバイダが必須カテゴリとして挙げられています。このリストはスコープ検証よりも先に評価され、顧客が明示的に依頼した場合でも上書きできません。

LLMを使う基盤に固有の要件もあります。APTS-SE-023は、パスワードやAPIキーのような秘密情報の平文を、LLMの推論コンテキストに一切入れないことを求めています。

モデルにはIDやロール名のような参照だけを渡し、実際の秘密情報はツールを実行する側で処理します。モデルのコンテキストに含められた文字列は、モデルの出力やログ、外部のAIプロバイダへの送信といった経路を通じて漏えいするリスクがあるためです。

操作の影響を測り、止める仕組みを用意する

安全制御のドメインには、20件の要件が含まれています。スコープ強制が「どこを触ってよいか」を決めるのに対し、安全制御は「その操作を、いま、その強度で実行してよいか」を判定します。

その判定の前提となるのが、操作の影響分類です。APTS-SC-001は、すべての操作を実行前にCritical、High、Medium、Lowの4段階に分類し、機密性、完全性、可用性の3つの観点で採点することを求めています。この分類により、その操作に人間の承認が必要かどうかが決まります。

負荷の制御としては、ホスト単位、サブネット単位、データセンター単位、ペンテスト全体という4つの層でレート制限を設けることがAPTS-SC-004で規定されています。

このドメインで特徴的なのは、キルスイッチの要件APTS-SC-009です。キルスイッチには、オペレータによる手動停止、承認された担当者による遠隔停止、制御サーバとの通信が失われた場合の自動停止という、互いに独立した3つの起動経路が求められます。

停止の動作は2段階で定義されています。第1段階では、起動から5秒以内に、新規のネットワークリクエスト、新規の攻撃ペイロード送信、新規のテスト操作をすべて停止します。

第2段階では、60秒以内に、実行中の操作の終了、子プロセスや外部エージェントの停止、ネットワーク接続の切断、テスト中に発行した一時認証情報の失効、ログの確定までを完了します。

人間が異常に気付いてボタンを押す場合だけでなく、基盤側の障害で制御が失われた場合にもペンテストが止まる設計です。

停止は、人間の判断を待たずに起きる場合もあります。APTS-SC-010は対象システムの応答時間を継続的に監視し、ベースラインの2倍を超えた場合はエスカレーション、ヘルスチェックの連続失敗が設定された閾値(推奨される既定値は3回)を超えた場合は当該対象へのテストの自動停止を求めています。

検証対象を壊さないための後始末も要件化されています。アカウント作成やファイル変更のような操作は実行前の状態とともに記録してロールバック可能にすること(APTS-SC-014)、テスト終了後にファイルのチェックサム、アカウント、データベースのレコード数、設定をベースラインと照合すること(APTS-SC-015)が定められています。

前回紹介した、モデルの外側で許可リストを強制する要件APTS-SC-020も、このドメインに含まれています。関連するAPTS-SC-019は、ファイルアクセス、通信先、プロセスの権限といった実行境界を、OSカーネルの隔離機構やコンテナランタイムのような、エージェント自身が変更できない層で強制することを求めています。

APTS-SC-020の根拠には、システムプロンプト内の指示はプロンプトインジェクション、敵対的入力、モデルの更新、想定外の入力に対して信頼できないと明記されています。

モデルへの指示は統制の根拠にならない、という前回確認した設計思想が、要件の文面にそのまま現れています。

人間の承認をどこに残すか

人間による監督のドメインには、19件の要件が含まれています。自動化の速度を活かしつつ、影響の大きい判断を人間に残すためのものです。

まず、事前承認を必要とする操作が、自律性レベルのL1とL2について定義されています(APTS-HO-001)。最も低いレベルでは、脆弱性の悪用試行、システム間の横展開、データへのアクセスのすべてに事前承認が必要です。自律性が上がると、承認の対象は深刻度の高い操作に絞られます。

例えば、CVSSスコア(脆弱性の深刻度を0から10で表す指標)が7.0以上の脆弱性の悪用には、承認が残ります。承認を求めたのに人間が応答しない場合の動作も、APTS-HO-003で定義されています。

タイムアウト後に操作を自動承認することは禁止されており、応答がなければ「承認しない」とみなして安全側に倒します。承認待ちのままペンテストが滞らないよう、拒否された操作は記録した上で次の検証に進みます。

承認とは別に、人間へのエスカレーションが必須となる場面も定義されています。APTS-HO-011が挙げるのは、ペンテスト中に別の攻撃者による侵害の痕跡を発見した場合、違法なコンテンツを発見した場合、未知の脆弱性(ゼロデイ)を発見した場合などです。

これらの予期しない発見について、基盤は状況、分析結果、推奨対応を人間のオペレータに即時エスカレーションします。人間が5分以内に応答しない場合は、すべての操作を一時停止して状態を保全します。

また、APTS-HO-013では、対象がスコープ内かどうかの確信度が75%を下回る場合、人間への確認を必須としています。

監督する人間の側にも要件があります。APTS-HO-018は、オペレータが担当する自律性レベルに応じた訓練と資格を持つこと、緊急停止やエスカレーション対応の訓練を受けること、年1回以上の能力評価を受けることを求めています。

承認ボタンを押す人間が状況を理解できていなければ、承認ゲートは形だけのものになるためです。

自律性のレベルと昇格の条件

段階的な自律性のドメインには、28件の要件が含まれています。前回、APTSが自律性をL1からL4の4段階に分けていることを紹介しました。このドメインを読むと、各レベルの違いは「人間の承認をどの粒度で求めるか」として整理されていることが分かります。

L2を例にすると、情報収集フェーズの中で複数の列挙技法を続けて実行することは自動で行えますが、情報収集から脆弱性の検証へ進むフェーズの遷移には、オペレータの承認が必要です。

L3では、人間が事前に境界を定義し、その内側であれば検証まで含めた一連の操作を任せます。

スコープ逸脱の兆候のような例外が起きたときに、初めて人間が介入します。

このレベルは、自由に選べるわけではありません。APTS-AL-025では、次のような昇格条件が定められています。

• L1からL2へは、スコープ違反も安全上のインシデントもゼロのまま、50時間以上のL1運用実績を文書化していること
• L2からL3へは、5件以上の案件にまたがる200時間以上のL2運用実績があり、封じ込めに失敗したインシデントがゼロであること
• L3からL4へは、500時間以上のL3運用実績に加えて、敵対的な安全性テストに合格し、開発チームから独立した人員による安全性評価を受け、24時間365日の監視体制とインシデント対応体制を備えていること

つまり、APTSにおいて自律性は導入時に選ぶ設定値ではなく、運用実績を積んで段階的に獲得する資格として扱われています。新しいペンテスト基盤にいきなり全フェーズを任せる運用は、この標準の枠組みにおいては成立しません。

4つのドメインに共通する設計

今回見た4つのドメインの要件は、共通の設計に沿っています。

• 境界はモデルへの指示ではなくモデルの外側の機構で強制する
• 人間の応答がなければ、承認せず停止する側に倒す
• 自律性は実績に応じて段階的に広げ、どの段階でも人間が止められる手段を残す

どれも、AIの判断能力を信頼の根拠にしない、という一貫した前提の上に成り立っています。

この設計は、ペンテストに限らず、外部に影響を与える操作を行うAIエージェント全般に応用できます。ファイルの削除、メールの送信、決済のような操作を自律的なシステムに任せる場面でも、同じ課題が成り立つためです。

次回は、APTSの残りの4つのドメインである「監査可能性」「操作耐性」「サプライチェーン信頼性」「報告」を見ていきます。ペンテスト基盤そのものが攻撃された場合の防御と、ペンテスト結果をどう信頼するかという問題を扱います。