AWS Security Hub とリスク分析を考慮したアラート対応アプローチ ~ 初期導入・運用設計を考える

こんにちは、2023 年 8 月にAWS Security Hero に選ばれました、吉江です。セキュリティコンサルタントであり、日本の AWS ユーザーグループである JAWS-UG の中でも、セキュリティに特化した Security-JAWS を運営しています。

　本日は、AWS Security Hub を含むクラウドセキュリティ体制管理 (Cloud Securitry Posture Management : 以下 CSPM) をまだ導入していない方に向け、導入検討時に考えるべきことや運用設計について触れたいと思います。

X ポスト » | Facebook シェア » | はてブ »

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。 

クラウドのリソースの設定を監視して脆弱な設定や設定不備を検知することによりセキュリティリスクを可視化し、レスポンスを行うためのしくみです。

管理対象となるクラウドのサービスと紐づけることで、クラウド上の脆弱な設定や設定不備のあるリソースを発見し、それらの設定に関してアラートをあげ、自動修復するといったことを考えることが可能です。

CSPM を導入することにより、管理対象となる環境に対してどれだけセキュリティ対策が行えているのかを自己評価することが可能であり、継続的な監視を行うことができます。そうして評価されたスコアを高めていくことで、自律的なサイバーセキュリティの高度化を促すことができます。

サイバーセキュリティの対策を立案するための工程は、現状把握、分析、計画立案です。現状把握を行うのに CSPM はとても有効な手段でもあります。さらに、CSPMの検出結果の一部をクラウドセキュリティ監査にも活用することが可能です。

CSPM では確認できない項目は、手動でクラウドセキュリティチェックを行う必要がありますが、多くの工数を簡略化できるでしょう。

2019 年に AWS Security Hub は、AWS が提供するマネージドな CSPM サービスとしてリリースされました。AWS Foundational Security Best Practices (FSBP) 標準 やサポートされている業界のベストプラクティスや標準に照らして、アカウントレベルとリソースレベルの設定を継続的に自動チェックします。

AWS Security Hub は、これらのチェックの結果をスコアとして提供し、注意が必要な特定のアカウントとリソースを特定します。さらに、自動修復をサポートしてくれます。2023 年の AWS re:Inforce では、自動化ルールが発表 され、検出された結果のフィールドを自動更新したり、検出結果を除外させるために非表示にするといったことも可能となりました。その直後には AWS Control Tower との統合 も発表され、

2023 年の AWS re:Invent でも複数の機能アップデートが発表されました。まだまだこれからも機能追加が行われるサービスと考えられます。

AWS Security Hub の特徴を見ていきましょう。

AWS Security Hub は、AWS リソースに関して、複数リージョンの検出結果を集約するクロスリージョン集約や、複数のAWS アカウントにわたるマルチアカウントのセキュリティ管理にも対応しています。マルチアカウントについては、AWS Organizations や AWS Control Tower を利用していない場合であっても、管理者アカウントを指定することで、特定の AWS アカウントにて AWS Security Hub による検知内容を集約することが可能です。

導入にあたっては、AWS Security Hub は有効化のためのボタンを押下するのみでとても簡単です。

セキュリティ標準についてみてみると、以下のフレームワークに対応しています。

• AWS Foundational Security Best Practices(FSBP)

• CIS AWS Foundations Benchmark v1.2.0

• CIS AWS Foundations Benchmark v1.4.0

• NIST SP 800-53 Revision 5

• PCI DSS v3.2.1

本フレームワークから技術的にチェックが可能な項目を AWS Security Hub にて確認することができます。

検出結果を集約するための統合という観点で言えば、以下は AWS Security Hub に結果を送信・統合 される他の AWS マネージド・サービスの一例です。

• AWS Config

• Amazon GuardDuty

• Amazon Inspector

• Amazon Macie

• AWS Health (セキュリティに関するアラートのみ)

• AWS IAM Access Analyzer

• AWS Systems Manager Patch Manager

• AWS Firewall Manager

