クラウドの「盲点」を突く侵入者：GuardDutyで検知するAPIの異常と、現場で生き残るための防御術
「ログを取っているから大丈夫」。そう思っている君のシステムが、深夜2時に静かに踏み台にされているとしたらどうする？
インシデント対応の現場に立つと痛感するんだが、多くのエンジニアは「ログを保存すること」をゴールにしている。だが、攻撃者はそのログの隙間を縫って、CloudTrailのイベントを消去したり、VPCの外へ静かにデータを持ち出したりする。今日は、AWSにおける「攻守の最前線」であるGuardDutyを軸に、実務で本当に使えるログ監視と防御の勘所を叩き込む。
—
1. なぜ「設定しただけ」のGuardDutyでは足りないのか
GuardDutyは優秀だ。特に「UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom」といった検知は、攻撃者が既知の脅威インテリジェンスと一致した際に即座に発報してくれる。
だが、現場の盲点は「攻撃者は最初から権限を奪いに来ない」という点にある。まずは低権限のIAMロールを奪い、そこから「列挙（Enumeration）」を繰り返して特権を探す。この「じわじわとした偵察」を検知するには、GuardDutyの検知結果をトリガーにして、自動的に隔離・調査を行うパイプラインが不可欠だ。
—
2. 実践：攻撃者の手口と防御の自動化
攻撃者は、まず DescribeInstances や ListBuckets を乱発し、環境の全容を探る。この不審なAPIコールを検知し、即座に当該IAMロールを無効化するフローを構築しよう。
Step 1: AWS EventBridgeで検知をトリガーする
GuardDutyの検知結果をLambdaに飛ばし、自動的にIAMユーザーをロックする設定だ。
CloudFormation/SAM テンプレートの一部
GuardDutyの特定の脅威タイプをトリガーにLambdaを起動する設定
GuardDutyEventRule:
Type: AWS::Events::Rule
Properties:
EventPattern:
source:
- “aws.guardduty”
detail-type:
- “GuardDuty Finding”
detail:
type:
- “UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom” # 悪意あるIPからのアクセス
Step 2: Pythonによる自動隔離スクリプト
検知されたIAMユーザーに「ポリシーを剥奪し、無効化する」スクリプトだ。これをLambdaに載せる。
import boto3
def lambda_handler(event, context):
iam = boto3.client(‘iam’)
# GuardDutyのイベント詳細からIAMユーザー名を取得
iam_user = event[‘detail’][‘resource’][‘accessKeyDetails’][‘userName’]
# 1. 既存の全ポリシーをデタッチ（即時権限剥奪）
attached_policies = iam.list_attached_user_policies(UserName=iam_user)[‘AttachedPolicies’]
for policy in attached_policies:
iam.detach_user_policy(UserName=iam_user, PolicyArn=policy[‘PolicyArn’])
# 2. ログイン禁止ポリシーをアタッチ（念押し）
# ※事前に「ログイン拒否」用ポリシーを作成しておくこと
iam.put_user_policy(
UserName=iam_user,
PolicyName=’DenyAllAccess’,
PolicyDocument='{“Version”: “2012-10-17”, “Statement”: [{“Effect”: “Deny”, “Action”: “”, “Resource”: “”}]}’
)
print(f”User {iam_user} has been quarantined.”)
—
3. アプリケーション層での「ログの空白」を埋める
インフラ側でGuardDutyを固めても、アプリケーション自体が脆弱なら無意味だ。特に、最近多いのが「SSRF（Server-Side Request Forgery）」を利用したAWSメタデータサービス（IMDSv2）へのアクセスだ。
攻撃者はアプリケーションの脆弱性を突き、http://169.254.169.254/latest/meta-data/iam/security-credentials/ を叩いて認証情報を盗もうとする。これを防ぐには、EC2/ECSの設定でIMDSv2を必須化し、セッションを保護するのが鉄則だ。
WAFでの防御設定（Nginx/CloudFront）
もし君がPHP等でアプリを組んでいるなら、リクエストヘッダーを厳格にチェックすべきだ。
NginxでSSRFの踏み台を防ぐ設定例
location / {
# 内部IPへのリクエストをブロックするWAF的アプローチ
if ($http_x_forwarded_for ~ “169.254.169.254”) {
return 403;
}
# 適切なセキュリティヘッダーの付与
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;
proxy_pass http://backend_app;
}
—
最後に：セキュリティは「設定して終わり」のタスクではない
いいかい、セキュリティは「完成品」ではない。攻撃者が手法を変えれば、君の監視ロジックも変えなければならない。
1. GuardDutyのコンソールを毎日見ろ。 「重要度：低」の検知が、実は大惨事の予兆であることは珍しくない。
2. IAMは最小権限の原則を守れ。 自動隔離スクリプトを書くほど、強すぎる権限を付与している自分を反省する機会にもなる。
3. 自動化を恐れるな。 手動で対応している間にデータは抜き取られる。信頼できる検知ロジックを作ったら、迷わず自動化してシステムに組み込むんだ。
セキュリティエンジニアとして一番大切なのは、技術力以上に「疑い続ける姿勢」だ。君が構築したこの強固な城が、明日には別の形に進化していることを期待しているよ。また現場で会おう。
コメント