組織のカスタムルールを有効にするには、 alloftrendproduct-conformity@trendmicro.com にメールを送信してアクセス権をリクエストし、リクエストに次の詳細を入力してください。
- Conformityの Organization アカウントの名前
- Cloud One または Conformity Standalone（つまり、cloudconformity.com）を介したアクセスかどうか
- 主要な連絡先のリスト
- 管理者ユーザであり、 APIキーが設定されていることを確認します。
- カスタムルールAPIを使いやすくするために、API管理ツール（Postmanなど）を使用して、テストおよび実装時にAPIペイロードをより簡単に保存、再利用、および管理できるようにすることを強くお勧めします。
- 使用可能なAPIエンドポイントの使用例と詳細については、 カスタムルールAPIのドキュメントを参照してください。
AdministratorとしてAPIキーを作成します。
APIリクエストを管理するために、Postman（または同等のプログラム）ダウンロードします。https://www.postman.com/downloads/ カスタムルールの問題を簡単にテスト、フォーマット、トラブルシューティングするために、これを強くお勧めします。
Postmanで、 'Custom Rules Demo'という名前の新しいワークスペースを作成します > ドロップダウンを開き > 'Add a request'をクリックして最初のリクエストをPostmanに追加します。要求に「List accounts」という名前を付けます。この List Accounts 要求を使用して、基本的な設定が機能していることを確認し、有効な応答を取得しています。
Headersで、Content-Type =application/vnd.api+jsonと、**Authorization ** =ApiKey XYZ123 を含め、XYZ123をAPIキーに置き換えます。
Conformity 組織のURLを書き留めます。これには、リージョン/環境、組織/アカウントID、またはその両方が含まれます。
postmanのクエリで、地域に応じてアカウントのエンドポイントURLを保存し（例：https://us-west-2 -api.cloudconformity.com/v1/accounts、Sendをクリックします。すべてが正しく設定されていれば、組織の Conformity アカウントに関するデータを含む応答が返されます。
Postman ワークスペースで、省略記号（3つのドット）をクリックし、正常に実行されたクエリを複製します（ほとんどの設定は再利用できます）。
新しいクエリの名前を'list custom rules'に変更します。URLを/ custom-rulesに変更します（例：https://us-west-2 -api.cloudconformity.com/v1/custom-rules）。[保存して送信]をクリックします。正常であるが空の応答が返されます。カスタムルールはまだ保存されていません。
これで、基本的な Postman/ APIの設定が完了し、テストが完了しました。カスタムルールを使用する準備ができました。

ワークフロー1：カスタムルールの作成、実行、アップデート、および削除

最初のカスタムルールを保存して実行する（Conformity Botを使用）

独自のカスタムルールを作成する前に、テンプレートを使用して主要な機能をデモすることをお勧めします。

成功した「list custom rules」要求を複製します。要求の種類を「POST」に変更し、名前を「save basic rule」に変更して、[Save]をクリックします。これは、https://us-west-2-api.cloudconformity.com/v1/custom-rulesなどのエンドポイントに対するPOSTコマンドになります。

Postmanの[Body]ヘッダで、[raw]を選択し、JSON形式が選択されていることを確認して、以下のカスタムルールテンプレートを貼り付け、[保存]をクリックします。Postman では、要求の本文を「美化」することもできます。このルールは、S3 バケット暗号化をチェックする基本的なデモルールです。

{
  "name": "S3 bucket has any Encryption",
  "description": "We want to demonstrate Custom Rules V1",
  "service": "S3",
  "resourceType": "s3-bucket",
  "severity": "MEDIUM",
  "enabled": true,
  "provider": "aws",
  "categories": [
    "security"
  ],
  "remediationNotes": "To remediate, follow these steps:\n1. Step one \n2. Step two\n",
  "attributes": [
    {
      "name": "bucketEncryption",
      "path": "data.Encryption",
      "required": true
    }
  ],
  "rules": [
    {
      "conditions": {
        "all": [
          {
            "fact": "bucketEncryption",
            "operator": "notEqual",
            "value": null
          }
        ]
      },
      "event": {
        "type": "Bucket has encryption enabled"
      }
    }
  ]
}

