Planejando a estrutura de uma hierarquia de autoridade de certificação

Como prática recomendada, planeje uma hierarquia de autoridades de certificação que corresponda à estrutura da sua organização. Normalmente, você pode implementar uma das seguintes estruturas comuns de CA.

Dois níveis: autoridade de certificação raiz e autoridade de certificação subordinada

Use esta opção se a sua carga de trabalho requer a estrutura de autoridade de certificação mais simples. Neste cenário, você cria uma única autoridade de certificação raiz confiável. Em seguida, você cria uma autoridade de certificação subordinada, por exemplo uma autoridade de certificação intermediária, para emitir certificados leaf para seus apps e serviços.

Três níveis: CA raiz e duas autoridades de certificação subordinadas

Use esta opção se a sua carga de trabalho exigir uma camada adicional entre as operações de autoridade de certificação raiz e de autoridade de certificação de nível mais baixo. Nesse cenário, a AC subordinada intermediária é usada somente para assinar Autoridades de Certificação subordinadas que emitem certificados leaf para seus aplicativos.

Configurando a profundidade de sua hierarquia de autoridade de certificação

Quando você está criando uma autoridade de certificação no Secrets Manager, é possível configurar o parâmetro Comprimento máximo do caminho para determinar quantos certificados de autoridade de certificação podem existir em sua cadeia de autoridade. Este valor reforça quantos certificados de autoridade de certificação podem existir no caminho de certificação de sua autoridade de certificação.

Em geral, você pode configurar uma AC raiz que não limite o número de Autoridades Certificadoras subordinadas que ela pode criar em seu caminho de certificação. No entanto, a definição de um comprimento máximo de caminho em Autoridades de Certificação subordinadas é uma etapa de segurança importante para evitar Autoridades de Certificação mal configuradas. Dependendo da colocação de uma autoridade de certificação subordinada em sua hierarquia, certifique-se de especificar um comprimento de caminho máximo para que seu poder de autoridade de assinatura seja limitado a apenas a profundidade pretendida.

O comprimento máximo do caminho que você define não inclui certificados leafs. No exemplo anterior, a AC subordinada no nível 4 pode emitir certificados de folha, mas não pode ter mais certificados de AC em seu caminho.

Escolhendo um período de validade para seus certificados

O período de validade de um certificado X.509 é um campo obrigatório que determina por quanto tempo o certificado é confiável e permanece válido. Ao planejar sua hierarquia de autoridade de certificação, trabalhe retrocedendo a partir de sua vida útil preferencial para os certificados leaf que deseja emitir para seus aplicativos. Em seguida, determine o período de validade dos certificados de autoridade de certificação.

Um certificado deve ter um período de validade que seja menor ou igual ao período de validade da CA que o emitiu. Por exemplo, se você criar uma CA raiz com um tempo de vida (TTL) de 10 anos, todas as Autoridades Certificadoras intermediárias subordinadas a ela deverão ter um TTL igual ou inferior a 10 anos. Da mesma forma, se uma autoridade de certificação intermediária tiver TTL de 3 anos, qualquer certificado leaf deverá ter um TTL que seja igual ou inferior a 3 anos.

1. Escolha um período de validade para os seus certificados leaf que seja apropriado para o seu caso de uso.

   Os certificados privados que podem ser criados com o Secrets Manager são considerados certificados leaf que podem ser emitidos para uma entidade final, como um app do cliente ou do servidor. Com o Secrets Manager, é possível criar certificados com um período de validade máximo de três anos ou 36 meses. Depois de determinar um TTL ou período de validade para certificados folha, você define o valor usando um modelo de certificado para que o TTL preferido seja aplicado sempre que um novo certificado folha for gerado.

   Quanto mais curto for o TTL dos seus certificados leaf, mais protegido você estará contra a exposição inadvertida ou o comprometimento do seu certificado e da sua chave privada. Um período de validade mais curto para os seus certificados significa que você reduz a probabilidade de comprometimento, mas também requer que você gire o certificado com mais frequência para garantir que ele permaneça válido. Para evitar uma indisponibilidade involuntária, é possível programar a rotação automática de seus certificados privados.

2. Escolha um período de validade para a autoridade de certificação subordinada.

   Como prática recomendada, defina um período de validade para um certificado de AC subordinado que seja significativamente mais longo do que os períodos de validade dos certificados que ele emite. Defina um período de validade de uma autoridade de certificação pai que seja de duas a cinco vezes o período de qualquer certificado de autoridade de certificação ou certificado leaf filho que ele emite. Por exemplo, se você tem um hierarquia de autoridade de certificação de dois níveis e deseja emitir certificados leaf com um TTL de um ano, configure a autoridade de certificação emissora subordinada com um TTL de três anos. Sempre é possível atualizar os certificados de autoridade de certificação subordinadas sem substituir o certificado de autoridade de certificação raiz.

3. Escolha um período de validade para a sua autoridade de certificação raiz.

   Quando você atualiza um certificado de autoridade de certificação raiz, a mudança impacta toda a infraestrutura de sua chave pública. Para minimizar o impacto, recomenda-se configurar um período de validade longo para o seu certificado de autoridade de certificação raiz. No Secrets Manager, o TTL padrão para certificados raiz é de 10 anos.

