Security Hub, GuardDuty, Detectiveの自動有効化される組織にセキュリティサービスを利用しているアカウントを追加したときの動作を確認してみた

たかやま

2023.10.02

こんにちは。たかやまです。

Organizationsを利用している環境ではSecurity HubやGuardDuty, DetectiveなどのサービスはOrganizationsと連携して「Organizationsによるアカウント管理」を使い管理を簡単に行うことができます。

Organizationsのアカウント管理にはサービスの自動有効化の機能があり、新規にアカウントが追加された際に自動的にSecurity HubやGuardDuty, Detectiveなどのサービスを有効化することができます。

ただ、新たにOrganizationsに追加するアカウントで既にサービスが有効化されている場合に管理アカウント設定が優先されるのかそれともアカウント側の設定が優先されるのか挙動が気になったので今回はそちらを試してまとめていきたいと思います。

さきにまとめ

Security Hub
- メンバーアカウントでSecurity Hubが有効化されていなければ、 Auto-enable accounts と Auto-enable default standards の設定に合わせて有効化される。
- すでにSecurity Hubが有効化されている場合には Auto-enable default standardsによるセキュリティ基準の有効化は行われない
GuardDuty
- メンバーアカウントでGuardDutyが有効化されていなければ、管理アカウントの設定で有効化される。
- すでにオプションが有効化されている場合も管理アカウントの自動有効化オプションで上書きされる
Detective
- メンバーアカウントでDetectiveが有効化されていなければ、管理アカウント集約された動作グラフが作成される。
- すでにDetectiveが有効化されている場合には管理アカウントに集約されつつ、メンバーアカウント側でも動作グラフが有効化されたままになる。
  - データ料金は集約分とメンバーアカウントの動作グラフ分で2重に発生する

やってみた

Security Hub

管理アカウントの設定

Security Hubの管理アカウントの設定はこちらです

メンバーアカウントの設定

招待前のメンバーアカウントのSecurity Hubの設定はこちらです

招待後のメンバーアカウントの設定

招待後のメンバーアカウントの設定は以下の通りです。

見ていただくとわかる通り管理アカウントでSecurity Hubは管理されている状態になっているはずですが、Auto-enable default standardsで有効化されるはずのセキュリティ基準FSBPとCISv1.2.0が有効化されていないことがわかります。

すでにSecurity Hubが有効化されている状態で招待が行われるとセキュリティ基準の設定は行われないようです。

念のため、メンバーアカウントからSecurity Hubを削除した状態で再度招待を行った場合は無事にセキュリティ基準が有効化されました。

GuardDuty

管理アカウントの設定

GuardDutyの管理アカウント設定はこちらです。
S3 Protection 以外を自動有効化する設定を入れています。

メンバーアカウントの設定

招待前のメンバーアカウントのGuardDutyの設定はこちらです。
メンバーアカウントではS3 Protectionのみ有効化しています。

AWS CLIで確認すると以下のような設定状況です

aws ec2 describe-regions --query "Regions[].[RegionName]" --output text \
 | while read region; do
   detector_id=$(aws guardduty list-detectors --query "DetectorIds[0]" --output text --region ${region} 2>/dev/null)
   if [ $? -eq 0 ] && [ "${detector_id}" != "None" ]; then
     echo "### GuardDuty is enabled in ${region}"
     aws guardduty get-detector \
     --detector-id ${detector_id} \
     --query "{
         S3DataEvents:Features[?Name=='S3_DATA_EVENTS'].Status | [0], 
         EKSAuditLogs:Features[?Name=='EKS_AUDIT_LOGS'].Status | [0], 
         EKSRuntimeMonitoring:Features[?Name=='EKS_RUNTIME_MONITORING'].Status | [0], 
         EKSAddonManagement:Features[?Name=='EKS_RUNTIME_MONITORING'] | [0].AdditionalConfiguration[?Name=='EKS_ADDON_MANAGEMENT'].Status | [0], 
         RDSLoginEvents:Features[?Name=='RDS_LOGIN_EVENTS'].Status | [0], 
         LambdaNetworkLogs:Features[?Name=='LAMBDA_NETWORK_LOGS'].Status | [0],
         EBSMalwareProtection:Features[?Name=='EBS_MALWARE_PROTECTION'].Status | [0]
     }" \
     --output table\
     --region ${region} 2>/dev/null
     aws guardduty list-members \
     --detector-id ${detector_id} \
     --query "Members[].[AccountId,RelationshipStatus]" \
     --output table \
     --region ${region}
   else
     echo "### GuardDuty is disabled in ${region}"
   fi
 done
(中略...)
### GuardDuty is enabled in ap-northeast-1
-----------------------------------------------------------------------------------------------------------------------------------------------
|                                                                 GetDetector                                                                 |
+----------------------+---------------------+---------------+-----------------------+--------------------+------------------+----------------+
| EBSMalwareProtection | EKSAddonManagement  | EKSAuditLogs  | EKSRuntimeMonitoring  | LambdaNetworkLogs  | RDSLoginEvents   | S3DataEvents   |
+----------------------+---------------------+---------------+-----------------------+--------------------+------------------+----------------+
|  DISABLED            |  DISABLED           |  DISABLED     |  DISABLED             |  DISABLED          |  DISABLED        |  ENABLED       |
+----------------------+---------------------+---------------+-----------------------+--------------------+------------------+----------------+
(中略...)

