Probar módulos personalizados de Security Health Analytics

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

Antes de empezar

Antes de poder probar módulos personalizados, debes cumplir los siguientes requisitos previos:

  • Todos los requisitos generales que se aplican al uso de módulos personalizados de Security Health Analytics. Para ver la lista completa de requisitos previos, consulta Usar módulos personalizados para Security Health Analytics.
  • Tu cuenta de usuario debe tener asignado uno o varios roles de gestión de identidades y accesos (IAM) que te permitan no solo trabajar con Security Command Center y módulos personalizados, sino que también incluyan el permiso securitycenter.securityhealthanalyticscustommodules.test. Para obtener más información sobre los permisos y roles que necesitas para trabajar con módulos personalizados, consulta Permisos de gestión de identidades y accesos 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 personalizados.

Crear recursos de prueba en un archivo YAML

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

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

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

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

Formato de los datos de prueba

Empieza el archivo con testData: en la primera línea, seguido de una o varias 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

Haz los cambios siguientes:

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

Ejemplos de definiciones de pruebas

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

Definición de recursos de ejemplo

En el siguiente ejemplo de definición de recurso de prueba, se prueba un módulo personalizado que comprueba si la propiedad rotationPeriod de los recursos CryptoKey supera los 2592000 segundos (30 días). Las demás propiedades de la definición no se usan en el módulo personalizado, pero siguen cumpliendo el esquema del recurso. Para ver la definición completa del módulo personalizado que prueba este ejemplo, consulta Definición de módulo personalizado de ejemplo.

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'

Definición de política de ejemplo

A continuación, se muestra un ejemplo de definición de prueba de una política de gestión de identidades y accesos:

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"

Probar un módulo personalizado

Puedes probar módulos personalizados nuevos o que ya tengas en laGoogle Cloud consola.

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 probarlo:

    • Para crear un módulo personalizado, haz clic en Crear módulo y sigue las instrucciones de Crear módulos personalizados.
    • Para abrir un módulo personalizado, haz clic en el icono de editar () situado en la sección Acciones, a la derecha de la fila del módulo que quieras probar.

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

  4. En Subir el archivo YAML, haga clic en Examinar para subir un archivo que contenga datos de recursos de ejemplo. La prueba se ejecuta en cuanto se sube el archivo YAML.

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

    • Si hay errores de sintaxis u otros errores en el archivo YAML, se mostrará un mensaje de error flotante cerca de la parte inferior de la página del navegador.

    • Si la prueba se realiza correctamente, devuelve la siguiente información:

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

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

Siguientes pasos