[新機能]Security HubがAWS基礎セキュリティのベストプラクティスについてコンプライアンスチェックできるようになったので詳細を解説しつつチューニングの考察してみた

Security Hubで新しく追加されたコンプライアンスチェックであるAWS Foundational Security Best Practices v1.0.0について解説し、チューニング方法も紹介しています！

#セキュリティ

#AWS Config

#AWS Security Hub

#AWS

臼田佳祐

2020.04.23

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

こんにちは、臼田です。

みなさん、自分たちのAWS環境のセキュリティチェックしていますか？(挨拶

今回はSecurity Hubの新しいセキュリティ基準(Standard)として追加されたAWS Foundational Security Best Practices v1.0.0について解説し、チューニング方法を考えていきます。

新機能の説明

新機能自体を説明する前に背景から行きます。

Security Hubはインシデントやコンプライアンスの情報を一元的に管理するサービスです。大きく2つ機能があり、GuardDutyやInspectorなどのインシデントの情報をまとめたり、CISベンチマーク等のコンプライアンスチェックを行うことができます。

コンプライアンスチェックの機能はこれまで2つの標準(Standard)に対応しており、初期から対応しているAWS CIS Foundations Benchmark v1.2.0と2020年2月に対応したPCI DSS v3.2.1がありました。

これらは自身のAWS環境をセキュアに保つために守るべき設定などを自動的にチェックしてくれる素晴らしい機能で、どちらも重複したチェック項目もありますが、CISはベーシックなセキュリティを見てくれて、PCI DSSはLambdaやCode Buildなどにも踏み込んで強めに見てくれる印象でした。

それぞれのチェック項目とそのチューニング方法については下記をご参照ください。

そして今回、AWS Foundational Security Best Practices v1.0.0に対応したコンプライアンスチェックができるようになりました。

AWS Security Hub launches the Foundational Security Best Practices standard

このチェック項目自体は新しいものですが、ベースとなる考え方としてはTop 10 security items to improve in your AWS accountが使われており、AWSセキュリティの専門家によって定義されたセキュリティのベストプラクティスとされています。

また、各チェック項目はNISTサイバーセキュリティフレームワークのIdentify / Protect / Detect / Recoverのいずれかに該当します。

では実際にどんな項目があるのか見ていきましょう。

AWS Foundational Security Best Practices v1.0.0のチェック項目

一覧はこちらのドキュメントに記載があります。現状31個の項目があります。各項目について、そのままで分かりづらい項目は補足しつつ見ていきましょう。

[ACM.1]インポートされたACM証明書は、有効期限から90日以内に更新する必要があります
- 証明書の期限が切れそうな場合に通知してくれます
[CloudTrail.1] CloudTrailを有効にして、少なくとも1つのマルチリージョン証跡で構成する必要があります
- CloudTrailは1つの設定ですべてのリージョンのログを取得することができるため、それを利用することが推奨されます
[CloudTrail.2] CloudTrailは保存時の暗号化を有効にする必要があります
[CodeBuild.1] CodeBuild GitHubまたはBitbucketソースリポジトリのURLはOAuthを使用する必要があります
- GitHubまたはBitbucketソースリポジトリのURLに個人用アクセストークンまたはユーザー名とパスワードが含まれていると意図しない漏洩に繋がります
[CodeBuild.2] CodeBuildプロジェクト環境変数にクリアテキストの資格情報を含めることはできません
- 意図しない漏洩につながるためです
[Config.1] AWS Configを有効にする必要があります
- 証跡管理のため必須の設定です
[EC2.1] Amazon EBSのスナップショットは公開しないでください。誰でも復元できるかどうかで決まります
[EC2.2] VPCのデフォルトのセキュリティグループは、インバウンドおよびアウトバウンドのトラフィックを許可するべきではありません
- 誤ってデフォルトのセキュリティグループが利用され意図しないアクセス経路が生まれるため、デフォルトのルールを削除すべきです
[EC2.3]接続されたEBSボリュームは保存時に暗号化する必要がある
[EFS.1] AWS KMSを使用して保存ファイルのデータを暗号化するようにAmazon EFSを構成する必要があります
[ELBv2.1]すべてのHTTPリクエストをHTTPSにリダイレクトするようにApplication Load Balancerを構成する必要があります
[ES.1] Elasticsearchドメインでは保存時の暗号化を有効にする必要があります
[GuardDuty.1] GuardDutyを有効にする必要があります
- すべてのAWS環境で必須の項目です
[IAM.1] IAMポリシーでは、完全な「*」管理権限を許可しないでください
- AdministratorAccessに準じる権限を持っているIAMポリシーは作成すべきではありません
- チェックはユーザーが作成したポリシーに対して行われます
[IAM.2] IAMユーザーにはIAMポリシーをアタッチしないでください
- IAMベストプラクティスとしてはグループまたはロールに割り当てることが推奨されています
[IAM.3] IAMユーザーのアクセスキーは90日以下ごとにローテーションする必要があります
[IAM.4] IAM rootユーザーアクセスキーは存在しないはずです
- rootのアクセスキーは利用すべきではありません
- 代わりにIAMユーザーを利用しましょう
[IAM.5]コンソールパスワードを持つすべてのIAMユーザーに対してMFAを有効にする必要があります
- MFAは必須項目です
[IAM.6] rootユーザーに対してハードウェアMFAを有効にする必要があります
[IAM.7] IAMユーザーのパスワードポリシーには強力な構成が必要です
[Lambda.1] Lambda関数は他のアカウントによるパブリックアクセスを禁止する必要がある
- Lambdaをパブリックに公開する設定がありますが、使うべきではありません
[Lambda.2] Lambda関数は最新のランタイムを使用する必要がある
- サポートされなくなった言語のランタイムが利用されている場合に検知されます
[RDS.1] RDSスナップショットはプライベートである必要があります
- スナップショットが公開されるとデータの漏洩に繋がります
[RDS.2] RDS DBインスタンスは、PubliclyAccessible構成によって決定されるパブリックアクセスを禁止する必要があります
- 基本的に公開する必要のないRDSはパブリックアクセスを禁止すべきです
[RDS.3] RDS DBインスタンスでは、保存時の暗号化を有効にする必要があります
[S3.1] S3 Block Public Access設定を有効にする必要があります
- S3のコンテンツを不意に公開しないためにS3 Block Public Accessを利用すべきです
[S3.2] S3バケットはパブリック読み取りアクセスを禁止する必要があります
[S3.3] S3バケットは公開書き込みアクセスを禁止する必要があります
[S3.4] S3バケットではサーバー側の暗号化を有効にする必要があります
[SSM.1] EC2インスタンスはAWS Systems Managerで管理する必要があります
- EC2インスタンスのインベントリの管理や脆弱性の管理が可能です
[SSM.2] Systems Managerによって管理されるすべてのEC2インスタンスは、パッチ要件に準拠している必要があります
- SSMパッチマネージャを利用することでパッチの適用状況を管理できます

一通り眺めてみていかがでしょうか？

かなり幅広いサービスに対してベストプラクティスとしてのチェックがかかるので、新しいスタンダードとして活用するのもありだと思います。

有効化してみた

Security Hubの画面にアクセスしてみると、ポップアップで有効化ボタンが現れたのでこちらから有効化してみました。

通常だと、Security Hub自体を有効化する時に一緒にチェックを入れて有効化するか、左カラムのセキュリティ基準からアクセスして有効化となると思います。

有効化してしばらくはスコアがかなり低く、詳細画面を確認するとわかりますがまだ各項目のチェックが行われていません。気長に1日くらい待ってからスコアを見るといいでしょう。

チューニング方法考えてみた

幅広くいろんな項目を見てくれますが、同時に少し強めのチェック項目かも？と感じるものもあるため、一般的な環境を想定した時に無効化したほうが良さそうな項目をいくつかピックアップして紹介します。

無効化していいかなーというやつ

[IAM.3] IAMユーザーのアクセスキーは90日以下ごとにローテーションする必要があります
- まず、基本的にはIAMユーザーを利用しなくていいところはしない前提です
- 代わりにIAMロールを利用します
- その上でアクセスキーが必要な箇所は、ローカルPCやSaaSでの利用などとなり、そこを90日毎に更新することはあまり現実的では無くなってきます
[SSM.1] EC2インスタンスはAWS Systems Managerで管理する必要があります
- SSMでのEC2の管理は、できると便利な反面EC2に対してのアクセスの設定を行うことができるなど、OSに対する権限が増えることになるので必ず有効にしなくてもいいです
- 使わない場合には無効化しましょう
- 逆に使う場合は漏れがなくなるので便利です

まあまあ、無効化でいいかもというやつ

こちらはもう少しやってもいいですが、やらなくてもいいかもという項目です。

暗号化系
- 対象
  - [CloudTrail.2] CloudTrailは保存時の暗号化を有効にする必要があります
  - [EC2.3]接続されたEBSボリュームは保存時に暗号化する必要がある
  - [EFS.1] AWS KMSを使用して保存ファイルのデータを暗号化するようにAmazon EFSを構成する必要があります
  - [ES.1] Elasticsearchドメインでは保存時の暗号化を有効にする必要があります
  - [RDS.3] RDS DBインスタンスでは、保存時の暗号化を有効にする必要があります
  - [S3.4] S3バケットではサーバー側の暗号化を有効にする必要があります
- これらはKMSを利用してストレージの暗号化を透過的に実施できます
- 物理的なアクセスに対する耐性のため、どこまでAWSの体制を信頼するかという検討をする必要があります
- 設定自体はそこまで難しくないので利用する方向でもいいでしょう
[ELBv2.1]すべてのHTTPリクエストをHTTPSにリダイレクトするようにApplication Load Balancerを構成する必要があります
- ケースバイケースですが、HTTPでのアクセスをHTTPSにするほうが昨今は好ましいです
- 特段HTTPを受ける理由があるのであれば無効化でいいでしょう
[S3.3] S3バケットは公開書き込みアクセスを禁止する必要があります
- S3バケットを公開したい場合でも、CloudFrontを挟んで公開する方がセキュアであるため、パブリックのアクセスは禁止でもいいかもしれません
- ただ適切に認められたコンテンツで権限設定されていれば問題ないため、場合によっては無効化しましょう