本番環境で採用すべき26のAWSセキュリティベストプラクティス

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

セキュリティは、 AWS Foundational セキュリティベストプラクティスの基本的な柱です。セキュリティリスクを最小限に抑え、環境を保護するには、サービス別にまとめられた AWS セキュリティベストプラクティスに従うことが不可欠です。この構造化されたアプローチは、潜在的な脆弱性に積極的に対処し、堅牢で安全なクラウドアーキテクチャーを維持するのに役立ちます。

• AWS IAM
  • （1） IAMポリシーでは、フルの ” * ” 管理者権限を許可すべきではない
  • （２） IAMユーザーにはIAMポリシーを添付してはならない
  • （３） IAMユーザーのアクセスキーは90日以内にローテーションする必要がある
  • （4） IAMルートユーザーアクセスキーは存在してはならない
  • （5）コンソールパスワードを持つすべてのIAMユーザーに対してMFAを有効にする必要がある
  • （6）ルートユーザーに対してハードウェアMFAを有効にする必要がある
  • （7） IAMユーザーのパスワードポリシーは強力な設定にする必要がある
  • （8）未使用のIAMユーザー認証情報は削除する必要がある
• Amazon S3
  • （9） S3ブロックパブリックアクセス設定を有効にする必要がある
  • （10） S3バケットではサーバーサイド暗号化が有効になっている必要がある
  • （11） S3ブロックパブリックアクセス設定はバケットレベルで有効にする必要がある
• AWS CloudTrail
  • （12） CloudTrailは、少なくとも1つのマルチリージョントレイルを有効にして設定する必要がある
  • （13） CloudTrailでは保存時の暗号化が有効になっている必要がある
  • （14） CloudTrailログファイルの検証が有効になっている必要がある
• AWS Config
  • （15） AWS Configを有効にする必要がある
• Amazon EC2
  • （16）接続されたEBSボリュームは保存時に暗号化する必要がある
  • （17） VPCフローログはすべてのVPCで有効にする必要がある
  • （18） VPCのデフォルトセキュリティグループは、インバウンドおよびアウトバウンドのトラフィックを許可しない
  • （19） EBSのデフォルト暗号化を有効にする必要がある
• AWS DMS
  • （20） AWSデータベース移行サービスのレプリケーションインスタンスは公開すべきではない
• Amazon EBS
  • （21） Amazon EBSスナップショットは公開すべきではない。誰でも復元できるかどうかで決まる。
• Amazon OpenSearch Service
  • （22） Elasticsearchドメインでは保存時の暗号化が有効になっている必要がある
• Amazon SageMaker
  • （23） SageMakerノートブックインスタンスはインターネットに直接アクセスできない
• AWS Lambda
  • （24） Lambda Lambdaはサポートされているランタイムを使用する必要がある
• AWS KMS
  • （25） AWS KMSキーは意図せず削除されてはならない
• Amazon GuardDuty
  • （26） GuardDutyを有効にする必要がある

解決すべき問題があり、ソリューションの構築とホスティングに AWS を選択しました。アカ​​ウントを設定し、設計、コーディング、構築、デプロイに取り掛かる準備は整いました。しかし、まだ早い段階です。

ソリューションが確実に機能し、安全で、信頼性が高く、パフォーマンスが高く、コスト効率に優れているようにするには、最初に取り組むべき重要な構成があります。これらに対処するのに最適な時期は、設計とエンジニアリングを開始する前の今です。最初からこれらの基盤を構築しておくと、長期的には大きな成果が得られます。

AWSの初期セットアップ

まず第一に、日常的なアクティビティにルートアカウントを使用しないでください。代わりに、Identity and Access Management (IAM) に移動して管理者ユーザーを作成してください。ルート認証情報は安全な場所に保存してください (パスワードは十分に強力ですか？)。ルートアカウントにアクセスキーが関連付けられている場合は、今すぐ削除してください。

また、ルート アカウントに対して多要素認証 (MFA) を有効にすることも重要です。その結果、MFA が有効でアクセス キーのないルートユーザーが作成されます。このアカウントは、絶対に必要な場合にのみ使用してください。

