本番環境で実践したいAWSセキュリティのベストプラクティス26選

本文の内容は、2022年8月29日にAlejandro Villanuevaが投稿したブログ(https://sysdig.com/blog/26-aws-security-best-practices/)を元に日本語に翻訳・再構成した内容となっております。

Well-architected フレームワークの最も重要な柱の1つは、セキュリティです。したがって、AWSセキュリティベストプラクティスに従って、不測なセキュリティの事態を防止することが重要です。

さて、あなたは問題を解決するために、ソリューションを構築してホストする目的でAWSに着目しました。アカウントを作成し、コーヒーを淹れてワークステーションに座り、設計、コーディング、ビルド、デプロイをする準備はすべて整いました。しかし、そうではありません。


ソリューションの運用性、安全性、信頼性、パフォーマンス、費用対効果を高めるには、多くのことを設定する必要があります。そして、まず最初に、それを行うための最適なタイミングは今です – 設計やエンジニアリングを始める前の最初からです。

AWSの初期設定

ルートアカウントは決して日常的に使用しないでください。代わりに、アイデンティティとアクセス管理（IAM）に対して、管理者ユーザを作成します。ルートの認証情報は安全な場所に保護し、ロックしてください（パスワードは十分強固ですか？）。ルートユーザーでキーが生成されている場合は、今がそれを削除する最適なタイミングです。

ルートアカウントの多要素認証(MFA)も絶対に有効にしたいはずです。最終的には、MFA付きのアクセスキーなしのルートユーザーを作成する必要があります。そして、このユーザは、厳密に必要でない限り、使用しないようにします。

さて、新しく作成した管理者アカウントですが、MFAを有効化することは必須です。セキュリティ第一の考え方をするなら（そして本当にそうしたいなら）、実はこれはアカウント内の全ユーザーの必須条件なのですが、特にパワーユーザーにとってはそうです。このアカウントは管理目的にのみ使用することになります。


日常的に使用する場合は、IAMパネルに移動して、あなたが明示的に権限を付与したリソースのみにアクセスできるユーザー、グループ、およびロールを作成する必要があります。

そして、

• 確実にセーフティロックされているルートアカウント（鍵なし）
• 管理者用のAdminアカウント
• 日常的に使用する複数のユーザー、グループ、およびロール

これらのアカウントはすべて、MFAを有効にして、強力なパスワードを設定する必要があります。

本当に始める準備はほぼ整いましたが、その前にAWSの責任共有モデルについて注意点があります。

AWS責任共有モデル

セキュリティとコンプライアンスは、AWSとお客様の間で共有される責任です。AWSはホストOSや仮想化レイヤーのコンポーネントから、サービスが稼働する施設の物理セキュリティまで運用・管理・制御を負います。お客様は、ゲストOS（アップデートやセキュリティパッチを含む）、その他の関連アプリケーションソフトウェア、およびAWSが提供するセキュリティグループファイアウォールの設定に責任と管理を負います。

AWSセキュリティベストプラクティスの責任分担

したがって、AWSのセキュリティを厳重に管理・運用することは、お客様の責任となります。

AWSクラウドセキュリティのベストプラクティスチェックリスト

このセクションでは、最も一般的なAWSのサービスについて説明し、採用するべき26のセキュリティベストプラクティスを紹介していきます。

オープンソースを利用したAWSセキュリティ – Cloud Custodianは、CSPM（Cloud Security Posture Management）ツールです。CSPMツールは、あなたのクラウド構成を評価し、一般的な構成の間違いを特定します。また、クラウドのログを監視し、脅威や設定変更を検出します。

それでは、サービスごとに見ていきましょう。

サービス別のAWSセキュリティベストプラクティス
	High Risk 🟥🟥🟥	Medium Risk 🟨🟨	Low Risk 🟩
AWS IAM	(1) IAMポリシーは、フル “*”管理者権限を許可してはいけません。 (4) IAM ルートユーザー アクセス キーは存在してはなりません。 (6) ルートユーザーでハードウェアMFAを有効にする必要があります。	(3) IAMユーザーのアクセスキーは、90日以内ごとにローテーションする必要があります。 (5) コンソールパスワードを持つすべてのIAMユーザーに対して、MFAを有効にする必要があります。 (7) IAMユーザーのパスワードポリシーは強固に設定する必要があります。 (8) 未使用のIAMユーザー認証情報は削除する必要があります。	(2) IAM ユーザーには IAM ポリシーを添付しないでください。
Amazon S3	(10) S3バケットはサーバーサイドの暗号化を有効にする必要があります。	(9) S3 パブリックアクセスブロックの設定を有効にする必要があります。 (11) S3 パブリックアクセスブロックの設定は、バケットレベルで有効にする必要があります。
AWS CloudTrail	(12) CloudTrailは、少なくとも1つのMulti-Region Trailが有効化され、設定されている必要があります。	(13) CloudTrailは、保存時において暗号化を有効にする必要があります。 (14) CloudTrailのログファイル検証が有効であることを確認する。
AWS Config	(15) AWS Configが有効である必要があります。
Amazon EC2	(16) アタッチされたEBSボリュームは、保存時において暗号化する必要があります。 (19) EBSのデフォルトの暗号化を有効にする必要があります。		(17) VPCのフローロギングは、すべてのVPCで有効にする必要があります。 (18) VPCのデフォルトセキュリティグループは、インバウンド・トラフィックとアウトバウンド・トラフィックを許可しないようにする必要があります。
AWS DMS	(20) AWS Database Migration Serviceのレプリケーションインスタンスは公開してはいけません。
Amazon EBS	(21) Amazon EBS スナップショットは公開すべきではありません。これは、誰でも復元できるかどうかによって判断されます。
Amazon OpenSearch Service	(22) Elasticsearchのドメインは、encryption at restを有効にする必要があります。
Amazon SageMaker		(23) SageMaker notebookインスタンスは、インターネットに直接アクセスできないようにする必要があります。
AWS Lambda		(24) Lambda function はサポートされたランタイムを使用する必要があります。
AWS KMS		(25) AWS KMS キーを意図せずに削除しないでください。
Amazon GuardDuty		(26) GuardDutyを有効にする必要があります。

AWSアイデンティティとアクセス管理(IAM)

AWS Identity and Access Management (IAM) は、AWSリソースへの最小特権アクセス制御の実施を支援します。IAMを使用すると、リソースを使用するための認証（サインイン）および許可（権限）を持つ人を制限することができます。

1.- IAMポリシーは、フル “*”管理者権限を許可してはいけません 🟥 🟥 🟥 ．

IAM ポリシーは、ユーザー、グループ、またはロールに付与される一連の特権を定義します。標準的なセキュリティのアドバイスに従って、タスクを実行するために必要な権限のみを許可することを意味する最小限の権限を付与する必要があります。

AWSセキュリティベストプラクティス 最小権限

ユーザーが必要とする最小限の権限セットではなく、完全な管理者権限を提供すると、潜在的に望ましくないアクションにリソースをさらすことになります。

各AWSアカウントについて、利用可能なカスタマー管理ポリシーをリストアップします：

aws iam list-policies --scope Local --query 'Policies[*].Arn'

前のコマンドは、Amazon Resource Names (ARN)と共にポリシーのリストを返します。これらのARNを使用して、今度はJSON形式のポリシードキュメントを取得します：

aws iam get-policy-version
	--policy-arn POLICY_ARN
	--version-id v1
	--query 'PolicyVersion.Document'

出力は、要求されたIAMポリシードキュメントになるはずです：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "1234567890",
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

次の要素については、注意が必要です：

"Effect": "Allow", "Action": "*", "Resource": "*" 

これらの要素が存在する場合、カスタマー管理ポリシーは完全な管理者権限を許可していることになります。これはリスクであり、回避しなければなりません。したがって、これらのポリシーを調整して、特定のリソースごとに許可したいアクションを正確に特定する必要があります。

他のIAMカスタマー管理ポリシーについて、前の手順を繰り返します。

オープンソースを使って完全な管理者権限の使用を検出したい場合、ここにCloud Custodian のルールがあります：

- name: full-administrative-privileges
  description: IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended and considered a standard security advice to grant least privilege -that is, granting only the permissions required to perform a task. Determine what users need to do and then craft policies for them that let the users perform only those tasks, instead of allowing full administrative privileges.
  resource: iam-policy
  filters:
    - type: used
    - type: has-allow-all

2.- IAM ポリシーをユーザーにアタッチしない 🟩

デフォルトでは、IAMユーザー、グループ、およびロールは、AWSリソースにアクセスできません。

AWSセキュリティベストプラクティスポリシー

IAMポリシーは、ユーザー、グループ、またはロールに特権を付与します。IAMポリシーは、ユーザーではなく、グループやロールに直接適用することをお勧めします。グループやロールレベルで特権を付与することで、ユーザー数の増加に伴うアクセス管理の複雑さを軽減することができます。アクセス管理の複雑さを軽減することで、本人が不用意に過剰な権限を受け取ったり、保持したりする機会を減らすことができるかもしれません。

3.- IAMユーザーのアクセスキーを90日以内ごとにローテーションする 🟨 🟨 

AWSは、アクセスキーを90日ごとにローテーションすることを推奨しています。アクセスキーをローテーションすることで、漏洩したアカウントや終了したアカウントに関連するアクセスキーが使用される可能性を減らすことができます。また、紛失、クラッキング、盗難の可能性がある古いキーでデータにアクセスできないようにすることもできます。アクセスキーのローテーションを行った後は、必ずアプリケーションを更新してください。

AWSセキュリティベストプラクティス ローテートAPIキー

まず、AWSアカウントで利用可能なすべてのIAMユーザーをリストアップします：

aws iam list-users --query 'Users[*].UserName'

このコマンドで返されたすべてのユーザーについて、各アクセスキーの有効期限を次のようにして確認します：

aws iam list-access-keys --user-name USER_NAME

これにより、指定されたIAMユーザーに存在する各アクセスキーのメタデータが表示されるはずです。出力はこのようになります：

{
    "AccessKeyMetadata": [
        {
            "UserName": "some-user",
            "Status": "Inactive",
            "CreateDate": "2022-05-18T13:43:23Z",
            "AccessKeyId": "AAAABBBBCCCCDDDDEEEE"
        },
        {
            "UserName": "some-user",
            "Status": "Active",
            "CreateDate": "2022-03-21T09:12:32Z",
            "AccessKeyId": "AAAABBBBCCCCDDDDEEEE"
        }
    ]
}

各アクティブキーの CreateDate パラメータ値を確認し、その作成時刻を判断します。アクティブなアクセスキーが過去90日以前に作成された場合、そのキーは古くなっており、AWSリソースへのアクセスを確保するためにローテーションする必要があります。

AWSアカウントに存在する各IAMユーザーについて繰り返します。

4.- IAM ルートユーザーのアクセスキーが存在しないことを確認する 🟥 🟥 🟥 

初期セットアップ時に述べたように、ルートユーザーに関連するすべてのアクセス キーを削除することを強くお勧めします。これにより、お客様のアカウントを侵害するために使用できる攻撃ベクトルが制限されます。また、最小限の特権を持つロールベースのアカウントを作成し、使用することを推奨します。

次のCloud Custodian ルールは、アカウントでルートアクセスキーが使用されているかどうかをチェックします。

- name: root-access-keys
  description: The root user account is the most privileged user in an AWS account. AWS Access Keys provide programmatic access to a given AWS account. It is recommended that all access keys associated with the root user account be removed.
  resource: account
  filters:
    - type: iam-summary
      key: AccountAccessKeysPresent
      value: 0
      op: gt

5.- コンソールパスワードを持っているすべてのIAMユーザーに対してMFAを有効にする 🟨 🟨

多要素認証（MFA）は、ユーザー名とパスワードの上に追加の保護レイヤーを追加します。MFAを有効にすると、ユーザーがAWSのWebサイトにサインインするときに、ユーザー名とパスワードの入力を要求されます。さらに、AWSのMFAデバイスから認証コードの入力が求められます。

AWSセキュリティベストプラクティス MFAダイアグラム

コンソールパスワードがあるすべてのアカウントでMFAを有効にすることをお勧めします。MFAは、コンソールアクセスのセキュリティを強化するために設計されています。認証するプリンシパルは、時間的な制約のあるキーを発行するデバイスを所有し、クレデンシャルに関する知識を持っている必要があります。

6.- ルートユーザーに対してハードウェアMFAを有効にする 🟥 🟥 🟥 

仮想MFAは、ハードウェアMFAデバイスと同レベルのセキュリティを提供しない場合があります。ハードウェア MFA は攻撃対象が最小限であり、悪意のあるユーザーがハードウェア デバイスに物理的にアクセスしない限り、盗まれることはありません。特にルートユーザーには、ハードウェアの購入承認やハードウェアの到着を待つ間、仮想MFAデバイスのみを使用することをお勧めします。

詳しくは、IAMユーザーガイドの「仮想多要素認証（MFA）デバイス（コンソール）を有効にする」をご覧ください。

以下は、ルートハードウェアMFAの欠如を検出するためのCloud Custodian ルールです：

- name: root-hardware-mfa
  description: The root user account is the most privileged user in an AWS account. MFA adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their username and password as well as for an authentication code from their AWS MFA device. It is recommended that the root user account be protected with a hardware MFA.
  resource: account
  filters:
    - or:
      - type: iam-summary
        key: AccountMFAEnabled
        value: 1
        op: ne
      - and:
        - type: iam-summary
          key: AccountMFAEnabled
          value: 1
          op: eq
        - type: has-virtual-mfa
          value: true

7.- IAMユーザーのパスワードポリシーが強固に設定されていることを確認する 🟨 🟨

強力なユーザーパスワードの作成を強制することをお勧めします。AWSアカウントにパスワードポリシーを設定して、パスワードの複雑さの要件と必須のローテーション期間を指定することができます。

パスワードポリシーを作成または変更すると、パスワードポリシーの設定のほとんどは、ユーザーが次にパスワードを変更したときに強制されます。一部の設定はすぐに実行されます。

何をもって強力なパスワードとするかは主観的な問題ですが、以下の設定は正しい道筋を示すものです：

RequireUppercaseCharacters: true
RequireLowercaseCharacters: true
RequireSymbols: true
RequireNumbers: true
MinimumPasswordLength: 8

8.- 未使用のIAMユーザーのクレデンシャルを削除する 🟨 🟨

IAMユーザーは、パスワードやアクセスキーなど、さまざまなタイプのクレデンシャルを使用してAWSリソースにアクセスすることができます。漏洩または放棄されたアカウントに関連する資格情報が使用される機会を減らすために、90日以上未使用のすべての資格情報を削除または無効化することをお勧めします。

IAMコンソールを使用して、日付のある資格情報のアカウントを監視するために必要な情報の一部を取得することができます。たとえば、アカウント内のユーザーを表示すると、アクセスキーage、パスワードage、およびLast activityのカラムがあります。これらのカラムのいずれかの値が90日以上である場合、それらのユーザーのクレデンシャルを非アクティブにしましょう。

また、クレデンシャルレポートを使用してユーザーアカウントを監視し、90日以上アクティビティのないアカウントを識別することができます。IAMコンソールから.csv形式のクレデンシャルレポートをダウンロードすることができます。

詳細については、IAMのためのAWSセキュリティベストプラクティスを確認してください。

Amazon S3

Amazon Simple Storage Service (Amazon S3)は、業界をリードするスケーラビリティ、データの可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。S3に関しては、採用すべきAWSセキュリティのベストプラクティスがいくつかあります。

9.- S3パブリックアクセスブロック設定を有効にする🟨 🟨

Amazon S3パブリックアクセスブロックは、AWSアカウント全体または個々のS3バケットレベルで制御を提供し、オブジェクトが決してパブリックアクセスを持っていないことを保証するように設計されています。パブリックアクセスは、アクセス制御リスト（ACL）、バケットポリシー、またはその両方を介してバケットとオブジェクトに付与されます。



S3バケットをパブリックアクセスさせるつもりがなければ、アカウントレベルのAmazon S3 パブリックアクセスブロック機能を構成する必要があります。

AWSアカウントで利用可能なすべてのS3バケットの名前を取得します：

aws s3api list-buckets --query 'Buckets[*].Name'

返された各バケットについて、S3パブリックアクセスブロック機能の設定を取得します：

aws s3api get-public-access-block --bucket BUCKET_NAME

先ほどのコマンドの出力はこのようになっているはずです：

"PublicAccessBlockConfiguration": {
  "BlockPublicAcls": false,
  "IgnorePublicAcls": false,
  "BlockPublicPolicy": false,
  "RestrictPublicBuckets": false
}

これらの値のいずれかがfalseである場合、データのプライバシーが危険にさらされていることになります。この短いコマンドを使って、修復してください：

aws s3api put-public-access-block
	--region REGION
	--bucket BUCKET_NAME
	--public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true	

10.- S3バケットのサーバーサイド暗号化を有効にする🟥 🟥 🟥

S3 バケット内の機密データのセキュリティ レイヤーを追加するには、サーバー側の暗号化を使用してバケットを構成し、保管中のデータを保護する必要があります。Amazon S3は、一意のキーで各オブジェクトを暗号化します。追加のセーフガードとして、Amazon S3は、定期的にローテートされるルートキーでキー自体を暗号化します。Amazon S3のサーバーサイドの暗号化は、あなたのデータを暗号化するために利用可能な最強のブロック暗号の1つ、256ビットAES-256（Advanced Encryption Standard)を使用しています。


