Locais do Cloud KMS

Em um projeto, os recursos do Cloud Key Management Service podem ser criados em um dos vários locais. Elas representam as regiões geográficas onde um recurso do Cloud KMS é armazenado e pode ser acessado. O local de uma chave afeta o desempenho dos aplicativos que usam a chave. Alguns recursos, como chaves do Cloud HSM, não estão disponíveis em todos os locais.

O material das chaves do Cloud KMS e do Cloud HSM é restrito à região selecionada em repouso e em uso.

Tipos de locais do Cloud KMS

É possível criar recursos do Cloud KMS, do Cloud HSM e do Cloud EKM em diferentes tipos de locais no Google Cloud, dependendo dos requisitos de disponibilidade. Os locais são adicionados regularmente. Para informações específicas sobre cada local, consulte Locais.

Saiba mais sobre como escolher o melhor tipo de local.

Locais regionais

Os datacenters de um local regional existem em um local geográfico específico. Por exemplo, um recurso criado em us-central1 está localizado na região central dos Estados Unidos.

Os recursos do Cloud KMS podem ser criados nos seguintes locais regionais:

Nome da região Descrição da região Cloud HSM disponível Cloud EKM disponível
asia-east1 Taiwan Sim Sim
asia-east2 Hong Kong Sim Sim
asia-northeast1 Tóquio Sim Sim
asia-northeast2 Osaka Sim Sim
asia-northeast3 Seul Sim Sim
asia-south1 Mumbai Sim Sim
asia-southeast1 Singapura Sim Sim
asia-southeast2 Jacarta Sim Sim
australia-southeast1 Sydney Sim Sim
europe-central2 Varsóvia Não Sim
europe-north1 Finlândia Sim Sim
europe-west1 Bélgica Sim Sim
europe-west2 Londres Sim Sim
europe-west3 Frankfurt Sim Sim
europe-west4 Holanda Sim Sim
europe-west6 Zurique Sim Sim
northamerica-northeast1 Montreal Sim Sim
us-central1 Iowa Sim Sim
us-east1 Carolina do Sul Sim Sim
us-east4 Virgínia do Norte Sim Sim
us-west1 Oregon Sim Sim
us-west2 Los Angeles Sim Sim
us-west3 Salt Lake City Sim Sim
us-west4 Las Vegas Sim Sim
southamerica-east1 São Paulo Sim Sim

Locais birregionais

Os datacenters de um local com duas regiões existem em dois locais geográficos específicos. Por exemplo, um recurso criado no local birregional nam4 persiste em data centers no centro e no leste dos Estados Unidos.

Os recursos do Cloud KMS podem ser criados nos seguintes locais birregionais:

Nome do local birregional Descrição do local birregional (bold indica a terceira réplica) Cloud HSM disponível Cloud EKM disponível
asia1 Tóquio, Osaka e Seul Não Não
eur4 Finlândia, Países Baixos e Bélgica Não Sim
eur5 Londres, Países Baixos e Bélgica Sim Sim
nam4 Iowa, Carolina do Sul e Oklahoma Não Sim

Locais multirregionais

Os datacenters de um local multirregional estão espalhados por uma área geográfica geral. Por exemplo, um recurso criado na multirregião europe permanecem em vários data centers na União Europeia. Não é possível prever ou controlar exatamente quais data centers estão selecionados ou onde eles estão localizados na multirregião.

Os recursos do Cloud KMS podem ser criados nos seguintes locais multirregionais:

Nome multirregional Observações Cloud HSM disponível Cloud EKM disponível
global Sim Não
asia Sim Sim
asia1 Considerado birregional para o Cloud Storage. Não Não
eur3 Não Não
eur5 Considerado birregional para o Cloud Storage. Não Não
europe Data centers dentro dos estados membros da União Europeia1 Sim Sim
nam3 Não Não
nam6 Não Não
nam9 Não Não
us Sim Sim
1 Os recursos criados na multirregião europe não são armazenados nos data centers europe-west2 (Londres) ou europe-west6 (Zurique).

O local global

