セキュリティ専用アカウントで GuardDuty・Inspector をコントロールOrganizations と Security Hub で全リージョンを集約し、Slack とメールに通知

1. なぜセキュリティ専用アカウントを分けるのか

「全部の検出結果を 1 か所で見る」だけなら、組織の管理アカウントで見る手もあります。それでもあえて専用のアカウントを作るのには、理由が 3 つあります。

2. 全体像 ─ 3 つのサービスと委任管理者

使うサービスは 3 つです。それぞれ役割が違います。

これらを組織全体で動かすときの鍵が委任管理者(delegated administrator)です。管理アカウントが「このサービスの組織全体の管理は moobon-security に任せる」と指定すると、moobon-security から全メンバーアカウントの有効化と検出結果の閲覧ができるようになります。

[ 管理アカウント ]  … 委任管理者を指定するだけ(以後はほぼ触らない)
        │
        ▼ 委任
[ moobon-security ]  … GuardDuty / Inspector / Security Hub の委任管理者
        │  ▲
        │  │ 検出結果が自動で集まる(組織のアカウント × 全リージョン)
        │  │
        │  ├── [ 管理アカウント ]
        │  └── [ 自社サービス用のアカウント ]
        │
        ▼ Security Hub(東京に全リージョンを集約)
        ▼ GuardDuty の重要度 MEDIUM 以上だけ
  EventBridge → SNS → メール / Slack(Amazon Q Developer)

3. moobon-security アカウントを作る

ここからの 3〜4 章は管理アカウントで実行します。まず組織の中に新しいアカウントを作ります。

# 管理アカウントで実行
aws organizations create-account \
  --email aws-security@example.com \
  --account-name moobon-security

# 作成の進み具合を確認(State が SUCCEEDED になれば完了)
aws organizations list-create-account-status --states SUCCEEDED IN_PROGRESS

• メールアドレスは個人ではなく共有の宛先に。このアドレスがアカウントのルートユーザーになります。担当が替わっても受け取れる、グループのアドレスにしておきます。
• Security OU に移す。ワークロード用のアカウントとは別の OU にしておくと、後から SCP をかけ分けやすくなります。

# Security OU を作って、moobon-security を移す
aws organizations create-organizational-unit \
  --parent-id <ROOT_ID> --name Security

aws organizations move-account \
  --account-id <SECURITY_ACCOUNT_ID> \
  --source-parent-id <ROOT_ID> \
  --destination-parent-id <SECURITY_OU_ID>

ログインは、IAM Identity Center(SSO)で moobon-security に Permission Set を割り当てて行います。ルートユーザーには MFA を設定し、ふだんは使いません。SSO の設定は、姉妹記事 AI 開発現場で IAM ユーザーをやめる ── AWS SSO + AssumeRole で詳しく書いています。

# ~/.aws/config に moobon-security 用のプロファイルを追加
[profile moobon-security]
sso_session = moobon-sso
sso_account_id = <SECURITY_ACCOUNT_ID>
sso_role_name = AdministratorAccess
region = ap-northeast-1

4. 管理アカウントで委任管理者を指定する

管理アカウントでやる作業は、実質ここまでです。3 つのサービスそれぞれで、moobon-security を委任管理者に指定します。

# 管理アカウントで実行
SEC=<SECURITY_ACCOUNT_ID>

# Security Hub(集約先のリージョン = ap-northeast-1 で 1 回)
aws securityhub enable-organization-admin-account \
  --admin-account-id $SEC --region ap-northeast-1

# GuardDuty と Inspector はリージョンごとに指定が必要
for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws guardduty enable-organization-admin-account \
    --admin-account-id $SEC --region $r
  aws inspector2 enable-delegated-admin-account \
    --delegated-admin-account-id $SEC --region $r
done

5. GuardDuty を組織全体で有効化する

ここからは moobon-security で実行します。委任管理者に指定されると、moobon-security 自身の GuardDuty は有効になっています。あとは、組織のアカウントをメンバーとして追加します。

