【アップデート】AWS Security Hub の『基礎セキュリティのベストプラクティス』に新たに36個のチェック項目が追加されました(2022年7月〜9月)
みなさん、こんにちは。
AWS事業本部コンサルティング部の芦沢(＠ashi_ssan)です。
みなさま、Security Hub運用されていますか？
ここ数ヶ月の間で『AWS 基礎セキュリティのベストプラクティス v1.0.0』に新しいチェック項目(コントロール)が 追加されました。AWS公式からも以下のようにアナウンスされています。
7月のアップデートで35個、9月のアップデートで1個のコントロールが追加されたため、2022年7月〜9月の期間で合計36個1の項目が追加されたことになります。
本エントリでは、新規追加されたコントロールを簡単なコメント付きで紹介していきます。 (コントロールの題目はまだ日本語化されていないので、 DeepL を活用して訳しています)
AWS Auto Scalling
[AutoScaling.3]Auto Scaling グループは、EC2インスタンスが Instance Metadata Service Version 2 (IMDSv2) を必要とするように設定すべき
重要度: HIGH
コメント:
- 従来の IMDSv1 は無期限サポートであり、IMDSv2への移行コストが発生するため、対応は必須ではないです。
- IMDSv2への移行により、SSRFなどの攻撃に対して一定の耐性があるなどのメリットがあります。
[AutoScaling.4]Auto Scaling グループの起動設定でメタデータ応答のホップリミットを1より大きくすべきではない
重要度: HIGH
コメント:
- ホップリミットを1にすることで、IMDSのPUTレスポンスをEC2インスタンスのみに制限できます。
- IMDSの不正利用を防ぐことができるため、原則対応しましょう。
- ただし、EC2のコンテナ環境においてはホップ数を2にするケースがある。
[AutoScaling.6]Auto Scaling グループは複数のインスタンスタイプを複数のアベイラビリティーゾーンで使用すべき
重要度: MEDIUM
コメント:
- 「アベイラビリティーゾーン内で特定のインスタンスタイプが不足する」ような可用性に影響が出るイベントに備えるために役立ちます。
- 高可用性が求められるワークロードでは対応すると良いです。
[AutoScaling.9]EC2 Auto ScalingグループはEC2起動テンプレートを使用する必要がある
重要度: MEDIUM
AWSドキュメント: [AutoScaling.9] EC2 Auto Scaling groups should use EC2 launch templates
コメント:
- 起動テンプレートは起動設定の後継機能で、起動テンプレートだとAuto Scalingの最新機能や改善点を確実に利用可能です。
- AWSも起動テンプレートの使用を強く推奨しており、今後起動設定が廃止される可能性も考えられるためCMとしては起動テンプレートの使用を推奨します。
AWS CloudFormation
[CloudFormation.1]CloudFormationスタックに対してSNSによる通知を設定すること
重要度: LOW
AWSドキュメント: [CloudFormation.1] CloudFormation stacks should be integrated with Simple Notification Service (SNS)
コメント:
- スタック更新が失敗した時等に通知が必要な場合は設定しましょう。
- EventBridgeで一括して通知設定を行うケースやCI/CDパイプライン側で通知を作り込むケースも想定されるため、対応必須とまでは言えません。
Amazon CloudFront
[CloudFront.10]CloudFrontディストリビューションは、エッジロケーションとカスタムオリジン間で非推奨のSSLプロトコルを使用しないでください
重要度: MEDIUM
コメント:
- CloudFrontとカスタムオリジン(EC2やオンプレのWebサーバ、S3静的ウェブサイト等)間のHTTPS通信で、SSLプロトコルに SSLv3 を使用しているかチェックします。
- 非推奨なSSLプロトコルの利用はセキュリティリスクにつながるため、CloudFrontとカスタムオリジン間のHTTPS通信は TLS1.2 以降を使用しましょう。
- 業務上 SSLv3 を使う必要があり、リスクを受容することが可能な場合は、抑制済み登録をしてください。
Amazon EC2
[EC2.23]EC2 Transit Gateway はVPCアタッチメントのリクエストを自動承諾すべきではない
重要度: HIGH
AWSドキュメント: [EC2.23] EC2 Transit Gateways should not automatically accept VPC attachment requests
コメント:
- 自動承諾をONにすると、「TGW共有先アカウントで作成したVPCアタッチメント」のリクエストを共有元アカウントで自動で受けいれます。
- 「意図しないVPCアタッチメントの作成」を防ぐために有効なので、基本は対応したほうが良いです。
- ただし、手動承認のコストが環境構築・運用で大きなボトルネックになっている場合は「抑制済み」対応でも問題ないです。
[EC2.24]準仮想化(PV)のEC2インスタンスは使うべきではありません
重要度: MEDIUM
AWSドキュメント: [EC2.24] Paravirtual EC2 instance types should not be used
コメント:
- 最適なパフォーマンスを得るために、PVではなくHVMを使用することを推奨します。
- 最新のインスタンスタイプはPVでは起動できず、ハードウェア拡張(拡張ネットワーキング等)もPVでは選択不可です。
Amazon ECR
[ECR.1]ECRプライベートリポジトリは、イメージスキャンを設定する必要があります
重要度: HIGH
AWSドキュメント: [ECR.1] ECR private repositories should have image scanning configured
コメント:
- イメージスキャンにより、コンテナイメージ内のOSパッケージの脆弱性を特定することが可能です。
- 別途3rd Partyのイメージスキャンを行っていないのであれば必須です。
- ECRのイメージスキャンには、基本スキャンと拡張スキャンがあります。
- 基本スキャン：OSパッケージの脆弱性を特定することが可能であり、Push時および手動スキャンに対応し、追加コストは発生しません。
- 拡張スキャン：Amazon Inspectorと統合され、OSパッケージのみならずサポート対象のプログラミング言語パッケージの脆弱性も特定することが可能です。
- 拡張スキャンはInspectorの利用コストが別途発生する点に注意です。
- また、リポジトリレベルのスキャン設定は非推奨となっており、プライベートリボジトリ全体への設定を推奨します。
[ECR.2]ECRプライベートリポジトリは、タグのイミュービリティを設定する必要があります
重要度: MEDIUM
AWSドキュメント: [ECR.2] ECR private repositories should have tag immutability configured
コメント:
- タグのイミュータビリティを有効にすると、同じタグを利用したイメージのリポジトリへのPushを防止できます。
- イメージ毎に一意のタグを付与することで、開発チームが作成したイメージと、実際に運用されているイメージの識別を容易にできます。
- 一意のタグの例としては、コミットIDやコミットハッシュなどを利用するケースがあります。
- たとえば、タグのイミュータビリティを無効にし、latestタグのまま運用した場合、予期しないバージョンのイメージが本番で起動し問題となり得る可能性があります。
Amazon ECS
[ECS.3]ECS タスクの定義では、ホストのPID Namespaceを共有しないでください
重要度: HIGH
AWSドキュメント: [ECS.3] ECS task definitions should not share the host's process namespace
コメント:
- コンテナ定義のpidModeパラメータがhostである場合、コンテナインスタンスと同じPID Namaspaceを共有することになります。
- さらにprivilegedパラメータがtrueであり、特権コンテナで実行されている場合、コンテナインスタンスへの特権昇格に繋がる可能性があります。
- ホストのPID Namespaceを共有しないことを推奨します。
[ECS.4]ECSコンテナは、非特権モードで実行する必要がある
重要度: HIGH
AWSドキュメント: [ECS.4] ECS containers should run as non-privileged
コメント:
- コンテナ定義のprivilegedパラメータがtrueである場合、コンテナインスタンスに対するルート権限を備えた特権コンテナとなり、通常ではアクセスできないリソースへのアクセスが可能となります。
- セキュリティが十分でない特権コンテナはセキュリティホールになり得るため、非特権モードでのコンテナ実行を推奨します。
[ECS.5]ECSコンテナは、ルートファイルシステムへのアクセスを読み取り専用に制限する必要があります。
重要度: HIGH
AWSドキュメント: [ECS.5] ECS containers should be limited to read-only access to root filesystems
コメント:
- バックドア目的のファイル配置ができなくなるため、厳格なセキュリティ要件が求められる場合は対応しましょう。
- 有効化する場合は下記を満たす必要があります。
- アプリケーション側でルートファイルシステムへの書き込みをしていないこと
- 各種ミドルウェアや利用しているソフトウェアエージェントがルートファイルシステムへの書き込みをしていないこと
- ECS Execを利用しないこと
- アプリケーションの動作に影響するため、有効化の際はStorageWriteBytesなどのメトリクスも確認しながら慎重に対応する必要があります。
- アプリケーションやエージェントの特性に依ってはファイルシステムへの書き込みが避けられず、工数を考えて対応しないことも考えられます。
[ECS.8]シークレットはコンテナ環境変数へ渡すべきではない
重要度: HIGH
AWSドキュメント: [ECS.8] Secrets should not be passed as container environment variables
コメント:
- この項目ではコンテナ環境変数に AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、ECS_ENGINE_AUTH_DATAのいずれかが入っていないかチェックを行います。
- 機密情報をプレーンテキストで渡してはいけないため、原則対応しましょう。
- 代替案として、Systems Manager Parameter Store もしくは Secrets Manager に機密情報を保存しそれを参照する構成にする、というものがあります。
[ECS.12]ECSクラスタはContainer Insightsを有効にする必要があります
重要度: MEDIUM
AWSドキュメント: [ECS.12] ECS clusters should have Container Insights enabled
コメント:
- Container Insightsを有効化することで、ECSタスクレベルでのメトリクスが収集できます。
- ECSサービスの継続性を把握するための実行中タスク数として、RunningTaskCountも提供されるのが大きな特徴です。
- 有効化すると、カスタムメトリクスとログ取り込み料金が必要となるため、開発環境などでは無効のままでも問題ないです。
Amazon EFS
[EFS.3]EFS アクセスポイントは、ルートディレクトリを適用する必要があります
重要度: MEDIUM
AWSドキュメント: [EFS.3] EFS access points should enforce a root directory
コメント:
- ディレクトリアクセス制限を設定していない（アクセスポイントのパスがサブディレクトリではなくルート("/")になっているような）ときに非準拠になります。
- 「指定されたサブディレクトリのファイルのみアクセスさせたい要件」がある場合には対応しましょう。
[EFS.4]EFSアクセスポイントは、ユーザーIDを適用する必要があります
重要度: MEDIUM
AWSドキュメント: [EFS.4] EFS access points should enforce a user identity
コメント:
- 対応するメリットとして、ファイルシステムに対する一貫性のあるアクセス制御を実現でき来ます。
- 対象のEFSで厳密なアクセス管理が必要でなければ必須ではありません。
Amazon EKS
今回、新しく EKS のチェック項目が追加されました。[EKS.1]ではなく、[EKS.2]から始まっています。
[EKS.2]EKSクラスターは、サポートされているKubernetesバージョンで実行する必要があります
重要度: HIGH
AWSドキュメント: [EKS.2] EKS clusters should run on a supported Kubernetes version
コメント:
- サポートされていないKubernetesバージョンは、サポート終了日以降にAWSのタイミングで自動更新が行われます。
- 自動更新のタイミングはユーザーでコントロールできないため、Kubernetesバージョンはサポート終了前に積極的に更新することを推奨します。
Elastic Load Balancing
ALB/CLBのDesync 緩和モードについては以下ブログが参考になります。
[ELB.12]Application Load Balancerは、防御的または最も厳格で構成する必要があります
重要度: MEDIUM
コメント:
- Desync 緩和モードではアプリケーションにセキュリティリスクを与える可能性のあるリクエストを、Application Load Balancerがどのように処理するかを決定します。
- Desync 緩和モードには3つのモードがあり、それぞれのモード設定時の振る舞いは以下です。
- 最も厳格 (Strictest)：RFC 7230に準拠したリクエスト以外をブロックする
- 防御的 (Defensive)[デフォルト値]：「RFC 7230に準拠したリクエストおよびRFC 7230に準拠していないがセキュリティリスクが低いリクエスト」以外をブロックする
- モニタリング (Monitor)：セキュリティリスクが高いリクエストを含めリクエストのブロックを行わない
- 「モニタリング (Monitor)」はセキュリティリスクの高いリクエストを許可する。そのため特別な理由がない限り、この項目は設定しないことをおすすめします。
- 「最も厳格 (Strictest)」は本コントロールに準拠する設定だが、従来のリクエストがブロックされる可能性がある。そのため本番環境への適用時には十分な検証を行ってください。
[ELB.13]Application/Network/Gateway Load Balancer は複数のアベイラビリティーゾーンにまたがる必要があります
重要度: MEDIUM
AWSドキュメント: [ELB.13] Application, Network, and Gateway Load Balancers should span multiple Availability Zones
コメント:
- マルチAZ配置によるコストを考慮して、開発環境などでは無効化しても良いです。
- 高可用性が求められる環境では有効化しましょう。
[ELB.14]Classic Load Balancerは、防御的または最も厳格で構成する必要があります
重要度: MEDIUM
コメント:
- [ELB.12]のClassic Load Balancer版のコントロールです。コメントも同じです。
Amazon Kinesis
[Kinesis.1]Kinesis Data Streams のサーバーサイド暗号化を有効化する必要があります。
重要度: MEDIUM
AWSドキュメント: [Kinesis.1] Kinesis Data Streams should be encrypted at rest
コメント:
- Kinesis Data Streamsで扱うデータの内容次第で暗号化するかを決定してください。
- 暗号化を有効にする際、KMS APIを利用することによるコスト増加やパフォーマンス影響(~100μs)があることも考慮しましょう。
AWS Network Firewall
今回のNetwork Firewallの新規コントロールは、Network Firewall自体への理解がある程度ないと理解できないものでした（私のことです
Nwtwork Firewallについてあまり詳しくない方は、まずこちらの入門ブログをご覧ください。
[NetworkFirewall.3]Network Firewallポリシーには、1つ以上のルールグループが関連付けられている必要があります
重要度: MEDIUM
AWSドキュメント: [NetworkFirewall.3] Network Firewall policies should have at least one rule group associated
コメント:
- Network Firewallポリシーにステートレスグループもしくはステートフルグループを関連付けることを求めます。
- ステートレスグループを関連付けていない場合、Network Firewallはステートレスデフォルトアクション（パス、ドロップ、ステートフルグループに転送）に基づきパケットを評価します。
- ルールグループの関連付けが無い場合、ステートレスデフォルトアクション（パス、ドロップ、ステートレスグループに転送）の動作はそれぞれ以下のようになります。
- パス ... すべてのトラフィックを許可
- ドロップ ... すべてのトラフィックを拒否
- ステートフルグループに転送 ... すべてのトラフィックを許可(ステートフルグループの関連付けが無い状態のデフォルト)
- つまり、このコントロールで非準拠が出た場合、Network Firewallは「すべてのトラフィックを許可(もしくは拒否)」する状態になっています。
- 意図しないトラフィックの許可(もしくは拒否)を防ぐためにも対応することを推奨します。
[NetworkFirewall.4]Network Firewallポリシーのデフォルトのステートレスアクションは、完全なパケットに対してドロップまたは転送される必要があります
重要度: MEDIUM
コメント:
- Network Firewallポリシーのステートレスデフォルトアクションの完全なパケットに対するアクションにおいて、「ドロップ」もしくは「ステートフルグループに転送」に設定することを求めます。
- ステートレスグループに一致しないパケットがストレートレスデフォルトアクションの設定に従って評価されます。
- スレートレスデフォルトアクションを「パス」に設定していると、ステートレスグループに一致しないパケットは許可されます。これが「意図しない許可」である場合、「ドロップ」もしくは「ステートフルグループに転送」に設定してください。
- ただし、ステートレスグループに一致しないパケットを意図的にすべて許可するような構成の場合は「抑制済み」としても問題ないです。
- また、「ステートフルグループに転送」に設定する際は、ステートフルグループが１つも設定されていないと、パケットが意図せず許可される可能性がある点に注意してください。
[NetworkFirewall.5]Network Firewallポリシーのデフォルトのステートレスアクションは、フラグメント化されたパケットに対してドロップまたは転送される必要があります
重要度: MEDIUM
コメント:
- Network Firewallポリシーのステートレスデフォルトアクションにおいて、フラグメント化されたパケットに対するアクションで「ドロップ」もしくは「ステートフルグループに転送」に設定することを求めます。
- 「NetworkFirewall.4」とコメントは同一になります。
Amazon Opensearch Service
[OpenSearch.7]OpenSearchドメインでは、きめ細やかなアクセスコントロールを有効にする必要がある
重要度: HIGH
AWSドキュメント: [OpenSearch.7] OpenSearch domains should have fine-grained access control enabled
コメント:
- きめ細やかなアクセスコントロールを有効にすることで、以下のようなデータへの追加のアクセスコントロールを可能にします。
- ロールベースのアクセスコントロール
- インデックスレベル、ドキュメントレベル、フィールドレベルのセキュリティ
- 以下の理由から既存ドメインの運用への影響が大きく、追加のアクセスコントロールを必要とする要件がない限り、対応する必要はありません。
- きめ細やかなアクセスコントロールを有効にすると、OpenSearchドメインへの認証方式がBasic認証もしくはIAMによる認証に変わる
- きめ細やかなアクセスコントロールを一度有効にした後、再度無効に戻すことができない点に注意
- あわせて、以下を考慮しましょう。これらはきめ細やかなアクセスコントロールの有無に関係なく設定すべきです。
- 意図せずパブリックアクセスを許可していないこと
- リソースベースポリシー、アイデンティティポリシー、IPベースポリシーのいずれかを使用してアクセスコントロールしていること
Amazon Redshift
[Redshift.9]Redshiftクラスターはデフォルトのデータベース名を使うべきではありません
重要度: MEDIUM
AWSドキュメント: [Redshift.9] Redshift clusters should not use the default database name
コメント:
- デフォルトのデータベース名は良く知られている・使われているため、偶発的なアクセスが起きやすくなります。
- Redshiftクラスターのデータベース名は作成後に変更できない点に注意が必要で、変更のコストが見合わない場合はこのコントロールを無効化しても問題ないです。
Amazon S3
[S3.13]S3バケットには、ライフサイクルポリシーを設定する必要があります
重要度: LOW
AWSドキュメント: [S3.13] S3 buckets should have lifecycle policies configured
コメント:
- S3ストレージコストを削減したい場合に、以下の観点で要件を整理してライフサイクルポリシーを設定すべきか判断してください。
- ストレージクラス移行アクション
- オブジェクトのサイズが128KB以上
- オブジェクトのアクセス頻度
- オブジェクトの取り出し時間
- 削除アクション
- ログ等の一定期間の保管のみ必要なオブジェクト
- ストレージクラス移行アクション
Amazon SNS
[SNS.2]トピックに送信された通知メッセージの配信状況のログを有効にする必要があります
重要度: MEDIUM
AWSドキュメント: [SNS.2] Logging of delivery status should be enabled for notification messages sent to a topic
コメント:
- CloudWatch Logsのコストが別途発生するため、通常の用途でSNSを使う場合は必須ではありません。
- エラーハンドリングにおいてログが役に立つ場合があるため、クリティカルな用途でSNSを利用する場合は有効化を推奨します。
- ログの流量が多い場合は、想定よりも配信コストが多くかかる可能性があるため注意です。
AWS WAF
以下のコントロールはすべて、旧バージョンのWAF Classic(WAF V2ではない)が対象である点に注意してください。
WAF ClassicとWAFv2の差についてもっと知りたい方は、こちらのブログが参考になります。
[WAF.2]WAF Regional ルールは、少なくとも1つの条件が必要です。
重要度: MEDIUM
AWSドキュメント: [WAF.2] A WAF Regional rule should have at least one condition
コメント:
- Conditionに何も設定が付与されていないと、リクエストが検査されずに通過する（=WAFとして機能しないため）ためチェックは必須です。
- Conditionが空のルールであっても、ルール1個単位で利用料金がかかるため不要なルールがある場合は削除しましょう。
[WAF.3]WAF Regional ルールグループには、少なくとも1つのルールが必要です。
重要度: MEDIUM
AWSドキュメント: [WAF.3] A WAF Regional rule group should have at least one rule
コメント:
- ルールグループにルールが設定されていないと、リクエストが検査されずに通過する（=WAFとして機能しないため）ためチェックは必須です。
- ルールが設定されていないルールグループであっても、ルールグループ1個単位で利用料金がかかるため不要なルールグループがある場合は削除しましょう。
[WAF.4]WAF Classic Regional web ACLには、少なくとも1つのルールまたはルールグループが必要です。
重要度: MEDIUM
AWSドキュメント: [WAF.4] A WAF Classic Regional web ACL should have at least one rule or rule group
コメント:
- web ACLにルールやルールグループが設定されていないと、リクエストが検査されずに通過する（=WAFとして機能しないため）ためチェックは必須です。
[WAF.6]WAFグローバルルールには、少なくとも1つの条件が必要です。
重要度: MEDIUM
AWSドキュメント: [WAF.6] A WAF global rule should have at least one condition
コメント:
- [WAF.2]のグローバルルール版です。コメントも同じです。
[WAF.7]WAFグローバルルールグループには、少なくとも1つのルールが必要です。
重要度: MEDIUM
AWSドキュメント: [WAF.7] A WAF global rule group should have at least one rule
コメント:
- [WAF.3]のグローバルルール版です。コメントも同じです。
[WAF.8]WAF global web ACLには、少なくとも1つのルールまたはルールグループが必要です。
重要度: MEDIUM
AWSドキュメント: [WAF.8] A WAF global web ACL should have at least one rule or rule group
コメント:
- [WAF.6]のグローバルルール版です。コメントも同じです。
最後に
以上、今回追加されたSecurity Hubの各コントロールについて確認してみました。
HIGH/CRITICAL の項目は、以下となっております。
- HIGH [AutoScaling.3]Auto Scaling グループは、EC2インスタンスが Instance Metadata Service Version 2 (IMDSv2) を必要とするように設定すべき
- HIGH [AutoScaling.4]Auto Scaling グループの起動設定でメタデータ応答のホップリミットを1より大きくすべきではない
- HIGH [EC2.23]EC2 Transit Gateway はVPCアタッチメントのリクエストを自動承諾すべきではない
- HIGH [ECR.1]ECRプライベートリポジトリは、イメージスキャンを設定する必要があります
- HIGH [ECS.3]ECS タスクの定義では、ホストのPID Namespaceを共有しないでください
- HIGH [ECS.4]ECSコンテナは、非特権モードで実行する必要がある
- HIGH [ECS.5]ECSコンテナは、ルートファイルシステムへのアクセスを読み取り専用に制限する必要があります。
- HIGH [ECS.8]シークレットはコンテナ環境変数へ渡すべきではない
- HIGH [EKS.2]EKSクラスターは、サポートされているKubernetesバージョンで実行する必要があります
- HIGH [OpenSearch.7]OpenSearchドメインでは、きめ細やかなアクセスコントロールを有効にする必要がある
CRITICALの新規コントロールはありませんでしたが、HIGHで失敗しているものについては優先度を上げて確認しておきましょう。
ここまで読んでくださりありがとうございました。
少しでもどなたかのお役に立てば幸いです。
以上、AWS事業本部コンサルティング部の芦沢(＠ashi_ssan)でした。
スペシャルサンクス
本エントリで紹介した各コントロールのコメントについては以下メンバーで精査を行いました。みなさんありがとうございました！
参考
- AWS Foundational Security Best Practices controls - AWS Security Hub
- 【アップデート】AWS Security Hub の『基礎セキュリティのベストプラクティス』に新たに25個のチェック項目が追加されました | DevelopersIO
- 7月のアップデートブログでは36個の項目が追加とありますが、その後すぐに[EC2.27]がretiredとなり廃止されたため、実際追加されたのは35個でした。 ↩
![[アップデート]Security Hub のセキュリティ標準に新たに25個のチェック項目が追加されました(2024/12/10)](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e71a738589e583b65670923628e8b6f4/45568b9fd457506bd2f3d6fd304d4b6a/aws-security-hub)