招待後のメンバーアカウントの設定

招待後のメンバーアカウントの設定は以下の通りです。

※他の設定も同様に管理アカウントに制御される状態になっています。

AWS CLIで確認すると以下のような設定状況です

aws ec2 describe-regions --query "Regions[].[RegionName]" --output text \
 | while read region; do
   detector_id=$(aws guardduty list-detectors --query "DetectorIds[0]" --output text --region ${region} 2>/dev/null)
   if [ $? -eq 0 ] && [ "${detector_id}" != "None" ]; then
     echo "### GuardDuty is enabled in ${region}"
     aws guardduty get-detector \
     --detector-id ${detector_id} \
     --query "{
         S3DataEvents:Features[?Name=='S3_DATA_EVENTS'].Status | [0], 
         EKSAuditLogs:Features[?Name=='EKS_AUDIT_LOGS'].Status | [0], 
         EKSRuntimeMonitoring:Features[?Name=='EKS_RUNTIME_MONITORING'].Status | [0], 
         EKSAddonManagement:Features[?Name=='EKS_RUNTIME_MONITORING'] | [0].AdditionalConfiguration[?Name=='EKS_ADDON_MANAGEMENT'].Status | [0], 
         RDSLoginEvents:Features[?Name=='RDS_LOGIN_EVENTS'].Status | [0], 
         LambdaNetworkLogs:Features[?Name=='LAMBDA_NETWORK_LOGS'].Status | [0],
         EBSMalwareProtection:Features[?Name=='EBS_MALWARE_PROTECTION'].Status | [0]
     }" \
     --output table\
     --region ${region} 2>/dev/null
     aws guardduty list-members \
     --detector-id ${detector_id} \
     --query "Members[].[AccountId,RelationshipStatus]" \
     --output table \
     --region ${region}
   else
     echo "### GuardDuty is disabled in ${region}"
   fi
 done
(中略...)
### GuardDuty is enabled in ap-northeast-1
-----------------------------------------------------------------------------------------------------------------------------------------------
|                                                                 GetDetector                                                                 |
+----------------------+---------------------+---------------+-----------------------+--------------------+------------------+----------------+
| EBSMalwareProtection | EKSAddonManagement  | EKSAuditLogs  | EKSRuntimeMonitoring  | LambdaNetworkLogs  | RDSLoginEvents   | S3DataEvents   |
+----------------------+---------------------+---------------+-----------------------+--------------------+------------------+----------------+
|  ENABLED             |  ENABLED            |  ENABLED      |  ENABLED              |  ENABLED           |  ENABLED         |  DISABLED      |
+----------------------+---------------------+---------------+-----------------------+--------------------+------------------+----------------+
(中略...)

GuardDutyの場合はオプションも管理アカウント側で管理される状態になるので、管理アカウントで設定された自動有効化の設定で上書きされる状態になります。

GuardDutyの自動有効化オプションは細かく定義することができるので、環境のユースケースに合わせて定義してください。

[アップデート] Amazon GuardDuty で Organizations の複数アカウントを管理する際に使える保護プランごとの自動有効化オプションが拡張されました | DevelopersIO

Detective

管理アカウントの設定

Detectiveの管理アカウントの設定はこちらです

メンバーアカウントの設定

招待前のメンバーアカウントのDetectiveの設定はこちらです。

招待後のメンバーアカウントの設定

招待後のメンバーアカウントの設定は以下の通りです。

管理アカウントでDetectiveは管理されている状態になっていますが、それとは別にメンバーアカウントでもDetectiveの動作グラフが有効化されたままになっていることが確認できます。

すでにSecurity Hubが有効化されている状態で招待が行われるとセキュリティ基準の設定は行われないようです。

集約されたDetectiveの動作グラフの他にメンバーアカウントの動作グラフが存在する場合には2重にデータ料金が発生するので、メンバーアカウントでDetectiveを閲覧するユースケースがない場合には動作グラフを削除することをおすすめします。

ちなみに、Detectiveが集約された動作グラフだけの場合にはアカウント管理で以下のようにマイ管理者アカウントのみが表示されるような状態になります。

最後に

今回はOrganizationsの自動有効化の挙動について試してみました。

メンバーアカウントの状態によってはOrganizationsの自動有効化のみで期待の状態になるとは限らないので、環境に合わせて設定を行う必要があると思います。

今回試したサービスはSecurity Hub, GuardDuty, Detectiveだけでしたが、他のサービスでもサービス毎に挙動が異なることがあると思うので今後も検証した際には情報を追加していけたらと思います。

以上、たかやま(@nyan_kotaroo)でした。

Security Hub, GuardDuty, Detectiveの自動有効化される組織にセキュリティサービスを利用しているアカウントを追加したときの動作を確認してみた

さきにまとめ