公開AWSアクセスキー9,308件がなお有効　企業関連768キーはアカウントを全面制御可能

Truffle Securityは2026年8月19日、公開コード、コンテナイメージ、データセット、CIログなどから過去4年間に検出したAmazon Web Services（AWS）のアクセスキーを再検証した調査結果を公表しました。

同社は、2022年8月から2026年8月までに公開上で確認した431,875件のAWS認証情報の検出結果を、64,024個のユニークなアクセスキーペアへ重複排除しています。このうち、2026年8月10日時点で完全な認証情報が残っており再検証できた10,616キーの88％、9,308キーが依然としてAWSへ認証可能でした。

さらに9,308キーを分析した結果、817キーが企業に関連すると判定され、このうち526キーがAWSアカウントのrootアクセスキー、242キーがAWS管理ポリシーAdministratorAccessを持つIAMユーザーのキーでした。両者は重複しておらず、合計768キーについて企業のAWSアカウントを全面的に制御できる権限があるとTruffle Securityは報告しています。

ここでいう768は「768社」や「768個のAWSアカウント」を意味しません。同一企業から複数キーが確認された例もあり、あるグローバルコンサルティング企業では別々のアカウントから19キーが確認されたとしています。

また、この調査で確認されたのは「公開状態になった認証情報が現在も有効であること」と、そのキーが持つ権限です。第三者による実際の不正利用や情報流出が768件すべてで確認されたという意味ではありません。

公開AWSアクセスキー調査のサマリー

• 【確認済み】Truffle Securityは2026年8月19日、公開状態になったAWSアクセスキーの再検証結果を公表しました。
• 【確認済み】調査母集団は431,875件の公開上の検出結果で、重複排除すると64,024個のユニークなAWSアクセスキーペア、50,654のAWSアカウントに対応していました。
• 【確認済み】64,024キーは、公開コード、Git履歴、Hugging Faceデータセット、Dockerイメージ、パッケージレジストリ、CIログなどから2022年8月～2026年8月に検出されたものです。
• 【確認済み】2026年8月10日に完全な認証情報を再検証できた10,616キーの88％、9,308キーがなお認証可能でした。
• 【確認済み】有効だった9,308キーのうち817キーが企業関連と判定されました。
• 【確認済み】企業関連817キーのうち526キーがroot、242キーがAdministratorAccessを持つIAMユーザーに紐づき、重複しない768キーが企業AWSアカウントを全面制御可能でした。
• 【確認済み】残る企業関連49キーは管理者未満の権限でした。
• 【確認済み】AWS Organizationsの管理アカウントに紐づく有効なrootキーも130件確認されています。
• 【確認済み】作成日を取得できた2,903キーの中央値は1,831日、約5年でした。
• 【確認済み】2,903キーのうち、漏えいキーより新しいアクセスキーが同一ユーザーに存在したのは398件、13.7％でした。
• 【確認済み】有効なIAMユーザーキー7,590件のうち929件には、AWSが公開・侵害された認証情報に適用するAWSCompromisedKeyQuarantine系のポリシーが付与されていました。
• 【確認済み】Truffle Securityの検証は読み取り専用のメタデータAPIに限定され、実データ、ポリシー文書、リソース内容の読み取りや変更は行っていません。
• 【確認済み】再検証した10,616キーのうち10,260キーについて所有者を特定し、公開前に通知を進めたとしています。
• 【重要】「768キーが全面制御可能」は、「768社で不正アクセス被害が確認された」という意味ではありません。

項目	Truffle Securityの調査結果
公開上のAWS認証情報検出	431,875件
ユニークなAWSアクセスキー	64,024
対応するAWSアカウント	50,654
2026年8月10日に再検証できたキー	10,616
再検証時も認証可能	9,308（88％）
企業関連と判定された有効キー	817
企業関連のrootキー	526
企業関連のAdministratorAccessキー	242
全面制御可能な企業関連キー	768
管理者未満の企業関連キー	49
AWS Organizations管理アカウントの有効rootキー	130
作成日を取得できたキー	2,903
キー作成日の中央値	1,831日、約5年
より新しいキーが存在	398／2,903（13.7％）
AWSCompromisedKeyQuarantineが付与された有効IAMキー	929
所有者を特定して通知対象としたキー	10,260／10,616

64,024キーすべての88％が「現在も有効」ではない

今回の数字を扱う際に最も注意したいのが、64,024と10,616という2つの母数です。

Truffle Securityの詳細な調査本文によると、同社のスキャナーは過去4年間に431,875件のAWS認証情報を検出し、64,024個のユニークなAWSアクセスキーペアへ重複排除しました。