AWSアカウントで利用可能なすべての既存のS3バケットをリストアップします：

aws s3api list-buckets --query 'Buckets[*].Name'

次に、前のステップで返されたS3バケットの名前を識別子として、Default Encryption機能のステータスを取得します：

aws s3api get-bucket-encryption --bucket BUCKET_NAME

コマンドの出力は、要求された機能の設定詳細を返すはずです。get-bucket-encryptionコマンドの出力がエラーメッセージを返す場合、デフォルトの暗号化は現在有効になっていないため、選択したS3バケットがAmazon S3に保存されたときにすべてのオブジェクトを自動的に暗号化することはありません。

すべてのS3バケットについて、この手順を繰り返します。

11.- バケットレベルでS3パブリックアクセスブロック設定を有効にする🟨 🟨

Amazon S3パブリックアクセスブロックは、AWSアカウント全体または個々のS3バケットレベルで制御を提供し、オブジェクトが決してパブリックアクセスを持っていないことを保証するように設計されています。パブリックアクセスは、アクセス制御リスト（ACL）、バケットポリシー、またはその両方を介してバケットとオブジェクトに付与されます。


S3バケットをパブリックアクセスさせるつもりがなければ（おそらくそうすべきではないでしょうが）、アカウントレベルのAmazon S3 パブリックアクセスブロック機能を構成する必要があります。

