このワークフロー例は、ワークフロー1からさらに進み、カスタムルール設定のテストを使用して新しいカスタムルールを作成するのに役立ちます
ワークフロー1では、デモンストレーションとしてカスタムルールを組織に直接保存しましたが、これは通常または推奨される開発フローとは異なります。代わりに、保存する前にダミーデータでルールをテストすることをお勧めします。このワークフローでは、リクエストボディにルール構成を渡し、既存のアカウントリソースデータから出力を返すことでカスタムルールをテストする方法を示します。
-
POSTクエリTest saved ruleを複製し、Test configurationに名前を変更します。
-
リクエストボディを修正し、accountIdフィールドを追加し、カスタムルールの詳細をconfigurationの下に移動してください。
{ "accountId": "a0b1c2d3-e4f5-a6b7-c8d9-e0f1a2b3c4d5", "configuration": { "name": "S3 bucket has any Encryption", "description": "We want to demonstrate Custom Rules V1", "categories": ["security"], "riskLevel": "MEDIUM", "provider": "aws", "enabled": true, "service": "S3", "resourceType": "s3-bucket", "remediationNote": "To remediate, follow these steps:\n1. Step one \n2. Step two\n", "attributes": [ { "name": "bucketEncryption", "path": "data.Encryption", "required": true } ], "eventRules": [ { "conditions": { "all": [ { "fact": "bucketEncryption", "operator": "notEqual", "value": null } ] }, "description": "Bucket has encryption enabled" } ] } } -
保存して送信をクリックします。対応は、選択したアカウント内のリソースデータに対するルール設定のチェック結果になります。上記の例では、各S3 bucketに対してFAILUREまたはSUCCESSのチェックが表示されるはずです。ワークフロー1では、すでにアカウントに保存したルールを実行するためにテスト実行機能を使用しましたが、この代替アプローチでは、最初に設定を保存する必要なく、開発とテストプロセスを迅速化することができます。
-
テストとして、「operator」を「notEqual」から「equal」に変更し、再度送信をクリックしてください。新しいルールロジックに基づいてチェック結果が変わるのがわかります。
別のサービス用の新しいカスタムルールを作成中
これまでのところ、例としてはAWS S3のみを使用してきました。他のプラットフォームやサービスのカスタムルールを作成するには、まずシンプルなダミールール構成を作成し、それを実行エンドポイントとresourceData=trueと組み合わせることをお勧めします。これにより、リソースデータの構造を学び、パス定義に役立てることができます。リソースデータを取得するには、選択したサービスからのresourceIdや、Conformityのデータ内のリソースタイプに相当するdescriptorType値など、いくつかのパラメータが必要です。
次の例ではAzure Virtual Machinesデータを使用します。この例を実行するには、Conformityと統合されたAzure Virtual MachineリソースをホストするAzure
Subscriptionが必要ですが、このプロセスはConformityがサポートする任意のサービスやリソースタイプに適用できます。
-
以下のリンクを参照して、サービスとdescriptorTypeの可能な値をレファレンスしてください (Custom RulesフレームワークのdescriptorTypeは、resource-typesエンドポイントからの「resource-types」の値にマップされます): https://us-west-2.cloudconformity.com/v1/resource-types
-
ctrl+fまたはcmd+fを使用して、Azure仮想マシンのリソースタイプ値を特定します。前のエンドポイントから以下を特定する必要があります。
{ "type": "resource-types", "id": "virtual-machines", "attributes": { "name": "Virtual Machine", "provider": "azure" }, "relationships": { "service": { "data": { "type": "services", "id": "VirtualMachines" } } } } -
Azureデータに対するルールを作成するには、まずChecks APIを実行して例のリソースIDを取得します。get azure check dataという新しいGET APIクエリを作成します。TMV1-Filterヘッダーには、選択したAzure Subscriptionを含むaccountIdsフィールドを含めます (list accountsクエリを再実行することで取得できます)。対応を制限するためにtopを使用することを確認してください。
-
上記の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が表示される可能性があります
-
新しいPOSTカスタムルール設定のテストクエリを作成します。すべてのCloud AccountsをリストするAPIから使用したいAzure Subscriptionの値をaccountIdに設定してください。
-
テストカスタムルール構成のPOSTクエリの本文には、データから適切なresourceId、service、descriptorTypeを使用してシンプルなダミールールを構築します。以下の例は、resourceIdフィールドが埋められているかを確認するルールで、データが存在するかどうかを確認するための簡単なプロキシチェックです。これは、リソースデータを返すという目的には十分です。
{ "accountId": "a0b1c2d3-e4f5-a6b7-c8d9-e0f1a2b3c4d5", "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", "riskLevel": "LOW", "enabled": true, "provider": "azure", "categories": ["security"], "remediationNote": "Check if resource exists", "attributes": [ { "name": "exists", "path": "resourceId", "required": true } ], "eventRules": [ { "conditions": { "all": [ { "fact": "exists", "operator": "notEqual", "value": null } ] }, "description": "Resource exists" } ] } } - 保存して送信をクリックしてください。対応は次のようになります。
{ "resourceId": "/subscriptions/27b11718-e2c4-4336-b3d6-ac291d8299d3/resourceGroups/CFX-WALLACE-RG/providers/Microsoft.Compute/virtualMachines/double-encrypted-vm", "region": "global", "status": "SUCCESS", "description": "Virtual Machine double-encrypted-vm passed 'Resource exists' rule condition.", "extraData": [ { "name": "successEvent", "label": "Passed Condition Event", "value": "Resource exists", "type": "META" } ] }
