組織のカスタムルールを有効にするには、alloftrendproduct-conformity@trendmicro.com にメールを送信してアクセスをリクエストし、リクエストに次の情報を入力してください。
- Conformityでの組織アカウント名
- Cloud OneまたはConformity Standalone (cloudconformity.comなど) を介してアクセスするかどうか
- 主要な連絡先の一覧表示
- 管理者ユーザであり、APIキーの設定があることを確認します。
- Custom Rules APIを快適に使用するには、API管理ツール ( Postmanなど) を使用して、テストおよび実装時にAPIペイロードを簡単に保存、再利用、および管理することをお勧めします。
- より包括的な使用例と使用可能なAPIエンドポイントの詳細については、 Custom Rules APIのドキュメントを参照してください。
AdministratorでAPIキーの作成する。
Postman (または同等のプログラム) をダウンロードしてAPIリクエストを管理する - https://www.postman.com/downloads/ - カスタムルールに関する問題のテスト、フォーマット、およびトラブルシューティングを簡単に行うには、これを強くお勧めします。
Postman で、 Custom Rules Demoという名前の新しいワークスペースを作成します。ドロップダウンをクリックし、 を選択します。リクエストを追加 して、Postman に最初のリクエストを追加します。リクエストに「 'List accounts' 」という名前を付けます。このList Accounts リクエストを使用して、基本設定が機能し、有効な応答が返されることを確認します。
[ Headers] で、 Content-Type = application/vnd.api+jsonおよび Authorization = ApiKey XYZ123を含めます。XYZ123は実際のAPIキーに置き換えます。
Conformity組織のURLを書き留めます。これには、地域/環境、組織IDまたはアカウントID (あるいはその両方) が含まれます。

7.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)。 [save and send] をクリックします。カスタムルールはまだ保存されていません。
これで、基本的なPostman/APIの設定とテストが完了しました。カスタムルールの使用方法をさらに詳しく説明する準備ができました。

リソースデータのクエリ

リソースデータをクエリするには

既存のルールのチェックデータを取得します。
- Conformityですでにサポートされている既存のルール、サービス、またはリソースタイプをクラウド環境から選択します。
- 適切なフィルタを使用してチェックエンドポイントをクエリする - アカウントチェックのリスト
- チェックの応答から、選択したリソースの provider service descriptorType と resource を書き留めます。
カスタムルール実行エンドポイントを使用してデータをクエリします。
- エンドポイントの実行に対するPOSTコマンドを設定します。
- accountId と resourceData=trueを含めます。 URLの例: https://conformity.{region}.cloudone.trendmicro.com/api/custom-rules/run?accountId=abcd1234-wxyz-6789-abcd-12345678abcd&resourceData=true

3.リクエスト本文には、次のテンプレートを使用します。チェックAPIレスポンスの provider service descriptorType と resource の値を、それぞれ値 provider service resourceType と resourceId に挿入します。残りの値はプレースホルダです。

    {
      "configuration": {
        "provider": "aws",
        "service": "service-value",
        "resourceType": "descriptorType-value",
        "resourceId": "resource-value",
        "name": "Query Resource Data",
        "description": "This is a simple custom rule template for querying resource data",
        "remediationNotes": "Pass this template as a POST request body to /custom-rules/run?resourceData=true&accountId=aaa-bbb-ccc",
        "severity": "LOW",
        "enabled": true,
        "categories": [
          "operational-excellence"
        ],
        "attributes": [
          {
            "name": "resourceId",
            "path": "resourceId",
            "required": true
          }
         ],
         "rules": [
            {
              "conditions": {
                "all": [
                  {
                    "fact": "resourceId",
                    "operator": "notEqual",
                    "value": null
                  }
                ]
              },
              "event": {
                "type": "Resource ID found. Return resource data"
              }
            }
          ]
        }
      }

SUCCESS.レスポンスは、次の2つのオブジェクトを含む配列である必要があります。

ワークフロー1: カスタムルールの作成、実行、更新、および削除

最初のカスタムルールの保存と実行 (Conformity Botを使用)

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

