AWS Security Hub中央設定のポリシー適用範囲と制限事項を確認してみた
みなさん Security Hub 運用されているでしょうか。
Security Hub に中央設定のアップデートがあってからあまり触れていなかったのですが、ポリシーを触ることがあったのでいくつか気になった動作について確認してみました。
中央設定について知りたい方は以下のブログを参照ください。
また、ポリシーの優先順位については以下のブログで詳しく解説されています。
今回気になった観点は以下です。
- ポリシーが適用されている環境でコントロールや標準を操作できるのか
- ポリシーはどのリージョンまで適用されるのか
- ポリシー設定後にセルフマネージドへ切り替えると Security Hub は有効化されたままなのか
これらについて確認してきます。
先にまとめ
- ポリシーが適用されている環境でコントロールやセキュリティ標準を操作できるのか
→ できない。Security Hubの無効化はもちろん、コントロールやセキュリティ標準は変更できない - ポリシーはどのリージョンまで適用されるのか
→ リンクされたリージョンまで。リージョン個別のポリシーは作成できない。 - ポリシー設定後にセルフマネージドへ切り替えると Security Hub は有効化されたままなのか
→ Security Hubが無効化された状態になる。
ポリシーアタッチ後の制限事項を確認してみる
ポリシーをアタッチした環境で、変更できないように制限されているか確認していきます。
ポリシーの準備
まず全てのコントロールを有効化するデフォルトのポリシーとして以下を作成します。対象は全てのアカウントを対象とします。
ポリシーを作成すると、全 OU・アカウントにポリシーが適用されます。適用にはしばらく時間がかかるので待機が必要です。ポリシーのステータスが成功になっていて、ポリシーがアタッチしたものになっていれば OK です。
もし Security Hub を委任しており、管理アカウントの設定が失敗する場合は個別で有効化しておく必要があります。管理アカウントは委任側から有効化できない点に注意しましょう。
適用後に子アカウントを確認してみると、「AWS 基礎セキュリティのベストプラクティス v1.0.0」が有効化され、全コントロールが有効になっていることが確認できました。
コントロールの変更
準備が整ったので、対象のアカウントへログインして動作を確認してみます。
コントロールを無効化しようとしたところ、以下のメッセージでエラーになりました。
サーバーに問題があるため、Security Hub はリクエストを処理できません。後でもう一度試してください。: This account is currently associated with a central configuration policy, so only the administrator can access this operation.
中央設定で管理されているためエラーになっていることが確認できました。
また、無効化されたコントロールを有効化も同じエラーになります。
セキュリティ標準の変更
次にセキュリティ標準を無効化してみます。
Error disabling standards arn:aws:securityhub:ap-northeast-1:111111111111:subscription/aws-foundational-security-best-practices/v/1.0.0: This account is currently associated with a central configuration policy, so only the administrator can access this operation.
こちらも中央設定で管理されていることがわかるメッセージでエラーになりました。
有効化されていない他のセキュリティ標準を有効化しようとしても同じエラーになります。
Security Hubの無効化
Security Hub 自体の無効化はそもそも非活性化されていてコンソールから無効化できませんでした。
試しに CLI で無効化してみましたが、こちらも同じメッセージが出て無効化できませんでした。
$ aws securityhub disable-security-hub
An error occurred (AccessDeniedException) when calling the DisableSecurityHub operation: This account is currently associated with a central configuration policy, so only the administrator can access this operation.
Security Hub、標準、コントロールそれぞれポリシーの設定からは変更できないことが確認できました。
ポリシーが適用されるリージョン
リンクされたリージョンはポリシー統制がちゃんと効いていることが確認できました。
それ以外のリージョンはどうなんだろうと試した結果、ポリシーの適用範囲は Security Hub がリンクされたリージョンでした。
この環境ではホームリージョンを東京、リンクされたリージョンにバージニア北部、大阪、オハイオを設定しています。
子アカウントへログインしてシドニーリージョンを開いてみると、Security Hub が設定されていない状態でした。このまま有効化してみます。
有効化後にAWS 基礎セキュリティのベストプラクティス v1.0.0
の標準を無効化してみると、エラーとならずに無効化できました。
リンクされたリージョン以外はポリシーの適用範囲外になることが確認できました。
ドキュメントにも以下の記載がありますね。
設定ポリシーは、ホームリージョンとリンクされているすべてのリージョンの関連付けられているアカウントのすべてに影響します。これらのリージョンの一部でのみ有効で、他のリージョンでは有効にならない設定ポリシーを作成することはできません。
リージョン個別の設定はできないことを覚えておきましょう。
集約しているリージョンについては意識しますが、それ以外のリージョンについては忘れがちなのでしっかり SCP などで制御しましょう。
セルフマネージドの動き
中央設定ポリシーとは別にアカウント個別で管理したいケースは、「セルフマネージド」にして独自運用も可能です。
設定画面の組織から、セルフマネージドにしたいアカウントや OU を選択し「編集」をクリックします。
管理タイプから一元管理
とセルフマネージド
が選択できるので、セルフマネージドを選択し適用します。
設定が完了し、適用が成功したら対象のアカウントへログインしてみます。
すると、Security Hub の初期設定から始まりました。セルフマネージドに設定したアカウントは、Security Hubが無効化された状態になるようです。
事前にポリシーを適用し、有効化された環境でもセルフマネージドにすると無効化されるため注意しましょう。
中央設定ポリシーの上限
中央設定ポリシーの上限っていくつなんだろうと、ふと気になったのでドキュメントを探してみました。
クォータのページには記載されていなかったのですが、こちらのドキュメントに記載がありました。
委任管理者は、推奨されるポリシーの代わりに最大 20 件のカスタム設定ポリシーを作成できます。
規模が大きくなり、個別対応等を行うと 20 件は超えるケースがありそうですね。意識しておきましょう。
まとめ
Security Hub の中央設定ポリシーとセルフマネージドの動作について確認してみました。
まとめると以下のようになります。
- ポリシーが適用されているアカウントではセキュリティ標準、コントロールは変更できない
- リンクされたリージョン以外にはポリシーは適用されない
- セルフマネージドを設定すると、Security Hub が無効化された状態になる
こうした仕様を理解した上で中央設定を活用していきましょう。
以上、鈴木純(@jusotech10)がお送りしました。