EC2に「アクセスキー」は眠っていませんか？流出事案に学ぶ構成見直しリスト

はじめに

こんにちは、クロスインダストリー第2本部クラウド活用推進課の岡野です。

先日、私が担当させていただいているお客様の環境において、AWSのアクセスキーが外部へ流出するという事案が発生しました。まず誤解のないよう冒頭に申し上げますが、本件は弊社の管理不備によるものではなく、またお客様自身も何か悪意を持って情報を漏洩させたわけではありません。しかし、どれほど注意を払っていても「事故」は起こり得るものです。

この事象がある程度収束した直後、私のX（旧Twitter）で投稿した内容がこちら。

アクセスキー、まじローテしてくださいね…！！ほんと…！
— Yuhi Okano / 岡野雄飛 (@yuhi6240) 2026年3月13日

本稿執筆時点で3万件以上のインプレッションがあり、いかに多くの企業や担当者が「明日は我が身」としてセキュリティインシデントに関心を持っていらっしゃるかわかりますよね。本記事では、事象発生から収束、そして再発防止策の策定に至るまでをまとめます。

はじめに
2026年3月13日：AWSからの緊急通知
- AWSが提示する「復旧への4ステップ」
攻撃のプロファイル：犯人は何を狙ったのか
- 「権限の壁」がもたらした恩恵
なぜ流出は起きたのか：テクニカルサポートの分析
再発防止に向けた「3段階の再発防止アプローチ」
おわりに

2026年3月13日：AWSからの緊急通知

事象の始まりは、AWSからの「アウトバウンドケース（不正利用や認証情報流出の疑い）」の起票でした。AWSは、公開リポジトリへのキーの露出や、異常なAPI呼び出しを検知すると、アカウント管理者へ通知を送ります。

この通知を検知し弊社内でエスカレーションを受け、お客様へ連絡を開始。リソースの操作権限を持たない立場において、私の使命は「迅速にお客様を正しい復旧手順へ導くこと」です。

即座にお客様の緊急連絡先へ電話を入れ、同時にAWSから提示された以下の「リカバリ4ステップ」を、お客様が迷わず実行できるよう整理して案内しました。

AWSが提示する「復旧への4ステップ」

AWSからのアウトバウンドケースには以下のように記載されています。

キーの交換と無効化：公開されたキーを即座に「非アクティブ」にする（いきなり削除するとアプリが止まって復旧不能になるため、まずは無効化に留める）。
CloudTrailログの確認：承認されていないIAMユーザーや、意図しないリソース（EC2やLambda）が作成されていないかを確認する。
不要なリソースの削除：全リージョンを横断して、攻撃者が作成したリソースがないか、請求コンソールと各サービスページを照らし合わせる。
セキュリティ確保の報告：手順完了後、AWSサポートへ報告し、アカウントの制限解除を依頼する。

この時、お客様に「どこをどう見ればいいのか」を具体的にお伝えできたことが、被害の拡大を防ぐ初動として機能しました。

攻撃のプロファイル：犯人は何を狙ったのか

AWS CloudTrail のログを精査したところ、流出したアクセスキーを用いた以下の不正操作の試行が確認されました。分析の結果、攻撃者は以下の2点を主目的としていたことが判明しました。

SES（メール送信基盤）の悪用：スパムメールを大量に配信するための踏み台として、SESのクォータ（送信上限）を確認し、送信を試みようとしていました。
EC2（仮想サーバー）の乗っ取り：稼働中のインスタンスに対し、SSH等で侵入を試みていた。

「権限の壁」がもたらした恩恵

なぜ防げたのか。

それは、流出したアクセスキーに紐づくIAMユーザーに対し、「その業務に必要最小限の権限（Least Privilege）」しか割り当てていなかったからです。「管理が楽だから」と安易に「FullAccess」を付与せず、運用の基本に忠実であったことが、首の皮一枚でアカウント全体の崩壊を防いだ結果となりました。

なぜ流出は起きたのか：テクニカルサポートの分析

弊社のテクニカルサポートに伺った所、流出経路として以下の可能性があると推察されていました。*1

バージョン管理システム（GitHub等）への誤コミット： .env ファイルなどの環境設定ファイルを誤ってパブリックリポジトリに公開してしまった。
ソースコードへの直書き：プログラム内に直接キーを埋め込み、そのまま共有範囲の広い場所へアップロードしてしまった。
外部公開サーバーの設定不備：ウェブサーバーの設定ミス等により、意図せず設定ファイルが外部から閲覧可能な状態になっていた。

コンソールのパスワード総当たり（ブルートフォース攻撃）による正面突破の可能性は低いという見解です。つまり、「技術的な脆弱性」よりも「運用の慣習」に起因する事故であった可能性が高いと見ています。

再発防止に向けた「3段階の再発防止アプローチ」

この事案を通じて、私はお客様へ（そしてこの記事を読んでいる皆様へ）、AWS Well-Architected フレームワークの「セキュリティの柱」に基づいた3段階の対策を強くおすすめいたします。

【提言1】理想：アクセスキーを「持たない」設計への移行

