はじめに
AWSを利用している皆様は Security Hub をしっかり利用されているでしょうか。
Security Hub を利用されている方でも Trusted Advisor をしっかり利用されているでしょうか。
（Trsuted Advisorは後述するように利用プランによる制限がありますが・・・）
これらのサービスはAWSのセキュリティの改善などに繋がるサービスですが、密接につながっている部分があります。
今回、 Security Hubの コントロールの棚卸しを実施し、不要と判断したコントロールを無効化したところ、意図せず Trusted Advisor の項目も無効化しまいました。
Security HubとTrsuted Advisorは同じConfigルールを使用していました。
備忘として今回の気づきをまとめます。
登場するサービスについて
詳細な説明は省略します。
200文字くらいでChatGPTにまとめてもらいました。
AWS Security Hub
AWS Security Hubは、複数のAWSアカウントやサービス全体のセキュリティ状況を統合的に可視化し、管理するサービスです。業界ベストプラクティスや規制に基づいたセキュリティチェックを自動で実施し、検出結果をダッシュボードで一元管理します。Amazon GuardDuty、Amazon Inspectorなど他のセキュリティサービスと連携し、脅威を迅速に特定し対応を促進します。
AWS Config
AWS Configは、AWSリソースの設定履歴を記録し、構成変更を追跡・評価するサービスです。リソースの現在の状態を可視化し、カスタムルールやAWS提供のマネージドルールを用いて設定のコンプライアンスを監視します。これにより、セキュリティや運用のベストプラクティスに基づいた管理を容易に実現できます。
AWS Trusted Advisor
AWS Trusted Advisorは、AWS環境の最適化を支援するガイドツールです。コスト最適化、パフォーマンス向上、セキュリティ強化、耐障害性向上に役立つ推奨事項を提供します。AWSリソースの設定を分析し、ベストプラクティスに基づいた改善ポイントを提示することで、運用効率と安全性を高めます。
各サービスの関係
ここからは、上記のサービス同士の関係について記載します。
Security Hub と Config
Security Hubを有効化する条件として「AWS Config を有効化する」があります。このことからもSecurity HubとConfigは密接に連携していることが伺えます。
というより、Security Hubの各項目（各コントロール）のセキュリティチェックはほとんどがマネージドな Configルール を用いてチェックされています。
Enabling and configuring AWS Config for Security Hubにも以下のように記されています。
AWS Security Hub uses AWS Config rules to run security checks and generate findings for most controls. ( AWS Security Hub は、AWS Config ルールを使用してセキュリティチェックを実行し、ほとんどのコントロールの検出結果を生成します。)
Some rules, called AWS Config managed rules, are predefined and developed by AWS Config. Other rules are AWS Config custom rules that Security Hub develops.(AWS Config マネージドルールと呼ばれる一部のルールは、AWS Config によって事前定義および開発されています。その他のルールは、Security Hub が開発する AWS Config カスタムルールです。)
Trusted Advisor と Config と Security Hub
Trusted Advisorは「AWS環境の最適化支援サービス」という性質上、様々なAWSサービスと連携（統合）が用意されています。
統合されたサービスはTrusted Advisorコンソールの各項目のページのソースとして表示されます。
Trusted Advisor独自で情報を収集するものもあれば、上記のスクショのように複数のサービスで検出された情報等を活用し、各カテゴリごとに網羅的に表示することができます。
なお、AWS Config と Trusted Advisor を統合するには以下の条件がクリアされている必要があります。
Security Hubの利用にもConfigが有効になっている必要がありますが、それに加えて特定のサポートプランを利用している必要があります。
- AWS Config が有効になっていること
- 該当する AWS Configマネージドルールが有効であること
- 特定のサポートプランを利用していること
- AWS ビジネスサポート
- AWS Enterprise On-Ramp
- AWS エンタープライズサポート
AWS Trusted Advisor が AWS Config を利用した 64 の新しいチェックを追加
Trusted Advisor の情報ソース
それぞれのソースの表示
ここからは冒頭に記載した
今回、 Security Hubの コントロールの棚卸しを実施し、不要と判断したコントロールを無効化したところ、意図せず Trusted Advisor の項目も無効化しまいました。
Security HubとTrsuted Advisorは同じConfigルールを使用していました。
についてです。
Trsusted AdvisorではSecurity Hubを情報ソースとして使用しています。
このように、どのコントロールを参照しているか確認できます。
また、Configも情報ソースとして使用しています。
同じように、どのConfigのマネージドルールを参照しているか確認できます。
Seucurity Hubのソースとして扱わないけどSecurity Hubでも利用するConfigルール
では次に、以下のパターンをご紹介します。
Security HubのRDS.14 Amazon Aurora クラスターではバックトラックが有効になっている必要がありますというコントロールがあります。
このコントロールは裏では aurora-mysql-backtracking-enabled というConfigルールを使用しています。上記のリンクのドキュメントにも記載されています。
そして、この Configuルールは Trsusted Advisorでも利用されており、耐障害性のカテゴリに表示されます。
ソースはConfigとして表示されています。
何が言いたいかというと、
Security Hubのコントロールに使用されていてもTrsusted Advisor上ではConfigとして扱われるケースがある（Security Hubのソースとしては扱われない）
ということです。
上記で紹介した ECR.1 ECRプライベートリポジトリでは、イメージスキャンを設定する必要がありますも、ページを確認すると Configルールの ecr-private-image-scanning-enabled を使用しています。
ECR.1ではTrsusted Advisor上ではソースがSecurity Hubとして扱われています。
RDS.14ではソースがConfigとして扱われています。
上記の2つのルールはどちらもConfigルールを使っているのですが、ソースがSecurity Hubなのか、Configになるのか、この違いがドキュメントでは見つけることができませんでした。
困ること
例えば以下のような目的でSecurity HubとTrsuted Advisorを運用したとします。
- Security HubのスコアをKPIとしており、不要な項目を無効化したい
- Trusted AdvisorはAWSの最適化を目指す目的で、基本的に全項目を確認したい
この場合、今回例にあげた ECR.1 と RDS.14 を無効化したいとなった場合、Trsuted AdvisorでSecurity Hubのソースを確認します。
結果、ECR.1は Trsuted Advisor の Security Hubソースとして利用しているのでこの背景も加味して無効化の可否を検討することができます。
RDS.14 は Security Hubソースとしては確認できません。（RDS.14で使用しているConfigルールを確認し、 Trsuted Advisor の Configソースから確認する必要があります。）
これに気付けないと、意図せず Trsuted Advisorの項目を無効化してしまいます。
以上が本記事でお伝えしたかった内容です。
ここまで厳密に考慮する必要があるケースは稀かと思いますが、意図せず Trsuted Advisor の項目を無効化してしまう、というリスクがあるのだなあという学びがありました。
（正直、ややこしいのでもう少し Trsuted AdvisorのソースとConfigルールの関係が把握しやすくなればいいなあと思いました。）