Modelo de blueprint do Anthos: auditoria e monitoramento de desvios da política

Neste documento, descrevemos como auditar e monitorar seus clusters do Anthos para determinar se houve um desvio das práticas recomendadas de segurança e das políticas anexadas a elas. Ele inclui uma visão geral de como e por que você audita e monitora as políticas, além de descrever os controles do Google Cloud usados para essa tarefa.

O documento faz parte de uma série de blueprints que fornecem orientação sobre como trabalhar com o Anthos. Para mais informações sobre esses blueprints, consulte Blueprints de segurança do Anthos: perguntas frequentes (em inglês).

Introdução

Seu cluster tem políticas que protegem o acesso aos recursos. É possível aumentar a segurança auditando e monitorando o desvio dessas políticas. A auditoria e o monitoramento fornecem insights sobre o status atual do cluster, mas não impedem nenhuma ação que possa burlar as políticas. Para ajudar na proteção contra alterações, você também precisa tomar medidas para aplicar políticas.

O monitoramento é semelhante à auditoria, mas tem uma finalidade um pouco diferente. Uma solução de monitoramento típica consiste em uma maneira de coletar métricas, painéis para visualizar o status de seus sistemas e aplicativos e uma maneira de enviar alertas quando anomalias são detectadas. Por outro lado, a auditoria é usada para validar o status dos sistemas, normalmente em relação a um conjunto de políticas que você definiu que precisam ser atendidas.

Para auditoria e monitoramento, considere os seguintes requisitos:

  • Quais controles de aplicação você tem e como auditar ou monitorar os desvios da política
  • Se você precisa de uma solução de monitoramento consolidada ou de uma segregada

Noções básicas dos controles de segurança necessários

Nesta seção, discutiremos os controles necessários para fazer o seguinte:

  • Implementar a auditoria que complemente a aplicação da política conforme descrito no guia de aplicação de políticas.

  • Implementar uma solução de monitoramento que funcione com clusters do Anthos GKE, não importa onde eles sejam implantados.

Namespaces

Como rotular recursos que precisam usar as mesmas políticas

Os namespaces permitem fornecer um escopo para recursos relacionados em um cluster, por exemplo, pods, serviços e controladores de replicação. Ao usar namespaces, é possível delegar a responsabilidade de administração dos recursos relacionados como uma unidade. Portanto, os namespaces são essenciais para a maioria dos padrões de segurança.

Os namespaces são um recurso importante para o isolamento do plano de controle. No entanto, eles não fornecem isolamento de nós, de plano de dados ou de rede.

Uma abordagem comum é criar namespaces para aplicativos individuais. Por exemplo, é possível criar o namespace myapp-frontend para o componente de IU de um aplicativo.

Anthos Config Management

Como aplicar configurações aos clusters do Anthos

Uma prática recomendada ao gerenciar clusters do Anthos é usar o Anthos Config Management, que mantém os clusters inscritos sincronizados com os configs. Um config é um arquivo YAML ou JSON armazenado no seu repositório, e que contém os mesmos tipos de detalhes de configuração que podem ser aplicados manualmente a um cluster usando o comando kubectl apply. O Anthos Config Management permite que você gerencie políticas e implantações de infraestrutura como você faz com os apps: adotando uma abordagem declarativa.

Use o Anthos Config Management com um repositório Git que atua como a única fonte confiável para as políticas declaradas. O Anthos Config Management pode gerenciar políticas de controle de acesso, como RBAC, cotas de recursos, namespaces e implantações de infraestrutura no nível da plataforma. O Anthos Config Management é declarativo. Ele verifica continuamente o estado do cluster e aplica o estado declarado na configuração para aplicar políticas.

Anthos Policy Controller

Como aplicar a conformidade com as políticas

O Anthos Policy Controller é um controlador de admissão dinâmico para o Kubernetes que aplica políticas baseadas na definição de recursos personalizados (CRD, na sigla em inglês) executadas pelo Open Policy Agent (OPA).

Os controladores de admissão são plug-ins do Kubernetes que interceptam solicitações ao servidor da API Kubernetes antes da permanência de um objeto, mas após a autenticação e autorização da solicitação. É possível usar controladores de admissão para limitar o uso de um cluster.

Para usar o controlador de política, declare um conjunto de restrições em um modelo de restrição (em inglês). Quando o modelo de restrição estiver implantado no cluster, será possível criar CRDs de restrição(em inglês) individuais que são definidos pelo modelo de restrição.

O diagrama a seguir mostra como o controlador de políticas usa a estrutura de restrições do OPA (em inglês) para definir e aplicar a política.

O framework de restrição de OPA recebe solicitações e aplica políticas para acesso a outros recursos.

O diagrama mostra o seguinte fluxo:

  1. As restrições são criadas a partir de modelos de restrição.
  2. As políticas são ativadas no cluster aplicando restrições.
  3. Uma solicitação é recebida e uma revisão de admissão é acionada, resultando em uma decisão de permissão ou negação.
  4. Uma auditoria contínua avalia todos os objetos ativos no cluster em relação às políticas.

