漏えいしたAWSアクセスキー、9,300件超が数年後も有効だった

公開されたAWS認証情報は、一時的な事故で終わるとは限らない。Truffle Securityが2022年8月から2026年8月にかけて行った調査では、漏えい後も何年にもわたって有効なキーが多数残り、企業のAWSアカウントを完全に掌握できる権限を持つものも確認された。

公開されたキーの88％が再認証に成功

Truffle Securityは、公開コードリポジトリ、Gitの履歴、データセット、Dockerイメージ、コンテナレジストリ、継続的インテグレーション（CI）ログなどから、AWSシークレット431,875件を収集した。重複を除くと、一意のAWSアクセスキー64,024件、50,654のAWSアカウントに相当する。

このうち完全なキーの組み合わせを確認できたのは10,616件。8月10日に再検証した結果、88％がなお認証に成功し、9,300件を超える公開済みキーが使用可能な状態だった。

公開リポジトリにキーが存在するだけで、必ずしも現在も危険とは限らない。実際のリスクになるのは、キーが失効しておらず、認証に使え、重要な権限を保持している場合だ。今回の調査では、この3つの条件が重なったケースが少なくなかった。

企業アカウントを完全に操作できるキーは768件

有効なキーのうち、企業のアカウントに紐づくと判断されたものは817件だった。その内訳は次の通り。

• AWSルートアカウントのキー：526件
• AWSのAdministratorAccessポリシーが付与されたIAMユーザーのキー：242件
• 企業のAWSアカウントを完全に管理できるキー：合計768件

ルート認証情報は、AWS利用者が持ち得る最も高いレベルの権限にあたる。一方、AdministratorAccessを持つIAMユーザーも、AWSの幅広いサービスをほぼ制限なく操作できる。

このレベルのキーが有効なら、アカウントの乗っ取り、リソースの不正作成、データへのアクセス、クラウド料金の不正利用などにつながる可能性がある。

つまり問題は、ソースコードから秘密情報を消し忘れたという単純な話ではない。キーをファイルから削除したりGitの履歴を書き換えたりしても、すでにコピーされた認証情報は無効にならない。必要なのは、キーそのものの失効またはローテーションだ。

最大の個別流出元はHugging Face

個別の流出元として最も多かったのは、機械学習用データセットなどを公開するプラットフォームのHugging Faceだった。AWS認証情報の露出は8,482件に上り、そのうち17.9％がルート認証情報だったとTruffle Securityは報告している。

同社はHugging Face上の公開データ全体を対象に、7.6ペタバイトをスキャンした。AWSキーに限らず、公開データセットに有効な認証情報が残り続け、一般に配布されるデータへ流れ込む可能性を示す結果だ。

セキュリティ担当者にとっての教訓は明確だ。現在のソースコードリポジトリだけを調べても不十分である。Gitの過去履歴、ビルド成果物、コンテナイメージ、レジストリ、公開データセット、CIの出力ログも、開発者が削除したつもりの認証情報を保持している可能性がある。

キーの中央値は約5年前、ローテーションも少数

報告された認証情報の年齢の中央値は約1,831日、約5年だった。最も古いキーは17.4年前のものだった。さらに、同じユーザーに新しいキーが紐づいていたのは**13.7％**にとどまり、多くが通常のローテーションで置き換えられていなかったことを示している。

長期間使えるアクセスキーは、不正利用の機会を広げる。担当者の異動、アプリケーションの移行、リポジトリの整理、運用担当の変更を経ても残り続けるため、誰が所有し、何に使われているのかを追跡しにくくなる。

数年前のキーだからといって、古くて無効だと決めつけるのは危険だ。公開されたキーは、所有者が無効化を確認できない限り、現役の侵害情報として扱い、失効・調査する必要がある。

予算アラートを設定していたアカウントは少なかった

Truffle Securityがアカウント情報を読み取れたのは2,754アカウントだったが、AWSの予算アラートを設定していたのは262アカウントだけだった。

予算アラートは、キーの失効や脅威検知の代わりにはならない。それでも、暗号資産のマイニングなどで高額なリソースが作られた場合に、早期警告として機能する。異常な支出を知らせる仕組みがなく、通知を受け取って対応できる担当者も決まっていなければ、侵害後も不正利用が続くおそれがある。

AWSの通知だけでは問題は解決しない

報告によると、AWSには漏えいしたアクセスキーを検知し、影響を受ける顧客へ通知し、制限や隔離措置を適用する保護機能がある。 しかし、今回これほど多くのキーが再び有効と確認されたことは、検知や通知が顧客側での迅速な失効・ローテーションに必ずしも結びついていなかったことを示唆する。

検知は認証情報対応の第一歩にすぎない。完全な対応には、所有者の特定、アクセス可能な範囲と権限の確認、不正利用の調査、キーの無効化が必要になる。

Truffle Securityは、自社の検証は読み取り専用で、認証の成否や権限・アカウントのメタデータを確認しただけで、顧客リソースを変更していないと説明している。ただし、この方法の運用上の詳細すべてが、今回提供された各情報源によって独立に裏付けられているわけではない。この点は、Truffle Security側の説明として受け止めるべきだ。

AWSキーが漏えいした場合に組織が取るべき対応

1. 直ちに失効またはローテーションする

公開された認証情報は、まず削除・無効化する。継続利用が必要な場合に限り、新しいキーを発行する。リポジトリから秘密情報を消す、ファイルを削除する、Gitの履歴を書き換えるといった対応だけでは、すでに流出したコピーを無効にできない。

2. ルートアクセスキーをなくす

AWSのルートユーザー用アクセスキーを、日常的なプログラム処理に使ってはならない。ルートキーは削除し、必要な権限を管理できるIAMロールなどへ移行する。

3. 権限と所有者を確認する

そのキーがどのアカウント、ユーザー、サービス、リソースに属していたのかを特定する。ルート権限、AdministratorAccess、広範なデータアクセス権、インフラを作成できる権限を持つキーから優先して確認する。

4. 失効前後の利用状況を調べる

認証ログ、AWS CloudTrailの記録、IAMの変更、新たに作成されたリソース、請求情報を確認し、不審な活動がないか調べる。キーを失効させれば今後の利用は止められるが、過去に悪用されたかどうかまでは分からない。

5. 長期キーを短期認証へ置き換える

可能な限り、恒久的なアクセスキーではなく、短期間だけ有効なIAMロールやワークロードIDを使う。最小権限の設計にすれば、認証情報が漏れた場合の被害も抑えられる。

6. 予算アラートと対応経路を設定する

AWS Budgetsのアラートとコスト異常検知を設定し、すぐに対応できる担当者へ通知を届ける。金銭面の監視は、シークレットスキャン、キーのローテーション、権限レビューを補う安全網であり、それらの代替ではない。

問題の本質は「漏えい」だけではない

今回の調査で特に重いのは、単なるシークレットの件数ではない。公開状態、認証の継続、高い権限、極端な長寿命、監視不足が同時に存在していた点だ。

公開データの中には、組織がどこで使っていたか忘れた認証情報が長期間残る。一方、コピーされたキーは明示的に失効されるまで使える可能性がある。

クラウドを運用する組織が取るべき前提はシンプルだ。公開されたAWS認証情報はすべて侵害されたものとして扱い、到達可能な範囲と権限を確認する。そのうえで直ちに失効またはローテーションし、長期アクセスキーを短期・最小権限のIDへ置き換えるべきである。