Práticas recomendadas para ativar o VPC Service Controls

Neste documento, descrevemos o processo recomendado para configurar e aplicar a proteção do VPC Service Controls à sua organização do Google Cloud.

A ativação descuidada do VPC Service Controls pode causar problemas com aplicativos atuais e causar uma interrupção temporária. Recomendamos que você planeje a ativação com cuidado e reserve tempo suficiente para coletar dados, realizar testes e analisar registros de violação. Garanta que as partes interessadas da equipe de operações do VPC Service Controls e da equipe de aplicativos estejam disponíveis para a tarefa.

Para cada carga de trabalho ou aplicativo integrado ao VPC Service Controls, é necessário repetir o processo de ativação.

Comunicação de coordenadas

Geralmente, a equipe de ativação da nuvem ou segurança de rede lidera o esforço para ativação do VPC Service Controls. Recomendamos que você tenha uma pessoa específica que crie e acompanhe reuniões multifuncionais, assim como documente os itens de ações. As equipes colaboram:

  • com os padrões de acesso das APIs do Google Cloud;
  • com a identificação de violações do perímetro de serviço;
  • com a permissão de acesso ao perímetro.

Assim como nos firewalls de rede convencionais, a intenção é identificar e permitir os fluxos necessários para o funcionamento eficiente de cargas de trabalho de negócios legítimas.

Padrões de acesso a documentos e casos de uso

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. Veja a seguir alguns padrões de acesso comuns:

  • Padrões de acesso a dados: serviços fora do perímetro armazenam ou recuperam dados que residem no perímetro.
  • Padrões de acesso a recursos:
    • Os usuários acessam projetos no perímetro usando o Console do Google Cloud.
    • Ferramentas ou serviços de terceiros gerenciam e acessam recursos dentro do perímetro.
    • Serviços ou recursos dentro do perímetro acessam APIs do Google.
  • Padrões de acesso ao endpoint:
    • Os usuários acessam recursos dentro do perímetro de um dispositivo que a organização gerencia.
    • Os recursos locais se comunicam com os recursos dentro do perímetro.

Depois de identificar os padrões de acesso para uma carga de trabalho, identifique os casos de uso e categorize-os em um dos padrões de acesso na lista anterior. Veja alguns casos de uso comuns:

  • Os administradores do Cloud gerenciam os projetos que fazem parte de um perímetro.
  • Serviços de automação, como o Terraform, o Jenkins e o Microsoft Azure DevOps, que residem fora do perímetro gerenciam a implantação de recursos dentro do perímetro.
  • Serviços de gerenciamento de configuração, como Ansible, Chef ou Puppet, que residem fora do perímetro gerenciam a implantação e a configuração de software em recursos que estão dentro do perímetro.
  • O monitoramento de segurança e a aplicação de serviços como o Forseti ou o SIEM que residem fora do perímetro consomem dados ou aplicam as políticas de segurança em um recurso dentro do perímetro.

Para cada caso de uso, documente o seguinte:

  • O padrão de acesso
  • Os atores que podem acionar o caso de uso
  • Condições que acionam o caso de uso
  • Se o caso de uso é um padrão de acesso válido e precisa ser permitido
  • Quaisquer suposições relacionadas ao caso de uso.

Para uma amostra de padrão de acesso e rastreador de casos de uso, consulte Modelo de integração do VPC Service Controls: casos de uso (PDF).

Fazer entrevistas

Faça entrevistas com as equipes de carga de trabalho para discutir os padrões de acesso e os casos de uso coletados dos modelos de comunicação anteriores. Veja alguns exemplos de perguntas que você pode fazer durante essas entrevistas:

  • Os casos de uso são uma prioridade a ser considerada para a ativação do VPC Service Controls? Recomendamos que você considere apenas cargas de trabalho de primeira prioridade para a ativação inicial e integre outras cargas de trabalho menos críticas depois de proteger recursos essenciais para os negócios.

  • É possível concluir uma execução abrangente de todos os casos de uso? Isso é feito para acionar todos os cenários de perímetro possíveis para que você possa analisar totalmente e confirmar que o aplicativo funcionará corretamente depois de aplicar restrições ao perímetro.

  • Quanto tempo leva para executar a execução do caso de uso?

  • Você está planejando alguma alteração importante nessa carga de trabalho que possa entrar em conflito com a ativação do VPC Service Controls? Os recursos de carga de trabalho precisam estar em um estado estável antes da ativação do VPC Service Controls.

