Testare 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 dei moduli personalizzati di Security Health Analytics, tra cui:

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

    Per l'elenco completo dei prerequisiti, consulta Utilizzare i moduli personalizzati per Security Health Analytics.

  • Al tuo account utente devono essere concessi uno o più ruoli IAM (Identity and Access Management) 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 ulteriori informazioni, consulta Quote dei moduli personalizzati.

Creare risorse di test in un file YAML

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

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 visualizzato nei risultati del test quando il test è riuscito.
  • 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 rilevamento.
  • SUB_PROPERTY: una proprietà secondaria o una proprietà di un'altra risorsa a cui la risorsa di destinazione fa riferimento nella relativa definizione.

Definizioni di test di esempio

Questa sezione contiene un esempio di definizione di una risorsa di test e di una definizione di 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 controlla se la proprietà rotationPeriod delle risorseCryptoKey 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 Definizione di un modulo personalizzato di esempio.

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 di 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"

Testare un modulo personalizzato

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

Per testare un modulo personalizzato:

  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 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 il modulo.

  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 di altro tipo, nella parte inferiore della pagina del browser viene visualizzato un messaggio di errore.

    • Se il test va a buon fine, restituisce le seguenti informazioni:

      • Il nome visualizzato del modulo personalizzato.
      • Il nome arbitrario specificato per la proprietà resource nel 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