[保存して送信]をクリックします。成功した場合、応答はルールのIDを含むルールデータを返します。これで、カスタムルールが組織に保存されました。これで、通常の Conformity Bot プロセスの一部として、関連する各クラウドアカウント（この場合はAWS）のリソースデータに対してルールが自動的に実行されます。
確認するには、前の[list custom rules]クエリに戻り、その要求を再度実行します。保存されたルールの詳細が応答で返されます。
オプション（環境および時間に依存 - それ以外の場合は次のセクションにスキップ）： いずれかのアカウントで Conformity Bot を実行できます。保存されたカスタムルールは、次回のConformity Bot実行時に自動的に取得され、'Resolve'ボタン（remediationNotesフィールドを使用して対処します）が含まれる点以外は他のルールと同じ形式でチェックが生成されます。
推奨（トラブルシューティングの注意）： コンソールでチェックを表示するには、カスタムルールを作成した後にブラウザウィンドウを更新して、 Conformity Webアプリケーションがチェックを正しく表示するために必要なデータをロードするようにします。Conformity アプリケーションでは、この更新を行わないと、チェックを正しく表示するために必要なすべてのデータがロードされない場合があります。
ブラウザを更新した後、[Browse All Checks]をクリックし、カスタムルールIDに基づいてフィルタします。最初のカスタムルールがアカウントに表示され、有効になります。

保存されている既存のルールのドライラン

ルールの結果をテストするには、APIを使用してルールを「ドライラン」します。予行演習の要求では、組織のアカウントから既存のリソースデータをフィードし、（ Conformity Bot の完了を待たずに）ただちに応答を返すことができます。

注意： 以下で使用されるリソースデータは Conformityによって保存されており、クラウド環境の最新の状態を反映していない場合があります。これは、 Conformity Bot またはリアルタイム監視が最後にリソースデータを更新した日時によって異なります。

以前の「 POST 」クエリを複製して「save basic rule」という名前を付け、「dry-run Saved Rule」の名前を変更します。
URLに「/run」を追加します。結果は次のようなURLへのPOSTクエリになります：https://us-west-2-api.cloudconformity.com/v1/custom-rules/run
ルールをドライランするアカウントのIDを取得します。応答「アカウントのリスト」クエリから取得できます。実行するデータセットをカスタムルールフレームワークが認識できるように、アカウントを識別する必要があります。
Paramsタブで、KEYのaccountIdにVALUE を入力し、およびKEYのidにVALUE を入力します。これにより、リクエストのURL文字列が自動的に更新されます（例：https://us-west-2-api.cloudconformity.com/v1/custom-rules/run?accountId=d2c91234-1234-abcd-zxcv-12345qwerty&id=CUSTOM-ENC12346UE
リクエストの[Body]をクリアし、save and sendをクリックします。これにより、選択したアカウントの Conformity によって保存された既存のS3データに対して「ドライラン」が実行され、各S3 バケットのリソースデータについて SUCCESS または FAILURE の結果が返されます。

既存の保存済みカスタムルールのアップデート、テスト、無効化、および削除

保存したカスタムルールは、更新、無効化、および完全に削除できます。ルールのアップデートには、基本的な設定の変更（重大度やカテゴリなど）や、ルールロジックを含むより大幅な変更を含めることができます。アップデートされたルールは、最新のロジックが実行されるまでチェックを保持します。

注：ルールを削除しても、関連するチェックの削除/削除など、関連するデータはすぐに変更されません。最初にルールを無効（つまり、有効：false）にして、削除する前に Conformity Bot を1サイクル実行できるようにすることをお勧めします。これにより、 Conformity Bot で関連するチェックを削除し、統計の更新、作成したJIRA / ServiceNowチケットのクローズなどの関連タスクを完了することができます。

POST クエリ「save basic rule」を複製し、PUT要求に変更して、「update Saveed rule」の名前を変更します。
/ をURLに追加します（例：https://us-west-2-api.cloudconformity.com/v1/custom-rules/CUSTOM-QqVHDF6JVdUE
ルールテンプレートの本文を変更して変更します。 a. 名前（ルールには任意の名前を付けます）および重要度（例：LOWに変更）の値 b. [ルール]→[条件]→[すべて]→[演算子]で、notEqualをequalに変更します（ルールのロジックが逆になります）。
[save and send]をクリックします。既存のルールが更新され、応答に表示されます。「list custom rules」を再実行すると確認できます。
dry run saved rule を実行して、新しくアップデートされたルールをテストします。以前は FAILUREであった SUCCESS チェックが表示されます。 Conformity Botを使用してルールを実行すると、チェックのデータが更新されます。
最後のクリーンナップとして、保存したルールを無効にして削除する準備をします。最初に保存されたルールを無効にします。これにより、 Conformity Bot で、チェックの削除に関連するタスク（関連するチェックの削除、統計の更新、作成済みのJIRA / ServiceNowチケットのクローズなど）を処理できるようになります。チェックが作成されていない場合カスタムルールを削除し、手順8に進んでカスタムルールを完全に削除します。PUT要求の「保存されたルールのアップデート」の本文を変更し、有効なプロパティをfalseに変更します。
[送信]をクリックします。既存のルールが更新され、応答に表示されます。確認するには、「list custom rules」またはGET /custom-rule/{ruleId}を再実行します。
Conformity Bot が、カスタムルールに関連するすべてのアカウントでサイクル全体を実行できるようにします。
PUTリクエストの「保存されたルールのアップデート」リクエストを複製し、DELETEリクエストに変更して、新しいリクエストの名前を「保存されたルールの削除」に変更します。
本文はクリアできます（必須ではありません）。URLに組織から削除するカスタムルールIDが含まれていることを確認し、[保存して送信]をクリックします。'list custom rules'クエリを再実行して、カスタムルールの配列が空になっているかどうかを再度確認できます。