新しく作成した管理者アカウントでは、MFA を有効にすることが不可欠です。実際、セキュリティを第一に考えたいのであれば、アカウント内のすべてのユーザーに対して MFA を有効にすることが必須です (そうしたいはずです)。これはパワー ユーザーにとって特に重要です。このアカウントは管理目的にのみ使用する必要があることに注意してください。

日常的に使用する場合は、IAM パネルでユーザー、グループ、ロールを作成します。これらの ID は、最小権限の原則に従って、明示的に権限を付与したリソースにのみアクセスできるようにする必要があります。

この時点で、次のものが必要です。

• ルートアカウント: アクセス キーなしで安全にロックされます。
• 管理者アカウント: 管理タスク用のみに使用されます。
• ユーザー、グループ、およびロール: 日常的なアクティビティ用に設定され、それぞれに必要な権限のみが付与されます。

すべてのアカウントでMFA が有効になっており、強力なパスワードが強制されていることを確認してください。AWS セキュリティのベストプラクティスを実装する準備はほぼ整いましたが、先に進む前に、 AWS 責任共有モデルについて少し理解しておきましょう。このモデルは、AWS が処理するセキュリティタスクと、顧客であるお客様が責任を負うセキュリティタスクを明確にします。AWS 環境のセキュリティ保護を進めていく上で、この違いを理解しておくことは非常に重要です。

AWS 責任共有モデル

セキュリティとコンプライアンスは、AWS とお客様の共同責任です。AWS は、ホストオペレーティングシステム、仮想化レイヤー、データセンターの物理的セキュリティなどのインフラストラクチャーを管理およびコントロールします。

お客様は、ゲストオペレーティングシステム(アップデートとセキュリティパッチを含む)、関連するアプリケーションソフトウェア、およびセキュリティグループやファイアウォールなどのAWS セキュリティ機能の設定を管理する責任があります。

つまり、AWS は安全な基盤を提供しますが、環境内での徹底したセキュリティ対策の管理と適用は完全にお客様の責任となります。

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

このセクションでは、最も一般的に使用されている AWS サービスのいくつかについて説明し、安全でコンプライアンスに準拠したクラウド環境を確保するために採用すべき26 のセキュリティのベストプラクティスを紹介します。

Sysdig Secure は、Sysdig の Cloud Native Application Protection Platform (CNAPP) の一部であり、AWS 環境のセキュリティとコンプライアンスの確保に役立ちます。包括的な CNAPP ツールとして、Sysdig Secure はクラウド構成を評価し、潜在的な構成ミスやセキュリティリスクを検出します。また、特定のコンプライアンス要件に合わせたカスタムポスチャーコントロールを作成できるため、構成の問題を高度にカスタマイズして検出できます。さらに、Sysdig Secure は AWS CloudTrail ログを継続的に監視し、疑わしいアクティビティ、不正な構成変更、潜在的な脅威をリアルタイムで検出します。

この記事の残りの部分では、Sysdig Secure のカスタムコントロール機能を活用して、AWS アカウントのセキュリティを強化します。特に、ここで示すすべてのコントロールは、Sysdig Secure ですぐに使用できる状態で提供されます。カスタムコントロールの作成の詳細については、 Sysdig ブログのカスタマイズされたポスチャポリシーの実装に関する詳細なガイドをご覧ください。

この記事で紹介するすべてのコントロールは、Sysdig Secure ですぐに使用できる状態で既に提供されています。

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

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

AWS Identity and Access Management (IAM) は、 AWS リソースへの最小権限アクセス制御を実施するのに役立ちます。IAM を使用すると、リソースを使用するために認証 (サインイン) および承認 (アクセス許可を持つ) されるユーザーを制限できます。

1.- IAM ポリシーでフルの” * “管理者権限を許可しない 🟥

Sysdig Secure でフルの管理者権限の使用を検出する場合は、Terraform Sysdig プロバイダーを使用して定義できるカスタムコントロールを次に示します。

terraform {
  required_providers {
    sysdig = {
      source = "sysdiglabs/sysdig"
      version = ">=0.5"
    }
  }
}

provider "sysdig" {
  sysdig_secure_url="https://secure.sysdig.com"
}