このCloud Custodian ルールを使用して、パブリックにアクセス可能なS3バケットを検出することができます。

- name: buckets-public-access-block
  description: Amazon S3 provides Block public access (bucket settings) and Block public access (account settings) to help you manage public access to Amazon S3 resources. By default, S3 buckets and objects are created with public access disabled. However, an IAM principle with sufficient S3 permissions can enable public access at the bucket and/or object level. While enabled, Block public access (bucket settings) prevents an individual bucket, and its contained objects, from becoming publicly accessible. Similarly, Block public access (account settings) prevents all buckets, and contained objects, from becoming publicly accessible across the entire account.
  resource: s3
  filters:
    - or:
      - type: check-public-block
        BlockPublicAcls: false
      - type: check-public-block
        BlockPublicPolicy: false
      - type: check-public-block
        IgnorePublicAcls: false
      - type: check-public-block
        RestrictPublicBuckets: false

AWS CloudTrail

AWS CloudTrailは、AWSアカウントのガバナンス、コンプライアンス、運用とリスクの監査を可能にするAWSサービスです。ユーザー、ロール、またはAWSサービスによって実行されたアクションは、CloudTrailのイベントとして記録されます。イベントには、AWS Management Console、AWS Command Line Interface、およびAWS SDKとAPIで実行されたアクションが含まれます。