Escolha de um serviço de gerenciamento de chaves

Antes de criar uma autoridade de certificação em Secrets Manager, você deve escolher um serviço de gerenciamento de chaves (KMS) para gerar as chaves públicas e privadas para a sua CA. Você pode escolher o mecanismo de certificado privado KMS interno; nesse caso, as chaves públicas e privadas da CA são criadas no software e gerenciadas internamente pelo serviço. Você também pode optar por gerenciar suas chaves em um módulo de segurança de hardware (HSM) externo. Secrets Manager suporta IBM Cloud Hyper Protect Crypto Services (HPCS) para gerenciar as chaves da CA. Você pode configurar uma CA para usar chaves existentes em um repositório de chaves privadas HPCS ou permitir que Secrets Manager crie novas chaves para a CA.

O mecanismo de certificado privado Secrets Manager está usando a API PKCS#11 para se comunicar com o HPCS. A autenticação e a autorização são feitas usando uma chave de API do IAM que é gerenciada usando um Secrets Manager segredo de credenciais do IAM. As operações de assinatura de criptografia são realizadas no HPCS com o material da chave privada da CA que nunca sai do dispositivo de criptografia.

Observação: o site Secrets Manager não controla os custos ou limites de taxas associados à criação de certificados CA com chaves no HPCS.

Como escolher um algoritmo para a geração de chaves

Antes de criar uma autoridade de certificação no Secrets Manager, é necessário escolher um algoritmo de chave para gerar as chaves públicas e privadas para a sua autoridade de certificação. O par de chaves pública e privada é usado para autenticar uma conexão SSL/TLS. Se você não tiver certeza de onde começar, é possível usar o guia sugerido a seguir para selecionar um algoritmo de chave.

1. Escolha uma família de algoritmos.

   O algoritmo de chave que você selecionar determinará o algoritmo de criptografia e o tamanho da chave a usar para gerar chaves e assinar certificados. Como uma melhor prática, use a mesma família de algoritmos para todos os certificados que pertencem a uma cadeia de certificados. O Secrets Manager suporta as famílias de algoritmos a seguir.

   Famílias de algoritmos e tamanhos de chave compatíveis

   Família de algoritmos	Descrição	Tamanhos de chaves suportados
   RSA	Amplamente usado e compatível com a maioria dos navegadores e servidores, o RSA é o padrão do setor para criptografia de chave pública-privada.	2048 bits 4096 bits
   Curva Elíptica (CE)	Gera chaves mais fortes e certificados menores. Por exemplo, uma chave EC de 256 bits é equivalente em força de criptografia a uma chave RSA de 3072 bits.	224 bits 256 bits 384 bits 521 bits

2. Escolha um tamanho de chave.

   O tamanho ou o comprimento da chave que você selecionar determina a segurança da criptografia. Quanto maior o tamanho da chave para uma família de algoritmos, mais difícil é quebrá-la. Tenha em mente que comprimentos de chave mais longos resultam em mais dados para armazenar e transmitir, o que pode impactar o desempenho do seu certificado. Como uma melhor prática, escolha um tamanho de chave que seja apropriado para o período de TTL ou validade do seu certificado.

   Para certificados de vida útil mais longa, é recomendável usar comprimentos de chave mais longos para fornecer mais proteção de criptografia.

Ler Lista de Revogação de Certificado

Com esse endpoint, você pode recuperar a LCR atual no formato bruto codificado em DER. Se /pem for adicionado ao ponto de extremidade, a LCR será retornada no formato PEM.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/crl(/pem)

Response 200 OK
<binary DER-encoded CRL>

Para validar que seus certificados de CA folha ou intermediários não sejam revogados do contexto de um certificado folha, é possível configurar sua CA com a propriedade "crl_distribution_points_encoded": true. Essa configuração codifica o endereço URL que é usado para fazer download da LCR da CA emissora na propriedade como X509v3 CRL Distribution Points em cada certificado de CA intermediário ou folha. Em seguida, seu validador de CA pode verificar se os certificados de CA folha ou intermediário são revogados.

Ler certificado de autoridade de certificação

Com esse endpoint, você pode recuperar o certificado da CA em formato bruto codificado em DER. Se /pem for adicionado ao ponto de extremidade, o certificado da CA será retornado no formato PEM.

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca(/pem)

Response 200 OK
<binary DER-encoded certificate >

Ler cadeia de certificados de CA

Com esse ponto de extremidade, você pode recuperar a cadeia de certificados da CA, que inclui a CA no formato PEM. Esse terminal é bare.. Ele não retorna uma estrutura de dados padrão do Vault e a CLI do Vault não pode lê-la,

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca_chain

Response 200 OK
<PEM-encoded certificate chain>

Para verificar se a cadeia de CAs é do contexto de um certificado folha, você pode configurar suas Autoridades de Certificação em Secrets Manager com a propriedade "issuing_certificates_urls_encoded": true. Em cada certificado de CA intermediário ou folha, essa configuração codifica o URL que é usado para baixar o certificado de CA emissor na propriedade Authority Information Access/CA Issuers. Em seguida, seu validador de CA pode validar cada certificado de CA.