Práticas recomendadas para ativar os VPC Service Controls

Este documento descreve o processo recomendado para configurar e aplicar a proteção do VPC Service Controls na sua Google Cloud organização.

A ativação descuidada dos VPC Service Controls pode causar problemas com as aplicações existentes e, potencialmente, causar uma interrupção. Recomendamos que planeie cuidadosamente a ativação e permita tempo suficiente para recolher dados, realizar testes e analisar os registos de violações. Certifique-se de que as partes interessadas da sua equipa de operações dos VPC Service Controls e da sua equipa de aplicações estão disponíveis para a tarefa.

Para cada carga de trabalho ou aplicação que integrar no VPC Service Controls, deve repetir o processo de ativação.

Coordenar a comunicação

Muitas vezes, a equipa de segurança de rede ou de ativação da nuvem lidera o esforço de ativação dos VPC Service Controls. Recomendamos que tenha uma pessoa dedicada à criação e monitorização de reuniões multifuncionais, bem como à documentação dos itens de ação. As suas equipas colaboram sobre o seguinte:

  • Google Cloud Padrões de acesso às APIs
  • Identificação de violações do perímetro de serviço
  • Permitir o acesso ao perímetro

Tal como acontece com as firewalls de rede convencionais, o objetivo é identificar e permitir os fluxos necessários para o funcionamento eficiente das cargas de trabalho empresariais legítimas.

Documente padrões de acesso e exemplos de utilização

Para iniciar o processo de ativação, identifique e documente claramente todos os padrões de acesso válidos. Os padrões de acesso são tipos repetíveis de interações entre elementos fora e dentro do perímetro. Seguem-se alguns padrões de acesso comuns:

  • Padrões de acesso aos dados: os serviços fora do perímetro armazenam ou obtêm dados que residem no perímetro.
  • Padrões de acesso aos recursos:
    • Os utilizadores acedem aos projetos no perímetro através da Google Cloud consola.
    • As ferramentas ou os serviços de terceiros gerem e acedem aos recursos dentro do perímetro.
    • Serviços ou recursos dentro do perímetro que acedem às APIs Google.
  • Padrões de acesso aos pontos finais:
    • Os utilizadores acedem a recursos dentro do perímetro a partir de um dispositivo gerido pela sua organização.
    • Os recursos no local comunicam com os recursos dentro do perímetro.

Depois de identificar os padrões de acesso para uma carga de trabalho, identifique os seus exemplos de utilização e categorize-os num dos padrões de acesso na lista anterior. Seguem-se alguns exemplos de utilização comuns:

  • Os administradores da nuvem gerem projetos que fazem parte de um perímetro.
  • Os serviços de automatização, como o Terraform, o Jenkins e o Microsoft Azure DevOps, que residem fora do perímetro, gerem a implementação de recursos dentro do perímetro.
  • Os serviços de gestão de configurações, como o Ansible, o Chef ou o Puppet, que residem fora do perímetro, gerem a implementação e a configuração de software em recursos que estão dentro do perímetro.
  • Os serviços de monitorização e aplicação de segurança, como o Forseti ou o SIEM, que residem fora do perímetro, consomem dados ou aplicam as políticas de segurança num recurso que está dentro do perímetro.

Para cada exemplo de utilização, documente o seguinte:

  • O padrão de acesso
  • Os intervenientes que podem acionar o exemplo de utilização
  • Condições que acionam o caso de utilização
  • Se o exemplo de utilização é um padrão de acesso válido e deve ser permitido
  • Quaisquer pressupostos relativos ao exemplo de utilização

Para ver um exemplo de padrão de acesso e um rastreador de exemplos de utilização, consulte o modelo de integração dos VPC Service Controls – exemplos de utilização (PDF).

Realize entrevistas

Realize entrevistas com as equipas de carga de trabalho para debater os padrões de acesso e os exemplos de utilização que recolhe dos modelos de comunicações anteriores. Seguem-se exemplos de perguntas que pode fazer durante estas entrevistas:

  • Os seus exemplos de utilização são uma prioridade a ter em conta para a ativação dos VPC Service Controls? Recomendamos que considere apenas as cargas de trabalho de primeira prioridade para a ativação inicial e integre outras cargas de trabalho menos críticas depois de proteger os recursos essenciais para a empresa.

  • Consegue concluir uma execução abrangente de todos os exemplos de utilização? Faz isto para acionar todos os cenários de perímetro possíveis para que possa analisar totalmente e confirmar que a aplicação vai funcionar corretamente depois de aplicar o perímetro.

  • Quanto tempo demora a execução do exemplo de utilização?

  • Está a planear alterações importantes para esta carga de trabalho que possam entrar em conflito com a ativação dos VPC Service Controls? As funcionalidades da carga de trabalho têm de estar num estado estável antes de ativar o VPC Service Controls.

Prepare uma execução de ensaio

O modo de teste reduz a complexidade dos testes da aplicação dos VPC Service Controls ao identificar violações sem interromper as aplicações. Configura um teste de execução como um perímetro separado que regista todas as violações, mas não executa nenhum bloqueio. Pode executar cargas de trabalho enquanto estão no perímetro de teste e gerar registos de violações para serem analisados.

