Security Hubのセキュリティ基準をはじめからていねいに

執筆時点より1年以上が経過し、新規に追加されたコントロールなどは加筆されておらずこの記事の情報は古くなっているためご注意下さい。（2022年3月追記）

この記事では、AWS Security Hubの中で設定できるセキュリティ基準（AWS Configのルールセット）について詳しく紹介しています。
ルールセットの内容の理解を通して、セキュリティのベストプラクティスを実践する方法を学ぶ入門者向けの内容です。

AWS Security Hubとは？

AWS Security HubはAWSのセキュリティ関連サービスの1つで、名前の通り"Hub"として機能することを想定したサービスです。AWS公式ドキュメントには以下のように記述があります。

AWS Security Hub では、AWS のセキュリティ状態を包括的に把握し、セキュリティ業界標準およびベストプラクティスに照らして環境をチェックするのに役立ちます。
Security Hub は、複数の AWS アカウント、サービス、およびサポートされているサードパーティーパートナー製品からセキュリティデータを収集して、セキュリティの傾向を分析し、最も優先度の高いセキュリティの問題を特定するのに役立ちます。

実際にどの様なことをができるかを知りたい場合には、弊社内でセキュリティやDevOpsに詳しいメンバーが執筆した以下のブログが大変お薦めです。（もちろんDevelopersIOのSecurity Hubの記事は他にも多くあります。）

• 【祝リリース】Security HubがGAになったので特徴と使い方まとめてみた
• Security Hub Standardsを利用してAWSのセキュリティチェックを試した
• [入門]社内勉強会で AWS Security Hubの話をしました

Security Hubで設定できるルールセットについて

あえて端的に言えば、Security Hubには「AWS Configのルールを一括して追加する」ことで、ベストプラクティスに沿ったセキュリティ設定が実施されているかを監視し、その情報を一元的に表示する機能があります。
実際にSecurity Hubを有効化する画面では、以下の３つのセキュリティ基準の中から複数個選択することができます。

• AWS 基礎セキュリティのベストプラクティス v1.0.0
• CIS AWS Foundations Benchmark v1.2.0
• PCI DSS v3.2.1

ここで追加されるAWS Configのルールは、厳密にはSLR (Service-Linked Rule)として扱われ、通常のConfigルールとは区別されます。 しかしSecurity Hub有効化後にどのようなルールが追加されたかを確認したい場合は、マネージメントコンソールのAWS Configの画面から、通常のConfigルールと同様に詳細を見ることできます。

Security Hubはセキュリティのベストプラクティスを定義するものであり、すぐにでも有効化したいところですが、利用料金（後述）も発生しますし、「どのような理由でどのようなルールが追加されているのか？」を先に確認しておくことで、修復アクションを取る際の見通しが良くなります。そしてこれらのルールセットは、システム運用者が念頭に置くべき具体的な設定項目の大部分を網羅しているため、このベストプラクティスに沿ったConfigルールセットを把握するという作業自体が、逆説的ではありますがAWSのセキュリティ設定を効率的に学び実践する上で適していると、個人的には思っています。

ここでは、Security Hubのセキュリティ基準のうちPCI DSSを除く、AWS 基礎セキュリティのベストプラクティスと、CIS AWS Fundation Benchmarkを詳しく見ていきます。

AWS 基礎セキュリティのベストプラクティス

文字通り、AWSにおける基本的なセキュリティのベストプラクティスが含まれたセキュリティ基準です。
合計で70個のコントロールがあり、AWSの各サービスのセキュリティ機能を活用した設定が盛り込まれています。 ここでコントロールとはSecurity Hub上の設定項目の単位で、各コントロールに対応する同数のService-Linked Rule（Configルール）が用意されています。不要なコントロールについては、Security Hub上でそれぞれ無効化することができます。
関連するAWSのサービス別に、コントロールをざっくりまとめると以下のとおりです。
修復アクションの詳細については、Security Hubの画面上の説明に加え、先の公式ドキュメントも併せてご参照ください。

IAM

• [IAM.1] IAM policies should not allow full "*" administrative privileges
• [IAM.2] IAM users should not have IAM policies attached
• [IAM.3] IAM users' access keys should be rotated every 90 days or less
• [IAM.4] IAM root user access key should not exist
• [IAM.5] MFA should be enabled for all IAM users that have a console password
• [IAM.6] Hardware MFA should be enabled for the root user
• [IAM.7] Password policies for IAM users should have strong configurations
• [IAM.8] Unused IAM user credentials should be removed

IAMの設定に関するルールが８個あります。いずれもよく知られているものが多いと思いますが、特にMFAの有効化は重要ですね。
なお、IAMユーザーキーのローテーションを一括して行うにはこちらのスクリプトを使う方法が便利です。

