Conformityカスタムルールの使い方

1. REST APIエンドポイントの基本的な理解。
2. JSON形式の理解: カスタムルールはJSONおよびjsonpathを使用して、リソースデータを識別および評価します。
3. Conformity環境への管理者レベルのアクセス。

1. お客様のOrganizationでカスタムルールを有効にするには、alloftrendproduct-conformity@trendmicro.comにメールを送信してアクセスをリクエストし、リクエストに以下の詳細を記載してください。
   • ConformityのOrganizationアカウント名
   • アクセスが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] という新しいワークスペースを作成します>ドロップダウンを開きます。>をクリックします。[Add a request] ' をクリックして、 Postmanに最初の要求を追加します 。リクエストに「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、保存をクリックして送信します。成功したが空のレスポンスが返ってくるはずです - まだカスタムルールを保存していません。
10. 基本的なPostman/APIのセットアップが完了し、テストも完了しました。これでカスタムルールの使用に深く入り込む準備が整いました。

    

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. 保存して送信をクリックします。成功すると、レスポンスにはルールの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アプリケーションがチェックを正しく表示するために必要なすべてのデータを読み込まない場合があります。
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. 名前 (ルールに好きな名前を付ける) と重大度 (例: 低に変更) の値を変更します。 b. ルール → 条件 → すべて → 演算子の下で、notEqualをequalに変更します (これによりルールのロジックが反転します)。
4. [save and send]をクリックします。既存のRuleが更新され、応答に表示されます。‘list custom rules’を再実行して確認できます。

   

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

   

6. 最終的なクリーンアップとして、保存されたRuleを無効化および削除する準備を行います。まず、保存されたRuleを無効化します。これにより、Conformity Botがチェックの削除に関連するタスク (例: 関連するチェックの削除、統計の更新、作成されたJira/ServiceNowチケットのクローズなど) を処理できるようになります。カスタムRuleに対してチェックが作成されていない場合は、ステップ8に進んでカスタムRuleを永久に削除してください。PUTリクエスト保存されたRuleの更新の本文を変更し、enabledプロパティをfalseに変更します。
7. 送信をクリックします。既存のRuleは更新され、応答に表示されます。‘list custom rules’を再実行するか、GET /custom-rule/{ruleId}で確認できます。
8. カスタムRuleに関連するアカウント全体でConformity Botが完全なサイクルを実行することを許可します。
9. PUTリクエストupdate saved ruleを複製し、DELETEリクエストに変更して、新しいリクエストをdelete saved ruleに名前を変更します。
10. 本文をクリアすることができます (必須ではありません)、削除したいカスタムルールIDを含むURLを組織から削除し、保存をクリックして送信します。カスタムルールの配列が空になっているかどうかを確認するために、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. 保存して送信をクリックします。応答には、選択したアカウントのリソースデータに対するRule構成のチェック結果が表示されます。上記の例では、各S3バケットに対してFAILUREまたはSUCCESSのチェックが表示されるはずです。ワークフロー1では、アカウントに既に保存したRuleを実行するためにドライラン機能を使用しましたが、この別のアプローチの利点は、最初に構成を保存する必要がないため、開発とテストのプロセスが迅速化されることです。
5. テストとして、"operator"を"notEqual"から"equal"に変更し、再度送信をクリックしてください。新しいRuleロジックに基づいてチェック結果が変わるのがわかります。

1. POSTクエリdry run configurationを複製し、dry run get resource dataに名前を変更します。
2. 「Params」タブで、キーresourceDataに値trueを入力し、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バケットの名前を設定します。リソース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. 保存して送信をクリックしてください。応答は、指定されたリソースが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"
        }
      }
    ]
  }
}