[概要]前提条件と制限アーキテクチャツールエピックトラブルシューティング関連リソース

AWS CloudFormation Guard ポリシーを使用して AWS Config カスタムルールを作成する

作成者: Andrew Lok (AWS)、Kailash Havildar (AWS)、Nicole"" (AWS)、Tanya Howell (AWS)

コードリポジトリ: aws-config-custom-rule-cloudformation-guard	環境：PoC またはパイロット	テクノロジー: セキュリティ、アイデンティティ、コンプライアンス、管理とガバナンス
AWS サービス: AWS CloudFormation、AWS Config

[概要]

AWS Config ルールは、 AWS リソースとそのターゲット設定の状態を評価するのに役立ちます。ルールには、マネージドルールとカスタム AWS Config ルールの 2 種類があります。は、関数 AWS Lambda または policy-as-code 言語 AWS CloudFormation Guard (GitHub) を使用してカスタムルールを作成できます。

Guard で作成されたルールは、マネージドルールよりもきめ細かな制御を提供し、通常、完全にカスタムの Lambda ルールよりも設定が容易です。このアプローチにより、エンジニアやアーキテクトは、Lambda を介してカスタムルールをデプロイするために必要な Python、NodeJS、または Java を知らなくてもルールを構築できます。

このパターンは、Guard でカスタムルールを採用するのに役立つ、実用的なテンプレート、コードサンプル、デプロイアプローチを提供します。このパターンを使用すると、管理者は AWS Config を使用して、設定項目属性を持つカスタムコンプライアンスルールを構築できます。例えば、デベロッパーは AWS Config 設定項目に対して Guard ポリシーを使用して、デプロイされたAWS リソース AWS とリソース以外のの状態を継続的にモニタリングし、ルール違反を検出して、修復を自動的に開始できます。

目的

このパターンを読み終えると、次のことができるようになります。

Guard ポリシーコードが AWS Config サービスとどのように相互作用するかを理解します。
シナリオ 1 をデプロイします。シナリオ 1 は、Guard 構文を使用して暗号化されたボリュームのコンプライアンスを検証する AWS Config カスタムルールです。このルールは、ドライブが使用中であることを確認し、ドライブタイプが gp3 であることを確認します。
シナリオ 2 をデプロイします。シナリオ 2 は、Guard 構文を使用して Amazon GuardDuty コンプライアンスを検証する AWS Config カスタムルールです。このルールは、 GuardDuty レコーダーで Amazon Simple Storage Service (Amazon S3) Protection と Amazon Elastic Kubernetes Service (Amazon EKS) Protection が有効になっていることを確認します。

前提条件と制限

前提条件

アクティブな AWS アカウント
AWS Configでをセットアップする AWS アカウント

制約事項

ガードカスタムルールは、ターゲット設定項目の JSON レコード内のキーと値のペアのみをクエリできます。

アーキテクチャ

Guard 構文をカスタム policy. AWS Config captures として AWS Config ルールに適用します。指定された各リソースの階層 JSON。 AWS Config 設定項目の JSON には、キーと値のペアが含まれます。これらの属性は、対応する値に割り当てられた変数として Guard 構文で使用されます。

以下は、Guard 構文の説明です。設定項目 JSON の変数が使用され、先頭に%文字が付加されます。


# declare variable
let <variable name> = <'value'>

# create rule and assign condition and policy
    rule <rule name> when 
        <CI json key> == <"CI json value"> {
            <top level CI json key>.<next level CI json key> == %<variable name>
        }

シナリオ 1: Amazon EBS ボリューム

シナリオ 1 は、Guard 構文を使用して暗号化されたボリュームのコンプライアンスを検証する AWS Config カスタムルールをデプロイします。このルールは、ドライブが使用中であることを確認し、ドライブタイプが gp3 であることを確認します。

シナリオ 1 AWS Config の設定項目の例を次に示します。この設定項目には、、volumestatus、およびの変数としてを使用した 3 つのキーvolumeencryptionstatusと値のペアがありますvolumetype。また、resourceTypeキーは Guard ポリシーのフィルターとして使用されます。


