この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
オペレーション部加藤(早)です。
AWSアクセスキーセキュリティ意識向上委員会って何？
昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、
多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。
そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。
アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、
セキュリティ対策を事前に適用した上で適切にご利用ください。
はじめに
AWSアクセスキー/シークレットキーの漏洩により不正利用が発生すると、緊急の対応が必要な上かなりの工数も取られて相当しんどいです。
なので本当は漏洩させないのが１番です。が、万が一の時慌てて二次被害を産まないよう、対応について予習をしておきましょう！
本記事では、以下のAWS公式ドキュメントを参考にご紹介します。
AWS アカウントでの不正なアクティビティに関する問題を解決する
また、過去に発生した被害について、ぜひ以下の実録記事も合わせてご覧ください。
【実録】アクセスキー流出、攻撃者のとった行動とその対策 | DevelopersIO
検知
代表的なものをご紹介します。
- 漏洩させた当事者からの報告
- AWSからの通知(メール/サポートケース)
- GuardDutyによる不正アクティビティの検知
- すぐ検知できず、不正利用をされた形跡を後で(多くの場合、請求書が来たときに…)発見
4つめはかなり辛いです。
一定金額以上の利用費が発生した時点でコストアラートを発砲するように設定しておくのも手です。
それよりもっと先手を打つための手段として、全リージョンでGuardDutyを有効化して通知を受け取れるようにしておくことをおすすめします。
- 一発でGuardDutyを全リージョン有効化して通知設定するテンプレート作った | DevelopersIO
- Amazon GuardDutyによる疑わしいネットワーク通信の検知と初動対応の振り返り | DevelopersIO
- 【全員必須】GuardDutyがコスパ最強の脅威検知サービスであることを証明してみた | DevelopersIO
対応開始の前に： アカウントにログイン出来ない場合
最も深刻な場合、不正利用者に全ての権限を奪取され、対象のアカウントにログインすらできなくなってしまいます。 その場合はAWSの問い合わせフォームから支援をリクエストすることになります。
引用： AWS アカウントでの不正なアクティビティに関する問題を解決する
注: ご自身のアカウントにサインインできない場合、お問い合わせフォームを利用して、AWS サポートからの支援をリクエストしてください。フォームには、パスワードをリセットする方法の説明も含まれています。
止血対応
組織のルールで定められた然るべき場所への報告が済んだら、AWS上の対応を行いましょう。
アクセスキー情報の公開を停止
誤って公開してしまった情報を非公開にします。
しかし、GitHubなどへの漏洩の場合、数分後には既にキー情報が不正利用者の手に渡っている可能性があり、これだけでは不十分です。
すべてのAWSアクセスキーを更新/削除
漏洩が発生したアクセスキーが特定できていれば優先的に、
そうでない場合は片っ端から（順序をつけるなら強力な権限を持つユーザから）アクセスキーを更新/削除してください。
事後にCloudTrailで被害状況を調査するときのため、20桁のアクセスキーの文字列は手元に残しておくことをおすすめします。
引用： AWS アカウントでの不正なアクティビティに関する問題を解決する
1. まず、2 つ目のキーを作成します。次に、新しいキーを使用するようにアプリケーションを変更します。
2. 1 つ目のキーを無効にします (ただし、削除しないでください)。
3. アプリケーションに問題がある場合は、一時的にキーを再アクティブ化してください。アプリケーションが完全に機能し、1 つ目のキーが無効な状態である場合は、1 つ目のキーを削除します。
4. 作成していない IAM ユーザーを削除します。
アプリケーションで使用しなくなったアクセスキーを削除できます。
漏洩したアクセスキーが特定出来ている場合も、その権限次第では不正利用者が漏洩したアクセスキーの権限を使って新規にIAMユーザやアクセスキー/シークレットキーを作成している可能性があります。
そうした可能性がある場合、漏洩したアクセスキー以外も全て更新する必要があります。
不正に作成されたIAMユーザを削除
作成した覚えのない、不正に作成されたIAMユーザはありませんか？
不正利用者はそのユーザを使ってあなたのAWS環境へログインしている可能性があります。削除しましょう。
既存IAMユーザのログインパスワードを変更
IAMユーザのパスワードが漏洩しているケースもあります。変更しておきましょう。
被害状況の確認
CloudTrailの確認
CloudTrailのイベント履歴から、直近90日のAPI操作情報履歴が確認できます。
漏洩の可能性があるアクセスキーで検索し、覚えのない操作（特にEC2等リソースの作成や新規IAMユーザ・アクセスキーの作成等）が含まれているかどうかを確認します。
請求金額の確認
請求ページから利用した覚えのないサービスやリージョンのリソース、その他意図しない請求が発生しているか等の状況を確認します。
不正利用者が仮想通貨のマイニングなどを行うためにEC2等のリソースを立ち上げ、請求が発生している可能性があります。
復旧対応
不正に作成されたリソースを削除
CloudTrailや請求情報等で確認したリソースを削除します。
調査のためにEC2インスタンスを保持しておきたい場合は、EBSスナップショットでバックアップを取得しておくことを検討ください。
事後対応
なぜ事象が発生したのか、検知の方法は適切だったか、再発防止方法、などなど
ぜひ組織で振り返りを行ってください。
その際、組織のIAMアクセスキー運用にベストプラクティスを取り入れられないか検討することをおすすめします。
AWS アクセスキーを管理するためのベストプラクティス - AWS 全般のリファレンス
特に、アクセスキーを直接アプリケーションのコードに埋め込む運用は推奨されていませんし、誤ってパブリックリポジトリにPushしてしまうなどの漏洩を起こしやすいです。 IAMロールに切り替えるか、それが難しい場合にもソースコードには埋め込まず、外部の機密情報ストレージ等(AWSマネージドサービスならSecret Manager)に保存した情報を取得することをおすすめします。
また、その際以下のようなツール類の導入を検討することもオススメします。
- AWSアクセスキーを含むソースコードのコミットをさせないためにgit-secret
- 端末内にアクセスキーを平文保存しないためにAWS Vault
AWSアクセスキーをGitリポジトリに混入させないために git-secrets を導入した | DevelopersIO
AWS Vaultで端末内のAWSアクセスキー平文保存をやめてみた | DevelopersIO
おわりに
一度漏洩が発生すると、被害の甚大さもさることながら、事後対応もかなり骨が折れます。
うっかりミスによる漏洩は珍しくないですが、ヒューマンエラーは防ぐことが本当に難しいです。
アクセスキー/シークレットキーを利用している場合はできればそれが本当に必要なのか、仕組みを見直してみることをオススメします！
1
