AWS Security Hub の『基礎セキュリティのベストプラクティス』に30個のチェック項目が追加されました(2022年2〜4月分)

杉金晋

2022.05.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさんこんにちは、杉金です。

AWS Security Hub の『AWS 基礎セキュリティのベストプラクティス』ですが、2022年2月〜4月の間に30個のチェック項目(コントロール)が追加されました。どのような項目が追加されたのかの紹介と対応について個人的な所感をコメントしていきます。

AWS公式アナウンス

2022年2月追加分

2022年3月追加分

2022年4月追加分

過去のアップデート紹介記事

過去のアップデート紹介記事は以下です。

Amazon EC2 Auto Scaling

[AutoScaling.2] EC2 AutoScalingグループは複数のアベイラビリティーゾーンにまたがって配置される必要があります

AWSドキュメント
重要度 : Medium
(コメント) マルチAZ配置によるコストを考慮して、開発環境等ではコントロールを無効化しても良い。高可用性が求められる環境では有効化。

[Autoscaling.5] Auto Scalingグループに関連付けられた起動設定はパブリックIPを割り当てる設定であってはならない

AWSドキュメント
重要度 : High
(コメント) インターネットからの意図しないアクセスを防ぐために有効化にすべき。対応としては、ロードバランサーをEC2の前段に配置してEC2をインターネットに直接公開させない。EC2からインターネットへのアウトバウンド通信が必要となる場合は、NATゲートウェイやVPCエンドポイントの利用によりパブリックIP付与を避ける。システム構成上、パブリックIPが必要となる場合は対象リソースのみ抑制済みにして例外として登録する。

Amazon CloudFront

[CloudFront.7] CloudFrontはカスタムSSL/TLS証明書を使用する必要があります

AWSドキュメント
重要度 : Medium
(コメント) カスタムSSL/TLS証明書を指定することでユーザー指定のドメイン名を設定することが可能。一方で検証環境等でデフォルトのドメインをそのまま使用するケースも存在するため、対応必須ではない。

[CloudFront.8] CloudFrontのディストリビューションでは、SNIを使用する設定にする必要があります

AWSドキュメント
重要度 : Low
(コメント) CloudFrontでHTTPSを使う際の選択肢として「SNI独自SSL」と「専用IP独自SSL」が存在する。レガシーなクライアントに対応が必要な場合はオプションで「専用IP独自SSL」を使用することが可能だが、月額600USDの追加料金が発生する。主要ブラウザは「SNI独自SSL」に対応しているため、一般的な用途ではこちらを選択する。一方でレガシーなクライアントへの対応のために「専用IP独自SSL」を使用することも考えられるため、対応必須ではない。

参考情報

[CloudFront.9] CloudFront ディストリビューションはカスタムオリジンへのトラフィックを暗号化します

AWSドキュメント
重要度 : Medium
（コメント）CloudFrontディストリビューションとカスタムオリジン間の通信を暗号化しているかどうかをチェックする。ネットワークトラフィックの盗聴や改ざんを防ぐために有効化にすべき。オリジンがS3ウェブサイトエンドポイントの場合はHTTP接続のみでHTTPS接続をサポートしていないため、構成次第では例外として登録する。

参考情報

AWS CodeBuild

[CodeBuild.4] CodeBuildプロジェクトはロギングを有効化する必要があります

AWSドキュメント
重要度 : Medium
(コメント) トラブルシューティングに使用できるため、有効化にすべき。リアルタイムな分析やログ内容からアラームを設定する場合はCloudWatch Logsへ出力する。長期的な保存要件がある場合や長期的な範囲で分析する場合、CloudWatch Logsの料金を気にする場合等ではS3へ出力することも可能。

[CodeBuild.5] CodeBuildプロジェクトは特権モードで実行するべきではありません

AWSドキュメント
重要度 : High
(コメント) CodeBuildで使用するコンテナが悪用された場合にホストコンピュータへのアクセス権限を持つことになるため、攻撃者が攻撃可能な範囲が極めて広範囲になる。（特権モードではビルドプロジェクトのDockerコンテナにすべてのデバイスへのアクセスが許可される）コントロールは有効化にすべき。

Amazon EC2

[EC2.20] AWSサイト間VPN接続の両方のVPNトンネルが稼働している必要があります

