Teste módulos personalizados para o Security Health Analytics

Esta página explica como testar módulos personalizados do Security Health Analytics na Google Cloud consola carregando um ficheiro YAML que contém dados de teste.

Antes de começar

Antes de poder testar módulos personalizados, tem de cumprir os seguintes pré-requisitos:

  • Todos os pré-requisitos gerais que se aplicam à utilização de módulos personalizados do Security Health Analytics. Para ver a lista completa de pré-requisitos, consulte o artigo Usar módulos personalizados para o Security Health Analytics.
  • A sua conta de utilizador tem de ter uma ou mais funções de gestão de identidade e acesso (IAM) que lhe permitam não só trabalhar com o Security Command Center e os módulos personalizados, mas também incluir a autorização securitycenter.securityhealthanalyticscustommodules.test. Para saber mais sobre as autorizações e as funções de que precisa para trabalhar com módulos personalizados, consulte o artigo Autorizações de IAM necessárias.
  • As chamadas da API para testar módulos personalizados estão sujeitas a uma quota. Para mais informações, consulte o artigo Quotas de módulos personalizados.

Crie recursos de teste num ficheiro YAML

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

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

Nas definições de teste, as únicas propriedades que tem de especificar são as propriedades que os seus módulos personalizados avaliam. Não precisa de incluir propriedades de recursos às quais o módulo personalizado não faz referência.

Para testar as suas expressões de IEC no módulo personalizado, especifique valores de propriedades no ficheiro de teste que façam com que as expressões de IEC sejam resolvidas como true.

Formato dos dados de teste

Comece o ficheiro com testData: na primeira linha, seguido de 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 o seguinte:

  • ARBITRARY_ASSET_NAME_N: um valor arbitrário que é apresentado nos resultados do teste quando o teste é bem-sucedido.
  • RESOURCE_TYPE_N: o tipo de recurso ou recurso que o módulo personalizado verifica, especificado como o nome do domínio do ponto final 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 deteçã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 uma propriedade de outro recurso a que o recurso de destino faz referência na respetiva definição de recurso.

Exemplos de definições de testes

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

Exemplo de definição de recurso

O exemplo seguinte 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 continuam a estar em conformidade com o esquema do recurso. Para ver a definição completa do módulo personalizado que este exemplo testa, consulte a Definição do módulo personalizado de exemplo.

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

Segue-se um exemplo de uma definição de teste para uma 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"

Teste um módulo personalizado

Pode testar novos módulos personalizados ou módulos personalizados existentes naGoogle Cloud consola.

Para testar um módulo personalizado, siga estes passos:

  1. Aceda à página Módulos do Security Health Analytics nas definições do Security Command Center.

    Aceda a Módulos

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

    • Para criar um novo módulo personalizado, clique em Criar módulo e siga as instruções em Crie módulos personalizados.
    • Para abrir um módulo personalizado existente, clique no ícone de edição () em Ações no lado direito da linha do módulo que quer testar.

  3. Selecione o separador Módulo de teste.

  4. Em Carregue o ficheiro YAML, clique em Procurar para carregar um ficheiro que contenha dados de recursos de exemplo. O teste é executado assim que o ficheiro YAML é carregado.

  5. Em Pré-visualização dos resultados do teste, verifique os resultados.

    • Se existirem erros de sintaxe ou outros erros no ficheiro YAML, é apresentada uma mensagem de erro flutuante perto da parte inferior da página do navegador.

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

      • O nome a apresentar do módulo personalizado.
      • O nome arbitrário que especifica na propriedade resource no ficheiro de dados de teste.
      • A organização, a pasta ou o projeto no qual o módulo personalizado foi ou vai ser criado.

    Os resultados dos testes não são armazenados nem escritos no Security Command Center.

O que se segue?