密着!!アクセスキー漏出事件24時｜コラム｜NURO Biz（ニューロ・ビズ）

始めに

開発本部のエンジニア、濱田です。
私事ですが、先日のAWS Summit Tokyoで2023 Japan AWS Top Engineersを受賞し、2023 Japan AWS Ambassadorsに選出されました。
https://sonybn.co.jp/news/2023/0530/

名だたるAWSエンジニアが名前を連ねるAWS Ambassaforに自分も加わることになり恐縮の極みですが、先輩Ambassadorの皆さんからたくさん技術を吸収して、最強のAWSエンジニアになりたいと思います。

アクセスキーの漏出について

本日のテーマは、AccessKey・Secret AccessKey（AK/SK）の漏出事故についてです。
最近、私の周囲でも漏出事故が相次ぎました。
幸い、いずれのケースも大事には至らなかったのですが、一歩間違えば大惨事になっていたケースもありました。
そこで今回は、アクセスキー漏出の事例や、対処方法、対策についてお話します。

アクセスキー漏出の危険性とは

AK/SKとは、AccessKey、Secret AccessKeyの略称で、AWSの認証情報です。
主に、AWS外からコマンドやプログラムでAWSを操作する場合に利用します。

AK/SKはIAMユーザと紐づいており、IAMユーザの持っている権限の範囲で、APIの実行が可能です。
例えば、EC2の作成が可能なIAMユーザのAK/SKが流出したとします。
その場合、AK/SKを入手した人間なら誰でも、そのアカウント上にEC2インスタンスを構築出来るようになります。
知らない間に巨大なインスタンスを立てられ、膨大な請求が来て初めて流出に気づいた、、、というケースが多いです。

このように、ユーザの権限によっては大事故に繋がりかねない、最上級のセキュリティインシデントと言っても過言ではありません（当社比）。

事例

では、AK/SKの流出事故とは一体どのようなものなのか？最近弊社にて扱った事例についてご紹介します。

事象
- エンジニアが誤ってAK/SKを含むコードをGithubへアップロードしてしまった
- 直後にAWSが検知、当該AK/SKを持つIAMユーザの権限を制限
- 制限直後、不審な第三者によるAPI実行が始まる
- API実行自体は、AK/SKをローテートするまで続いた

以下が当時のタイムラインです。

ポイント1: AK/SKアップロードに対してのレスポンスの速さ 19:10に、AK/SKがGithubの公開リポジトリへアップロードされてから、AWSは僅か3分で検知しています。しかし、AWSの検知から更に4分後に最初の不審なAPI実行がありました。 AWSの検知は確かに速いですが、安心できる訳ではなさそうです。
ポイント2: 様々なAPIの、世界各国からの不正実行
漏出したAK/SKを用いて、世界中からAPIが不正実行されています。色々なAPIが実行されていますが、恐ろしいことに、ListUsersとCreateUsersの2種類が実行されています。クラッキングにおいて、最初にバックドアを仕掛ける手法が定石と言われています。ここでユーザを作成されていたら、クラッカーがいつでもAWSに侵入できる状態になり、大惨事になっていたという事です。
ポイント3: AK/SKを無効化するまで攻撃は止まらない実は、19:25時点でエンジニアが誤操作に気付き、リポジトリそのものを削除していました。しかし、既に保存されているのか、リポジトリを消しても攻撃は止んでいません。 21:27に管理者がAK/SKを無効化して初めて、攻撃が止まりました。

いかがでしたでしょうか？ AWSとクラッカーの攻防の速度から、オペレータもスピード感を持って対応しなければならないと理解頂ければ幸いです。

対処法

では、もしAK/SKが流出してしまったら、どんな対応をしなければならないのでしょうか？

その1: AK/SKを無効化する何よりも、まずは漏出したAK/SKを無効化しましょう。 AK/SKの漏出をAWSからの通知メールで検知した場合、どのAKが流出したかはメール内に記載されています。検知の方法が何であれ、とにかくAK/SKをまず無効化しましょう。
その2: AWS CloudTrailを確認する AK/SKを無効化したら、次は影響度合いの調査です。 AWS CloudTrailを確認しましょう。当該AK/SKでフィルターをかける事で、そのAK/SKを用いて実行されたAPIの一覧を確認できます。

※ 画像ではログをエクスポートし、Excelでフィルターをかけています

実行されたAPIを抽出したら、次はそのAPIがどんなものかを調べましょう。例えば、各種リソースの作成や、S3などのデータ領域を読み込む操作が行われていないか、注意しましょう。

1点注意事項があります。 CloudTrailを確認する際は、全てのリージョンを確認しましょう。リージョン依存のサービスの操作ログは各リージョンにのみ出力され、IAMなどのグローバルサービスについてはus-east-1のみに出力されます。使っていないリージョンについても、忘れず確認しましょう。

その3: 侵害されたリソースを削除するこれは言うまでもないことですが、不審なリソースがあった場合、すぐに確認・削除しましょう。繰り返しですが、使っていないリージョンについても、忘れず確認しましょう。
その4: (ケースが上がっていた場合) AWSへ連絡する AWSがAK/SK漏出を検知した場合、顧客アカウント向けのサポートケースを作成しています。こちらに対して、対応した旨を報告しましょう。 AWSの確認が完了すると、アカウント(弊社対応時はIAMユーザ)に対してかけられた制限が全て解除されます。

以上が、AK/SK漏出が起きた場合に取るべき対処法でした。

AK/SK漏出への対策

では、そもそもAK/SKを漏出させない為にはどうしたら良いのでしょうか？実は、AWSでは「AK/SKを使わない」ことがベストプラクティスです。基本的には、AK/SKではなく、一時的な認証情報を利用しましょう。

スクリプトをAWS上に移行出来る場合基本的には、IAMロールで権限を付与しましょう。 EC2インスタンス上でAWS CLIを実行する場合、自動的にインスタンスに付与されたIAMロールで一時認証情報を発行・利用してくれます。 AWS CLIを用いたバッチなどを実行する場合は、EC2へ移行するか、Lambdaにて実装しましょう。
どうしてもオンプレミス側でスクリプトを実行しなければならない場合しかし、どうしてもオンプレミス側でAWS CLIなどのスクリプトを実行しなければならない場合もあると思います。その場合は、以下のポイントを踏まえて、AK/SKを使いましょう。
アクセスキーをコードに埋め込まない・アプリケーション毎にアクセスキーを分ける・定期的にアクセスキーをローテートする・使っていないアクセスキーを削除する

特に「アクセスキーをコードに埋め込まない」について、いくつかパターンがあります。 AWS CLIの場合、ユーザのホームディレクトリ配下、.aws内に credentials というファイルが作成されます。こちらにAK/SKを書き込んでおくことで、透過的に権限を読み込むことが出来ます。

AWS SDKの場合、AK/SKをOSの環境変数に登録しておき、必要に応じて読み込むことが出来ます。

# 環境変数
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# Python
import os
import boto3

access_key = os.environ['AWS_ACCESS_KEY_ID']
secret_key = os.environ['AWS_SECRET_ACCESS_KEY']

client = boto3.client('ec2',
  aws_access_key_id=access_key,
  aws_secret_access_key=secret_key
)

これらのベストプラクティスはAWS公式ドキュメントにも詳しく書かれているので、AK/SKを利用する方は必ずご一読下さい。

https://docs.aws.amazon.com/ja_jp/accounts/latest/reference/credentials-access-keys-best-practices.html