Criar uma hierarquia de CA

Com CA privada da AWS, você pode criar uma hierarquia de autoridades de certificação com até cinco níveis. A CA raiz, na parte superior de uma árvore de hierarquia, pode ter qualquer número de ramificações. A CA raiz pode ter até quatro níveis de CAs subordinadas em cada ramificação. Você também pode criar várias hierarquias, cada uma com sua própria raiz.

Uma hierarquia de CA bem projetada oferece os seguintes benefícios:

• Controles de segurança granulares apropriados para cada CA

• Divisão de tarefas administrativas para melhor balanceamento de carga e segurança

• Uso de CAs com confiança limitada e revogável para operações diárias

• Períodos de validade e limites de caminho de certificado

O diagrama a seguir ilustra uma hierarquia de CA de três níveis simples.

Cada CA na árvore é apoiada por um certificado X.509 v3 com autoridade de assinatura (simbolizada pelo ícone). pen-and-paper Isso significa que, como CAs, elas podem assinar outros certificados subordinados a elas. Quando uma CA assina um certificado CA de nível inferior, ela confere autoridade limitada e revogável no certificado assinado. A autoridade de certificação raiz no nível 1 assina certificados CA subordinados de alto nível no nível 2. Essas CAs, por sua vez, assinam certificados para CAs no nível 3 que são usados por administradores de PKI (infraestrutura de chave pública) que gerenciam certificados de entidade final.

A segurança em uma hierarquia de CA deve ser configurada para ser mais forte na parte superior da árvore. Essa disposição protege o certificado CA raiz e sua chave privada. A CA raiz ancora a confiança para todas as CAs subordinadas e para os certificados de entidade final abaixo dela. Embora danos localizados possam resultar do comprometimento de um certificado de entidade final, o comprometimento da raiz destrói a confiança em toda a PKI. As CAs raiz e subordinadas de nível superior são usadas com pouca frequência (geralmente para assinar outros certificados CA). Consequentemente, são rigorosamente controladas e auditadas para garantir um risco menor de comprometimento. Nos níveis inferiores da hierarquia, a segurança é menos restritiva. Essa abordagem permite as tarefas administrativas de rotina de emissão e revogação de certificados de entidade final para usuários, hosts de computador e serviços de software.

nota

Usar uma CA raiz para assinar um certificado subordinado é um evento raro que ocorre apenas em algumas circunstâncias:

• Quando a PKI é criada

• Quando uma CA de nível superior precisa ser substituída

• Quando um respondedor de lista de revogação de certificados (CRL) ou de protocolo OCSP precisa ser configurado

As CAs raiz e outras CAs de alto nível exigem processos operacionais altamente seguros e protocolos de controle de acesso.

Validar certificados de entidade final

Os certificados de entidade final derivam sua confiança de um caminho de certificação que leva de volta por meio das CAs subordinadas para uma CA raiz. Quando um navegador da Web ou outro cliente é apresentado com um certificado de entidade final, ele tenta construir uma cadeia de confiança. Por exemplo, ele pode verificar se o nome distinto do emissor do certificado e o nome distinto do assunto correspondem aos campos correspondentes do certificado CA emissor. A correspondência continuaria em cada nível sucessivo na hierarquia até que o cliente atinja uma raiz confiável contida em seu armazenamento de confiança.

O armazenamento de confiança é uma biblioteca de CAs confiáveis que o navegador ou o sistema operacional contém. Para uma PKI privada, a TI da sua organização deve garantir que cada navegador ou sistema tenha previamente adicionado a CA raiz privada ao seu armazenamento de confiança. Caso contrário, o caminho de certificação não poderá ser validado, resultando em erros de cliente.

O diagrama seguinte mostra o caminho de validação que um navegador segue quando apresentado com um certificado X.509 de entidade final. Observe que o certificado de entidade final não possui autoridade de assinatura e serve apenas para autenticar a entidade que o possui.

O navegador inspeciona o certificado de entidade final. O navegador descobre que o certificado oferece uma assinatura de CA subordinada (nível 3) como sua credencial de confiança. Os certificados para as CAs subordinadas devem ser incluídos no mesmo arquivo PEM. Como alternativa, eles também podem estar em um arquivo separado que contém os certificados que compõem a cadeia de confiança. Ao encontrá-los, o navegador verifica o certificado de CA subordinada (nível 3) e descobre que ele oferece uma assinatura de CA subordinada (nível 2). Por sua vez, a CA subordinada (nível 2) oferece uma assinatura da CA raiz (nível 1) como sua credencial de confiança. Se o navegador encontrar uma cópia do certificado CA raiz privado pré-instalado em seu armazenamento de confiança, ele validará o certificado de entidade final como confiável.