EC2

• [EC2.1] Amazon EBS snapshots should not be public, determined by the ability to be restorable by anyone
• [EC2.2] The VPC default security group should not allow inbound and outbound traffic
• [EC2.3] Attached EBS volumes should be encrypted at-rest
• [EC2.4] Stopped EC2 instances should be removed after a specified time period
• [EC2.6] VPC flow logging should be enabled in all VPCs
• [EC2.7] EBS default encryption should be enabled
• [EC2.8] EC2 instances should use IMDSv2
• [AutoScaling.1] Auto Scaling groups associated with a load balancer should use load balancer health checks

VPCやEC2まわりの設定ルールが9個ほど含まれていました。EBSについてはデフォルト暗号化設定と、アタッチされているEBSが暗号化されているかの2重のコントロールが課されています。
ここでIMDSv2とは、Instance Meta Data Service Version 2を意味しています。旧来のVersion 1と比べて複数の脆弱性に対する修正が適用されています。

Lambda

• [Lambda.1] Lambda function policies should prohibit public access
• [Lambda.2] Lambda functions should use latest runtimes

Lambdaのコントールは2種類です。pubulicアクセスの制限と、ランタイムのアップデートに関するコントロールです。

S3

• [S3.1] S3 Block Public Access setting should be enabled
• [S3.2] S3 buckets should prohibit public read access
• [S3.3] S3 buckets should prohibit public write access
• [S3.4] S3 buckets should have server-side encryption enabled
• [S3.5] S3 buckets should require requests to use Secure Socket Layer
• [S3.6] Amazon S3 permissions granted to other AWS accounts in bucket policies should be restricted

S3については、おなじみのpublicアクセスに関連したものが複数含まれています。
S3のアクセスを制御する方法は、IAMポリシー、バケットポリシー、バケットACL、オブジェクトACLなど複数あるため注意が必要です。

RDS

• [RDS.1] RDS snapshots should be private
• [RDS.2] RDS DB instances should prohibit public access, determined by the PubliclyAccessible configuration
• [RDS.3] RDS DB instances should have encryption at rest enabled
• [RDS.4] RDS cluster snapshots and database snapshots should be encrypted at rest
• [RDS.5] RDS DB instances should be configured with multiple Availability Zones
• [RDS.6] Enhanced monitoring should be configured for RDS DB instances and clusters
• [RDS.7] RDS clusters should have deletion protection enabled
• [RDS.8] RDS DB instances should have deletion protection enabled
• [RDS.9] Database logging should be enabled
• [RDS.10] IAM authentication should be configured for RDS instances
• [RDS.11] RDS instances should have automatic backups enabled

RDSに関連したコントロールは11個ありました。
マルチAZの使用や自動バックアップ、削除保護など直接的にセキュリティに関係ないものも含まれていますが、様々なワークロードでベストプラクティスな設定と言えそうです。

DynamoDB

• [DynamoDB.1] DynamoDB tables should automatically scale capacity with demand
• [DynamoDB.2] DynamoDB tables should have point-in-time recovery enabled
• [DynamoDB.3] DynamoDB Accelerator (DAX) clusters should be encrypted at rest

DAXクラスターのストレージ暗号化については私は試したことが無いのですが、ドキュメントによると簡単に設定できそうです。

Redshift

• [Redshift.1] Amazon Redshift clusters should prohibit public access
• [Redshift.2] Connections to Amazon Redshift clusters should be encrypted in transit
• [Redshift.3] Amazon Redshift clusters should have automatic snapshots enabled
• [Redshift.6] Amazon Redshift should have automatic upgrades to major versions enabled

Redshiftに関しては、publicアクセス禁止、通信の暗号化、スナップショットの有効化、自動アップグレードのコントロールがありました。

Elastic Load Balancer

• [ELB.3] Classic Load Balancer listeners should be configured with HTTPS or TLS termination
• [ELB.4] Application load balancers should be configured to drop HTTP headers
• [ELB.5] Application and Classic Load Balancers logging should be enabled
• [ELBv2.1] Application Load Balancer should be configured to redirect all HTTP requests to HTTPS

[ELB.4] は無効なHTTPヘッダーをドロップする設定がされているかを確認するコントロールです。
また4つ目 [ELBv2.1] の設定はリダイレクトを選択していなければ無効にしても良いかもしれません。
話の本筋ではありませんが、AWSのドキュメント中で「ELBv2」の表記は、ALBを指し（多くの場合でCLB/NLBを除外し）ています。

CloudFront

• [CloudFront.1] CloudFront distributions should have a default root object configured
• [CloudFront.2] CloudFront distributions should have origin access identity enabled
• [CloudFront.3] CloudFront distributions should require encryption in transit
• [CloudFront.4] CloudFront distributions should have origin failover configured

