AWS Security Hub運用の第一歩 #SecurityHub

はじめに

これは GLOBIS Advent Calendar 2022の17日目の記事です。

今回は弊社でSecurity Hub導入の一端をご紹介したいと思います。

AWS Security Hub は、AWS 内のセキュリティの状態と、セキュリティ標準およびベストプラクティスに準拠しているかどうかをチェックできるツールです。

詳細についてはAWS公式ドキュメントをご覧ください。

前提

弊社ではAWSアカウントは目的に応じて複数取得し、使い分けています。

そのためアカウント跨ぎで管理を一元化するためにAWS Security Hub と AWS Organizations の統合しています。

組織管理アカウントからSecurity Hub管理者アカウントへと権限を委任することで、検出結果を集約し、AWS Chat Botを使いSlackへと検出結果を通知しています。

また、検出結果は1つのリージョンに集約させています。

単純にセキュリティ標準およびベストプラクティスに乗っ取っていないのであれば実リソースとして存在するのが好ましくありません。

弊社ではAWSリソースの作成の大部分をTerraformで行っているため、tfsecを用いた静的解析を併用しています。

tfsecはGithubActionsを用いてPR作成時にチェックを行ってい予防的な役割を担っています。

そのためSecurity Hubのリソースチェックとしての役割としては以下に大別されます。

セーフティネットとしての役割
AWS Security Hub コントロールアップデートへの追従
- AWS Security Hub で 36 のセキュリティベストプラクティスコントロールが新たにリリース

大量通知

すでに運用しているアカウントでSecurity Hubを有効化するとSlackへ大量の通知が届きました。

単純に心臓に悪い上、1つ1つスクロールしながら確認していくのは苦行です。

通知を工夫して視認性を確保しなければ形骸化してしまう恐れがあります。

1件 CRITICAL
8件 HIGH
9件 MEDIUM …

のようにサマリー形式で通知することも考えましたが、検出結果を見るためにマネジメントコンソールを見る必要があるため手間がかかります。

Severity (重要度)や新規に検出されたものはSlackへ通知をする。という条件付けを以下のようにEventBridgeのイベントパターンで制御することも可能です。

{
	"source": [
		"aws.securityhub"
	],
	"detail-type": [
		"Security Hub Findings - Imported"
	],
	"detail": {
		"findings": {
			"Compliance": {
				"Status": [
					{
						"anything-but": "PASSED"
					}
				]
			},
			"Severity": {
				"Label": [
					"CRITICAL", 
					"HIGH"
				]
			},
			"Workflow": {
				"Status": [
					"NEW"
				]
			}
		}
	}
}

しかし、本来であれば全てのSeverity見るべきですし、「新規に検出されたものはSlackへ通知をする」という条件付けは一度見逃すと致命的なリスクになり得ます。

そのため、通知の工夫は後回しでSecurity Hubの警告を少なくする方針を取りました。

現状の把握

Security Hubで検知された警告をAWSマネジメントコンソール上で確認しました。

全てを1回のMTGで議論することは困難と判断し、Severityが「CRITICAL、HIGH」のみのものに関して改善及びもしくはルールの無効化を議論するという目線合わせをしました。

(MTG資料一部抜粋)

無効化するルール選定

現状出ている警告が対処することは現実的に可能か、また無効化する上で代替案はあるか、社内規定はクリアできているのかという観点でチームで議論しました。

例えば、[IAM.6] Hardware MFA should be enabled for the root user は rootアカウントにハードウェアMFAを必須とするルールです。

昨今のリモートワークの背景や、複数アカウントを運用していることを加味すると物理端末の管理は現実的ではありません。

弊社では仮想MFAを必須としている他、代替案としてrootユーザーのログイン時に通知するといった他の方法でカバーすることで無効化をすることを決定しました。

対して無効化しないルールについてはissueを作成し、調査及び改善していくことになりました。

準拠するために大幅な変更が伴う場合

AWSの警告に沿って改善を進めていくと、アーキテクチャの変更を迫られるケースがあります。

[S3.8] S3 Block Public Access setting should be enabled at the bucket level はバケットレベルでS3にパブリックアクセスブロック設定がされている必要があります。

静的ウェブサイトホスティングを利用している場合はパブリックアクセスを有効化する必要があり、このルールに準拠する場合には諦める他ありません。

静的ウェブサイトホスティングの機能であるインデックスドキュメント/カスタムエラードキュメントを利用している場合、Lambda@edge等でその機能を補完する必要があります。

CloudFrontを使用したデフォルトルートオブジェクトやカスタムエラーレスポンスで制御することも可能ですが、静的ウェブサイトホスティングとは動作が異なり完全に代替機能として使うことはできません。

例えば、デフォルトルートオブジェクトはサブディレクトリ配下には適用されません。

また、現時点ではカスタムエラーレスポンスはビヘイビア単位では設定できないため、工夫が必要になります。

さいごに

今回は弊社でAWS Security Hub導入の一端をご紹介させていただきました。

AWSを運用していて後からSecurity Hubの導入をすると大量の警告が出る。というのはあるあるなようで、検索をすると色々な記事やスライドで語られています。

Security Hub導入で困っている方に弊社の取り組みが少しでも参考になると幸いです。

おまけ

サマリー形式の通知

Security Hubの検出結果をサマリー形式で通知するためのCloudFormationテンプレートが公式で用意されています。

AWSリソースはTerraformで扱いたいため導入には至りませんでしたが、便利だと思いますので検討する余地はあると思います。

https://aws.amazon.com/jp/blogs/security/how-to-set-up-a-recurring-security-hub-summary-email/

Datadog Cloud Security Posture Management

https://docs.datadoghq.com/ja/security_platform/cspm/

Datadogでも以下のフレームワークを用いてAWSのセキュリティモニタリングを実現できます。

弊社でもDatadogを活用しており、ログやアラート等を全てDatadogに集約点できる点で魅力を感じています。