AI開発時代の多層防御を設計する〜AWSアクセスキーにまつわる怖い話〜

はじめに

こんにちは、3 月に Algomatic にエンジニアとして JOIN しましたぴやてぃと申します。

普段はフロントエンドからバックエンド、インフラまでフルスタックに開発していて、最近は Claude Code をはじめとする生成 AI ツールを活用しながら日々プロダクトを作っています。AWS が好きでいつかラスベガスに行きたいです。

前回の記事はこちら、三上さんによる「LeLab で始めるノーコード模倣学習」でした。人間にとっては簡単な動作も、ロボットが学習するには一苦労なんだな、というのがわかりとても勉強になりました。（最後のロボットの動画はなんだかかわいくて愛着が湧きました）

tech.algomatic.jp

今回は「初夏のアドベントカレンダー 20 日目」として、夏と言ったら怖い話、ということで、生成 AI で開発を進めていく会社にいるからこそ起きうる怖い話をしようかなと思います。

さてみなさん、AWS のアクセスキーどうしていますか？

個人で AWS を使っている人、個人のリポジトリにそのまま push したりしていませんか？

開発で使っている人、アクセスキーを最後に更新したのはいつですか？

アクセキーって普段あまり意識しないのですが、これが漏洩すると本当にやばいことが起きるんです。

そして厄介なことに、生成 AI を使ってコードを書くようになってこの「漏洩」の入口が一つ増えました。これまでは人間がうっかり認証情報をコミットしてしまうのが主な原因でしたが、いまは生成 AI が勝手にコードへ認証情報を混入させる、ということが起きるようになってきたのです。

しかもこれは「たまたま」ではありません。生成 AI は「一発で動くコード」を最短で出そうとするので、認証情報を環境変数やシークレットマネージャから読む正しい書き方より、そのままコードにベタ書きするほうを選びがちなのです。実際、GitHub Copilot の補完候補のうち3 回に 1 回ほどシークレットの構造を満たす文字列（API キーらしき値）が混ざっていたというGitGuardian の調査結果もあります。「人間のうっかり」だけでなく「AI の常習」として混入が起きる、というのが今の前提です。

とはいえ、生成 AI を使って開発を効率化したいですよね。私もそうです。

そこで大事になるのが、防御の仕組みをしっかり作っておくことです。具体的には「シフトレフト」と「監視設計」。この 2 つを生成 AI 時代の開発に合わせて設計しておくことが、安心して生成 AI に開発を任せるための前提になります。

1 章：API キーが漏れたら何が起きるの？

ある日、あなたは生成 AI にコードを組んでもらいました。サクッと動くコードが出てきて、いい感じです。

しかし、そのコードには AWS のアクセスキーがハードコーディングされていました。あなたはそれに気づきませんでした。

そのソースコードがそのまま Git に push され、あるいはデプロイされると、どうなるか。悪意ある攻撃者が、そのアクセスキーをすぐに抜き取ってきます。

もしもこのとき、AWS の権限が最小限に絞られていなかったら――つまり、そのキーで広い操作ができてしまう状態だったら、何が起きるでしょうか。

一番イメージしやすいのは、データを抜かれる情報漏洩でしょう。「いやでも、個人開発だし」「検証環境だから大した情報ないし」と思うかもしれません。

たしかに、扱っている情報次第ではダメージが小さく済むこともあります。でも、怖いのは情報漏洩だけではないのです。

漏れたアクセスキーを使って、攻撃者はあなたの財布（AWS アカウント）で計算資源を勝手に回すことがあります。

古典的なのが「クリプトジャッキング」と呼ばれる攻撃です。漏れたキーを使って、攻撃者があなたのアカウントの全リージョンに大量のサーバーを立て、仮想通貨のマイニングを走らせる。普段使っていないリージョンにまで展開されるので、気づいたときには手遅れ、ということが起きます。

被害額は、規模によっては数千万円に達することがあります。

最近では、この攻撃の「生成 AI 版」とも言えるLLMjackingも登場しています。漏れたキーで、被害者の費用でホスト型の LLM（Amazon Bedrock など）を勝手に呼び出す攻撃です。狙う対象がマイニング用のサーバーから LLM の推論に変わっただけで、「他人の財布で計算資源を回す」という本質はクリプトジャッキングとまったく同じです。

「でも AWS が返金してくれるんでしょ？」と思うかもしれません。

たしかに、不正利用が認められれば AWS はある程度の返金対応をしてくれます。ただし、100% 返ってくる保証はありませんし、そのためには「いつ・どのキーで・何が起きたのか」をきちんと調査して時系列で説明する必要があります。（実際やってみるとわかるのですが、結構大変な作業です…）

