Security Hubを中央設定へ移行した際にハマったこと

はじめに

Security HubはAWSのセキュリティ状況を可視化する上で非常に便利なサービスです。
2023年11月に中央設定という便利な機能が追加されました。

従来の機能（ローカル設定）では、マルチアカウントで運用している場合においてアカウント毎に標準の追加やコントロールの無効化などを容易に実施することが出来ませんでした。
中央設定はこれらの課題を解決してくれます。

この記事では、元々ローカル設定で動かしていた環境を中央設定へ移行する際にハマったことを説明します。

Security Hub

AWSのセキュリティに関する状況を一箇所でまとめて見ることが出来るサービスです。
機能のひとつに「セキュリティ基準」というものがあり、AWSのベストプラクティスや各種基準（CIS Benchmark、PCI DSSなど）に沿っているかをチェックする機能もあります。
詳細は、以下などをご確認ください。

中央設定とは？

ローカル設定に対して中央設定は以下のような違いがあります。

• ローカル設定
  • Security Hubの管理アカウントからOrganizations配下のメンバアカウントに対して、AWSアカウント作成時に自動有効化することは出来る
  • 自動有効化した際のセキュリティ基準はAWSがデフォルトとして指定しているものだけ
  • 細かな制御は出来ず、実施するためには個々のAWSアカウントおよびリージョンでひとつずつ設定する必要がある
• 中央設定
  • Security Hubの管理アカウントにてポリシーというものを作成し、それをOrganizations配下のメンバアカウントへ適用することが出来る
    • 個々のAWSアカウントおよびリージョンでひとつずつ設定を行う必要がない
  • ポリシーでは適用するセキュリティ基準やセキュリティコントロールを細かく指定出来る（逆にSecurity Hubの無効化を強制することも出来る）

また、クラスメソッドさんのブログが非常に分かりやすかったです。

ハマったこと その1

中央設定ではあらかじめ作成しておいたポリシーを組織やアカウントに適用させる必要があります。
今回の作業で一番大きい組織では100個を超えるアカウントが存在してました。

中央設定の適用はCloudFormationで実施したのですが、適用が完了する前にタイムアウトが発生しロールバックしてしまう事象が発生しました。

AWSサポートに確認したところ、AWS::SecurityHub::PolicyAssociationリソース作成のタイムアウトは約2時間であり、現時点でタイムアウトは延長できないとのことでした。
そのため、代替案としてリソースインポートを用いる方法を紹介されました。
CloudFormation経由ではなく一度手動でポリシー適用を行い、その後にCloudFormationスタックへインポートすることで無事に適用することが出来ました。

ハマったこと その2

いくつかのアカウントに対してポリシー適用が失敗しました。
ログには以下のような内容が記載されてありました。

Policy association failed because standards could not be enabled in Regions <リージョン名>, <リージョン名> and 2 other(s). Check if AWS Config is enabled and properly configured and retry.

これは、Security Hubの管理アカウントで集約リージョンとして指定されているリージョンのうち、AWS Configが有効となっていないケースで発生するようです。
今回は利用可能なリージョンを全て集約リージョンへ含めるようにしていたのですが、Organizations配下で有効なリージョンが統一されていない場合にはこのようなエラーに直面する場合があるかと思います。
中央設定の場合は集約リージョンを個別に設定出来ないため、この点はデメリットと言えるかもしれません。

最後に

中央設定に移行したことで、Security Hubの構成管理が非常にシンプルになりました。
これからもSecurity Hubを活用してセキュリティを高めていきたいです。