Security Hub中央設定のポリシー継承ルールを確認してみた
2024.02.27こんにちは。たかやまです。
Security Hub中央設定ポリシーの継承ルールについて考える機会があったので、その内容をお伝えします。
さきにまとめ
- ポリシーは
AND条件で評価はされず、優先度の高い1つのポリシーのみ適用される - ポリシーは「
アカウント>子OU>親OU」の優先度順で適用される- 同じ優先度のポリシーが適用された場合、後から適用したポリシーが上書きされる
- OUにポリシーを適用している状態から、単一アカウントのポリシーを外す場合は
セルフマネージドポリシーを適用する
ポリシー継承ルールについて
まず初めに、ポリシーを適用した場合の継承のルールについて確認したいと思います。
以下はAWSのドキュメントから引用した継承ルールの概要です。
- OU:Root (緑) — この OU は、適用されている設定ポリシーを使用します。 - OU:Prod (青) — この OU は OU:Root から設定ポリシーを継承します。 - OU:Applications (緑) — この OU は、適用されている設定ポリシーを使用します。 - Account 1 (緑) — このアカウントは、適用されている設定ポリシーを使用します。 - Account 2 (青) — このアカウントは OU:Applications の設定ポリシーを継承します。 - OU:Dev (黄) — この OU はセルフマネージド型です。 - Account 3 (緑) — このアカウントは、適用されている設定ポリシーを使用します。 - Account 4 (青) — このアカウントは OU:Dev のセルフマネージド型の動作を継承します。 - OU:Test (青) — このアカウントは OU:Root の設定ポリシーを継承します。 - Account 5 (青) — このアカウントは OU:Root の設定ポリシーを継承します。これは、その直接の親である OU:Test には設定ポリシーが関連付けられていないためです。
実際に見てみるとわかりやすいと思うので試してみます。
Organizationsは以下のようなOU構成を用意しています。
Root/
├── 01-Prod/
│ └── Applications/
│ ├── Account1
│ └── Account2
├── 02-Dev/
│ ├── Account3
│ └── Account4
└── 03-Test/
└── Account5
AWSドキュメントに合わせてポリシーは以下を用意しています。
まずは、RootにRoot-policyを適用していきます。
Rootに適用する場合はすべてのアカウントに適用することになります。このとき、02-Devはセルフマネージドで管理したいので組織単位またはアカウントを除外で02-DevのOU IDを指定します。
他のポリシーはOUまたはアカウントごとの適用になるため、特定のアカウントで対象のOUまたはアカウントを指定して適用していきます。
※執筆時点では組織内で選択を利用した適用がうまく機能せず、組織単位またはアカウントを入力を利用することで適用できました
すべてのポリシーを適用した状態がこちらです。
AWSドキュメントに記載されている継承ルール通りポリシーが適用されていることがわかります。
(再掲)
- OU:Root (緑) — この OU は、適用されている設定ポリシーを使用します。 - OU:Prod (青) — この OU は OU:Root から設定ポリシーを継承します。 - OU:Applications (緑) — この OU は、適用されている設定ポリシーを使用します。 - Account 1 (緑) — このアカウントは、適用されている設定ポリシーを使用します。 - Account 2 (青) — このアカウントは OU:Applications の設定ポリシーを継承します。 - OU:Dev (黄) — この OU はセルフマネージド型です。 - Account 3 (緑) — このアカウントは、適用されている設定ポリシーを使用します。 - Account 4 (青) — このアカウントは OU:Dev のセルフマネージド型の動作を継承します。 - OU:Test (青) — このアカウントは OU:Root の設定ポリシーを継承します。 - Account 5 (青) — このアカウントは OU:Root の設定ポリシーを継承します。これは、その直接の親である OU:Test には設定ポリシーが関連付けられていないためです。
Security Hub中央設定ポリシーの場合は、IAMポリシーやサービスコントロールポリシー(SCP)のように複数のポリシーがAND条件で評価されるわけではなく、優先度の高い1つのポリシーのみが適用されることがわかります。
また優先度も小さい単位で適用しているポリシーが優先されるようです。
優先度順としてはアカウント > 子OU > 親OUと覚えればよさそうですね。
気になった部分
ここからは個人的に気になった部分についてまとめていきます。
同じ優先度のポリシーが適用された場合
同じ優先度のポリシーが適用された場合、どのポリシーが適用されるでしょうか。
ここではOverride-policyというポリシーを用意し、Applications OUに適用してみます。
結果としては、後から適用したOverride-policyが上書きする形で適用されました。
これは不意に既存のポリシーを上書きしてしまうことがないように注意が必要そうです。
Root、OU、アカウントに対してすでにポリシーが適用されていないかは、ポリシーのステータスで確認することができます。
適用済みのステータスがついている場合は、ポリシーが直接適用されていることを意味します。継承済みのステータスがついている場合は、親のOUからポリシーが継承されていることを意味します。
AWS CLIで確認する場合は以下のコマンドで確認することができます。
aws securityhub list-configuration-policy-associations
実行例(クリックで展開)
[cloudshell-user@ip-10-130-34-105 ~]$ aws securityhub list-configuration-policy-associations
{
"ConfigurationPolicyAssociationSummaries": [
{
"ConfigurationPolicyId": "a7a0c147-00c8-4b5a-b189-f7aab3137af7",
"TargetId": "xxxxxxxxxxxx",
"TargetType": "ACCOUNT",
"AssociationType": "APPLIED",
"UpdatedAt": "2024-02-27T02:13:16.227000+00:00",
"AssociationStatus": "SUCCESS"
},
{
"ConfigurationPolicyId": "55fe6b79-2d44-4e04-a39d-6b2c52e3b29b",
"TargetId": "r-0orw",
"TargetType": "ROOT",
"AssociationType": "APPLIED",
"UpdatedAt": "2024-02-27T01:54:43.144000+00:00",
"AssociationStatus": "SUCCESS"
},
{
"ConfigurationPolicyId": "4e544185-65dd-40b7-b520-0384cf1ff0ff",
"TargetId": "ou-0orw-se15szmr",
"TargetType": "ORGANIZATIONAL_UNIT",
"AssociationType": "APPLIED",
"UpdatedAt": "2024-02-27T03:01:09.828000+00:00",
"AssociationStatus": "SUCCESS"
},
{
"ConfigurationPolicyId": "SELF_MANAGED_SECURITY_HUB",
"TargetId": "ou-0orw-8ynk65w5",
"TargetType": "ORGANIZATIONAL_UNIT",
"AssociationType": "APPLIED",
"UpdatedAt": "2024-02-27T01:54:35.152000+00:00",
"AssociationStatus": "SUCCESS"
},
{
"ConfigurationPolicyId": "5837ef56-98ce-4fab-9cc3-6df992ed42c0",
"TargetId": "xxxxxxxxxxxx",
"TargetType": "ACCOUNT",
"AssociationType": "APPLIED",
"UpdatedAt": "2024-02-27T02:13:42.274000+00:00",
"AssociationStatus": "SUCCESS"
},
{
"ConfigurationPolicyId": "55fe6b79-2d44-4e04-a39d-6b2c52e3b29b",
"TargetId": "xxxxxxxxxxxx",
"TargetType": "ACCOUNT",
"AssociationType": "INHERITED",
"UpdatedAt": "2024-02-27T01:54:36.326000+00:00",
"AssociationStatus": "SUCCESS"
},
{
"ConfigurationPolicyId": "55fe6b79-2d44-4e04-a39d-6b2c52e3b29b",
"TargetId": "ou-0orw-vsolo6ag",
"TargetType": "ORGANIZATIONAL_UNIT",
"AssociationType": "INHERITED",
"UpdatedAt": "2024-02-27T01:54:27.645000+00:00",
"AssociationStatus": "SUCCESS"
},
{
"ConfigurationPolicyId": "55fe6b79-2d44-4e04-a39d-6b2c52e3b29b",
"TargetId": "ou-0orw-f768s563",
"TargetType": "ORGANIZATIONAL_UNIT",
"AssociationType": "INHERITED",
"UpdatedAt": "2024-02-27T01:54:27.670000+00:00",
"AssociationStatus": "SUCCESS"
},
{
"ConfigurationPolicyId": "55fe6b79-2d44-4e04-a39d-6b2c52e3b29b",
"TargetId": "ou-0orw-44ibzu7z",
"TargetType": "ORGANIZATIONAL_UNIT",
"AssociationType": "INHERITED",
"UpdatedAt": "2024-02-27T01:54:37.561000+00:00",
"AssociationStatus": "SUCCESS"
},
{
"ConfigurationPolicyId": "SELF_MANAGED_SECURITY_HUB",
"TargetId": "xxxxxxxxxxxx",
"TargetType": "ACCOUNT",
"AssociationType": "INHERITED",
"UpdatedAt": "2024-02-27T01:54:33.568000+00:00",
"AssociationStatus": "SUCCESS"
},
{
"ConfigurationPolicyId": "4e544185-65dd-40b7-b520-0384cf1ff0ff",
"TargetId": "xxxxxxxxxxxx",
"TargetType": "ACCOUNT",
"AssociationType": "INHERITED",
"UpdatedAt": "2024-02-27T03:01:08.311000+00:00",
"AssociationStatus": "SUCCESS"
},
{
"ConfigurationPolicyId": "55fe6b79-2d44-4e04-a39d-6b2c52e3b29b",
"TargetId": "ou-0orw-qxn4ap9x",
"TargetType": "ORGANIZATIONAL_UNIT",
"AssociationType": "INHERITED",
"UpdatedAt": "2024-02-27T01:54:41.562000+00:00",
"AssociationStatus": "SUCCESS"
}
]
}
適用済み＝APPLIED継承済み＝INHERITED
適用済みのポリシーがある場合は、継承済みステータスのOU、アカウントに影響がでる可能性があるため、ポリシーを適用して問題ないか事前に確認を実施してください。
OU単位に適用するポリシーの内、単一アカウントのポリシーを外す場合
すべてのアカウントにポリシーを適用する場合は、組織単位またはアカウントを除外で対象のOU、アカウントを指定することで除外できることをお伝えしました。
一方で、特定のアカウントでポリシーを適用する場合は、組織単位またはアカウントを除外の設定項目が確認できません。
（また、セルフマネージドを適用するポリシーを作れるわけでもない）
では、どうやって設定するのかというと組織ツリーから個別にOU、アカウントを選択してセルフマネージドのポリシーを適用することで、ポリシー設定から除外することができます。
除外したいOU、アカウントを選択して編集を選択します。
個別に管理タイプを設定する画面が表示されるので、セルフマネージドを選択して設定を保存します。
AWS CLIで設定する場合は、以下のコマンドで設定することができます。
aws securityhub start-configuration-policy-association \
--configuration-policy-identifier SELF_MANAGED_SECURITY_HUB \
--target '{"AccountId": "xxxxxxxxxxxx"}' # アカウントを指定する場合
さきほどの組織ツリーに戻ると、セルフマネージドのポリシーが適用されていることが確認できます。
ちなみに、セルフマネージドはアカウントに紐づけられている状態なので、この状態から Account2 をOU移動させたとしてもポリシー継承を拒否してしまう点は注意が必要です。
ためしに、 Root-policy を継承している 03-Test OUに Account2 を移動させてみます。
セルフマネージドのまま、Root-policyが継承されていないことがわかります。改めて継承できる状態にしたい場合には、さきほどの管理タイプを設定で一元管理の設定に戻してください。
最後に
ポリシーというとIAMやSCPと同じような評価の仕組みを想像してしまいますが、中央設定ポリシーは他のポリシーとは異なる評価であることがわかりました。
多くのアカウントを管理するOrganizationだと、比例して中央設定ポリシー多くなることが予想されます。
この継承ルールを理解して、適切なポリシー運用を行っていくことが重要になりそうです。
以上、たかやま(@nyan_kotaroo)でした。
![【Security Hub修復手順】[KMS.5] KMSキーはパブリックに公開すべきではありません](https://images.ctfassets.net/ct0aopd36mqt/wp-refcat-img-cea52bc8a6ec5cad9021b38df4a08b9e/24c76ee7c1ae7aa7f9676a59c77f8702/aws-security-hub)