AWSドキュメント
重要度 : Medium
(コメント) コントロールは有効化にすべき。2つのVPNトンネルのうち1本がダウンしている場合は冗長性が確保できないためリンクアップの対応が必要。使用していないVPN接続を放置している場合はVPN設定の削除を行う。

参考情報

[AWS Black Belt Online Seminar]オンプレミスとAWS間の冗長化接続

[EC2.21] ネットワークACLは 0.0.0.0/0 からの ポート22または3389のインバウンド許可ルールを追加してはいけない

AWSドキュメント
重要度 : Medium
(コメント) ネットワークACLではアクセス制限をかけずに、セキュリティグループによるアクセス制御を行うケースもある。「[EC2.19] セキュリティグループは、リスクの高いポートへの無制限のアクセスを許可してはならない」の対応を行う前提でコントロールを無効化としてもよい。

参考情報

[EC2.22] 使用していないセキュリティグループは削除する必要があります

AWSドキュメント
重要度 : Medium
(コメント) 使用していないセキュリティグループを定期的に棚卸しすることで、意図しないセキュリティグループをリソースにアタッチする可能性を下げることができる。運用上の理由で定期的にアタッチとデタッチを繰り返すようなセキュリティグループが発生する可能性もあり、対応必須ではない。

Elastic Load Balancing

[ELB.9] Classic Load Balancers はクロスゾーン負荷分散を有効にする必要がある

AWSドキュメント
重要度 : Medium
(コメント)クロスゾーン負荷分散を無効にしているとAutoScalingグループのインスタンス間で負荷の偏りが発生する。意図しないスケーイン/アウトの発生原因となるため、クロスゾーン負荷分散を有効にする。

[ELB.10] Classic Load Balancer は、複数のAvailability Zoneで動作させる必要があります

AWSドキュメント
重要度 : Medium
(コメント)マルチAZ配置によるコストを考慮して、開発環境などでは無効化しても良い。高可用性が求められる環境では有効化。

AWS Lambda

[Lambda.5] VPC Lambda 関数は、複数のAvailability Zoneで動作させる必要があります

AWSドキュメント
重要度 : Medium
(コメント)開発環境などではチェックを無効化しても良い。高可用性が求められる環境では有効化。

AWS Network Firewall

[NetworkFirewall.6] ステートレス Network Firewall ルールグループは空であってはならない

AWSドキュメント
重要度 : Medium
(コメント)ステートレス Network Firewall ルールグループが空の場合、トラフィックは処理されない。ルールグループが空であってもセキュリティホールとならないため対応必須ではない。

Amazon OpenSearch Service

OpenSearch.1〜6、8がコントロール追加として発表されましたが、こちらはAmazon Elasticsearch Serviceのリプレースですので本記事での紹介を割愛します。

Amazon RDS

[RDS.11] RDSインスタンスの自動バックアップは有効にする必要があります

AWSドキュメント
重要度 : Medium
(コメント)対障害性を考慮して自動バックアップを有効にする。保管期間は35日まで指定可能。

参考情報

[RDS.24] RDS DBクラスターでは、カスタムの管理者ユーザー名を使用する必要があります

AWSドキュメント
重要度 : Medium
(コメント)攻撃者はデフォルトのユーザー名でログインを試行する可能性が高い。パブリックなDBを作成している場合は、ユーザー名変更の対応をすべき。(そもそもパブリックDB作成を避ける)プライベートなDBの場合は、アクセス元となるプライベート環境(VPC, オンプレミス)の信頼性が対応の判断基準となる。攻撃のリスクが低い場合は抑制済みとしてよい。

[RDS.25] RDS DBインスタンスでは、カスタムの管理者ユーザー名を使用する必要があります

AWSドキュメント
重要度 : Medium
(コメント)攻撃者はデフォルトのユーザー名でログインを試行する可能性が高い。パブリックなDBを作成している場合は、ユーザー名変更の対応をすべき。(そもそもパブリックDB作成を避ける)プライベートなDBの場合は、アクセス元となるプライベート環境(VPC, オンプレミス)の信頼性が対応の判断基準となる。攻撃のリスクが低い場合は抑制済みとしてよい。

Amazon Redshift

[Redshift.8] Amazon Redshiftクラスターでは、デフォルトのAdminユーザ名を使用しないでください

