Conformityカスタムルールクイックレファレンスガイド

• カスタムRuleを実行し、リソースデータをクエリ
• list custom rules
• カスタムRuleを作成
• カスタムRuleを取得
• カスタムRuleを削除
• カスタムRuleの更新

1. お客様のOrganizationでカスタムルールを有効にするには、alloftrendproduct-conformity@trendmicro.comにメールを送信してアクセスをリクエストし、リクエストに以下の詳細を記載してください。
   • Organizationアカウントの名前 (Conformity)
   • アクセスがCloud One経由であれ、Conformity Standalone (つまりcloudconformity.com) 経由であれ
   • 主要な連絡先を一覧表示
   • 管理者ユーザであり、APIキーが設定されていることを確認してください。
   • カスタムルールAPIに慣れるために、API管理ツール (例: Postman) を使用して、テストおよび実装中にAPIペイロードを簡単に保存、再利用、および管理することをお勧めします。
   • より包括的な使用例と利用可能なAPIエンドポイントの詳細については、[Custom Rules API documentation]を参照してください。
2. APIキーを作成 - [Administrator.]として
3. Postman (または同等のプログラム) をダウンロードしてAPIリクエストを管理します - https://www.postman.com/downloads/ - カスタムルールのテスト、フォーマット、およびトラブルシューティングを簡単に行うために、これは強く推奨されます。
4. Postmanで、新しいワークスペースを[Custom Rules Demo] > [Click on the drop-down]と名付けて作成し、[Add a request]を選択してPostmanに最初のリクエストを追加します。リクエストに[‘List accounts’]と名付けます。このList accountsリクエストを使用して、基本的なセットアップが機能しており、有効な応答を返していることを確認します。
5. [Headers]の下に、[Content-Type] = application/vnd.api+jsonおよび[Authorization] = ApiKey XYZ123を含め、XYZ123をあなたのAPIキーに置き換えてください。
6. Conformity OrganizationのURLに注意してください。これには、リージョン/環境およびOrganizationやAccount Idが含まれます。
7. postmanクエリで、地域に応じてアカウントエンドポイントURLを保存します。例えば、https://us-west-2-api.cloudconformity.com/v1/accountsを保存し、[Send]をクリックします。カスタムルールが正しく構成されている場合、Organization内のConformityアカウントに関するデータが含まれた応答を受け取るはずです。
8. Postmanワークスペースで、三点リーダー (3つの点) をクリックし、成功したクエリを複製します (ほとんどの設定を再利用できます)。
9. 新しいクエリをlist custom rulesにリネームし、URLを /custom-rules に変更します。例えば、https://us-west-2-api.cloudconformity.com/v1/custom-rules、[save and send]をクリックします。成功したが空のレスポンスが返されるはずです - まだカスタムルールを保存していません。
10. これで、基本的なPostman/APIのセットアップが完了し、テストも済んでいるはずです。カスタムルールの使用にさらに深く取り組む準備が整いました。

    

1. 既存のRuleのチェックデータを取得します。
   • 既にConformityでサポートされているクラウド環境の既存のルール、サービス、またはリソースタイプを選択してください。
   • 適切なフィルターを使用してチェックエンドポイントをクエリします - アカウントチェックの一覧
   • チェック応答から、選択したリソースのプロバイダ、サービス、descriptorType、およびリソースをメモしてください。
2. カスタムルール実行エンドポイントを使用してデータを照会します。
   • runエンドポイントにPOSTコマンドを設定します。
   • accountIdとresourceData=trueを含めます。例のURL: https://conformity.{region}.cloudone.trendmicro.com/api/custom-rules/run?accountId=abcd1234-wxyz-6789-abcd-12345678abcd&resourceData=true
3. リクエスト本文には、以下のテンプレートを使用してください。provider、service、descriptorType、resourceの値をチェックAPIレスポンスから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"
              }
            }
          ]
        }
      }
   

4. 応答は2つのオブジェクトを含む配列である必要があります: a) チェック応答 ("status": "SUCCESS")、および b) resourceData

1. 成功したlist custom rulesリクエストを複製します。POSTリクエストタイプに変更し、save basic ruleと名前を変更して保存をクリックします。これは、https://us-west-2-api.cloudconformity.com/v1/custom-rulesのようなエンドポイントへのPOSTコマンドになります。
2. Postmanの[Body]ヘッダーの下で、[Raw]を選択し、JSON形式が選択されていることを確認します > 以下のカスタムルールテンプレートを貼り付けます > [保存]をクリックします。Postmanではリクエスト本文をBeautifyすることもできます。このルールは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"
          }
        }
      ]
    }
   

