【小ネタ】IAMポリシーにAWSExposedCredentialPolicy_DO_NOT_REMOVEが設定された

はじめに

瀬田@大阪オフィスです。アクセスキーちゃんと管理していますか?もし、漏洩した場合にこんなことがあるよという情報です。

概要

AWSでアクセスキー漏洩等で不正アクセスを検知した場合、AWSExposedCredentialPolicy_DO_NOT_REMOVEというポリシーが漏洩したIAMユーザに適用される場合があります。これが実施されることで、漏洩ユーザの権限によるアカウント内の作業ができない状態になります。

自分の AWS アカウントが危険にさらされているようです

この権限がついたことで侵害を防げたというわけではなく、必ず設定されるかも不明のため、漏洩した場合は必ず環境の確認をしましょう。

アクセスキーの漏洩を防ぐ

そもそも、アクセスキーが漏洩しないように対策を行いましょう。 git-secretsの導入はマストです。

AWSアクセスキーをGitリポジトリに混入させないために git-secrets を導入した

適切な権限管理と二段階認証の導入

そのユーザに必要なIAM権限のみを適用するよう設計をすると同時に、MFA認証の導入を検討してください。

IAMユーザーのMFA（多要素認証）は有効になっていますか？現状を確認→是正→適切な状態を維持するまでの流れを整理してみた

漏洩してしまったら

AWSドキュメントでは以下の対策が示されています。

• AWS ルートアカウントのユーザーパスワードを変更する。
• すべてのルートおよび AWS Identity and Access Management (IAM) アクセスキーを削除するか、交換する。
• 危険にさらされている IAM ユーザーを削除し、他のすべての IAM ユーザーのパスワードを変更する。
• EC2 インスタンスおよび AMI、EBS ボリュームおよびスナップショット、および IAM ユーザーなどの作成していないアカウントのリソースを削除する。

被害状況の把握

アクセスキーの漏洩後、不正なEC2が大量に起動されたり、情報を引き出される恐れがあります。これは、CloudTrailを確認することで操作履歴が確認できます。 なお、S3のオブジェクトレベルの操作とLambdaのデータイベントはデフォルトでは取得していません。S3データの引き出しを検知したい場合は、CloudTrailの証跡から上記の設定を必要に応じて実施してください。

最後に

AWSも様々な施策を実施してセキュリティを高めているようです。しかし、基本は自分たちでセキュリティインシデントを発生させないよう運用の設計を行いましょう。漏洩した場合の対応コストは膨大になりがちなため、先手を打っておくことが必要です。