- 公開日
セキュリティ業務でAIを使うときは、調べてよい対象と目的を先に固定し、秘密を除いた資料から原因候補や確認事項を整理させます。ログの分析を頼むことと、設定変更や権限追加を認めることは別です。AIが提案した修正は、担当者が根拠と影響を確認し、許可された検証環境で確かめてから変更承認へ進めます。
「防御のため」という目的だけでは、どの環境を調べ、何を変更してよいかは決まりません。対象の所有者、委託範囲、利用できる資格情報、停止条件を明らかにし、AIへ渡す入力もその範囲に合わせます。ここでは攻撃手順ではなく、障害ログの分析から防御上の修正を検討する一件の案件を扱います。AIを含むシステムで守る資産や経路の洗い出しは「AIの脅威モデリングとは？ データからツールへ届く経路を点検する」で扱っています。
分析の依頼と、操作の許可を分けて始める
架空の社内文書サービスで、検証環境の閲覧要求が拒否される障害を調べるとします。案件責任者は、セキュリティ担当者に「検証環境の機密を除いた分析用ログを基に、原因候補と確認案をまとめる」ことを許可しています。本番への接続、他部署のデータ閲覧、権限変更、外部への送信は、この依頼に含まれない設定です。
AIの利用先も組織が承認した分析環境に限定し、提供するログの種類と保存条件がその承認に含まれることを確認します。社内のAIだから何でも渡せると判断したり、学習に使われない設定だけで入力を許可したりしません。サービスの契約・設定と、資料の取扱条件を実際の利用に対応させます。
NIST SP 800-115の2.1節は、評価の計画段階で、対象の資産や前提を集め、目的、範囲、役割と責任、制約などを計画にまとめることを示しています。5.2.1節も、侵入テストの計画段階で規則を定め、管理者の承認を文書化するとしています。2008年の一般的な評価ガイドであり、現在のAI製品仕様を示す資料ではありません。本稿では、作業範囲を記録してから評価するという計画の観点を参照します。
この案件では、担当者が分析用資料を作り、システム管理者が検証用設定の状態を確認し、案件責任者が追加試験の要否を判断します。AIは資料整理を支援しますが、自分で対象を追加したり、利用者の権限を拡大したりする主体にはしません。
認証情報は、モデルへ渡す前に除く
説明用の原ログに、次の項目があるとします。時刻、要求ID、主体、文書ID、判定はすべて架空です。認証情報欄の「DUMMY_ONLY_NOT_VALID」は、実際には使用できないダミー文字列です。
| 原ログの項目 | 説明用の値 | AI向け資料での扱い |
|---|---|---|
| 時刻・環境 | 検証時刻T1・検証環境 | 事象の順序を追うため保持する |
| 要求ID | TEST-REQ-A | 他の記録との対応に必要な範囲で保持する |
| 主体 | test-viewer | 実環境では必要に応じ一貫した仮名へ置き換える。再識別の可能性も管理する |
| 操作・対象 | read・test-document-A | 許可された検証対象と照合できる形で保持する |
| 判定 | permission_denied | 拒否された事象として保持する |
| 認証情報 | DUMMY_ONLY_NOT_VALID | 値を除き「認証情報の値を除去」と表示する |
この表は、ダミー情報の除去を説明する例です。有効な認証情報をAIへ入力して「秘密を消して」と頼む手順ではありません。実務では、管理された前処理で許可した項目だけを抜き出し、検出処理と人の確認を組み合わせてから分析環境へ渡します。検出器に一致しなかったことだけで、秘密がないと断定しないようにします。
OWASPのLogging Cheat Sheetは、アクセストークン、パスワード、接続文字列などをログへ直接記録しないための除去・マスキング等を示しています。すでにログに含まれている場合も、AI向け資料を作る前に同様のデータ分類が必要です。自由文のエラー、URLのパラメータ、スタックトレースにも情報が混ざるため、名前が「認証情報」の欄だけを調べて終わらせません。
原本は担当者がアクセス制限された保管先で扱い、分析用の複製と区別します。原本を書き換えて秘密を隠すと、証拠や変更履歴を損なうおそれがあります。秘密を含む記録の保護・除去は、組織の保管方針と事故対応手順に従って判断します。AIへ渡した資料には、どの項目を除去したかを残しますが、除去した値そのものは書きません。
拒否ログから、原因を決め付けず候補を整理する
AIへの依頼は、「認証情報を除いた検証ログを基に、観測事実、原因候補、追加確認を分けてください。許可された資料にない設定は未確認とし、認可の無効化や権限拡大を解決策として確定しないでください。変更は行わず、確認案だけを作ってください」とできます。差し替えるのは資料名、対象環境、分析目的、禁止する操作です。
この資料から確認できるのは、閲覧要求が権限不足を示す判定で拒否されたことです。それだけでは、利用者の登録、対象文書の分類、認可設定、テストデータの準備のどこが原因かは決まりません。例えば、対象文書が誤って制限領域に入っている可能性と、閲覧用アカウントに必要な役割が付いていない可能性を候補に分け、管理者へ照会する設定項目を示します。
望ましい分析案は、「test-viewerのread要求が拒否された。原因は未確定。対象文書のアクセス規則と、当該主体に現在付与されている役割を、管理者が検証環境の設定から照合する」です。「ユーザーに管理者権限を付ければ直る」とする案は、症状を消せても不要な操作を許すため、そのまま採用しません。
ログ中の自由文に操作を求める記載があっても、分析対象のデータとして扱います。AIが読み取った文言をコマンドへ変えたり、ログに現れた接続先を自動的に調査対象へ追加したりしません。必要な追加調査は、対象と実施方法を担当者が確認してから許可範囲へ入れます。
修正案は、許す動作と拒否する動作の両方で確かめる
管理者の照合で、検証用文書の分類が想定と違うと確認された場合を考えます。担当者は「文書分類を正しい検証用領域へ戻す」という修正案を作り、対象、変更前後、影響する利用者、戻し方を示します。原因が未確認のまま、権限設定と文書分類を同時に変更すると、何が効いたかを切り分けにくくなります。
修正を検証する際は、許可された検証環境とダミーデータに範囲を固定します。次の表は試験計画の期待結果であり、実行済みの結果ではありません。
| 確認する条件 | 期待結果 | 異なる場合の対応 |
|---|---|---|
| 正規の閲覧主体が対象文書を読む | 許可された文書を取得できる | 分類と認可設定を再確認する |
| 同じ主体が範囲外の文書を読む | 拒否され、本文は返らない | 修正を採用せずアクセス範囲を見直す |
| 閲覧主体が文書更新を求める | 更新は拒否される | 広すぎる権限がないか調べる |
| 新しい診断ログを出力する | 認証情報の値が記録されない | ログ生成と前処理の双方を修正する |
| 処理結果を取得できない | 成功とせず未確認として残す | 管理者が要求と対象の状態を照会する |
正規の閲覧が一度成功しても、制限対象の閲覧や更新まで許可されたなら採用できません。秘密の検出が出たかだけでなく、分析入力、生成された報告、保存ログに秘密が再掲されないかも確認します。AIの「安全です」という評価は、これらの照合結果の代わりにはなりません。
承認者へ渡すのは、変更案と確認した範囲
担当者は承認者へ、対象環境、確認した原因、変更差分、試験条件と結果、残る未確認事項、戻し方を渡します。未実施の試験は「未実施」、証拠を取得できていない項目は「未確認」とし、同じ欄へまとめて合格にしません。この記事の試験は未実行例なので、実際の変更承認には実環境で得た証拠が別途必要です。
検証で合格しても、本番適用はこの案件の分析依頼に含まれません。本番の所有者が、適用対象、時間帯、依存サービス、監視と中止条件を確認する別の変更手続へ引き継ぎます。似たシステムへ転用するときも、検証環境での許可を別環境の操作許可へ読み替えないようにします。
もし実際の資格情報が外部へ渡った疑いが生じたら、通常の分析を続ける前に情報管理・事故対応の担当者へ伝えます。OWASPのSecrets Management Cheat Sheetは、露出した秘密の失効・更新や、ログの完全性を保った除去手順を扱っています。AI側の画面から文字を消しただけで、資格情報が無効になったとは考えません。対象の所有者が失効と利用履歴、保存先への影響を確認します。
案件の終了時には、分析用資料と試験用資格情報の扱いを保管方針に従って確定し、担当者と終了確認を記録します。対象、入力、権限、検証結果が追えることが、別案件へ応用するための前提です。AIに渡す情報を減らした分だけ診断が難しくなる場合は、秘密を追加で渡すのではなく、権限のある担当者が元資料を確認し、必要な事実だけを補います。
AIに渡したデータの保存先と削除までの管理は「AIに渡したデータはどこに残るか 分類から削除までの管理」、API・外部ツールの権限を最小にする点検は「API・外部ツール権限の最小化チェックリスト」で解説しています。
