AWS のマルチアカウントにおける Security Hub の運用は Central configuration を使おう

どうもこんにちは西川です。AWS Community Builder に選ばれたからにはAWSのこともアウトプットしなきゃということで、今日は Security Hub の Central configurationの素晴らしさをお伝えしたいと思います。

Security Hub 運用の課題と Central configuration

Cental configuration は re:Invent 2023 で発表された機能で、実は最近までこの機能が追加されていたことに西川は気づいておりませんでした（汗）
でも、この機能はSecurity Hubを運用していくうえでは欠かせない機能で、それはなぜかというと、Automation rules では、OU単位だったり、アカウントについているタグ等を判別してルールを書くことができないのですが、AWSアカウントをOrganization管理していると、Sandbox OUやプロトタイプの実装するアカウントだったり、個人検証用のアカウント（Sandbox OUに入れているかもしれませんが）だったり、色々なケースがあり、そこの統制どうするの？って結構考えるポイントなんですよね。
なぜならば、ちょっとワークショップを試したいとなっても、Security Hubでそんなに危険ではないものまでうわーって検出が上がってしまったりすると、「一時的なものやねん」という気持ちになりますし、そういうこともあるから、こういうアカウントに関してはSecurity Hub自体無効化してもいいかもな、とかルールを緩めてもいいかもな、というお気持ちになるときありますよね。少なくとも私はあります。
そこで使えるのがこのCentral configurationなのです！

Security Hub Central configuration を有効化する際の注意点

すでにSecurity Hubを全アカウントで有効化している状態でCentral configurationを有効化すると、再検出が走ります。つまりAWS Configの料金が掛かるということだけはご認識ください。

またお作法的なこともありまして、Central configurationを有効化したあとは下に添付している画像のような状態となっております。

この状態ではセルフマネージドというポリシーが当てられることになりますが、アカウント所有者が個別で設定をしている状態になっています。それが意図したとおりであればよいのですが、全体管理したいのにもかかわらず、そうなってしまっている場合は注意が必要です。ただし、セルフマネージドが有効なときもあります。それはどんなときかというと、アカウントをすでに停止してしまっていてOrganizationから除外できないときです。そういう状態の場合は、新しいポリシーを当てることができません。そうなるとその上位のOUのポリシーステータスが失敗となってしまいます。そういった場合は、セルフマネージドに変更することでポリシーのステータスを成功にすることができますのでやってみてください。

はい、ということで、まずはデフォルトのポリシーを作りましょう。そして、それをrootアカウントに対して適用してください。そうすることにより、そこに属するOU配下すべてのアカウントに対してそのルールが適用されます。また、それ以降作られるアカウントに対して同じポリシーが自動的に適用されます。

それでは、ポリシーの作成をみていくことにしましょう。

このようになっておりまして、「組織全体でAWSが推奨するSecurity Hubの設定を使用」の設定タイプが推奨されているのですが、これを選ぶとセキュリティ基準は「AWS 基礎セキュリティのベストプラクティス v1.0.0」だけが有効な状態になって変更ができません。それしか使わないのであればよいのですが、そうでない場合は少し微妙です。なので、推奨ではあるもののこれは使わず、「Security Hub の設定をカスタマイズ」　を選択して、セキュリティ基準で自組織で最低限使用するものを選択するようにしましょう。
ちなみになのですが、ここをカスタムせずに「組織全体でAWSが推奨するSecurity Hubの設定を使用」をしてしまうと、ポリシー名が変更できず、configuration-policy-01 というとても微妙な名前のポリシーが最初に作られることになります。（あとから変えられはするし間違ってはいないのですが。。）

設定の確認

問題なく設定できると、各AWSアカウントのSecurity Hub の概要ページで画像のように表示されます

そして、このページでセキュリティ基準を勝手に有効化しようとしても下記のようにエラーがでます。

Central configuration を設定したSecurity Hubの管理を移譲しているアカウントでは、成功すると下記の画像のようにポリシーが当てられていることがわかります。

さらにSecurity OUにはすべてのセキュリティ基準を設定した厳格なポリシーを当てると下記の画像のように、他のOUはgeneral-policyのままですが、Security OUのみrestrict-policyが当たっているのがわかります。

Central configuration のとても良いところ

ここまでで、既にお分かりいただけているかもしれませんが、このCentral configuration のどういうところが良いかというと、まずSecurity Hubをそもそも有効化するかどうかというのを中央管理できるのがとてもよいです。個人検証用アカウントでAWSのワークショップをやってみるとわかりますが、コンプライアンスに違反しているリソースは普通に作られますよね。それでいちいちアラートがあがってくると大変です。しかもそれが開発者全員参加のワークショップの場合とてもノイジーであることは想像に難くありません。なので、そういうOUやアカウントのみSecurity Hubを無効化するという選択ができるのがまず良いです。

また、セキュリティ基準が柔軟に変更できるので、クレジットカードを扱うようなサービスだけはPCI DSSを選択したり、扱わなければ組織のガイドラインにあったセキュリティ基準を選択するということが可能です。つまり、本番環境やステージング環境では厳しめの基準を設定し、開発環境では少し緩めの基準を設定するなど環境に合わせた設定をすることができます。ああ、なんて素晴らしいのでしょう！

さらに今までどおり、その中でも有効化させるコントロールを選んだり、コントロールのパラメーターを調整できたり柔軟な設定が可能なのです！