Projetar e arquitetar perímetros de serviço

Neste documento, descrevemos as arquiteturas recomendadas de implantação do VPC Service Controls. Este documento destina-se a administradores de rede, arquitetos de segurança e profissionais de operações de nuvem que executam e operam grandes implantações de escala de produção no Google Cloud e que querem diminuir o risco de perda de dados confidenciais.

Como a proteção do VPC Service Controls afeta a funcionalidade dos serviços em nuvem, recomendamos planejar a ativação do VPC Service Controls com antecedência e considerar o VPC Service Controls durante o design da arquitetura. É importante manter o design do VPC Service Controls o mais simples possível. Recomendamos que você evite projetos de perímetro que usem várias pontes, projetos de rede de perímetro ou um perímetro da DMZ) e níveis de acesso complexos.

Usar um perímetro unificado comum

Um perímetro grande único, chamado de perímetro unificado, oferece a proteção mais eficaz contra a exfiltração de dados em comparação com o uso de vários perímetros segmentados.

Um perímetro unificado comum também oferece o benefício de menor overhead de gerenciamento para as equipes responsáveis pela criação e manutenção do perímetro. Como os serviços e os recursos de rede em um perímetro podem se comunicar livremente com as permissões necessárias do IAM e dos controles de rede, as equipes responsáveis pelo gerenciamento do perímetro se preocuparão principalmente com o acesso norte-sul, que é o acesso da Internet a recursos dentro do perímetro.

Quando uma organização usa vários perímetros menores, as equipes de gerenciamento de perímetro precisam dedicar recursos para gerenciar o tráfego leste-oeste entre os perímetros de uma organização, além do tráfego norte-sul de fora da organização. Dependendo do tamanho da organização e do número de perímetros, esse overhead pode ser considerável. Recomendamos que você aplique ao seu perímetro camadas com outros controles de segurança e práticas recomendadas, como garantir que os recursos na rede VPC não tenham saída direta da Internet.

Os perímetros de serviço não foram criados para substituir ou reduzir a necessidade de controles do IAM. Ao definir controles de acesso, recomendamos garantir que o princípio de privilégio mínimo seja seguido e as práticas recomendadas do IAM sejam aplicadas.

Para mais informações, consulte Como criar um perímetro de serviço.

Usar vários perímetros em uma organização

Alguns casos de uso podem exigir vários perímetros para uma organização. Por exemplo, para uma organização que processa dados de saúde, é recomendável um perímetro para dados não ofuscados e de alta confiança e outro perímetro separado para dados desidentificados de nível inferior a fim de facilitar o compartilhamento com entidades externas sem deixar de proteger os dados de alta confiança.

Se sua organização quiser obedecer a padrões como o PCI DSS, é recomendável ter um perímetro separado em torno dos dados regulamentados.

Quando o compartilhamento de dados for um caso de uso principal para sua organização, considere usar mais de um perímetro. Se você produzir e compartilhar dados de nível inferior, como dados de saúde de pacientes desidentificados, é possível usar um perímetro separado para facilitar o compartilhamento com entidades externas. Para mais informações, consulte padrões de referência para troca de dados segura.

Além disso, se você usa sua organização do Google Cloud para hospedar locatários independentes e de terceiros, como parceiros ou clientes, considere definir um perímetro para cada locatário. Se você considerar o movimento de dados de um desses locatários para outro como exfiltração, recomendamos implementar um perímetro separado.

Design de perímetro

Recomendamos que você ative todos os serviços protegidos ao criar um perímetro, o que ajuda a reduzir a complexidade operacional e minimizar possíveis vetores de exfiltração. Como o fato de deixar APIs desprotegidas aumenta possíveis vetores de exfiltração, serão necessárias revisões e justificativas para que sua organização opte por proteger uma API e não outra.

Todos os novos projetos precisam passar pelo processo de revisão e qualificação, que é descrito nas seções a seguir. Inclua no perímetro todos os projetos que atenderem às condições de qualificação.

Verifique se não há um caminho para o VIP particular de qualquer uma das VPCs no perímetro. Se você permitir uma rota de rede para private.googleapis.com, a proteção do VPC Service Controls contra exfiltração de dados internos é negada Se você precisar permitir o acesso a um serviço não compatível, isole o uso dos serviços não compatíveis em um projeto separado ou mova toda a carga de trabalho para fora do perímetro.

Revisar e qualificar projetos

Uma empresa comum tem muitos projetos que representam cargas de trabalho e construções de alto nível, como planos de controle, data lakes, unidades de negócios e estágios do ciclo de vida. Além de organizar esses projetos e componentes em pastas, recomendamos que você os qualifique para dentro ou fora de um perímetro do VPC Service Controls. Para fazer a qualificação, considere as seguintes perguntas:

  • Existe um componente que tenha uma dependência rígida em um serviço não compatível com o VPC Service Controls?

    A aplicação do VPC Service Controls não é ambígua. Portanto, esse tipo de dependência pode não funcionar em um perímetro. Recomendamos que você modifique a carga de trabalho para isolar o requisito de serviços não compatíveis em um projeto separado ou retire totalmente a carga de trabalho do perímetro.

  • Há um componente que não tem dados confidenciais e não consome dados confidenciais de outros projetos?

Se você respondeu sim a qualquer uma das perguntas anteriores, recomendamos que não coloque o projeto em um perímetro. É possível contornar isso, conforme discutido no tópico Design de lista de permissões. No entanto, recomendamos que você minimize a complexidade do perímetro.

A seguir