3. [save and send]をクリックします。成功すると、レスポンスにはルールのIDを含むルールデータが返されます。これでカスタムルールがあなたのOrganizationに保存されました。このルールは、通常のConformity Botプロセスの一環として、各関連クラウドアカウント (この場合はAWS) のリソースデータに対して自動的に実行されます。
4. 確認するには、前のlist custom rulesクエリに戻り、そのリクエストを再度実行してください。保存されたRuleの詳細を含むデータがレスポンスに表示されるはずです。
5. [Optional (environment and time dependent - otherwise skip to the next section):] Conformity Botを1つのアカウントで実行できます。保存されたカスタムRuleは次回のConformity Botの実行時に自動的に反映され、他のRuleと同じ形式でチェックが行われますが、解決ボタンが含まれる点が除外されます (remediationNotesフィールドで対応されます)。
6. [Recommended (troubleshooting note):] カスタムルールを作成した後にConformityコンソールでチェックを表示したい場合は、ブラウザウィンドウを更新して、Conformityウェブアプリケーションがチェックを正しく表示するために必要なデータを読み込むようにしてください。この更新を行わないと、Conformityアプリケーションはチェックを正しく表示するために必要なデータの一部しか読み込まない可能性があります。
7. ブラウザを更新した後、[Browse All Checks]をクリックし、カスタムルールIDを使用してフィルタリングすると、アカウントで最初のカスタムルールがライブでアクティブになっているのがわかります。

   

   

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

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

   

1. POSTクエリsave basic ruleを複製し、それをPUTリクエストに変更してupdate saved ruleに名前を変更します。
2. URLに/<custom-rule-id>を追加します。例: https://us-west-2-api.cloudconformity.com/v1/custom-rules/CUSTOM-QqVHDF6JVdUE
3. ルールテンプレートの本文を次のように変更します: a. nameの値 (ルールに好きな名前を付ける) とseverityの値 (例: 低に変更)。 b. rules → conditions → all → operatorの下で、notEqualをequalに変更 (これによりルールのロジックが反転します)。
4. [save and send]をクリックします。既存のRuleが更新され、レスポンスに表示されます。‘list custom rules’を再実行して確認できます。

   

5. 新しく更新されたルールを[dry run saved rule]を実行してテストしてください - 以前のFAILUREチェックがSUCCESSチェックに置き換わっていることに気付くはずです。ルールをConformity Botで実行すると、チェックのデータが更新されるのがわかります。

   

6. 最終的なクリーンアップとして、保存されたルールを無効化および削除する準備を行います。まず、保存されたルールを無効化します。これにより、Conformity Botがチェックの削除に関連するタスク (例: 関連するチェックの削除、統計の更新、作成されたJIRA/ServiceNowチケットのクローズなど) を処理できるようになります。カスタムルールに対してチェックが作成されていない場合は、ステップ8に進んでカスタムルールを永久に削除してください。PUTリクエスト保存されたルールの更新の本文を変更し、enabledプロパティをfalseに変更します。
7. [Send]をクリックします。既存のRuleが更新され、レスポンスに表示されます。‘list custom rules’を再実行するか、GET /custom-rule/{ruleId}で確認できます。
8. カスタムRuleに関連するアカウント全体でConformity Botが完全なサイクルを実行することを許可します。
9. PUTリクエスト[update saved rule]を複製し、それを[DELETE]リクエストに変更して、新しいリクエストを[delete saved rule]に名前変更してください。
10. 本文をクリアすることができます (任意)、URLに組織から削除したいカスタムルールIDが含まれていることを確認し、[save and send]をクリックします。カスタムルールの配列が空であるかどうかを確認するために、list custom rulesクエリを再実行して再確認することができます。

    

1. POSTクエリdry run saved ruleを複製し、dry run configurationに名前を変更します。
2. [Params]の下で、'id'を削除し (このルールは削除されました)、'accountId'はそのままにします。結果として得られるクエリ文字列は、https://us-west-2-api.cloudconformity.com/v1/custom-rules/run?accountId=d2c91234-1234-1234-1234-123456786.
3. 実行エンドポイントは、'configuration'を使用してRuleをラップするリクエスト本文を識別できます。[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
      }
    }
   