これら64,024キーは、発見された時点ではAWSへの認証が確認されたキーです。

その後、2026年8月10日に改めて再検証するため、アクセスキーIDとシークレットアクセスキーの完全な組み合わせを保持していた10,616ペアを抽出しました。

この10,616キーのうち88％、9,308キーが再検証時点でも認証可能だったというのが、詳細調査の正確な母数です。

Truffle Securityの製品発表やAWS Analyze紹介記事には「64,024 AWS keysをre-checkedし、88％がactive」と要約した表現もありますが、同社の詳細な研究方法では再検証対象を10,616キーとしています。

本記事では、より詳細な一次調査の方法論に基づき、「10,616キーを再検証し、9,308キーが有効」と整理します。

768キーが企業AWSアカウントを全面制御可能

Truffle Securityは、有効だった9,308キーについてAWSアカウントの連絡先情報やユーザー名のパターンなどから所有属性を分析し、817キーを企業関連と判定しました。

同社の定義では、AWSアカウントの連絡先に実在企業名がある場合、または一般的なWebメールではない組織ドメインが確認できる場合などを「Corporate」としています。

817キーの内訳は、

• rootキー：526
• AdministratorAccessを持つIAMユーザー：242
• 管理者未満：49

でした。

rootとAdministratorAccessの242キーは重複していないため、768キーが企業AWSアカウントを全面的に制御できる権限を持っていたとしています。

これは768社を意味しません。

Truffle Securityは、ソフトウェア、クラウド、ITコンサルティング企業に偏りが見られ、あるグローバルコンサルティング企業では複数AWSアカウントから19個の漏えいキーが確認されたとしています。

rootアクセスキー526件は特に重大

AWSのrootユーザーは、AWSアカウントにおける最上位の主体です。

AWS公式ドキュメントも、rootユーザーのアクセスキーを作成しないことを強く推奨しています。

IAMユーザーの場合はIAMポリシーで権限を絞れますが、rootユーザーはアカウントの最上位権限を持つため、rootアクセスキーの公開は影響範囲が極めて大きくなります。

Truffle Securityが過去4年間に確認した64,024ユニークキー全体では、10,625キー、16.6％がrootキーでした。

さらに今回再検証した有効キーの中には、AWS Organizationsの管理アカウントに紐づくrootキーが130件ありました。

Organizationsの管理アカウントは複数AWSアカウントを束ねる管理上の中心となるため、Truffle Securityはこうしたrootキーの露出について、単一アカウントより広い影響につながる可能性を指摘しています。

「84％が管理者」は全9,308キーの割合ではない

Truffle Securityの調査には「84％がAdministratorAccess」という数字も登場しますが、この数字にも母数の注意が必要です。

有効なIAMユーザーキー7,590件について、同社はアタッチされたAWS管理ポリシーやグループポリシーの名称を取得できるか試しました。

実際にポリシー情報を列挙できたのは1,157ユーザーです。

そのうち976ユーザー、84％がAdministratorAccessを直接、またはグループ経由で保有していました。さらに144ユーザーがIAMFullAccessを持っていました。

つまり、「有効なAWSキー9,308件の84％が管理者権限」という意味ではありません。

Truffle Security自身も、IAMポリシーを列挙できるユーザーは管理者や隔離対象ユーザーへ偏るため、84％という比率は方向性を示す数字として扱い、件数は正確だと説明しています。

セキュリティ調査の数字を引用する際は、権限を確認できたサブセットと全体母数を分ける必要があります。

5年以上前のアクセスキーが半数、86％はローテーションの痕跡なし

アクセスキーの作成日を取得できた2,903キーでは、作成からの中央値が1,831日でした。

約5年です。

このうち1,459キーは5年以上前に作成され、最も古いキーは17.4年前に作成されていました。

また、同じユーザーに「漏えいしたキーより新しいアクセスキー」が存在したのは398件、13.7％だけでした。

Truffle Securityは、残る約86％について、ローテーション、置き換え、削除が行われていない状態だったと評価しています。

AWSの公式ベストプラクティスは、可能な限りIAMユーザーの長期アクセスキーを使わず、IAMロールなどによる一時的な認証情報を利用することを推奨しています。

一時的な認証情報は有効期限を持つため、認証情報が意図せず露出した場合でも、手動で失効させるまで永続的に有効な長期アクセスキーよりリスクを抑えやすくなります。

AWSが侵害・公開を検知した929キーも認証可能なまま

今回の調査で注目されるのが、AWS側ですでに公開・侵害を検知されていたキーです。

有効なIAMユーザーキー7,590件のうち929件には、AWSのAWSCompromisedKeyQuarantine系ポリシーが付与されていました。