成功した「list custom rules」リクエストを複製します。リクエストタイプを「POST」に変更し、名前を「save basic rule」に変更して、 [保存] をクリックします。これは、https://us-west-2-api.cloudconformity.com/v1/custom-rulesなどのエンドポイントへのPOSTコマンドです。

PostmanのBodyヘッダでRawを選択し、JSON形式が選択されていることを確認し、以下のカスタムルールテンプレートを貼り付けて、[Save] をクリックします。 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"
      }
    }
  ]
}

[ save and send] をクリックします。成功した場合、応答はルールIDを含むルールデータを返します。カスタムルールが組織に保存されました。ルールは、通常のConformity Botプロセスの一環として、関連する各クラウドアカウント (この場合はAWS) のリソースデータに対して自動的に実行されます。
確認するには、前の「list custom rules」クエリに戻り、その要求を再度実行します。これで、保存されたルールの詳細を示すデータがレスポンスに返されます。
オプション (環境と時間に依存します。それ以外の場合は次のセクションに進みます): いずれかのアカウントで Conformity Bot を実行できます。保存されたカスタムルールは、次回のConformity Botの実行時に自動的に選択され、他のルールと同じ形式でチェックが生成されます。
推奨 (トラブルシューティングメモ): Conformityコンソールでチェックを表示する場合は、カスタムルールの作成後にブラウザウィンドウを更新し、 Conformity Webアプリケーションがチェックを正しく表示するために必要なデータをロードすることを確認します。この最新表示を行わなくても、Conformityアプリケーションはチェックを正しく表示するために必要なデータの一部のみをロードする場合があります。
ブラウザを更新した後、[Browse All Checks] をクリックし、カスタムルールIDを使用してフィルタを実行すると、アカウントで有効な最初のカスタムルールが表示されます。

既存の保存済みルールのドライラン

ルールの結果をテストするには、APIを使用してルールを「ドライラン」します。ドライランリクエストでは、組織内のアカウントから既存のリソースデータをフィードし、すぐにレスポンスを返すことができます (Conformity Botの完了を待つ必要はありません)。

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

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

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

保存したカスタムルールを更新、無効化、および完全に削除できます。既存のカスタムルールは、基本的な設定の変更 (重要度やカテゴリなど) や、ルールロジックなどのより重要な変更に応じて更新できます。更新されたルールでは、最新のロジックが実行されるまでチェックが保持されます。

注意: ルールを削除すると、 **** は関連するデータを即座に変更します。たとえば、関連するチェックの削除/削除です。最初にルールを無効 (有効: false) にし、Conformity Botが削除されるまで1サイクル実行できるようにすることをお勧めします。これにより、Conformity Botは関連するチェックを削除し、統計の更新、作成されたJIRA/ServiceNowチケットのクローズなどの関連タスクを完了することができます。

「save basic rule」という名前のPOSTクエリを複製し、PUTリクエストに変更して、「保存されたルールの更新」という名前に変更します。
追加 / URL (例: https://us-west-2-api.cloudconformity.com/v1/custom-rules/CUSTOM-QqVHDF6JVdUE)
次の項目を変更して、ルールテンプレートの本文を変更します。 a.名前 (ルールの名前は任意) と重大度 (低に変更するなど) の値。 b. [ルール]→[条件]→[すべて]→[演算子] で、[notEqual] を [等しい] に変更します (これにより、ルールのロジックが反転します)。
[ save and send] をクリックします。既存のルールが更新され、応答に表示されます。「list custom rules」を再度実行することで確認できます。
dry run saved ruleを実行して、新しく更新されたルールをテストします。以前のFAILUREチェックがSUCCESSチェックに置き換わります。Conformity Botでルールを実行すると、チェックのデータが更新されます。
最後に、保存したルールを無効にして削除する準備をします。まず、保存されたルールを無効にします。これにより、関連するチェックの削除、統計の更新、作成されたJIRA/ServiceNowチケットのクローズなど、チェックの削除に関連するタスクをConformity Botが処理できるようになります。カスタムルールに対してチェックが作成されていない場合をクリックしてから手順8に進み、カスタムルールを完全に削除します。 PUTリクエストの「保存されたルールの更新」の本文を変更し、有効化されたプロパティをfalseに変更します。
[ Send] をクリックします。応答に示されているように、既存のルールが更新されます。確認するには、「list custom rules」または GET /custom-rule/{ruleId}を再度実行します。
カスタムルールに関連するアカウント全体で、Conformity Botによる完全なサイクルの実行を許可します。
PUTリクエスト「update saved rule」を複製し、「DELETE」リクエストに変更して、新しいリクエストの名前を「delete saved rule」に変更します。
本文を消去し (オプション)、組織から削除するカスタムルールIDがURLに含まれていることを確認して、[save and send] をクリックします。 ' 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
  }
}