ワークフロー2：「ドライラン」機能を使用してルールを構築する

アカウントに対してドラフトルール設定のドライ実行

ワークフロー1では、カスタムルールをデモ用に組織に直接保存しました。これは通常の開発フローや推奨される開発フローではありません。代わりに、保存する前に、ルールをテストして空実行してからダミーデータを使用する必要があります。このワークフローでは、リクエストの本文にルール設定を渡し、既存のアカウントリソースデータから出力を返すことで、ドライランの方法を示します。

「dry run Saved rule」という名前の POST クエリを複製し、「dry run configuration」の名前を変更します。
「Params」で「id」を削除し（このルールは削除されました）、「accountId」はそのままにします。結果のクエリ文字列は、https://us-west-2-api.cloudconformity.com/v1/custom-rules/run?accountId=d2c91234-1234-1234-1234-123456786.のようになります。

実行エンドポイントは、「設定」を使用してルールをラップするリクエスト本文を識別できます。[Body]で、次の設定を保存します。

{
  "configuration": {
    "name": "S3 bucket logging enabled",
    "description": "S3 buckets have logging enabled",
    "service": "S3",
    "resourceType": "s3-bucket",
    "attributes": [
      {
        "name": "bucketLogging",
        "path": "data.LoggingEnabled",
        "required": true
      }
    ],
    "rules": [
      {
        "conditions": {
          "all": [
            {
              "value": null,
              "operator": "notEqual",
              "fact": "bucketLogging"
            }
          ]
        },
        "event": {
          "type": "Bucket has logging enabled"
        }
      }
    ],
    "severity": "MEDIUM",
    "categories": [
      "security"
    ],
    "provider": "aws",
    "enabled": true
  }
}

[保存して送信]をクリックします。応答は、選択したアカウントのリソースデータに対するルール設定のチェック結果になります。上記の例では、S3 バケットごとに FAILURE または SUCCESS チェックが表示されます。ワークフロー1では、アカウントにすでに保存されているルールをドライラン機能を使用して実行しましたが、この代替アプローチの利点は、設定を最初に保存する必要がないため、開発およびテストプロセスの速度が向上することです。
テストとして、「operator」を「notEqual」から「equal」に変更し、もう一度[send]をクリックします。新しいルールロジックに基づいてチェック結果が変更されます。

Run Endpointを使用してリソースデータを返す

カスタムルールのルール属性を作成する場合、パスを正しく定義できるようにリソースデータの構造を把握することが重要です。これを支援するために、 Conformity カスタムルールでは、単一のリソースのリソースデータをクエリして、実行エンドポイントからの確認応答で返すことができます。

そのためには、ルール設定で特定のリソースIDを定義し、要求パラメータresourceData = trueを適用する必要があります。

POST クエリ「dry run configuration」を複製し、「dry run get resource data」の名前を変更します。
[Params]タブで、値がtrueのキーのresourceDataを入力し、accountIdパラメータを保持します。最終的なリクエストURLは、https://us-west-2-api.cloudconformity.com/v1/custom-rules/run?accountId=d2c97341-0be1-4166-be5f-55d55e9ef056&resourceData=true.のようになります。

「Body」内に、resourceIdという名前のパラメータを設定内に追加します。この値は、リソースデータを返すアカウントのS3 バケットの名前です。リソースIDがわからない場合は、以前の応答の例を確認するか、チェックエンドポイントに別のクエリを実行して、いくつかの考えを確認できます。

リクエストの本文は次のようになります。