AWS ネイティブのマネージドサービスを多く統合することができるため、AWS 内で連携しやすいと言えるでしょう。また、AWS とのパートナーシップを結んでいる複数の 3rd パーティーベンダーも存在し、それらのサービスで検知した内容を AWS Security Hub に送信し、AWS Security Hub 上のダッシュボードで結果を統合し、検知内容を一元管理することも可能です。

アラートを通知するにあたり、Amazon EventBridge を通じて、Amazon SNS や AWS Chatbot への連携が可能なので、メールはもちろん自社で利用している Chatops ツールへの連携も可能です。また、自動修復 のためのアクションを行うために AWS Lambda、AWS Step Functions、AWS Systems Manager Run Command 等を連携先として指定することも可能です。一方で、属人的な運用を排除することを目指して、何をどのように自動修復を設定するかはシステムに対するかなり熟考した設計の理解と実装が必要となります。当初目論んだ運用設計どおりに Playbook の実装や自動修復が行えたからといって、システムアーキテクチャが変わる等の変革が訪れるとともに、当初設定した運用設計自体もまた可能性があるためです。これからAWS Security Hubの導入を考えられている方々にはいきなり自動修復を目指すのではなく、運用設計やシステムのアーキテクチャの変更可能性などをきちんと検討いただくことをおすすめします。その上で、後のフェーズにて改めて 自動化 を検討されるのが良いと考えます。

AWS Security Hub にしても、3rd パーティー CSPM を利用するにしても、運用するイメージを最初にある程度立てておくのが良いでしょう。

アラートが鳴りすぎて疲弊して、運用出来そうにありませんという声はよく聞きます。導入する際には運用設計を考えておく必要がありますので、参考にいただけると幸いです。ここからは、AWS Security Hub の初期設定と運用設計について気をつけておくべきポイントを述べたいとおもいます。

ここでは最低限検討しておくべき運用設計を列挙します。

初期設定の中で、利用していない AWS サービスにおける不要な AWS Security Hub の Control を除外するとしましたが、今後、該当サービスを利用することになった場合は、 Control を再度有効にすることをルールとして定めておくことです。

次に、 AWS Security Hub の新しい Control が増えた場合は自動的に有効化となるようにしておきましょう。同様に Amazon SNS と連携して、AWS Security Hub の発表をサブスクライブすることをおすすめします。受け取った際はほんの少しの工数を使って、新規で増えたり、更新となった Control の要否の判断と、Control を有効化とするなら必要に応じてアラート対応、不要とするなら除外対応を行いましょう。

ここで注意点としてあげておきたいのは、対応速度です。一年に一度の棚卸しを、といったことを耳にしますが、数日内にあるいは当日のうちに対策方針を決めるくらいのスピード感で実施したほうが楽だと考えます。ソフトウェアバージョンアップ対応ほどに大変な思いをするわけではないので、一定の保守工数の中でエラスティックに対応し、後回しにしないことをおすすめします。

これらの対応がそれぞれ行えるようになったならば、自動化の対応 を検討するフェーズに進むことも良いと思います。ですが、「運用」の本質は「価値の提供」であり、ユーザーへサービスの価値を提供できるなら「手段」は何でも良いのです (私が尊敬する方の言葉です)。自動化を目的とせず、運用の効率化に着目しながら、セキュリティとしての価値、そしてビジネスにコミットするための価値を築いてほしいと考えます。

本稿では、CSPM を題材に、AWS Security Hub の特徴、AWS Security Hub の初期導入と運用設計について述べました。

あくまで私個人の意見ですが、本番サービスに影響を出すといったものではないので、もっとカジュアルに CSPM に取り組んでみてもいいと思っています。それでも、AWS Security Hub 対応や、その他 AWS セキュリティサービスなど、何から手をつけたらいいのかわからなくて大変だといった場合の読者には、AWS Security Maturity Model (AWS セキュリティ成熟度モデル) を一度読んでいただくことをおすすめします。そして運用設計を考える上でどういった観点が必要なのか、イメージした上で各種セキュリティサービスを導入いただくことをおすすめします。

焦ることはなく、段階的にこつこつと取り組んでいきましょう。