2つ目 [CloudFront.2] のオリジンアクセスアイデンティティについては、CloudFrontを使う上で推奨されることの多い機能かと思われますので、是非検討ください。詳しくはこちらのブログ記事の中でわかりやすく解説されています。

KMS

• [KMS.1] IAM customer managed policies should not allow decryption actions on all KMS keys
• [KMS.2] IAM principals should not have IAM inline policies that allow decryption actions on all KMS keys
• [EFS.1] Amazon EFS should be configured to encrypt file data at rest using AWS KMS
• [SNS.1] SNS topics should be encrypted at rest using AWS KMS

KMSに関連したものは4つありました。
[KMS.1] はカスタマーポリシーの中で、すべてのKMSキーに対する復号化アクションが許可されていないかを確認するものです。権限や対象とするリソースは最小限に絞る必要があります。

Systems Manager

• [SSM.1] EC2 instances should be managed by AWS Systems Manager
• [SSM.2] All EC2 instances managed by Systems Manager should be compliant with patching requirements
• [SSM.3] Instances managed by Systems Manager should have an association compliance status of COMPLIANT

Systems ManagerによってEC2が管理されているかを問うコントロールです。
最近では、Systems Managerのセットアップを支援する新機能が追加されたそうですので、是非活用したいです。

Secrets Manager

• [SecretsManager.1] Secrets Manager secrets should have automatic rotation enabled
• [SecretsManager.2] Secrets Manager secrets configured with automatic rotation should rotate successfully

Secrets Managerの特徴的な機能として、パスワード等秘密情報の自動ローテーション機能があります。 この機能が有効化され、正常にローテートが行われているかを確認できるコントロールです。

CloudTrail

• [CloudTrail.1] CloudTrail should be enabled and configured with at least one multi-Region trail
• [CloudTrail.2] CloudTrail should have encryption at-rest enabled

CloudTrailが有効化され、暗号化されているかを確認するコントロールです。

CodeBuild

• [CodeBuild.1] CodeBuild GitHub or Bitbucket source repository URLs should use OAuth
• [CodeBuild.2] CodeBuild project environment variables should not contain clear text credentials

[CodeBuild.2] のコントロールではCodeBuildのプロジェクトの中に、下記の2つの環境変数（AWSの認証情報）が含まれていないかを確認できます。

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

コード中の認証情報を誤ってpushしないようにする仕組みとしてはgit-secretsもありますので、このコントロールを有効化する場合は併せて検討ください。

その他のサービス

• [Config.1] AWS Config should be enabled
• [GuardDuty.1] GuardDuty should be enabled
• [ACM.1] Imported ACM certificates should be renewed after a specified time period
• [EMR.1] Amazon EMR cluster master nodes should not have public IP addresses
• [ES.1] Elasticsearch domains should have encryption at-rest enabled
• [SageMaker.1] SageMaker notebook instances should not have direct internet access
• [DMS.1] Database Migration Service replication instances should not be public

ConfigはSecurity Hubを使う以上、当然有効にする必要があります。加えてGurdDutyも有効化が求められています。
EMRやElasticsearch、SageMakerなど、サービスを利用していなければこれらのコントロールは無効化しておきましょう。利用していなかったとしてもいつか使用する可能性もありますので、このままにしておきましょう。（ステータス：「成功」と記録されます）

CIS AWS Fundation Benchmark v1.2.0

CIS Benchmarkは、非営利団体CIS(Center for Internet Security)により公開されているセキュリティ基準です。 AWSでのCISの利用に関してはDevelopersIOの以下の記事に詳しい解説があり、実際に検討されている方は是非一度ご覧ください。

• あなたのAWSセキュリティ監査状況を採点〜CISベンチマークを読んでみた

こちらは合計で43個のConfigルールが設定されます。 ※分類分けの名称は便宜的に付けた非公式のものです。

アカウント管理および権限管理設定

• 1.1 – Avoid the use of the "root" account
• 1.2 – Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password
• 1.3 – Ensure credentials unused for 90 days or greater are disabled
• 1.4 – Ensure access keys are rotated every 90 days or less
• 1.5 – Ensure IAM password policy requires at least one uppercase letter
• 1.6 – Ensure IAM password policy requires at least one lowercase letter
• 1.7 – Ensure IAM password policy requires at least one symbol
• 1.8 – Ensure IAM password policy requires at least one number
• 1.9 – Ensure IAM password policy requires a minimum length of 14 or greater
• 1.10 – Ensure IAM password policy prevents password reuse
• 1.11 – Ensure IAM password policy expires passwords within 90 days or less
• 1.12 – Ensure no root account access key exists
• 1.13 – Ensure MFA is enabled for the "root" account
• 1.14 – Ensure hardware MFA is enabled for the "root" account
• 1.16 – Ensure IAM policies are attached only to groups or roles
• 1.20 - Ensure a support role has been created to manage incidents with AWS Support
• 1.22 – Ensure IAM policies that allow full ":" administrative privileges are not created