次のセクションでは、すべてのリージョンでインフラストラクチャーを監視するためにCloudTrailを構成するのに役立ちます。

12.- 少なくとも1つのMulti-Region trailを有効化してCloudTrailを構成する 🟥 🟥 🟥

CloudTrailは、AWSマネジメントコンソール、AWS SDK、コマンドラインツールから行われたAPIコールを含む、アカウントに対するAWS APIコールの履歴を提供します。履歴はまた、AWS CloudFormationのような、より高いレベルのAWSサービスからのAPIコールを含んでいます。


CloudTrailによって生成されたAWS APIコールの履歴は、セキュリティ分析、リソース変更の追跡、およびコンプライアンス監査を可能にします。また、Multi-Region trailは以下のようなメリットもあります。

• Multi-Region trailは、他の使われていないリージョンで発生する予期せぬアクティビティを検出するのに役立ちます。
• Multi-Region trailでは、グローバル サービス イベント ロギングがデフォルトで有効になっていることを確認します。グローバルサービスのイベントログは、AWSのグローバルサービスによって生成されたイベントを記録します。
• Multi-Region trailでは、すべての読み取りと書き込み操作の管理イベントが、CloudTrailがAWSアカウントのすべてのリソースの管理操作を記録することを保証します。

デフォルトでは、AWSマネジメントコンソールを使用して作成されたCloudTrailは、Multi-Region trailになります。

選択したAWSリージョンで利用可能なすべてのTrailをリストアップします：

aws cloudtrail describe-trails

出力には、各AWS CloudTrailとその構成詳細が表示されます。IsMultiRegionTrail 設定パラメータ値がfalseの場合、選択したTrailは現在すべてのAWSリージョンで有効ではありません：

{
    "trailList": [
        {
            "IncludeGlobalServiceEvents": true,
            "Name": "ExampleTrail",
            "TrailARN": "arn:aws:cloudtrail:us-east-1:123456789012:trail/ExampleTrail",
            "LogFileValidationEnabled": false,
            "IsMultiRegionTrail": false,
            "S3BucketName": "ExampleLogging",
            "HomeRegion": "us-east-1"
        }
    ]
}

すべてのtrailを確認し、少なくとも1つがmulti-Regionであることを確認します。

13.- CloudTrail で保存時の暗号化を有効にする🟨 🟨

CloudTrailが、AWS Key Management Serviceのカスタマーマスターキー（CMK）によるサーバーサイド暗号化（SSE）を使用するよう設定されているか確認します。

KmsKeyIdが定義されていればチェックは通ります。機密性の高いCloudTrailログファイルのセキュリティを強化するために、CloudTrailログファイルにはAWS KMS-managed keys (SSE-KMS) によるサーバーサイド暗号化を使用して、保存時において暗号化を行う必要があります。なお、デフォルトでは、CloudTrailからバケットに配信されるログファイルは、Amazon S3が管理する暗号化キー（SSE-S3）を用いたAmazonサーバーサイド暗号化により暗号化されます。

ログが暗号化されているかどうかは、以下のCloud Custodianルールで確認することができます：

- name: cloudtrail-logs-encrypted-at-rest
  description: AWS CloudTrail is a web service that records AWS API calls for an account and makes those logs available to users and resources in accordance with IAM policies. AWS Key Management Service (KMS) is a managed service that helps create and control the encryption keys used to encrypt account data, and uses Hardware Security Modules (HSMs) to protect the security of encryption keys. CloudTrail logs can be configured to leverage server side encryption (SSE) and KMS customer created master keys (CMK) to further protect CloudTrail logs. It is recommended that CloudTrail be configured to use SSE-KMS.
  resource: cloudtrail
  filters:
    - type: value
      key: KmsKeyId
      value: absent

以下のようにAWSコンソールを使って修復することができます：

1. AWSマネジメントコンソール（https://console.aws.amazon.com/cloudtrail/）にサインインします。
2. 左側のナビゲーションパネルで、Trails を選択します。
3. 名前列で、更新する必要があるTrails 名を選択します。
4. S3セクションの横にある鉛筆のアイコンをクリックして、トレイルバケットの構成を編集します。
5. S3 bucket*の下にあるAdvancedをクリックします。
6. Encrypt log files の横の Yes を選択して、カスタマーマスターキー（CMK）を使用してSSE-KMSでログファイルを暗号化します。
7. 新しいCMKを作成してその名前を入力するには、Create a new KMS key の横の Yes を選択し、そうでない場合は No を選択して地域で利用可能な既存のCMK暗号化キーを使用します。
8. Saveをクリックして、SSE-KMS暗号化を有効にします。

14.- CloudTrailログファイル検証を有効にする 🟨 🟨

CloudTrail ログファイル検証は、CloudTrail が Amazon S3 に書き込む各ログのハッシュを含むデジタル署名付きダイジェストファイルを作成します。これらのダイジェストファイルを使用して、CloudTrailがログを配信した後に、ログファイルが変更、削除、または未変更であったかどうかを判断することができます。

すべてのトレイルでファイル検証を有効にすることをお勧めします。ログファイル検証は、CloudTrailログの追加的な完全性チェックを提供します。

AWSコンソールでこれを確認するには、次のようにします：

1. AWSマネジメントコンソール（https://console.aws.amazon.com/cloudtrail/）にサインインします。
2. 左のナビゲーションパネルで、Trailsを選択します。
3. Name 列で、調べる必要のあるTrail名を選択します。
4. S3 セクションで、Enable log file validation status をチェックします。
5. Enable log file validation statusがNoに設定されている場合、選択したTrailではログファイルの整合性検証が有効になっていません。この場合、修正します。
   1. S3セクションの横にある鉛筆のアイコンをクリックして、Trailバケットの設定を編集します。
   2. S3 bucket*の下でAdvancedをクリックし、Enable log file validationを検索します。
   3. ログファイル検証を有効にするために[はい]を選択し、Saveをクリックします。

AWS Cloudtrailのセキュリティベストプラクティスについてはこちらをご覧ください。

AWS Config

AWS Configは、AWSアカウントに関連するリソースの詳細なビューを提供し、それらがどのように構成されているか、それらが互いにどのように関連しているか、構成とそれらの関係が時間の経過とともにどのように変化しているかが含まれます。

15.- AWS Configが有効になっていることを確認する 🟥 🟥 🟥

AWS Configサービスは、お客様のアカウントでサポートされているAWSリソースの構成管理を行い、ログファイルを配信します。記録される情報には、構成項目（AWSリソース）、構成項目間の関係、リソース間の構成変更が含まれます。


