セキュリティ意識向上のために事例と対応や防止方法について書いてみた

こんばんは、菅野です。 4月になり、多くの企業では新年度がはじまりました。 人事異動や入社などにより環境が変わるこのタイミングは、セキュリティについて考えてもらうのに丁度いいタイミングだと思い今回このブログを書いています。

はじめに

クラスメソッドでは多くのお客様環境と関わっているため、年に数回セキュリティのトラブル解決の協力をすることがあります。 今回はなぜ発生したのか、どんな状況になるのか、どうしたら防げるのかといった実例をご紹介いたしますのでご一読ください。

一番多いパターンは？

クラスメソッドでお手伝いするセキュリティトラブルの大半は「アクセスキー漏洩」です。 さらにそのほとんどはアクセスキー・シークレットアクセスキーを含んだプログラムソースを公開リポジトリに置いた、というものでした。 悪い人達はパブリック公開されるファイルを自動でチェックし、常に狙っているのです。

事例：公開リポジトリでのアクセスキー漏洩

概要

漏洩したアクセスキーを使って世界中のリージョンにハイスペックな EC2 インスタンスを可能な限り起動し、それらを使って仮想通貨のマイニング（採掘）が行われていました。 不正利用開始から停止までの約36時間で計上された EC2 の不正利用額は約300万円くらいまで膨らんでいました。

発覚

アクセスキーの漏洩が発生すると、AWS からの新しいサポートケース起票という形で連絡が来ます。同時にサポートケースが起票されたということで root ユーザーのメールアドレス宛にメールが届きますので内容を確認しましょう。

• 【ポイント】Compromised や compromise というキーワードでメールを早期発見し、初動を可能な限り早くしましょう。
• 【ポイント】必ず AWS から連絡が来るとは限りませんので「Amazon GuardDuty」を設定して早期発見の可能性を上げましょう。

初動対応

「漏洩元の公開リポジトリからファイルを消す」といった作業をしている間にも、漏洩したアクセスキーが使われての被害がどんどん拡大するかもしれません。 被害の拡大を防ぐことを最優先として行動しましょう。

• 【ポイント】漏洩元はとりあえず放置して、まずは漏洩したアクセスキーの無効化を！

調査1

まずは IAM で漏洩したアクセスキーを持つ IAM ユーザーの持つ権限（アタッチされている IAM ポリシー）を確認しましょう。 何も権限が無いならひとまず安心ですがそんな事はほとんどありません。逆に Administrator 権限を持っていたとしたら非常事態です。

• 【ポイント】漏洩したアクセスキーの権限を確認して「何をされた可能性があるのか」を把握しましょう。

調査2

次に CloudTrail を使って実際に何をされたかを確認しましょう。Cloud Trail ではアクセスキーによる API の実行履歴を検索可能です。 そのアクセスキーを使って何かをされていれば履歴として残っていますので被害の実態を掴みましょう。

• 【ポイント】エラーコードが「AccessDenied」であればその API の実行は失敗しています。
• 【ポイント】Cloud Trail による調査は全てのリージョンで行う必要があります。

対応1

調査が済んでいますので、不正に実施された内容に対する復旧作業を行います。 EC2 インスタンスが不正に起動されていたのであれば削除する、といった感じで一つずつ対応しましょう。

• 【ポイント】漏洩したアクセスキーに IAM の権限があった場合、他の IAM ユーザーを作成してそれを利用するパターンもありましたので見落とさないように。

対応2

復旧が完了した後はセキュアな状態にするための作業を行います。 本番環境の AWS アカウントの場合はすぐに、とはいかないかもしれませんが可能な限り早い対応が必要です。

• 【ポイント】以下のような対応を行う事でこれ以上不正なアクセスや利用をされないようにしましょう。
• 全 IAM ユーザーのパスワードをリセット
• 全 IAM ユーザーの全アクセスキーをローテート、もしくは不要なものは削除
• root ユーザーのパスワードをリセット

対応3

漏洩元（公開したファイル）の削除や修正も忘れずに行いましょう。

報告

AWS から連絡があったのであれば対応が完了した旨を返信しましょう。 こちらからの返信前に AWS が確認して連絡が来ることもあります。サポートケースがクローズされれば今回の対応が完了となります。

防止や被害軽減を考える

アクセスキー漏洩が発生しないように git-secrets を利用する

• git-secrets を使用する事でソースにアクセスキーを含んだまま commit できなくする事が可能です。
• AWSアクセスキーをGitリポジトリに混入させないために git-secrets を導入した ｜ DevelopersIO

全ての IAM ユーザーや IAM ロールの権限を見直す

• 特に IAM 関連の権限は可能な限り外してください。変更や作成の権限は無いからといって安心はできず、持っているポリシーによっては「何ができるのか」を調べる事が可能となり、操作可能なリソースが知られるなど不正利用の手助けになってしまう可能性があります。

Amazon GuardDuty を利用する

• 不正なアクセスの早期発見が可能になります。
• EC2 にアタッチした IAM ロールの一時クレデンシャルが AWS 外部から利用されたことが報告され、不正利用が発覚した事例もあります。

まとめ

いかがでしたでしょうか。 アクセスキーの漏洩事故は少しの油断で誰にでも発生してしまいます。ブログにうっかり記載してしまう、なんてこともあるかもしれません。 皆様がアクセスキーの取り扱いに対して今以上に慎重になっていただければ防止できるはずですので、この記事がそのきっかけになれば幸いです。