【資料公開】AWS Security Hub導入と運用の検討ポイント

2022 年 9 月 14 日に開催したセミナー「クラウドセキュリティの最適解」におけるセッション「AWS Security Hub 導入と運用の検討ポイント」の資料公開です。AWS 環境のセキュリティチェックを行うサービスの導入ポイントについて、ブログでも説明します。

本セッションの内容は、クラスメソッド社内で AWS Security Hub の導入支援経験のあるメンバーが集まって、どのような進め方をしているかを共有するわいわい会の内容をまとめたものになります。

登壇資料では、始めに AWS Security Hub の概要や失敗したセキュリティチェックの対応例を記載していますが、ブログ版ではメインとなるセキュリティ基準「AWS 基礎セキュリティのベストプラクティス」の導入と運用の検討ポイントに絞って記載しています。

登壇資料の目次

• AWS Security Hub の概要
• セキュリティチェックの対応例
• AWS Security Hub 導入と運用の検討ポイント ブログでも紹介
• みんなでセキュリティ対策（合わせて読みたい資料） ブログでも紹介

概要について資料を見ていただくか次のブログが役立ちます。

AWS Security Hub 導入の各フェーズでやること

AWS Security Hub のセキュリティ基準機能を導入するために各フェーズでやることをまとめた図です。どのような状況でも「この通りにやれば完璧」というものではありませんが、導入を検討する際の一つの例としてご参考にしていただけると幸いです。

大きく「お試しフェーズ」「本格導入フェーズ」「運用フェーズ」の 3 つに分けており、以降では各フェーズのやることについて一つずつ解説していきます。

お試し導入フェーズ

まずはお試し利用を行うフェーズであり、やることは 2 つです

• コントロール（セキュリティチェック項目）を把握
• コストの把握

お試し導入は簡単で、まず AWS Security Hub のマネジメントコンソールからポチポチっと有効化できます。1 点注意として、AWS Config の利用が前提となっています。

簡単な設定がありますので「AWS 基礎セキュリティのベストプラクティス」を選択して「Security Hub の有効化」を行います。CIS AWS Foundations Benchmark や PCI DSS に従う必要がある場合は、他のセキュリティ基準の有効化も検討します。特に要件がない場合は、「AWS 基礎セキュリティのベストプラクティス」がおすすめです。対象としている AWS リソースが多く、アップデートも頻繁なためです。

お試しで AWS Security Hub を有効化するときは、メインで利用しているリージョンの他に、バージニア北部リージョンと普段利用していないリージョンも 1 つ以上有効化しておくとよいです。CloudFront や WAF の一部のチェック項目はバージニア北部リージョンのみで評価されるためです。また、普段利用していないリージョンで AWS Security Hub を有効化した際のコストも把握できるためです。

コントロール（セキュリティチェック項目）の把握

AWS 基礎セキュリティのベストプラクティスには 189 個のコントロールがあります（2022年9月12日時点）。

AWS Foundational Security Best Practices コントロール - AWS Security Hub

サービス別のコントロール数の分布は次の通りです。EC2 や RDS などの主要なサービスのコントロール数が多いことが分かります。

各コントロールには重要度が設定されており、重要度別にコントロールを色分けしたグラフが次の図です。最も高い重要度のCRITICALは全体の約 10%程度です。

重要度の定義はAWSユーザーガイドに記載があります

コントロールの結果を生成および更新する - AWS Security Hub

コントロールの確認に時間的な制約がある場合は、よく対象サービスの利用頻度や重要度で優先度をつけて確認を行います。

コストの把握

セキュリティ基準の料金はチェック回数による従量課金となります。

料金 - AWS Security Hub | AWS

事前に正確なコスト算出は難しいため、実際の利用料金を参考にします。設定画面からチェック回数とコストの予測を確認することができるため、お試し期間の間におおよそのコストを把握しておきます。

本格導入フェーズ

本格導入フェーズでは次の 4 つを検討します。

• 設定と無効化項目の検討
• 通知の検討
• 初期セットアップ方法の検討
• 修復作業の自動化の検討

設定と無効化項目の検討

AWS Security Hub の主な設定とコントロールの無効化について検討します。また、組織的に導入する場合はマルチアカウント管理についても検討します。

導入に向けて検討する設定内容

主な設定項目とおすすめ設定は次の通りです。

