Modo de execução de ensaio para perímetros de serviço

Quando usa os VPC Service Controls, pode ser difícil determinar o impacto no seu ambiente quando um perímetro de serviço é criado ou modificado. Com o modo de teste, pode compreender melhor o efeito da ativação do VPC Service Controls e das alterações aos perímetros em ambientes existentes.

No modo de teste, os pedidos que violam a política de perímetro não são recusados, apenas registados. Pode usar o modo de teste para testar a configuração do perímetro e monitorizar a utilização de serviços sem impedir o acesso aos recursos. Os exemplos de utilização comuns incluem o seguinte:

  • Determinar o impacto das alterações aos perímetros de serviço existentes.

  • Pré-visualizar o impacto que os novos perímetros de serviço vão ter.

  • Monitorizar pedidos a serviços protegidos que têm origem fora de um perímetro de serviço. Por exemplo, ver a origem dos pedidos a um determinado serviço ou identificar a utilização inesperada de serviços na sua organização.

  • Nos seus ambientes de programação, criar uma arquitetura de perímetro análoga à do seu ambiente de produção. Isto permite-lhe identificar e mitigar quaisquer problemas que sejam causados pelos seus perímetros de serviço antes de publicar as alterações no seu ambiente de produção.

Os perímetros de serviço podem existir exclusivamente no modo de teste. Também pode ter perímetros de serviço que usam uma combinação de modos aplicados e de teste.

Vantagens do modo de teste

Com o modo de teste, pode criar novos perímetros de serviço ou alterar vários perímetros existentes sem afetar um ambiente existente. Os pedidos que violam a nova configuração do perímetro não são bloqueados. Também pode compreender o impacto do perímetro num ambiente em que nem todos os serviços usados estão integrados com o VPC Service Controls.

Pode analisar os registos do VPC Service Controls para recusas, alterar a configuração para corrigir potenciais problemas e, em seguida, aplicar a nova postura de segurança.

Se não for possível resolver os problemas com a configuração do perímetro, pode optar por manter a configuração de teste de execução do perímetro e monitorizar os registos para verificar se existem recusas inesperadas que possam indicar uma tentativa de exfiltração. No entanto, os pedidos ao perímetro não são recusados.

Conceitos do modo de execução de ensaio

O modo de execução de ensaio funciona como uma segunda passagem de avaliação da configuração do perímetro. Por predefinição, a configuração do modo aplicado para todos os perímetros de serviço é herdada para a configuração do modo de teste, onde a configuração pode ser modificada ou eliminada sem afetar o funcionamento do perímetro de serviço.

Uma vez que o modo de teste simula herda a configuração do modo aplicado, em cada passo, ambas as configurações têm de ser válidas. Em particular, um projeto só pode estar num perímetro na configuração aplicada e num perímetro na configuração de teste de execução. Como resultado, as alterações que abrangem vários perímetros, como mover um projeto entre perímetros, têm de ser sequenciadas pela ordem adequada.

O modo de teste só regista um pedido se cumprir ambos os seguintes critérios:

  • O pedido não foi recusado pela execução de teste ou pela configuração aplicada do perímetro.

  • O pedido viola a configuração de teste da área restrita.

Por exemplo, se as configurações idênticas do modo de teste e do modo aplicado restringirem um contentor do Cloud Storage, o modo aplicado bloqueia e regista qualquer pedido ao contentor do Cloud Storage. O modo de teste apenas regista as diferenças nas violações em comparação com o modo aplicado.

Nos registos de auditoria de uma verificação de políticas no modo de teste, o valor do campo metadata.dryRun True no registo de auditoria é definido como True. Para mais informações, consulte o artigo Conteúdo do registo de auditoria.

Também pode criar perímetros que tenham apenas uma configuração de teste. Isto permite-lhe simular o impacto de um novo perímetro aplicado no seu ambiente.

Para avaliar a configuração de teste de um perímetro de serviço, defina o campo useExplicitDryRunSpec na configuração do perímetro de serviço como True. Para mais informações, consulte accessPolicies.servicePerimeters.

Semântica das políticas

A secção seguinte descreve a relação entre a política do modo de aplicação e do modo de teste, e a ordem em que a aplicação é resolvida.

Restrição de subscrição única

Um Google Cloud projeto só pode ser incluído numa configuração aplicada e numa configuração de teste. No entanto, as configurações aplicadas e de teste não têm de ser para o mesmo perímetro. Isto permite-lhe testar o impacto da transferência de um projeto de um perímetro para outro sem comprometer a segurança atualmente aplicada ao projeto.

Exemplo

O projeto corp-storage está atualmente protegido pela configuração aplicada do PA do perímetro. Quer testar o impacto da mudança do projeto corp-storage para o PB do perímetro.

A configuração de teste de execução para a PA ainda não foi modificada. Uma vez que a configuração de teste não foi modificada, herda corp-storage da configuração aplicada.

