此工作流程範例將在工作流程1的基礎上進一步幫助您使用測試自訂規則配置來創建新的自訂規則
在工作流程1中,我們將自訂規則直接儲存到組織中作為示範——這與常規或推薦的開發流程不同。相反,您應該在儲存之前使用虛擬資料來測試規則。此工作流程將展示如何通過在請求正文中傳遞規則配置並從現有帳戶資源資料中返回輸出來測試自訂規則。
-
複製名為Test saved rule的 POST 查詢並重新命名為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 儲存桶的失敗或成功檢查。在工作流程 1 中,我們使用了測試運行功能來運行已儲存到帳戶的規則,但這種替代方法允許您加快開發和測試過程,而無需先儲存配置。
-
作為測試,將「operator」從「notEqual」更改為「equal」,然後點擊再次發送 - 您將看到檢查結果根據新的規則邏輯而改變。
為其他服務建立新的自訂規則
到目前為止,我們僅在範例中使用了AWS S3。若要為其他平台和/或服務建立自訂規則,建議先建立一個簡單的虛擬規則配置,並將其與運行端點和resourceData=true結合,以便了解資源資料的結構並通知您的路徑定義。您將需要一些參數來獲取資源資料,包括所選服務的resourceId,以及等同於Conformity資料中的資源類型的descriptorType值。
以下範例使用 Azure 虛擬機資料。您必須擁有一個 Azure Subscription,並在其中託管一個與 Conformity 整合的 Azure 虛擬機資源,但此過程可應用於任何
Conformity 支援的服務或資源類型。
-
請參考以下連結以查閱服務和描述符類型的可能值(在自訂規則框架中,描述符類型映射到來自資源類型端點的「資源類型」值):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 標頭中,包含 accountIds 欄位及您選擇的 Azure Subscription(您可以透過重新執行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 查詢的主體,使用適當的 resourceId、service 和 descriptorType 從資料中構建一個簡單的虛擬規則。以下範例是一個檢查 resourceId 欄位是否填入的規則,一個簡單的 Proxy 檢查以確認資料是否存在——這足以達到返回資源資料的目的:
{ "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" } ] }
