AWSは、パブリックGitHubリポジトリに流出したIdentity and Access Management(IAM)アクセスキーを自動的に隔離できます。このプロセスでは、クラウド悪用のリスクを軽減するため、数秒以内に制限的なマネージドポリシーが適用されます。
Palo Alto Networks傘下のUnit 42の研究者らがこの対応メカニズムを詳しく調査し、AWSがAWSCompromisedKeyQuarantineマネージドポリシーを用いて、特定の高リスクアクションを拒否しつつ、可能な限り既存リソースへのアクセスを維持していることを明らかにしました。
AWSが流出したIAM認証情報を検知・隔離
長期的なIAMアクセスキーは、依然として重大なクラウドセキュリティ上の懸念事項です。ソースコードや設定ファイル、環境変数ファイル、あるいはパブリックなパッケージリポジトリに誤ってコミットされてしまうことがあるためです。
Websitesecurity audit
流出したキーが発見されると、攻撃者は影響を受けたIAMアイデンティティに付与されている権限次第で、クラウド資産の列挙、暗号資産マイニング用インフラの構築、永続化の確立、権限の変更、不正な課金の発生などを行える可能性があります。
AWSのこの自動保護機能は、GitHubのシークレットスキャン提携プログラムと連携しています。GitHubはパブリックリポジトリおよびパブリックなnpmパッケージをスキャンし、既知のシークレットパターンを検出すると、提携しているサービスプロバイダーに通知します。これによりAWSは、アカウント所有者が手動でキーを失効させるのを待たずに対応できます。
Unit 42が実施したテストでは、研究者がAWSのアクセスキーとシークレットをパブリックGitHubリポジトリにプッシュしました。すると認証情報が流出してからわずか10秒後に、AWSは関連するIAMユーザーにAWSCompromisedKeyQuarantineV3ポリシーを付与しました。
GitHubからの通知はその1秒後に届き、続いてAWS Healthアラート、メール通知、影響を受けたキーとIAMユーザーの詳細を記載したAWSサポートケースが発行されました。
この隔離ポリシーが重要なのは、IAMユーザーを無効化したり、すべての権限を取り消したりするわけではない点です。代わりに、アカウント侵害後によく悪用されるアクションに対して明示的な拒否(Deny)ステートメントを適用します。
AWSのポリシー評価では、明示的な拒否は許可(Allow)よりも優先されます。つまり、IAMユーザーの既存のポリシーがそのアクションを許可していたとしても、隔離用の制御が優先されるということです。
2020年8月に導入されたAWSCompromisedKeyQuarantineの初期バージョンは、IAM、Amazon EC2、AWS Organizations、AWS Lambda、Amazon Lightsailにまたがる28件のアクションをブロックしていました。
その後AWSは制御対象を拡大し、バージョン2ではAmazon S3向けの制限を追加、拒否リストの対象を17サービスに広げ、最終的に61件の高リスク権限を追加でカバーするようになりました。バージョン3ではこの拡張された保護がそのまま維持されています。
制限対象となるアクションの例としては、新規IAMユーザーやアクセスキーの作成、ポリシーの付与、ロールの作成、EC2インスタンスの起動、スポットインスタンスのリクエスト、Lambda関数の作成、Lightsailの機微な操作などが挙げられます。
これらの制御は、該当アイデンティティに紐づく正規のワークロードへの即座の支障を避けつつ、権限昇格や永続化、リソースの乗っ取り、詐欺関連の活動を阻止するよう設計されています。
ただし、このポリシーは認証情報のローテーションやインシデント対応の代わりにはなりません。AWSは顧客に対し、このマネージドポリシーを取り外さず、サポートケースに記載された指示に従うよう勧めています。
セキュリティチームは、このイベントを侵害の可能性があるものとして扱い、影響を受けた認証情報を使用しているすべてのシステムを特定し、キーを交換し、IAM権限を見直したうえで、流出の前後双方における活動を調査する必要があります。
Websitesecurity audit
防御側は、AWS CloudTrail内でIAMサービスからのAttachUserPolicyイベントを特定することで、隔離イベントを監視できます。リクエストパラメータには該当するポリシーARNが記載されており、AWSCompromisedKeyQuarantineポリシーが付与されたタイミングを把握する手掛かりになります。
組織はこれらのイベントをSIEMやアラートプラットフォームに連携させ、クラウドエンジニアリングチームとセキュリティチームの両方が同じ通知を受け取れるようにすべきです。
今回の事例は、多層防御モデルの重要性を浮き彫りにしています。GitHubのシークレットスキャンがパブリックへの流出を検知し、AWSが危険なアクションを自動的に制限し、そして社内の対応者が認証情報のローテーションと不正利用の調査によって封じ込めを完了させる、という一連の流れです。
SOCのアラート調査時間を1件あたり21分短縮。即座に対応できるIOCコンテキストでSOCを強化: TI Lookupを貴社のSOCに統合する
翻訳元: https://gbhackers.com/aws-detects-and-quarantines-exposed-iam-credentials/
