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 el La consola de Google Cloud subiendo un archivo YAML que contiene datos de prueba.

Antes de comenzar

Para poder probar los módulos personalizados, debes cumplir con lo siguiente requisitos previos:

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

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

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

  • Tu cuenta de usuario debe tener uno o más Identity and Access Management (IAM) que te permiten no solo trabajar con Security Command Center y módulos personalizados, sino que también incluye securitycenter.securityhealthanalyticscustommodules.test. Para obtener más información sobre los permisos y roles necesitas trabajar con módulos personalizados, consulta Permisos de IAM obligatorios.

  • 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.

Crea recursos de prueba en un archivo YAML

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

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

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

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

Formato de los datos de prueba

Inicia el archivo con testData: en la primera línea y, luego, 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: un valor arbitrario que se muestra en los resultados de la prueba cuando esta se completa correctamente.
  • RESOURCE_TYPE_N: Es el tipo de recurso. que el módulo personalizado verifica, especificado como el nombre de dominio de las APIs extremo de servicio y nombre de recurso, 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 hallazgo.
  • PROPERTY_VALUE_N: Es un valor de la propiedad que activa un hallazgo.
  • SUB_PROPERTY: Es una subpropiedad o propiedad de otro recurso al que hace referencia el recurso objetivo en su definición.

Ejemplos de definiciones de prueba

Esta sección contiene un ejemplo de una definición de recurso de prueba y un definición de la política de prueba. Aunque los dos ejemplos se muestran definidos en archivos separados, las definiciones de asset para recursos y políticas se pueden se combina 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 CryptoKey recursos supera los 2592000 segundos (30 días). El otro propiedades de la definición no se usan en el módulo personalizado, pero aún se ajustan al esquema del recurso. Para todas las definición del módulo personalizado que prueba este ejemplo, consulta Ejemplo de definición de 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

A continuación, se incluye un ejemplo de definición de prueba para un 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 el Consola de Google Cloud

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

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

    Ir a Módulos

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

    • Para crear un módulo personalizado nuevo, haz clic en Crear módulo y sigue las instrucciones instrucciones en Crea módulos personalizados.
    • Para abrir un módulo personalizado existente, haz clic en el botón () debajo de Actions en el lado derecho de la fila para el 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 contiene 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, verifica los resultados.

    • Si hay errores de sintaxis u otros errores en tu archivo YAML, Aparece un mensaje de error 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 en el archivo de datos de prueba.
      • La organización, la carpeta o el proyecto en el que se encontraba el módulo personalizado el proyecto.

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

¿Qué sigue?