{
  "configuration": {
    "name": "S3 bucket logging enabled",
    "description": "S3 buckets have logging enabled",
    "service": "S3",
    "resourceType": "s3-bucket",
    "resourceId": "<INSERT S3 BUCKET NAME>",
    "attributes": [
      {
        "name": "bucketLogging",
        "path": "data.LoggingEnabled",
        "required": true
      }
    ],
    "rules": [
      {
        "conditions": {
          "all": [
            {
              "value": null,
              "operator": "notEqual",
              "fact": "bucketLogging"
            }
          ]
        },
        "event": {
          "type": "Bucket has logging enabled"
        }
      }
    ],
    "severity": "MEDIUM",
    "categories": [
      "security"
    ],
    "provider": "aws",
    "enabled": true
  }
}

[save and send]をクリックします。応答には、選択したルール設定の確認結果と、そのリソースのリソースデータが含まれます。このリソースデータを使用して、選択したサービス用に作成する新しいルールを作成できます。

注意： 単一のリソースIDを入力しないと、要求は422エラーを返します。

ダミーデータを使用して新しいカスタムルールテンプレートをテストする

Conformity カスタムルールでは、リクエストの本文の一部としてダミーリソースデータを渡すこともできます。これにより、アカウントの実際のリソースデータを使用せずに、さまざまなシナリオのカスタムルールをテストできます。

前のクエリを複製するか、新しい POST クエリを作成して、「dry run withダミデータ」という名前を付けます。
クエリ文字列が次のようになるようにパラメータを削除します：https://us-west-2-api.cloudconformity.com/v1/custom-rules/run。

リクエストの本文に、次のように入力します。これには、ルール設定と、ルールロジックに渡されるリソースデータの両方が含まれます。

{
  "configuration": {
    "name": "S3 bucket logging enabled",
    "description": "S3 buckets have logging enabled",
    "service": "S3",
    "resourceType": "s3-bucket",
    "categories": [
      "security"
    ],
    "attributes": [
      {
        "name": "bucketLogging",
        "path": "data.LoggingEnabled",
        "required": true
      }
    ],
    "rules": [
      {
        "conditions": {
          "all": [
            {
              "value": null,
              "operator": "notEqual",
              "fact": "bucketLogging"
            }
          ]
        },
        "event": {
          "type": "Bucket has logging enabled"
        }
      }
    ],
    "severity": "HIGH",
    "provider": "aws",
    "enabled": true
  },
  "resource": {
    "accountId": "wonKey-",
    "organisationId": "DonNke3",
    "resourceId": "auto-remediate-v1-serverlessdeploymentbucket-154y8zf51bnh2",
    "service": "S3",
    "ccrn": "ccrn:aws:iwonKey-:S3:us-west-2:auto-remediate-v1-serverlessdeploymentbucket-154y8zf51bnh2",
    "region": "us-west-2",
    "descriptorType": "s3-bucket",
    "data": {
      "Name": "auto-remediate-v1-serverlessdeploymentbucket-154y8zf51bnh2",
      "CreationDate": "2020-09-08T00:44:14.000Z",
      "region": "us-west-2",
      "resourceId": "auto-remediate-v1-serverlessdeploymentbucket-154y8zf51bnh2",
      "Grants": [
        {
          "Grantee": {
            "DisplayName": "aws.sandbox",
            "ID": "69a55bbb9669d3276014662091a21e9b3577353e2a3912f02117d22f95d944ce",
            "Type": "CanonicalUser"
          },
          "Permission": "FULL_CONTROL"
        }
      ],
      "Owner": {
        "DisplayName": "aws.sandbox",
        "ID": "69a55bbb9669d3276014662091a21e9b3577353e2a3912f02117d22f95d944ce"
      },
      "Policy": null,
      "Encryption": {
        "Rules": [
          {
            "ApplyServerSideEncryptionByDefault": {
              "SSEAlgorithm": "AES256"
            }
          }
        ]
      },
      "Lifecycle": null,
      "LoggingEnabled": {
        "TargetBucket": "cf-templates-fw8u6fo2nupv-us-west-2",
        "TargetGrants": [],
        "TargetPrefix": ""
      },
      "BucketVersioning": {},
      "ObjectLockConfiguration": null,
      "BucketAccelerateConfiguration": {},
      "BucketWebsite": null,
      "Tags": [
        {
          "Key": "STAGE",
          "Value": "v1"
        },
        {
          "Key": "service",
          "Value": "auto-remediate"
        }
      ],
      "PublicAccessBlockConfiguration": null
    },
    "name": "S3 Bucket",
    "link": "https://s3.console.aws.amazon.com/s3/buckets/auto-remediate-v1-serverlessdeploymentbucket-154y8zf51bnh2/?region=us-west-2&tab=overview",
    "linkTitle": "auto-remediate-v1-serverlessdeploymentbucket-154y8zf51bnh2",
    "provider": "aws",
    "lastModifiedDate": 1602099955645,
    "lastModifiedBy": "SYSTEM"
  }
}

