Testar módulos personalizados para o Security Health Analytics

Nesta página, explicamos como testar os módulos personalizados do Security Health Analytics no console do Google Cloud fazendo upload de um arquivo YAML com os dados de teste.

Antes de começar

Antes de testar módulos personalizados, você precisa atender aos seguintes pré-requisitos:

  • Todos os pré-requisitos gerais que se aplicam ao uso dos módulos personalizados do Security Health Analytics, incluindo:

    • Ativação do nível de serviço Premium
    • Ativação da API Security Command Center

    Veja a lista completa de pré-requisitos em Como usar módulos personalizados para o Security Health Analytics.

  • Sua conta de usuário precisa receber um ou mais papéis do Identity and Access Management (IAM) que permitam não apenas trabalhar com o Security Command Center e módulos personalizados, mas também incluir a permissão securitycenter.securityhealthanalyticscustommodules.test. Para saber mais sobre as permissões e os papéis necessários para trabalhar com módulos personalizados, consulte Permissões do IAM necessárias.

  • As chamadas de API para testar módulos personalizados estão sujeitas a uma cota. Para mais informações, consulte Cotas de módulos personalizados.

Criar recursos de teste em um arquivo YAML

Para testar um módulo personalizado, defina definições de recursos e definições de políticas falsas ou ambas em um arquivo YAML.

As definições não correspondem a recursos reais ou instâncias de política, mas as definições precisam estar em conformidade com os esquemas dos tipos de recursos ou políticas especificados nos módulos personalizados.

Nas definições de teste, as únicas propriedades que precisam ser especificadas são as que os módulos personalizados avaliam. Não é necessário incluir propriedades de recurso que não sejam referenciadas pelo módulo personalizado.

Para testar as expressões CEL no módulo personalizado, especifique valores de propriedade no arquivo de teste que façam com que as expressões CEL sejam resolvidas como true.

Formato dos dados de teste

Inicie o arquivo com testData: na primeira linha, seguido por uma ou mais definições 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

Substitua:

  • ARBITRARY_ASSET_NAME_N: um valor arbitrário que é exibido nos resultados do teste quando ele é bem-sucedido.
  • RESOURCE_TYPE_N: o tipo de recurso que o módulo personalizado verifica, especificado como o nome de domínio do endpoint do serviço da API e o nome do recurso, por exemplo, cloudkms.googleapis.com/CryptoKey.
  • PROPERTIES_TO_TEST_N: as propriedades usadas na lógica de detecção do módulo personalizado para acionar uma descoberta.
  • PROPERTY_VALUE_N: um valor da propriedade que aciona uma descoberta.
  • SUB_PROPERTY: uma subpropriedade ou propriedade de outro recurso ao qual o recurso de destino faz referência na definição de recursos.

Exemplos de definições de teste

Esta seção contém um exemplo de definição de recurso de teste e de política de teste. Embora os dois exemplos sejam mostrados como definidos em arquivos separados, as definições de asset para recursos e políticas podem ser combinadas em um único arquivo testData.

Exemplo de definição de recurso

O exemplo a seguir de uma definição de recurso de teste testa um módulo personalizado que verifica se a propriedade rotationPeriod dos recursos CryptoKey excede 2592000 segundos (30 dias). As outras propriedades na definição não são usadas no módulo personalizado, mas ainda estão em conformidade com o esquema do recurso. Para ver a definição completa do módulo personalizado que este exemplo testa, consulte Exemplo de definição 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'

Exemplo de definição de política

Veja a seguir um exemplo de definição de teste para uma política do 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"

Testar um módulo personalizado

É possível testar novos módulos personalizados ou módulos existentes no console do Google Cloud.

Para testar um módulo personalizado, siga estas etapas:

  1. Acesse a página Módulos do Security Health Analytics nas configurações do Security Command Center.

    Acesse Módulos

  2. Abra ou crie um módulo personalizado para teste:

    • Para criar um módulo personalizado, clique em Create module e siga as instruções em Create custom modules.
    • Para abrir um módulo personalizado, clique no ícone de edição () em Ações, no lado direito da linha do módulo que você quer testar.

  3. Selecione a guia Testar módulo.

  4. Em Fazer upload do arquivo YAML, clique em Procurar para fazer upload de um arquivo que contenha dados de amostra de recursos. O teste é executado assim que o arquivo YAML é enviado.

  5. Em Visualização dos resultados do teste, confira os resultados.

    • Se houver sintaxe ou outros erros no arquivo YAML, uma mensagem de erro flutuante será exibida perto da parte inferior da página do navegador.

    • Se o teste for bem-sucedido, ele vai retornar as seguintes informações:

      • Nome de exibição do módulo personalizado.
      • O nome arbitrário especificado na propriedade resource no arquivo de dados de teste.
      • A organização, a pasta ou o projeto em que o módulo personalizado foi ou será criado.

    Os resultados do teste não são armazenados ou gravados no Security Command Center.

A seguir