クラウドインテグレーション部クラウドソリューション2課の川井です。
今回は、AWS Organizations と AWS Security Hubの連携における構成と運用方法について記載します。
本記事では、構成についてのみ記載していきます。
AWS Security Hubは、AWS Organizationsとの連携を行うことで、組織内のすべてのアカウントのセキュリティ状態を一元管理できます。
AWS Security Hubとは、AWSクラウド環境におけるセキュリティの可視化と管理を一元化するサービスです。
自動化された継続的なセキュリティのベストプラクティスチェックによって検出された セキュリティイベントを自動検出して、可視化させます。
AWS 基礎セキュリティのベストプラクティスや、CIS AWS Foundations Benchmarkなどのセキュリティ基準に
基づく自動チェックを実行し、コンプライアンス状態を評価します。
サポートされているセキュリティ基準
参考: Security Hub 標準のリファレンス
以下の画像が実際のコンソール画面で確認した、現在サポートされているセキュリティ基準です。
セキュリティイベントを自動的に分類し、重要度に応じてアラートを生成します。
これにより、優先的に対処すべき問題を迅速に特定できます。
重要度一覧
CRITICAL：この問題はエスカレートしないようすぐに修正する必要あり
HIGH：この問題は優先事項として対処する必要があり
MEDIUM： この問題は対処する必要があるが、緊急ではない
LOW： この問題は単独で対処する必要はない
INFORMATIONAL： 問題は見つからなかった
Amazon GuardDuty、Amazon Inspector、Amazon MacieなどのAWSセキュリティサービスやサードパーティー製品からの
検出結果を統合し、包括的な脅威インテリジェンスを提供します。
つまり、Security Hubと統合したAWSサービスの検出結果を、Security Hubのアラート検出結果の画面に
統合して表示されることができます。以下の画像が統合されているAWSリソース一覧の一部です。
AWS Security Hubは、AWS環境全体のセキュリティ状況を一元的に可視化します。
これにより、異なるAWSアカウントやリージョンにまたがるセキュリティイベントを一箇所で確認できます。
これを実装するには、AWS Organizationsと連携が必須になります。
Security Hubを有効化（使用）する上で、AWS Config の有効化が必須になります。
何故ならば、Security Hubを有効化するとAWS Config内に選択したセキュリティ基準に沿って、Security Hubにより Configルールが自動的に作成されます。
Security Hubのセキュリティチェックは、一部 Configルールを利用してセキュリティ評価を実行します。
具体的には、Security Hubのコントロールの一部はAWS Configルールをベースにしており、リソースの構成がセキュリティベストプラクティスに従っているかどうかをチェックしているからです。
流れは、以下のようになります。
１．Security Hub:
Security Hubは、AWS Configルールを使用して、リソースの構成がセキュリティ基準に従っているかどうかを評価します。
例えば、「EC2インスタンスに対してセキュリティグループが適切に設定されているか」などのチェックを行います。
２．AWS Configルールの評価:
AWS Configルールは、指定された評価基準に従ってリソースの構成を継続的に監視し、評価結果をSecurity Hubに送信します。
３．結果の統合とレポート:
Security Hubは、AWS Configからの評価結果を統合し、Security Hubのダッシュボードで表示します。
今回は、AWS Organizationsと連携してSecurity Hubを使用する想定です。
また、Security Hubのセキュリティイベントで『CRITICAL』と『HIGH』の重要度アラートを検知した際、通知させるようにします。
この構成のもと、考慮する要素を記載していきます。
まず、Security Hubはリージョン単位のサービスなので、リージョンごとに有効化する必要があります。
例えば、東京と大阪、バージニア北部でリソースを作成しており、全てのリージョンで Security Hubを有効化するのであれば、全てのリージョンでSecurity Hubを有効化する必要があります。
※組織設定の中央設定を用いれば、集約リージョンのホームリージョンの設定のみの対応可能
そして、Security Hubの集約リージョンの設定を用いることで、例えば、東京リージョンに集約させた場合、
他リージョンで発報したアラートを東京リージョンのSecurity Hubのコンソール画面に集約して、見る事が可能なので、
運用する際 アラート確認をする時に各リージョンに移動するなどの手間は回避できます。
設定例は以下の通りです。
バージニア北部リージョンと大阪リージョンのアラートをホームリージョンである東京リージョンで集約させる例です。
次は各アカウント間で、発報したアラート集約の件についてです。
Security Hubでは、AWS Organizationsと連携する事で、複数アカウントのアラートを集約することが可能です。
集約を設定するには、まず管理アカウントを選定し（DefaultではOrganizationsの管理アカウントがSecurity Hubの管理アカウントになっています）、そのアカウントで Security Hubを有効化にします。
次に各アカウントを、メンバーアカウントとして追加して Security Hubを使用するように設定します。
この設定により、全てのアカウントからのアラートが、管理アカウントに集約され、セキュリティアラートを一元管理することができます。
要は、管理アカウントにメンバーアカウントのアラートの検出結果を集約できるということです。
また、先のリージョン集約の設定が管理アカウントに設定されていれば、
管理アカウントの特定リージョンに、全てのメンバーアカウントの各リージョンの検出結果を集約させて見ることが出来ます。
・ 設定上の注意点
管理アカウントにメンバーアカウントの検出結果を集約させるには、管理アカウントのSecurity Hubの設定で、
メンバーアカウントを追加します。しかし複数リージョンで Security Hubを有効にしている場合、
各リージョンごとで、メンバーアカウントへの追加を行わなければなりません。
※組織設定の中央設定を用いれば、集約リージョンのホームリージョンの設定のみの対応可能
集約の流れとして、メンバーアカウントの検出結果は、まず、管理アカウントの各リージョンごとに集約されてきます。
バージニア北部なら管理アカウントのバージニア北部のSecurity Hubで、 東京なら管理アカウントの東京のSecurity Hubで集約されます。
もし集約リージョンの設定を入れていた場合は、
管理アカウントの集約リージョンの設定において、集約リージョンに全て検出結果が集まるという流れになります。
例えば、集約リージョンの設定を東京リージョンにしていれば東京リージョンに全ての検出結果が集約されます。
・ 設定上の考慮点
AWS Organizations と AWS Security Hubの管理アカウントは、同様のアカウントにしないというのが、
AWSのベストプラクティスとなっています。
基本的に、Organizationsの管理アカウントが、Security Hubの管理権限を持っていますので、Security Hubの管理権限を
別のアカウントに委任するというのがAWSの推奨です。また、権限の委任は各リージョンごとに行う必要があります。
※組織設定の中央設定を用いれば、集約リージョンに指定したリージョンは自動的に権限が委任される
組織設定の方法には、以下の2種類があります。
・中央設定（参考：中央設定の使用を開始する）
・ローカル設定（Defaultの設定）
組織設定とは、管理アカウント（委任管理アカウント）でメンバーアカウントのSecurity Hubの設定を一括で行うものです。
例えば、Security Hubの有効化やどのセキュリティ基準を有効化する設定などです。
デフォルトでは、ローカル設定となっていますが、以下の設定画面にあるように推奨は中央設定となっています。
これは、中央設定の方が詳細な設定が可能であり、一括設定がしやすくなるためです。
先にも、※の所で記載していますが、Security Hubの有効化やメンバーアカウント追加処理、
Security Hubの権限委任の設定など一括で設定することが出来ます。
また、この中央設定を使用する場合は、Organizationsの管理アカウントから別のアカウントに、
必ずSecurity Hubの権限委任を行う 必要があります。
余談ですが、Security Hubを運用する上で、
Security Hubの不要なアラートを止める方法として、コントロールの無効化という設定があります。
これは、各アカウントごとで設定する必要があるものなので、各アカウントごとで無効化の設定をしなければなりませんが、
中央設定では管理アカウントでコントロールの設定を一括管理することが出来ます。
以下が中央設定のコントロール画面です。
セキュリティアラートが上がっても気付けなければ意味がなく、
また、Security Hubのコンソール画面に入って確認するというのも手間になるので、重要度『CRITICAL』と『HIGH』のアラートを検知したら、E-mailアドレスないしSlackのチャンネル等に通知を飛ばすという設定をします。
セキュリティアラートが発報する頻度についてですが、 有効化したセキュリティ基準により作成されたコントール（セキュリティルール）によって、再評価（セキュリティチェック）される時間は異なります。
最初にセキュリティ基準を有効化して始めのセキュリティチェックが入ってから、最短で12時間、最長で24時間ごとに、各コントール（ルール）ごとに再評価（セキュリティチェック）されていきます。
つまり、最初にセキュリティチェックが実行されて初期アラートが出てから24時間以内に、セキュリティアラートに対して特に何もアクションしていない場合、
Security Hubによって再評価された際、新たにセキュリティアラートが作成されてアラートが発報されます。
なので、初期アラート（例えば、S3にパブリックなアクセスから接続が許可されている）が検知された際、
何もアクションを取らなかった場合、最長24時間以内に同様のアラートがまた検知されます。
セキュリティアラートを検知するには、EventBridgeを使えば実装することが出来ます。
今回の構成では、セキュリティアラートを管理アカウントの特定のリージョンに集約させていますので、
集約させたアカウントのリージョンにのみEventBridgeを作成すれば問題ありません。
EventBridgeのイベントパターンの例を以下に記載します。
{
"detail": {
"findings": {
"Compliance": {
"Status": ["WARNING", "FAILED"]
},
"ProductName": ["Security Hub"],
"RecordState": ["ACTIVE"],
"Severity": {
"Label": ["HIGH", "CRITICAL"]
},
"Workflow": {
"Status": ["NEW"]
}
}
},
"detail-type": ["Security Hub Findings - Imported"],
"source": ["aws.securityhub"]
}
一部説明を入れると、
Security HubはAWS GuardDutyやAWS Inspector等と統合されています。
なので、Security Hubの検出結果の画面に GuardDutyやInspectorの検出結果も表示されます。
そして、今回は Security Hubの検出結果のみ検知したいので、[ ProductName : [Security Hub] ]の一文を入れています。
また、新しく作成されたアラートのみ検知したいので、[ Workflow : {Status: [NEW]} ]を入れています。
抑制済みのワークフローステータスについては、今後記載する運用の所で説明しますが、ワークフローステータスが抑制済みに変更した場合のものを検知させたくないので、この一文をいれています。
構成ポイントを考慮した上で作成した構成図は以下のようになります。
異なる AWSアカウントやリージョンにまたがるセキュリティイベントを、Security Hubの権限を委任した
委任管理アカウント一か所に集約させ、 重要度が高い（CRITICALとHIGH）アラートを検知させます。
また補足ですが、リージョン集約の設定は管理アカウントで設定したものが各メンバーアカウントに自動的に反映されます。
これは、ローカル設定、中央設定どちらでも同様です。
なので、構成図のメンバーアカウントと管理アカウントのリージョン集約の設定は、先に記載したアラート集約の経路通りで、
委任管理アカウントへのアラート集約の経路とは関係ありません。
ただ単純に各アカウントごとで東京リージョンにアラートが集約される設定となります。
再度、集約の経路を記載すると、以下のようになります。
１．メンバーアカウント及び管理アカウントの検出結果は、委任管理アカウントの各リージョンごとに集約される。
２．委任管理アカウントの集約リージョンの設定において、特定リージョンに全て検出結果が集約される。
構成図通りに設定していきます。
管理アカウントのAWS Organizations の マネジメントコンソールでサービスへ移動します。
Security Hub を 「アクセス有効」 にします。これを行わないとアカウント間でのアラートの集約の連携が出来ません。
東京リージョンで、Security Hubの有効化と、委任先のアカウントを入力します。
セキュリティ基準は、使用したいものを選定してチェックを入れて下さい。
先にも記載した通りで、Security Hubを使用するにはAWS Configの有効化が必要ですので先に有効化しましょう。
また、Configを有効化する際の注意点としては、
ConfigもSecurity Hubと同様リージョン単位のリソースなので、Security Hubを有効化するリージョンごとにConfigも有効化しなければなりません。
委任先のアカウントで、Security Hubを有効化します。また、Configの有効化も行います。
この時点で、委任管理アカウント 及び メンバーアカウントに追加するアカウントのSecurity Hubを有効化するリージョンで、
先にConfigの有効化をしておきましょう。
委任先のアカウントで、集約リージョンの設定をします。集約したいリージョンで行います。
今回であれば、東京リージョンで設定します。
Security Hubを使用するリージョンが明確に決まっているのであれば、ここのチェックはいりません。
委任先のアカウントで、Security Hubの組織設定をします。
Security Hubのコンソール画面の設定にいくと、Defaultがローカル設定になっているので、特に設定を変更する必要はありません。
そして、アカウントをメンバーアカウントに追加した際に Security Hubを有効化したい場合、『Auto-enable accounts』の箇所を有効化にします。
また、セキュリティ基準を有効化したい場合は、『Auto-enable default standards』の箇所を有効化します。
default standardsとは、セキュリティ基準の『AWS 基礎セキュリティのベストプラクティス v1.0.0 』と『CIS AWS Foundations Benchmark v1.2.0』の2つが有効化されます。
ローカル設定では詳細な設定が出来ないため、他のセキュリティ基準も一緒に有効化したい場合は中央設定を使用することをお勧めします。
※ローカル設定では、この設定を各リージョンごとで行う必要があります。
今回の構成であれば、東京と大阪、バージニア北部のリージョンで行います。
また、Security Hubの権限委任も各リージョンごと行う必要があるので、まずは管理アカウントへ行って
Security Hubの有効化と権限委任の設定を行います。
1.『中央設定に変更』
設定に画面で編集を押し、Defaultがローカル設定になっているので、中央設定に変更して設定を開始します。
2.『中央設定のセットアップ（リージョン）』
リージョンの設定は、先に集約リージョンの設定をしていれば反映されているので、確認して続行します。
3.『中央設定のセットアップ（組織の設定）』
カスタマイズしたいので、設定タイプは Security Hub の設定をカスタマイズを選択します。
カスタムポリシーの設定は、Security Hubは有効化にし、
セキュリティ基準は『AWS 基礎セキュリティのベストプラクティス v1.0.0』のみ有効化
コントロール（セキュリティルール）は一旦全て有効化にします。
アカウントの設定は、全てのメンバーアカウントに適応します。
最後に、カスタムポリシー名を設定して、ポリシーを作成します。
※中央設定では、カスタムポリシーで設定した集約リージョンで指定したリージョン 及び 指定したアカウントで
自動的にこのポリシーが適応されています。
今回の構成であれば、各メンバーアカウントの東京と大阪、バージニア北部のリージョンでも、今設定した内容が反映されます。
なので、中央設定で設定をしていれば 各リージョンごとに設定を行う必要がありません。他のリージョンの権限委任も自動的に行ってくれます。
先に記載したEventBridgeのルールイベントパターンを参考に、通知させたい通知先をターゲットに設定をしていただければ良いと思いますので、
EventBridgeの作成ついては省略いたします。
これで構成図通りの設定は完了です。
今回は、AWS Organizationsを使ってSecurity Hubのセキュリティアラートを一元管理する方法を記載しました。
Security Hubは 有効化したけれども、そもそもどういう構成にしたらいいのかよく分からないという方々にとって、
Security Hubの構築方法の一つの例になれば幸いです。
次は、Security Hubを運用する上で考慮する点を記載していきますので、
引き続き、よろしくお願いいたします。
クラウドインテグレーション部
クラウドソリューション2課
川井 康敬