# moobon-security で実行(リージョンごと)
DET=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text \
        --profile moobon-security)

# 組織のアカウントをメンバーに追加(組織内のアカウントなら招待メールは不要)
aws guardduty create-members \
  --detector-id $DET \
  --account-details AccountId=<ACCOUNT_ID_1> AccountId=<ACCOUNT_ID_2> \
  --profile moobon-security

# メンバーが揃ったか確認(RelationshipStatus が Enabled になっていれば OK)
aws guardduty list-members --detector-id $DET --profile moobon-security \
  --query 'Members[].[AccountId,RelationshipStatus]' --output table

MOOBON は管理アカウントを含めて数個のアカウントなので、メンバーを個別に追加しています。アカウントがよく増える組織なら、update-organization-configuration で --auto-enable-organization-members ALL を指定しておくと、既存のアカウントも、これから組織に入るアカウントも自動で対象になります。

6. Inspector を組織全体で有効化する

Inspector は、これから組織に入るアカウントを自動で有効化する設定と、既存のアカウントを有効化する操作が別になっています。自動有効化の設定だけでは、既存のアカウントはスキャンされません。

# moobon-security で実行
# ① これから入るアカウントを自動で有効化
aws inspector2 update-organization-configuration \
  --auto-enable ec2=true,ecr=true,lambda=true \
  --profile moobon-security

# ② 既存のアカウントをメンバーにして、スキャンを有効化
for acct in <ACCOUNT_ID_1> <ACCOUNT_ID_2>; do
  aws inspector2 associate-member --account-id $acct --profile moobon-security
done
aws inspector2 enable \
  --account-ids <ACCOUNT_ID_1> <ACCOUNT_ID_2> \
  --resource-types EC2 ECR LAMBDA \
  --profile moobon-security

コンソールなら、Inspector の「アカウント管理」画面にある「すべてのアカウントをアクティブ化」で同じことができます。

7. Security Hub に集約する

GuardDuty と Inspector の検出結果は、Security Hub を有効にしたアカウントでは自動的に Security Hub に送られます。あとは、①全リージョンの結果を 1 つのリージョンに集め、②組織のアカウントをメンバーにする、の 2 つを設定します。

① 全リージョンの結果を東京に集める

# moobon-security の ap-northeast-1 で実行
aws securityhub create-finding-aggregator \
  --region-linking-mode ALL_REGIONS \
  --region ap-northeast-1 --profile moobon-security

これで東京リージョンが集約リージョンになり、ほかのリージョンの検出結果もここに集まります。この集約が、8 章の通知を直すときの鍵になります。

② 組織のアカウントをメンバーにする

aws securityhub create-members \
  --account-details '[{"AccountId":"<ACCOUNT_ID_1>"},{"AccountId":"<ACCOUNT_ID_2>"}]' \
  --profile moobon-security

aws securityhub list-members --only-associated --profile moobon-security \
  --query 'Members[].[AccountId,MemberStatus]' --output table

設定チェックの基準は、AWS 基礎セキュリティのベストプラクティス(FSBP)と CIS AWS Foundations Benchmark を有効にしています。アカウント数が多い組織なら、中央設定(Central configuration)で「どの基準を使うか」をポリシーとして組織のルートや OU に関連づけると、新しいアカウントにも同じ設定が自動で適用されます。

8. 通知 ─ 東京しか拾えていなかった

1 画面にまとまっても、画面を開かなければ気づけません。最後に、対応が必要なものがメールと Slack に届くよう通知を作ります。条件は「GuardDuty の検出で、重要度が MEDIUM(4)以上」に絞りました。Inspector と設定チェックは件数が多いので、通知ではなく画面で片づけます。

最初に作った通知 ── GuardDuty のイベントを直接拾う

最初は、よく紹介されている形で、GuardDuty のイベントを EventBridge で直接拾うルールを東京リージョンに作りました。

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [{ "numeric": [">=", 4] }] }
}