今回のキーは、EC2内部のアプリケーションで使用されていました。しかし、AWSのベストプラクティスでは、EC2内でアクセスキーを使うことは推奨されていません。

AWS Identity and Access Management ユーザーガイドより抜粋

可能であれば、アクセスキーなどの長期的な認証情報を作成する代わりに、一時的な認証情報を使用することをお勧めします。

「IAM ロール（インスタンスプロフィール）」を使えば、サーバー内に永続的なキーを保存せず、一時的な認証情報を自動的に利用できます。

「コードの書き換えが大変ではないか」という懸念をよく伺いますが、AWS SDKを利用していれば、認証情報の参照優先順位（Credentials Provider Chain）の仕組みにより、プログラム自体を修正することなく、キーを削除してロールを付与するだけで移行できるケースがあります。

公式ドキュメント参考：AWS SDKs and Tools standardized credential providers

All SDKs have a series of places (or sources) that they check in order to find valid credentials to use to make a request to an AWS service. After valid credentials are found, the search is stopped. This systematic search is called the credential provider chain.

When using one of the standardized credential providers, the AWS SDKs always attempt to renew credentials automatically when they expire. The built-in credential provider chain provides your application with the ability to refresh your credentials regardless of which provider you are using in the chain. No additional code is required for the SDK to do this.

日本語訳：すべてのSDKには、AWSサービスへのリクエストに使用する有効な認証情報を見つけるためにチェックする一連の場所（またはソース）があります。有効な認証情報が見つかると、検索は停止します。この体系的な検索は、認証情報プロバイダーチェーンと呼ばれます。

標準化された認証情報プロバイダーのいずれかを使用する場合、AWS SDK は認証情報の有効期限が切れると常に自動的に更新を試みます。組み込みの認証情報プロバイダーチェーンにより、チェーン内でどのプロバイダーを使用しているかに関わらず、アプリケーションは認証情報を更新できます。SDK がこれを行うために追加のコードは必要ありません。

【提言2】キーを廃止できない場合の「リスク緩和策」：自動ローテーションの導入

理想はアクセスキーを全廃することですが、サードパーティ製のSaaSとの連携や、どうしてもIAMロールに対応できないレガシーな外部システムなど、現実には「どうしてもキーを発行せざるを得ない」ケースが存在します。

その際、最も避けるべきは「一度発行したキーを数年間使い続ける」ことです。アクセスキーは、いわば「有効期限のないパスワード」。もし1年前に漏洩していたとしたら、攻撃者は1年間、いつでもあなたの環境に侵入できることになります。

そこで導入を検討したいのが、AWS Secrets Manager 等を活用した「キーの自動ローテーション」です。

「90日」という期限の根拠：多くのセキュリティ基準（PCI DSSなど）では、90日以内のパスワード変更を求めています。万が一、キーが流出したとしても、自動更新される仕組みがあれば、攻撃者がそのキーを使える期間を強制的に「最大90日間」に限定できます。いわば、被害の「被害期間の切り出し」を行うわけです。
手動運用の限界を突破する：「3ヶ月に1回、手動でキーを更新してアプリを再起動する」という運用は、ほぼ確実に形骸化します。担当者の交代や作業漏れが発生し、結局「動いているから触らない」という放置状態に陥るからです。
Secrets Managerによる「疎結合」な管理：Secrets Managerを使えば、アプリケーションはAWSに対して「今の最新のキーを教えて」とAPI経由で尋ねる形になります。これにより、キーが裏側で自動更新されても、アプリケーション側の設定を毎回書き換える必要がなくなります。

「キーを捨てられない」のであれば、せめて「キーを常に新しく保つ仕組み」をインフラ側に組み込む。これが、現実的な運用における強力なガードレールとなります。

【提言3】被害範囲の最小化：権限の絞り込みと異常検知の徹底

キーの廃止も、自動ローテーションの導入もすぐには難しい。そのような状況であれば、せめて権限の見直しだけはご検討ください。

今回の事案では、攻撃者がSESを利用したスパム配信やEC2の乗っ取りを企図していましたが、結果として初期段階で阻止されました。これは、対象のアクセスキーに紐づくIAMユーザーに、業務上不要な権限（AdministratorAccessなど）を与えず、権限を最小限に絞り込んでいたことが最大の要因です。

また、あわせて Amazon GuardDuty を有効化し、不審なIPアドレスからの操作を自動検知する仕組みを整えることも重要です。万が一キーが悪用された際に、即座に異常を検知して初動を早める体制があれば、被害を最小限に抑えることが可能になります。

おわりに

アクセスキーの管理は、どれほど注意していてもリスクをゼロにすることは困難です。しかし、今回の対応を通じて改めて思ったのは、「運用の仕組み（アーキテクチャ）で、ヒューマンエラーが致命傷にならない状態を作る」ことの重要性です。

こうした「冷や汗をかく経験」を、単なる事故で終わらせるのではなく、より安全なクラウド活用のための「糧」に変えていく。それこそが、私たちがお客様に提供できる最大の価値だと考えています。

今後も、お客様が「安全に、かつ安心して」AWSの恩恵を享受できるよう、ベストプラクティスに基づいた伴走支援を続けて参ります。

*1:恐らくそうではないか、という推察です