Testare i moduli personalizzati per Security Health Analytics

Questa pagina spiega come testare i moduli personalizzati di Security Health Analytics nella Google Cloud console caricando un file YAML contenente i dati di test.

Prima di iniziare

Prima di poter testare i moduli personalizzati, devi soddisfare i seguenti prerequisiti:

  • Tutti i prerequisiti generali che si applicano all'utilizzo dei moduli personalizzati di Security Health Analytics. Per l'elenco completo dei prerequisiti, consulta Utilizzo dei moduli personalizzati per Security Health Analytics.
  • Al tuo account utente devono essere concessi uno o più ruoli Identity and Access Management (IAM) che ti consentano non solo di utilizzare Security Command Center e i moduli personalizzati, ma che includano anche l'autorizzazione securitycenter.securityhealthanalyticscustommodules.test. Per saperne di più sulle autorizzazioni e sui ruoli necessari per utilizzare i moduli personalizzati, consulta Autorizzazioni IAM richieste.
  • Le chiamate API per testare i moduli personalizzati sono soggette a una quota. Per saperne di più, consulta Quote dei moduli personalizzati.

Creare risorse di test in un file YAML

Per testare un modulo personalizzato, definisci definizioni di risorse fittizie, definizioni di criteri fittizi o entrambe in un file YAML.

Le definizioni non corrispondono a istanze di risorse o criteri reali, ma devono essere conformi agli schemi dei tipi di risorse o criteri specificati nei moduli personalizzati.

Nelle definizioni di test, le uniche proprietà che devi specificare sono quelle valutate dai moduli personalizzati. Non è necessario includere le proprietà delle risorse a cui il modulo personalizzato non fa riferimento.

Per testare le espressioni CEL nel modulo personalizzato, specifica i valori delle proprietà nel file di test in modo che le espressioni CEL restituiscano true.

Formato dei dati di test

Inizia il file con testData: sulla prima riga, seguita da una o più definizioni - asset.

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

Sostituisci quanto segue:

  • ARBITRARY_ASSET_NAME_N: un valore arbitrario che viene visualizzato nei risultati del test quando il test ha esito positivo.
  • RESOURCE_TYPE_N: il tipo di asset o risorsa controllato dal modulo personalizzato, specificato come nome di dominio dell'endpoint del servizio dell'API e nome della risorsa, ad esempio cloudkms.googleapis.com/CryptoKey.
  • PROPERTIES_TO_TEST_N: le proprietà utilizzate nella logica di rilevamento del modulo personalizzato per attivare un risultato.
  • PROPERTY_VALUE_N: un valore della proprietà che attiva un risultato.
  • SUB_PROPERTY: una sotto-proprietà o una proprietà di un'altra risorsa a cui la risorsa di destinazione fa riferimento nella sua definizione di risorsa.

Esempi di definizioni di test

Questa sezione contiene un esempio di definizione di risorsa di test e una definizione di criteri di test. Sebbene i due esempi vengano mostrati come definiti in file separati, le definizioni asset per risorse e criteri possono essere combinate in un unico file testData.

Esempio di definizione di risorsa

Il seguente esempio di definizione di risorsa di test verifica un modulo personalizzato che controlla se la proprietà rotationPeriod delle risorse CryptoKey supera 2592000 secondi (30 giorni). Le altre proprietà nella definizione non vengono utilizzate nel modulo personalizzato, ma sono comunque conformi allo schema della risorsa. Per la definizione completa del modulo personalizzato testato in questo esempio, consulta Esempio di definizione di modulo personalizzato.

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'

Esempio di definizione di criteri

Di seguito è riportato un esempio di definizione di test per un criterio IAM:

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"

Testare un modulo personalizzato

Puoi testare i nuovi moduli personalizzati o quelli esistenti nella Google Cloud console.

Per testare un modulo personalizzato:

  1. Vai alla pagina Moduli di Security Health Analytics nelle impostazioni di Security Command Center.

    Vai ai moduli

  2. Apri o crea un modulo personalizzato per il test:

    • Per creare un nuovo modulo personalizzato, fai clic su Crea modulo e segui le istruzioni riportate in Creare moduli personalizzati.
    • Per aprire un modulo personalizzato esistente, fai clic sull'icona di modifica () in Azioni sul lato destro della riga del modulo che vuoi testare.

  3. Seleziona la scheda Testa modulo.

  4. In Carica il file YAML, fai clic su Sfoglia per caricare un file che contiene dati degli asset di esempio. Il test viene eseguito non appena viene caricato il file YAML.

  5. In Anteprima dei risultati del test, controlla i risultati.

    • Se nel file YAML sono presenti errori di sintassi o di altro tipo, viene visualizzato un messaggio di errore mobile nella parte inferiore della pagina del browser.

    • Se il test ha esito positivo, restituisce le seguenti informazioni:

      • Il nome visualizzato del modulo personalizzato.
      • Il nome arbitrario specificato nella proprietà resource nel file di dati di test.
      • L'organizzazione, la cartella o il progetto in cui è stato creato o verrà creato il modulo personalizzato.

    I risultati dei test non vengono archiviati o scritti in Security Command Center.

Passaggi successivi