届け先は SNS トピックを 2 つ。1 つはメール用で、EventBridge の入力トランスフォーマーで日本語の本文に組み立てています。もう 1 つは Slack 用で、Amazon Q Developer in chat applications(旧 AWS Chatbot)につないで #aws-security チャンネルに流しています。

東京でサンプルの検出を発生させるとメールも Slack も届き、これで完成だと思っていました。

落とし穴 ── 東京以外の検出は、どこにも届かない

記事にまとめるために設定を見直していて、気づきました。GuardDuty のイベントは、検出が起きたリージョンの EventBridge にしか届きません。東京にルールを 1 つ置いただけでは、たとえばオレゴン(us-west-2)で起きた検出は、どこにも通知されないのです。

直し方 ── 通知の起点を Security Hub に変える

各リージョンにルールを作って東京へ転送する方法もありますが、MOOBON では 7 章で全リージョンの検出結果を Security Hub の東京に集約済みでした。それなら、Security Hub が取り込んだ検出結果のイベントを東京で拾えば、ルール 1 つで全リージョンを拾えます。下記を pattern.json として保存します。

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "ProductName": ["GuardDuty"],
      "Severity": { "Label": ["MEDIUM", "HIGH", "CRITICAL"] },
      "Workflow": { "Status": ["NEW"] },
      "RecordState": ["ACTIVE"]
    }
  }
}

# moobon-security の ap-northeast-1(集約リージョン)で実行
aws events put-rule \
  --name securityhub-guardduty-medium-plus \
  --event-pattern file://pattern.json \
  --profile moobon-security

aws events put-targets \
  --rule securityhub-guardduty-medium-plus \
  --targets file://targets.json \
  --profile moobon-security

Security Hub の検出結果は ASFF という共通形式なので、メール本文を組み立てる入力トランスフォーマーの参照先も書き換えます。検出結果は detail.findings[0] の下に入っています。

// targets.json(メール用ターゲットの入力トランスフォーマー部分)
"InputPathsMap": {
  "acct":   "$.detail.findings[0].AwsAccountId",
  "region": "$.detail.findings[0].Region",
  "sev":    "$.detail.findings[0].Severity.Product",
  "label":  "$.detail.findings[0].Severity.Label",
  "type":   "$.detail.findings[0].Types[0]",
  "title":  "$.detail.findings[0].Title",
  "desc":   "$.detail.findings[0].Description",
  "first":  "$.detail.findings[0].FirstObservedAt",
  "last":   "$.detail.findings[0].LastObservedAt"
},
"InputTemplate": "\"【GuardDuty 検知】重要度 <sev>(<label>)\"\n\"アカウント: <acct>　リージョン: <region>\"\n..."

メール本文には、SSO 経由で moobon-security に入り、該当リージョンの GuardDuty を直接開くリンクも入れています。IAM Identity Center のアクセスポータルの URL に #/console?account_id=…&role_name=…&destination=… を付けると、ログイン後にそのコンソールの画面まで直接飛べます。通知を受けてから画面を開くまでの手間が少ないほど、確認が後回しになりません。

Slack 側は、生のイベントを SNS に流すだけです。Amazon Q Developer は Security Hub のイベントを読みやすい形に整えて投稿してくれるので、追加の設定はいりません。

確認 ── オレゴンでサンプルを発生させる

# 東京以外のリージョンで、重要度 MEDIUM のサンプル検出を 1 件だけ発生させる
DET=$(aws guardduty list-detectors --region us-west-2 \
        --query 'DetectorIds[0]' --output text --profile moobon-security)
aws guardduty create-sample-findings --region us-west-2 \
  --detector-id $DET --finding-types "Recon:EC2/Portscan" \
  --profile moobon-security

結果は、約 1 分で東京のルールが反応し、メールと Slack の両方に届きました。同じタイミングで、古いルール(GuardDuty 直結)は 1 回も反応していません。東京以外の検出を拾えていなかったことが、実際に確かめられた形です。確認できたら古いルールは無効にし(東京の検出が二重に届くため)、サンプルの検出はアーカイブしておきます。

9. 費用とハマりどころ