Preparar um teste

O modo de teste reduz a complexidade do teste da aplicação de restrições do VPC Service Controls identificando as violações sem interromper os aplicativos. Configure um teste como um perímetro separado que registra todas as violações, mas não executa nenhum bloqueio. É possível executar cargas de trabalho enquanto elas estiverem no perímetro do teste e gerar registros de violação a serem analisados.

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

  1. Identifique todos os projetos que se qualificam como parte do perímetro e conclua o caso de uso e o processo de entrevista desses 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 serem protegidos, adicione todos os serviços que têm suporte.

  4. Crie um coletor de registros agregados que envia todos os registros para o BigQuery ou crie um coletor de registros para cada projeto que envia os registros de simulação para um conjunto de dados comum do BigQuery. Para consultar essas mensagens de registro e identificar violações do VPC Service Controls, use uma consulta SQL.

    Para criar um coletor de registros que contém todas as mensagens de registro relevantes do VPC Service Controls, use o seguinte filtro:

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

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

  6. Se você já tiver uma lista de IPs públicos, identidades, dispositivos de confiança, projetos ou redes VPC permitidos, adicione-os a uma regra de entrada ou nível de acesso, conforme aplicável no perímetro do modo de teste. Permitir fluxos legítimos conhecidos ajuda a reduzir o número de registros de violação 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 à Internet ou ao VIP particular.

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

    Em "Detalhes da zona", o nome do DNS *.googleapis.com tem restricted.googleapis.com no campo "Dados".

Executar casos de uso

Em um prazo determinado, peça para a equipe do aplicativo executar a carga de trabalho no projeto no perímetro do modo de teste. Verifique se você tem uma cobertura completa de todo o código que pode chamar as APIs do Google. Quando a simulação for concluída, a equipe de revisão designada poderá realizar a análise de registros de violação.

Analisar violações

Os registros de violação do modo de teste contêm a maioria das informações necessárias para determinar se uma violação do aplicativo requer alguma ação, como adicionar identidades ou endereços IP à lista de permissões do perímetro. Os dados da violação são armazenados na tabela cloudaudit_googleapis_com_policy do BigQuery. Veja a seguir os elementos principais para analisar a violação:

  • O serviço protegido e o método da API sendo chamados.
  • O projeto dentro do perímetro que teria bloqueado a solicitação.
  • O e-mail da identidade que está chamando a API protegida.
  • O endereço IP do autor da chamada.
  • O tipo de violação.

O exemplo a seguir é uma consulta do BigQuery que retorna 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 você a identificar as violações relevantes:

  • Adicione um qualificador de carimbo de data/hora para o período em que cada aplicativo exclusivo executou o respectivo caso de uso:

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

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

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

Analisar registros de violação

Ao analisar os registros de violação, determine se os itens a seguir são verdadeiros:

  • A identidade (e-mail) deve invocar as APIs protegidas?
  • O autor da chamada precisa ter permissão para invocar a API fora do perímetro?

Com base nos critérios anteriores, determine se você precisa permitir que a identidade, o dispositivo, o endereço IP, o intervalo CIDR, o projeto ou a rede acessem o perímetro de fora.

Algumas entradas talvez tenham um endereço IP private. Isso indica que a chamada veio da rede do Google, seja dos próprios serviços do Google ou de uma VPC em um projeto que esteja fora do perímetro. Nos serviços do Google, como gravadores de coletores de registros, é necessário adicionar a conta de serviço do Google a uma lista de permissões.

As entradas sem e-mails se devem à edição de registros de auditoria do Cloud para operações somente leitura que foram negadas devido à falta de permissões do IAM. Nesses casos, é possível usar o endereço IP e os nomes dos recursos para entender a origem da tentativa de acesso. Esse tipo de tentativa de acesso pode ser um acesso acidental por um usuário de fora da organização. Por exemplo, um usuário que digita incorretamente um bucket com nome semelhante.

Se você vir um tipo de violação de SERVICE_NOT_ALLOWED_FROM_VPC, a carga de trabalho talvez esteja usando um serviço compatível com o VPC Service Controls, mas que não foi adicionado à lista de APIs protegidas. Por exemplo, se o IAM causou essa violação, o administrador precisará adicionar o 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

É possível criar um painel do Looker Studio para analisar violações. Para mais informações, consulte Monitorar violações do VPC Service Controls na organização do Google Cloud com o Looker Studio. O Looker Studio era antes chamado de Data Studio.

A seguir