【初心者向け】AWS Security Hubにおける「重大」な検出結果と運用を理解しよう

最近、有名企業に対するサイバー攻撃のニュースを耳にすることが多くなりました。
「事前に知っていれば対策できたのに…」と後悔しても、後の祭りです。

AWS環境においても、セキュリティの脆弱性を見つけて事前に対策しておきたいですよね。

本ブログでは、対策の第一歩として、セキュリティ状態を把握するサービス「AWS Security Hub」について紹介します。

AWS Security Hubと重要度の理解

AWS Security Hubは、AWS環境のセキュリティ状態を一元管理するサービスです。

AWSには複数のセキュリティサービス（Amazon GuardDuty、Amazon Inspector、Amazon Macie等）が存在しますが、それらの統合的なビューの役割を持っています。

セキュリティのベストプラクティスに反する設定や、潜在的なリスクがある場合に自動で検知し、改善を促してくれます。

基本的な機能や見方については、下記のブログをご覧ください。

https://aws.taf-jp.com/blog/127404

検出結果の項目数は333項目（2025/10/03時点）もあります。

参照：Security Hub CSPM のコントロールリファレンス

https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-controls-reference.html

リソースが複数ある環境では1項目に対して複数の検出結果が見られる場合もあり、どの結果に何から対応したらよいか困る方も多いと思います。

そこで、AWS Security Hubでは、検出結果を「重要度」によって分類する機能が存在しています。

＜検出結果の重要度分類＞

各検出結果は、上記のいずれかに分類されます。

この分類基準について、AWS公式ドキュメントでは以下のように記載されています。

重要度は、以下の基準の評価に基づいて決定されます:

• 脅威アクターがコントロールに関連する設定の弱点を利用する際の難易度 この難易度は、弱点を利用して脅威シナリオを実行するために必要な洗練度または複雑さの度合いによって決まります。
• 弱点が AWS アカウント または リソースの侵害につながる可能性はどの程度ですか？ AWS アカウント または リソースの侵害は、データまたは AWS インフラストラクチャの機密性、完全性、可用性が何らかの形で損なわれることを意味します。侵害の可能性は、脅威シナリオが AWS のサービス または リソースの中断または違反につながる可能性を示します。

コントロールの検出結果の重要度レベル

つまり、攻撃者にとって「攻撃されやすく」「影響が大きい」項目ほど重要度が高くなっています。それらを放置すると重大なインシデントに発展するリスクがあります。

重要度「重大」の検出結果

では、実際に「重大」と分類される検出結果を見ていきましょう。現在全25項目ありますが、実は半数以上が「リソースのパブリックアクセス禁止」と「スナップショットのパブリック復元禁止」の2つのテーマに集中しています。これは、AWSがこの2点をいかに重要視しているかが表れています。

それぞれの項目について、『何が危険なのか』『どう対応すべきか』を具体的に解説していきます。

＜リソースのパブリックアクセス禁止：14項目＞

KMS.5 KMS keys should not be publicly accessible

内容：KMSキーは、パブリックにアクセス可能であるべきではありません。

危険性：KMSキーが公開されると、誰でもそのキーを使用してデータの暗号化・復号化が可能になります。これにより、機密データの漏洩、不正なデータアクセス、暗号化されたリソース（S3バケット、RDSデータベース、EBSボリュームなど）への不正アクセスが発生する可能性があります。また、攻撃者による暗号化操作でコストが増大するリスクもあります。

対応：必要最小限のプリンシパル（特定のIAMロール、ユーザー、AWSアカウント）のみにアクセスを制限しましょう。

• S3.2 S3 general purpose buckets should block public read access

内容：S3汎用バケットでは、パブリック読み取りアクセスをブロックする必要があります。

• S3.3 S3 general purpose buckets should block public write access

内容：S3汎用バケットでは、パブリック書き込みアクセスをブロックする必要があります。

• S3.19 S3 access points should have block public access settings enabled

内容：S3アクセスポイントでは、パブリックアクセスブロック設定を有効にする必要があります。

危険性：誰でもアクセスし、読み取りや書き込みができ攻撃の対象になりやすく、そのリソースから機密データが漏洩するリスクがあります。

対応：ブロックパブリックアクセスをオンにしましょう。要件的にパブリックアクセス（インターネットからの接続）が必要な場合は、オリジンアクセスコントロール（OAC）やバケットポリシーで、必要最小限のプリンシパル（特定のIAMロール、ユーザー、AWSアカウント）のみにアクセスを制限しましょう。

