Crie e planeie perímetros de serviço

Este documento descreve as arquiteturas de implementação do VPC Service Controls recomendadas. Este documento destina-se a administradores de rede, arquitetos de segurança e profissionais de operações na nuvem que executam implementações de grande escala em produção no Google Cloud Google Cloud e que querem mitigar o risco de perda de dados confidenciais.

Uma vez que a proteção do VPC Service Controls afeta a funcionalidade dos serviços de nuvem, recomendamos que planeie a ativação do VPC Service Controls antecipadamente e considere o VPC Service Controls durante o design da arquitetura. É importante manter o design dos VPC Service Controls o mais simples possível. Recomendamos que evite designs de perímetro que usem várias pontes, projetos de rede de perímetro ou um perímetro DMZ e níveis de acesso complexos.

Use um perímetro unificado comum

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

Um perímetro unificado comum também oferece a vantagem de reduzir os custos de gestão para as equipas responsáveis pela criação e manutenção do perímetro. Uma vez que os serviços e os recursos de rede num perímetro podem comunicar livremente com as autorizações de acesso e os controlos de rede de IAM necessários, as equipas responsáveis pela gestão de perímetros preocupam-se principalmente com o acesso norte-sul, que é o acesso da Internet aos recursos no interior do perímetro.

Quando uma organização usa vários perímetros mais pequenos, as equipas de gestão de perímetros têm de dedicar recursos à gestão do tráfego leste-oeste entre os perímetros de uma organização, além do tráfego norte-sul proveniente de fora da organização. Dependendo da dimensão da organização e do número de perímetros, esta sobrecarga pode ser considerável. Recomendamos que adicione camadas ao seu perímetro com controlos de segurança adicionais e práticas recomendadas, como garantir que os recursos na rede VPC não têm saída direta para a Internet.

Os perímetros de serviço não se destinam a substituir nem a reduzir a necessidade de controlos do IAM. Quando definir controlos de acesso, recomendamos que se certifique de que o princípio do menor privilégio é seguido e que as práticas recomendadas da IAM são aplicadas.

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

Use vários perímetros numa organização

Determinados exemplos de utilização podem exigir vários perímetros para uma organização. Por exemplo, uma organização que processa dados de cuidados de saúde pode querer um perímetro para dados de confiança elevada não ocultados e um perímetro separado para dados de identificação removida de nível inferior, para facilitar a partilha com entidades externas, ao mesmo tempo que protege os dados de confiança elevada.

Se a sua organização quiser agir em conformidade com normas como a PCI DSS, é recomendável ter um perímetro separado em torno dos seus dados regulamentados.

Quando a partilha de dados é um exemplo de utilização principal para a sua organização, considere usar mais do que um perímetro. Se produzir e partilhar dados de nível inferior, como dados de saúde de pacientes anonimizados, pode usar um perímetro separado para facilitar a partilha com entidades externas. Para mais informações, consulte os padrões de referência para a troca de dados segura.

Além disso, se usar a sua organização para alojar inquilinos independentes de terceiros, como parceiros ou clientes, considere definir um perímetro para cada inquilino. Google Cloud Se considerar que a movimentação de dados de um destes inquilinos para outro é exfiltração, recomendamos que implemente um perímetro separado.

Design de perímetro

Recomendamos que ative todos os serviços protegidos quando criar um perímetro, o que ajuda a reduzir a complexidade operacional e a minimizar potenciais vetores de exfiltração. Uma vez que deixar as APIs desprotegidas aumenta os possíveis vetores de exfiltração, devem existir revisões e justificações se a sua organização optar por proteger uma API e não outra.

Todos os novos projetos devem passar pelo processo de revisão e qualificação descrito nas secções seguintes. Inclua no perímetro todos os projetos que cumprem as condições de qualificação.

Certifique-se de que não existe um caminho para o VIP privado a partir de nenhuma das VPCs no perímetro. Se permitir uma rota de rede para private.googleapis.com, nega a proteção dos VPC Service Controls contra a exfiltração de dados internos. Se tiver de permitir o acesso a um serviço não suportado, experimente isolar a utilização de serviços não suportados num projeto separado ou mover toda a carga de trabalho para fora do perímetro.

Reveja e qualifique projetos

Uma empresa típica tem muitos projetos que representam cargas de trabalho e construções de alto nível, como planos de controlo, data lakes, unidades empresariais e fases do ciclo de vida. Além de organizar estes projetos e componentes em pastas, recomendamos que os qualifique para estarem dentro ou fora de um perímetro dos VPC Service Controls. Para se qualificar, considere as seguintes perguntas:

  • Existe um componente que tem uma dependência rígida de um serviço que o VPC Service Controls não suporta?

    A aplicação dos VPC Service Controls é inequívoca, pelo que este tipo de dependência pode não funcionar num perímetro. Recomendamos que modifique a carga de trabalho para isolar o requisito de serviços não suportados num projeto separado ou mova a carga de trabalho completamente para fora do perímetro.

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

Se respondeu sim a alguma das perguntas anteriores, recomendamos que não coloque o projeto num perímetro. Pode contornar esta situação, conforme abordado no tópico Conceção da lista de autorizações. No entanto, recomendamos que minimize a complexidade do perímetro.

O que se segue?