流出したAWSアクセスキー、数千件が今も有効な状態に

研究者らが、今も有効に機能する流出済みのAWSアクセスキーを数千件発見しました。その中には、企業アカウントへの完全な管理者権限を持つものが数百件含まれていたということです。

Truffle Securityは、64,024個のユニークなAWSアクセスキーを含む431,875件の公開情報を分析し、この結果にたどり着きました。研究者らが再確認した10,616件の完全なキーペアのうち、9,308件が依然としてAWSでの認証に成功しました。有効なキーの数自体は当初の件数と比べると少数ですが、リスクの本質は、たった1件でも流出した有効なキーが悪用された場合にどれだけの権限を与えてしまうかという点にあります。

この調査は、攻撃者がこれらの認証情報を実際に利用したことまでは立証していません。しかし、単に情報が流出しただけではリスクがそこで終わらないことを示しています。流出したキーは、そのコピーがさまざまなパイプラインに拡散していく過程で有効なまま残り続けることがあり、かつての開発者のミスが長期にわたるクラウドセキュリティ上のリスクへと変貌してしまうのです。

流出したAWSキーの数千件が今も機能

研究者らは、GitリポジトリやGit履歴、Dockerイメージ、パッケージレジストリ、CIログ、公開データセットなどから公開されていた431,875件の資料を分析しました。

この分析により、64,024個のユニークなAWSアクセスキーが特定されました。研究者らは2026年8月10日に10,616件の完全なキーペアを再検証し、その88%が依然としてAWSでの認証に成功することを確認しました。

より深刻な発見は、それらのキーの一部が何にアクセスできてしまうのかという点でした。

有効な認証情報のうち817件が企業に紐づいており、そのうち526件はルートアクセスキー、242件はAWSの管理者アクセスポリシーが付与されたIAM認証情報でした。つまり、企業に紐づく768件のキーが、当該AWSアカウントへの完全な管理者権限を持っていたことになります。

作成日を取得できた有効なキー2,903件について見ると、キーの年齢の中央値は約5年で、最も古いものは17.4年前に作成されたものでした。

流出したAWSキーが何年も有効なまま残る理由

AWSアクセスキーは、公開状態で流出したからといって自動的に無効化されるわけではありません。誰かが明示的に失効させない限り、これらのキーは有効なままです。

この事実は、認証情報のライフサイクル管理が破綻していることを物語っています。企業がリポジトリからシークレットを削除したり、別のキーに切り替えたり、アプリケーションを廃止したりすることはあっても、それらの行為が必ずしも元のキー自体の失効を意味するわけではないのです。

Truffle Securityが、AWSのAWSCompromisedKeyQuarantineポリシーが付与された認証情報の中にも有効なものを発見したという点は、特に示唆に富んでいます。AWS自身が一部の認証情報を「侵害済み」と識別していたにもかかわらず、そのキーは依然として存在し、認証を通過できてしまっていたのです。

ここには可視性の問題と、社内ポリシーの問題も絡んでいます。組織では時間の経過とともに古いIAMユーザーが蓄積されていきますが、その認証情報の所有者がすでに誰もいない場合、それが今も有効かどうか、あるいは当初付与された権限を今も本当に必要としているかどうかをチェックする人間自体が存在しない可能性があります。

これが、作成から5年が経過したシークレットが、それを生み出したシステム自体が完全に変わってしまった後でも、技術的には有効なまま残り続けてしまう理由の説明になります。

教訓はAWSにとどまらない

今回の調査はAWSアクセスキーに焦点を当てたものですが、そこから得られる認証情報管理の教訓は、より広範に当てはまります。同様の過ちは、APIキーやデータベース認証情報から、SaaSプラットフォームで使われるトークンに至るまで、あらゆるものに起こり得ます。

組織のインフラのより多くの部分がクラウドへと移行するにつれて、このリスクは抑え込むのが一段と難しくなりつつあります。今回の調査で単一の情報源として最大だったのはHugging Faceで、3,394件の公開データセットにまたがり8,482個のユニークな有効AWSキーが発見されました。

AIエージェントやインテグレーションにサービスIDが付与され、MCPサーバーやクライアントが利用する認証情報、そしてクラウドリソースやデータベースその他のサービスへのアクセス権限が広がっていくのに伴い、同じ問題はさらに深刻な意味を持つようになります。

長期間有効な認証情報は、可能な限り短命な認証情報やロールベースのアクセス制御に置き換えるべきです。

流出したキーは、ソースコードから単に取り除くだけでなく、直ちに失効または再発行すべきです。また、組織はGit履歴や公開されている成果物のスキャンを行い、明確な認証情報ポリシーを維持するとともに、不審な活動を検知するためのログ記録や課金アラートも活用すべきでしょう。

目指すべきゴールはシンプルです。今日流出した認証情報が、5年後になっても同じ「扉」を開けられる状態であってはならない、ということです。

関連記事: AI主導のAWS攻撃が示す、流出した認証情報がわずか10分足らずで完全な管理者アクセスにつながる実態。攻撃者にアクセス権限をエスカレートされる前に、セキュリティチームが流出したキーを失効させておくべき理由を改めて浮き彫りにしています。