どうすれば防げたでしょうか？

ここで考えたいのは、「どの時点でこうなる未来を止められたか」です。

• AI がキーを埋め込んだ瞬間に気づけていたら？

• push される前に弾けていたら？

• 万が一漏れても、被害が広がる前に検知できていたら？

と言った感じで、防げるポイントはいくつかあります。

生成 AI に任せて爆速で開発するほど、人間の目視レビューは追いつかなくなるため、こうした防御を自動で・事前に効かせる仕組みが必要になってきます。次の章で具体的に見ていきましょう。

2 章：生成 AI 時代の多段防御設計

シフトレフト：発生源で弾こう

混入の発生源が AI に移った今は、コードが生まれる瞬間に防ぐことが大切です。こうして開発の早い段階（＝図でいう「左」）で問題を止める考え方をシフトレフトと呼びます。

シフトレフト自体は以前からある考え方で、できるだけ早い段階で問題を見つけよう、というものです。

本記事では、それをさらに一歩進め、AI がコードを生成する瞬間（プロンプト投入前・ツール実行前）まで検知を前倒しするという意味で用いています。

「左」側で止める必要があるのは、漏洩してからでは遅いからです。

GitGuardian の調査によると、公開された認証情報は中央値で 4 分未満で外部に発見されています。一方で、Verizon の 2025 DBIR（データ侵害インシデントレポート）によると、漏れたシークレットが修正されるまでには中央値で約 94 日かかるとされています。

具体的には、左から順に次のような防御ゲートを設置します。

(a) 生成の瞬間に弾く

まずは、AI がコードを書くタイミングです。

AI コーディングツールのフック機能を使えば、プロンプトを送る前やコマンドを実行する前にシークレットをスキャンできます。最近では ggshield の AI Hook のように、AI ワークフローへ組み込めるツールも登場しています。

(b) コミット前に弾く

次はコミット前です。

pre-commit フックでシークレットスキャンを実行します。gitleaks や TruffleHog などを使えば、git commit の時点で「API キーが混ざっていますよ」と止めてくれます。

開発者の手元で完結するので、開発体験を大きく損なわずに導入できるのもメリットです。

(c) CI で弾く

万が一ローカル環境をすり抜けても、CI（継続的インテグレーション）でシークレットスキャンや GitHub Secret Scanning / Push Protection を実行すれば、リモートリポジトリに到達する前に止められます。

「人間のレビューだけに頼らない」仕組みにしておくことがポイントです。

(d) IaC にセキュリティを焼き込む

インフラをコードで管理しているなら、そこにも防御を組み込めます。

AWS CDK や Terraform で、最小権限・長命なアクセスキーの禁止・IMDSv2 の強制といったルールを最初からコードに落とし込めます。

さらに、cdk-nag・tfsec・Checkov などを使えば、ポリシー違反をデプロイ前に自動で検知できます。最近では Amazon Inspector が SAST（静的アプリケーションセキュリティテスト）や IaC コードのスキャンを行ってくれるようになったので、これを使うのも選択肢の 1 つです。

aws.amazon.com

「人間が気を付ける」のではなく、「仕組みで守る」。生成 AI で開発する今は、この考え方がこれまで以上に重要になってきたと感じています。

万が一に備えて、監視もしっかりしよう

シフトレフトはとても強力ですが、それだけで完璧というわけではありません。

そのため、漏れた後の被害を最小限にする「右」の防御も必要です。1 章で見たように、漏れたキーはコストを急激に膨らませます。ここを早期に捕まえるのが監視の役割です。

コストアラートをかけておく

AWS も推奨していますが、Cost Anomaly Detection などで異常な課金の急増を検知できるようにしておきます。1 章のクリプトジャッキングや LLMjacking は、まさに「請求額が爆発する」攻撃なので検知しやすいです。

API コールと不審な挙動を監視する

CloudTrail で API コールを記録し、GuardDuty で不審なモデル呼び出しなどを検知します。「見覚えのないリージョンからのアクセス」「普段使わない API の呼び出し」あたりは要注意のサインです。

ここで、「どんな API コールが危ないのか」を見ておきましょう。クラウドへの攻撃の多くはマルウェアを仕込むのではなく、AWS の正規の API を順番に叩くだけで進みます。つまり攻撃の足跡はほぼすべて CloudTrail に残ります。見るべきポイントは、だいたい攻撃の流れに沿って 4 つです。

