概要

今回は、AWS Security Hubについての説明や、スコアが低い時にどのように上げていくと良いか、考慮すべき事項などについて調査したことをまとめます。

AWS Security Hubとは

AWS 内のセキュリティの状態と、セキュリティ標準およびベストプラクティスに準拠しているかどうかを、包括的に把握 できるようするものです。

AWS Security Hub はクラウドセキュリティ態勢管理 (CSPM) サービスで、AWS リソースに対してセキュリティのベストプラクティスを自動的かつ継続的にチェックして設定ミスを特定し、
セキュリティアラート (検出結果) を標準化された形式で集約して、より簡単に強化、調査、修正できるようにします。

つまり、セキュリティサービスの検出結果を一元管理することによって、問題がある箇所の調査・修正時間を短縮できます。

CIS AWS Foundations Benchmark v3.0.0とは？

AWSのセキュリティ構成のベストプラクティスのセットであり、明確なステップバイステップの実装と評価手順を提供します。
オペレーティングシステムからクラウドサービス、ネットワークデバイスに至るまで、このベンチマークのコントロールは、組織が使用する特定のシステムを保護するのに役立ちます。

AWS Security Hubは、CIS AWS Foundations Benchmark v3.0.0、1.4.0、v1.2.0をサポートしています。

重要度の基準は以下の通り

重要度の定義

重要度ラベルは次のように定義されています。

重大 - この問題は、さらに悪化しないように直ちに修復する必要があります。
高 - この問題は短期的な優先事項として対処する必要があります。
中 - この問題は、中期的な優先事項として対処する必要があります。
低 - この問題には、独自のアクションは必要ありません。

自社のSecurity Hubのスコア、知ってますか？

全体で見ると75%でしたが、CIS AWS Foundations Benchmark v3.0.0は28%と低いスコアとなっていました。

今回は特に、後者のスコアを上げていくことを考えたいと思います。

どこまでやるべきか？スコアは何%を目指すべきか？

この記事を書くにあたりいくつかの事例を引用・参考にしましたが、概ね80%前後のものが多い印象で、可能であれば100%を目指すのが良いようです。

実際、Security Hubでは修正方法が詳細に記載されており、100%を目指すこと自体は可能です。
しかし、やろうとすると以下の問題に直面します。

運用負荷とのバランス

スコアが低い場合、その理由としてはここが最も大きいのではないでしょうか。
例えば、「IAMユーザーのアクセスキーを90日でローテーションする」や「ルートユーザーの認証に物理MFAデバイスを利用する」など、導入することにより運用負荷が上がることから取り入れていない場合もあると思います。

修正することにより新たにかかるコストは？

修正には追加設定やリソースが必要となり、それらにコストがかかる場合もあります。
例えばCloudTrailログや、S3アクセスログの保存およびログファイルへのアクセス、物理MFAデバイスの購入などにも料金がかかります。

これらのコストが積み重なることによりいずれ無視できないものになる可能性があるため、セキュリティ要件とコストとの兼ね合いを考える必要があります。

修正にかかる工数

修正するにも人手が必要です。

Security Hubでは、コンソールにスキャン結果がデータとしてまとめられており、修復のための調査がしやすくなっています。また、後述する自動修復機能も利用可能です。
ただし、それらを利用した上でも工数はかかります。

例えば手動で直す場合は、修復手順のドキュメントを確認し、コンソールやCLIから適切な操作をする必要があります。また、Terraform等でIaC化されている場合は、修復したことによる実際のインフラとコードとの差分を合わせる作業が必要となります。

そもそも本当に修正が必要なのか？の検討

失敗コントロールの中には、所属企業のポリシーやプロジェクトの要件的に不要なものもあると思います。

例えば、「CloudTrailのログファイルの暗号化をデフォルトからSSE-KMS暗号化に変更する」など、必要なければ設定しなくても問題ない項目もあります。
もちろん設定した方がより強固なセキュリティを確保できますが、先に挙げた運用負荷や修正工数、修正することによる新たなコストを考慮して決定すべきです。

現実的なラインを模索する

