Ansichten:

Dieses Workflow-Beispiel führt Sie weiter von Workflow 1 und hilft Ihnen, eine neue benutzerdefinierte Regel mit der Option 'Testen einer benutzerdefinierten Regelkonfiguration' zu erstellen

Im Workflow 1 haben wir eine benutzerdefinierte Regel direkt in der Organisation gespeichert, um dies zu demonstrieren - dies unterscheidet sich vom regulären oder empfohlenen Entwicklungsablauf. Stattdessen sollten Sie eine Regel mit Dummy-Daten testen, bevor Sie sie speichern. Dieser Workflow zeigt, wie man eine benutzerdefinierte Regel testet, indem man eine Regelkonfiguration im Anforderungstext übergibt und eine Ausgabe aus den vorhandenen Kontodatenressourcen zurückgibt.
  1. Duplizieren Sie die POST-Anfrage mit dem Namen „Test gespeicherte Regel“ und benennen Sie sie um in „Testkonfiguration“.
  2. Ändern Sie den Anforderungstext, indem Sie ein accountId-Feld hinzufügen und die Details der benutzerdefinierten Regel unter Konfiguration verschieben: 
    {
	"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"
			}
		]
	}
}
  3. Klicken Sie auf Speichern und Senden. Die Antwort wird die Prüfergebnisse der Regelkonfiguration gegen die Ressourcendaten im ausgewählten Konto sein. Im obigen Beispiel sollten Sie für jeden S3-Bucket eine FEHLER- oder ERFOLGSprüfung sehen. In Workflow 1 haben wir die Testlauf-Funktion verwendet, um eine Regel auszuführen, die wir bereits im Konto gespeichert haben, aber dieser alternative Ansatz ermöglicht es Ihnen, den Entwicklungs- und Testprozess zu beschleunigen, ohne die Konfiguration zuerst speichern zu müssen.
  4. Als Test ändern Sie den "Operator" von "notEqual" zu "equal" und klicken Sie erneut auf Senden - Sie werden sehen, dass sich die Prüfergebnisse basierend auf der neuen Regel-Logik ändern.

Erstellen einer neuen benutzerdefinierten Regel für einen anderen Dienst

Bisher haben wir nur AWS S3 für unsere Beispiele verwendet. Um eine benutzerdefinierte Regel für eine andere Plattform und/oder einen anderen Dienst zu erstellen, wird empfohlen, zunächst eine einfache 'Dummy'-Regelkonfiguration zu erstellen und sie mit dem Ausführungsendpunkt und resourceData=true zu kombinieren, damit Sie die Struktur der Ressourcendaten kennenlernen und Ihre Pfaddefinitionen informieren können. Sie benötigen einige Parameter, um die Ressourcendaten zu erhalten, einschließlich einer resourceId vom gewählten Dienst sowie den descriptorType-Wert, der den Ressourcentypen in Cloud Risk Management Daten entspricht.
Das folgende Beispiel verwendet Azure Virtual Machines Daten. Sie müssen über eine Azure Subscription verfügen, die eine Azure Virtual Machine Ressource hostet, die mit Cloud Risk Management integriert ist, um dieses Beispiel zu verwenden. Der Prozess kann jedoch auf jeden Dienst oder Ressourcentyp angewendet werden, der von Cloud Risk Management unterstützt wird.
  1. Verweisen Sie auf den folgenden Link, um mögliche Werte für Service und descriptorType nachzuschlagen (descriptorType im Custom Rules-Framework wird auf Werte für "resource-types" vom resource-types Endpunkt abgebildet):
  2. Verwenden Sie Strg+F oder Cmd+F, um die Ressourcentyp-Werte für eine Azure-VM zu identifizieren. Sie sollten Folgendes vom vorherigen Endpunkt identifizieren: 
    {
      "type": "resource-types",
      "id": "virtual-machines",
      "attributes": {
        "name": "Virtual Machine",
        "provider": "azure"
      },
      "relationships": {
        "service": {
          "data": {
            "type": "services",
            "id": "VirtualMachines"
          }
        }
      }
    }
  3. Um eine Regel gegen Azure-Daten zu erstellen, führen Sie zuerst die Checks API aus, um eine Beispiel-Ressourcen-ID zu erhalten. Erstellen Sie eine neue GET-API-Abfrage mit dem Namen 'get azure check data'. Fügen Sie im TMV1-Filter-Header das Feld accountIds mit Ihrer gewählten Azure Subscription ein (dies können Sie erhalten, indem Sie die Abfrage 'list accounts' erneut ausführen). Stellen Sie sicher, dass Sie 'top' verwenden, um die Antwort zu begrenzen.
  4. Speichern und senden Sie die obige GET-Abfrage und notieren Sie den Wert für eine Beispiel-resourceId für eine bestimmte Überprüfung, bei der descriptorType = virtual-machine ist. Für Azure-virtuelle Maschinen werden Sie wahrscheinlich eine lange resourceId wie "/subscriptions/1abc1234-1234-1234-1234-abcd1d821234/resourceGroups/my-resource-group/providers/Microsoft.Compute/virtualMachines/my-special-virtual-machine" sehen
  5. Erstellen Sie eine neue POST Testbenutzerdefinierte Regelkonfiguration-Abfrage. Stellen Sie sicher, dass accountId den Wert der Azure Subscription hat, die Sie aus der Liste aller Cloud-Konten API verwenden möchten.
  6. Für den Hauptteil der Testbenutzerdefinierte Regelkonfiguration POST-Anfrage, erstellen Sie eine einfache Dummy-Regel unter Verwendung der entsprechenden resourceId, des Dienstes und des descriptorType aus den Daten. Das folgende Beispiel ist eine Regel, die überprüft, ob das resourceId-Feld ausgefüllt ist, ein einfacher Proxy-Check, ob die Daten existieren - was ausreicht, um die Ressourcendaten zurückzugeben: 
    {
	"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"
			}
		]
	}
}
  7. Klicken Sie auf Speichern und Senden. Die Antwort sollte etwa so aussehen: 
    {
	"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"
		}
	]
}