クラウドの「鍵」をドブに捨てるな：IAMキー漏洩の現実と、即死を防ぐ自動防衛術
「GitHubにシークレットをコミットした」というミスは、もはや事故ではなく、レッドチームから見れば「招待状」です。クラウド環境におけるIAMアクセスキーの漏洩は、数秒で数千ドルのマイニング課金や、バックエンドDBの全ダンプに直結します。
今日は、攻撃者がどのようにキーを奪い、我々がそれをどう封じ込めるべきか、現場の視点で語ります。
—
1. 攻撃者が「GitHubのコミット」をどう狙っているか
攻撃者のBotは、GitHubのパブリックリポジトリを秒単位でクローリングしています。AKIAで始まるアクセスキーIDを見つけた瞬間、彼らは以下のステップを自動実行します。
1. 権限列挙: aws sts get-caller-identity で誰の権限かを確認。
2. 権限昇格の模索: iam:CreateAccessKey や iam:PutUserPolicy があれば、バックドアアカウントを即座に作成。
3. データ抽出: S3バケットのリストアップ、RDSのスナップショット取得、EC2の全停止。
これらはすべて、人間がコーヒーを淹れている間に完了します。あなたが「やばい、消そう」と焦ってコミット履歴を削除しても、既にそのキーは攻撃者のデータベースに取り込まれた後です。
—
2. 攻撃手法の PoC（概念実証）
もし攻撃者があなたのキーを手に入れたら、Pythonの boto3 を使って以下のような短時間のスクリプトで全環境を汚染します。
import boto3
# 漏洩したキーを使用
session = boto3.Session(
aws_access_key_id='AKIA...',
aws_secret_access_key='...'
)
# 悪意ある攻撃者が最初に行う「足跡消し・権限奪取」の例
def exploit_iam(session):
iam = session.client('iam')
# 自分の権限を強力にするインラインポリシーをアタッチ
iam.put_user_policy(
UserName='exposed-user',
PolicyName='FullAccessBackdoor',
PolicyDocument='{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"*","Resource":"*"}]}'
)—
3. 防御の要：CloudTrailとEventBridgeによる自動封じ込め
「キーを漏らさない」のは前提ですが、人間は必ずミスをします。重要なのは、「漏洩した瞬間にそのキーを無効化する」という自動化フローを構築しておくことです。
実装案：CloudTrail イベントによる自動無効化
CloudTrail で特定のIAM操作を検知し、EventBridge を経由して Lambda を起動し、キーを強制無効化する仕組みです。
Lambdaによる自動無効化スクリプト (Python)
import boto3
import os
def lambda_handler(event, context):
# イベントから対象のユーザーとアクセスキーを取得
user_name = event['detail']['requestParameters']['userName']
access_key_id = event['detail']['responseElements']['accessKey']['accessKeyId']
iam = boto3.client('iam')
# 該当キーを即座に無効化（Inactive）
iam.update_access_key(
UserName=user_name,
AccessKeyId=access_key_id,
Status='Inactive'
)
# 必要に応じて通知（SNS等でアラート）
print(f"セキュリティ警告: キー {access_key_id} を自動無効化しました。ユーザー: {user_name}")—
4. 運用エンジニアが明日からやるべき3つのこと
コードを書き換える前に、以下の「泥臭い」設定を確認してください。
① git-secrets または trufflehog の導入
開発者のPCに pre-commit フックを入れましょう。コミットする前に「AKIA」という文字列が含まれていないかチェックするだけで、事故の9割は防げます。
② IAMの利用範囲を「物理的に」狭める
開発用・本番用でIAMを完全に分離するのは基本です。さらに、IAM User ではなく IAM Role を使い、一時的な認証情報（STS）のみで運用する環境を構築してください。
③ .env ファイルを絶対に含めない
node.js や Python で環境変数を読み込む際、.env ファイルが git status に出ていないか確認してください。.gitignore への追記は必須です。
# .gitignore の鉄則
.env
.env.local
.env.*.local
*.pem—
最後に：セキュリティは「性悪説」で設計せよ
セキュリティのプロフェッショナルは、「自分のコードがいつかGitHubに流出する」ことを前提にシステムを設計します。
IAMキーをハードコードしてはいけない、というのは教科書に書いてある通りですが、「もし漏れたら、どの範囲まで被害を拡大させずに止めるか（Bulkhead パターン）」という考え方が、現場では最も重要です。
皆さんのシステムが、攻撃者にとって「割に合わないターゲット」になるよう、今日から権限の見直しと監視の自動化に着手してください。それが、結果として自分自身の運用工数を減らすことにも繋がります。
コメント