![[アップデート] Amazon GuardDuty の有効化を AWS Organizations の宣言型ポリシーで一元管理できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-f1f1e80330aaa8917410e012de277155/263838c1009bccfef2d8a98f11615f2d/amazon-guardduty?w=3840&fm=webp)
[アップデート] Amazon GuardDuty の有効化を AWS Organizations の宣言型ポリシーで一元管理できるようになりました
はじめに
先日のアップデートで、Amazon GuardDuty の有効化を AWS Organizations の宣言型ポリシーで一元管理できるようになりました。
これまで Organizations 連携で GuardDuty を使う場合は、委任管理者アカウントでリージョンごとに自動有効化を設定していました。それを全リージョン・全アカウントの有効化を、1 つのポリシーで管理できます。
従来の自動有効化と何が違うのかを整理し、検証用の組織で実際に設定してみたのでまとめます。
アップデートの概要
GuardDuty が、AWS Organizations の宣言型ポリシー（ポリシータイプ GUARDDUTY_POLICY）に対応しました。
委任管理者アカウント（または管理アカウント）でポリシーを作り、組織の root、OU、アカウントのいずれかにアタッチする形です。これは他のポリシーと同様ですね。
アタッチ先のアカウントでは、ポリシーに書いた GuardDuty の機能と保護プランが有効化されます。あとから組織に参加したアカウントや、OU に移動してきたアカウントにも、ポリシーが引き継がれます。
ポリシーは「デフォルト設定」と「リージョンごとの上書き」の 2 つの設定で構成されます。
defaultブロック: GuardDuty が使えるすべてのリージョンに適用される- リージョン名のブロック: そのリージョンだけ
defaultを丸ごと置き換える
default を省略した場合は、名前を書いたリージョン以外はポリシーの管理対象外になります。
ポリシーで有効/無効を管理できる機能は次のとおりです。
| ポリシーのキー | 機能 |
|---|---|
foundational |
基本的な脅威検出（Foundational） |
s3_data_events |
S3 Protection |
eks_audit_logs |
EKS Protection |
ebs_malware_protection |
Malware Protection for EC2 |
rds_login_events |
RDS Protection |
lambda_network_logs |
Lambda Protection |
runtime_monitoring |
Runtime Monitoring（EKS、ECS Fargate、EC2 のエージェント管理を含む） |
ai_protection |
AI Protection |
同じブロックの中で他の機能を有効にする場合は、foundational も有効にしておく必要があります。
対応リージョンは、すべての商用リージョンと AWS GovCloud (US) リージョンです。
これまでと何が変わったのか
従来の自動有効化と比べると、次のようになります。
| 項目 | 従来の自動有効化 | 組織ポリシー |
|---|---|---|
| 適用する範囲 | 組織全体に一律。OU やアカウントごとには分けられない | root、OU、アカウントごとにアタッチできる |
| リージョン | 使うリージョンごとに設定する | default で全リージョン、必要なリージョンだけ上書き |
| 新しいリージョン | 個別に設定する | default を使っていれば自動で対象になる |
| 新しいアカウント | 自動有効化の設定に従う | アタッチ先に入ったアカウントがポリシーを引き継ぐ |
| アカウント単位の変更 | 委任管理者は Accounts ページからアカウントごとに変更できる。メンバーアカウントは変更できない | ポリシーが管理する保護プランは、委任管理者もコンソールや API から変更できない。ポリシーを更新して変える |
このようにポリシーによって個別に設定していた部分を、まとめて管理できるようになりました。分かりやすいメリットとしては以下です。
リージョンごとに設定して回らなくてよい
新しいリージョンが増えた場合も、default を使っていれば自動で対象になり、リージョンごとの設定のずれを気にしなくてよくなります。
OU ごとに保護プランを変えられる
root に組織全体の基準となるポリシーを置き、特定の OU にだけ別のポリシーをアタッチする、といった使い方ができます。
複数のポリシーが効く場合は、上位と下位のポリシーがマージされます。同じ保護プランを両方で指定していれば、アカウントに近い階層の設定が優先されます。
1 つのポリシーで適用範囲を把握できる
従来の自動有効化でも、保護プランごとに全アカウントへ一括で有効化できました。
ただ、設定はリージョンごとに分かれていたので、どのリージョンで何が有効になるかは各リージョンの設定を見て回る必要がありました。
ポリシーでは、アタッチ先（root、OU、アカウント）、リージョン、保護プランが 1 つの JSON にまとまります。
どこに何が効いているかを、ポリシーを見れば把握できます。
やってみた
検証環境
検証用の Organizations 環境で試してみます。
今回は以下の前提で進めてみました。
- ポリシーの管理は、GuardDuty の委任管理者アカウントへ任せる構成にする
- 委任ポリシーの更新は管理アカウント、ポリシーの作成は委任管理者アカウントで行う。どちらも東京リージョンの GuardDuty コンソールから操作する
- もともと自動有効化を設定してあり、メンバーアカウントでは S3 Protection や RDS Protection などが有効になっている
- ポリシーは、メンバーアカウント 1 つだけにアタッチする
管理アカウントで委任ポリシーを更新する
委任管理者アカウントの GuardDuty コンソールを開くと、ナビゲーションに「Organization Policies」が追加されています。
ただ、開いてみると「Create policy」は選べず、次のメッセージが表示されていました。
Your delegated administrator cannot configure GuardDuty policies.
Your management account has not updated the delegation policy with required permissions. Contact your management account administrator to update the delegation policy from the GuardDuty Settings page.
委任ポリシーの更新が必要です。
メッセージの案内どおり、管理アカウントの GuardDuty コンソールで「設定」を開きます。
「Delegation policy」というセクションがあり、委任管理者に権限が足りていない旨が表示されていました。
「Attach statement」を選ぶと、GuardDuty が委任ポリシーに必要な Statement を自動で追記してくれます。
「Copy and attach」で JSON をコピーし、自分で貼り付けることもできます。
「Attach statement」を押すと、追記される内容の差分が表示されます。
確認のチェックを入れて「Attach policy」を選びます。
既存の Statement はそのまま残り、5 つの Statement が追記されました。
設定前の状態
委任ポリシーを更新したあと、委任管理者アカウントで「Organization Policies」を開き直すと、「Create policy」を選べるようになりました。
画面上部には、ポリシーを作るときにポリシータイプが有効になる旨が表示されています。
The GuardDuty organization policy type in AWS Organizations will be enabled during policy creation.
ポリシーを作ってアタッチする
「Create policy」をクリックしてポリシー作成を進めます。
なお、Organizations コンソールの「Amazon GuardDuty policies」ページから JSON を直接書いて作ることもできます。
Step 1 でポリシー名を入れます。
Step 2 でアタッチ先を選びます。
組織全体、特定の OU やアカウント、アタッチしない、の 3 つから選べます。
今回は「Specific organizational units and accounts」で、メンバーアカウント 1 つだけを選びました。
Step 3 で保護プランを選びます。
ここで設定する「Default configuration」が、ポリシーの default ブロックになります。画面にも「This configuration applies to all AWS Regions.」と書かれています。
選ばなかった保護プランは、このポリシーの管理対象になりません。今回は Foundational GuardDuty と S3 Protection を選びました。
Step 4 はリージョンごとの上書きです。「Add regional override」で東京リージョンを選びます。
default で選んだ Foundational GuardDuty と S3 Protection には、あらかじめチェックが入っていました。
上書きは default を丸ごと置き換えるため、画面にも「All features must be specified.」と表示されています。この 2 つはそのまま有効にし、今回は EKS Protection を追加して「Enable」にしました。
Step 5 の「Review and create」で、「Policy document」を展開すると生成された JSON を確認できます。
今回の設定では次のようになりました。
{
"guardduty": {
"enablement": {
"default": {
"foundational": { "status": { "@@assign": "enabled" } },
"s3_data_events": { "status": { "@@assign": "enabled" } }
},
"ap-northeast-1": {
"foundational": { "status": { "@@assign": "enabled" } },
"s3_data_events": { "status": { "@@assign": "enabled" } },
"eks_audit_logs": { "status": { "@@assign": "enabled" } }
}
}
}
}
default が全リージョン共通のベースライン、ap-northeast-1 が東京リージョンのみの上書き設定です。
「Create policy」を選ぶと、無事ポリシーを作成できました。
設定後の状態
Accounts ページを見て設定がどう変わったのかを確認してみます。
ポリシーをアタッチしたアカウントだけ、ステータスが「有効 (Policy managed)」になりました。
私の環境では、ポリシーを作ってから 1 分ほどで表示が変わっていました。
保護プランの列を見ると、ポリシーで管理している S3 Protection にも「(Policy managed)」が付いていました。
一方、ポリシーに含めていない RDS Protection は、元の「有効」のままでラベルも付いていません。ポリシーは保護プランごとに管理する仕組みのようです。
アタッチしたアカウントを選んで「保護プランを編集」から S3 Protection を開くと、有効化と無効化の操作がグレーアウトしていました。
委任管理者からも、ポリシーが管理する保護プランは変更できません。
All 1 selected account(s) have this feature managed by a configuration policy. Update the policy to change this setting.
組織の自動有効化の設定も見てみます。
保護プランごとの「新しいアカウントについて自動有効化」に、すべて「(Policy managed)」が付いていました。
ポリシーに含めていない RDS Protection や、もともと自動有効化していなかった Runtime Monitoring も同じです。
表示されている値は、ポリシーを作る前の自動有効化の設定がそのまま残ったものです。
ドキュメントには、ポリシータイプを有効にすると、ポリシーをアタッチしたかどうかに関係なく、リージョン単位の自動有効化は適用されなくなると書かれています。
「Enable for all accounts (Policy managed)」は、ポリシーが全アカウントで有効化しているという意味ではないので注意しましょう。
自動有効化の設定が今は効いていない、という意味で読むのがよさそうです。
最後に、大阪リージョンも確認しました。
アタッチしたアカウントでは、default に書いた S3 Protection が「(Policy managed)」になっていました。
東京だけで指定した EKS Protection は、大阪では「(Policy managed)」になっていません。
default は全リージョンに、リージョンの上書きはそのリージョンだけに効いていることを確認できました。
注意点
最初のポリシーを作った時点で、もともとあった組織の自動有効化が止まる
GUARDDUTY_POLICY ポリシータイプを有効にすると、ポリシーをアタッチする前でも、リージョン単位の自動有効化は適用されなくなります。
GuardDuty のコンソールでは、最初のポリシーを作るとポリシータイプが自動で有効になります。
試しにポリシーを 1 つ作っただけで、組織全体の自動有効化が止まることになります。
今回の検証では１アカウントのみへのアタッチでしたが、組織の自動有効化の設定にはすべて「(Policy managed)」が付きました。
root にポリシーをアタッチしていれば、新しいアカウントもポリシーで有効化されます。
困るのは、今回のように一部にだけアタッチした状態で、ポリシーの範囲外にアカウントが加わる場合です。
既存の自動有効化に頼って新しいアカウントを有効化している場合は、最初のポリシーを作る前に、新しいアカウントもポリシーの範囲に入るようにアタッチ先を決めておきましょう。
「無効化」「デタッチ」「ポリシータイプの無効化」の動作の違いに注意する
元に戻したいときの操作は 3 つあり、効果が異なります。ドキュメントの記述をまとめると次のとおりです。
| 操作 | 対象アカウントの GuardDuty | 新しいアカウント | リージョン単位の自動有効化 |
|---|---|---|---|
ポリシーで disabled を指定する |
無効になり、コンソールや API から有効にできなくなる | ポリシーに従う | 止まったまま |
| ポリシーをデタッチする | 現在の状態のまま残る | 自動では有効にならない（上位の階層に別のポリシーが残っていれば、その範囲では適用が続く） | 止まったまま |
| ポリシータイプを無効にする | 現在の状態のまま残る | 自動有効化の設定に従う | 元の設定で再開する |
従来の自動有効化に戻したい場合は、ポリシータイプを無効にしましょう。ポリシータイプを無効にすると、そのタイプのポリシーは自動でデタッチされます。削除はされません。
デタッチやポリシータイプの無効化をしても、ポリシーで有効になった GuardDuty や保護プランは有効なまま残ります。止めたい場合は、別途無効化が必要です。
なお、ポリシーで disabled を指定すると、現在有効なアカウントでも保護プランが止まります。
保存する前に、どのアカウントとリージョンが影響を受けるかを Accounts ページなどで確認しておきましょう。
コンソールで作ると default が入り、全リージョンで課金が発生しうる
コンソールの Step 3 で選んだ保護プランは、ポリシーの default として全リージョンへ適用されます。
ポリシーをアタッチすると、GuardDuty のメンバーでなかったアカウントでも GuardDuty と保護プランが自動で有効化され、対象のリージョンすべてで料金がかかります。
また、GuardDuty は CloudTrail のグローバルサービスイベントを有効なすべてのリージョンで処理するため、リソースのないリージョンでも料金が発生します。
特定のリージョンだけを管理したい場合は、default を省略してリージョン名のブロックだけを書く方法がドキュメントで紹介されています。
ポリシー管理に移行するときに気をつけること
自動有効化で設定できる保護プランは、ポリシーでもほぼ同じ範囲を管理できます。
ただし、組織の自動有効化とポリシーは併用できません。
ポリシータイプを有効にした時点で、自動有効化の設定は保護プランごとではなく、組織全体でまとめて効かなくなります。
そのため、移行するときは次の点に気をつけましょう。
| 気をつけること | 対応 |
|---|---|
| ポリシーの範囲外に加わったアカウントは、自動で有効化されない | 新しく加わるアカウントも含めてカバーできるよう、root や OU にアタッチする |
| ポリシーに書かなかった保護プランは、新しいアカウントで自動有効化されない | 自動有効化で使っていた保護プランは、すべてポリシーに書く |
| IaC で管理している自動有効化の設定が効かなくなる | IaC で管理する対象を、自動有効化の設定からポリシーに移すかを決めておく |
今回の検証でも、ポリシーに含めていない RDS Protection の自動有効化の設定に「(Policy managed)」が付いていました。
まとめ
GuardDuty の有効化を、AWS Organizations の宣言型ポリシーで一元管理できるようになりました。
ポリシーが管理する保護プランはポリシーを更新しない限り変更できないので、基準を固定しておきたい環境に向いています。
一方で、最初のポリシーを作った時点で組織の自動有効化は止まり、ポリシーの範囲外に加わったアカウントは自動で有効化されなくなります。
既存の自動有効化を使っている組織では、どこまでをポリシーに任せるかを決めてから、最初のポリシーを作るのがよさそうです。
以上、鈴木純がお送りしました。
参考
- Amazon GuardDuty now supports centralized management using AWS Organizations declarative policies
- Managing accounts using organization policies - Amazon GuardDuty
- Considerations and limitations - Amazon GuardDuty
- Amazon GuardDuty policies - AWS Organizations
- [アップデート] AWS Organizations でメンバーアカウントの GuardDuty 自動有効設定の方法が変わりました
