こんにちは。枡川です。
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: DISABLEDTerraform の場合
現状は dataSources しか使えないようです。(AWS Provider v5.7.0 で非対応)
issue は立っているので、いずれ対応されることが想定されます。
まとめ
各機能ごとの設定方法が統一されて、非常に使いやすくなったように感じております。
すでにスクリプトや IaC のテンプレートを作りこんでいる場合はどこかのタイミングで移行することを推奨します。
12
