Gerir recursos

As autoridades de certificação (ACs) criadas através do serviço de autoridade de certificação baseiam-se em dois tipos de recursos secundários:

• Uma versão da chave do Cloud Key Management Service, usada para assinar certificados e listas de revogação de certificados (CRLs) emitidas pela AC. Para mais informações sobre as versões das chaves, consulte o artigo Versões das chaves.
• Um contentor do Cloud Storage, usado para alojar um certificado da AC e todas as LRCs publicadas pela AC, se estas definições estiverem ativadas. Para mais informações acerca dos contentores do Cloud Storage, consulte o artigo Contentores.

Ambos os recursos têm de existir para cada CA e não podem ser alterados depois de o CA ser criado.

Modelos de gestão

O CA Service suporta dois modelos de gestão do ciclo de vida para estes recursos:

• Gerido pela Google
• Gerido pelo cliente

A chave do Cloud KMS e o contentor do Cloud Storage não têm de usar o mesmo modelo de gestão. Por exemplo, a chave do Cloud KMS pode ser gerida pela Google e o contentor do Cloud Storage pode ser gerido pelo cliente ou vice-versa.

Gerido pela Google

O serviço de AC cria e configura automaticamente os recursos de acordo com este modelo na criação da AC e elimina os recursos na eliminação da AC. Estes recursos não são cobrados separadamente.

Por predefinição, as novas ACs usam chaves do Cloud KMS geridas pela Google e contentores do Cloud Storage. As chaves do Cloud KMS geridas pela Google usam o nível de proteção do HSM e não são reutilizadas em várias ACs. Pode escolher um algoritmo de chave específico para a chave do Cloud KMS gerida pela Google enquanto cria uma AC. As chaves do Cloud KMS geridas pela Google não são reutilizadas em várias ACs.

Para obter informações sobre como criar uma CA de raiz, consulte Crie uma CA de raiz. Para saber como criar uma AC subordinada, consulte o artigo Crie uma AC subordinada. Para orientações sobre a escolha de um algoritmo de chave, consulte o artigo Escolha um algoritmo de chave.

Gerido pelo cliente

Só pode criar recursos geridos pelo cliente para CAs no nível empresarial. Tem de criar e configurar os recursos geridos pelo cliente antes da criação da AC. Além disso, tem de eliminar estes recursos num momento adequado após a destruição da CA. Os utilizadores são faturados diretamente por estes recursos. As chaves do Cloud KMS geridas pelo cliente podem usar os níveis de proteção de HSM, software ou externos.

O serviço de CA trata o projeto como o limite de segurança para as chaves do Cloud KMS geridas pelo cliente. Por exemplo, considere que um utilizador, a Alice, usa uma chave do Cloud KMS gerida pelo cliente para criar uma AC no projeto test. Em seguida, outro utilizador, o João, pode usar a mesma chave do Cloud KMS para criar outra AC no mesmo projeto. Embora a Alice precise de ter acesso de administrador à chave para criar a primeira AC, o Bob não precisa de nenhum acesso a essa chave porque a Alice já ativou a utilização da chave pelo serviço de AC no projeto test.

Vantagens da criação de recursos geridos pelo cliente

Uma vantagem deste modelo é que os autores das chamadas têm controlo direto sobre esses recursos. Os autores das chamadas podem atualizar diretamente atributos, como a gestão de acesso, para satisfazer os requisitos da respetiva organização.

A criação de uma AC com recursos geridos pelo cliente requer que o autor da chamada tenha acesso administrativo a esses recursos para conceder o acesso adequado ao serviço de AC. Para mais informações, consulte o artigo CA Service Service Agent.

Localização das chaves do Cloud KMS

Tem de criar chaves do Cloud KMS geridas pelo cliente na mesma localização que a dos recursos do serviço de AC. Para ver a lista completa de localizações do serviço de CA, consulte Localizações. Para ver a lista de localizações onde os recursos do Cloud KMS podem ser criados, consulte as localizações do Cloud KMS.

Localização dos contentores do Cloud Storage

