IAMユーザーの認証情報が漏洩した際の対処を、シンプルに出来るか考える

エンタープライズクラウド部の山下(祐)です。本ブログでは、IAMユーザーの認証情報が漏洩した際の対処を、シンプルに出来るか考えてみたいと思います。

背景
留意事項
前提条件
考察
まとめ
補足
- IAMユーザーに全てのActionをDenyするポリシーをアタッチする方法について
- （参考）対処法一覧

背景

セキュリティインシデントへの対応は、運用設計・組織体制の整備・マニュアルの整備・トレーニングなど、事前の準備が不可欠です。その辺りは、下記のドキュメントに非常によくまとめられていますので、よろしければご参照ください。

AWS Security Incident Response Guide - AWS Security Incident Response Guide

しかしながら、限られた時間・リソースで完璧な準備を整えることは難しいですし、いざインシデントが起きた際に、冷静さを失わずに、迅速・正確に対処を行うことは、なかなか簡単なことではありません。

そのため、被害の拡大は防止しつつ、作業を出来るだけ簡略化することで、対応の難易度を少しでも下げられないかと考えました。

留意事項

本ブログでご紹介する考え方はベースとして参考にしていただきつつ、実際に漏洩の疑いがある場合の対処については、自組織のAWS環境や運用体制・社内ルールに合わせて最適化していただければ幸いです。

また、漏洩のリスクを出来るだけ減らすため、漏洩時の影響を出来るだけ小さくするためにも、以下のベストプラクティスに沿った設計・運用を意識・実践いただければ幸いです。

IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management

IAM ユーザーのアクセスキーの管理 - AWS Identity and Access Management

AWS アカウントとリソースを保護するためのベストプラクティスについて学ぶ | AWS re:Post

前提条件

本ブログでは、以下を前提条件としたうえで、対処について考えたいと思います。

対象とする認証情報

本ブログでは、IAMユーザーに関する以下の認証情報を対象とします。

マネジメントコンソールのログインパスワード
アクセスキー/シークレットキー
MFAデバイスや専用ソフトウェアがインストールされた端末

対象リソース

本ブログで考察するのは、「漏洩の疑いがある認証情報そのものに対する対処」となります。

しかしながら、実際に漏洩が起きた際には、新たなユーザーを作成されたり既存ユーザーの認証情報を変更されたりして、そこから被害が拡大することがあります。そのため、本ブログの対象リソースに加え、以下についても必ず確認し、しかるべき対処を実施するようにしましょう。

漏洩の経路はどこか（公開されたリポジトリにアクセスキーをハードコーティングしていないか等）
既存のリソースやIAMユーザーに不正な変更が加えられていないか
不正なリソースやIAMユーザーが作成されていないか

詳細は、下記の関連ドキュメントも参考にしてください。

AWS アカウントでの不正なアクティビティに関する問題の解決 | AWS re:Post

Remediating potentially compromised AWS credentials - Amazon GuardDuty

対象フェーズ

本ブログでは、以下ドキュメントで説明されているインシデント対応フェーズの、「封じ込め」「根絶」「回復」に絞って考察します。

Operations - AWS Security Incident Response Guide

つまり、認証情報の漏洩や不正なアクティビティがあると判断された状態とします。（すでに疑いではないレベル） IAMユーザーの認証情報漏れに関していえば、それぞれ以下のような対処が該当します。

封じ込め：漏洩したアクセスキーの無効化・マネジメントコンソールのログインパスワードの無効化など
根絶　　：漏洩したアクセスキーの削除・MFA設定の削除など
回復　　：新しいアクセスキーの発行・新しいマネジメントコンソールログインパスワードの発行など

考察

対処法について、以下の3パターンを考えました。

No.	封じ込め	根絶	回復
1	IAMユーザーに全てのActionをDenyするポリシーをアタッチ	IAMユーザーを削除	IAMユーザーを作り直す
2	IAMユーザーに全てのActionをDenyするポリシーをアタッチ	漏洩した認証情報の削除	新しい認証情報の発行 IAMユーザーからDenyポリシーをデタッチ
3	漏洩した認証情報の無効化	漏洩した認証情報の削除	新しい認証情報の発行

No.1について

この方法は、漏洩した認証情報によらず、同じ方法で対処することが可能です。運用手順のパターンが減るので、封じ込め・根絶に関しては、もっとも簡便な手順といえます。

一方で、認証情報が漏洩する度に、IAMユーザーを丸ごと作り直す必要があるので、回復の手間やユーザー管理の観点では、むしろ負荷が高くなります。

No.2について

この方法は、封じ込めは一つの方法に統一し、根絶・回復は認証情報毎に変える方法です。

No.1 と No.3 の中間にあたる方法です。

No.3について

この方法は、漏洩した認証情報毎に個別の対処を行う方法です。作業のパターンが増えるため、対処法を組織レベルで浸透させることには負荷がかかるかもしれません。なお、個別の対処法については、後述の「（参考）対処法一覧」にまとめましたので、よろしければご参照ください。

どの案を採用するか

結論から言うと、No.2が最も導入しやすいかと思います。インシデント発生時には、迅速に封じ込めを行い、被害拡大を防止することが非常に重要です。封じ込めのパターンが1つしかなければ、対応に迷って初動が遅れるリスクは軽減できるかと思います。

