クラウドがよく分かる！お役立ちコラム

AWSセキュリティ監視運用とは？基本と役割を解説

約11分で読めます

• #Amazon GuardDuty
• #AWS Security Hub
• #Amazon Security Lake

AWSのセキュリティ監視運用でよくある課題

AWSでは、セキュリティ関連サービスを個別に導入しやすいという特徴があります。一方、運用設計まで含めて整理できていない人は多いようです。結果「脅威は検出できていても優先順位が付けられない」「ログは残っていても調査に生かせない」などの状態に陥ります。

監視運用として十分か判断しづらい

GuardDutyは、AWS環境内のログやデータソースを継続的に分析し、不正利用の兆候や不審な挙動を検出するサービスです。そのため、導入することで異常を見つけやすくなります。ただ、GuardDutyだけで設定不備の全体像を把握したり、優先順位を付けたりすることはできません。

結果、GuardDutyは入れているが次の行動が判断できない状態に陥ります。監視すること自体は実現できていても、その次が見えづらいことで、運用としては不十分さを感じるのです。

優先順位付けや対応判断につなげにくい

セキュリティの状況を把握するために、Security Hubへ結果を集約する運用が採用されがちです。GuardDutyの検出結果も取り込めるため、他の情報と組み合わせて運用することも多いでしょう。個々のアラートを追うより、どの問題を優先して確認すべきかを整理しやすくなります。

ただ、見える化されるだけであり、優先順位や対応すべきかどうかを明示してくれるものではありません。誰がどの順に対応するか、誰に通知してどのように対応するかの運用が必要です。情報を集約するだけで満足し、運用が伴わないと課題を抱えます。

ログを調査や分析に生かしきれない

さまざまなセキュリティデータを、Security Lakeへ集約するという考えは広がっています。個別に運用するよりも、一元化したほうが管理・分析に役立てられるからです。

とはいえ、Security Hubと同様に「集約する」という部分で満足するケースが多くみられます。重要なことは、集約したデータを適切に活用することです。OCSFに正規化され、Parquet形式で保存される良さを活かせないと、運用的な課題を感じるでしょう。

Security Lake・Security Hub・GuardDutyの違い

Security Lake・Security Hub・GuardDutyはよく名前の挙がるサービスです。それぞれの役割は重複していないため、個々を理解して、監視運用の設計につなげていきましょう。

GuardDuty：脅威を検出するサービス

GuardDutyは、AWS環境内の挙動を監視するサービスです。不審な通信や認証情報の不正利用の兆候などを検出する役割を担います。監視運用の流れでは「まず異常を見つける入口」として位置づけると良いでしょう。

一方で、検出結果の可視化には対応していません。また、設定不備の対処について明確な方針を示してくれるものでもありません。そのため、可視化や具体的な対応は別の仕組みと組み合わせて考える必要があります。

Security Hub：検出結果や設定不備を整理するサービス

Security Hubは、複数のサービスから上がってくる検出結果をまとめてくれます。どこにどのような問題があるのかを横断的に把握しやすくするサービスです。GuardDutyのような脅威検出結果は、設定評価に関する情報も集約され、日々の確認対象を整理しやすくなります。

また、Security Hubの検出結果はAWS Security Finding Formatで扱われることが特徴です。統一されることで、複数ソースの情報を比較しやすくなっています。

Security Lake：ログを集約し分析する基盤

Security Lakeは、セキュリティ関連データを一元化できるサービスです。データが必要なとき、横断的に調査しやすくするための基盤といえます。

監視運用では、アラートを見て終わりではありません。「なぜ起きたのか」「関連するログに不審な動きはないか」まで確認することが大半です。

このとき、データが分析しやすい形で整っていると、調査のしやすさが大きく変わります。Security Lakeはソースデータを変換し、OCSFとParquetへ整えたうえで保存できるのです。

サービスを組み合わせた監視運用の基本フロー

複数のサービスを言葉で比較しても、具体的なイメージを持ちにくいかもしれません。監視運用のフローに沿って並べなければ掴みづらいでしょう。続いては、AWSの監視運用をイメージしやすいように、基本的な流れを順番にみていきます。

GuardDutyで脅威や不審な挙動を検出

監視運用の入口はGuardDutyです。AWS環境内で起きている不審な挙動を継続的に監視し「異常」を拾う役割を担います。たとえば、通常と異なる通信や認証情報の不自然な利用などです。

これらを検知できれば、運用担当者が確認すべき事象として素早く把握できます。人間だけでは検知できる範囲に限界があるため、GuardDutyを起点とするのです。

Security Hubで優先順位の決定

次にSecurity Hubで、検出結果や設定不備をまとめて確認します。この際に重要なポイントは、「今どれを優先して見るべきか」を判断しやすくすることです。たとえば、業務への影響度や脅威の深刻度から判断します。

GuardDutyとSecurity Hubを有効にすると、GuardDutyの結果がSecurity Hubへ送信されます。アカウント全体を横断的に評価でき、広い視点で優先順位を決定しやすくなるのです。

Security Lakeで集約と調査や分析