すべてのリージョンでAWS Configを有効にすることが推奨されます。AWS ConfigがキャプチャーするAWS構成アイテムの履歴は、セキュリティ分析、リソース変更の追跡、およびコンプライアンス監査を可能にします。

選択したリージョンで、Configサービスによって作成されたすべての構成レコーダーと配信チャネルのステータスを取得します：

aws configservice --region REGION get-status

前のコマンドの出力は、利用可能なすべてのAWS Config配信チャネルと構成レコーダーのステータスを示しています。AWS Configが有効でない場合、構成レコーダーと配信チャンネルの両方のリストが空欄で表示されます：

Configuration Recorders:
Delivery Channels:

また、以前は有効であったが現在は無効になっている場合は、ステータスがOFFになっています：

Configuration Recorders:
name: default
recorder: OFF
Delivery Channels:
name: default
last stream delivery status: NOT_APPLICABLE
last history delivery status: SUCCESS
last snapshot delivery status: SUCCESS

この問題を改善するために、AWS Configを有効にした後、すべてのリソースを記録するように設定します。

1. AWS Configのコンソール（https://console.aws.amazon.com/config/）を開きます。
2. AWS Configを構成するリージョンを選択します。
3. AWS Config を使用したことがない場合は、AWS Config デベロッパーガイドの「使用の開始」を参照してください。
4. メニューから「設定」ページに移動し、以下を実行します。
   1. 編集を選択します。
   2. Resource types to record で、Record all resources supported in this regionと Include global resources (e.g., AWS IAM resources)」を選択します。
   3. Data retention period で、AWS Config データのデフォルトの保持期間を選択するか、カスタムの保持期間を指定します。
   4. AWS Config ロールで、Create AWS Config service-linked role を選択するか、Choose a role from your account を選択し、使用するロールを選択します。
   5. Amazon S3 バケットで、使用するバケットを指定するか、バケットを作成し、オプションでプレフィックスを含めます。
   6. Amazon SNSトピックの下で、アカウントからAmazon SNSトピックを選択するか、作成します。Amazon SNSの詳細については、『Amazon Simple Notification Service Getting Started Guide』を参照してください。
5. 保存を選択します。

さらに詳しく説明するには、AWS Configのセキュリティベストプラクティスに従います。

Amazon EC2

Amazon Elastic Compute Cloud（Amazon EC2）は、ソフトウェアシステムのビルドとホストに使用する、サイズ変更可能なコンピューティング能力を提供するWebサービスです。したがって、EC2はAWSのコアサービスの1つであり、最高のセキュリティプラクティスとEC2を保護する方法を知ることが必要です。

16.- アタッチされたEBSボリュームが保存時に暗号化されていることを確認する 🟥 🟥 🟥 

アタッチされている状態のEBSボリュームが暗号化されているかどうかを確認します。このチェックを通過するためには、EBSボリュームが使用中であり、暗号化されている必要があります。EBSボリュームがアタッチされていない場合は、このチェックの対象外です。


EBSボリューム内の機密データのセキュリティを強化するために、EBSの保存時の暗号化を有効にする必要があります。Amazon EBS暗号化は、独自のキー管理インフラストラクチャーをビルド、維持、およびセキュリティ保護する必要がない、EBSリソースの簡単な暗号化ソリューションを提供します。暗号化されたボリュームとスナップショットを作成する際に、KMSキーを使用します。

EC2 Elastic Block Storeのボリュームが暗号化されているかどうかを判断するには、describe-volumesコマンドを実行します：

aws ec2 describe-volumes
	--filters Name=attachment.instance-id, Values=INSTANCE_ID

コマンドの出力には、インスタンスのEBSボリュームの暗号化状態（有効はtrue、無効はfalse）が表示されるはずです。

暗号化されていない既存のボリュームまたはスナップショットを暗号化する直接的な方法はありません。ボリュームまたはスナップショットは、作成時にのみ暗号化できます。

デフォルトで暗号化を有効にすると、Amazon EBSは、Amazon EBS暗号化用のデフォルトのキーを使用して、出来上がった新しいボリュームまたはスナップショットを暗号化します。デフォルトで暗号化を有効にしていない場合でも、個々のボリュームまたはスナップショットを作成するときに暗号化を有効にすることができます。どちらの場合も、Amazon EBS暗号化のデフォルトキーを上書きして、対称暗号化用のカスタママネージドキーを選択することができます。

17.- すべてのVPCでVPCフローログを有効にする 🟩

VPCフローログ機能を使用すると、VPC内のネットワークインターフェイスに出入りするIPアドレスのトラフィックに関する情報をキャプチャーできます。フローログを作成すると、CloudWatch Logsでそのデータを表示・取得することができます。コストを削減するために、フローログをAmazon S3に送信することもできます。

VPCのパケット拒否のフローログを有効にすることをお勧めします。フローログは、VPCを通過するネットワークトラフィックの可視性を提供し、異常なトラフィックを検出したり、セキュリティワークフロー中に洞察を提供することができます。デフォルトでは、レコードには、送信元、宛先、プロトコルなど、IPアドレスフローのさまざまなコンポーネントの値が含まれます。

- name: flow-logs-enabled
  description: VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. After you've created a flow log, you can view and retrieve its data in Amazon CloudWatch Logs. It is recommended that VPC Flow Logs be enabled for packet 'Rejects' for VPCs.
  resource: vpc
  filters:
    - not:
        - type: flow-logs
          enabled: true

18.- VPCのデフォルトセキュリティグループがインバウンド・トラフィックとアウトバウンド・トラフィックを許可していないことを確認 🟩

デフォルトセキュリティグループのルールは、同じセキュリティグループに割り当てられたネットワークインターフェース（および関連するインスタンス）からのすべてのアウトバウンドとインバウンドトラフィックを許可します。

デフォルトのセキュリティグループを使用することはお勧めしません。デフォルトのセキュリティグループは削除できないため、デフォルトのセキュリティグループのルール設定を変更して、インバウンドとアウトバウンドのトラフィックを制限する必要があります。これにより、EC2インスタンスなどのリソースに誤ってデフォルトのセキュリティグループが設定された場合、意図しないトラフィックを防ぐことができます。


選択したリージョン内のデフォルトセキュリティグループの説明を取得します：

aws ec2 describe-security-groups
	--region REGION
	--filters Name=group-name,Values='default'
	--output table
	--query 'SecurityGroups[*].IpPermissions[*].IpRanges'

このコマンドが何も出力を返さない場合は、デフォルトのセキュリティグループがパブリックなインバウンドトラフィックを許可していないことを意味します。そうでない場合は、次の例のように、定義されているインバウンドトラフィックのソース IP が返されるはずです。