resource "sysdig_secure_posture_control" "no_full_administrative_privileges_policies" {
  name = "IAM - No Full Administrative Privileges Policies"
  description = "It's more secure to start with a minimum set of permissions and grant additional permissions as necessary, rather than starting with permissions that are too lenient and then trying to tighten them later. Providing full administrative privileges instead of restricting to the minimum set of permissions that the user is required to do exposes the resources to potentially unwanted actions. IAM policies that have a statement with "Effect": "Allow" with "Action": "\*" over "Resource": "\*" should be removed."
  resource_kind = "AWS_POLICY"
  severity = "High"
  rego = <<-EOF
    package sysdig

    import future.keywords.if
    import future.keywords.in

    default risky := false

    risky if {
	input.AttachmentCount > 0
	document := json.unmarshal(input.VersionDocument)
	some stmt in document.Statement
	stmt.Effect == "Allow"
	stmt.Resource == "*"
	stmt.Action == "*"
    }
  EOF
  remediation_details = <<-EOF
    **From Console**: Perform the following to detach the policy that has full administrative privileges:

    1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
    2. In the navigation pane, click Policies and then search for the policy name found in the audit step.
    3. Select the policy that needs to be deleted.
    4. In the policy action menu, select first Detach
    5. Select all Users, Groups, Roles that have this policy attached
    6. Click Detach Policy
    7. In the policy action menu, select Detach
    8. Select the newly detached policy and select Delete
  EOF
}