AWS公式ドキュメントによると、AWSCompromisedKeyQuarantineはIAMユーザーの認証情報が侵害または公開された場合にAWS側が適用するマネージドポリシーです。

このポリシーはIAMユーザー作成、アクセスキー作成、一部のEC2・Lambda操作など特定の危険なアクションを拒否し、潜在的な不正利用による被害を抑えることを目的としています。

Truffle Securityは、この929キーについて再検証時も「認証自体は可能」だったと報告しました。

ただし、ここで「認証可能」と「元の権限を制限なく利用可能」を混同してはいけません。

Quarantineポリシーが付与されたIAMユーザーでは、AWSが定義した一部アクションが拒否されます。AWS公式も、このポリシーを削除せず、サポートケースや通知メールに記載された手順に従うよう求めています。

Truffle Securityの指摘は、「AWSが検知・隔離措置を講じても、所有者側でキー自体を失効・ローテーションしなければ認証情報が残り続ける」という運用上の問題です。

112キーは少なくとも3年前から隔離対象

Truffle Securityによると、929キーのうち112キーには、AWSが2023年以降新規適用を停止した初期版のAWSCompromisedKeyQuarantineが付与されていました。

同社は、この112キーについて少なくとも3年前にはAWS側で露出が検知され、所有者へ通知されていたと推定しています。

それでも2026年8月10日時点で認証可能でした。

公開された認証情報について「検知した」「通知した」だけではインシデント対応は完了しません。

利用中のシステムへの影響を確認しながら、キーの無効化・交換、派生した一時認証情報の失効、利用履歴の確認まで完了する必要があります。

Hugging Faceが最大の単一流出源、8,482ユニークキー

64,024ユニークキーの調査母集団で、最大の単一ソースはHugging Faceでした。

Truffle Securityは、Hugging Face上の3,394個の公開データセットから8,482個のユニークなAWSキーを検証しています。

そのうち17.9％がrootキーで、同社が追跡する流出元の中で最も高いroot比率だったとしています。

ただし、この8,482という数字は今回8月10日に再検証した9,308キーの内訳ではなく、過去4年間にTruffle Securityが検出・検証した64,024キー全体におけるHugging Face由来の数字です。

同社が6月に実施した別調査では、Hugging Face上の公開データ7.6PB、約1億8,690万ファイルをスキャンし、3,343個のAWSキーがその時点でSTS認証を通過しました。

さらに907キーはS3バケット一覧を取得でき、メタデータ上、Public Access Blockが有効なS3領域だけで51.7TBが到達可能範囲として確認されています。

Truffle Securityは実際のS3オブジェクト名やデータ内容を読み取っておらず、容量や公開設定などのメタデータだけで検証しています。

AI学習データは「削除したはずの秘密」を再配布する

Hugging Faceの調査で重要なのは、認証情報の多くがデータセット公開者自身から直接漏れたものではない点です。

Truffle Securityによると、AWS、GCP、Azureなどのクラウド認証情報は、元のGitHubリポジトリ、Webページ、チャットログなどで一度公開された後、Webやコードを収集する学習コーパスへ取り込まれ、その派生データセットへ複製されるケースが確認されました。

6月の調査では、検証済みの秘密情報の44％が複数データセットに存在し、1つの認証情報が1,131個の公開データセットへ複製された例もありました。

このため、公開リポジトリから秘密情報を削除しただけでは対処として不十分です。

一度外部へ公開された認証情報はコピー済みと考え、必ず失効・ローテーションする必要があります。

セキュリティ対策Labでは、委託業者の個人GitHubリポジトリからAWS GovCloudの管理者認証情報などが公開されたCISAの事案を、CISA、自らの認証情報漏洩の教訓を公表で取り上げています。

CISA自身も、この事案を受け、漏えいした特定のキーだけでなく、関係者が管理者権限を持っていた環境の認証情報を広く再発行しました。

クラウドの被害は「データ漏えい」だけではない

有効なAWSアクセスキーが悪用された場合、影響はキーに付与された権限によって変わります。

管理者権限やroot権限であれば、クラウド上のデータ、サーバー、アプリケーション、IAM設定など広い範囲へ影響が及ぶ可能性があります。

また、クラウドでは攻撃者が大量のコンピューティングリソースを作成すると、被害企業側へ利用料金が発生する可能性もあります。

Truffle SecurityがBudget情報を読み取り可能だった2,754キーを確認したところ、何らかのBudget Alertを設定していたアカウントは262件、9.5％でした。

Cost Explorerを確認できた1,059キーの範囲では、2026年7月に50アカウントが1,000ドル超、9アカウントが1万ドル超を利用し、読み取り可能な集合の月間利用額は合計42万631ドルでした。