Para testar o impacto, primeiro, remova corp-storage da configuração de teste para PA e adicione o projeto à configuração de teste para PB. Tem de remover corp-storage da configuração de teste de execução para a PA primeiro, porque os projetos só podem existir numa configuração de teste de execução de cada vez.

Quando tiver a certeza de que a migração do corp-storage de PA para PB não terá efeitos adversos na sua postura de segurança, decide aplicar as alterações.

Existem duas formas de aplicar as alterações aos perímetros PA e PB:

  • Pode remover manualmente corp-storage da configuração aplicada para PA e adicionar o projeto à configuração aplicada para PB. Uma vez que corp-storage só pode estar numa única configuração aplicada de cada vez, tem de realizar os passos nesta ordem.

    -or-

  • Pode usar a ferramenta de linha de comandos gcloud ou a API Access Context Manager para aplicar todas as configurações de teste. Esta operação aplica-se a todas as configurações de teste de execução modificadas para os seus perímetros, pelo que deve coordenar a operação com qualquer outra pessoa na sua organização que tenha modificado as configurações de teste de execução para os seus perímetros. Uma vez que a configuração de teste para o PA já exclui corp-storage, não são necessários passos adicionais.

A configuração aplicada de um perímetro é executada primeiro

Apenas os pedidos permitidos pela configuração aplicada de um perímetro, mas negados pela configuração de teste, são registados como violações da política de teste. Os pedidos que são recusados pela configuração aplicada, mas seriam permitidos pela configuração de teste, não são registados.

Os níveis de acesso não têm um equivalente no modo de teste

Embora possa criar uma configuração de teste para um perímetro, os níveis de acesso não têm uma configuração de teste. Na prática, isto significa que, se quiser testar como uma alteração a um nível de acesso afetaria a configuração de teste de execução, tem de:

  1. Crie um nível de acesso que reflita as alterações que quer fazer a um nível de acesso existente.

  2. Aplique o novo nível de acesso à configuração de teste para o perímetro.

O modo de teste não tem um impacto negativo na segurança

As alterações a uma configuração de teste para um perímetro, como adicionar novos projetos ou níveis de acesso a um perímetro, ou alterar os serviços protegidos ou acessíveis a redes dentro do perímetro, não têm impacto na aplicação real de um perímetro.

Por exemplo, suponha que tem um projeto que pertence ao perímetro de serviço PA. Se o projeto for adicionado à configuração de teste de execução de outro perímetro, a segurança real aplicada ao projeto não se altera. O projeto continua a ser protegido pela configuração aplicada da PA de perímetro, como esperado.

Ações de execução de ensaio e estados de configuração

Com a funcionalidade de teste de execução, pode:

  • Crie um perímetro apenas com uma configuração de teste

  • Atualize a configuração de teste de um perímetro existente

  • Mova um novo projeto para um perímetro existente

  • Mova um projeto de um perímetro para outro

  • Elimine a configuração de execução de ensaio de um perímetro

Com base na ação realizada no modo de teste, um perímetro pode estar num dos seguintes estados de configuração:

Herdado de aplicado: estado predefinido para perímetros aplicados. Neste estado, quaisquer alterações à configuração aplicada do perímetro também são aplicadas à configuração de teste.

Modificado: a configuração de teste de execução de um perímetro foi vista ou alterada e, em seguida, guardada. Neste estado, as alterações à configuração aplicada de um perímetro não são aplicadas à configuração de teste.

Novo: o perímetro tem apenas uma configuração de teste. Mesmo que sejam feitas alterações à configuração de teste, até que este perímetro tenha uma configuração aplicada, o estado permanece Novo.

Eliminada: a configuração de execução de ensaio para o perímetro foi eliminada. Este estado permanece até criar uma nova configuração de teste para o perímetro ou anular a ação. Neste estado, as alterações à configuração aplicada de um perímetro não são aplicadas à configuração de teste.

Limitações do modo de execução de ensaio

O modo de teste aplica-se apenas aos perímetros. Não ajuda a compreender o impacto da restrição do acesso à API ao Google Cloud VIP restrito ou privado. Recomendamos que se certifique de que todos os serviços que quer usar estão disponíveis no VIP restrito antes de configurar o domínio restricted.googleapis.com.

Se não tiver a certeza de que as APIs que está a usar num ambiente existente são suportadas pelo VIP restrito, recomendamos que use o VIP privado. Pode continuar a aplicar a segurança do perímetro para os serviços suportados. No entanto, se usar o VIP privado, as entidades na sua rede têm acesso a serviços não seguros (serviços não suportados pelos controlos de serviços VPC), como as versões de consumidor do Gmail e do Drive. Uma vez que o VIP privado permite serviços que não são suportados pelos VPC Service Controls, é possível que código comprometido, software malicioso ou um utilizador malicioso na sua rede exfiltre dados através desses serviços não seguros.

O que se segue?