前のコマンドは、ポリシーのリストとその Amazon リソースネーム (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 リソースへのアクセス権がありません。

IAM ポリシーは、ユーザー、グループ、またはロールに権限を付与します。IAM ポリシーは、ユーザーではなく、グループとロールに直接適用することをお勧めします。グループまたはロール レベルで権限を割り当てると、ユーザー数が増えてもアクセス管理の複雑さが軽減されます。アクセス管理の複雑さが軽減されると、プリンシパルが誤って過剰な権限を受け取ったり保持したりする可能性も減ります。

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

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

まず、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 ルートユーザーアクセスキーが存在しないことを確認する 🟥

次のカスタム コントロールは、アカウントでルートアクセス キーが使用されているかどうかを確認します。

terraform {
  required_providers {
    sysdig = {
      source = "sysdiglabs/sysdig"
      version = ">=0.5"
    }
  }
}

provider "sysdig" {
  sysdig_secure_url="https://secure.sysdig.com"
}

resource "sysdig_secure_posture_control" "disabled_root_access_keys" {
  name = "IAM - Disabled Root Access Keys"
  description = "Removing access keys associated with the 'root' user account limits vectors by which the account can be compromised. Additionally, removing the root access keys encourages the creation and use of role based accounts that are least privileged."
  resource_kind = "AWS_ROOT_USER"
  severity = "High"
  rego = <<-EOF
    package sysdig

    import future.keywords.if

    default risky := false

    risky if {
	input.Report.accessKey1Active == true
    }

    risky if {
	input.Report.accessKey2Active == true
    }
  EOF
  remediation_details = <<-EOF
    **From Console**: Perform the following to delete or disable active root user access keys:

    1. Sign in to the AWS Management Console as root and open the IAM console at https://console.aws.amazon.com/iam/.
    2. Click on <Root\_Account\_Name> at the top right and select My Security Credentials from the drop down list.
    3. On the pop out screen Click on Continue to Security Credentials.
    4. Click on Access Keys (Access Key ID and Secret Access Key).
    5. Under the Status column if there are any Keys which are Active.
    5. Click on Make Inactive - (Temporarily disable Key - may be needed again).
    6. Click Delete - (Deleted keys cannot be recovered).
  EOF
}

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

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

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

さらにセキュリティの層を追加したい場合は、MFA を使用してログインを監視し、スパムを検出することをお勧めします。AWS セキュリティのベストプラクティスをさらに見ていきましょう。

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

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

詳細については、IAM ユーザーガイドの「仮想多要素認証 (MFA) デバイスの有効化 (コンソール)」を参照してください。

ルートハードウェア MFA の欠如を検出するためのカスタム コントロールを次に示します。

terraform {
  required_providers {
    sysdig = {
      source = "sysdiglabs/sysdig"
      version = ">=0.5"
    }
  }
}

provider "sysdig" {
  sysdig_secure_url="https://secure.sysdig.com"
}

resource "sysdig_secure_posture_control" "defined_root_hardware_mfa" {
  name = "IAM - Defined Root Hardware MFA"
  description = "A hardware MFA has a smaller attack surface than a virtual MFA. For example, a hardware MFA does not suffer the attack surface introduced by the mobile smartphone on which a virtual MFA resides. **Note**: Using hardware MFA for many, many AWS accounts may create a logistical device management issue. If this is the case, consider implementing this Level 2 recommendation selectively to the highest security AWS accounts and the Level 1 recommendation applied to the remaining accounts."
  resource_kind = "AWS_ROOT_USER"
  severity = "Medium"
  rego = <<-EOF
    package sysdig

    import future.keywords.if

    default risky := false

    risky if {
	not input.AccountSummary.AccountMFAEnabled
    }

    risky if {
	not input.AccountSummary.AccountMFAEnabled == 1
    }

    risky if {
	input.AccountSummary.AccountMFAEnabled == 1
	not input.VirtualMfaSerialNumber
    }

    risky if {
	input.AccountSummary.AccountMFAEnabled == 1
	not input.VirtualMfaSerialNumber == ""
    }
  EOF
  remediation_details = <<-EOF
    **From Console**: Perform the following to establish a hardware MFA for the root user account:

    1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.

    **Note**: To manage MFA devices for the AWS root user account, you must use your root account credentials to sign in to AWS. You cannot manage MFA devices for the root account using other credentials.

    2. Choose Dashboard, and under Security Status, expand Activate MFA on your root account.
    3. Choose Activate MFA.
    4. In the wizard, choose A hardware MFA device and then choose Next Step.
    5. In the Serial Number box, enter the serial number that is found on the back of the MFA device.
    6. In the Authentication Code 1 box, enter the six-digit number displayed by the MFA device. You might need to press the button on the front of the device to display the number.
    7. Wait 30 seconds while the device refreshes the code, and then enter the next six-digit number into the Authentication Code 2 box. You might need to press the button on the front of the device again to display the second number.
    8. Choose Next Step. The MFA device is now associated with the AWS account. The next time you use your AWS account credentials to sign in, you must type a code from the hardware MFA device.

Remediation for this recommendation is not available through AWS CLI.
  EOF
}

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

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

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

強力なパスワードの条件は主観的なものですが、以下の設定を採用することで正しい方向へ進むことができます：

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

8.- 未使用の IAM ユーザー認証情報を削除する 🟨

IAM ユーザーは、パスワードやアクセスキーなど、さまざまな種類の認証情報を使用して AWS リソースにアクセスできます。侵害されたアカウントや放棄されたアカウントに関連付けられた認証情報が使用される機会を減らすために、90 日以上使用されていないすべての認証情報を削除または非アクティブ化することをお勧めします。

IAM コンソールを使用して、アカウントの期限切れの認証情報を監視するのに必要な情報の一部を取得できます。たとえば、アカウント内のユーザーを表示すると、アクセスキーの有効期間、パスワードの有効期間、および最終アクティビティの列があります。これらの列のいずれかの値が 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 ビットの Advanced Encryption Standard (AES-256) を使用します。

AWS アカウントで利用可能な既存の S3 バケットをすべて一覧表示します。

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

ここで、前の手順で返された S3 バケットの名前を識別子として使用して、デフォルトの暗号化機能のステータスを取得します。

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 パブリック アクセスブロック機能を設定する必要があります。

このカスタムコントロールを使用して、パブリックにアクセス可能な S3 バケットを検出できます。

terraform {
  required_providers {
    sysdig = {
      source = "sysdiglabs/sysdig"
      version = ">=0.5"
    }
  }
}

provider "sysdig" {
  sysdig_secure_url="https://secure.sysdig.com"
}

resource "sysdig_secure_posture_control" "bucket_public_access_block" {
  name = "S3 - Blocked Public Access (Bucket-wise)"
  description = "Amazon S3 `Block public access (bucket settings)` prevents the accidental or malicious public exposure of data contained within the respective bucket(s). Amazon S3 `Block public access (account settings)` prevents the accidental or malicious public exposure of data contained within all buckets of the respective AWS account. Whether blocking public access to all or some buckets is an organizational decision that should be based on data sensitivity, least privilege, and use case."
  resource_kind = "AWS_S3_BUCKET"
  severity = "High"
  rego = <<-EOF
    package sysdig

    import future.keywords.if

    default risky := false

    risky if {
	not input.PublicAccessBlock[0].BlockPublicAcls
    }

    risky if {
	not input.PublicAccessBlock[0].BlockPublicPolicy
    }

    risky if {
	not input.PublicAccessBlock[0].IgnorePublicAcls
    }

    risky if {
	not input.PublicAccessBlock[0].RestrictPublicBuckets
    }
  EOF
  remediation_details = <<-EOF
    ## Remediation Impact
    When you apply Block Public Access settings to an account, the settings apply to all AWS Regions globally. The settings might not take effect in all Regions immediately or simultaneously, but they eventually propagate to all Regions.

    ## If utilizing Block Public Access (bucket settings)
    **Remediate Using AWS Console**:
    1. Login to AWS Management Console and open the Amazon S3 console using https://console.aws.amazon.com/s3/.
    2. Select the Check box next to the Bucket.
    3. Click on Edit public access settings.
    4. Click Block all public access.
    5. Repeat for all the buckets in your AWS account that contain sensitive data.
  EOF
}

AWS CloudTrail

AWS セキュリティのベストプラクティスでは、脅威を検出する際に IAM に次いで考慮すべき最も重要なサービスは CloudTrail です。

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

イベントには、AWS マネジメントコンソール、AWS コマンドラインインターフェース、AWS SDK および API で実行されたアクションが含まれます。CloudTrailと CloudWatchの違いをご覧ください。

次のセクションでは、すべてのリージョンにわたってインフラストラクチャーを監視するように CloudTrail を構成する方法について説明します。

12.- 少なくとも 1 つのマルチリージョン Trailを使用して CloudTrail を有効にする 🟥

CloudTrail は、AWS マネジメントコンソール、AWS SDK、コマンドラインツールから行われた API 呼び出しなど、アカウントの AWS API 呼び出しの履歴を提供します。履歴には、AWS CloudFormation などの上位レベルの AWS サービスからの API 呼び出しも含まれます。

CloudTrail によって生成されるAWS API コール履歴により、セキュリティ分析、リソース変更の追跡、コンプライアンス監査が可能になります。マルチリージョンの証跡には、次のような利点もあります。

• マルチリージョンTrailは、使用されていないリージョンで発生する予期しないアクティビティを検出するのに役立ちます。
• マルチリージョンTrailでは、証跡に対してグローバル サービスイベント ログがデフォルトで有効になります。グローバルサービスイベント ログには、AWS グローバル サービスによって生成されたイベントが記録されます。
• マルチリージョンTrailの場合、すべての読み取りおよび書き込み操作の管理イベントにより、CloudTrail は AWS アカウントのすべてのリソースに対する管理操作を記録するようになります。

デフォルトでは、AWS マネジメントコンソールを使用して作成された CloudTrail 証跡は、マルチリージョンTrailです。

選択した AWS リージョンで利用可能なすべてのTrailを一覧表示します。

aws cloudtrail describe-trails

出力には、各 AWS CloudTrail Trailとその構成の詳細が表示されます。configIsMultiRegionTrailパラメータ値が 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 つがマルチリージョンであることを確認します。

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

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

KmsKeyIdが定義されている場合、チェックは成功します。機密性の高い CloudTrail ログファイルのセキュリティを強化するには、保存時の暗号化に AWS KMS 管理キー (SSE-KMS) を使用したサーバーサイド暗号化を CloudTrail ログファイルに使用してください。デフォルトでは、CloudTrail によってバケットに配信されるログファイルは、Amazon S3 管理暗号化キー (SSE-S3) を使用した Amazon サーバーサイド暗号化によって暗号化されることに注意してください。

次のカスタム コントロールを使用して、ログが暗号化されていることを確認できます。

terraform {
  required_providers {
    sysdig = {
      source = "sysdiglabs/sysdig"
      version = ">=0.5"
    }
  }
}

provider "sysdig" {
  sysdig_secure_url="https://secure.sysdig.com"
}

resource "sysdig_secure_posture_control" "enabled_trail_log_file_encryption" {
  name = "Logging - Enabled Trail Log File Encryption"
  description = "Configuring CloudTrail to use SSE-KMS provides additional confidentiality controls on log data as a given user must have S3 read permission on the corresponding log bucket and must be granted decrypt permission by the CMK policy."
  resource_kind = "AWS_CLOUD_TRAIL"
  severity = "Medium"
  rego = <<-EOF
    package sysdig

    import future.keywords.if

    default risky := false

    risky if {
	not is_valid
    }

    is_valid if {
	input.KmsKeyId
	input.KmsKeyId != null
	input.KmsKeyId != ""
    }
  EOF
  remediation_details = <<-EOF
    ## Remediation Impact
    Customer created keys incur an additional cost. See https://aws.amazon.com/kms/pricing/ for more information.

    ## Remediate Using AWS Console
    Perform the following to configure CloudTrail to use SSE-KMS:

    1. Sign in to the AWS Management Console and open the CloudTrail console at https://console.aws.amazon.com/cloudtrail.
    2. In the left navigation pane, choose Trails .
    3. Click on a Trail.
    4. Under the S3 section click on the edit button (pencil icon).
    5. Click Advanced.
    6. Select an existing CMK from the KMS key Id drop-down menu.

    **Note**: Ensure the CMK is located in the same region as the S3 bucket.

    **Note**: You will need to apply a KMS Key policy on the selected CMK in order for CloudTrail as a service to encrypt and decrypt log files using the CMK provided. Steps are provided here for editing the selected CMK Key policy.

    7. Click Save.
    8. You will see a notification message stating that you need to have decrypt permissions on the specified KMS key to decrypt log files.
    9. Click Yes.

    ## Remediate Using Command Line
    Perform the following to configure CloudTrail to use SSE-KMS:

    ```
    aws cloudtrail update-trail --name <trail_name> --kms-id <cloudtrail_kms_key>
    aws kms put-key-policy --key-id <cloudtrail_kms_key> --policy <cloudtrail_kms_key_policy> 
    ```
  EOF
}

次のように AWS コンソールを使用して修正できます。

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

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

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

すべてのTrailでファイル検証を有効にすることをお勧めします。ログ ファイルの検証により、CloudTrail ログの整合性チェックがさらに強化されます。

AWS コンソールでこれを確認するには、次の手順に従います。

1. https://console.aws.amazon.com/cloudtrail/で AWS マネジメントコンソールにサインインします。
2. 左側のナビゲーション パネルで、[Trails]を選択します。
3. 「Name」列で、調べる必要があるトレイル名を選択します。
4. S3セクションで、ログ ファイルの検証ステータスを有効にするかどうかを確認します。
5. ログ ファイルの検証ステータスを有効にします。機能のステータスが[No]に設定されている場合、選択したTrailではログ ファイルの整合性検証が有効になっていません。この場合、修正します。
   1. Trail バケットの設定を編集するには、S3セクションの横にある鉛筆アイコンをクリックします。
   2. S3 バケット*の下の[Advanced]をクリックし、[Enable log file validation]構成ステータスを検索します。
   3. ログ ファイルの検証を有効にするには[Yes]を選択し、[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. https://console.aws.amazon.com/config/で AWS Config コンソールを開きます。
2. AWS Config を設定するリージョンを選択します。
3. これまで AWS Config を使用したことがない場合は、AWS Config 開発者ガイドの「Getting Started」を参照してください。
4. メニューから設定ページに移動し、次の操作を行います。
   1. 編集を選択します。
   2. 記録するリソースの種類で、このリージョンでサポートされているすべてのリソースを記録すると、グローバルリソース (AWS IAM リソースなど) を含めるを選択します。
   3. 「データ保持期間」で、AWS Config データのデフォルトの保持期間を選択するか、カスタム保持期間を指定します。
   4. AWS Config ロールで、AWS Config サービスにリンクされたロールの作成を選択するか、アカウントからロールを選択を選択して、使用するロールを選択します。
   5. Amazon S3 バケットで、使用するバケットを指定するか、バケットを作成し、オプションでプレフィックスを含めます。
   6. Amazon SNS トピックで、アカウントから Amazon SNS トピックを選択するか、トピックを作成します。Amazon SNS の詳細については、Amazon Simple Notification Service 入門ガイドを参照してください。
5. [Save]を選択します。

さらに詳しく知るには、AWS Config の AWS セキュリティのベストプラクティスに従ってください。

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 アドレス フローのさまざまなコンポーネントの値が含まれます。

terraform {
  required_providers {
    sysdig = {
      source = "sysdiglabs/sysdig"
      version = ">=0.5"
    }
  }
}

provider "sysdig" {
  sysdig_secure_url="https://secure.sysdig.com"
}

resource "sysdig_secure_posture_control" "enabled_vpc_flow_logs" {
  name = "Logging - Enabled VPCs Flow Logs"
  description = "VPC Flow Logs provide visibility into network traffic that traverses the VPC and can be used to detect anomalous traffic or insight during security workflows."
  resource_kind = "AWS_CLOUD_TRAIL"
  severity = "Low"
  rego = <<-EOF
    package sysdig

    import future.keywords.if
    import future.keywords.in

    default risky := false

    risky if {
	not is_valid
    }

    is_valid if {
	some f in input.FlowLogs
	f.FlowLogStatus == "ACTIVE"
    }
  EOF
  remediation_details = <<-EOF
    ## Remediation Impact
    By default, CloudWatch Logs will store Logs indefinitely unless a specific retention period is defined for the log group. When choosing the number of days to retain, keep in mind the average number of days it takes an organization to realize they have been breached is 210 days (at the time of this writing). Since additional time is required to research a breach, a minimum 365 day retention policy allows time for detection and research. You may also wish to archive the logs to a cheaper storage service rather than simply deleting them. See the following AWS resource to manage CloudWatch Logs retention periods:

    https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html

    ## Remediate Using AWS Console
    Perform the following to determine if VPC Flow logs is enabled:

    1. Sign into the management console.
    2. Select Services then VPC.
    3. In the left navigation pane, select Your VPCs.
    4. Select a VPC.
    5. In the right pane, select the Flow Logs tab.
    6. If no Flow Log exists, click Create Flow Log.
    7. For Filter, select Reject.
    8. Enter in a Role and Destination Log Group.
    9. Click Create Log Flow.
    10. Click on CloudWatch Logs Group.

    **Note**: Setting the filter to Reject will dramatically reduce the logging data accumulation for this recommendation and provide sufficient information for the purposes of breach detection, research and remediation. However, during periods of least privilege security group engineering, setting this the filter to All can be very helpful in discovering existing traffic flows required for proper operation of an already running environment.
  EOF
}

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 ユーザーガイド（Linuxインスタンス向け）の「デフォルトでの暗号化」を参照してください。

なお、以下のインスタンスタイプは暗号化をサポートしていません：R1、C1、M1。

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

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

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

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

AWS データベース移行サービス (DMS)

AWS Database Migration Service (AWS DMS) は、リレーショナルデータベース、データウェアハウス、NoSQL データベース、その他の種類のデータストアの移行を容易にするクラウド サービスです。AWS DMS を使用すると、データを AWS クラウドに移行したり、クラウドとオンプレミスの組み合わせ間で移行したりできます。

20.- AWS Database Migration Service レプリケーションインスタンスがパブリックではないことを確認する 🟥

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

1. https://console.aws.amazon.com/dms/で AWS マネジメントコンソールにサインインします。
2. 左側のナビゲーション パネルで、[Replication instances]を選択します。
3. 調べる DMS レプリケーション インスタンスを選択して、リソース構成の詳細を含むパネルを開きます。
4. ダッシュボードの下部パネルから[Overview]タブを選択し、 [Publicly accessible] 属性値を確認します。属性値が[Yes]に設定されている場合、選択した Amazon DMS レプリケーションインスタンスは Virtual Private Cloud (VPC) の外部からアクセス可能であり、セキュリティリスクにさらされる可能性があります。これを修正するには、次の手順を実行します。
   1. ダッシュボードのトップメニューから「Create replication instance 」ボタンをクリックして、プロセスを開始します。
   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. [Delete replication instance]ダイアログ ボックスでインスタンスの詳細を確認し、[Delete]をクリックして選択した DMS リソースを終了します。
5. 選択したリージョンにプロビジョニングされた AWS DMS レプリケーションインスタンスごとに、手順 3 と 4 を繰り返します。
6. コンソールのナビゲーション バーからリージョンを変更し、他のすべてのリージョンに対してこのプロセスを繰り返します。

AWS Database Migration Service の AWS セキュリティのベストプラクティスの詳細をご覧ください。

Amazon Elastic Block Store (EBS)

Amazon Elastic Block Store (Amazon EBS) は、EC2 インスタンスで使用するためのブロックレベルのストレージボリュームを提供します。EBS ボリュームは、未フォーマットの未処理ブロック デバイスのように動作します。これらのボリュームは、インスタンスにデバイスとしてマウントできます。インスタンスにアタッチされた 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 ドメインで保存時の暗号化が有効になっていることを確認する 🟥

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ドメインで保存データの暗号化が有効になっていません。以下のコマンドを使用して修正してください。

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 ノートブックインスタンスがインターネットの直接アクセスできないことを確認する 🟨

SageMaker インスタンスを VPC なしで設定すると、デフォルトでインスタンスで直接インターネットアクセスが有効になります。インスタンスを VPC で設定し、デフォルト設定を [無効 – VPC 経由でインターネットにアクセス] に変更する必要があります。

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

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

1. https://console.aws.amazon.com/sagemaker/で AWS マネジメントコンソールにサインインします。
2. ナビゲーション パネルの[Notebook]で、[Notebook instances]を選択します。
3. 調べたい SageMaker ノートブックインスタンスを選択し、インスタンス名 (リンク) をクリックします。
4. 選択したインスタンスの設定ページで、ネットワークセクション内にVPCサブネットIDやセキュリティグループIDがあるか確認してください。これらのネットワーク設定が存在しない場合、次のようなステータスが表示されます：No custom VPC settings applied（カスタムVPC設定が適用されていません）。この場合、ノートブックインスタンスはVPCネットワーク内で実行されていないため、このコンプライアンスルールで説明されている手順に従い、VPC内でインスタンスをデプロイすることができます。一方、ノートブックインスタンスがVPC内で実行されている場合は、Direct internet access（直接インターネットアクセス）の設定属性値を確認してください。この属性値がEnabledに設定されている場合、選択したAmazon SageMakerノートブックインスタンスはパブリックにアクセス可能です。
5. ノートブックで直接インターネット アクセスが有効になっている場合は、次の 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設定が、各言語でサポートされているランタイムに設定された期待値と一致していることを確認することを推奨しています。このコントロールは、次のランタイムの関数設定をチェックします: 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 ルールは、パッケージタイプがイメージであるFunctionを無視します。

Lambda ランタイムは、メンテナンスとセキュリティ更新の対象となるオペレーティングシステム、プログラミング言語、ソフトウェアライブラリの組み合わせに基づいて構築されています。ランタイムコンポーネントがセキュリティ更新でサポートされなくなると、Lambda はランタイムを廃止します。廃止されたランタイムを使用する関数を作成することはできませんが、その関数は呼び出しイベントを処理するために引き続き使用できます。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 を一覧表示します。検出器は、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 Foundational Security Best Practices、AWS Well-Architected Framework、CIS Amazon Elastic Kubernetes Service（EKS）Benchmarkといった基準を活用して、定期的にポリシーチェックを行うことが有益です。これらの監査により、環境を確認し、AWSセキュリティのベストプラクティスに反している箇所を特定し、進化するセキュリティニーズに対応し続けることができます。

まとめ

完全にクラウドへ移行することは多くの機会を生み出しますが、同時に幅広い攻撃ベクトルをもたらします。採用する各AWSサービスには固有のセキュリティリスクが伴い、それらには注意深い管理と積極的な対応が必要です。

幸いなことに、Sysdig Secureのようなクラウドネイティブのセキュリティツールが、このプロセスをサポートしてくれます。これらのツールは、ベストプラクティスに関するガイダンスを提供し、コンプライアンス基準を満たす手助けをし、AWSセキュリティのベストプラクティスに沿った運用を実現することで、クラウドリスクを自信を持って効果的に管理できるよう支援します。

---

これらすべてのサービスを構成および管理する方法を知りたい場合は、Sysdig がクラウド セキュリティ ポスチャー管理 (CSPM) の改善をお手伝いします。次のリソースでさらに詳しく調べてください。

• Sysdig Secure による AWS セキュリティ サービスの改善
• Sysdig で Amazon EC2 を保護する方法
• Sysdig で AWS Route 53 を保護する方法
• Sysdig による AWS RDS セキュリティ イベントの追跡
• Amazon GuardDuty と Sysdig によるマルウェアの検出