オンコール対応や本番環境の緊急オペレーションを担当しているエンジニアに向けた内容です。深夜のアラート対応中に届く「至急」の連絡が、実は生成AIによる標的型フィッシングだったらどうなるでしょうか。SRE（サイト信頼性エンジニアリング。システムの可用性や運用品質を工学的に管理する役割）の現場は、この種の攻撃にとって好条件が揃っています。判断を急がせる文化と、Slackやパニックボタン的なエスカレーションフローが常態化しているためです。今回はその落とし穴と具体的な対策を整理しました。
何が起きるか：オンコール対応そのものが攻撃対象になる
従来のフィッシング対策研修は「不自然な英語」「汎用的な挨拶」「怪しい送信元アドレス」を見抜く訓練が中心でした。ところが大規模言語モデル（LLM。大量のテキストを学習し自然な文章を生成するAI技術）の普及によって、この見分け方はほぼ意味を失いました。
LLMを使えば、攻撃者は数秒で文法的に完璧な文面を大量生成できます。人間のアナリストが半日かけて作る標的型メールと同等の精度を、瞬時に複数パターン用意できるということです。
さらに深刻なのは音声クローンです。ポッドキャストやカンファレンス動画から30秒程度の音声を抽出するだけで、本人そっくりの声色・抑揚・話し方を再現できます。SREの現場に置き換えると、次のようなシナリオが現実味を帯びます。
- オンコール担当者に「本番DBのアクセスキーを再発行してSlackで共有してほしい」という、上長そっくりの声で緊急電話がかかる
- インシデント対応中のチャンネルに、実在するベンダー名を騙り「復旧のため一時的にIAMロールの権限を昇格してほしい」というチケットが投稿される
- CI/CDパイプラインの障害対応時に、社内の情報システム部門を装い「認証情報をこのフォームに入力してください」という誘導リンクが送られる
どれも文面や口調に不自然さがありません。攻撃者は自動化されたOSINT（オープンソースインテリジェンス。公開情報を収集・分析する手法）でLinkedInや社内Wikiから実在のプロジェクト名や同僚の名前を拾い、文脈に織り込んできます。
なぜ起きるか：SREの業務プロセスが「緊急性」を前提にしているため
原因を段階的に分解すると、技術的な脆弱性ではなく運用プロセスの構造的な弱点が見えてきます。
第一に、インシデント対応は「スピード優先」で設計されています。SLO（サービスレベル目標。可用性やレイテンシなどの目標値）の違反が続くと、MTTR（平均復旧時間）を縮めることが最優先になり、承認フローを一時的にスキップする運用が許容されがちです。攻撃者はこの「緊急時は例外処理が通る」という前提を悪用します。
第二に、オンコールの連絡経路が分散しすぎています。PagerDuty、Slack、電話、SMSなど複数チャネルを併用している組織では、どのチャネル経由の依頼を信用してよいかの基準が曖昧なままになっているケースが少なくありません。
第三に、IaC（Infrastructure as Code。TerraformやPulumiなどでインフラ構成をコードとして管理する手法）の運用において、緊急変更を手動apply（コードの変更をインフラに適用する操作）で行う「割れ窓」的な運用フローが残っている場合、攻撃者がその手動apply権限を狙って社会工学的にアクセスを取得しようとする余地が生まれます。
第四に、オブザーバビリティ（システムの内部状態を外部から観測できる仕組み。ログ・メトリクス・トレースの3本柱で構成される）のツールに対する認証情報が、個人のパスワードマネージャーや共有Slackチャンネルにベタ書きされている場合、音声フィッシングで一言聞き出されるだけで突破されてしまいます。
自分のプロジェクトが該当するか確認する
次の観点で、自組織のインシデント対応フローを点検してみてください。
- 緊急時の例外承認ルート：
runbook（障害対応手順書）やincident-response.mdに「緊急時はSlack DMのみで権限昇格を承認可」といった記述がないか確認します - オンコール連絡手段の正本化：PagerDutyやOpsgenieの設定画面で、エスカレーションポリシーに登録された連絡先が「公式に登録された番号・アカウントのみ」に限定されているか確認します
- IaCのapply権限：
terraform state listやpulumi stackのアクセス権限を確認し、緊急時に誰が手動applyできるか、その承認記録が残る仕組みかチェックします - シークレット管理：Vault、AWS Secrets Manager、GCP Secret Managerなどを使わず、Slackやメールに認証情報が平文で流通していないかgrepしてみます
- 監査ログの有無：CloudTrailやGCP Audit Logsで、過去の緊急対応時にIAM権限が変更された履歴を遡り、承認プロセスを経ずに変更された記録がないか確認します
該当する項目が1つでもあれば、次の対策を検討する価値があります。
対策の手順：プロセスをゼロトラスト化する
人間の注意力に頼る防御はもう機能しません。ここでは仕組み化できる対策を順番に示します。
1. コールバック検証ルールをrunbookに明記する
権限昇格や振込先変更、緊急のシークレットローテーションなど「重大な操作」については、依頼を受けた経路とは別の、事前登録済みの連絡先で必ず本人確認する運用を明文化します。音声クローンやSlackなりすましは、この「別経路での確認」だけで無効化できます。
# runbookに明記する例（Markdown断片）
## 緊急権限昇格の承認フロー
1. 依頼を受けたチャネル（Slack/電話/SMS）では即時対応しない
2. PagerDutyに登録された正規の電話番号へこちらから発信し口頭確認
3. 承認者は必ずオンコール表に記載された当番のみ
4. 承認記録をIncident管理チケットに残す2. IaCの緊急変更を承認必須のパイプラインに寄せる
手動applyを許容している場合、緊急時こそCI/CD経由の承認フローに寄せる方が安全です。TerraformであればAtlantisやTerraform CloudのRun承認機能を使い、Pulumiであればpulumi up --diffの内容を必ずレビュー者が確認してからマージする運用にします。緊急変更用の専用ブランチとレビュアーを事前に決めておくと、パニック状態でも手順から外れにくくなります。
3. オブザーバビリティで異常な承認パターンを検知する
メトリクスやログに「誰が」「いつ」「どの経路で」権限変更を承認したかを記録し、Grafanaなどのダッシュボードでアラート化します。深夜帯・休日・普段と異なるIPからの承認リクエストが急増していないか監視することで、攻撃の兆候を早期に拾えます。
4. 障害対応訓練にソーシャルエンジニアリングのシナリオを組み込む
誤字脱字を探す訓練はもう時代遅れです。代わりに、実際のインシデント対応演習（ゲームデー、カオスエンジニアリング訓練）の中に「なりすまし電話がかかってくる」「Slackに偽の緊急チケットが投稿される」といったシナリオを混ぜ、コールバックルールが実際に守られるかを検証します。
5. コストと運用負荷のバランスを取る
全ての操作にコールバック検証を義務付けると、MTTRが悪化しSLO違反を招きかねません。影響範囲の大きい操作（本番DBの権限、支払い関連、IAMのroot相当の変更）に限定してルールを適用し、それ以外は既存の自動化フローを維持するなど、優先度に応じた線引きが現実的です。
まとめ
生成AIによって、文面や声だけで真偽を見抜く時代は終わりました。SREやインフラ担当者がまず確認すべきは、次の3点です。
- runbookに緊急時の例外承認ルートが明記されているか、独立した経路でのコールバック検証が組み込まれているか
- IaCの緊急変更が手動apply任せになっておらず、承認フローと監査ログが残る仕組みになっているか
- インシデント対応訓練にソーシャルエンジニアリングのシナリオが含まれているか
まずは自組織のrunbookを開いて、緊急時の承認フローに「別経路での本人確認」が一行でも書かれているか確認してみてください。書かれていなければ、それが最初に埋めるべき穴です。