AWS Security Hub はすべてのリージョンで有効化することがベストプラクティスです。誤って普段利用していないリージョンでセキュリティを考慮できていないリソースを作成した場合などにおいて、そのリソースが危険な設定のまま放置されているリスクに気づくこともできます。

セキュリティ基準は、「AWS 基礎セキュリティのベストプラクティス」が対象としている AWS リソースが多く、アップデートも頻繁なことからおすすめです。

新しいコントロールの自動有効化は、コスト増加にも関係するため、その点を踏まえて検討します。

無効化するコントロールの検討

コントロール毎に無効化することができます。

無効化することにより、チェック対象外になること以外にコスト削減効果もあります。

無効化を検討する際に参考となる基準の例として次の項目があります。

• 自社のセキュリティポリシー/ガイドライン
• コントロールの重要度
• 対象サービスの利用状況

例えば、社内のセキュリティポリシーで暗号化が必須ではない場合は、暗号化に関するコントロールの無効化を検討します。AWS において、データの暗号化はユーザーの責任のため暗号化はしておいた方がよいですが、本当に必要なコントロールのみを定着させることを優先する考え方もあります。

また、AWS のユーザーガイドに無効化する可能性があるコントロールが紹介されているため、合わせて確認します。

無効にする可能性のある AWS Foundational Best Practices コントロール - AWS Security Hub

マルチアカウント管理

組織的に AWS Security Hub を導入する場合はマルチアカウント管理も検討します。

AWS Security Hub にはコントロールのチェック結果を集約する機能があるため、CCoE などの AWS 全体を管理する組織の AWS アカウントに集約することができます。全体を管理する組織がある場合は、これまで紹介した設定の検討や無効化するコントロールの方針決めを統一した基準にするため、一元的に管理することをおすすめします。

初期セットアップ方法は後述します。

通知の検討

コントロールのチェック失敗をメールやチャットツールに通知することができます。ただし、何も考えずに全てを通知すると一度に何十通ものメールが届き、確認しなくなってしまいます。

そのため、重要度や社内セキュリティポリシーを参考に項目を絞ることを検討します。

通知の設定や通知項目のフィルター方法は次のブログが参考になります。

もし通知だけでは見逃しや放置の可能性がある場合は、チケット管理システムと連携させることもできます。

例として、Backlog 課題の起票を行うブログを紹介します。

初期セットアップ方法の検討

AWS アカウント発行時の初期設定をマネジメントコンソールで行うか自動化するか検討します。AWS アカウント数が少ない場合は手作業の設定も候補になりますが、アカウント数が数十アカウントと多い場合は自動化を検討します。

AWS CloudFormation で AWS Security Hub を有効化するだけなら簡単にできます。

AWSTemplateFormatVersion: 2010-09-09
Description: "Enable AWS Security Hub"

Resources:
  SecurityHub:
    Type: AWS::SecurityHub::Hub

ただし、現状の AWS CloudFormation では、有効化するセキュリティ基準の指定やコントロールの無効化といった設定には対応していません。例えば、CloudFomation で有効化した場合は「AWS 基礎セキュリティのベストプラクティス」と「CIS AWS Foundations Benchmark」の 2 つが有効状態となり、どちらか一方のセキュリティ基準のみを利用したい場合は、無効化する作業が必要となります。

AWS::SecurityHub::Hub - AWS CloudFormation

上記のため、次の方法・ツールが設定自動化の候補となります。

• AWS CLI を用いたスクリプトによる設定
• AWS Step Function, AWS Lambda による設定
• Terraform による設定

Terraform においても AWS 基礎セキュリティと CIS の両方が有効化されますが、個別のコントロールの無効化に対応しています。

aws_securityhub_standards_control | Resources | hashicorp/aws | Terraform Registry

もしくは、サンプルソリューションとなりますが、AWS 提供の設定ツールもあります。

aws-samples/aws-security-hub-cross-account-controls-disabler

初期セットアップに関するブログを紹介します。

AWS Organizations 環境のブログです。

非 AWS Organizations 環境のブログです。

サンプルソリューションに関するブログもあります。

修復作業の自動化の検討

失敗したコントロールに対して AWS Lambda などを用いて修復作業を自動化することもできます。

修復の自動化は導入スピードを優先して運用フェーズで検討することもあります。特に、利用期間が長い AWS アカウントでは設定の自動化の影響を確認する時間がかかる場合があります。