[ save and send] をクリックします。応答は、選択したアカウントのリソースデータに対するルール設定のチェック結果になります。上記の例では、各S3バケットのFAILUREまたはSUCCESSチェックが表示されます。ワークフロー1では、事前にアカウントに保存したルールを実行するために予行演習機能を使用しましたが、この代替方法を使用すると、最初に設定を保存することなく、開発とテストのプロセスを迅速化できます。
テストとして、「演算子」を「notEqual」から「equal」に変更し、[送信] を再度クリックします。新しいルールロジックに基づいてチェック結果が変更されることを確認します。

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

カスタムルールのルール属性を記述する際の重要な課題の1つは、パスを正しく定義できるようにリソースデータの構造を把握することです。Conformityカスタムルールを使用すると、単一のリソースのリソースデータをクエリし、実行エンドポイントからの確認応答で返すことができます。

これを行うには、ルール設定で特定のリソースIDを定義し、リクエストパラメータ resourceData=trueを適用する必要があります。

POSTクエリ「dry run configuration」を複製し、「dry run get resource data」という名前を変更します。
[パラメータ] タブで、キー「resourceData」と値「true」を入力し、「 Params 」パラメータはそのままにします。最終リクエスト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を1つも入力しない場合、リクエストは422エラーを返します。

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

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

前のクエリを複製するか、新しいPOSTクエリを作成し、「ダミーデータを使用してドライラン」という名前を付けます。
クエリ文字列が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"
  }
}

[save and send] をクリックします。応答には、選択したルール設定のチェック結果と、そのリソースのリソースデータが含まれます。このリソースデータは、選択したサービスの新しいルールを作成するのに役立ちます。

[
  {
    "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データに対するルールを作成するには、最初にConformityチェックAPI を実行してサンプルのリソースIDを取得します。「get azure check data」という新しいGET APIクエリを作成します。パラメータに、選択したAzureサブスクリプションの「accountIds」フィールドを含めます (「アカウントの一覧表示」クエリを再実行するか、 Conformity UIで選択したサブスクリプションを選択し、ブラウザのURLでIDを表示することで取得できます)。フィルタを使用して応答を制限してください。例: https://us-west-2-api.cloudconformity.com/v1/checks?accountIds=40220033-1234-1234-1234-12349976fc65&filter[services]=VirtualMachines。
上記のGETクエリを保存して送信します。上記のGETクエリを保存して送信し、descriptorType = virtual-machineの指定されたチェックについてのサンプルresourceIdの値をメモしてください。 Azure仮想マシンの場合、"/subscriptions/1abc1234-1234-1234-1234-abcd1d821234/resourceGroups/my-resource-group/providers/Microsoft.Compute/virtualMachines/my-special-virtual-machine " のような長いresourceIdが表示される可能性があります。
resourceData=true を使用してデータをドライランするための新しいPOSTクエリを作成し、リソースデータを返し、「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 仮想マシンのリソースデータが含まれている必要があります。これを参照として使用して、データ内の特定の JSON.path 値に基づいてより高度なルールを構築できます。以下のデータ例を使用して vmSize をチェックする条件を作成すると、カスタムルール条件ステートメントで JSON.path data.hardwareProfile.vmSize を参照できます。

ワークフロー3: より高度なカスタムルールロジックを調べる

ルールの構造を確認します。

複数条件および/またはネストされた条件

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

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

ワークフロー4: 特定のアカウントのルールの作成または例外の適用

カスタムルールは、成功、失敗、エラーの結果のみを許可します。カスタムルールは、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カスタムルールクイックレファレンス/参照情報ガイド

APIリファレンス

基本設定の確認