Exportar registros para um sistema SIEM

Nesta página, descrevemos como exportar registros do Google Distributed Cloud (GDC) com isolamento físico para um sistema externo de gerenciamento de eventos e informações de segurança (SIEM, na sigla em inglês). Essa integração permite a análise centralizada de registros e um monitoramento de segurança aprimorado.

O núcleo da exportação de registros envolve a implantação de um recurso personalizado SIEMOrgForwarder. Esse recurso funciona como um arquivo de configuração, especificando os detalhes da instância externa de SIEM designada para receber os registros. Ao definir esses parâmetros no arquivo SIEMOrgForwarder, os administradores podem estabelecer um pipeline de exportação de registros simplificado e seguro.

Antes de começar

Para receber as permissões necessárias para gerenciar recursos personalizados do SIEMOrgForwarder, peça ao administrador da organização do IAM para conceder a você um dos papéis associados da organização de exportação do SIEM.

Dependendo do nível de acesso e das permissões necessárias, você pode receber papéis de criador, editor ou leitor para esse recurso no namespace do projeto. Para mais informações, consulte Preparar permissões do IAM.

Depois de receber as permissões necessárias, conclua estas etapas antes de exportar registros para um sistema SIEM externo:

1. Estabelecer conectividade: verifique se há uma conexão entre o GDC e o destino externo do SIEM. Se necessário, colabore com o operador de infraestrutura (IO, na sigla em inglês) para estabelecer uma conexão de uplink com a rede do cliente.

2. Defina as variáveis de ambiente: defina as seguintes variáveis de ambiente para executar os comandos desta página:

   • O caminho do arquivo kubeconfig:

     export KUBECONFIG=KUBECONFIG_PATH
     

     Substitua KUBECONFIG_PATH pelo caminho do arquivo kubeconfig do servidor de API Management.

   • O namespace do projeto:

     export PROJECT_NAMESPACE=PROJECT_NAMESPACE
     

Configurar a exportação de registros

Crie o secret e o recurso personalizado SIEMOrgForwarder no mesmo namespace. É possível usar qualquer namespace de projeto. Cada SIEMOrgForwarder exporta registros de plataforma de todos os clusters na organização. Portanto, não é necessário criar esses recursos em outros projetos ou clusters.

Como prática recomendada, use o namespace platform-obs porque SIEMOrgForwarder exporta apenas registros da plataforma. Os papéis de organização de exportação do SIEM também concedem acesso de leitura a todos os secrets no namespace em que são concedidos. Portanto, peça ao administrador da organização do IAM para conceder esses papéis apenas aos administradores da plataforma.

Importante: a pilha de geração de registros limita o número de novas tentativas de estabelecer uma conexão com a solução SIEM e enviar um registro de auditoria. O operador de infraestrutura pode configurar manualmente o número exato de novas tentativas, mas o padrão é definido como cinco. Se a conexão falhar após as novas tentativas especificadas, a pilha de geração de registros não enviará registros de auditoria para a solução SIEM.

Exportar registros para um sistema SIEM externo:

1. Forneça um token para conectar a pilha de geração de registros ao sistema SIEM. Para realizar essa ação, crie um secret no namespace do projeto para armazenar o token no caso do Splunk e a senha no caso do Elastic SIEM:

   cat <<EOF | kubectl --kubeconfig=${KUBECONFIG} apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: SECRET_NAME
     namespace: ${PROJECT_NAMESPACE}
   type: Opaque
   stringData:
     SECRET_FIELD: FIELD_VALUE
   EOF
   

   Substitua:

   • SECRET_NAME: o nome do secret.
   • SECRET_FIELD: o nome do campo em que você quer armazenar o secret. Para o Elastic, use o mesmo valor de HTTP_USER_NAME no recurso personalizado.
   • FIELD_VALUE: FIELD_VALUE é o token no caso do Splunk e a senha no caso do Elastic.
   • TOKEN: seu token.
   Observação :use tokens separados para registros de auditoria e operacionais, implantando dois secrets de acordo. É necessário referenciar o nome do secret correspondente no recurso personalizado SIEMOrgForwarder.

