AWS IAM キー露出への対応：GitHub からのリーク 10秒後に完了する検出と封じ込め

AWS Automatically Quarantines Exposed IAM Keys Within 10 Seconds of GitHub Leak

2026/09/21 CyberSecurityNews — Amazon Web Services (AWS) は、Identity and Access Management (IAM) のアクセスキーが公開 GitHub リポジトリに露出した場合、検出から封じ込めまでを数秒で完了できる。Unit 42 が実施した管理下での認証情報露出テストでは、研究者が認証情報を公開してからわずか 10 秒後に、影響を受ける IAM ユーザーに対してマネージド・ポリシー AWSCompromisedKeyQuarantineV3 が適用され、攻撃者が認証情報を悪用できる時間が大幅に短縮された。

長期間有効な IAM アクセスキーは、対話型の認証を必要とせずプログラムからアクセスできるため、依然として攻撃者にとって有力な初期アクセス経路となっている。また、開発者が誤って、ソースコード／設定ファイル／外部公開された環境ファイルにアクセスキーをコミットする可能性もある。

GitHub のシークレット・スキャンは、公開リポジトリなどの公開領域から既知の認証情報パターンを検索し、パートナー連携を通じて検出した AWS のシークレットを AWS へ直接報告することで、AWS 側で対応できるようにしている。

AWS が露出した IAM キーを自動で隔離

Unit 42 が公開した調査結果から、2025年12月19日に実施されたテストにおける自動化の詳細な動作を確認できる。GitHub の Push Protection によるアクセスキー／シークレットの検出をテストするために、研究者は 18:50:05 UTC の時点で、アクセスキーとシークレットを公開リポジトリへ Push した。

18:50:15 UTC の時点で、AWSCompromisedKeyQuarantineV3 が TestUser に適用されたことを示す AttachUserPolicy イベントを、AWS の CloudTrail が記録した。その 1 秒後に GitHub が警告メールを送信し、18:50:17 には AWS Health が「Risk IAM quarantine」の通知を表示したほか、18:50:26 に AWS がメールを送信し、18:50:59 までには Support Case が作成された。

ただし、ログに関する 1 つの問題が、インシデントの初動調査を複雑にする可能性がある。CloudTrail の userIdentity フィールドでは、実際には TestUser が実行した操作ではないにもかかわらず、ポリシーを適用した主体として TestUser が記録されており、このレコードから AWS の自動処理による操作であることを明確に判別することもできなかった。

また、このテストでは、Health の警告／Support Case の作成についても、それぞれ CloudTrail イベントが生成されなかったため、AttachUserPolicy のレコードが、機械的に処理できるシグナルとして最も信頼性が高い。

AWS は 2020年8月に AWSCompromisedKeyQuarantine ポリシーを導入し、2021年4月に V2／2024年8月に V3 を導入した。最初のバージョンでは、IAM／EC2／Organizations／Lambda／Lightsail にまたがる 28 種類の操作を明示的に拒否し、V2 では制限対象が S3 まで拡大された。最終的に 17 のサービスで、61 種類の権限が拒否対象として追加されたほか、その後の改訂では、ECS／ECR／Bedrock／SageMaker／STS などのサービスを悪用する攻撃にも対応した。

こうした変化は、クラウドを標的とする攻撃手法の変化を反映している。IAM Role／Lambda の作成制限は暗号資産マイニングでの永続化を妨げ、S3 の削除操作に対する制限はデータを悪用した恐喝を阻止する可能性があり、Bedrock 関連の拒否設定は、権限のない生成 AI の利用に対処する。

IAM のポリシー評価では、明示的な Deny が Allow より優先されるため、この隔離機能はユーザーの既存権限を書き換えることなく、指定された高リスクの操作をブロックできる。ただし、隔離はアクセスキーの無効化ではなく、AWS はアクセスキーを無効化したり AWSDenyAll を適用したりせず、選択した操作だけを意図的にブロックすることで、正規のワークロードへ与える可能性がある影響を抑えている。

そのため、攻撃者は拒否リストに含まれていない操作を引き続き実行できる可能性がある。管理者に求められるのは、ポリシーの適用を認証情報の露出インシデントが確認されたものとして扱う／AWS Support Case を確認する／アクセスキーをローテーションまたは無効化する／漏えい前後の活動を調査することである。

セキュリティチームに対して推奨されるのは、AWSCompromisedKeyQuarantine／AWSCompromisedKeyQuarantineV2／AWSCompromisedKeyQuarantineV3 のいずれかが、requestParameters.policyArn に含まれる IAM の AttachUserPolicy イベントを検出した場合に警告を生成することである。

さらに、影響を受けたユーザー名について、GitHub の自動検証用 User-Agent を含む GetCallerIdentity リクエストなどの、CloudTrail に記録された前後の活動と関連付けて調査する必要がある。また、Support Case を AWS Systems Manager Explorer で一元管理し、通知がクラウド・エンジニアリング部門内だけに留まらないようにすることも重要となる。

Palo Alto Networks によると、Cortex Cloud は ID を起点とするクラウド脅威に行動情報を追加できる一方、Idira PAM はシークレットの一元管理／Just-In-Time アクセス／常時付与される権限をなくす運用をサポートする。

Unit 42 Cloud Security Assessment を利用する組織は、クラウドの設定不備やセキュリティ上の問題を特定することもできる。複雑なマルチ・アカウントのクラウド環境で侵害が疑われる場合は、Unit 42 Incident Response チームへ直ちに対応を依頼することが推奨される。

ソースコードなどに誤って認証情報を格納して意図せず外部へ公開してしまうミスは、クラウド運用の現場において初期侵入のリスクを高める深刻な課題です。Amazon Web Services (AWS) の認証キーが漏えいした場合、攻撃者による不正アクセス／システム内部での永続化／機密データの窃取や破壊／権限のないリソースの不正利用といった重大な被害につながります。これに対し、自動検知とマネージドポリシー適用による迅速なアクセス制限／CloudTrail ログの監視と連動した通知トリガーの設定／漏えいした鍵の即時回転および無効化といった運用フローの確立が有効です。迅速な対応体制を組み込んでおく取り組みが求められます。