優先度の高い検出結果が出たときは、その事象だけでなく周辺ログまで必要になりがちです。このときに備えて、Security Lakeも運用に組み込んでおきましょう。ログやイベントを分析しやすい形で集約すれば、インシデント調査や傾向分析を進めやすくなります。

特に、複数のデータソースを横断して把握したい際に、Security Lakeは非常に魅力的です。集約と正規化が済んでいることで、分析ツールなどにも適用しやすくなります。

通知や運用フローを活かした継続的な対応

監視運用では、検出結果を見つけるだけでは不十分です。以下も決定しておくことで、はじめて運用として成り立ちます。

• 誰に知らせるのか
• どの条件でエスカレーションするのか
• どこまでを自動化するのか　など

また、Security Hubは新規の検出結果や既存結果の更新をEventBridgeイベントとして送信できます。重要度の高い結果を通知したり、チケットを発行したりするなど、運用フローのトリガーになるでしょう。

Security Lake・Security Hub・GuardDutyを活用するメリット

Security Lake・Security Hub・GuardDutyを組み合わせることで、監視運用で多くのメリットを生み出します。特に、役割を分けて監視運用を設計できる点は大きなメリットです。

監視運用の抜け漏れを減らしやすい

解説してきたとおり、Security Lake・Security Hub・GuardDutyはそれぞれ任せる役割が異なります。

• GuardDuty：脅威検出を任せる
• Security Hub：可視化と優先順位付けを支援してもらう
• Security Lake：データの蓄積と分析を一元化させる

このとおりに役割分担すると、監視運用の論点が整理しやすくなるのです。つまり、どこで異常を見つけ、どこで全体を見て、どこで深掘りするかがを明確にできます。結果、運用の抜け漏れを減らしやすいというメリットにつながるのです。

監視運用の流れを整理しやすい

監視運用では、何かしらのアラートが出た後のフローで混乱しがちです。しかし、AWSのサービスを軸にフローを設計すれば、各人がやるべきことを流れで整理しやすくなります。

具体的には、Security Hubで結果を集約し、必要に応じてEventBridgeで通知や後続処理、詳細調査ではSecurity Lakeという流れがおすすめです。検出と対応で必要なサービスが対になり、確認すべき情報もその後の行動も明らかになります。

将来的な体制拡張につなげやすい

Security LakeはAWS以外のソースも取り込みしやすいことがメリットです。また、Security Hubも複数のソースからのセキュリティデータを扱えます。

そのため、AWS中心で環境を構築していても、将来的に他ツールや他クラウドへ広げることが可能です。より高度な分析やSOC運用へ広げたい場合の土台として利用できます。

AWSの導入時に押さえたいポイント

Security Lake・Security Hub・GuardDutyはいずれも有用なサービスです。ただ、一度にすべてを完璧に整えようとすると、かえって運用しづらいかもしれません。そのため、何を先に整えるか、どこまでを初期範囲とするかを決めたうえで、段階的に進めることが重要です。

まずはGuardDutyとSecurity Hubから整備

監視運用の初期段階では、まず異常を見つける仕組みと、確認対象を整理する仕組みを先に整えましょう。GuardDutyとSecurity Hubを組み合わせ、重要な検出結果を把握できる状態を目指します。

検出結果が十分なものになれば、その先の深い調査や分析強化を見据えることが可能です。Security Lakeまで広げるのは、運用が安定し関係者の負荷が少なくなってからにしましょう。

Security Hubは前提となる設定や連携条件を確認

Security Hubは有効化すれば使い始めやすいサービスです。ただ、期待する結果を得るには前提条件の確認が欠かせません。

特に、現在はAWS Configとの統合により、AWS Configのマネージドルールやカスタムルールの評価結果を扱えるようになりました。多くの情報が得られる反面、不用意にデータを集めることで内容を理解できないこともあるのです。

そのため、設定評価を監視運用に活かしたいならば、AWS Configの有効化や記録対象の整理も前提に置くべきです。「有効すれば終わり」という考えは捨て、丁寧にひとつづつ整理しましょう。

Security Lakeは目的を決めてから活用

Security Lakeは便利ですが、とりあえず集約するだけでは価値を発揮できません。目的に応じてやるべきことが変化するため、まずは以下のとおり検討してみましょう。

• インシデント調査を効率化したい
• 長期的な傾向を把握したい
• 将来的に他ツールと連携したい

これら以外の選択肢もありますが、いずれにしろ目的によって、重視すべきデータや運用方法が変わります。何のために蓄積するかを先に決めないと、データの保管だけで終わってしまうのです。

収集した情報の活用まで検討

監視運用を形にするには、サービス選定だけでなく運用責任の整理が欠かせません。最低限、以下は決定するようにしておきましょう。

• 誰がSecurity Hubを確認するか
• 重要な検出結果はどの手段で通知するか
• 詳しい調査が必要なときにSecurity Lakeをどう参照するか

細かすぎると感じるかもしれません。しかし、ここまで決めておくことで、導入効果を感じやすくなるのです。加えてEventBridge連携まで考慮すると、通知や後続処理を設計しやすくなります。