Normalmente, o navegador também verifica cada certificado em relação a uma lista de revogação de certificados (CRL). Um certificado expirado, revogado ou configurado incorretamente é rejeitado e a validação falha.

Planejar estrutura de uma hierarquia de CA

Em geral, sua hierarquia de CA deve refletir a estrutura de sua organização. Aponte para um comprimento de caminho (ou seja, o número de níveis de CA) não maior do que o necessário para delegar funções administrativas e de segurança. Adicionar uma CA à hierarquia significa aumentar o número de certificados no caminho de certificação, o que aumenta o tempo de validação. Manter o comprimento do caminho no mínimo também reduz o número de certificados enviados do servidor ao cliente ao validar um certificado de entidade final.

Em teoria, uma CA raiz, que não tem pathLenConstraintparâmetros, pode autorizar níveis ilimitados de CAs subordinadas. Uma CA subordinada pode ter quantas CAs subordinadas filhas forem permitidas por sua configuração interna. CA privada da AWS hierarquias gerenciadas oferecem suporte a caminhos de certificação da CA com até cinco níveis de profundidade.

As estruturas de CA bem projetadas têm vários benefícios:

• Controles administrativos separados para diferentes unidades organizacionais

• A capacidade de delegar acesso a CAs subordinadas

• Uma estrutura hierárquica que protege as CAs de nível superior com controles de segurança adicionais

Duas estruturas comuns de CA realizam tudo isso:

• Dois níveis de CA: CA raiz e CA subordinada

  Essa é a estrutura de CA mais simples que permite políticas separadas de administração, controle e segurança para a CA raiz e uma CA subordinada. Você pode manter controles e políticas restritivos para sua CA raiz enquanto permite acesso mais permissivo para a CA subordinada. A última é utilizada para emissão em massa de certificados de entidade final.

• Três níveis de CA: CA raiz e duas camadas de CA subordinada

  Semelhante à acima, essa estrutura adiciona uma camada de CA para separar ainda mais a CA raiz das operações da CA de nível inferior. A camada de CA média é usada apenas para assinar CAs subordinadas que realizam a emissão de certificados de entidade final.

Estruturas de CA menos comuns incluem o seguinte:

• Quatro ou mais níveis de CA

  Embora menos comuns do que hierarquias de três níveis, as hierarquias de CA com quatro ou mais níveis são possíveis e podem ser necessárias para permitir delegação administrativa.

• Um nível de CA: somente CA raiz

  Essa estrutura é comumente usada para desenvolvimento e teste quando uma cadeia completa de confiança não é necessária. Usada na produção, é atípica. Além disso, ela viola a prática recomendada de manter políticas de segurança separadas para a CA raiz e as CAs que emitem certificados de entidade final.

  No entanto, se você já estiver emitindo certificados diretamente de uma CA raiz, poderá migrar para o. CA privada da AWS Isso fornece vantagens de segurança e controle sobre o uso de uma CA raiz gerenciada com OpenSSL ou outro software.

Exemplo de uma PKI privada para um fabricante

Neste exemplo, uma empresa de tecnologia hipotética fabrica dois produtos da Internet das Coisas (IoT), uma lâmpada inteligente e uma torradeira inteligente. Durante a produção, cada dispositivo recebe um certificado de entidade final para que possa se comunicar de forma segura pela Internet com o fabricante. A PKI da empresa também protege sua infraestrutura de computação, incluindo o site interno e vários serviços de computação auto-hospedados que executam operações financeiras e comerciais.

Consequentemente, a hierarquia de CA modela estreitamente esses aspectos administrativos e operacionais do negócio.

Essa hierarquia contém três raízes, uma para Operações internas e duas para Operações externas (uma CA raiz para cada linha de produto). Ela também ilustra vários comprimentos de caminho de certificação, com dois níveis de CA para Operações internas e três níveis para Operações externas.

