こんにちは、カスタマーサクセス部の山﨑です。
クラウド環境がビジネスの中心となる中、セキュリティ対策の重要性はますます高まっています。そこで頼りになるのが、AWSが提供するセキュリティ管理サービスである「AWS Security Hub」です。
Security Hub自体はよく耳にするセキュリティ管理サービスではありますが「導入が難しそう」「運用方法がわからない」と感じている方もいらっしゃると思います。
そこで今回は、Security Hubの基本から導入手順、そして効果的な運用ステップまでを整理してみました。
導入編
Security Hubについて
AWS Security Hub とは、AWS Config Rules の仕組みを活用してセキュリティ管理を行うサービスとして位置付けられ、主に以下2つの機能を備えています。
- AWS アカウントのセキュリティ状態を継続的にチェックする
- セキュリティイベントを集約管理する
1. AWSアカウントのセキュリティ状態を継続的にチェックする
Security Hubでは、セキュリティ状態をチェックする項目を「セキュリティコントロール」、セキュリティコントロールを用途に応じてひとまとめにしたものを「セキュリティ標準」と呼んでいます。
任意のセキュリティ標準を有効化することで、セキュリティチェックが開始されます。
| セキュリティ標準 | セキュリティレベル | 説明 |
|---|---|---|
| AWS 基礎セキュリティのベストプラクティス v1.0.0 | 中 | AWSにおけるセキュリティのベストプラクティスをもとにしたセキュリティ標準 |
| CIS AWS Foundations Benchmark v1.2.0 | 中 | 米国の非営利団体であるCIS（Center for Internet Security）により公開されているAWS Foundations Benchmark v1.2.0のセキュリティ標準（2018年） |
| CIS AWS Foundations Benchmark v1.4.0 | 中 | 米国の非営利団体であるCIS（Center for Internet Security）により公開されているAWS Foundations Benchmark v1.4.0のセキュリティ標準（2021年） |
| CIS AWS Foundations Benchmark v3.0.0 | 中 | 米国の非営利団体であるCIS（Center for Internet Security）により公開されているAWS Foundations Benchmark v3.0.0のセキュリティ標準（2024年 |
| PCI DSS v3.2.1 | 高 | 継続的なPCI DSSセキュリティ活動をサポートするように設計されたセキュリティ標準 |
| NIST Special Publication 800-53 Revision 5 | 高 | 米国国立標準技術研究所（NIST）のSpecial Publication 800-53 Revision 5（NIST SP 800-53 r5）に準拠したセキュリティ標準 |
| AWS リソースタグ付け標準 | ー | AWS リソースにタグキーが付与されているかを迅速に特定するための標準（他とは少し毛色が違いますが記載しています） |
2. セキュリティイベントを集約管理する
Security Hubを使うと、AWSのさまざまなセキュリティサービスやサードパーティー製品からのセキュリティイベントを一元管理できます。たとえば、Config RulesやAmazon Inspector、GuardDuty等もSecurity Hubと連携できるため、これらのセキュリティイベントをSecurity Hubでまとめて管理することが可能です。
他にもリージョン集約機能を使うと、複数のAWSリージョンで有効になっているSecurity Hubの検出結果を、1つのリージョンにまとめて管理できます。
複数のAWSアカウントでSecurity Hubを利用している場合、アカウント統合機能により特定のアカウントに検出結果を集約することも可能です。これらの機能を活用することで、複数のAWSアカウントやリージョンで有効化されているSecurity Hubの検出結果を、1つのアカウントとリージョンに一元化できます。
導入方法
導入方法についてはそれぞれ以下のブログをご覧ください。
単一アカウントへの導入
マルチアカウントへの導入
基本運用方針
対応するセキュリティコントロール
Security Hubでは、セキュリティコントロールのSeverity（重要度）を定義しています。これらのうち、「CRITICAL」「HIGH」のセキュリティコントロールをメインターゲットとし、「MEDIUM」「LOW」への対応は努力目標とします。
目標とするセキュリティスコア
Security Hubでは、有効になっているセキュリティコントロールのうち、チェックをクリアした（PASSED）のコントロールの割合をセキュリティスコアとして算出しています。
セキュリティ対策は、コストとトレードオフの関係にあります。セキュリティ対策を実施すればするほど、セキュリティはより強固になりますが、その反面で人的コストや金銭的コストがかさみます。
よって、セキュリティスコアの目標は「80％」を1つの目安とします。組織によっては、より高い目標として「90％」を掲げることもあると思いますが、先述したトレードオフの観点から「100％」を目指すことはオススメいたしません。
運用編（基本）
運用における5つの基本ステップ
| No | ステップ | 概要 |
|---|---|---|
| 1 | セキュリティ標準を最適化する | 必要なセキュリティ標準のみを有効化する |
| 2 | チェック数を減らす | 不要なセキュリティコントロールは無効化し、許容するセキュリティコントロールは検出を抑制する |
| 3 | 検出結果を解消する | 「CRITICAL」「HIGH」と重要度が高い検出結果から順に対応する |
| 4 | 検出結果の通知設定を行う | セキュリティコントロールに抵触した検出結果を通知する |
| 5 | セキュリティコントロールの変更を把握する | 適宜内容が更新されるセキュリティコントロールを把握する |
STEP1. セキュリティ標準を最適化する
過度にセキュリティ標準を有効化していると、それだけ検出数は増加します（2024年10月時点でセキュリティコントロールは400個以上あります）
システムが遵守すべきセキュリティ水準に従って適切なセキュリティ標準が有効化になっているかどうかを念の為に見直します。以下は1つの目安です
- 一般的な公開Webサイト、会員制サイト等のシステムの場合
- AWS Foundational Security Best Practices
- CIS AWS Foundations Benchmark v3.0.0
- 機密情報が含まれるシステムの場合
- AWS Foundational Security Best Practices
- CIS AWS Foundations Benchmark v3.0.0
- NIST SP 800-53 Rev. 5
- 決済システムを扱っている場合
- AWS Foundational Security Best Practices
- CIS AWS Foundations Benchmark v3.0.0
- PCI DSS v3.2.1
STEP2. チェック数を減らす
セキュリティ標準には多数のセキュリティコントロールが含まれていますが、システムによっては検出を許容するチェック項目が存在することもあります。例えば、以下はその一例です。
チェックする必要がないセキュリティコントロール
電池切れ等の物理的トラブルを避けるため、組織としてハードウェアMFAではなく、Google Authenticatorのような仮想MFAデバイスを採用している場合は以下のセキュリティコントロールを無効化します。
- IAM.6: Hardware MFA should be enabled for the root user
無効化する際は、なぜ無効化することになったのか、理由を記載しておくことをオススメします。
チェックはするが、一部のシステムやリソースでは許容するセキュリティコントロール
例えば、システムの特殊要件によって特定のEC2インスタンスへのPublic IPアドレスの付与を許容している場合は、該当リソースのみ以下のセキュリティコントロールの検出を抑制します。
- EC2.9: EC2 instances should not have a public IPv4 address
検出の抑制は「ワークフローステータス」を変更することによって設定します。詳細は以下ブログ、ドキュメントをご覧ください。
セキュリティコントロールの検出を抑制すればステータスがFAILEDでも、許容したセキュリティコントロールであることがコントロール画面から確認することができます。
STEP3. 検出結果を解消する
STEP1とSTEP2を実施することで、本当にチェックすべきセキュリティコントロールのみが検出される状態になっているはずです。
ここからはいよいよ「CRITICAL」「HIGH」と重要度が高い検出結果から順に対応していきます。
検出されたセキュリティコントロールに対して、具体的にどのように対応すべきなのかはAWS公式ドキュメントに1つずつ記載されているため、こちらを確認しながら対応していくことをオススメします。
※ 対応完了後は、検出結果の「ワークフローステータス」を「解決済み」に変更することを忘れないようにしましょう
STEP4. 検出結果の通知設定を行う
STEP1〜STEP3を実施することで、重要度が高い「CRITICAL」「HIGH」の検出結果はほとんど無くなっているはずです。
このタイミングで検出結果の通知設定を行い、検出内容をタイムリーに把握して迅速に対応できるように準備します。
Security Hubを有効化したタイミングで、合わせて検出結果の通知設定を行うのも1つの方法です。
しかし、Security Hubは数時間に1回の頻度でセキュリティコントロールをチェックするため、STEP3を実施する前に通知設定をすると場合によっては1日に100件以上の通知が飛んできてしまいます。つまり、ノイズになってしまう可能性があるので個人的にはオススメしません。
通知設定については以下ブログをご参照ください。
STEP5. セキュリティコントロールの変更を把握する
セキュリティコントロールの内容は不定期に追加/変更/削除等の変更が加えられます。
実際、Security Hubがリリースされて間もない頃はおよそ100個程度しかなかったセキュリティコントロールは、都度変更が加えられた結果として2024年10月時点で400個以上になっています。
セキュリティコントロールの変更を把握する方法については以下ブログをご覧ください。
運用編（発展）
STEP6. 検出を未然に防ぐ
STEP1〜STEP5まで実施できていれば、Security Hubの運用としては充分です。
しかし、セキュリティコントロールによってはすぐに修復したいもの（例：Security GroupのInboundで「0.0.0.0/0」のエントリーはすぐに削除したい）は自動的に修復させることを検討します。
自動修復については様々な方法があるので詳細は割愛しますが、興味がある方は以下ブログやドキュメントを是非ご覧ください。
STEP7. 新しいチェック項目を作成する
Security Hubのセキュリティコントロールではカバーできないチェック項目がある場合は、Custom Config Rules として新規作成することも可能です。
STEP8. ワークフローステータスの更新を自動化する
事前定義したルールに従って、Security Hubの検出結果を自動的に更新することができます。
まとめ
AWS Security Hubを活用することで、AWS環境のセキュリティを一元的に管理し、潜在的なリスクを早期に発見・対処することが可能になります。この記事では、導入から運用までの基本的なステップをご紹介しましたが、いかがでしたでしょうか？
セキュリティ対策は一度設定して終わりではなく、継続的な見直しと改善が求められます。Security Hubを効果的に運用し、最新のセキュリティ状況を把握することで、安心・安全なAWS環境を維持していくことに繋がります
この記事が皆様のセキュリティ強化のお役に立てれば幸いです。
山﨑 翔平 (Shohei Yamasaki) 記事一覧はコチラ
カスタマーサクセス部所属。2019年12月にインフラ未経験で入社し、AWSエンジニアとしてのキャリアを始める。2023 Japan AWS Ambassadors/2023-2024 Japan AWS Top Engineers