------------------------
|DescribeSecurityGroups|
+----------------------+
|        CidrIp        |
+----------------------+
|  0.0.0.0/0           |
|  ::/0                |
|  1.2.3.4/32          |
|  1.2.3.5/32          |
+----------------------+

返された IP が  0.0.0.0/0 または ::/0の場合、選択されたデフォルトセキュリティグループはパブリックインバウンドトラフィックを許可していることになります。EC2上でSSHを保護する場合の本当の脅威は何かについては、以前説明しました。

この問題を改善するには、新しいセキュリティグループを作成し、それらのセキュリティグループをリソースに割り当てます。デフォルトのセキュリティグループが使用されないようにするには、それらのインバウンドルールおよびアウトバウンドルールを削除します。

19.- EBSのデフォルトの暗号化を有効にする🟥 🟥 🟥

アカウントで暗号化を有効にすると、Amazon EBSボリュームとスナップショット コピーは、保存時に暗号化されます。これは、データに対する追加の保護レイヤーを提供します。詳細については、Amazon EC2 User Guide for Linux Instancesの Encryption by default を参照してください。

次のインスタンスタイプは、暗号化をサポートしていないことに注意してください：R1、C1、およびM1。

get-ebs-encryption-by-defaultコマンドを実行して、選択したリージョンのAWSクラウドアカウントでEBSの暗号化がデフォルトで有効になっているかどうかを確認します：

aws ec2 get-ebs-encryption-by-default
	--region REGION
	--query 'EbsEncryptionByDefault'

コマンドが false を返した場合、選択した AWS リージョンで、新しい EBS ボリュームに対するデフォルトでの保存データの暗号化が有効になっていません。以下のコマンドで修正します：

aws ec2 enable-ebs-encryption-by-default
	--region REGION

AWS Database Migration Service (DMS)

AWS Database Migration Service（AWS DMS）は、リレーショナルデータベース、データウェアハウス、NoSQLデータベースなどのデータストアを簡単に移行できるクラウドサービスです。AWS DMSは、AWSクラウドへのデータ移行や、クラウドとオンプレミスの組み合わせ間でのデータ移行に使用できます。

20.- AWS Database Migration Serviceのレプリケーションインスタンスが公開されていないことを確認する🟥 🟥 🟥

個人データの公開を避け、セキュリティリスクを最小限に抑えるために、Amazon Database Migration Service (DMS) がインターネットからパブリックアクセスできないことを確認します。DMSレプリケーションインスタンスは、ソースとターゲットデータベースの両方が、VPN、VPCピアリング接続、またはAWS Direct Connect専用接続を使用してインスタンスのVPCに接続されている同じネットワーク内にある場合、プライベートIPアドレスを設定してパブリックアクセス機能を無効にしておく必要があります。

1. AWS Management Consoleにサインインします（https://console.aws.amazon.com/dms/）。
2. 左側のナビゲーションパネルで、レプリケーションインスタンスを選択します。
3. 調べたいDMSレプリケーションインスタンスを選択し、リソース構成の詳細が表示されたパネルを開きます。
4. ダッシュボードの下部パネルから概要タブを選択し、一般にアクセス可能な構成属性値を確認します。属性値がYesに設定されている場合、選択したAmazon DMSレプリケーションインスタンスはVirtual Private Cloud（VPC）外部からアクセス可能であり、セキュリティリスクにさらされる可能性があります。修正するには、以下を実行します。
   1. ダッシュボードのトップメニューから レプリケーションインスタンスの作成 ボタンをクリックし、起動プロセスを開始します。
   2. レプリケーションインスタンスの作成 ページで、以下を実行します。
      1. Publicly accessibleチェックボックスのチェックを外して、新しいレプリケーションインスタンスへのパブリックアクセスを無効にします。この設定を無効にすると、Amazon DMSは作成時にインスタンスにパブリックIPアドレスを割り当てず、VPC外のソース/ターゲット・データベースに接続できなくなります。
      2. Nameボックスに新しいレプリケーションインスタンスの一意の名前を入力し、手順5でコピーした構成情報を使用してインスタンスの残りの設定を構成します。
      3. Create replication instanceをクリックし、新しいAmazon DMSインスタンスを起動します。
   3. 新しく作成したAWS DMSレプリケーションインスタンスを含む新しい移行タスクを作成し、データベース移行計画を更新します。
   4.  古いレプリケーションインスタンスの追加課金を停止するには。
      1. 古いDMSインスタンスを選択し、ダッシュボードのトップメニューから［Delete］ボタンをクリックします。
      2. レプリケーションインスタンスの削除ダイアログボックスで、インスタンスの詳細を確認し、削除をクリックして選択したDMSリソースを終了させます。
5. 選択した地域にプロビジョニングされた各 AWS DMS レプリケーションインスタンスについて、ステップ番号 3 と 4 を繰り返します。
6. コンソールのナビゲーションバーからリージョンを変更し、他のすべてのリージョンでこのプロセスを繰り返します。

AWS Database Migration Serviceのセキュリティベストプラクティスの詳細については、こちらをご覧ください。

Amazon Elastic Block Store（EBS）

Amazon Elastic Block Store (Amazon EBS)は、EC2インスタンスで使用するためのブロックレベルのストレージボリュームを提供します。EBSボリュームは、フォーマットされていないrawブロックデバイスのように動作します。これらのボリュームは、インスタンス上のデバイスとしてマウントすることができます。インスタンスにアタッチされたEBSボリュームは、インスタンスの寿命とは無関係に永続化するストレージボリュームとして公開されます。これらのボリュームの上にファイルシステムを作成したり、ブロックデバイス（ハードドライブなど）を使用するのと同じ方法で使用したりすることができます。

インスタンスに接続されたボリュームの構成を動的に変更することができます。

21.- Amazon EBS スナップショットが公開されていないこと、または誰でも復元できるようになっていないことを確認する 🟥 🟥 🟥 

EBSスナップショットは、EBSボリューム上のデータを特定の時点でAmazon S3にバックアップするために使用されます。スナップショットを使用して、EBSボリュームの以前の状態を復元することができます。スナップショットを一般に共有することは、ほとんど認められません。一般的に、スナップショットを一般に共有する決定は、誤って、またはその意味を完全に理解せずに行われたものです。このチェックは、そのような共有がすべて完全に計画され、意図的に行われたことを確認するのに役立ちます。

すべてのEBSボリュームスナップショットのリストを取得します：

aws ec2 describe-snapshots
	--region REGION
	--owner-ids ACCOUNT_ID
	--filters Name=status,Values=completed
	--output table
	--query 'Snapshots[*].SnapshotId'

各スナップショットについて、 createVolumePermission 属性を確認します：

