GuardDuty の API が変更されてました (dataSources ではなく features を利用して各機能を有効化/無効化することが推奨です )
こんにちは。枡川です。
GuardDuty の各機能を有効化する際の API が 2023 年 3 月に変更されていました。
GuardDuty は継続的に新規機能の追加が行われており、直近では EKS Runtime Monitoring や Lambda Protection などが追加されています。
GuardDuty を有効化する CreateDetector API や設定を変更する UpdateDetector API を利用する際に、各種機能を有効化するか無効化するかを設定することが可能です。
GuardDuty の各種機能を制御するための設定は、旧来 dataSources
オブジェクトを利用しておりましたが、機能ごとの設定方法がより統一された features
オブジェクトを利用することが推奨になっております。
※ アカウント集約時に利用する UpdateMemberDetectors や UpdateOrganizationConfiguration も同様の変更が入っております。
具体的に何が変わったのか
UpdateDetector API の Request Syntax を見るのが一番わかりやすいかと思うので、引用します。
{ "dataSources": { "kubernetes": { "auditLogs": { "enable": boolean } }, "malwareProtection": { "scanEc2InstanceWithFindings": { "ebsVolumes": boolean } }, "s3Logs": { "enable": boolean } }, "enable": boolean, "features": [ { "additionalConfiguration": [ { "name": "string", "status": "string" } ], "name": "string", "status": "string" } ], "findingPublishingFrequency": "string" }
dataSources
オブジェクトでは機能ごとに個別の構造を持っていたのに対して、features
オブジェクトでは各機能ごとの設定方法が統一化されています。
どうしても機能ごとの設定が必要になる部分は存在するかと思いますが、それらは additionalConfiguration
の中で設定する形になっております。
各機能の有効化/無効化は name
と status
を指定して、機能の種類に関わらず設定できるようになっています。
2023 年 7 月時点ではどちらを指定しても機能の有効化/無効化を制御可能です。(API 側の話なので、IaC ツール等が対応していない可能性はあります。)
注意点としては、2023 年 3 月以降に追加された GuardDuty の機能は、features
オブジェクトからのみ設定可能です。
現時点(2023/07)では下記機能が対象になります。
- RDS Protection
- EKS Protection Runtime Monitoring
- Lambda Protection
また、両方を同時に指定するとエラーになります。※ 下記は CLI 実行時のエラー
An error occurred (BadRequestException) when calling the UpdateDetector operation: The request failed because both data sources and features were provided. You can provide only one; it is recommended to use features.
現在の設定内容を確認する GetDetector についても、レスポンスに dataSources
と features
が両方存在する形になります。
{ "createdAt": "string", "dataSources": { "cloudTrail": { "status": "string" }, "dnsLogs": { "status": "string" }, "flowLogs": { "status": "string" }, "kubernetes": { "auditLogs": { "status": "string" } }, "malwareProtection": { "scanEc2InstanceWithFindings": { "ebsVolumes": { "reason": "string", "status": "string" } }, "serviceRole": "string" }, "s3Logs": { "status": "string" } }, "features": [ { "additionalConfiguration": [ { "name": "string", "status": "string", "updatedAt": number } ], "name": "string", "status": "string", "updatedAt": number } ], "findingPublishingFrequency": "string", "serviceRole": "string", "status": "string", "tags": { "string" : "string" }, "updatedAt": "string" }
GuardDuty 有効化時に dataSources
, features
のどちらを使用しても、現在の設定内容を両方の属性から確認可能です。
dataSources
は単純に情報が少ない形になります。
上記を踏まえて、features
を使わない理由が特に無いといった形ですね。
AWS CLI で設定してみる。
今回は下記 json ファイルを用意して、 GuardDuty 有効化時に機能の有効化を制御してみました。
[ { "Name": "S3_DATA_EVENTS", "Status": "ENABLED" }, { "Name": "EKS_AUDIT_LOGS", "Status": "DISABLED" }, { "Name": "RDS_LOGIN_EVENTS", "Status": "ENABLED" }, { "Name": "EKS_RUNTIME_MONITORING", "Status": "DISABLED", "AdditionalConfiguration": [ { "Name": "EKS_ADDON_MANAGEMENT", "Status": "DISABLED" } ] }, { "Name": "LAMBDA_NETWORK_LOGS", "Status": "DISABLED" } ]
上記ファイルを指定して create-detector コマンドを実行することで GuardDuty 有効化時に機能の有効化/無効化を制御可能です。
aws guardduty create-detector --enable --features file://<jsonファイル名>
同様に update-detector コマンドを実行することで既に有効化されているアカウントで機能の有効化/無効化を制御可能です。
aws guardduty update-detector --detector-id <DetectorID> --features file://<jsonファイル名>
CloudFormation で設定してみる。
CloudFormation も同様です。
DataSources
と Features
の両方を指定することが可能ですが、Features
を利用することが推奨になります。
GuardDuty: Type: "AWS::GuardDuty::Detector" Properties: Enable: true Features: - Name: S3_DATA_EVENTS Status: ENABLED - Name: EKS_AUDIT_LOGS Status: DISABLED - Name: EBS_MALWARE_PROTECTION Status: ENABLED - Name: RDS_LOGIN_EVENTS Status: ENABLED - Name: EKS_RUNTIME_MONITORING Status: DISABLED - Name: LAMBDA_NETWORK_LOGS Status: DISABLED
Terraform の場合
現状は dataSources
しか使えないようです。(AWS Provider v5.7.0 で非対応)
issue は立っているので、いずれ対応されることが想定されます。
まとめ
各機能ごとの設定方法が統一されて、非常に使いやすくなったように感じております。
すでにスクリプトや IaC のテンプレートを作りこんでいる場合はどこかのタイミングで移行することを推奨します。