O uso de CAs raiz separadas e camadas de CAs subordinadas adicionais no lado de Operações externas é uma decisão de design que atende às necessidades de negócios e de segurança. Com várias árvores de CA, a PKI tem um futuro comprovado contra reorganizações corporativas, alienações ou aquisições. Quando ocorrem alterações, uma hierarquia de CA raiz inteira pode ser movida de forma limpa com a divisão que ela protege. E com dois níveis de CA subordinada, as CAs raiz têm um alto nível de isolamento das CAs de nível 3 que são responsáveis pela assinatura em massa dos certificados para milhares ou milhões de itens fabricados.

No lado interno, as operações corporativas da Web e de computação interna completam uma hierarquia de dois níveis. Esses níveis permitem que administradores da Web e engenheiros de operações gerenciem a emissão de certificados de forma independente para seus próprios domínios de trabalho. A compartimentação da PKI em domínios funcionais distintos é uma prática recomendada de segurança e protege cada um de um comprometimento que pode afetar o outro. Os administradores da Web emitem certificados de entidade final para uso por navegadores da Web em toda a empresa, autenticando e criptografando comunicações no site interno. Os engenheiros de operações emitem certificados de entidade final que autenticam hosts de datacenter e serviços de computação entre si. Esse sistema ajuda a manter os dados confidenciais seguros, criptografando-os na LAN.

Definir restrições de comprimento no caminho de certificação

A estrutura de uma hierarquia de CA é definida e aplicada pela extensão das restrições básicas que cada certificado contém. A extensão define duas restrições:

• cA: se o certificado definir uma CA. Se esse valor for falso (o padrão), o certificado será um certificado de entidade final.

• pathLenConstraint: o número máximo de CAs subordinadas de nível inferior que podem existir em uma cadeia de confiança válida. O certificado da entidade final não conta, porque não é um certificado de CA.

Um certificado CA raiz precisa de flexibilidade máxima e não inclui uma restrição de comprimento de caminho. Isso permite que a raiz defina um caminho de certificação de qualquer comprimento.

nota

CA privada da AWS limita o caminho de certificação a cinco níveis.

As CAs subordinadas têm valores de pathLenConstraint iguais ou superiores a zero, dependendo da localização no posicionamento da hierarquia e dos recursos desejados. Por exemplo, em uma hierarquia com três CAs, nenhuma restrição de caminho é especificada para a CA raiz. A primeira CA subordinada tem um comprimento de caminho de 1 e, portanto, pode assinar as CAs filhas. Cada uma dessas CAs filhas deve necessariamente ter um valor igual a pathLenConstraint. Isso significa que elas podem assinar certificados de entidade final, mas não podem emitir certificados CA adicionais. Limitar o poder de criar novas CAs é um controle de segurança importante.

O diagrama a seguir ilustra essa propagação de autoridade limitada pela hierarquia.

Nesta hierarquia de quatro níveis, a raiz é irrestrita (como sempre). Mas a primeira CA subordinada tem um pathLenConstraint valor igual a 2, o que limita suas CAs filhas de terem mais de dois níveis de profundidade. Consequentemente, para um caminho de certificação válido, o valor da restrição deve diminuir para zero nos próximos dois níveis. Se um navegador da Web encontrar um certificado de entidade final desta ramificação que tenha um comprimento de caminho superior a quatro, a validação falhará. Esse certificado pode ser o resultado de uma CA criada acidentalmente, de uma CA configurada incorretamente ou de uma emissão não autorizada.

Gerenciar o comprimento do caminho com modelos

CA privada da AWS fornece modelos para a emissão de certificados raiz, subordinados e de entidade final. Esses modelos encapsulam as melhores práticas para os valores de restrições básicas, incluindo o comprimento do caminho. Os modelos incluem o seguinte:

• RootCACertificate/V1

• Certificado CA subordinado_ 0/V1 PathLen

• Certificado CA subordinado_ 1/V1 PathLen

• Certificado CA subordinado _ 2/V1 PathLen

• Certificado CA subordinado _ 3/V1 PathLen

• EndEntityCertificate/V1

A API IssueCertificate retornará um erro se você tentar criar uma CA com um comprimento de caminho maior ou igual ao comprimento de caminho de seu certificado CA emissor.

Para obter mais informações sobre modelos de certificado, consulte Noções básicas sobre modelos de certificados.

Automatizar a configuração da hierarquia da CA com o AWS CloudFormation

Depois de escolher um design para sua hierarquia de CA, você pode testá-lo e colocá-lo em produção usando um AWS CloudFormation modelo. Para obter um exemplo desse modelo, consulte Declarar uma hierarquia de CA privada no Guia do usuário do AWS CloudFormation .