Tem de criar contentores do Cloud Storage geridos pelo cliente aproximadamente na mesma localização que os recursos do serviço de AC. Não pode criar o contentor do Cloud Storage fora do continente onde criou os recursos do serviço de CA.

Por exemplo, se a sua CA estiver em us-west1, pode criar os contentores do Cloud Storage em qualquer região única nos EUA, como us-west1 ou us-east1, a região dupla NAM4 e a multirregião US.

Para ver a lista de localizações onde é possível criar recursos do Cloud Storage, consulte as localizações do Cloud Storage.

Acesso aos recursos geridos

Qualquer pessoa que tenha o URL do certificado da AC alojado num contentor do Cloud Storage ou quaisquer CRLs publicadas pela AC pode aceder a estes recursos por predefinição. Para impedir o acesso público ao certificado da CA e à LCR, adicione o projeto que contém o conjunto de CAs a um perímetro dos VPC Service Controls.

Ao adicionar o projeto que contém o conjunto de AC a um perímetro do VPC Service Controls, o contentor do Cloud Storage gerido pela Google junta-se ao perímetro. O perímetro do VPC Service Controls garante que não é possível aceder ao contentor do Cloud Storage a partir de redes não aprovadas.

Os clientes dentro do perímetro da rede continuam a poder aceder às CRLs e aos certificados da AC sem autenticação. Os pedidos de acesso de fora da rede aprovada falham.

URLs baseados em HTTP para certificados de ACs e CRLs

Os certificados da AC e as CRLs estão disponíveis em URLs baseados em HTTP pelos seguintes motivos:

• Um certificado de AC publicado num contentor do Cloud Storage não deve ser fidedigno pelos clientes tal como está. Os certificados de AC fazem parte de uma cadeia de certificados, que começa com o certificado da AC de raiz. Cada certificado na cadeia de certificados é assinado pelo certificado da AC que está mais acima na cadeia para preservar a integridade do certificado. Por isso, não existe nenhuma vantagem adicional na utilização do protocolo HTTPS.

• Alguns clientes rejeitam URLs baseados em HTTPS ao validar certificados.

Ative a publicação de certificados da AC e CRLs para ACs num grupo de ACs

O serviço de AC permite a publicação de certificados de AC e CRLs em contentores do Cloud Storage por predefinição quando cria um novo conjunto de ACs. Se tiver desativado a publicação do certificado da AC e da LCR durante a criação do grupo de ACs e quiser ativá-los agora, pode seguir as instruções nesta secção.

Para ativar a publicação de certificados da AC e a publicação de CRLs para todas as ACs num conjunto de ACs, faça o seguinte:

gcloud privateca pools update POOL_ID --location LOCATION --publish-crl --publish-ca-cert

Para saber como ativar a publicação de LRCs para revogar certificados, consulte o artigo Revogar certificados.

Desative a publicação de certificados da AC e CRLs para ACs num grupo de ACs

Para desativar a publicação de certificados da AC ou a publicação de CRLs para todas as ACs num conjunto de ACs, faça o seguinte:

gcloud privateca pools update POOL_ID --location LOCATION --no-publish-crl --no-publish-ca-cert

A desativação dos pontos de distribuição não elimina o contentor do Cloud Storage nem as respetivas autorizações e não remove os certificados da AC nem as LCRs já alojadas no mesmo. No entanto, significa que as CRLs futuras vão deixar de ser publicadas no contentor do Cloud Storage e os certificados futuros não vão ter as extensões AIA e CDP.

Atualize o formato de codificação dos certificados da AC e das CRLs publicados

Para atualizar o formato de codificação dos certificados da AC e das CRLs publicadas, faça o seguinte:

gcloud privateca pools update POOL_ID --location=LOCATION --publishing-encoding-format=PUBLISHING_ENCODING_FORMAT

O que se segue?

• Saiba como criar grupos de CA.
• Saiba como criar uma AC raiz.
• Saiba como criar uma AC subordinada.
• Saiba como criar uma AC subordinada a partir de uma AC externa.