◎概要
今回、Security Hubの構築と運用方法について整理しました。
一先ず、Security Hubは有効化にしたけれども、
どう運用していけばいいのか、そもそもどういう機能なのかよく分からないという方々にとって、Security Hubの構築及び運用方法の一つの例になれば幸いです。
◎Security Hubとは
先ずは、Security Hubとは、そもそもなんなのかというと、
自動化された継続的なセキュリティのベストプラクティスチェックに
よって、検出された Security Hub上のセキュリティアラート（=検出結果）を自動検出して、出力させるもの
と言った感じの説明になるかと思います。
自動化された継続的なセキュリティのベストプラクティスチェック
とは何なのかというと
下記のSecurity Hubのコンソール画面にある
セキュリティ基準に基づいて継続的なセキュリティチェックを行います。
なので、Security Hubを使用する上で、どのセキュリティ基準を
使用（有効化）するのかを吟味する必要があります。
Security Hubを有効化しようとすると、デフォルトだと下記の
画像の通り、
・AWS 基礎セキュリティのベストプラクティス v1.0.0
・CIS AWS Foundations Benchmark v1.2.0
この2つのセキュリティ基準にチェックが入っています。
勿論、全てのセキュリティ基準を有効化した方セキュリティ的には
ベストだとは思いますが、
その分、セキュリティチェックするルールの数を増える為、
チェックする項目が増えます。ですので最初から全てを有効化するのは、
個人的にはオススメはしません。
実際、有効化すると分かりますが、かなりの数のアラートが出てくる
ので、構築しながら、テストしながら、アラートに対応していく
のは、かなり骨が折れるとか思いますので、先ずは、
・AWS 基礎セキュリティのベストプラクティス v1.0.0
だけ有効化するでいいのではと思っています。
運用していく中で、徐々に有効化するセキュリティ基準を増やしていくという対応がいいのではと考えます。有効化したはいいが、結局アラート対応はやっていませんでは、宝の持ち腐れになってしまいますので、先ずは対応出来る範囲で行いましょう。
ちなみに、重要度ラベル定義は以下の通り。
CRITICAL：この問題はエスカレートしないようすぐに修正する必要あり
HIGH：この問題は優先事項として対処する必要があり
MEDIUM： この問題は対処する必要があるが、緊急ではない
LOW： この問題は単独で対処する必要はない
INFORMATIONAL： 問題は見つからなかった
なので、最低でも「CRITICAL」や「HIGH」は対応していかなければ
ならないと感じます。「LOW」に関しては、対応する必要はないかと感じますが「MEDIUM」に関しましては、プロジェクトのSecurity Hubに対する温度感によって対応するかどうかが決まるのではと思います。
正直MEDIUMは、CRITICALやHIGHよりも数が多いので対応するはかなり骨が折れます...
◎Security Hub 構築について
Security Hubとはどんな機能なのかは説明した所で、
Security Hubを構築する上で考慮する事は以下の点かと思います。
・どのリージョンで有効化するか
Security Hubはリージョン単位のリソースなので、リージョンごとに有効化する必要があります。なので、例えば東京とバージニア北部でリソース作成しているのであれば、両リージョンで有効化するかどうかの選択が必要になるかと思います。
只、集約リージョンという設定があるので、バージニア北部で発報したアラートを東京リージョンのSecurity Hubのコンソール画面に集約して、見る事が可能なので、運用する際、アラート確認をする時に各リージョンに移動するなどの手間は回避できます。
下記の画像は、大阪とバージニア北部のセキュリティアラートを
東京リージョンで見られるように集約した設定の例です。
・Security Hubの検出結果について
Security Hubは、有効化したセキュリティ基準により作成された
コントール（セキュリティルール）によって、再評価（セキュリティチェック）される時間は異なりますが、最初にセキュリティ基準を有効化して始めのセキュリティチェックが入ってから、最短で12時間、最長で24時間ごとに、各コントール（ルール）ごとに再評価（セキュリティチェック）されていきます。
つまり、最初にセキュリティチェックされてから、24時間以内には、セキュリティアラートに対して特に何もアクションしていない場合、Security Hubによって再評価された際、新たにセキュリティアラートが作成されてアラートが発報されます。
アラートが上がっても気付けなければ意味がないですし、
Security Hubのコンソール画面に入って確認するというのも手間なので、
E-mailアドレスにないしSlackのチャンネル先にアラートを飛ばすという
対応を取った方がいいかと思います。
アラートを検知する方法は、EventBrigeを使えば簡単に実装する事が出来ます。EventBrigeのイベントパターンの例を下記に記載しておきます。
{
"detail": {
"findings": {
"Compliance": {
"Status": ["WARNING", "FAILED"]
},
"ProductName": ["Security Hub"],
"RecordState": ["ACTIVE"],
"Severity": {
"Label": ["HIGH", "CRITICAL", "MEDIUM"]
},
"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"]}」を入れています。抑制済みにのワークフローステータスについては、この後説明しますが、ワークフローステータスが抑制済みに変更した場合のものも検知させたくないという理由もあります。
最後に通知先ですが、通知先に関しては各プロジェクトごとに異なると思いますので、各プロジェクトに合わせて通知先を決めていただければと思います。
一番簡単なのは、SNSを使ってサブスクリプションにE-mailアドレスを設定する事、またSlackに飛ばしたのなら、AWS Chatbotを使用したり、最近ではDatadogに飛ばしたいという要件もあるかもしれませんので、その場合Datadogが用意してくれているLambdaのDatadogForwarderを作成したりして通知させればいいかと思います。
そもそも検出結果を通知させないという要件もあるかもしれませんので、そこは各プロジェクトごとの要件に合わせて決めて頂ければと。
・Security Hub と AWS Organizationsの統合について
AWS Organizationsを使ってアカウント管理しているプロジェクトも
多いのと思います。Security Hubは、Organizationsと統合されていますので、Organizationsの管理アカウントでメンバーアカウントのSecurity Hubの設定を管理する事が出来ます。要は、管理アカウントで Security Hubを有効化するかどうか、どのセキュリティ基準を有効化するかどうかなど設定できるようになります。
また、Security Hubの検出結果を管理アカウントの集約リージョンに
全て集約させることも出来ます。例えば管理アカウントの東京リージョンに全てのメンバーアカウントの各リージョンの検出結果を集約させて見る事が出来るという事です。
そうすれば、管理アカウントの集約リージョンにのみEventBrigeを
作成すれば、全てのメンバーアカウントの各リージョンの検出結果を検知
させる事が出来るので、設定的にもとても楽になりますね。
余談ですが、管理アカウントにメンバーアカウントの検出結果を集約させるには、管理アカウントのSecurity Hubコンソール画面の設定という項目で、他アカウントをメンバーアカウントとして追加しなければならないのですが、もし複数リージョン使用していて、これを集約リージョンに集約させたい場合、このメンバーアカウントへの追加は、各リージョンごとに行わなければなりません。
細かい話ですが、
集約の流れとして、メンバーアカウントの検出結果は、
先ず、管理アカウントの各リージョンごとに集約されてきます。
バージニア北部なら、管理アカウントのバージニア北部のSecurity Hubで
東京なら、管理アカウントの東京のSecurity Hubに集約されます。
次に、管理アカウントの集約リージョンの設定において、
集約リージョンに全て検出結果がそこに集まるという流れになります。
例えば、集約リージョンの設定を東京リージョンにしていれば東京リージョンに集約されます。
なので、管理アカウントの各リージョンごとでメンバーアカウントの追加をする必要があります。
そして、Organizationsとの統合にとって考慮する事は以下の点かと思います。
・Security Hubの管理権限に委任
AWSのベストプラクティスとして、基本的には管理アカウントは使用しないものとなっているはずです。なので、Security Hubの管理権限も他のアカウントに委任するというのがAWSの推奨です。また、Organizationsのベストプラクティスとして、Securityアカウントを一つ払い出して、そこで管理するというのを推奨しているようです。
・組織設定の方法
管理アカウントでSecurity Hubの設定を管理する事が出来るというのは先にお伝えしましたが、設定として
・中央設定
・ローカル設定
というものがあります。デフォルトではローカル設定となっています。
基本的には、どちらもメンバーアカウントの設定をどうするかというものになるのですが、下記の画像見てわかる通り推奨は中央設定となっています。
只、個人的にどっちでも良いのかと思ってはいるのですが、
中央設定にするメリットとデメリットを上げるとすれば、
メリットは、この後運用の設定で記載しますが、不要なアラートを止める方法として、コントールの無効化という設定があります。これは、各アカウントごとで設定する必要があるものなので、各メンバーアカウントごとで無効化の設定をしなければなりませんが、中央設定では管理アカウントでコントールの設定を管理する事が出来ます。
デメリットとしてあげるとしたら、先に記載した管理権限の委任を必ず行う必要があるという事だと思います。要は、アカウントの管理者と、Security Hubの管理者を必ず別々のアカウントにしなければならないという事です。
・その他
これは、そこまで重要な事ではないですが、
考慮する必要があるかもしれませんので記載しておきます。
Security Hubを有効化する上で、AWS Configの有効化が必須になります。何故ならば、Security Hubを有効化するとConfig内にConfigルールが、Security Hubによって自動的に作成されます。Security Hubのセキュリティチェックは、実際にはこのConfigルールがチェックしているからです。そして、Configを有効化する際には必ずConfigのログをS3に格納する必要があります。このログというのは、Configはリソースの設定変更を記録するという機能も持っていますので、そのログの格納先を必ず指定しなければなりません。
なので、このログを例えば管理アカウントに集めるのか、はたまた、各アカウントごとに保存させるかどうかというのも考慮する必要あるかもしれません。
もし一か所に集めたい場合はS3に下記のバケットポリシーを付与するれば可能なので参考になればと思います。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AWSConfigBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "config.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::<バケット名>",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": [
"99070648×××,
"××××31949458",
"1195××××5306",
"429796××××22"
]
}
}
},
{
"Sid": "AWSConfigBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "config.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::<バケット名>/AWSLogs/*
],
"Condition": {
"StringEquals": {
"AWS:SourceAccount": [
"99070648×××,
"××××31949458",
"1195××××5306",
"429796××××22"
]
}
}
}
]
}
◎Security Hub 運用について
Security Hubを運用する上で考慮する事は以下の点かと思います。
・不要なアラートについて
Security Hubのルールには引っ掛かりアラートが出ているが、設定上の理由等で対応する必要のない、また敢えてそういう設定しているリソースに対してアラート発報された場合、どう対処するかを考える必要があります。
方法としては、以下の２つになります。
①セキュリティアラートのコントロールを無効化する
コントロールとは、セキュリティ標準に基づいて AWS 環境を評価するための具体的なルールやチェックポイントのことで、これらのコントロールは、業界標準やベストプラクティスに基づいて設定されており、セキュリティの脆弱性を検出し、改善策を提供するために使用されるものです。特徴は以下の通りです。
メリット：Security Hubのセキュリティチェックの対象外となる為、再度有効化しない限りアラートが発報しない
デメリット：セキュリティチェックに引っかかっているリソースのみを発報を止めるという事は出来ない
・注意点
複数のアカウントまたは複数のリージョンで同一のアラートが発報している状態で、同一のアラートを無効化したい場合、Seccurity Hubは リージョン単位のリソースである為、コントロールの無効化は、各アカウントの各リージョンごとに行わなければなりません。しかし、中央設定を使っている場合は一括で無効化する事は可能です。
②ワークフローステータスをSUPPRESSED(抑制済み)に変更する
ワークフローステータスは、セキュリティの調査やアラートの進行状況を示すステータスです。Security Hub では、発見されたセキュリティ問題や脅威に対してどのように対応しているかを追跡するために、ワークフローステータスを使用します。特徴は以下の通りです。
メリット ：リソース単位でセキュリティアラートを無効化する事が出来る。
デメリット：Security Hubの仕様上、アラートが保存される期間が、３ヶ月となるので、アラートが削除された後は、再度アラートが発報されますので、再度ワークフローステータスを変更するというオペレーションをしなくてはいません。しかし、Security Hubのオートメーションルールを作成すれば自動的に抑制済みに変更出来ます
ワークフローステータス参考資料：https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/finding-workflow-status.html
なので、結論としては、
例えば設定上あえて、作成している全てのS3がパブリックアクセスを有効化している場合、コントールを無効化する事でアラート発報自体を止める、要はセキュリティチェックをしなくなるように、SecurityHubでコントールを無効化すればよいかと思います。只、今後作成されるリソース（ここではS3ですが）に対してもセキュリティチェックをしなくなってしまいますので注意してください。
また、発報している対象のリソースのみアラート発報を止めたい場合は、ワークフローステータスをSUPPRESSED(抑制済み)に変更するという対応するべきだと思います。その際、手動で抑制済みに変更するのは手間なので、SecurityHubオートメーションルールを作成して自動化させる事をお勧めします。
オートメーションルール参考資料：https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/automation-rules.html
オートメーションルールの作成する際の条件のお勧めは、
下記の画像の通りで、「GeneratorId」と「ResourceId」です。
AWS Organizationsの統合している際の注意点
オートメーションルールは、Organizationの管理アカウントからSecurity Hubの管理権限を委任されたアカウントのみでしか作成出来ません。また、オートメーションルールはリージョン単位で作成されるリソースである為、抑制したいアラートが発報されているリージョンでルールを作成する必要がありますのでご注意ください。
◎最後に
Security Hub の 構築と運用方法については、記載した内容を
考慮して貰えれば良いのではないと思います。
これが誰かの一助になれば幸いです。