その一方で、No.1のように、根絶対応で毎回IAMユーザーを削除するのは、かなりの負荷となります。

本ブログでは深堀しませんが、侵害された認証情報を使って、他のIAMユーザーのアクセスキー等を削除・再発行し、再発行したキーで不正利用をされるケースもあります。そういった二次被害にあった認証情報についても全て「IAMユーザーごと削除」となると、大量のIAMユーザーの作り直しが発生してしまう可能性があります。

そのため、封じ込めは迅速に行いつつ、根絶対応は着実に進めることが良いのではないかと考えます。

まとめ

以上、IAMユーザーの認証情報が漏洩した際の対処法に関する考察でした。

冒頭で紹介したホワイトペーパーにも記載されていますが、組織の封じ込め戦略・根絶戦略は様々な要因に依存しており、組織によって最適解は異なります。

本ブログでご紹介した内容を参考にしていただきつつ、自組織に最適化された戦略を立案いただければ幸いです。

補足

最後に、今回の考察にあたって調査した内容等を、参考情報として記載します。

IAMユーザーに全てのActionをDenyするポリシーをアタッチする方法について

この方法は「AWSCompromisedKeyQuarantineV2」から着想を得ました。 AWSCompromisedKeyQuarantineV2は、IAMユーザーの認証情報が漏洩したり、公開されたりしたことをAWSが検知した場合に、AWSチームによって適用されるマネージドポリシーです。

被害の拡大に繋がりそうな、特定のアクションへのアクセスを拒否するポリシーとなっています。

詳細は、以下ページをご確認ください。

AWSCompromisedKeyQuarantineV2 - AWS マネージドポリシー

（参考）対処法一覧

各認証情報で漏洩があった際に取り得る対処について、表にまとめました。一番左の列に、対象の認証情報を記載し、対処毎の効果を記載します。

効果は「対処後、不正なアクティビティを防ぐことが出来るか」という観点で評価します。

〇：不正アクティビティを防止可能
△：状況によっては不正アクティビティを防止可能
ー：効果なし

逆に言うと、上記以外の観点は評価基準に入っていませんので、〇が常にベストプラクティスといえるわけではありません。

	IAMユーザー削除	IAMユーザーに全てのActionをDenyするポリシーをアタッチ	マネジメントコンソールのパスワード無効化	アクセスキー削除	アクセスキー無効化	MFAデバイス削除	MFAデバイス無効化
マネジメントコンソールのログインパスワード漏洩疑い	〇	〇	△	ー	ー	ー	ー
アクセスキーの漏洩疑い	〇	〇	ー	〇	〇	ー	ー
MFAデバイスの盗難・紛失疑い	〇	〇	△	△	△	△	△

マネジメントコンソールのログインパスワード漏洩疑い

マネジメントコンソールのパスワード無効化により、コンソールログインを防止することができます。ただし、不正利用者が、漏洩したパスワードを使用して既にマネジメントコンソールにログイン済みの場合、パスワードを無効化しても、ログアウトしなければマネジメントコンソール上で操作が可能です。

ログイン履歴はCloudTrailのログで確認できますので、対象ユーザーがログインしているかどうか必ず確認しましょう。ログインしていない場合のみ、パスワード無効化が、即効性のある封じ込め対策として機能します。

アクセスキーの漏洩

アクセスキーが漏洩した場合、当該アクセスキーを削除、もしくは無効化することで、当該アクセスキーを使用した追加のアクティビティを防止することが可能です。

MFAデバイスの盗難・紛失

盗難・紛失したMFAデバイスをAWS上で削除・無効化することで、多要素認証に使用できなくすることが可能です。

また、マネジメントコンソールのパスワード無効化やアクセスキーの無効化により、MFAを使用する前段階のログイン等を防止できる可能性もあります。

ただし、不正利用者がMFAを利用して既にマネジメントコンソールにログインしたりAWS CLIのセッショントークンを取得済みの場合、追加のアクティビティを防止することはできません。

共通して効果のある対処

どの情報の漏洩にも共通して効果のある対処法は、以下2つの方法です。

当該IAMユーザーを削除する

当該IAMユーザーを削除してしまえば、そのユーザー、および、紐づいていたアクセスキーでは何も出来なくなります。マネジメントコンソールにログイン中のIAMユーザーであっても削除することが可能です。
ただし、IAMユーザーを一度削除すると、復活させることは出来ません。「マネジメントコンソールのパスワードが漏れた可能性があるのでIAMユーザーごと削除したら、実はアクセスキーが重要なアプリケーションに使用されていて、アプリが停止してしまった。」といった別の被害を生む可能性もあります。そのため、IAMユーザーの削除をいきなり実行するのはリスクがあります。

IAMユーザーに全てのActionをDenyするポリシーをアタッチ

当該ユーザーに、全てのアクションをDenyするポリシーをアタッチすることで、以降のAPIリクエストは全て拒否されます。その状態でも、APIリクエストを出すことは出来ますし、出されたAPIリクエストは、CloudTrailにログとして残ります。冒頭でご紹介したホワイトペーパーに、封じ込めの目的の一つとして「証拠保全」が挙げられています。そういった観点でも、いきなりユーザーを削除するのではなく、まずは封じ込めとしてDenyポリシーをアタッチする方がベターかと思います。