こんにちは！インフラやクラウドのセキュリティを担当していると、「セキュリティってなんだか難しそう……」「どこから手をつければいいの？」という声を本当によく耳にします。
特に、AWSなどのクラウドを使い始めたばかりの新人エンジニアさんや、アプリ開発がメインの一般開発者さんにとって、IAM（Identity and Access Management：ユーザーや権限の管理）の設定やログの監視は、黒い画面の向こう側の出来事のように感じられて不安になりますよね。
でも、大丈夫です！セキュリティの本質は、私たちが普段の生活で何気なくやっている「防犯」と同じなんです。今回は、家の鍵の防犯にたとえながら、クラウドの心臓部であるIAMの変更ログ監視と、怪しい動きを自動で撃退する仕組みについて、一緒に一歩ずつ学んでいきましょう！
—
1. クラウドの「合鍵」と「ピッキング」の怖さ
皆さんが暮らしているお家を想像してみてください。玄関の鍵はしっかり閉めますよね。では、その「鍵を作るマスターキー（合鍵）」がもし泥棒の手に渡ってしまったらどうなるでしょうか？鍵自体は壊されていないので、泥棒は堂々と玄関から入り込んで、家中の宝物を持ち去ってしまいます。
クラウドの世界でもこれと全く同じことが起きます。それが IAM（権限管理）の乗っ取り です。
クラウド（AWSなど）では、サーバーやデータベースを動かすために「誰が・何をしていいか」を決める通行手形（アクセスキーやIAMユーザー）が存在します。もし悪意ある攻撃者が、何らかの理由で権限を管理する「管理者（ルートユーザーや特権IAM）」のパスワードやアクセスキーを盗み出したら……？ 彼らは瞬時にすべての部屋の合鍵を作り、勝手に新しいユーザーを作って、仮想サーバーをマイニング（暗号資産の不正採掘）に使ったり、顧客データを盗み出したりしてしまいます。
ここで恐ろしいのは、「正規の鍵を使って入室している」ため、普通のシステムエラーや不具合には見えないという点です。だからこそ、「誰が、いつ、どの鍵を新しく作ったのか」という変更履歴を常に監視しておく必要があるのです。
—
2. 泥棒の侵入を監視する防犯カメラ：CloudTrailとGuardDuty
家に防犯カメラやセンサーライトがあれば、夜中に庭に誰かが入ってきたときにすぐに気づけますよね。AWSの世界にも、これと全く同じ仕組みが用意されています。
すべての足跡を記録する「AWS CloudTrail」
CloudTrailは、いわばクラウド上の防犯カメラと全自動の出入国管理記録です。
「誰が」「いつ」「どこのIPアドレスから」「どんな操作をしたか」のすべてを記録し続けます。例えば、「深夜2時に、普段はアクセスしない海外のIPアドレスから、新しい管理者用ユーザーが作られた」といった不審な動きも、このCloudTrailのログにはすべてバッチリ残ります。
不審な動きを察知する警備員「Amazon GuardDuty」
ただ、毎日何万行もあるログを目視でチェックし続けるのは、人間には不可能です。そこで登場するのが、AIを活用した優秀な警備員Amazon GuardDutyです。
GuardDutyは、CloudTrailのログやネットワークの通信を常に監視し、「おや？ この動き、過去のサイバー攻撃のパターンにそっくりだぞ」「普段と違う動き（異常検知）をしている！」と察知すると、すぐに赤色灯を回してアラートを上げてくれます。
—
3. アラートを上げるだけじゃ物足りない！「自動応答（Lambda連携）」
防犯カメラが泥棒を見つけて「ギャー！」とサイレンを鳴らしても、警備員が駆けつけるまでに時間がかかったら、その間に泥棒は逃げてしまいますよね。クラウドのセキュリティも同じです。深夜にアラートが鳴っても、担当者が朝まで寝ていたら被害が広がってしまいます。
そこで、「怪しい動きを検知したら、システムが自動で即座に反撃（防御）する」という仕組みを作ります。これが、ログ監視と AWS Lambda（サーバーレスで動くプログラム） を連携させた自動応答の仕組みです。
例えば、以下のようなシナリオを考えてみましょう。
1. 検知: GuardDutyが「不審なIAMポリシーの変更（権限の格上げ）」を検知する。
2. 通知: そのイベントがAWS EventBridge（イベントの交通整理役）に飛ぶ。
3. 自動ブロック（Lambda）: 紐づけられたLambda関数（プログラム）が秒速で起動し、怪しいIAMユーザーのアクセスキーを即座に「無効化（Inactive）」にする！
これなら、担当者が寝ている深夜であっても、システムが勝手に泥棒の鍵をその場で取り上げてくれます。
—
4. 【実践】IAM変更を検知して自動で封じ込めるLambdaコード例
それでは、実務で使える具体的な設定のイメージを見ていきましょう。
今回は、Pythonを使って「不審なIAM関連のアクション（ユーザー作成やポリシー変更など）」が起きたときに、該当するユーザーのアクセスキーを自動で無効化するLambda関数のサンプルコードをご紹介します。
※実際の現場では、誤検知によるサービスの停止を防ぐため、「特定の検証用アカウント以外」や「人間の管理者が意図して行った作業か」を判定するロジックをもう少し丁寧に挟みますが、今回は基本の骨組みを見てみましょう。
import json
import boto3
import logging
# ログ出力の設定
logger = logging.getLogger()
logger.setLevel(logging.INFO)
# IAMクライアントの初期化（AWSの権限操作用）
iam_client = boto3.client('iam')
def lambda_handler(event, context):
"""
GuardDutyやEventBridgeから渡されたイベントを受け取り、
不審な操作を行ったIAMユーザーのアクセスキーを無効化する関数です。
"""
logger.info("イベントを受信しました: %s", json.dumps(event))
try:
# EventBridge経由で渡されたCloudTrailのイベント詳細から、操作を行ったユーザー名を取得
# ※イベントの構造は連携元によって異なりますが、CloudTrailの基本構造を想定
detail = event.get('detail', {})
userIdentity = detail.get('userIdentity', {})
# 操作を実行したユーザー名（またはロール名）を特定
username = userIdentity.get('userName')
if not username:
logger.warning("操作を行ったユーザー名が特定できませんでした。処理を終了します。")
return {'status': 'No username found'}
# 【セキュリティ上の重要防衛策】
# システム管理用の特権アカウントなど、間違えて止めてはいけないホワイトリスト（除外設定）を設けます
whitelist_users = ['SystemAdminDeployRole', 'MasterAutomatedPipeline']
if username in whitelist_users:
logger.info(f"ユーザー '{username}' はホワイトリストに含まれているため、処理をスキップします。")
return {'status': 'Whitelisted user'}
logger.warning(f"【警告】不審なIAM操作を検知しました！ 該当ユーザー: {username}")
# そのユーザーに紐づいているアクティブなアクセスキーの一覧を取得
response = iam_client.list_access_keys(UserName=username)
access_keys = response.get('AccessKeyMetadata', [])
# 見つかったアクセスキーをすべて「無効 (Inactive)」に変更する
for key in access_keys:
access_key_id = key['AccessKeyId']
current_status = key['Status']
if current_status == 'Active':
logger.info(f"アクセスキー '{access_key_id}' を無効化しています...")
iam_client.update_access_Key(
UserName=username,
AccessKeyId=access_key_id,
Status='Inactive'
)
logger.info(f"成功: アクセスキー '{access_key_id}' を無効化しました。")
# 必要に応じて、SlackやSNS(Amazon SNS)へ管理者へのアラート通知をここに記述します
return {
'status': 'Success',
'message': f'User {username} access keys have been deactivated.'
}
except Exception as e:
logger.error(f"エラーが発生しました: {str(e)}")
raise eコードのポイント
- ホワイトリストの重要性: 自動で鍵を壊す（無効化する）プログラムを作る際、一番怖いのは「本番環境のデプロイ用システムアカウント」を間違えて止めてしまい、会社全体のサービスを止めてしまうこと（自爆攻撃）です。除外設定（ホワイトリスト）は絶対に忘れないようにしましょう！
- 迅速な対応: 人間がSlackを見てからポチポチ操作するのではなく、プログラムがミリ秒単位で動くことで、被害を最小限に食い止めることができます。
—
5. まとめ：今日からできる一歩
いかがでしたでしょうか？ IAM変更ログの監視とLambda連携というと、なんだかすごく難しそうな魔法の技術に聞こえたかもしれませんが、やっていることは「家の防犯カメラが泥棒を見つけて、自動で玄関の補助ロックをガチャンと閉める」という、至ってシンプルな防犯対策です。
最後に、今日から実践できるセキュリティのステップをまとめておきますね。
1. まずはCloudTrailがちゃんと動いているか確認する（全リージョンで有効になっていますか？）
2. GuardDutyを有効化してみる（ポチッとボタンを押すだけで、優秀な警備員が雇えます）
3. 重要度の高いIAM変更（ルートユーザーの使用や、ポリシーの勝手な変更）に気づける環境を少しずつ整える
セキュリティは一度に完璧な城を築く必要はありません。泥棒が入りにくい工夫を、一つずつ積み重ねていきましょう。一歩ずつ、安全なクラウドインフラを作っていきましょうね！
コメント