Prueba módulos personalizados para las estadísticas del estado de la seguridad

En esta página, se explica cómo probar módulos personalizados de las estadísticas de estado de seguridad en la console de Google Cloud subiendo un archivo YAML que contenga datos de prueba.

Antes de comenzar

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

  • Todos los requisitos previos generales que se aplican al uso de 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 los requisitos previos, consulta Cómo usar módulos personalizados para las estadísticas del estado de seguridad.

  • Se debe otorgar a tu cuenta de usuario uno o más roles de Identity and Access Management (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 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, debes definir definiciones de recursos o 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 tus 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 incluyas propiedades de recursos a las que no haga referencia el módulo personalizado.

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

Formato de los datos de prueba

Inicia el archivo con testData: en la primera línea, seguido 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: Es un valor arbitrario que se muestra en los resultados de la prueba cuando esta se realiza correctamente.
  • RESOURCE_TYPE_N: Es el tipo de activo o recurso que verifica el módulo personalizado, especificado como el nombre de dominio del extremo de 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 hallazgo.
  • 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 hace referencia el recurso de destino en su definición de recurso.

Definiciones de pruebas de ejemplo

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 recursos

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 aún cumplen con el esquema del recurso. Para obtener la definición completa 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

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"

Prueba 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 en Crea módulos personalizados.
    • Para abrir un módulo personalizado existente, haz clic en el ícono de edición () en Acciones, a la derecha de la fila del módulo que deseas 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 recursos 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 o de otro tipo 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, muestra la siguiente información:

      • Es el nombre visible del módulo personalizado.
      • Es 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?