2. Implante o recurso personalizado SIEMOrgForwarder no namespace do projeto. É preciso especificar o tipo de registro escolhendo entre registros de auditoria ou operacionais. Para configurar a exportação de registros para os dois tipos de registro, implante um recurso SIEMOrgForwarder para cada tipo.

   Importante: o recurso personalizado SIEMOrgForwarder precisa estar no mesmo namespace que o Secret criado na etapa anterior.

   O exemplo a seguir mostra como aplicar uma configuração a um recurso personalizado SIEMOrgForwarder para o Splunk:

     cat <<EOF | kubectl --kubeconfig=${KUBECONFIG} apply -f -
     apiVersion: logging.gdc.goog/v1
     kind: SIEMOrgForwarder
     metadata:
       name: SIEM_ORG_FORWARDER
       namespace: ${PROJECT_NAMESPACE}
     spec:
       source: LOG_TYPE
       destinations:
         splunkOutputs:
           - host: SIEM_HOST
             token:
               name: SECRET_NAME
               field: SECRET_FIELD
             tls: "TLS"
             netConnectTimeout: NET_CONNECT_TIMEOUT
     EOF
   

   Substitua:

   • SIEM_ORG_FORWARDER: o nome do arquivo de definição de SIEMOrgForwarder.
   • LOG_TYPE: o tipo de registro que você está exportando. Os valores aceitos são audit e operational.
   • SIEM_HOST: o nome do host do SIEM.
   • SECRET_NAME: o nome do secret.
   • SECRET_FIELD: o nome do campo em que você armazenou o secret.
   • TLS: o status do Transport Layer Security (TLS). Os valores aceitos são "On" e "Off".
   • NET_CONNECT_TIMEOUT: o tempo máximo em segundos de espera para que uma conexão seja estabelecida. Por exemplo, um valor de 180 significa esperar 180 segundos.

   O exemplo a seguir mostra como aplicar uma configuração a um recurso personalizado SIEMOrgForwarder para o Elastic:

     cat <<EOF | kubectl --kubeconfig=${KUBECONFIG} apply -f -
     apiVersion: logging.gdc.goog/v1
     kind: SIEMOrgForwarder
     metadata:
       name: SIEM_ORG_FORWARDER
       namespace: ${PROJECT_NAMESPACE}
     spec:
       source: LOG_TYPE
       destinations:
         elasticOutputs:
           - host: SIEM_HOST
             port: SIEM_PORT
             http_credential:
               http_user: HTTP_USER_NAME
               http_passwd: SECRET_NAME
             tls: "TLS"
             netConnectTimeout: NET_CONNECT_TIMEOUT
             index: INDEX
     EOF
   

   Substitua:

   • SIEM_ORG_FORWARDER: o nome do arquivo de definição de SIEMOrgForwarder.
   • LOG_TYPE: o tipo de registro que você está exportando. Os valores aceitos são audit e operational.
   • SIEM_HOST: o nome do host do SIEM.
   • SIEM_PORT: a porta da instância do SIEM.
   • HTTP_USER_NAME: o nome de usuário da instância do SIEM. Esse valor também precisa ser a chave SECRET_FIELD no secret que armazena a senha.
   • SECRET_NAME: o nome do secret.
   • TLS: o status do Transport Layer Security (TLS). Os valores aceitos são "On" e "Off".
   • NET_CONNECT_TIMEOUT: o tempo máximo em segundos de espera para que uma conexão seja estabelecida. Por exemplo, um valor de 180 significa esperar 180 segundos.
   • INDEX: o índice da instância do Elastic. Se não for especificado, o tipo de registro (audit ou operational) será usado. Este campo é opcional.

3. Verifique o status do recurso personalizado SIEMOrgForwarder implantado:

     kubectl --kubeconfig=${KUBECONFIG} describe siemorgforwarder/SIEM_ORG_FORWARDER \
         -n ${PROJECT_NAMESPACE}
   

   De acordo com o tipo de registro, verifique o seguinte status:

   • Registros de auditoria: verifique o status de AuditLoggingReady.

   • Registros operacionais: verifique o status de OperationalLoggingReady.

     Observação: pode levar alguns minutos para que as mudanças sejam propagadas e o status seja atualizado.