これは不正利用による請求額ではありません。通常のAWS利用額です。

一方、認証情報が悪用された場合に異常な計算資源利用を早期検知するうえで、予算アラートやコスト異常検知が補助的なシグナルになることを示しています。

AWSも2025年の公式Security Blogで、長期アクセスキーの露出がAWS Customer Incident Response Teamが観測するセキュリティインシデントで主要な初期侵入経路になっているとして、長期認証情報からIAMロール・フェデレーション・一時認証情報への移行を推奨しています。

公開されたアクセスキーは「削除」ではなく失効が必要

ソースコードやデータセットからアクセスキーを削除しても、そのキーが無効になるわけではありません。

Git履歴、フォーク、キャッシュ、コンテナイメージ、AI学習データなどにコピーが残っている可能性があります。

AWSは、アクセスキーを意図せず公開した場合について、

• その認証情報が何へアクセスできるか確認する
• 認証情報を無効化する
• 必要に応じて、そのキーから発行された一時認証情報も失効させる
• CloudTrailなどでアカウントへのアクセスを確認する
• 重要データの変更や永続化されたアクセスがないか確認する

といった対応を案内しています。

重要なのは、キーの交換だけでインシデント対応を終えないことです。

漏えいした長期認証情報から攻撃者が一時認証情報を発行していた場合、元のアクセスキーを交換しても、そのセッションが直ちに無効になるとは限りません。

また、不正なIAMユーザー、ロール、アクセスキーなどが作成されていないかも確認する必要があります。

情報システム・クラウド管理部門への示唆

今回の調査は、「アクセスキーを公開しない」という基本対策だけでは不十分であることを示しています。

企業では少なくとも次の4段階で管理する必要があります。

第一に、長期アクセスキーそのものを減らします。

AWSは人間ユーザーにIAM Identity Centerや外部IdPとのフェデレーションを利用し、ワークロードにはIAMロールを利用して、一時認証情報を使うことを推奨しています。

特にrootアクセスキーは原則として作成せず、既存のrootアクセスキーがある場合は必要性を確認して削除するべきです。

第二に、秘密情報の公開を継続的に検知します。

対象はGitHubだけではありません。

• Git履歴
• CI/CDログ
• Docker／OCIイメージ
• パッケージ
• 公開ドキュメント
• チャットログ
• AIへの入力
• 学習用データセット
• バックアップ
• 社員個人のリポジトリ

まで含めて考える必要があります。

第三に、「検知後に失効したか」を追跡します。

Truffle Securityの調査では、AWS側のQuarantineポリシーが付与されたキーであっても多数が認証可能な状態で残っていました。

アラートをチケット化しただけではなく、

「キーを無効化した」
「代替認証へ移行した」
「一時セッションを確認した」
「利用履歴を調査した」
「残存コピーを探索した」

までをクローズ条件にする必要があります。

第四に、認証情報の権限を最小化します。

漏えいそのものを完全にゼロにできなくても、IAMロール、最小権限、Permission Boundary、SCP、ネットワーク条件などを組み合わせれば、1つのキーが漏えいした際の影響範囲を小さくできます。

セキュリティ対策Labでは、AWS認証情報の悪用が実際のクラウド利用へつながった事例として、つくるAI、AWSアカウントへの不正アクセスで迷惑メール17.6万通を配信も取り上げています。

クラウドのアクセスキーは単なる「パスワードの一種」ではありません。

1つの長期キーがストレージ、計算資源、データベース、IAM、組織管理へ横断的な権限を持つ場合があります。

今回のTruffle Securityの調査で最も重い数字は、公開されたキーの数そのものではなく、「公開から数年経過しても認証可能で、企業アカウントを全面制御できるキーが残っていた」ことです。

出典

• 768 Leaked Corporate AWS Keys Held Full Admin Rights – Truffle Security
• Truffle Security launches TruffleHog AWS Analyze to reduce remediation time on leaked AWS credentials – Truffle Security
• Scanning 7.6 Petabytes of HuggingFace Training Data for Secrets – Truffle Security
• Security best practices in IAM – Amazon Web Services
• Secure access keys – Amazon Web Services
• Create access keys for the root user – Amazon Web Services
• AWSCompromisedKeyQuarantineV3 – Amazon Web Services
• Practical steps to minimize key exposure using AWS Security Services – AWS Security Blog
• What to Do If You Inadvertently Expose an AWS Access Key – AWS Security Blog
• CISA、自らの認証情報漏洩の教訓を公表 – セキュリティ対策Lab
• つくるAI、AWSアカウントへの不正アクセスで迷惑メール17.6万通を配信 – セキュリティ対策Lab