本記事は
AWSアワード記念！夏のアドベントカレンダー
4日目の記事です。
🎆🏆
3日目
▶▶ 本記事 ▶▶
5日目
🏆🎆
はじめに
こんにちは、大林です。
今年のAWS Summit Tokyoにて、2024 Japan AWS Jr. Championsに選出されました。多くの方々のご支援とご協力のおかげで今の自分があると思います。
今回は、AWS Security Hubを活用した効率的でセキュアなマルチアカウント管理というテーマで書いていきます。
AWS Security Hubを導入、運用する際によくある課題を取り上げ、その課題をどのように解決していけばいいのか紹介します。
AWS Security Hubとは
AWS Security Hubは、セキュリティ基準から逸脱したリソースがないかチェックしてくれるサービスです。Amazon GuardDutyやAWS ConfigなどのAWSサービスやサードパーティのセキュリティツールと統合し、ダッシュボードを使って「どのアカウントで何が検知されているのか」を確認することができます。
AWS Security Hubに情報を集約
AWS Security HubではAWSアカウントにおけるセキュリティ情報を一元管理することができます。様々なAWSサービスからのセキュリティアラートや評価結果を一箇所にまとめることで、重要な問題を特定しやすくなります。
AWS Security Hubから情報を受け取る
AWS Security Hubから情報を受け取ることで、検知後の効果的なセキュリティ対応が可能になります。例えば、Security Lakeにデータを送信しておけば、データ分析が行いやすくなります。また、Amazon Detectiveを使用して検知結果の詳細な調査が可能となり、インシデントの原因を迅速に特定できます。これにより、セキュリティインシデントの対応時間を短縮し、被害を最小限に抑えることができます。
AWS Security Hub導入における課題
どのように統制を効かせていくのか
まず、導入にあたってアカウント管理をする上でどのように統制を効かせていくのかをはじめに考えなければなりません。今回は、「ガイドラインのみのパターン」と「ガイドラインとガードレール」を組み合わせたパターンの2つのパターンを比較してみます。
ガイドラインとは、システム運用や開発における基本的なルールやベストプラクティスを指します。企業や組織がどのようにシステムを管理し、セキュリティやコンプライアンスを維持するかを示すための指針です。
ガードレールは、システム運用や開発における厳格な制限や制約を指します。企業や組織が設定したポリシーやルールに基づいて、セキュリティやコンプライアンスを守るための仕組みです。
柔軟性の観点では、ガードレールを採用しない分、ガイドラインのみの方が開発の柔軟性は高いです。ただ、ガードレールを実装することで、統制を効かせつつある程度の柔軟性を確保した環境を整えることができます。
コンプライアンスの観点では、ガイドラインのみだと、コンプライアンス遵守は各チームや個人の自主性に依存しますので、より統制を効かせたいのであればガードレールを実装するのがいいです。
コストの観点では、ガイドラインのみだと、各チームが非効率なリソース利用を行った場合、コストが増加することがあります。一方で、ガードレールを導入することで、ガードレール実装における初期コストはかかりますが、非効率なリソース利用を防ぐことができます。
柔軟性・コンプライアンス・コストの観点、また、アカウント管理者として最終的にどのように統制を効かせていくのかを考え、統制方法を選択していく必要があります。
AWS Security Hubを有効化していないリージョンの設定
AWS Security Hubを有効化しないリージョンへの対応方法について説明していきます。
使用しないリージョンはSCPで操作制限をして、意図しないリージョンでのリソース作成を防ぐのが最善です。
たまに操作ミスにより意図しないリージョンでのリソース作成をしてしまうことがあると思います。もし、AWS Security Hubを有効化していないリージョンにリソースを作成してしまった場合は、そのリソースが攻撃を受けてもセキュリティ検知が行われないため攻撃に気づけなくなります。
こういったことを防ぐために、使用しないリージョンではSCPを使用して操作を制限した方がいいです。
AWS Security Hubを導入した場合の組織構成
AWS Security Hubを導入した場合の組織構成について説明していきます。
情報セキュリティ担当者や監査人がAWS Security Hubのスコアを見ることを考慮すると、図のように集約のためのアカウント（監査アカウント）を用意し、監査アカウントのAWS Security Hubに各アカウントの検知結果を集約するとよいでしょう。
この構成により、監査アカウントのAWS Security Hubから各子アカウントの検知結果を一元的に確認することができます。
リージョンを切り替えて検知内容を確認することで負担が増加している
次に、リージョンを切り替えて検知内容を確認することで運用負荷が増加しているという課題です。
AWS Security Hubはリージョンごとのサービスなので、リージョン集約設定を有効化しなければ、毎回リージョンごとにSecurity Hubの検知を確認する必要があります。
例えば、12リージョン、13リージョンのSecurity Hubのスコアを確認しようとすると、それだけでかなりの手間になります。
この課題を解決するために、AWS Security Hubのリージョン集約を使用して、特定のリージョンから各リージョンのAWS Security Hubのスコアや検知結果を確認できるようにしておくと運用負荷が減少します。
AWS Security Hubの運用における課題
検知後のアクションにどのように繋げていくのか
検知後のアクションへの繋げ方について説明します。
検知後のアクションに繋げるための導線として、通知があります。
メールやSlack、Backlogなど通知方法はいくつかありますが、ケースに応じて通知方法を変えていく必要があります。
例えば、メールやSlackなどで通知内容を手軽に確認できるようにしたいのか、Backlogを使用して通知内容をチケット化して管理したいのか、などです。
このように、通知方法を選定するときは、この通知を通して何がしたいのかという観点で通知方法を選ぶ必要があります。
通知が飛びすぎて重要検知を見逃してしまう
AWS Security Hubを有効化して、通知もできるようにしたが、実際に通知させてみると思ったより通知が多いパターンです。
この構成図は、AWS Security HubのイベントをAmazon EventBridgeでトリガーして、AWS Lambdaで通知をするフローを示しています。
AWS Security Hubの通知を全て受け取る設定にすると、かなりの量の通知が届いてしまいます。
AWS Security Hubには検知結果に重要度が割り振られています。重要度がHIGH以上またはCRITICALの検知のみをトリガーにするようにEventBridgeのルールを作成していくと通知の量を抑えつつ、重要度が高い通知は迅速に対応することができます。
ケースに応じた検知の変更をしたい
Security Hub オートメーションルール
オートメーションルールを使用すると、ケースに応じた検知の定義ができます。
例えば、特定のOUまたはアカウントにおいて、特定の検知の重要度をHIGHからCRITICALに変更したい場合です。
そういったケースで使用できるのが、オートメーションルールです。
オートメーションルールは、特定のOUまたはアカウントの特定の検知の重要度をHIGHからCRITICALに自動で変更するなどのカスタマイズが可能です。
また、重要度の変更だけでなく、特定の通知のみ自動で通知を抑制することもできます。
Security Hub 中央設定
もう一つケースに応じた検知の定義の解決策として、中央設定を紹介します。
中央設定を利用すると、組織単位、アカウント単位で設定（セキュリティ基準の有効化、コントロール設定など）を一括反映することができます。
この設定は管理するアカウントの数が多くなり、各組織でセキュリティ基準やコントロールをカスタマイズしたい場合に非常に有効な設定です。
そのため、オートメーションルールと比較すると、より大規模なアカウント管理に向いている設定だと言えます。
ガードレール実装に必要なタグを管理をしたい
AWS Security Hubはタグの管理にも役立ちます。
例えば、Amazon GuardDutyのRuntime MonitoringやMalware Protectionで使用される除外タグがAWSリソースに設定されているかであったり、Configの自動修復機能を実装している場合は修復されないためのタグがついているかなど、ガードレールに必要なタグが設定されているか確認できます。
現状、全てのリソースに対応していないので、使用する際はドキュメントを読み込む必要があります。
継続的な改善に繋げるために何をしたらいいのか
セキュリティ通知は検知や修正するだけではなく、検知の傾向を分析して、改善まで行動していく必要があります。
以下では、分析や改善について具体的にどのように行動していけばいいのか説明していきます。
通知後にどのような対応すればいいのか
具体的な通知後のアクションについて説明していきます。
基本的に通知を受信したら、CCoEチーム・開発チームで分担して検知内容に対して、調査・修正・抑制していきます。
全ての検知をCCoE側で対応すると時間がかかりすぎてしまうので、まずは開発チームで対応してもらうのがいいです。
開発チームで対応できない、していない場合はCCoEチームと一緒に対応する方法を取ると、開発チームとCCoEチームの時間を有効に使用できます。
調査はAmazon Detectiveを使用した方法が効率的です。
Amazon Detectiveは、セキュリティデータをより詳細な調査したり、グラフを使用した調査を行ったりする便利なサービスです。
ただ、Amazon Detectiveを使用すると、その分コストが増加します。Amazon Detectiveのコストを許容できない場合は、AWS Security Hubのマネジメントコンソールであったり、Amazon GuardDutyなどの個々のサービスに表示されている検知内容を確認する方法もあります。
最近、Amazon GuardDutyは調査用のマネジメントコンソールが見やすくなっているので、使用を検討してもいいと思います。
検知内容を抑制する判断基準は？
AWS Security Hubで検知内容を抑制する判断基準について説明します。
AWS Security Hubで検知していても、システム構成上必要なリソース設定だったり、変更すると別の問題が発生するためにあえて設定しているものだったりすることもあると思います。
こういった場合はリスクを受容して、検知結果を抑制しましょう。
ただ、検知されたリソースについて本当に意図した設定になっているかの確認は必要です。
検知状況の分析
なぜ分析をする必要があるのかというと、分析をすることで具体的な改善アクションが決めやすくなるためです。
AWS Security Hubのインサイトを例に挙げると、インサイトを使用することで、各OUごとや各アカウントごとに検知状況を確認できるダッシュボードを作成することができます。
今回はAWS Security Hubのインサイトを使用しましたが、Amazon QuickSightやSplunkなどでもセキュリティの傾向を分析することもできます。
改善における具体なアクション
改善について具体的に説明していきます。今回はSecurity Hubのスコア改善・セキュリティ意識の改善の2点についてお話しします。
まずは、Security Hubのスコア改善についてです。
スコアを改善するには、例えばSlackなどのチャットツールで、CCoEメンバーがスコアが良かった上位3アカウントと、ワーストの3アカウントを公開して、開発チームに改善を促す方法もあります。
改善を促しても、スコアが改善しない場合はCCoEと一緒に改善していくと有効です。
次に、セキュリティ意識の改善について説明していきます。
この改善が必要な理由は、セキュリティ意識が高いと、セキュリティ通知が飛んできてすぐにリソースの設定変更を行うなどアクションに繋がりやすくなるためです。
GameDayに参加するなど、実際に攻撃されるとどうなってしまうのか体験することで、セキュリティ意識の改善につなげていくことができます。
統制を効かせる仕組みを作成しても、実際に動かないと意味がないのでセキュリティ意識の向上は非常に大切になってきます。
おわりに
今回はAWS Security Hubを活用したマルチアカウント管理方法を紹介しました。アカウント管理は、CCoEチームと開発チームなどのAWSリソースを作成するチームが協力することによってセキュアな環境を構築することができます。 アカウント管理に必要なAWSサービスは今後もアップデートし続けられるので、それぞれの会社や組織でアカウント運用におけるガイドラインの修正や統制の効かせ方もアップデートし続しつづけていく必要があります。