• Lambda.1 Lambda function policies should prohibit public access

内容：Lambda関数のポリシーは、パブリックアクセスを禁止する必要があります。

• RDS.2 RDS DB Instances should prohibit public access, as determined by the PubliclyAccessible configuration

内容：RDS DBインスタンスは、PubliclyAccessible 設定によって決定されるパブリックアクセスを禁止する必要があります。

• Redshift.1 Amazon Redshift clusters should prohibit public access

内容：Redshiftクラスターは、パブリックアクセスを禁止する必要があります。

• DMS.1 Database Migration Service replication instances should not be public

内容：Database Migration Serviceのレプリケーションインスタンスは、パブリックであるべきではありません。

• EMR.2 Amazon EMR block public access setting should be enabled

内容：EMRのパブリックアクセスブロック設定を有効にする必要があります。

• Opensearch.2 OpenSearch domains should not be publicly accessible

内容：OpenSearchドメインは、パブリックにアクセス可能であるべきではありません。

• ES.2 Elasticsearch domains should not be publicly accessible

内容：Elasticsearchドメインは、パブリックにアクセス可能であるべきではありません。

• MSK.4 Amazon MSK clusters should have public access disabled

内容：Amazon MSKクラスターでは、パブリックアクセスを無効にする必要があります。

危険性：誰でも呼び出しやアクセスができ攻撃の対象になりやすく、そのリソースや関連するリソースから機密データが漏洩するリスクがあります。

対応：できる限りプライベートでのアクセスに限定しましょう。

パブリックエンドポイントではなく、VPCエンドポイントを使用しましょう。

要件的にパブリックアクセスの禁止が難しい場合は、セキュリティグループでアクセス元を必要最小限にしぼりましょう。

• SSM.4 SSM documents should not be public

内容：SSMドキュメントは、パブリックであるべきではありません。

• SSM.7 SSM documents should have the block public sharing setting enabled

内容：SSMドキュメントでは、パブリック共有ブロック設定を有効にする必要があります。

危険性：誰でも呼び出しやアクセスができ攻撃の対象になりやすく、そのリソースや関連するリソースから機密データが漏洩するリスクがあります。

対応：SSMドキュメントは、プライベートでのアクセスに限定しましょう。

＜スナップショットのパブリックで復元禁止：4項目＞

• EC2.1 EBS snapshots should not be publicly restorable

内容：EBSスナップショットは、パブリックに復元可能であるべきではありません。

• RDS.1 RDS snapshot should be private

内容：RDSスナップショットは、プライベートであるべきです。

• DocumentDB.3 Amazon DocumentDB manual cluster snapshots should not be public

内容：DocumentDBの手動クラスタースナップショットは、パブリックであるべきではありません。

• Neptune.3 Neptune DB cluster snapshots should not be public

内容：Neptune DBクラスターのスナップショットは、パブリックであるべきではありません。

危険性：パブリックに復元可能な場合、誰でも復元できます。その中に含まれる機密データ漏洩のリスクが極めて高まります。

対応：共有設定を[パブリック]ではなく、[プライベート]で設定しましょう。特定のAWSアカウントとのみ共有が必要な場合は、共有したいAWSアカウントIDを指定した[プライベート]共有設定にしましょう。

＜その他の検出結果＞

• IAM.4 IAM root user access key should not exist

内容：IAMルートユーザーのアクセスキーは、存在してはなりません。

危険性：最高権限を持つユーザーのアクセスキーが、コード埋め込みやGitHubへの誤プッシュなどによって万が一漏洩した場合、リソースの作成、削除、悪用などやりたい放題になってしまいます。

対応：アクセスキーを削除し、日々の運用にはIAMユーザーやIAMロールを使用しましょう。

• IAM.6 Hardware MFA should be enabled for the root user

内容：ルートユーザーには、ハードウェアMFAを有効にする必要があります。

危険性：仮想MFAは、ハードウェアMFAと比較してセキュリティレベルが低く、フィッシング攻撃やマルウェアによる窃取リスクがあります。

対応：ハードウェアMFAデバイスを購入し、設定しましょう。

• KMS.3 AWS KMS keys should not be deleted unintentionally

内容：AWS KMSキーは、意図せず削除されるべきではありません。

危険性：KMSキーを削除すると、そのキーで暗号化されたすべてのデータ(S3オブジェクト、EBSボリューム、RDSデータベースなど)が永久に復号化不可能になります。誤削除による業務停止やデータロストは甚大な被害をもたらします。