• ① 探索（Discovery）：侵入直後、攻撃者は「何ができるアカウントなのか」を調べます。GetCallerIdentity（自分が誰かの確認）、ListUsers / ListRoles / GetAccountAuthorizationDetails（権限の棚卸し）、DescribeInstances / ListBuckets といった List*・Describe* 系の短時間での連発が典型的なサインです。とくに見覚えのない IP からこれが来たら要注意。

• ② 権限昇格（Privilege Escalation）：次に、奪った権限をさらに広げにきます。AttachUserPolicy / PutUserPolicy（とくに AdministratorAccess のアタッチ）、UpdateAssumeRolePolicy、sts:AssumeRole あたりが代表格です。「自分自身に管理者権限を付ける」イベントは、ほぼ一発で危険信号と考えてよいです。

• ③ 永続化（Persistence）：一度入った経路を絶たれても戻れるよう、裏口を作ります。CreateUser → CreateAccessKey の連続実行、CreateLoginProfile、AddUserToGroup（管理者グループへの追加）などが該当します。

• ④ 証拠隠滅（Defense Evasion）：暴れる前にログを止める攻撃者もいます。StopLogging / DeleteTrail / UpdateTrail が該当するイベントになります。ログが消されたという事実そのものが、強いインシデントのサインになります。

これらに加えて、失敗した API コール（AccessDenied）も見逃せません。攻撃者が権限を探って総当たりしている最中は、アクセス拒否が大量に出ます。

これらの CloudTrail のイベントを EventBridge で受け取り、該当するイベント名だったら SNS や Slack へ通知すると気づきやすいです。Amazon Q を使って、CloudTrail の危険なイベントを Slack へ要約通知するのも選択肢の 1 つです。

全リージョンを監視する

攻撃は普段使っていないリージョンで起きることもあるため、監視は全リージョンにかけておくこと。一つのリージョンだけ見ていても、攻撃者は誰も見ていない場所を狙います。

可能なら最小権限を徹底する

仮にキーが漏れても、そのキーでできることが最小限に絞られていれば、被害も最小限で済みます。ただし、ここは開発スピードとトレードオフなので要検討です。

3章：まとめ

生成AIにコードを書かせる時代になって、シークレット混入の発生源が「人間のうっかり」から「AIの常習」へ変わりました。だからこそ、多層防御を設けることでセキュリティインシデントの発生を防ぐのが大事です。

• 左（シフトレフト）：発生源で弾く

AIが書いた瞬間・コミット前・CI・IaCの各ゲートで、シークレットや危険な設定を止める。

• 右（監視）：漏れても被害を抑える

コストアラート・CloudTrail・GuardDutyなどを使った監視で、漏れた後の被害を最小化する。

ただし、この辺りの設計は開発スピードとトレードオフになります。堅牢にすればするほど、アラートの確認や権限の問題で開発スピードが落ちてしまいます。

開発を始める前に、「今回はどこまで防御するか」をチームで話しておけるといいのかなと思います。

私は、こうした防御設計は、開発にブレーキをかけるためのものではなく、むしろ生成AIで爆速に開発するためのものだと思っています。

「漏らさない・漏れても広がらない」仕組みが自動で・事前に効いているからこそ、私たちは安心してAIにコードを書かせ、開発を進められます。防御がないまま走るのは、ブレーキのない車でアクセルを踏むようなものです。怖くて結局スピードは出せません。

生成AIで開発を加速させるために、防御の設計を最初にしっかりやっておくのが大切です。

参考文献

本文中でも触れていますが、参考にした主な情報源です。

• Yes, GitHub's Copilot can Leak (Real) Secrets - GitGuardian Blog

• The State of Secrets Sprawl 2025 - GitGuardian Blog

• 2025 Data Breach Investigations Report (DBIR) - Verizon

• LLMjacking: Stolen Cloud Credentials Used in New AI Attack - Sysdig

• The Growing Dangers of LLMjacking - Sysdig

• ggshield - GitHub

• gitleaks - GitHub

• TruffleHog - GitHub

• Push protection for repositories and organizations - GitHub Docs

• cdk-nag - GitHub

• tfsec - GitHub

• Checkov

• AWS CloudTrail User Guide - AWS Documentation

• Detecting unusual spend with AWS Cost Anomaly Detection - AWS Documentation

• What is Amazon GuardDuty? - AWS Documentation

• Security best practices in IAM - AWS Documentation

• MITRE ATT&CK

エンジニアを募集しています！

ここまで読んでいただきありがとうございました！

Algomatic では6月に体勢が変わり、「AI時代の企業OSを作る」という新しいミッションに向かって一緒に走っていけるエンジニアを募集しています。

もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！

recruiting.algomatic.jp