O local global é uma multirregião especial. Os data centers estão espalhados por todo o mundo. Não é possível prever ou controlar exatamente quais data centers estão selecionados ou onde eles estão localizados.

Como escolher o melhor tipo de local

Como regra, projete seu aplicativo para que todos os seus componentes estejam geograficamente próximos uns dos outros e próximos aos clientes do seu aplicativo. O local das chaves é um aspecto importante do design do aplicativo. Após a criação, uma chave não pode ser movida ou exportada.

Ao usar um local multirregional, como a multirregião europe, os recursos permanecem em vários data centers espalhados pela multirregião. Criar e atualizar chaves em locais multirregionais, incluindo o local global, pode ser menos eficiente do que usar um local de região única. Para mais informações, consulte Como ler e gravar em locais multirregionais.

Use o local global se todas as condições a seguir forem verdadeiras:

  • Os componentes do seu aplicativo são distribuídos globalmente
  • Você tem leituras ou gravações pouco frequentes, mas usa outras operações criptográficas com frequência
  • Suas chaves não têm requisitos de residência geográfica

Para as integrações com as chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês), você precisa usar a mesma localização exata dos outros recursos relacionados à integração. Algumas integrações do CMEK não são compatíveis com o local global.

Para mais informações sobre integrações do CMEK, consulte a seção relevante de Criptografia em repouso.

Locais birregionais só são compatíveis com recursos do Cloud Storage que também usam um local birregional.

Os recursos do Cloud EKM dependem da conectividade entre o Google Cloud e um serviço de gerenciamento de chaves externo, fora do Google Cloud. Para recursos do Cloud External Key Manager, selecione um local geograficamente mais próximo possível do local onde as chaves são armazenadas no serviço de gerenciamento de chave externo.

O Cloud HSM depende da disponibilidade de hardware físico nos data centers de um local. Para recursos do Cloud HSM, selecione um local compatível com o Cloud HSM.

Os recursos do Cloud HSM têm cotas específicas do local. As cotas do Cloud KMS são globais.

Locais birregionais e multirregionais têm cotas separadas, independentemente das cotas para locais únicos. Por exemplo, para criar recursos do Cloud HSM no nam4 em duas regiões, você precisa ter uma cota de HSM em nam4, mesmo se você já tiver uma cota nas regiões individuais que participam em nam4, como us-central1.

Como ler e gravar em locais multirregionais

Ler e gravar recursos ou metadados associados em locais birregionais ou multirregionais, incluindo o local global, pode ser mais lento que a leitura ou gravação de uma única região.

  • Quando você cria ou lê versões de chave, o consenso é sempre exigido entre os data centers que armazenam o material da chave. As leituras e gravações em uma única região geralmente são mais eficientes do que aquelas em um local birregional ou multirregional.
  • Quando você realiza operações criptográficas, como ao criptografar ou descriptografar dados, o consenso não é necessário. Para operações criptográficas, os locais com duas regiões e multirregionais têm um desempenho semelhante ao de regiões de uma única região.
  • Quando você armazena as chaves em um local ou local geograficamente próximo aos dados que eles protegem ou validam, as operações criptográficas geralmente são mais eficientes.

As vantagens e desvantagens entre desempenho e disponibilidade são exclusivas para cada aplicativo. Os locais de várias regiões, incluindo a região dupla ou global, são mais adequados para cargas de trabalho de leitura intensa.

Como determinar as regiões disponíveis

Você pode usar o SDK do Cloud ou a API Cloud Key Management Service para ver uma lista de regiões disponíveis.

gcloud

gcloud kms locations list

Na saída do comando, a coluna HSM_AVAILABLE indica se o local é compatível com o Cloud HSM. A coluna EKM_AVAILABLE indica se o local é compatível com o Cloud External Key Manager.

API

Use os métodos Locations.get e Locations.list.

As respostas dos dois métodos incluem campos booleanos relacionados aos recursos de um local:

  • Se um local for compatível com chaves do Cloud HSM, hsmAvailable será true.

  • Se um local for compatível com chaves do Cloud EKM, ekmAvailable será true.

A seguir