Prueba módulos personalizados para Security Health Analytics

En esta página, se explica cómo probar los módulos personalizados de Security Health Analytics en la consola de Google Cloud mediante la carga de un archivo YAML que contenga datos de prueba.

Antes de comenzar

Antes de que puedas probar los módulos personalizados, debes cumplir con los siguientes requisitos previos:

  • Todos los requisitos previos generales que se aplican para usar los módulos personalizados de Security Health Analytics, incluidos los siguientes:

    • Activación del nivel de servicio Premium
    • Habilitación de la API de Security Command Center

    Para obtener la lista completa de requisitos previos, consulta Usa módulos personalizados para Security Health Analytics.

  • Tu cuenta de usuario debe tener una o más funciones de Identity and Access Management (IAM) que te permitan trabajar no solo con Security Command Center y módulos personalizados, sino que también incluya el permiso securitycenter.securityhealthanalyticscustommodules.test. Para obtener más información sobre los permisos y las funciones que necesitas para trabajar con módulos personalizados, consulta Permisos de IAM necesarios.

  • Las llamadas a la API para probar módulos personalizados están sujetas a una cuota. Para obtener más información, consulta Cuotas de módulos personalizadas.

Crea recursos de prueba en un archivo YAML

Para probar un módulo personalizado, define definiciones de recursos falsas, definiciones de políticas falsas o ambas en un archivo YAML.

Las definiciones no corresponden a instancias reales de recursos o políticas, pero deben cumplir con los esquemas de los tipos de recursos o políticas que se especifican en los módulos personalizados.

En las definiciones de prueba, las únicas propiedades que debes especificar son las que evalúan tus módulos personalizados. No es necesario que incluyas propiedades del recurso a las que el módulo personalizado no haga referencia.

Para probar las expresiones en CEL en el módulo personalizado, especifica los valores de propiedad en el archivo de prueba que hagan que las expresiones CEL se resuelvan en true.

Formato de los datos de prueba

Inicia el archivo con testData: en la primera línea, seguida de una o más definiciones de - 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

Reemplaza lo siguiente:

  • ARBITRARY_ASSET_NAME_N: Valor arbitrario que se muestra en los resultados de la prueba cuando esta es correcta.
  • RESOURCE_TYPE_N: Es el tipo de elemento o recurso que verifica el módulo personalizado, especificado como el nombre de dominio del extremo del servicio y el nombre del recurso de la API, por ejemplo, cloudkms.googleapis.com/CryptoKey.
  • PROPERTIES_TO_TEST_N: Son las propiedades que se usan en la lógica de detección del módulo personalizado para activar un resultado.
  • PROPERTY_VALUE_N: Es un valor de la propiedad que activa un resultado.
  • SUB_PROPERTY: Es una subpropiedad o propiedad de otro recurso al que el recurso de destino hace referencia en su definición de recurso.

Ejemplos de definiciones de prueba

En esta sección, se incluye un ejemplo de una definición de recurso de prueba y una definición de política de prueba. Aunque los dos ejemplos se muestran como definidos en archivos separados, las definiciones de asset para recursos y políticas se pueden combinar en un solo archivo testData.

Ejemplo de definición de recurso

En el siguiente ejemplo de una definición de recurso de prueba, se prueba un módulo personalizado que verifica si la propiedad rotationPeriod de los recursos CryptoKey supera los 2592000 segundos (30 días). Las otras propiedades de la definición no se usan en el módulo personalizado, pero aun así cumplen con el esquema del recurso. Para obtener la definición completa del módulo personalizado que se prueba en este ejemplo, consulta Ejemplo de definición de un módulo personalizado.

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'

Ejemplo de definición de política

El siguiente es un ejemplo de una definición de prueba para una política de 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"

Cómo probar un módulo personalizado

Puedes probar módulos personalizados nuevos o existentes en la consola de Google Cloud.

Para probar un módulo personalizado, sigue estos pasos:

  1. Ve a la página Módulos de Security Health Analytics en la configuración de Security Command Center.

    Ir a Módulos

  2. Abre o crea un módulo personalizado para realizar pruebas:

    • Para crear un nuevo módulo personalizado, haz clic en Create module y sigue las instrucciones que se indican en Cómo crear módulos personalizados.
    • Para abrir un módulo personalizado existente, haz clic en el ícono de edición () que se encuentra en Acciones, en el lado derecho de la fila del módulo que quieres probar.

  3. Selecciona la pestaña Módulo de prueba.

  4. En Subir el archivo YAML, haz clic en Explorar para subir un archivo que contenga datos de elementos de muestra. La prueba se ejecuta en cuanto se sube el archivo YAML.

  5. En Vista previa de los resultados de la prueba, revisa los resultados.

    • Si hay errores de sintaxis o de otro tipo en el archivo YAML, aparece un mensaje de error flotante cerca de la parte inferior de la página del navegador.

    • Si la prueba es exitosa, muestra la siguiente información:

      • El nombre visible del módulo personalizado.
      • El nombre arbitrario que especificas en la propiedad resource del archivo de datos de prueba.
      • La organización, la carpeta o el proyecto en el que se creó o se creará el módulo personalizado.

    Los resultados de las pruebas no se almacenan ni se escriben en Security Command Center.

¿Qué sigue?