{
  "version": "1.3",
  "accountId": "111111111111",
  "configurationItemCaptureTime": "2023-01-15T19:04:45.402Z",
  "configurationItemStatus": "ResourceDiscovered",
  "configurationStateId": "4444444444444",
  "configurationItemMD5Hash": "",
  "arn": "arn:aws:ec2:us-west-2:111111111111:volume/vol-222222222222",
  "resourceType": "AWS::EC2::Volume",
  "resourceId": "vol-222222222222",
  "awsRegion": "us-west-2",
  "availabilityZone": "us-west-2b",
  "resourceCreationTime": "2023-01-15T19:03:22.247Z",
  "tags": {},
  "relatedEvents": [],
  "relationships": [
    {
      "resourceType": "AWS::EC2::Instance",
      "resourceId": "i-33333333333333333",
      "relationshipName": "Is attached to Instance"
    }
  ],
  "configuration": {
    "attachments": [
      {
        "attachTime": "2023-01-15T19:03:22.000Z",
        "device": "/dev/xvda",
        "instanceId": "i-33333333333333333",
        "state": "attached",
        "volumeId": "vol-222222222222",
        "deleteOnTermination": true,
        "associatedResource": null,
        "instanceOwningService": null
      }
    ],
    "availabilityZone": "us-west-2b",
    "createTime": "2023-01-15T19:03:22.247Z",
    "encrypted": false,
    "kmsKeyId": null,
    "outpostArn": null,
    "size": 8,
    "snapshotId": "snap-55555555555555555",
    "state": "in-use",
    "volumeId": "vol-222222222222",
    "iops": 100,
    "tags": [],
    "volumeType": "gp2",
    "fastRestored": null,
    "multiAttachEnabled": false,
    "throughput": null,
    "sseType": null
  },
  "supplementaryConfiguration": {}
}

以下は、シナリオ 1 で Guard 構文を使用して変数とルールを定義する例です。以下の例で、次の操作を行います。

最初の 3 行は、 let コマンドを使用して変数を定義します。これらは、設定項目の属性から派生した名前と値が割り当てられます。
compliancecheck ルールブロックは、に一致するresourceTypeキーと値のペアを検索する条件依存関係にを追加しますAWS::EC2::Volume。一致が見つかった場合、ルールは残りの JSON 属性を通過しstate、、encrypted、の 3 つの条件で一致を検索しますvolumeType。


let volumestatus = 'available'
let volumetype = 'gp3'
let volumeencryptionstatus = true

    rule compliancecheck when 
        resourceType == "AWS::EC2::Volume" {
            configuration.state == %volumestatus
            configuration.encrypted == %volumeencryptionstatus
            configuration.volumeType == %volumetype
        }

このカスタムルールを実装する完全な Guard カスタムポリシーについては、 GitHub コードリポジトリのawsconfig-guard-cft「.yaml」またはawsconfig-guard-tf-ec「2vol.json」を参照してください。このカスタムポリシーを Guard にデプロイする HashiCorp Terraform コードについては、コードリポジトリのawsconfig-guard-tf-example「.json」を参照してください。

シナリオ 2: GuardDuty コンプライアンス

シナリオ 2 では、Guard 構文を使用して Amazon GuardDuty コンプライアンスを検証する AWS Config カスタムルールをデプロイします。このルールは、 GuardDuty レコーダーで Amazon S3 Protection と Amazon EKS Protection が有効になっていることを確認します。また、 GuardDuty 検出結果が 15 分ごとに公開されることを確認します。このシナリオは、すべての AWS アカウントと組織 ( 内) AWS リージョンにデプロイできます AWS Organizations。

シナリオ 2 AWS Config の設定項目の例を次に示します。この設定項目には、Guard ポリシーで変数としてを使用した FindingPublishingFrequency、、の 3 つのキーS3Logsと値のペアがありますKubernetes。また、resourceTypeキーはポリシーのフィルターとして使用されます。


{
  "version": "1.3",
  "accountId": "111111111111",
  "configurationItemCaptureTime": "2023-11-27T13:34:28.888Z",
  "configurationItemStatus": "OK",
  "configurationStateId": "7777777777777",
  "configurationItemMD5Hash": "",
  "arn": "arn:aws:guardduty:us-west-2:111111111111:detector/66666666666666666666666666666666",
  "resourceType": "AWS::GuardDuty::Detector",
  "resourceId": "66666666666666666666666666666666",
  "resourceName": "66666666666666666666666666666666",
  "awsRegion": "us-west-2",
  "availabilityZone": "Regional",
  "resourceCreationTime": "2020-02-17T02:48:04.511Z",
  "tags": {},
  "relatedEvents": [],
  "relationships": [],
  "configuration": {
    "Enable": true,
    "FindingPublishingFrequency": "FIFTEEN_MINUTES",
    "DataSources": {
      "S3Logs": {
        "Enable": true
      },
      "Kubernetes": {
        "AuditLogs": {
          "Enable": true
        }
      }
    },
    
    "Id": "66666666666666666666666666666666",
    "Tags": []
  },
  "supplementaryConfiguration": {
    "CreatedAt": "2020-02-17T02:48:04.511Z"
  }
}

以下は、シナリオ 2 で Guard 構文を使用して変数とルールを定義する例です。以下の例で、次の操作を行います。

最初の 3 行は、 let コマンドを使用して変数を定義します。これらは、設定項目の属性から派生した名前と値が割り当てられます。
compliancecheck ルールブロックは、に一致するresourceTypeキーと値のペアを検索する条件依存関係にを追加しますAWS::GuardDuty::Detector。一致が見つかった場合、ルールは残りの JSON 属性を通過しS3Logs.Enable、、Kubernetes.AuditLogs.Enable、の 3 つの条件で一致を検索しますFindingPublishingFrequency。


