csa certificate authority service
1.0.0
This is not an officially supported Google product. This code creates PoC demo environment for CSA Certificate Authority Service demo. This demo code is not built for production workload.
Este guia de arquitetura permite uma implantação simplificada e segura do Certificate Authority Service (CAS). Ele cria uma autoridade de certificação raiz junto com duas autoridades de certificação subordinadas e um certificado folha. Essas autoridades certificadoras são altamente disponíveis, escaláveis e simples de manter, permitindo que você crie uma infraestrutura de chave pública (PKI) privada para afirmar identidades por meio de certificados e estabelecer uma raiz de confiança em suas cargas de trabalho.
Embora este guia de arquitetura se concentre em uma implantação CAS completa (indicada como arquitetura 1 na figura abaixo (ou seja, aquela em que todas as autoridades de certificação estão hospedadas no Google Cloud), o CAS é extremamente flexível e capacita sua organização a criar uma PKI privada em uma variedade de diferentes maneiras, conforme ilustrado no diagrama abaixo.
Também forneceremos detalhes sobre como usar CSR (Solicitação de assinatura de certificado) para implementar a arquitetura híbrida, na qual as CAs podem residir fora do GCP (arquiteturas #2-3).
Serviço de autoridade de certificação (CAS) - O serviço de autoridade de certificação é um serviço do Google Cloud altamente disponível e escalonável que permite simplificar, automatizar e personalizar a implantação, o gerenciamento e a segurança de autoridades de certificação (CA) privadas.
Key Management Service (KMS) - O Cloud Key Management Service permite criar, importar e gerenciar chaves criptográficas e executar operações criptográficas em um único serviço de nuvem centralizado. Você pode usar essas chaves e realizar essas operações usando o Cloud KMS diretamente, usando o Cloud HSM ou o Cloud External Key Manager ou usando integrações de chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês) em outros serviços do Google Cloud.
Google Cloud Storage (GCS) - Cloud Storage é um serviço gerenciado para armazenamento de dados não estruturados. Armazene qualquer quantidade de dados e recupere-os com a frequência que desejar.
Ao projetar PKI com GCP CAS, os seguintes limites devem ser levados em consideração, bem como cotas e limites e limitações conhecidas:
| Recurso | Unidade | Valor |
|---|---|---|
| CAs pendentes 1 | por local por projeto | 100 |
| CAs | por local por projeto | 1.000 |
| Certificados revogados não expirados 2 | por CA ou lista de certificados revogados (CRL) | 500.000 |
1 autoridade de certificação (CA) pendente é uma CA subordinada que foi criada, mas ainda não ativada e, portanto, está no estado AWAITING_USER_ACTIVATION.
2 A CRL pode conter no máximo 500.000 certificados revogados não expirados. Se você tentar revogar mais que esse limite, a solicitação de revogação falhará. Se precisar revogar mais de 500.000 certificados, recomendamos que você espere até que os certificados revogados existentes expirem ou revogue o certificado CA emissor.
##Instruções do Terraform:
Faça logon na sua organização e atribua a si mesmo uma função de administrador de serviço do CA e administrador do Cloud KMS no projeto a ser usado para a implantação.
Se for necessário criar um novo projeto e ativar o faturamento. Siga as etapas deste guia.
Abra o Cloud Shell e clone o seguinte repositório git usando o comando abaixo:
git clone https://github.com/GCP-Architecture-Guides/csa-certificate-authority-service.git
Navegue até a pasta csa-certificate-authority-service.
cd csa-certificate-authority-service</th>
Exporte o ID do projeto na variável Terraform
export TF_VAR_demo_project_id=[YOUR_PROJECT_ID]
Enquanto estiver na pasta csa-certificate-authority-service, execute os comandos abaixo em ordem.
terraform init terraform plan terraform apply
se solicitado, autorize a chamada da API.
Assim que a implantação for concluída, ele publicará o resumo de saída dos ativos orquestrados. Ele implanta os recursos em cinco minutos.
Após concluir a demonstração, navegue até a pasta Certificate-authority-service e execute o comando abaixo para destruir todos os recursos da demonstração.
terraform destroy
## Resumo do Terraform:
| Piscina | CA | Validade | Estado | Nome do Assunto | Região | Nível |
|---|---|---|---|---|---|---|
| Pool raiz de demonstração | CA raiz | 10 anos | Habilitado | Organização: Demonstração CA CN: demonstração ID do recurso: [padrão] | us-central1 (Iowa) | Empresa |
| Sub-pool de demonstração | Sub CA com CA raiz no Google Cloud | 3 anos | Habilitado | Organização: Demonstração CA CN: demonstração ID do recurso: [padrão] | us-central1 (Iowa) | Empresa |
| Demo-Sub-Pool-2 | Sub CA com CA raiz no Google Cloud | 3 anos | Habilitado | Organização: Demonstração CA CN: demonstração ID do recurso: [padrão] | nós-leste1 | Empresa |
| Piscina | Métodos de RSC aceitos | Chaves e algoritmos permitidos | Tamanho da chave e algoritmo | Opções de publicação | Valores de linha de base configurados | Restrições de extensão configuradas | Restrições de identidade configuradas |
|---|---|---|---|---|---|---|---|
| Pool raiz de demonstração | Permitir tudo | Sem restrições | RSA_PKCS1_4096_SHA256 | Para o bucket do GCS no formato PEM | Nenhum | Copie todas as extensões das solicitações de certificado | Copiar assunto e SAN(s) de solicitações de certificado |
| Sub-pool de demonstração | Permitir tudo | Sem restrições | RSA_PKCS1_4096_SHA256 | Para o bucket do GCS no formato PEM | Nenhum | Copie todas as extensões das solicitações de certificado | Copiar assunto e SAN(s) de solicitações de certificado |
| Demo-Sub-Pool-2 | Permitir tudo | Sem restrições | RSA_PKCS1_4096_SHA256 | Para o bucket do GCS no formato PEM | Nenhum | Copie todas as extensões das solicitações de certificado | Copiar assunto e SAN(s) de solicitações de certificado |
Melhores práticas para serviço de autoridade de certificação
O serviço de autoridade de certificação do Google Cloud tem vários requisitos de registro e monitoramento para garantir a segurança e a integridade do serviço. Esses requisitos incluem o seguinte:
Registro em log de auditoria: as operações de log realizadas no serviço, como emissão, renovação e revogação de certificados, são registradas e podem ser auditadas pelos clientes.
Notificações de eventos: os clientes podem receber notificações de eventos importantes, como expiração de certificados, por e-mail ou por meio de um webhook.
Transparência de certificados: Todos os certificados emitidos são registrados em logs de Transparência, o que permite auditoria de emissão e revogação de certificados.
Monitoramento de segurança e disponibilidade: As equipes de segurança e operações monitoram constantemente o serviço em busca de possíveis ameaças à segurança e problemas de disponibilidade.
Conformidade: o serviço de autoridade de certificação do Google Cloud está em conformidade com vários padrões que especificam requisitos operacionais e de segurança para autoridades de certificação.
No geral, estes requisitos de registo e monitorização visam proporcionar aos clientes transparência e visibilidade do serviço, garantindo ao mesmo tempo a segurança e a disponibilidade do serviço.
Os serviços do Google Cloud gravam registros de auditoria para ajudar você a responder às perguntas "Quem fez o quê, onde e quando?" dentro dos seus recursos do Google Cloud.
Os seguintes tipos de logs de auditoria estão disponíveis para o CA Service:
Registros de auditoria de atividades administrativas
Inclui operações de "gravação administrativa" que gravam metadados ou informações de configuração.
Não é possível desativar os registros de auditoria de atividades administrativas.
Registros de auditoria de acesso a dados
Inclui operações de "leitura administrativa" que leem metadados ou informações de configuração. Também inclui operações de “leitura de dados” e “gravação de dados” que leem ou gravam dados fornecidos pelo usuário.
Para receber logs de auditoria de acesso a dados, você deve ativá-los explicitamente.
Para logs de auditoria específicos criados pelo Serviço de Autoridade de Certificação, consulte.
Os registros de auditoria de atividades administrativas estão sempre ativados; você não pode desativá-los.
Os logs de auditoria de acesso a dados são desabilitados por padrão e não são gravados, a menos que sejam explicitamente habilitados.
Para obter informações sobre como habilitar alguns ou todos os seus logs de auditoria de acesso a dados, consulte Habilitar logs de auditoria de acesso a dados.
No console do Google Cloud, você pode usar o Logs Explorer para recuperar as entradas do registro de auditoria do seu projeto, pasta ou organização do Cloud:
No console do Google Cloud, acesse a página Logging> Logs Explorer.
Selecione um projeto, uma pasta ou uma organização do Cloud existente.
No painel Construtor de consultas, faça o seguinte:
protoPayload.serviceName="privateca.googleapis.com"
O Cloud Monitoring pode ser usado para monitorar operações executadas em recursos no Certificate Authority Service.
Use as instruções a seguir para ativar os alertas recomendados.
Acesse a página Visão geral do serviço CA no console do Google Cloud.
No canto superior direito da página Visão geral, clique em + 5 alertas recomendados .
Habilite ou desabilite cada alerta lendo sua descrição.
Alguns alertas suportam limites personalizados. Por exemplo, você pode especificar quando deseja ser alertado sobre um certificado CA expirado ou a taxa de erro para uma alta taxa de falhas na criação de certificados.
Todos os alertas suportam canais de notificação.
Clique em Enviar depois de ativar todos os alertas desejados.
Documente políticas e modelos de certificados
Restrições de identidade
Restrições de extensão
Principais condições de uso
Identificadores de política
Extensões
Para mitigar o risco de abuso, as políticas de certificados devem ser revisadas para garantir que os modelos tenham funcionalidade aprovada e definida
Criar plano de resposta de compromisso da CA
Educar todas as partes interessadas
Revise as políticas de segurança e comunicação da CA pelo menos uma vez por ano
Estabeleça planos de CA de backup
CAs de inventário
Verifique se apenas CAs aprovadas são usadas
Certifique-se de que apenas raízes aprovadas sejam confiáveis
Faça o inventário de CAs raiz confiáveis em sistemas de terceiros confiáveis
Revise e verifique as permissões dos modelos de certificado existentes
Aplicar verificação de revogação em sistemas de terceiros confiáveis
Habilitar logs de auditoria e alertas
Identifique o comprometimento com base no design de alertas e relatórios
Estabeleça uma compreensão clara do que ocorreu
Quem detectou o incidente.
Se disponível, quem perpetrou o incidente.
Quando a CA foi comprometida.
Onde ocorreu o incidente.
Quais raízes, sub-CAs e o número de certificados de usuário final afetados pelo incidente.
A suposta causa subjacente do incidente.
Quais medidas corretivas foram tomadas ou serão tomadas para resolver a causa subjacente do incidente.
Uma lista de certificados e domínios envolvidos na violação.
Como o incidente foi detectado?
Descrição detalhada da exploração.
Detalhes sobre qual infraestrutura foi comprometida.
Detalhes sobre como a infraestrutura foi comprometida.
Uma linha do tempo detalhada dos eventos.
A vulnerabilidade foi detectada por operações normais? Se não foi, por quê?
A vulnerabilidade foi descoberta na auditoria mais recente? Se sim, a vulnerabilidade foi corrigida? Se a vulnerabilidade não foi corrigida, por que não?
Esta vulnerabilidade foi detectada pela auditoria mais recente? Se não, explique o porquê.
Que mudanças políticas precisam ser feitas?
Qualquer outra informação apropriada.
Ative a equipe de resposta a incidentes
Conter e isolar o ambiente de CA impactado a. Para impedir que uma CA emita certificados, consulte
Estabeleça um plano para comunicar o impacto e as próximas etapas das mitigações às partes interessadas impactadas (internas/externas)
Após a conclusão de uma investigação e verificação da contenção, execute o seguinte:
Revogar e redefinir credenciais para quaisquer identidades comprometidas que foram mapeadas para uma função que fornece permissões elevadas para CAs e políticas/modelos associados.referência-1 e referência-2
Revogar CAs comprometidas e certificados associados e estabelecer nova referência de CAs
Adicionar ao status de CRL/atualização no Respondente OCSP (se não for automatizado) para notificar assuntos, partes confiáveis e fornecedores
Revogar certificados existentes e reemitir certificados de novas referências de CAs
Remover/substituir certificados raiz
Validar se a verificação de revogação está habilitada em sistemas de terceiros confiáveis
Validar substituições de certificado e raiz
Acompanhe e relate o progresso
Consulte abaixo o custo mensal estimado para executar este ambiente de demonstração. Observe que isso foi estimado no momento da criação do padrão. A estimativa pode mudar com o tempo e variar por região. Revise o custo de cada recurso na Calculadora de preços do Google Cloud.
| SKU de DevOps | SKU empresarial | |
|---|---|---|
| Taxa mensal da CA | US$ 20 | US$ 200 |
| Taxas de certificado | 0-50 mil a US$ 0,3 50 mil -100 mil a US$ 0,03 Mais de 100 mil @ US$ 0,0009 Camadas entre CAs | 0-50 mil a US$ 0,5 50 mil -100 mil a US$ 0,05 Mais de 100 mil @ US$ 0,001 Camadas entre CAs |
| Suporte HSM para chave CA | ||
| Chave CA BYO | X | |
| Certificados rastreados e revogados | X | |
| QPS | 25 | 7 |
| Otimizado para ... | Alto volume, curta duração | Baixo volume, longa duração |
Visão geral do CAS
Apresentando o Blog do CAS
Vídeos instrutivos CAS
Repositório CAS GitHub
