Testa i moduli personalizzati per Security Health Analytics

Questa pagina spiega come testare i moduli personalizzati di Security Health Analytics nella console Google Cloud 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 di Security Health Analytics moduli personalizzati, tra cui:

    • Attivazione del livello di servizio Premium
    • Attivazione dell'API Security Command Center

    Per l'elenco completo dei prerequisiti, vedi Utilizzo dei moduli personalizzati per Security Health Analytics.

  • Al tuo account utente deve essere concesso uno o più IAM (Identity and Access Management) che ti consentono non solo di lavorare con Security Command Center moduli personalizzati, ma include anche 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 ulteriori informazioni, consulta le quote per i moduli personalizzati.

Creare risorse di test in un file YAML

Per testare un modulo personalizzato, definisci definizioni di risorse e criteri falsi 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 del test, le uniche proprietà che devi specificare sono le proprietà valutate dai moduli personalizzati. Non è necessario includere le proprietà delle risorse a cui non fa riferimento il modulo personalizzato.

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

Formato dei dati di test

Inizia il file con testData: nella prima riga, seguito 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 vengono visualizzati nei risultati del test quando il test ha esito positivo.
  • RESOURCE_TYPE_N: il tipo di risorsa o asset controllato dal modulo personalizzato, specificato come nome di dominio dell'endpoint di servizio e della risorsa dell'API, 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 proprietà secondaria o una proprietà di un'altra risorsa a cui la risorsa di destinazione fa riferimento nella relativa definizione.

Esempi di definizioni del test

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

Definizione di risorsa di esempio

Il seguente esempio di definizione di una risorsa di test testa un modulo personalizzato che verifica se la proprietà rotationPeriod CryptoKey risorse superano 2592000 secondi (30 giorni). L'altro della definizione non vengono utilizzate nel modulo personalizzato, ma siano conformi allo schema della risorsa. Per l'intera definizione del modulo personalizzato che questo esempio sottopone a test, 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'

Definizione dei criteri di esempio

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"

Testa un modulo personalizzato

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

Per testare un modulo personalizzato, segui questi passaggi:

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

    Vai a Moduli

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

    • Per creare un nuovo modulo personalizzato, fai clic su Crea modulo e segui le istruzioni 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 Modulo di test.

  4. In Carica il file YAML, fai clic su Sfoglia per caricare un file contenente dati di 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 il file YAML contiene errori di sintassi o altri errori, un file nella parte inferiore della pagina del browser.
    • Se ha esito positivo, il test restituisce le seguenti informazioni:

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

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

Passaggi successivi