この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。
Security Hub に新しいセキュリティ標準が追加されました。
引用します。(機械翻訳)
AWSアカウントとデプロイされたリソースがAWSセキュリティの専門家によって定義されたセキュリティのベストプラクティスと一致しない場合を検出します。この厳選された一連のコントロールは、AWSにおけるお客様のセキュリティ体制の向上に役立ち、AWSの最も人気のある基本的なサービスをカバーします。AWSセキュリティのベストプラクティスからの逸脱が特定されると、AWS Security Hubは詳細で実用的な調査結果をお客様に発行します。
Security Hub で3つの基準を用いて自身の AWS 環境を評価可能になりました。
| 基準 | マネジメントコンソール上の説明 |
|---|---|
| CIS AWS Foundations Benchmark v1.2.0 | Center for Internet Security (CIS) AWS Foundations Benchmark v1.2.0 は、AWS のセキュリティ設定のベストプラクティスのセットです。この Security Hub 標準では、CIS 要件のサブセットに対するコンプライアンスの準備状況が自動的にチェックされます。 |
| PCI DSS v3.2.1 | Payment Card Industry Data Security Standard (PCI DSS) v3.2.1 は、カード所有者データを保存、処理、転送するエンティティ向けの情報セキュリティ標準です。この Security Hub 標準では、PCI DSS 要件のサブセットに対するコンプライアンスの準備状況が自動的にチェックされます。 |
| new AWS 基礎セキュリティのベストプラクティス v1.0.0 | AWS 基礎セキュリティのベストプラクティス標準は、AWS アカウントとデプロイされたリソースがセキュリティのベストプラクティスと一致しないことを検出する自動化されたセキュリティチェックのセットです。この標準は AWS セキュリティの専門家によって定義されたものです。この厳選された一連の統制は、AWS におけるセキュリティ体制の改善に役立ち、AWS で最も人気の高い基礎的なサービスを網羅しています。 |
AWS 基礎セキュリティのベストプラクティス v1.0.0 活用方法
AWS 基礎セキュリティのベストプラクティス v1.0.0 はどのように活用したらいいでしょうか。
弊社にもよくご相談を頂く、以下のようなケースで活用できると考えます。
- アプリケーションをAWSで稼働させたが、セキュリティに不安がある
- 手探りでAWS環境を構築した。専門家の観点からセキュリティチェックをして欲しい
- 社内規定で定期的なセキュリティチェックを求められている。何か材料はないか？
定期的なチェック
Security Hubを有効にしておいて、ワンショット、または、定期的なセキュリティチェックを行います。 チェック自体は、AWSが自動的にアカウント内を巡回してチェックを行なってくれます。管理者側は結果を確認するだけです。
以下の例のように成功、失敗、不明が判りやすく表示されます。
修復手順
チェックで検出された際の修復手順が案内されることも非常に便利なサービスです。
修復手順は以下にまとまっています。 AWS Foundational Security Best Practices controls
項目の無効
セキュリティチェックは全ての項目に合格する必要がありません。 自社システムのポリシーに従ってください。チェックをパスしたい項目は無効にします。
AWS 基礎セキュリティのベストプラクティス v1.0.0 有効化
それでは有効にしてみましょう。
マネジメントコンソールから Security Hub を開きます。
Security Hub に移動 をクリックします。
Security Hub を初めて開く場合は以下の画面が表示されると思います。
チェックボックスをチェックして Security Hub の有効化 をクリックします。
以下のようなポップアップが表示された場合は、標準を有効化 をクリックします。
セキュリティ基準 で 有効化 をクリックしても同じ結果になります。
AWS 基礎セキュリティのベストプラクティス v1.0.0 評価項目
ACM.1 インポートされた ACM 証明書は、有効期限から 90 日以内に更新する必要があります
アカウントのACM証明書が90日以内に期限切れになるようにマークされているかどうかを確認します。 AWS Certificate Managerが提供する証明書は自動的に更新されます。 ACMは、インポートした証明書を自動的に更新しません。
CloudTrail.1 CloudTrail を有効にして、少なくとも 1 つのマルチリージョントレイルで設定する必要があります
少なくとも1つのマルチリージョンCloudTrail証跡があることを確認します。 CloudTrailは、アカウントのAWS API呼び出しの履歴を提供します。 CloudTrailによって生成されたAWS API呼び出し履歴により、セキュリティ分析、リソース変更追跡、コンプライアンス監査が可能になります。
CloudTrail.2 CloudTrail では、保管時の暗号化を有効にする必要があります
CloudTrailがサーバー側の暗号化（SSE）AWS Key Management Serviceカスタマーマスターキー（CMK）暗号化を使用するように構成されているかどうかを確認します。 機密性の高いCloudTrailログファイルのセキュリティをさらに強化するには、CloudTrail ログファイルの保存時に暗号化するために、AWS KMS管理キー（SSE-KMS）によるサーバー側の暗号化を使用する必要があります。
CodeBuild.1 CodeBuild GitHub または Bitbucket ソースリポジトリの URL は OAuth を使用する必要があります
GitHubまたはBitbucketソースリポジトリのURLに個人用アクセストークンまたはユーザー名とパスワードが含まれているかどうかを確認します。 認証資格情報は、クリアテキストで保存または送信したり、リポジトリURLに表示したりしないでください。
CodeBuild.2 CodeBuild プロジェクトの環境変数には、クリアテキストの認証情報を含めないでください
プロジェクトに環境変数AWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYが含まれているかどうかを確認します。
認証資格情報AWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEY、これは意図しないデータの暴露や不正アクセスにつながる可能性があるとして、クリアテキストで保存すべきではありません。
Config.1 AWS Config を有効にする必要があります
AWS Configがローカルリージョンのアカウントで有効になっているかどうかを確認し、すべてのリソースを記録しています。
AWS Configサービスは、アカウントでサポートされているAWSリソースの構成管理を実行し、ログファイルを配信します。記録される情報には、構成アイテム（AWSリソース）、構成アイテム間の関係、およびリソース間の構成変更が含まれます。
EC2.1 EBS スナップショットはパブリックであってはなりません。誰でも復元できるかどうかによって決まります。
Amazon Elastic Block Storeのスナップショットが公開されていないことを確認します。 EBSスナップショットは、明示的に許可しない限り、誰もがパブリックに復元できるようにするべきではありません。
EC2.2 VPC のデフォルトのセキュリティグループはインバウンドトラフィックとアウトバウンドトラフィックを許可しない必要があります
VPCのデフォルトのセキュリティグループがインバウンドまたはアウトバウンドのトラフィックを許可しないことを確認します。
デフォルトのセキュリティグループを使用することはお勧めしません。 デフォルトのセキュリティグループは削除できないため、デフォルトのセキュリティグループルール設定を変更して、インバウンドおよびアウトバウンドトラフィックを制限する必要があります。 これにより、EC2インスタンスなどのリソースに対してデフォルトのセキュリティグループが誤って構成された場合に、意図しないトラフィックが防止されます。
EC2.3 アタッチされた EBS ボリュームは、保管時に暗号化する必要があります
接続状態にあるEBSボリュームが暗号化されているかどうかを確認します。 このチェックに合格するには、EBSボリュームが使用中の状態であり、暗号化されている必要があります。 EBSボリュームが接続されていない場合、このチェックの対象ではありません。
EFS.1 Elastic File System は、AWS KMS を使用して保管時のファイルデータを暗号化するように設定する必要があります
Amazon KMSを使用してファイルデータを暗号化するようにAmazon Elastic File Systemが設定されているかどうかを確認します。
Amazon EFSで機密データのセキュリティを強化するには、暗号化されたファイルシステムを作成する必要があります。
ELBv2.1 Application Load Balancer は、すべての HTTP リクエストを HTTPS にリダイレクトするように設定する必要があります
Application Load BalancerのすべてのHTTPリスナーでHTTPからHTTPSへのリダイレクトが構成されているかどうかを確認します。 Application Load Balancerの1つ以上のHTTPリスナーにHTTPからHTTPSへのリダイレクトが構成されていない場合、チェックは失敗します。
ES.1 ElasticSearch ドメインでは、保管時の暗号化を有効にする必要があります
Amazon Elasticsearch Service（Amazon ES）ドメインで保存時の暗号化構成が有効になっているかどうかを確認します。
Elasticsearchの機密データのセキュリティをさらに強化するには、Elasticsearchを保存時に暗号化するように構成する必要があります。
GuardDuty.1 GuardDuty を有効にする必要があります
Amazon GuardDutyがGuardDutyアカウントとリージョンで有効になっているかどうかを確認します。
IAM.1 IAM ポリシーは完全な「*」管理権限を許可してはなりません
IAMポリシーのデフォルトバージョン（顧客管理ポリシーとも呼ばれます）に、「リソース」：「*」に対して「効果」：「許可」、「アクション」：「*」のステートメントを含む管理者アクセス権があるかどうかを確認します。
これらを指定すると最小限のアクセス許可ではなく、管理者権限を付与することになります。 タスクの実行に必要な必要最小限の権限のみを付与することをおすすめします。
IAM.2 IAM ユーザーには IAM ポリシーをアタッチしないでください
どのIAMユーザーにもポリシーがアタッチされていないことを確認します。 代わりに、IAMユーザーはIAMグループまたはロールから権限を継承する必要があります。
IAM.3 IAM ユーザーのアクセスキーは、90 日以内にローテーションする必要があります
アクティブなアクセスキーが90日以内にローテーションされるかどうかを確認します。
既にアクセスキーをお持ちの場合、セキュリティハブは90日ごとにアクセスキーをローテーションすることをお勧めします。 アクセスキーをローテーションすると、侵害されたアカウントまたは終了したアカウントに関連付けられているアクセスキーが使用される可能性が低くなります。 また、失われたり、クラックされたり、盗まれたりした可能性のある古いキーでデータにアクセスできないようにします。 アクセスキーをローテーションした後は、常にアプリケーションを更新してください。
IAM.4 IAM ルートユーザーアクセスキーは存在してはなりません
rootユーザーアクセスキーが使用可能かどうかを確認します。
ルートアカウントに関連付けられているすべてのアクセスキーを削除することをお勧めします。 これにより、アカウントを侵害するために使用できるベクターが制限されます。また、最小限の特権であるロールベースのアカウントの作成と使用を奨励します。
IAM.5 MFA は、コンソールパスワードを持つすべての IAM ユーザーに対して有効にする必要があります
コンソールパスワードを使用するすべてのIAMユーザーに対してAWS Multi-Factor Authentication（MFA）が有効になっているかどうかを確認します。
多要素認証（MFA）は、ユーザー名とパスワードに加えて保護層を追加します。 MFAが有効になっている場合、ユーザーがAWSウェブサイトにサインインすると、ユーザー名とパスワード、およびAWS MFAデバイスからの認証コードの入力を求められます。
IAM.6 ハードウェア MFA はルートユーザーに対して有効にする必要があります
AWSアカウントがハードウェア多要素認証（MFA）デバイスを使用してルート認証情報でサインインできるかどうかを確認します。
IAM.7 IAM ユーザーのパスワードポリシーには、強力な設定が必要です
IAMユーザーのアカウントパスワードポリシーが以下の推奨構成を使用しているかどうかを確認します。
- 1 文字以上のアルファベット大文字 (A～Z) を必要とする： true
- 1 文字以上のアルファベット小文字 (a～z) を必要とする： true
- 少なくとも 1 つの数字が必要： true
- 少なくとも 1 つの英数字以外の文字が必要 (!@#$%^&*()_+-=[]{}|')： true
- パスワードの最小文字数：14以上
- 直近 n 回分のパスワードを記憶して再利用を防ぐ：24
- パスワード有効期限(日)：90
Lambda.1 Lambda 関数は、他のアカウントによるパブリックアクセスを禁止する必要があります
Lambda関数のリソースベースのポリシーがアカウント外のパブリックアクセスを禁止しているかどうかを確認します。
Lambda関数は、関数に格納されているコードへの意図しないアクセスを許可する可能性があるため、公にアクセス可能であってはなりません。
Lambda.2 Lambda 関数は最新のランタイムを使用する必要があります
ランタイムのLambda関数設定が、サポートされている各言語の最新のランタイムに設定された期待値と一致することを確認します。
Lambdaランタイムオペレーティングシステム、プログラミング言語、およびソフトウェアライブラリの組み合わせを中心に構築されており、メンテナンスとセキュリティの更新が必要です。 ランタイムコンポーネントがセキュリティ更新でサポートされなくなった場合、Lambdaはランタイムを非推奨にします。
RDS.1 RDS スナップショットはプライベートにする必要があります
RDSスナップショットが公開されているかどうかを確認します。
RDSスナップショットは、意図しない限り公開しないでください。 暗号化されていない手動スナップショットをパブリックとして共有すると、すべてのAWSアカウントがそのスナップショットを利用できるようになります。 これにより、RDSインスタンスから意図しないデータが漏洩する可能性があります。
RDS.2 RDS DB インスタンスはパブリックアクセスを禁止する必要があります。PubliclyAccessible 設定によって決まります。
RDSインスタンスがパブリックにアクセス可能かどうかを確認します。
RDSインスタンスをパブリックにアクセスできる明確な要件が無いかぎり、PubliclyAccessible 設定は使用しないでください。
RDS.3 RDS DB インスタンスでは、保管時の暗号化を有効にする必要があります
RDS DBインスタンスに対してストレージ暗号化が有効になっているかどうかを確認します。
RDS DBインスタンスの機密データのセキュリティをさらに強化するには、RDS DBインスタンスが保存時に暗号化されるように構成する必要があります。 Amazon RDS DBインスタンスと保管時のスナップショットを暗号化するには、RDS DBインスタンスの暗号化オプションを有効にします。 保存時に暗号化されるデータには、DBインスタンスの基になるストレージ、その自動バックアップ、リードレプリカ、スナップショットが含まれます。
S3.1 S3 ブロックパブリックアクセス設定を有効にする必要があります
次のパブリックアクセスブロック設定がアカウントレベルで構成されているかどうかを確認します。
- ignorePublicAcls： true
- blockPublicPolicy： true
- blockPublicAcls： true
- restrictPublicBuckets： true
S3.2 S3 バケットはパブリック読み取りアクセスを禁止する必要があります
S3バケットがパブリック読み取りアクセスを許可するかどうかを確認します。 パブリックアクセスのブロック設定、バケットポリシー、およびバケットアクセスコントロールリスト（ACL）を評価します。
インターネット上のすべての人がS3バケットから読み取る必要がある明確な要件がない限り、S3バケットは一般公開されるべきではありません。
S3.3 S3 バケットはパブリック書き込みアクセスを禁止する必要があります
S3バケットがパブリック書き込みアクセスを許可するかどうかを確認します。 パブリックアクセスのブロック設定、バケットポリシー、およびバケットアクセスコントロールリスト（ACL）を評価します。
インターネット上のすべての人がS3バケットに書き込む必要がある明確な要件がない限り、S3バケットは一般公開されるべきではありません。
S3.4 S3 バケットでは、サーバー側の暗号化を有効にする必要があります
S3バケットでAmazon S3のデフォルトの暗号化が有効になっているか、またはS3バケットポリシーがサーバー側の暗号化なしでput-objectリクエストを明示的に拒否していることを確認します。
SSM.1 EC2 インスタンスは、AWS Systems Manager で管理する必要があります
アカウントのEC2インスタンスがAWS Systems Managerによって管理されているかどうかを確認します。 Systems Managerは、AWSインフラストラクチャの表示と制御に使用できるAWSサービスです。
セキュリティとコンプライアンスを維持するために、Systems Managerは管理対象インスタンスをスキャンします。 マネージドインスタンスは、Systems Managerで使用するように構成されたマシンです。 Systems Managerは、検出したポリシー違反を報告または修正します。Systems Managerは、マネージドインスタンスの構成と維持にも役立ちます。
SSM.2 Systems Manager で管理される EC2 インスタンスでは、パッチのインストール後、パッチコンプライアンスステータスが COMPLIANT である必要があります
この制御のAmazon EC2システムManagerパッチのコンプライアンスの遵守状況があるかどうかをチェックします。 Systems Manager Patch Managerによって管理されているインスタンスのみをチェックします。
まとめ
これは何も考えずに有効化でいいと思います。 AWSを使ううえでよく発生しそうなセキュリティ事故を防いでくれると思います。
気になる料金は AWS Security Hub の料金 に記載があります。 引用します。
例 1: 中小規模の組織 料金体系: 1 拠点リージョン、1 アカウント アカウント/リージョン/月あたり 250 件のセキュリティチェック アカウント/リージョン/月あたり 5,000 件の検出結果の取り込みイベント 月額料金 = 250 * 0.0010 USD (チェック/アカウント/リージョン/月あたり最初の 10 万回) + 5,000 * 0 USD (イベント/アカウント/リージョン/月あたり最初の 1 万回) = 0.25 USD/月
0.25 USD (月あたり)
参考
AWS Security Hub launches the Foundational Security Best Practices standard AWS Foundational Security Best Practices controls 【祝リリース】Security HubがGAになったので特徴と使い方まとめてみた うわっ…私のセキュリティスコア低すぎ…？Security HubのCISベンチマークの俺流チューニングで100%準拠を目指す
以上、吉井 亮 がお届けしました。
2