対応：KMSキーの削除保留期間を7日以上(推奨は30日)に設定しましょう。削除前の対象キーで暗号化されたリソース確認も重要です。

• EC2.19 Security groups should not allow unrestricted access to ports with high risk

内容：セキュリティグループは、リスクの高いポートへの無制限のアクセスを許可するべきではありません。

危険性：システム制御や機密データに関係するポートについて、誰でもアクセスできてしまうと、システムへの不正侵入や情報漏洩などのリスクが高まります。

対応：アクセス元を必要最小限にしぼりましょう。

• CodeBuild.1 CodeBuild Bitbucket source repository URLs should not contain sensitive credentials

内容：CodeBuildのBitbucketソースリポジトリURLには、機密性の高い認証情報を含めるべきではありません。

危険性：認証情報の漏洩により不正アクセスや不正利用のリスクが高まります。

対応：平文で保存・送信される認証情報を削除しましょう。認証は、OAuth認証へ切り替えましょう。

• CodeBuild.2 CodeBuild project environment variables should not contain clear text credentials

内容：CodeBuildプロジェクトの環境変数には、平文の認証情報を含めるべきではありません。

危険性：認証情報の漏洩により不正アクセスや不正利用のリスクが高まります。

対応：CodeBuildプロジェクトの環境変数からAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYを削除しましょう。

AWS Systems Manager Parameter StoreまたはAWS Secrets Managerに認証情報を保存し、ビルド仕様(buildspec.yml)から安全に取得する設定に変更しましょう。

• Config.1 AWS Config should be enabled and use the service-linked role for resource recording

内容：AWS Configを有効にし、リソース記録にサービスにリンクされたロールを使用する必要があります。

危険性：設定変更があった際に、セキュリティインシデント発生時の原因調査や証跡追跡ができません。また、AWS Security Hubの大部分はAWS Configのデータを使用しているため、不十分な検出結果となってしまう可能性があります。

対応：AWS Security Hubを使用するすべてのリージョンでAWS Configを有効化しましょう。

AWS Security Hubの運用

検出項目について少し理解が深まったところで、実際にAWS Security Hubを運用していくうえで注意すべき点について解説します。

1. コンプライアンス標準の選択

自社に適したコンプライアンス標準を選択しましょう。基本となるのは、CIS AWS Foundations Benchmarkです。決済情報を扱う場合はPCI-DSS、業界や組織の要件に応じてNIST CSFやISO 27001などの標準も検討してください。複数の標準を有効化することも可能ですが、運用負荷とのバランスを考慮することが重要です。

2. 対応フローの整備

検出結果に対する対応フローを事前に整備しておきましょう。

誰がトリアージを行い、誰が修正を実施するのか、エスカレーションパスはどうするのかを明確にします。

また、対応期限の設定やチケット管理システムとの連携も検討し、検出から修正完了までのプロセスを可視化できる体制を構築しましょう。

3. 優先順位をつける

すべての検出結果に同時に対応するのは現実的ではありません。

重要度だけでなくビジネス影響度も考慮して優先順位をつけましょう。

一般的には、本番環境を開発環境より、個人情報を扱うシステムを内部システムより、外部公開サービスを内部サービスより優先します。

この優先順位に基づいて、段階的に対応を進めていくことが成功の鍵です。

4. マルチアカウントでの一元管理

企業などで複数のAWSアカウントを運用している場合、AWS Organizationsとの統合により管理者アカウントでAWS Security Hubを一元管理できます。これにより、組織全体のセキュリティ状況を単一のダッシュボードで把握でき、アカウントごとに個別にログインする手間が省けます。スケーラブルなセキュリティ管理の実現には不可欠な機能です。

5. 誤検知への対応

ビジネス要件上問題のない検出結果には、抑制ルールを設定してノイズを減らしましょう。

ただし、抑制理由は必ず文書化し、定期的に見直すことが重要です。

ビジネス要件が変われば、以前は問題なかった設定が新たなリスクになる可能性もあります。

抑制ルールの棚卸しを定期的に実施する運用を確立しましょう。

まとめ

本ブログでは、AWS環境のセキュリティ環境の把握の第一歩として、AWS Security Hubの検出結果や運用について紹介しました。まずは、一度有効化し「実力テスト」をしてみて、「重大」から対策をしていきましょう。そして、AWS Security Hubは継続的な運用こそが重要です。「定期テスト」によって安全な環境を維持していきましょう。

上記サービスの導入に関してお困りでしたら、是非お気軽にお問合せください。

最後までお読みいただき、ありがとうございました。