aws ec2 describe-snapshot-attribute
	--region REGION
	--snapshot-id SNAPSHOT_ID
	--attribute createVolumePermission
	--query 'CreateVolumePermissions[]'

先ほどのコマンドの出力は、選択したスナップショットからEBSボリュームを作成するための権限に関する情報を返します。

{
    "Group": "all"
}

コマンドの出力が  "Group": "all"の場合、スナップショットはすべてのAWSアカウントとユーザーからアクセス可能です。この場合は、このコマンドを実行して修正します：

aws ec2 modify-snapshot-attribute
	--region REGION
	--snapshot-id SNAPSHOT_ID
	--attribute createVolumePermission
	--operation-type remove
	--group-names all

Amazon OpenSearch Service

Amazon OpenSearch Serviceは、AWSクラウド上でOpenSearchクラスターのデプロイ、運用、スケーリングを簡単に行うことができるマネージドサービスです。Amazon OpenSearch Serviceは、Amazon Elasticsearch Serviceの後継サービスで、OpenSearchとレガシーElasticsearch OSS（オープンソースの最終バージョンである7.10まで）をサポートしています。クラスター作成時に、どの検索エンジンを使用するかのオプションがあります。

22.- Elasticsearchのドメインでencryption at restを有効にする🟥 🟥 🟥

OpenSearch の機密データのセキュリティを強化するために、OpenSearch を保存時に暗号化するよう設定する必要があります。Elasticsearchドメインは、保存時のデータの暗号化を提供しています。この機能は、AWS KMSを使用して、暗号化キーを保存および管理します。暗号化の実行には、256ビットキー（AES-256）のAdvanced Encryption Standardアルゴリズムが使用されます。

現在利用可能なすべてのAmazon OpenSearchドメインをリストアップします：

aws es list-domain-names --region REGION

ここで、 data-at-rest encryption 機能が有効になっているかどうかで判断します：

aws es describe-elasticsearch-domain
	--region REGION
	--domain-name DOMAIN_NAME
	--query 'DomainStatus.EncryptionAtRestOptions'

 Enabled フラグがfalseの場合、選択したAmazon ElasticSearchドメインでdata-at-rest暗号化が有効ではないので修正します：

aws es create-elasticsearch-domain
	--region REGION
	--domain-name DOMAIN_NAME
	--elasticsearch-version 5.5
	--elasticsearch-cluster-config InstanceType=m4.large.elasticsearch,InstanceCount=2
	--ebs-options EBSEnabled=true,VolumeType=standard,VolumeSize=200
	--access-policies file://source-domain-access-policy.json
	--vpc-options SubnetIds=SUBNET_ID,SecurityGroupIds=SECURITY_GROUP_ID
	--encryption-at-rest-options Enabled=true,KmsKeyId=KMS_KEY_ID

新しいクラスターのプロビジョニングが完了したら、既存のデータ（元のクラスターからエクスポートされたもの）を新しく作成されたクラスターにアップロードします。

すべてのデータのアップロードが完了したら、暗号化されていないOpenSearchドメインを削除して、リソースに対する課金を停止するのが安全です：

aws es delete-elasticsearch-domain
	--region REGION
	--domain-name DOMAIN_NAME

Amazon SageMaker

Amazon SageMakerは、フルマネージドな機械学習サービスです。Amazon SageMakerを使用すると、データサイエンティストとデベロッパーは、迅速に機械学習モデルをビルドして訓練し、それらを本番環境用のホスト環境にデプロイすることができます。

23.- SageMaker ノートブックインスタンスが直接インターネットにアクセスできないことを確認する 🟨 🟨

VPC を使用せずに SageMaker インスタンスを構成した場合、デフォルトでインスタンスの直接インターネット アクセスが有効になっています。インスタンスを VPC で構成し、デフォルトの設定を [無効 – VPC 経由でインターネットにアクセス] に変更する必要があります。

ノートブックからモデルをトレーニングまたはホストするためには、インターネットアクセスが必要です。インターネットアクセスを有効にするには、VPCにNATゲートウェイがあり、セキュリティグループがアウトバウンド接続を許可していることを確認します。ノートブックインスタンスを VPC 内のリソースに接続する方法の詳細については、Amazon SageMaker デベロッパーガイドの「ノートブックインスタンスを VPC 内のリソースに接続する」を参照してください。

また、SageMaker の設定へのアクセスを、許可されたユーザーのみに制限する必要があります。SageMaker の設定とリソースを変更するために、ユーザーの IAM 権限を制限します。

1. AWS Management Console にサインインします（https://console.aws.amazon.com/sagemaker/）。
2. ナビゲーションパネルで、Notebook の下にある Notebook instances を選択します。
3. 調査したいSageMakerノートブックインスタンスを選択し、インスタンス名（リンク）をクリックします。
4. 選択したインスタンスの設定ページの「ネットワーク」セクションで、VPC サブネット ID とセキュリティグループ ID があるかどうかを確認します。これらのネットワーク設定の詳細がない場合、代わりに以下のステータスが表示されます。”カスタム VPC 設定を適用していません”。 ノートブックインスタンスはVPCネットワーク内で実行されていないため、この適合ルールに記載されている手順に従って、VPC内にインスタンスをデプロイすることができます。そうではなく、ノートブックインスタンスがVPC内で実行されている場合は、[Direct internet access]構成属性の値を確認します。属性値が Enabled に設定されている場合、選択した Amazon SageMaker ノートブックインスタンスはパブリックアクセス可能です。

ノートブックのダイレクトインターネットアクセスが有効になっている場合は、このCLIコマンドで再作成することで修正します：

aws sagemaker create-notebook-instance
	--region REGION
	--notebook-instance-name NOTEBOOK_INSTANCE_NAME
	--instance-type INSTANCE_TYPE
	--role-arn ROLE_ARN
	--kms-key-id KMS_KEY_ID
	--subnet-id SUBNET_ID
	--security-group-ids SECURITY_GROUP_ID
	--direct-internet-access Disabled

AWS Lambda

AWS Lambdaを使用すると、サーバーのプロビジョニングや管理なしでコードを実行することができます。消費した計算時間に対してのみ課金され、コードが実行されていないときは課金されません。事実上あらゆるタイプのアプリケーションやバックエンドサービスのコードを実行することができ、そのすべてをゼロ管理で行うことができます。

コードをアップロードするだけで、Lambdaがコードの実行とスケーリングに必要なすべての処理を行い、高い可用性を実現します。他のAWSサービスから自動的にトリガーされるようにコードをセットアップしたり、Webやモバイルアプリから直接呼び出すこともできます。

Lambda functionで実行するコードのセキュリティ確保や監査を行わないと、攻撃者の最初のアクセスになりかねないという問題にも触れなくてはなりません。