IAMについてはAWS 基礎セキュリティのベストプラクティスと重複しているものもありますが、加えてパスワードポリシーなどがCISに準拠しているかを簡単に確認できるようです。具体的なパスワード要件としては、大文字・小文字・記号・数字を含む14文字以上となっています。

証跡の設定

• 2.1 – Ensure CloudTrail is enabled in all Regions
• 2.2 – Ensure CloudTrail log file validation is enabled
• 2.3 – Ensure the S3 bucket CloudTrail logs to is not publicly accessible
• 2.4 – Ensure CloudTrail trails are integrated with Amazon CloudWatch Logs
• 2.5 – Ensure AWS Config is enabled
• 2.6 – Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket
• 2.7 – Ensure CloudTrail logs are encrypted at rest using AWS KMS CMKs
• 2.8 – Ensure rotation for customer-created CMKs is enabled
• 2.9 – Ensure VPC flow logging is enabled in all VPCs

CloudTrailを使った証跡の管理に関するコントロールです。
先程のIAM同様にAWS 基礎セキュリティのベストプラクティスとの重複は多いですが、注目すべき差分は[2.1]の全てのリージョンでの有効化ではないかと思われます。

ログメトリクスの設定

• 3.1 – Ensure a log metric filter and alarm exist for unauthorized API calls
• 3.2 – Ensure a log metric filter and alarm exist for AWS Management Console sign-in without MFA
• 3.3 – Ensure a log metric filter and alarm exist for usage of "root" account
• 3.4 – Ensure a log metric filter and alarm exist for IAM policy changes
• 3.5 – Ensure a log metric filter and alarm exist for CloudTrail configuration changes
• 3.6 – Ensure a log metric filter and alarm exist for AWS Management Console authentication failures
• 3.7 – Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer created CMKs
• 3.8 – Ensure a log metric filter and alarm exist for S3 bucket policy changes
• 3.9 – Ensure a log metric filter and alarm exist for AWS Config configuration changes
• 3.10 – Ensure a log metric filter and alarm exist for security group changes
• 3.11 – Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL)
• 3.12 – Ensure a log metric filter and alarm exist for changes to network gateways
• 3.13 – Ensure a log metric filter and alarm exist for route table changes
• 3.14 – Ensure a log metric filter and alarm exist for VPC changes

全てメトリクスフィルターとアラームが存在するかを確認するコントロールです。
ルートアカウントやMFAに関連したメトリクスは重要ですのでこれらのコントロールはどんなワークロードでも有効化したいです。
一方で、セキュリティグループやルートテーブルの変更検知はシステムの運用フェーズでは便利ですが、構築の段階では利用費を抑制する観点から一時的に外しておいても良さそうです。

セキュリティグループの設定

• 4.1 – Ensure no security groups allow ingress from 0.0.0.0/0 to port 22
• 4.2 – Ensure no security groups allow ingress from 0.0.0.0/0 to port 3389
• 4.3 – Ensure the default security group of every VPC restricts all traffic

インバウンドのトラフィックのうち、任意のIPアドレスから22番ポートまたは3389番ポートへのアクセスが許可されていないか調べることが出来ます。
またデフォルトセキュリティグループの扱いについてのコントロールもあります。

Security Hub利用費に関するご注意点

ここまで読まれて勘の良い方はお気づきかもしれませんが、Security Hubが提供しているのは一元的な表示とルールセットであり、実態としてはAWS Configが動作しその費用が（Security Hubの利用費とは別に）AWS Configの利用費として発生します。
そのため、AWS Configの単価自体は他のサービスと比べて廉価ですが、CloudFormationやTerraformなどを経由して一度に複数のリソースを扱う場合には慎重になる必要があります。
さらに、AWSサービスの意図しない動作や内部でのループが発生している場合に、Configによる意図しない動作の検知が累積して利用費が高騰してしまうことがあります。 例えば、Fargateサービスが設定不備のあるタスクを無限に再起動させてしまい、その起動/停止の度にセキュリティグループの付け外しが発生し、セキュリティグループに関連するルールに則ってそれをConfigが検知することで、利用費が増加してしまうケースが考えられます。ご注意ください。

おわりに

実際に113個のコントロールを自分で一つひとつ確認することで、非常に勉強になりました。
どなたかに届け幸いです。