Com o controlador de políticas, é possível aplicar políticas personalizadas, como a aplicação de rótulos. O controlador de políticas permite aplicar a maioria das restrições que podem ser aplicadas usando o PodSecurityPolicies (em inglês). No entanto, eles normalmente exigem menos sobrecarga operacional pelos seguintes motivos:

  • O controlador de políticas inclui uma biblioteca de modelos padrão que inclui modelos de restrição, o que significa que você não precisa escrever suas próprias políticas para casos comuns, como faz com o PodSecurityPolicies.
  • Você não precisa gerenciar RoleBindings como quando usa o PodSecurityPolicies.
  • O Policy Controller é compatível com o modo de simulação para que você possa validar o efeito de uma restrição antes de aplicá-la.
  • É possível definir políticas para namespaces, o que dá a você a oportunidade de realizar um aumento mais lento das políticas mais restritivas. Isso é semelhante a uma estratégia de versão canário, em que você gerencia a exposição de políticas de lançamento que podem ter efeitos inesperados. Por exemplo, o lançamento pode revelar que você restringiu o acesso a um volume de um pod, mas que o pod precisa ter acesso ao volume.
  • O Policy Controller fornece uma única maneira de aplicar políticas, sejam elas restrições personalizadas ou restrições do PodSecurityPolicies definidas no repositório do Gatekeeper (em inglês).

Para mais informações sobre como usar o Policy Controller para aplicar políticas definidas por você, consulte Anthos Config Policy Controller Management.

Cloud Operations para GKE

Como monitorar clusters do GKE

O Cloud Operations para o GKE foi projetado para monitorar clusters do GKE. Ele gerencia os serviços do Cloud Monitoring e do Cloud Logging juntos e apresenta um painel de operações do Cloud para o GKE personalizado para clusters do GKE. O Cloud Operations para GKE têm um conjunto de recursos monitorados do GKE que representam recursos como clusters, nós, pods e contêineres. É possível desativar o Cloud Operations para GKE e para clusters do GKE On-Prem, mas recomendamos mantê-las ativadas para esses produtos.

Security Health Analytics

Como identificar vulnerabilidades

O Security Health Analytics evita incidentes identificando possíveis configurações incorretas e violações de conformidade nos recursos do Google Cloud, e sugerindo ações corretivas apropriadas. Os verificadores do Security Health Analytics geram tipos de descoberta de vulnerabilidades disponíveis no Security Command Center. As descobertas de verificação de contêiner estão relacionadas às configurações de contêiner do GKE e pertencem ao tipo de verificação CONTAINER_SCANNER.

Integração do Security Command Center com o Pub/Sub

É possível receber alertas sobre descobertas na Central de comando de segurança usando o app de notificação. O app se inscreve em um tópico de notificações do Pub/Sub e envia notificações para um canal configurado, como e-mail ou SMS.

Inventário de recursos do Cloud

Como monitorar recursos do Google Cloud

O Cloud Asset Inventory permite monitorar alterações de recursos e políticas em que você está inscrito por meio de notificações em tempo real. É possível monitorar alterações de tipos de recursos e tipos de política compatíveis dentro de uma organização, pasta ou projeto ou de outros recursos especificados. Você configura as inscrições criando um feed. Os tipos de recursos compatíveis incluem tipos de recursos do GKE e tipos de políticas do IAM.

É possível monitorar recursos confidenciais de segurança, como regras de firewall e alterações nas políticas do IAM. Qualquer alteração nesses recursos envia imediatamente uma notificação por meio do Pub/Sub, permitindo que você tome medidas rápidas, se necessário.

As notificações em tempo real se conectam às suas cargas de trabalho atuais. Com essa funcionalidade, é possível mesclar ações, como criar uma Função do Cloud para reverter uma alteração de recurso após a alteração ser detectada.

Como fazer alertas usando o registro de auditoria do Cloud

Os clusters do GKE integram o Kubernetes Audit Logging com o registro de auditoria do Cloud e o Cloud Logging. É possível usar o Cloud Operations para GKE para configurar métricas com base nas entradas de registro. É possível usar métricas com base em registros para configurar uma política de alertas.

As políticas para alertas especificam canais de notificação, que permitem especificar como você quer ser informado de que uma política de alertas foi acionada. É possível configurar um gerenciador de notificações usando o Cloud Run ou o Cloud Functions para realizar uma ação em resposta, por exemplo, para reverter a alteração ou notificá-lo por e-mail.

Resumo geral

Para integrar os controles, determine suas necessidades de auditoria e monitoramento. Em seguida, mapeie o escopo dos controles discutidos neste guia e o estágio em que eles precisam ser configurados, conforme descrito nas etapas a seguir.

  1. Antes de começar a configurar os clusters, consulte Padrões de monitoramento e geração de registros híbridos e em várias nuvens para determinar o nível de isolamento necessário.

  2. Crie seus clusters: Siga as orientações no guia de aumento de proteção do cluster aplicável (GKE ou GKE On-Prem). Ao criar o cluster, siga o guia de aumento de proteção e use a sinalização --enable-network-policy. São necessárias políticas de rede. Esta etapa permite implementar regras de firewall posteriormente que restringem o tráfego que flui entre os pods em um cluster.

  3. Defina os namespaces e rótulos necessários para os pods. Isso fornece um escopo de nome que permite trabalhar com políticas e contas de serviço do Kubernetes.

  4. Instale o Policy Controller usando o Anthos Config Management.

    Siga as orientações descritas no guia de aplicação de políticas.

  5. Configure o Cloud Operations para GKE para atender aos requisitos:

  6. Configurar o Cloud Operations para políticas, notificações e gerenciadores de alertas do GKE.

  7. Configurar notificações em tempo real do Cloud Asset Inventory.

  8. Configure um processo para analisar regularmente as descobertas de contêiner geradas a partir das verificações do Security Health Analytics.