[保存して送信]をクリックします。応答は、指定されたリソースがSuccessまたはFailureとして評価されたかどうかに基づく単純な確認応答になります。

[
  {
    "region": "us-west-2",
    "resource": "auto-remediate-v1-serverlessdeploymentbucket-154y8zf51bnh2",
    "ccrn": "ccrn:aws:iWdNVKe-:S3:us-west-2:auto-remediate-v1-serverlessdeploymentbucket-154y8zf51bnh2",
    "status": "SUCCESS",
    "message": "S3 Bucket auto-remediate-v1-serverlessdeploymentbucket-154y8zf51bnh2 passed 'Bucket has logging enabled' rule condition.",
    "extradata": [
      {
        "name": "successEvent",
        "label": "Passed Condition Event",
        "value": "Bucket has logging enabled",
        "type": "META"
      }
    ]
  }
]

ユーザは、前のリソースデータワークフローからの応答に基づいて独自のリソースデータを入力できます。これにより、環境内のリソースの作成に依存したり、 Conformity Botを介して特定のリソースデータを格納したりすることなく、リクエスト本文に小さな迅速な変更を加えて、予期される結果を評価できます。開発者は、将来同様のルールを作成する際に役立つように、ダミーのリソースデータオブジェクトの小さなライブラリを収集することもできます。これにより、リソースデータなどのクエリが頻繁に実行されることがなくなり、カスタムルールの開発をさらにスピードアップできます。

別のサービス用の新しいカスタムルールの作成

ここまでの例では、AWS S3のみを使用しました。別のプラットフォームやサービス用のカスタムルールを作成するには、まず単純な「ダミー」ルール設定を作成し、それを実行エンドポイントおよびresourceData = trueと組み合わせて、リソースデータの構造を学習して通知できるようにすることをお勧めします。パスの定義選択したサービスからresourceIdを含むリソースデータを取得するには、いくつかのパラメータと、 Conformityのデータの「resource-types」に相当するdescriptorType値が必要です。

次の例では、Azure Virtual Machinesのデータを使用しています。この例では、 Conformity と統合された Azure Virtual Machine リソースをホストするAzure サブスクリプションが必要ですが、このプロセスは、 Conformityでサポートされる任意のサービスまたはリソースタイプに適用できます。

次のリンクを参照して、serviceとdescriptorTypeの可能な値を参照してください（カスタムルールフレームワークのdescriptorTypeは、resource-typesエンドポイントからの「resource-types」の値にマップされます）：https://us-west-2.cloudconformity.com/v1/resource-types

ctrl + fまたはcmd + fを使用して、Azure仮想マシンのリソースの種類の値を特定します。前のエンドポイントから次のものを特定する必要があります。

109: 
  type: "resource-types" 
  id: "virtual-machines" 
  attributes: 
    name: "Virtual Machine" 
  relationships: 
    service: 
      data: 
        type: "services" 
        id: "VirtualMachines"

Azureデータに対するルールを作成するには、まず ConformityChecks APIを実行してサンプルのリソースIDを取得します。「get azure check data」という名前の新しいGET APIクエリを作成します。パラメータで、選択したAzure サブスクリプションのaccountIdsフィールドを含めます（「list account」クエリを再実行するか、 Conformity UIで選択したサブスクリプションを選択し、IDをブラウザのURL）。また、フィルタを使用して応答を制限する必要もあります。たとえば、クエリ文字列は次のようになります。https://us-west-2-api.cloudconformity.com/v1/checks?accountIds=40220033-1234-1234-1234-12349976fc65&filter[services]=VirtualMachines.
上記のGETクエリを保存して送信し、descriptorType = virtual-machineで指定されたチェックのリソースIDの例の値をメモします。Azure仮想マシンの場合、「/subscriptions/1abc1234-1234-1234-1234-abcd1d821234/resourceGroups/my-resource-group/providers/Microsoft.Compute/virtualMachines/my-special-virtual-machine」
新しいPOSTクエリを作成し、resourceData = trueを使用してデータをドライランし、リソースデータを返し、「dry run get azure vm data」という名前を付けます。クエリ文字列の例：https://us-west-2-api.cloudconformity.com/v1/custom-rules/run?accountId=40220033-1234-1234-1234-12349976fc65&resourceData=true