Para preparar o ambiente de teste, faça o seguinte:

  1. Identifique todos os projetos qualificados para fazer parte do perímetro e conclua o exemplo de utilização e o processo de entrevista para esses projetos.
  2. Crie um perímetro de teste e adicione todos os projetos.
  3. No perímetro de serviço do VPC Service Controls, em Serviços restritos > Serviços a proteger, adicione todos os serviços suportados.

  4. Crie um destino de registo agregado que envia todos os registos para o BigQuery ou crie um destino de registo para cada projeto que envia os registos de teste para um conjunto de dados do BigQuery comum. Para consultar estas mensagens de registo e identificar violações dos VPC Service Controls, pode usar uma consulta SQL.

    Para criar um destino do registo que inclua todas as mensagens de registo relevantes do VPC Service Controls, use o seguinte filtro:

    logName="projects/$PROJECT/logs/cloudaudit.googleapis.com%2Fpolicy"

  5. Para garantir a máxima segurança, não permita o acesso a serviços não suportados. Configure o seu perímetro de forma que apenas os serviços restritos funcionem no perímetro. Para o fazer, configure a lista de serviços acessíveis para RESTRICTED-SERVICES.

  6. Se já tiver uma lista de IPs públicos, identidades, dispositivos fidedignos, projetos ou redes de VPC permitidos, adicione-os a uma regra de entrada ou a um nível de acesso, conforme aplicável, no perímetro de teste. Permitir fluxos legítimos conhecidos ajuda a reduzir o número de registos de violações e permite que os revisores se concentrem em eventos acionáveis.

  7. Verifique se nenhuma das VPCs nos projetos tem um caminho de saída para a Internet ou o VIP privado.

  8. Verifique se todas as VPCs têm o DNS *.googleapis.com a apontar para restricted.googleapis.com.

    Nos detalhes da zona, o nome DNS *.googleapis.com tem restricted.googleapis.com no campo de dados

Executar exemplos de utilização

À hora acordada, a equipa da aplicação executa a respetiva carga de trabalho no projeto no perímetro do teste de simulação. Certifique-se de que tem cobertura total de todo o código que possa chamar as APIs Google. Quando o teste estiver concluído, a equipa de revisão designada pode realizar a análise do registo de violações.

Analise violações

Os registos de violações de teste de execução contêm a maioria das informações de que precisa para determinar se uma violação da aplicação requer alguma ação, como adicionar identidades ou endereços IP à lista de autorizações do perímetro. Os dados de violação são armazenados na tabela do BigQuery cloudaudit_googleapis_com_policy. Seguem-se os elementos principais para analisar a violação:

  • O serviço protegido e o método da API que está a ser chamado.
  • O projeto dentro do perímetro que teria bloqueado o pedido.
  • O email da identidade que está a chamar a API protegida.
  • O endereço IP do autor da chamada.
  • O tipo de violação.

O exemplo seguinte é uma consulta do BigQuery que devolve todos os detalhes da violação:

SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
where JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') = "true" #ensure these are dry-run logs

Consultar violações relevantes

As seguintes estratégias podem ajudar a identificar as violações relevantes:

  • Adicione um qualificador de indicação de tempo para o período em que cada aplicação única executou o respetivo exemplo de utilização:

    WHERE receiveTimestamp >'2020-07-23 19:53:48.241317 UTC'

  • Adicione um filtro para a convenção de nomenclatura de identidades de carga de trabalho ou projetos:

    WHERE where resource.labels.project_id like '%APPLICATION_NAME%'

Reveja os registos de violações

Quando revê registos de violações, determine se o seguinte é verdadeiro:

  • A identidade (email) deve invocar as APIs protegidas?
  • O autor da chamada deve poder invocar a API a partir de fora do perímetro?

Com base nos critérios anteriores, determine se tem de permitir que a identidade, o dispositivo, o endereço IP, o intervalo CIDR, o projeto ou a rede acedam ao perímetro a partir do exterior.

Algumas entradas podem ter um endereço IP de private. Isto indica que a chamada foi feita a partir da rede Google, quer pelos próprios serviços da Google, quer por uma VPC num projeto que está fora do perímetro. Para serviços Google, como os gravadores de destino de registo, tem de adicionar a conta de serviço Google a uma lista de autorizações.

As entradas sem emails devem-se à ocultação dos registos de auditoria na nuvem para operações só de leitura que foram recusadas devido à falta de autorizações da IAM. Nestes casos, pode usar o endereço IP e os nomes dos recursos para compreender a origem da tentativa de acesso. Este tipo de tentativa de acesso pode ser um acesso acidental por parte de um utilizador externo à sua organização. Por exemplo, um utilizador que escreve incorretamente um contentor com um nome semelhante.

Se vir um tipo de violação SERVICE_NOT_ALLOWED_FROM_VPC, a carga de trabalho pode estar a usar um serviço suportado pelos VPC Service Controls, mas não foi adicionado à lista de APIs protegidas. Por exemplo, se a IAM causar uma violação deste tipo, o administrador deve adicionar a IAM à lista de serviços acessíveis executando o seguinte comando da CLI do Google Cloud:

gcloud access-context-manager perimeters update perimeter_test \
 --add-vpc-allowed-services=RESTRICTED-SERVICES,IAM.googleapis.com \
 --policy=1234567890

Pode criar um painel de controlo do Looker Studio para rever as violações. Para mais informações, consulte o artigo Monitorize as violações do VPC Service Controls na sua Google Cloud organização com o Looker Studio. O Looker Studio era anteriormente conhecido como Data Studio.

O que se segue?