4. [save and send]をクリックします。応答には、選択したアカウントのリソースデータに対するRule構成のチェック結果が表示されます。上記の例では、各S3バケットに対してFAILUREまたはSUCCESSのチェックが表示されるはずです。ワークフロー1では、アカウントに既に保存したRuleを実行するためにドライラン機能を使用しましたが、この別のアプローチでは、構成を最初に保存する必要なく、開発およびテストプロセスを迅速化することができます。
5. テストとして、"operator" を "notEqual" から "equal" に変更し、[click send again] - 新しいルールロジックに基づいてチェック結果が変わるのがわかります。

1. POSTクエリdry run configurationを複製してdry run get resource dataに名前を変更してください。
2. [Params] タブの下で、値を true に設定したキー resourceData を入力し、accountId パラメータを保持します。最終的なリクエストURLは、https://us-west-2-api.cloudconformity.com/v1/custom-rules/run?accountId=d2c97341-0be1-4166-be5f-55d55e9ef056&resourceData=true.
3. [Body]の内部で、resourceIdという名前のパラメーターを構成に追加し、値にはリソースデータを返したいアカウント内のS3バケットの名前を指定します。Resource idが不明な場合は、以前の応答の例を確認するか、checksエンドポイントに対して別のクエリを実行してアイデアを得ることができます。

   

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

    {
      "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
      }
    }
   

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

   注意 単一のResource idを入力しない場合、リクエストは422エラーを返します。

   

1. 前のクエリを複製するか、新しいPOSTクエリを作成してダミーデータでドライランと名付けてください。
2. パラメータを削除して、クエリ文字列がhttps://us-west-2-api.cloudconformity.com/v1/custom-rules/runと同様の結果を返すようにします。
3. リクエストの本文に次の内容を入力してください。これには、ルール構成と、ルールロジックに渡されるリソースデータの両方が含まれます。

    {
      "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"
      }
    }
   

4. [save and send]をクリックします。応答は、指定されたリソースが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"
          }
        ]
      }
    ]
   

5. ユーザとして、前のリソースデータワークフローの応答に基づいて独自のリソースデータを入力できます。これにより、環境内でリソースを作成し、特定のリソースデータをConformity Botの実行を介して取り込んで保存する必要なく、リクエスト本文に小さな迅速な変更を加えて期待される結果を評価することができます。開発者として、将来の同様のRuleの開発に役立つダミーリソースデータオブジェクトの小さなライブラリを収集することを選択するかもしれません。これにより、例えばリソースデータの頻繁なクエリを回避することで、カスタムRuleの開発をさらに迅速化することができます。

1. 次のリンクを参照して、サービスおよびdescriptorTypeの可能な値を参照してください (カスタムルールフレームワークのdescriptorTypeは、リソースタイプエンドポイントの [resource-types]の値にマップされます): https://us-west-2.cloudconformity.com/v1/resource-types
2. ctrl+fまたはcmd+fを使用して、Azure Virtual Machineのリソースタイプ値を特定します。前のエンドポイントから以下を特定する必要があります:

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

3. Azureデータに対するルールを作成するには、まずConformity Checks APIを実行して、リソースIDの例を取得します。‘get azure check data’という新しいGET APIクエリを作成します。パラメータには、選択したAzureサブスクリプションを含むaccountIdsフィールドを含めます (これは、‘list accounts’クエリを再実行するか、Conformity UIで選択したサブスクリプションを選択し、ブラウザのURLでIDを表示することで取得できます)。レスポンスを制限するためにフィルターを使用することを確認してください。例えば: https://us-west-2-api.cloudconformity.com/v1/checks?accountIds=40220033-1234-1234-1234-12349976fc65&filter[services]=VirtualMachines。
4. 上記の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が表示されることが多いです。
5. 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
6. POSTクエリの本文には、データから適切なresourceId、service、descriptorTypeを使用してシンプルなダミーRuleを構築します。以下の例は、resourceIdフィールドが埋められているかどうかをチェックするRuleです。これはデータが存在するかどうかを確認するためのシンプルなプロキシチェックであり、リソースデータを返すという目的には十分です。

    {
      "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"
            }
          }
        ]
      }
    }
   

7. [save and send]をクリックします。応答にはAzure Virtual Machineのリソースデータが含まれている必要があり、これを参照情報として使用して、データ内の指定されたJSON.path値に基づいて、より高度なRuleを構築できます。以下の例データを使用してvmSizeをチェックする条件を作成するには、カスタムRule条件文でJSON.path data.hardwareProfile.vmSizeを参照することができます。

{
  "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"
        }
      }
    ]
  }
}