Benutzerdefinierte Module für Security Health Analytics testen

Auf dieser Seite wird erläutert, wie Sie benutzerdefinierte Module von Security Health Analytics in der Google Cloud Console testen, indem Sie eine YAML-Datei mit Testdaten hochladen.

Hinweise

Bevor Sie benutzerdefinierte Module testen können, müssen Sie die folgenden Voraussetzungen erfüllen:

  • Alle allgemeinen Voraussetzungen für die Verwendung benutzerdefinierter Security Health Analytics-Module, darunter:

    • Aktivierung der Premium-Dienststufe
    • Aktivierung der Security Command Center API

    Eine vollständige Liste der Voraussetzungen finden Sie unter Benutzerdefinierte Module für Security Health Analytics verwenden.

  • Ihrem Nutzerkonto muss eine oder mehrere IAM-Rollen (Identity and Access Management) gewährt werden, die es Ihnen ermöglichen, nicht nur mit Security Command Center und benutzerdefinierten Modulen zu arbeiten, sondern auch mit der Berechtigung securitycenter.securityhealthanalyticscustommodules.test. Weitere Informationen zu den Berechtigungen und Rollen, die Sie für die Arbeit mit benutzerdefinierten Modulen benötigen, finden Sie unter Erforderliche IAM-Berechtigungen.

  • API-Aufrufe zum Testen benutzerdefinierter Module unterliegen einem Kontingent. Weitere Informationen finden Sie unter Benutzerdefinierte Modulkontingente.

Testressourcen in einer YAML-Datei erstellen

Zum Testen eines benutzerdefinierten Moduls definieren Sie in einer YAML-Datei gefälschte Ressourcendefinitionen, falsche Richtliniendefinitionen oder beides.

Die Definitionen entsprechen nicht realen Ressourcen- oder Richtlinieninstanzen. Sie müssen jedoch den Schemas der Ressourcen- oder Richtlinientypen entsprechen, die in Ihren benutzerdefinierten Modulen angegeben sind.

In Ihren Testdefinitionen müssen nur die Attribute angegeben werden, die von Ihren benutzerdefinierten Modulen ausgewertet werden. Sie müssen keine Ressourcenattribute angeben, auf die das benutzerdefinierte Modul nicht verweist.

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 mit testData: in der ersten Zeile, 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, das bzw. die vom benutzerdefinierten Modul geprüft wird, angegeben als Domainname des Dienstendpunkts und Ressourcenname der API, z. B. cloudkms.googleapis.com/CryptoKey.
  • PROPERTIES_TO_TEST_N: Die Attribute, die in der Erkennungslogik des benutzerdefinierten Moduls verwendet werden, um ein Ergebnis auszulösen.
  • PROPERTY_VALUE_N: Ein Wert der Eigenschaft, die ein Ergebnis auslöst.
  • SUB_PROPERTY: Eine untergeordnete Property oder Property einer anderen Ressource, auf die die Zielressource in ihrer Ressourcendefinition verweist.

Beispieltestdefinitionen

Dieser Abschnitt enthält ein Beispiel für eine Testressourcendefinition und eine Testrichtliniendefinition. Obwohl die beiden Beispiele in separaten Dateien definiert werden, können asset-Definitionen für Ressourcen und Richtlinien in einer einzigen testData-Datei kombiniert werden.

Beispiel für 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 Attribute in der Definition werden nicht im benutzerdefinierten Modul verwendet, entsprechen aber weiterhin dem Schema der Ressource. Die vollständige Definition des benutzerdefinierten Moduls, das in diesem Beispiel getestet wird, finden Sie unter 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 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 der Google Cloud Console testen.

So testen Sie ein benutzerdefiniertes Modul:

  1. Rufen Sie in den Security Command Center-Einstellungen die Seite Module von Security Health Analytics auf.

    Zu den Modulen

  2. Öffnen oder erstellen Sie ein benutzerdefiniertes Modul zum Testen:

    • Klicken Sie zum Erstellen eines neuen benutzerdefinierten Moduls auf Modul erstellen und folgen Sie der Anleitung unter Benutzerdefinierte Module erstellen.
    • Wenn Sie ein vorhandenes benutzerdefiniertes Modul öffnen möchten, klicken Sie rechts in der Zeile des zu testenden Moduls unter Aktionen auf das Symbol „Bearbeiten“ ().
  3. Wählen Sie den Tab Testmodul (Testmodul) aus.

  4. 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.

  5. Sehen Sie sich die Ergebnisse unter Vorschau der Testergebnisse an.

    • Wenn die YAML-Datei Syntax- oder andere Fehler enthält, wird unten auf der Browserseite eine Floating-Fehlermeldung angezeigt.
    • Wenn der Test erfolgreich ist, gibt er die folgenden Informationen zurück:

      • Der Anzeigename des benutzerdefinierten Moduls.
      • Der beliebige Name, den Sie in der Testdatendatei für das Attribut resource angeben.
      • Die Organisation, der Ordner oder das Projekt, in dem das benutzerdefinierte Modul erstellt wurde oder erstellt wird.

    Testergebnisse werden nicht in Security Command Center gespeichert oder geschrieben.

Nächste Schritte