上記の課題を踏まえて、現実的にどの程度であれば無理なく実現可能かを考えていきます。

全ての検査項目をONにしておく必要はない。不要なら無効化（または抑制済み）できる。

こちらのスライドでは、自社のセキュリティポリシーや、重要度などによってコントロールを無効化することを検討する必要性が紹介されています。

無効化することによりスコア計算の分母が減りスコア上昇につながるだけでなく、コスト削減も見込めます。
これは、Security Hubによるスキャンやレポート処理が減ることや、失敗コントロールを修正するために必要な新たなリソース利用が不要となることなどが理由です。

例えば、VPCフローログを有効にする必要のあるコントロールがあります。このコントロールを無効化して評価対象から外すことで、フローログ分の料金も節約できます。

こちらの記事では、スコアを上げるために無効化する項目と、その考え方について紹介されています。

ちなみに、SUPPRESSED(抑制済み) にすることも可能です。
これは、コントロールを有効化したまま、検出結果を無視することができます。

自動修復機能も使える

Security Hubでは、失敗コントロールの自動修復機能が用意されています。
料金は以下の通りです。

自動修復機能を使用する上でのメリットとデメリット

じゃあ全部自動修正すればいいじゃん！と思うかもしれませんが、そうはいかないのが難しいところです。
確かに、この機能のメリットとして、ワンクリックや自動で修正できる点が挙げられます。

一方デメリットとしてドリフトの発生があります。
ドリフトとは、terraformやAWS CloudFormationのようなIaCに記述されたコードと、実際のAWSリソースとの差分のことを指します。

自動修復機能を使用すると、失敗コントロールをワンクリックで修正できますが、その修正はIaCには反映されないため手動でコードを修正する必要が出てきます。

また、ドリフト検知をせずにterraformからインフラを更新しようとすると、せっかく自動修復されたものが上書きされてしまうことがあります。

以下の資料にもドリフト発生への注意について記載されています。

注意: 修復は、早急な対処が必要な緊急事態を対象としています。このソリューションでは、AWS Security Hub コンソールから開始された場合にのみ、検出結果を修正するための変更を行います。
これらの変更を元に戻すには、リソースを手動で元の状態に戻す必要があります。AWS CloudFormation スタックの一部としてデプロイされた AWS リソースを修正する場合は、ドリフトが発生する可能性があることに注意してください。可能な場合は、スタックのリソースを定義するコードを変更し、スタックを更新して、スタックのリソースを修正してください。詳細については、 AWS CloudFormation ユーザーガイドの「ドリフトとは」を参照してください。

ちなみに、terraform cloudにはドリフト検知機能があるそうです。（ドリフト検知の実演は5:20〜）

なお、以下スライドでは自動化導入前にガートレール設定で対応できるかチェックした方がいいと説明されています。
確かに、そもそも間違った設定をさせないよう予防できればそれが一番ですね。

継続的かつ段階的にスコアを上げていく

上記を踏まえて、どのような戦略でスコアを上げていくのかを考えます。
前提として、テスト環境と本番環境がそれぞれ用意されているものとすると、まずはテスト環境で検証することが重要です。

28%というスコアからの改善となるため、いきなり100%を目指すのは難しいでしょう。
セキュリティ専門の担当者がいれば別ですが、そうでない場合は基本的に開発タスクと兼任することになります。そのため担当メンバーの負荷が上がることになってしまいます。

そこで第一段階として40〜50%を目指すというのが、現実的な目標となると思います。

スコア改善のため、まずはそれぞれの環境で不要なコントロールを無効化します。これによってスコア計算の分母が減り、スコアが上昇します。

次に、残った失敗コントロールのうち重要度が高いもの・影響範囲が狭いもの等をテスト環境で修正します。この時自動修正機能を試してみてもいいと思います。ドリフトの修正含め、どの程度の修正工数がかかるかをここでチェックします。

この結果を見て、テスト環境での運用が問題なければ本番環境での修正を実施します。この一連の流れを繰り返すことで、徐々に安全にスコアを上げていけると考えられます。