POST クエリの本文には、データの適切なresourceId、service、descriptorTypeを使用して単純なダミールールを作成します。次の例は、resourceIdフィールドにデータが入力されているかどうかをチェックするルールです。データが存在するかどうかの単純なプロキシチェックで、リソースデータを返すのに十分です。

{
  "configuration": {
    "name": "Check if resource exists",
    "description": "Simple check if resource data exists for given resource",
    "resourceId": "/subscriptions/27b11718-e2c4-4336-b3d6-ac291d8299d3/resourceGroups/CFX-WALLACE-RG/providers/Microsoft.Compute/virtualMachines/double-encrypted-vm",
    "service": "VirtualMachines",
    "resourceType": "virtual-machines",
    "severity": "LOW",
    "enabled": true,
    "provider": "azure",
    "categories": [
      "security"
    ],
    "remediationNotes": "Check if resource exists",
    "attributes": [
      {
        "name": "exists",
        "path": "resourceId",
        "required": true
      }
    ],
    "rules": [
      {
        "conditions": {
          "all": [
            {
              "fact": "exists",
              "operator": "notEqual",
              "value": null
            }
          ]
        },
        "event": {
          "type": "Resource exists"
        }
      }
    ]
  }
}

[save and send]をクリックします。応答には、 Azure Virtual Machineのリソースデータが含まれているはずです。これを参照として使用し、データ内の指定されたjson.path値に基づいてより高度なルールを構築できます。次のサンプルデータを使用して、vmSizeをチェックする条件を作成するために、カスタムルール条件文でjson.path data.hardwareProfile.vmSizeを参照できます。

ワークフロー3：より高度なカスタムルールロジックの検討

Rule Anatomyを確認してください。

複数または入れ子の条件

ここまでの例では、条件が1つだけの非常に単純なロジックを使用しています。JSONルールエンジンを使用すると、カスタムルールのネスト条件または組み合わせ条件の数にハード制限はありません。

より複雑なルールのいくつかの例については、ここを参照してください。

ワークフロー4：特定のアカウントのルールの構築または除外の適用

カスタムルールは、 SUCCESS、 FAILURE、 ERROR の結果のみを許可し、 Conformityの既存のチェックフレームワークの複雑なビジネスロジックを削除するように設計されています。（注意： ERROR の結果は、リソースデータやルールロジックの問題を表し、 Conformity Bot では保存されませんが、開発を支援するために実行エンドポイントによって返されます）。

特定のパラメータに一致するリソースに対して SUCCESS を自動的に渡す条件を構築することで、例外と同等の機能を実装する方法があります。

S3暗号化とパブリックアクセスブロックの両方をチェックする設定の例を次に示します。ただし、名前に「test」が含まれるバケットについては自動的に成功します。

{
  "configuration": {
    "name": "S3 encrypted and public access block - with safelist for 'test'",
    "description": "Check S3 has encryption AND public access block, but safelist 'test' buckets",
    "service": "S3",
    "resourceType": "s3-bucket",
    "severity": "HIGH",
    "enabled": true,
    "provider": "aws",
    "categories": [
      "security"
    ],
    "remediationNotes": "To remediate, follow these steps:\n1. Do as you wish \n2. Step two\n",
    "attributes": [
      {
        "name": "bucketEncryption",
        "path": "data.Encryption",
        "required": true
      },
      {
        "name": "publicAccessBlockConfiguration",
        "path": "data.PublicAccessBlockConfiguration",
        "required": true
      },
      {
        "name": "safeList",
        "path": "data.resourceId",
        "required": true
      }
    ],
    "rules": [
      {
        "conditions": {
          "any": [
            {
              "fact": "safeList",
              "operator": "pattern",
              "value": ".*test.*"
            },
            {
              "all": [
                {
                  "fact": "bucketEncryption",
                  "operator": "notEqual",
                  "value": null
                },
                {
                  "fact": "publicAccessBlockConfiguration",
                  "operator": "notEqual",
                  "value": null
                }
              ]
            }
          ]
        },
        "event": {
          "type": "Bucket has encryption enabled"
        }
      }
    ]
  }
}

このページのトピック

Conformity カスタムルールの使用開始

前提条件

初期設定