24.- Lambda functionでサポートされているランタイムを使用する🟨 🟨

このAWSセキュリティベストプラクティスでは、ランタイムのLambda function 設定が、各言語でサポートされているランタイムに設定されている期待値と一致していることを確認することを推奨しています。このコントロールは、次のランタイムのfunction 設定をチェックします：nodejs16.x, nodejs14.x, nodejs12.x, python3.9, python3.8, python3.7, ruby2.7, java11, java8, java8.al2, go1.x, dotnetcore3.1, dotnet6

AWS Configのルールでは、パッケージタイプがimageであるfunctionは無視されます。

Lambdaランタイムは、OS、プログラミング言語、ソフトウェアライブラリの組み合わせでビルドされ、メンテナンスやセキュリティアップデートの対象となります。ランタイムコンポーネントがセキュリティアップデートのサポートを終了すると、Lambdaはランタイムを非推奨にします。非推奨のランタイムを使用するfunctionを作成できない場合でも、そのfunctionは呼び出しイベントを処理するために使用できます。Lambda functionが最新のものであることを確認し、古いランタイム環境を使用しないようにします。

選択したAWSクラウドリージョンで利用可能なすべてのAmazon Lambda functionの名前を取得します：

aws lambda list-functions
  --region REGION
  --output table
  --query 'Functions[*].FunctionName'

次に、各 function で利用可能なランタイム情報を調べます：

aws lambda get-function-configuration
  --region REGION
  --function-name FUNCTION_NAME
  --query 'Runtime'

返された値を、AWSがサポートするAmazon Lambdaのランタイムの更新リスト、およびAWSのドキュメントに記載されているサポート終了プランと比較します。

ランタイムがサポートされていない場合、最新のランタイムバージョンを使用するように修正します。例えば、以下のようになります：

aws lambda update-function-configuration
  --region REGION
  --function-name FUNCTION_NAME
  --runtime "nodejs16.x"

AWS Key Management Service (AWS KMS)

AWS Key Management Service (AWS KMS)は、クラウド用に拡張された暗号化およびキー管理サービスです。AWS KMSのキーと機能は、他のAWSサービスで使用され、あなたはAWSを使用する独自のアプリケーションでデータを保護するためにそれらを使用することができます。

25.- AWS KMSキーを意図せず削除しないこと🟨 🟨

KMSキーは一度削除すると復元できません。KMSキーで暗号化されたデータも、KMSキーが削除されると永久に復元できません。重要なデータが削除予定のKMSキーの下で暗号化されている場合、意図的に暗号の消去を行うのでなければ、データの復号化または新しいKMSキーの下での再暗号化を検討してください。

KMSキーの削除が予定されている場合、誤設定による削除を取り消すための時間を確保するために、強制的な待機期間が設けられています。デフォルトの待機期間は30日ですが、KMSキーの削除がスケジュールされている場合は、7日間まで短縮することができます。待機期間中は、スケジュールされた削除をキャンセルすることができ、KMSキーが削除されることはありません。

選択したAWSリージョンで利用可能なすべてのカスタマーマスターキーをリストアップします：

aws kms list-keys --region REGION

各CMKに対してdescribe-keyコマンドを実行し、削除予定のキーを特定します：

aws kms describe-key --key-id KEY_ID

このコマンドの出力には、選択されたキーのメタデータが表示されます。 KeyState の値がPendingDeletionになっていれば、そのキーは削除が予定されています。しかし、これが本当に望むものでない場合（最も一般的なケース）、次のようにして削除のスケジュールを解除してください：

aws kms cancel-key-deletion --key-id KEY_ID

Amazon GuardDuty

Amazon GuardDutyは、継続的なセキュリティ監視サービスです。Amazon GuardDutyは、AWS環境における予期しない、潜在的に不正または悪意のあるアクティビティを特定するのに役立ちます。

26.- GuardDutyを有効にする🟨 🟨

サポートされているすべてのAWSリージョンでGuardDutyを有効にすることが強く推奨されます。そうすることで、積極的に使用していないリージョンでも、GuardDutyで不正または異常なアクティビティに関する調査結果を生成することができます。また、GuardDutyはIAMなどのグローバルなAWSサービスのCloudTrailイベントを監視できるようになります。

既存のすべてのAmazon GuardDuty detectorのIDをリストアップします。detectorは、AWS GuardDutyサービスを表すオブジェクトです。GuardDutyが動作させるには、detectorを作成する必要があります：

aws guardduty list-detectors
	--region REGION
	--query 'DetectorIds'

list-detectorsコマンドの出力が空の配列を返した場合、利用可能なGuardDuty detectorは存在しません。この場合、Amazon GuardDutyサービスはAWSアカウント内で有効になっていません。この場合、次のコマンドを使用してdetectorを作成します：

aws guardduty create-detector
	--region REGION
	--enable

detectorが有効になると、AWS CloudTrail、VPCフローログ、DNSログから独立したデータのストリームをプルして分析を開始し、調査結果を生成するようになります。

AWSのコンプライアンス標準とベンチマーク

AWSインフラクチャーを安全に保つためのセットアップとメンテナンスは、終わりのない労力であり、多くの時間を必要とします。

このため、クラウド環境を効果的に保護するために必要なすべての要件を提供する、業界に関連するコンプライアンス標準（複数可）に従う方がよいでしょう。

環境の保護とセキュリティ標準への準拠は継続的に行われるため、CIS Amazon Web Services Foundations Benchmarkのようなポリシーを定期的に実行するのもよいでしょう。

まとめ

オール・クラウド化は、新しい可能性の扉を開きますが、同時に攻撃ベクトルへの扉を大きく開くことにもなります。AWSの新しいサービスを利用するたびに、潜在的な危険性を認識し、十分に準備する必要があります。

幸いなことに、FalcoやCloud Custodianのようなクラウドネイティブセキュリティツールは、これらのベストプラクティスを案内し、コンプライアンス要件を満たすのを助けてくれます。

---

これらのサービスをどのように設定し管理するかについて、SysdigがCSPM（Cloud Security Posture Management）を改善するお手伝いをします。以下のリソースでより深く掘り下げてみてください。

• Sysdig SecureによるAWSセキュリティサービスの向上
• SysdigでAmazon EC2のセキュリティを確保する方法
• SysdigでAWS Route 53を保護する方法
• SysdigによるAWS RDSのセキュリティイベントをハンティングする
• Amazon GuardDutyとSysdigを使ったマルウェア対策

30日間の無料トライアルに登録し、ご自分の目でお確かめください。

AWS MarketplaceでSysdig Secure DevOps Platformをご購入ください！

Sysdigは、AWS Marketplaceで簡単にご購入いただくことができます。

AWS MarketplaceのSysdig Secure DevOps Platformをご参照ください。