AWSドキュメント
重要度 : Medium
(コメント)攻撃者はデフォルトのユーザー名でログインを試行する可能性が高い。パブリックなDBを作成している場合は、ユーザー名変更の対応をすべき。(そもそもパブリックDB作成を避ける)プライベートなDBの場合は、アクセス元となるプライベート環境(VPC, オンプレミス)の信頼性が対応の判断基準となる。攻撃のリスクが低い場合は抑制済みとしてよい。

Amazon S3

[S3.9] S3のサーバーアクセスログは有効化する必要があります

AWSドキュメント
重要度 : Medium
(コメント)S3オブジェクトに対する操作を記録する機能として、S3サーバーアクセスログとCloudTrail S3オブジェクトレベルログが存在する。S3サーバーアクセスログの方がCloudTrail S3オブジェクトレベルログより安価であり、不特定多数からのアクセスが予想されるバケット(例: 静的ウェブサイトホスティング設定のバケット)では、トラフィックの分析や問題のトラブルシューティングのために最初に有効化を検討するべきである。一方でCloudTrail S3オブジェクトレベルログの方がより詳細な情報を取得できるため、本番環境で機密性の高い情報を保存している場合等ではCloudTrail S3オブジェクトレベルログを使用することが推奨される。S3バケットを不特定多数に公開していなかったり、CloudTrail S3オブジェクトレベルログを使用しているケースを考慮すると、対応必須ではない。

参考情報

[S3.10] バージョニングが有効なS3バケットには、ライフサイクルポリシーが設定されている必要があります

AWSドキュメント
重要度 : Medium
(コメント)ライフサイクルポリシーを設定しない場合、旧バージョンのオブジェクトがS3バケットに溜まり続けて手動削除が必要となる。ライフサイクルポリシーによるオブジェクト自動削除やストレージクラス変更によりコスト最適化を図る。

参考情報

[S3.11] S3 バケットではイベント通知が有効化されます

AWSドキュメント
重要度 : Medium
（コメント）イベント通知を有効にして、不正なデータアクセスに繋がるイベントを関連チームに警告できる。イベント通知はEventBridge経由でも実行できる。

参考情報

[S3.12] S3 アクセスコントロールリスト (ACL) はバケットに対するユーザーアクセスを管理するために使用されません

AWSドキュメント
重要度 : Medium
（コメント）S3 ACLはオブジェクト単位にも設定できるため、意図しないパブリックオブジェクトができやすい。また、バケットポリシーに比べてきめ細やかなアクセス制御ができない。ACLの代わりにIAMポリシーやS3バケットポリシーによるアクセス制御を行う。

参考情報

Amazon ECR

[ECR.3] ECR リポジトリに少なくとも1つのライフサイクルポリシーが設定されます

AWSドキュメント
重要度: Medium
(コメント)Amazon ECR リポジトリに少なくとも1つのライフサイクル ポリシーが構成されているかどうかをチェックする。ライフサイクルポリシーの設定によりリポジトリ容量の節約ができる。また、意図しない古いコンテナイメージの利用を防ぐことができるため、有効化すべき。

参考情報

統合パートナー追加

Security Hubはサードパーティ製品と統合ができ、以下の3パートナーとの統合も発表されました。

Sonrai Dig

Fugue

Data Theorem

統合パートナーとの連携はSecurity Hubの「統合」から行えます。

おわりに

対応必須かをコメントに記載しておりますが、システムの構成や要件、サービスの仕様変更等によって判断基準は変わります。コメントはあくまで参考程度に留めていただければと思います。追加された30のコントロールのうち、重要度Highは2つでした。(Autoscaling.5, CodeBuild.5) 記事執筆時点では追加されたコントロールはSecurity Hubの自動修復ツールに対応していないため、ツールもいずれアップデートしてくれることを望みます。もしくは追加されたコントロールの自動修復機能をいっそ自分で作るのもありかもしれないなと密かな野望を抱いています。

参考情報

AWS

関連記事

AWS Security Hubの特定のコントロールで、対象のリソースと更新時間が同一のチェック内容が複数表示されるはなぜですか？

平井裕二

2024.05.31

【登壇資料】組織的なクラウド統制のはじめの一歩 後編

たかやま

2024.05.29

[小ネタ]定期実行されるAWS Security Hub コントロールのチェック周期を確認してみた

べこみん

2024.05.28

【アップデート】AWS Security Hub のセキュリティ標準に新たに15個のチェック項目が追加されていました(2024/5/3)

おつまみ

2024.05.28