独自の修復を作り込む前に試していただきたいのが、AWS が提供しているソリューションです。比較的簡単に導入できます。修復の開始をユーザーが実行することにより自動で修復が行われます。コントロールの失敗時に自動で修復されるのではなく、キックはユーザーが行い、その後の修復が自動となります（半自動という言い方のほうがしっくりきます）。

（AWS での自動化されたセキュリティ対応の画像引用元）AWS での自動化されたセキュリティ対応 | 実装 | AWS ソリューション

詳しく知りたい場合は、次の登壇資料＆動画を見ていただくのがおすすめです。

修復作業の自動化を導入する前に！！！

重要なことですが、そもそも修復を自動化してまで制限したい内容であれば、予防的ガードレール（AWS の利用制限）で防ぐことができないかをまずは検討します。

AWS Organizations を利用している場合は SCP (Service Control Policy) で制限し、利用していない場合でも IAM ポリシーで制限できるか検討します。

また、自動修復は AWS リソースの設定を変更することになるため、事前のテストも必要です。

運用フェーズ

運用フェーズでは次の 4 つを検討します。

• 失敗したコントロールの対応
• 新規コントロールの検討
• 修復作業の自動化の検討（本格導入フェーズと同じ内容）
• ルール見直し・棚卸し

失敗したコントロールの対応

失敗したコントロールの対応は次の 2 つです

• 是正する
  • 是正後、自動的に「成功」となる（12 時間以内が目安）
• 抑制する
  • リスク保有すると判断したリソースは SUPPRESSED（抑制済み）として評価対象外とする

セミナー中では是正後 24 時間以内が目安と説明していましたが、セキュリティチェックの実行スケジュールを確認したところ、定期的なチェックは 12 時間以内の自動実行でした。

コントロールの無効化と抑制の違いのイメージは次の図となります。無効化はコントロール単位、抑制はコントロールの対象となるリソース単位で対象外にできます。

抑制するときは、抑制する（リスクを保有する）と判断した理由を残すことを推奨します。AWS CLI 操作になりますが、AWS Security Hub サービス上でも Note (メモ) を残すことができます。

新規コントロールの検討

コントロールはアップデートにより追加されます。稀に削除されることもあります。

2022 年 9 月 12 日時点の「AWS 基礎セキュリティベストプラクティス」のコントロール数の推移です。頻繁に追加されていることが分かります。

コントロール数の増減が分かりやすいようにした別のグラフです。少ないですが、削除される場合もあることが分かると思います。

新しいコントロールをキャッチアップする方法としては、AWS が提供している SNS トピックをサブスクライブ（購読）する方法があります。メール等でアップデート情報を受信できます。

最新情報の通知を受信することでいつのまにかコントロールが増えていて気づかなかったという状況を防ぐことができます。もし何も設定を変更していないのにセキュリティスコアが下がった場合は、コントロールが追加されたことが原因かもしれません。

修復作業の自動化の検討

本格導入フェーズと検討内容は同じになります。本格導入フェーズから継続して検討するか、運用フェーズで検討を開始します。

ルール見直し・棚卸し

最後はこれまで検討した内容の定期的な棚卸しと見直しです。

定期的に実施する内容や見直す内容としては次の内容があります。

• 効果測定（セキュリティスコアや対応状況の確認）
• 無効化するコントロールの精査
• 抑制済み（リスク保有）項目の棚卸し
• 通知が形骸化していないかの確認・改善

上記対応のための人的リソースと時間を確保することが大事です。導入して終わりではありません。

抑制済み（リスク保有）項目の棚卸しに便利な機能として、AWS Security Hub のインサイト機能があります。下図は抑制済み項目を表示している例です。

抑制済み一覧のインサイトは次のブログで紹介されています。

以上で、各フェーズのやることの紹介は終わりです。

合わせて読みたい

最後に、組織的にセキュリティ対策を実施する取り組みを紹介しているブログや公開資料を紹介します。どの内容も検討の手助けになります。AWS Security Hub 以外の内容もありますが、考え方などは参考になります。

AWS Security Hub の導入アーキテクチャや運用方法、周囲の巻き込み方などを紹介しているブログです。

組織的なセキュリティ対応の内容を紹介している資料です。進め方やアーキテクチャが紹介されており、とても参考になります。

さいごに

AWS で作成したリソースのセキュリティチェックを行う AWS Security Hub のセキュリティ基準に関する導入と運用における検討ポイントをまとめて紹介しました。また、合わせて読みたいブログと資料も掲載しました。

このブログがどなたかのご参考になれば幸いです。