let s3protection = true
let kubernetesprotection = true
let publishfrequency = 'FIFTEEN_MINUTES'

    rule compliancecheck when 
        resourceType == "AWS::GuardDuty::Detector" {
            configuration.DataSources.S3Logs.Enable == %s3protection
            configuration.DataSources.Kubernetes.AuditLogs.Enable == %kubernetesprotection
            configuration.FindingPublishingFrequency == %publishfrequency
        }

このカスタムルールを実装する完全な Guard カスタムポリシーについては、 GitHub コードリポジトリのawsconfig-guard-cft-gd「.yaml」を参照してください。このカスタムポリシーを Guard にデプロイする HashiCorp Terraform コードについては、コードリポジトリのawsconfig-guard-tf-gd「.json」を参照してください。

ツール

AWS サービス

AWS CloudFormation は、 AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、 AWS アカウントおよびリージョン全体でライフサイクル全体を通じてリソースを管理するのに役立ちます。
AWS Config は、内のリソース AWS アカウントとその設定方法の詳細ビューを提供します。リソースがどのように相互に関連しているか、またそれらの構成が時間の経過とともにどのように変化したかを特定するのに役立ちます。

その他のツール

HashiCorp Terraform はオープンソースの infrastructure as code (IaC) ツールで、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングおよび管理できます。

コードリポジトリ

このパターンのコードは、リポジトリ GitHub AWS Config のある AWS CloudFormation Guard で入手できます。このコードリポジトリには、このパターンで説明されている両方のシナリオのサンプルが含まれています。

エピック

タスク	説明	必要なスキル
（オプション) ルールのキーと値のペアを選択します。	カスタム Guard ポリシーを定義する場合は、以下の手順を実行します。シナリオ 1 または 2 のサンプルポリシーのいずれかを使用している場合は、以下の手順をスキップします。にサインイン AWS Management Console し、AWS Config コンソールを開きます。左側のナビゲーションで、リソースを選択します。リソースインベントリで、 AWS Config カスタムルールを作成するリソースのタイプを選択します。 [詳細を表示] を選択します。設定項目の表示 (JSON) を選択します。このセクションでは、JSON 形式で設定項目を表示するように展開します。 AWS Config カスタムルールを構築するキーと値のペアを特定します。	AWS 管理者、セキュリティエンジニア
カスタムルールを作成します。	以前に特定したキーと値のペアを使用するか、提供されているサンプル Guard ポリシーのいずれかを使用して、AWS Config 「カスタムポリシールールの作成」の手順に従ってカスタムルールを作成します。	AWS 管理者、セキュリティエンジニア
カスタムルールを検証します。	カスタム Guard ルールを検証するには、次のいずれかを実行します。 AWS Command Line Interface () に次のコマンドを入力しますAWS CLI。 `cfn-guard validate -r guard-s3.guard -d s3bucket-prod-pass.json` Detective モードでのAWS Config 「ルールによるリソースの評価」の指示に従って、にルールをデプロイします AWS Config。Guard 構文が、ターゲットアカウントまたはファイル内の対応するリソースに正しく一致することを確認します。	AWS 管理者、セキュリティエンジニア

トラブルシューティング

問題ソリューション

問題	ソリューション
の外部で Guard ポリシーをテストする AWS Config	ユニットテストは、ローカルデバイスまたは IDE などの統合開発環境 ( AWS Cloud9 IDE) で実行できます。ユニットテストを実行するには、以下を実行します。 AWS CloudFormation Guard CLI とその依存関係をインストールします。 JSON 形式の CI サンプルを .json ファイルとしてワークステーションに保存します。 GuardDuty ポリシーを .guard ファイルとしてワークステーションに保存します。 Guard CLI で次のコマンドを入力して、Guard ポリシーを使用してサンプル JSON ファイルを検証します。 `cfn-guard validate \ -r guard-s3.guard \ -d s3bucket-prod-pass.json`
AWS Config カスタムルールのデバッグ	Guard ポリシーで、`EnableDebugLogDelivery`値をに変更します`true`。デフォルト値は、`false`です。ログメッセージは Amazon に保存されます CloudWatch。

の外部で Guard ポリシーをテストする AWS Config

ユニットテストは、ローカルデバイスまたは IDE などの統合開発環境 ( AWS Cloud9 IDE) で実行できます。ユニットテストを実行するには、以下を実行します。

AWS CloudFormation Guard CLI とその依存関係をインストールします。
JSON 形式の CI サンプルを .json ファイルとしてワークステーションに保存します。
GuardDuty ポリシーを .guard ファイルとしてワークステーションに保存します。
Guard CLI で次のコマンドを入力して、Guard ポリシーを使用してサンプル JSON ファイルを検証します。
```
cfn-guard validate \
-r guard-s3.guard \
-d s3bucket-prod-pass.json
```

AWS Config カスタムルールのデバッグ

Guard ポリシーで、EnableDebugLogDelivery値をに変更しますtrue。デフォルト値は、falseです。ログメッセージは Amazon に保存されます CloudWatch。