Auf dieser Seite wird erläutert, wie Sie benutzerdefinierte Module für Security Health Analytics in derGoogle Cloud -Konsole testen, indem Sie eine YAML-Datei mit Testdaten hochladen.
Hinweise
Bevor Sie benutzerdefinierte Module testen können, müssen die folgenden Voraussetzungen erfüllt sein:
- Alle allgemeinen Voraussetzungen, die für die Verwendung von benutzerdefinierten Modulen für Security Health Analytics gelten. Eine vollständige Liste der Voraussetzungen finden Sie unter Benutzerdefinierte Module für Security Health Analytics verwenden.
- Ihrem Nutzerkonto muss mindestens eine IAM-Rolle (Identity and Access Management) zugewiesen sein, mit der Sie nicht nur mit Security Command Center und benutzerdefinierten Modulen arbeiten können, sondern die auch die Berechtigung
securitycenter.securityhealthanalyticscustommodules.test
enthält. Weitere Informationen zu den Berechtigungen und Rollen, die Sie für die Arbeit mit benutzerdefinierten Modulen benötigen, finden Sie unter Erforderliche IAM-Berechtigungen. - Für API-Aufrufe zum Testen benutzerdefinierter Module gilt ein Kontingent. Weitere Informationen finden Sie unter Kontingente für benutzerdefinierte Module.
Testressourcen in einer YAML-Datei erstellen
Wenn Sie ein benutzerdefiniertes Modul testen möchten, definieren Sie in einer YAML-Datei gefälschte Ressourcendefinitionen, gefälschte Richtliniendefinitionen oder beides.
Die Definitionen entsprechen nicht echten Ressourcen- oder Richtlinieninstanzen, müssen aber den Schemas der Ressourcen- oder Richtlinientypen entsprechen, die in Ihren benutzerdefinierten Modulen angegeben sind.
In Ihren Testdefinitionen müssen Sie nur die Properties angeben, die von Ihren benutzerdefinierten Modulen ausgewertet werden. Sie müssen keine Ressourcenattribute angeben, auf die im benutzerdefinierten Modul nicht verwiesen wird.
Wenn Sie Ihre CEL-Ausdrücke im benutzerdefinierten Modul testen möchten, geben Sie in der Testdatei Attributwerte an, die dazu führen, dass die CEL-Ausdrücke in true
aufgelöst werden.
Format der Testdaten
Beginnen Sie die Datei in der ersten Zeile mit testData:
, gefolgt von einer oder mehreren - asset
-Definitionen.
testData: - asset: resource: ARBITRARY_ASSET_NAME_1 assetType: RESOURCE_TYPE_1 resourceData: PROPERTIES_TO_TEST_1: PROPERTY_VALUE_1 SUB_PROPERTY: SUB_PROPERTY_VALUE PROPERTIES_TO_TEST_2: PROPERTY_VALUE_2 - asset: resource: ARBITRARY_ASSET_NAME_2 assetType: RESOURCE_TYPE_2 iamPolicyData: PROPERTIES_TO_TEST_3: PROPERTY_VALUE_3 PROPERTIES_TO_TEST_4: PROPERTY_VALUE_4
Ersetzen Sie Folgendes:
ARBITRARY_ASSET_NAME_N
: Ein beliebiger Wert, der in den Testergebnissen angezeigt wird, wenn der Test erfolgreich ist.RESOURCE_TYPE_N
: Der Typ des Assets oder der Ressource, die vom benutzerdefinierten Modul geprüft wird. Er wird als Domainname des Dienstendpunkts der API und als Ressourcenname angegeben, z. B.cloudkms.googleapis.com/CryptoKey
.PROPERTIES_TO_TEST_N
: Die Eigenschaften, die in der Erkennungslogik des benutzerdefinierten Moduls verwendet werden, um ein Ergebnis auszulösen.PROPERTY_VALUE_N
: Ein Wert der Property, der ein Ergebnis auslöst.SUB_PROPERTY
: Eine untergeordnete Property oder Property einer anderen Ressource, auf die die Zielressource in ihrer Ressourcendefinition verweist.
Beispiel für Testdefinitionen
Dieser Abschnitt enthält ein Beispiel für eine Testressourcendefinition und eine Testrichtliniendefinition. Obwohl die beiden Beispiele in separaten Dateien definiert sind, können asset
-Definitionen für Ressourcen und Richtlinien in einer einzigen testData
-Datei kombiniert werden.
Beispiel für eine Ressourcendefinition
Im folgenden Beispiel für eine Testressourcendefinition wird ein benutzerdefiniertes Modul getestet, das prüft, ob das Attribut rotationPeriod
von CryptoKey
-Ressourcen 2592000
Sekunden (30 Tage) überschreitet. Die anderen Eigenschaften in der Definition werden im benutzerdefinierten Modul nicht verwendet, entsprechen aber weiterhin dem Schema der Ressource. Die vollständige Definition des benutzerdefinierten Moduls, das in diesem Beispiel getestet wird, finden Sie unter Beispiel für die Definition eines benutzerdefinierten Moduls.
testData: - asset: resource: THE CRYPTOKEY TEST WAS SUCCESSFUL! assetType: cloudkms.googleapis.com/CryptoKey resourceData: nextRotationTime: '2020-02-05T12:00:55.192645Z' primary: state: 'ENABLED' purpose: 'ENCRYPT_DECRYPT' rotationPeriod: '2592001s'
Beispiel für eine Richtliniendefinition
Das folgende Beispiel zeigt eine Testdefinition für eine IAM-Richtlinie:
testData: - asset: resource: //cloudresourcemanager.googleapis.com/projects/fake-project assetType: cloudresourcemanager.googleapis.com/Project iamPolicyData: bindings: - role: "roles/viewer" members: - "serviceAccount:fake-service-account@compute-system.iam.gserviceaccount.com" - "user:fake-email-account"
Benutzerdefiniertes Modul testen
Sie können neue oder vorhandene benutzerdefinierte Module in derGoogle Cloud -Konsole testen.
So testen Sie ein benutzerdefiniertes Modul:
Rufen Sie in den Security Command Center-Einstellungen die Seite Module von Security Health Analytics auf.
Öffnen oder erstellen Sie ein benutzerdefiniertes Modul zum Testen:
- Wenn Sie ein neues benutzerdefiniertes Modul erstellen möchten, klicken Sie auf Modul erstellen und folgen Sie der Anleitung unter Benutzerdefinierte Module erstellen.
- Wenn Sie ein vorhandenes benutzerdefiniertes Modul öffnen möchten, klicken Sie in der Zeile des Moduls, das Sie testen möchten, rechts unter Aktionen auf das Symbol „Bearbeiten“ edit.
Wählen Sie den Tab Testmodul (Testmodul) aus.
Klicken Sie unter YAML-Datei hochladen auf Durchsuchen, um eine Datei mit Beispiel-Asset-Daten hochzuladen. Der Test wird ausgeführt, sobald die YAML-Datei hochgeladen wurde.
Sehen Sie sich unter Vorschau der Testergebnisse die Ergebnisse an.
- Wenn Ihre YAML-Datei Syntax- oder andere Fehler enthält, wird unten auf der Browserseite eine schwebende Fehlermeldung angezeigt.
Wenn der Test erfolgreich ist, werden die folgenden Informationen zurückgegeben:
- Der Anzeigename des benutzerdefinierten Moduls.
- Der beliebige Name, den Sie für das Attribut
resource
in der Testdatendatei angeben. - Die Organisation, der Ordner oder das Projekt, in dem das benutzerdefinierte Modul erstellt wurde oder wird.
Testergebnisse werden nicht gespeichert oder in Security Command Center geschrieben.
Nächste Schritte
- Weitere Informationen zur Verwendung benutzerdefinierter Module finden Sie unter Benutzerdefinierte Module für Security Health Analytics verwenden.
- Informationen zum Arbeiten mit Ergebnissen in der Google Cloud Console finden Sie unter Mit Ergebnissen arbeiten.