O blog da AWS

Como implementar uma solução híbrida de infraestrutura de chaves públicas (PKI) na AWS

Por Max Farnga, Consultor de transformação de segurança da AWS 
À medida que os clientes migram suas cargas de trabalho para a Amazon Web Services (AWS), eles podem estar executando uma combinação híbrida usando sua infraestrutura local e a nuvem. Quando certificados de segurança são emitidos para essa infraestrutura, ter uma entidade certificadora raiz comum de confiança na hierarquia de certificados permite a consistência e a interoperabilidade de sua solução de infraestrutura de chave pública (PKI).Neste blog post, mostraremos como você pode planejar e implantar uma infraestrutura de chave pública (PKI) que permite que certificados sejam emitidos em um ambiente híbrido (na nuvem e on-premises) com uma entidade certificadora raiz comum. Essa solução usará o serviço Certificate Authority do Windows Server (Windows CA), também conhecido como Active Directory Certificate Services (ADCS) para distribuir e gerenciar certificados x.509 para usuários do Active Directory, controladores de domínio, roteadores, estações de trabalho, servidores web, dispositivos móveis e outros dispositivos. E as soluções , incluindo API Gateway, CloudFront, Elastic Load Balancers e outras cargas de trabalho.

O serviço Certificate Authority do Windows Server (Windows CA) também se integra ao AWS CloudHSM para armazenar com segurança as chaves privadas que assinam os certificados emitidos por suas CAs e usar o HSM para realizar as operações de assinatura criptográfica. Na Figura 1, o diagrama abaixo mostra como o AWS Private CA e o Windows CA podem ser usados juntos para emitir certificados em um ambiente híbrido.

Figura 1: Hierarquia de PKI híbrida

A PKI é uma estrutura que permite um ambiente digital seguro e confiável por meio do uso de um mecanismo de criptografia de chave pública e privada. A PKI mantém transações eletrônicas seguras na Internet e em redes privadas. Também controla a verificação, emissão, revogação e validação de sistemas individuais em uma rede.

Há dois tipos de PKI:

Este blogpost se concentra na implementação de uma PKI privada para emitir e gerenciar certificados privados.

Ao implementar uma PKI, podem haver desafios do ponto de vista da segurança, de infraestrutura e das operações de dia-a-dia, especialmente ao lidar com cargas de trabalho em várias plataformas. Esses desafios incluem gerenciar PKIs isolados para redes individuais no ambiente on-premises e na nuvem da AWS, gerenciar PKIs sem módulos de segurança de hardware (HSM) na nuvem ou em ambiente on-premises e falta de automação para escalar rapidamente os servidores de PKI para atender à demanda.

A Figura 2 mostra como uma PKI interna pode ser limitada a uma única rede. No exemplo a seguir são demonstradas a CA raiz, as CAs emissoras e o ponto de distribuição da lista de certificados revogados (CRL), onde estão todos na mesma rede e emitem certificados criptográficos somente para usuários e dispositivos na mesma rede privada.

Figura 2: Hierarquia de PKI local em uma única rede

Planejando a implantação do seu sistema PKI

É importante considerar cuidadosamente seus requisitos de negócios, casos de uso de criptografia, arquitetura de rede corporativa e os recursos de suas equipes internas. Você também deve planejar como gerenciar a confidencialidade, a integridade e a disponibilidade das chaves criptográficas. Essas considerações devem orientar o projeto e a implementação do seu novo sistema de PKI.

Na seção abaixo, descrevemos os principais serviços e componentes usados para projetar e implementar essa solução híbrida de PKI.

Principais serviços e componentes dessa solução híbrida de PKI

Visão geral da solução

Essa PKI híbrida pode ser usada se você precisar de uma nova PKI privada ou quiser fazer o upgrade de uma PKI existente com um provedor de serviços criptográficos (CSP) para uma PKI segura com Windows Cryptography Next Generation (CNG). O design híbrido de PKI permite que você gerencie perfeitamente as chaves criptográficas em toda a infraestrutura de TI da sua organização, desde on-premises até várias redes da AWS.

Figura 3: Arquitetura da solução de PKI híbrida

A arquitetura da solução é mostrada na figura anterior — Figura 3. A solução usa uma CA raiz offline que pode ser operada on-premises ou em uma Amazon VPC, enquanto as CAs subordinadas do Windows são executadas em instâncias EC2, e são integradas ao CloudHSM para gerenciamento e armazenamento das chaves. Para isolar a PKI do acesso externo, o cluster do CloudHSM é implantado em subnets protegidas (sem conectividade), as instâncias EC2 são implantadas em subnets privadas e a VPC host tem conectividade de rede site-to-site com a rede on-premises. Os volumes EBS das instâncias EC2 são criptografados com chaves gerenciadas pelo cliente (customer managed keys) do AWS KMS. Usuários e dispositivos se conectam e se registram na interface PKI por meio de um Network Load Balancer.

Essa solução também inclui uma CA privada subordinada do AWS Private CA, para emitir certificados que serão instalados nos serviços da AWS integrados ao ACM. Por exemplo, ELB, CloudFront e API Gateway. Isso é para que os certificados que os usuários veem sejam sempre apresentados a partir da PKI interna da sua organização.

Pré-requisitos para implantar a solução de PKI interna híbrida na AWS

  • É necessária experiência com a nuvem AWS, o Windows Server e o AD CS para implantar e configurar essa solução.
  • Uma conta da AWS para implantar os recursos da nuvem.
  • Uma CA raiz offline, em execução no Windows Server 2016 ou posterior, para assinar o CloudHSM e as CAs emissoras, incluindo a CA privada e as CAs do Windows. Para ajudá-lo no processo de criação aqui está um artigo do AWS QuickStart para implantar sua CA raiz em uma VPC. Recomendamos instalar o Windows Root CA em sua própria conta da AWS.
  • Uma VPC com pelo menos quatro subnets. Duas ou mais subnets públicas e duas ou mais subnets privadas, em duas ou mais AZs, com regras de firewall seguras, como HTTPS, para se comunicar com seus servidores web PKI por meio de um balanceador de carga, junto com DNS, RDP e outra porta para se comunicar na rede da sua organização. Você pode usar esse exemplo de modelo de VPC do CloudFormation para ajudá-lo a começar com o provisionamento de sua PKI VPC.
  • Conexão site-to-site do AWS Direct Connect ou VPN de sua VPC com a rede on-premises e outras VPCs para gerenciar várias redes com segurança.
  • Instâncias EC2 do Windows Server 2016 para as CAs subordinadas.
  • Um ambiente do Active Directory que tem acesso à VPC que hospeda os servidores PKI. Isso é necessário para uma implementação do Windows Enterprise CA.

Implemente a solução

O código e as instruções do CloudFormation abaixo ajudarão você a implantar e configurar todos os componentes da AWS mostrados no diagrama de arquitetura acima. Para implementar a solução, você fara o deployment uma série de Templates do CloudFormation por meio do AWS Management Console.

Se você não estiver familiarizado com o CloudFormation, aprenda mais sobre ele em Introdução ao AWS CloudFormation. Os Templates dessa solução podem ser implantados com o console do CloudFormation, o AWS Service Catalog ou um pipeline de código.

Baixe e revise o pacote de modelos do CloudFormation e PowerShell

Para facilitar a implantação dos componentes dessa solução interna de PKI, você precisa baixar e implantar um pacote de modelos. O pacote inclui um conjunto de modelos do CloudFormation e um script do PowerShell para concluir a integração entre o CloudHSM e os servidores Windows CA.

Para baixar o pacote de modelos
  1. Baixe ou clone o repositório de código-fonte da solução no GitHub da AWS.
  2. Revise as descrições em cada modelo para obter mais instruções.

Implante os templates de CloudFormation

Agora que você baixou os Templates, use o console do CouldFormation para implantá-los.

Para implantar o Template de modificação da VPC

Implemente esse modelo em uma VPC existente para criar as subnets protegidas para implantar um cluster do CloudHSM.

  1. Navegue até o console do CloudFormation.
  2. Selecione a região da AWS apropriada e, em seguida, escolha Create Stack.
  3. Escolha Carregar um arquivo de template.
  4. Selecione 01_PKI_Automated-VPC_Modifications.yaml como o arquivo da stack do CloudFormation e escolha Avançar.
  5. Na página Especificar detalhes da Stack, insira o nome da stack e os parâmetros. Alguns parâmetros têm uma lista suspensa que você pode usar para selecionar valores existentes.
Figure 4: Example of a <strong>Specify stack details</strong> page Figura 4: Exemplo de uma página de detalhes da Stack Specify

6. Escolha Avançar, Avançar e Criar Stack.

Para implantar o modelo de S3 bucket PKI CRL Distribution point (CDP)

Esse modelo cria um bucket S3 para o ponto de distribuição Certificate Revocation List (CRL) e Authority Information Access (AIA), com políticas de bucket iniciais que permitem acesso a partir da PKI VPC a usuários e dispositivos de PKI de sua rede on-premises, com base nas informações que você forneceu. Para conceder acesso às contas adicionais da AWS, VPCs e redes on-premises, consulte as instruções no template.

  1. Navegue até o console do CloudFormation.
  2. Escolha Carregar um arquivo de Template.
  3. Selecione 02_PKI_Automated-Central-PKI_CDP-S3Bucket.yaml como o arquivo de Stack do CloudFormation e escolha Avançar.
  4. Na página Especificar detalhes da Stack, insira o nome da stack e os parâmetros.
  5. Escolha Avançar, Avançar e Criar Stack
Para implantar o modelo subordinado do AWS Private CA

Essa etapa provisiona a CA privada da AWS, que é assinada por uma CA raiz existente do Windows. O provisionamento de sua CA privada com o CloudFormation torna possível assinar a CA com uma CA raiz do Windows.

  1. Navegue até o console do CloudFormation.
  2. Escolha Carregar um arquivo de modelo.
  3. Selecione 03_PKI_Automated-ACMPrivateca-Provisioning.yaml como o arquivo de Stack do CloudFormation e escolha Avançar.
  4. Na página Especificar detalhes da Stack, insira o nome da pilha e os parâmetros. Alguns parâmetros têm uma lista suspensa que você pode usar para selecionar valores existentes.
  5. Escolha Avançar, Avançar e Criar Stack.

Atribuir e configurar certificados

Depois de implantar os modelos anteriores, use o console para atribuir permissões de renovação de certificados ao AWS Private CA e configurar seus certificados.

Para atribuir permissões de renovação
  1. No console da CA privada do AWS Private CA, escolha CAs privadas.
  2. Selecione sua CA privada na lista.
  3. Escolha a guia Permissões.
  4. Selecione Autorizar ACM para usar essa CA para renovações.
  5. Escolha Salvar.
Para assinar certificados de CA privados com uma CA externa (console)
  1. No console do AWS Private CA, selecione sua CA privada na lista.
  2. No menu Ações, escolha Importar certificado CA. O console ACM Private CA retorna a solicitação de assinatura de certificado (CSR).
  3. Escolha Exportar CSR para um arquivo e salve-o localmente.
  4. Escolha Avançar.

a. Use sua CA raiz existente do Windows.

b. Copie a CSR para a CA raiz e assine-a.

c. Exporte o CSR assinado no formato base64.

d. Exporte o <RootCA>certificado .crt no formato base64.

  1. Na página Carregar os certificados, faça o upload dos certificados CSR e RootCA assinados.
  2. Escolha Confirmar e importar para importar o certificado de CA privado.
Para solicitar um certificado privado usando o console do AWS Private CA

Observação: anote os IDs do certificado que você configura nesta seção para usar ao implantar os Templates do HTTPS Listeners no CloudFormation.

  1. Faça login no console e abra o console do ACM.
  2. Escolha Solicitar um certificado.
  3. Na página Solicitar um certificado, escolha Solicitar um certificado privado e Solicitar um certificado para continuar.
  4. Na página Selecionar uma autoridade de certificação (CA), escolha Selecionar uma CA para ver a lista de CAs privadas disponíveis.
  5. Escolha Avançar.
  6. Na página Adicionar nomes de domínio, insira seu nome de domínio. Você pode usar um nome de domínio totalmente qualificado, como www.exemplo.com, ou um nome de domínio simples, também chamado de apex, como exemplo.com. Você também pode usar um asterisco (*) como curinga na posição mais à esquerda para incluir todos os subdomínios no mesmo domínio raiz. Por exemplo, você pode usar *.example.com para incluir todos os subdomínios do domínio raiz example.com.
  7. Para adicionar outro nome de domínio, escolha Adicionar outro nome a este certificado e digite o nome na caixa de texto.
  8. (Opcional) Na página Adicionar tags, marque seu certificado.
  9. Ao terminar de adicionar tags, escolha Revisar e solicitar.
  10. Se a página Revisar e solicitar contiver as informações corretas sobre sua solicitação, escolha Confirmar e solicitar.

Observação: você pode saber mais em Solicitando um certificado privado.

Para compartilhar a CA privada com outras contas ou com sua organização

Você pode usar o AWS Private CA para compartilhar uma única CA privada com várias contas da AWS. Para compartilhar sua CA privada com várias contas, siga as instruções em Como usar a RAM da AWS para compartilhar sua conta cruzada do AWS Private CA.

Continue implantando os templates de CloudFormation

Com os certificados atribuídos e configurados, você pode concluir a implantação dos templates de CloudFormation para essa solução.

Para implantar o template de Network Load Balancer

Nesta etapa, você provisiona um Network Load Balancer.

  1. Navegue até o console do CloudFormation.
  2. Escolha Carregar um arquivo de template.
  3. Selecione 05_PKI_Automated-LoadBalancer-Provisioning.yaml como o arquivo de Stack do CloudFormation e escolha Avançar.
  4. Na página Especificar detalhes da Stack, insira o nome da Stack e os parâmetros. Alguns parâmetros são preenchidos automaticamente ou têm uma lista suspensa que você pode usar para selecionar valores existentes.
  5. Escolha Avançar, Avançar e Criar Stack.
Para implantar o Template de configuração do HTTPS Listener

As etapas a seguir criam o HTTPS Listener com uma configuração inicial para o balanceador de carga.

  1. Navegue até o console do CloudFormation:
  2. Escolha Carregar um arquivo de Template.
  3. Selecione 06_PKI_Automated-HTTPS-Listener.yaml como o arquivo da Stack do CloudFormation e escolha Avançar.
  4. Na página Especificar detalhes da Stack, insira o nome da Stack e os parâmetros. Alguns parâmetros são preenchidos automaticamente ou têm uma lista suspensa que você pode usar para selecionar valores existentes.
  5. Escolha Avançar, Avançar e Criar Stack.
Para implantar o modelo de CMK do AWS KMS

Nesta etapa, você cria uma CMK do AWS KMS para criptografar volumes do EC2 EBS e outros recursos. Isso é necessário para as instâncias do EC2 nesta solução.

  1. Abra o console do CloudFormation.
  2. Escolha Carregar um arquivo de Template.
  3. Selecione 04_PKI_Automated-KMS_CMK-Creation.yaml como o arquivo da Stack do CloudFormation e escolha Avançar.
  4. Na página Especificar detalhes da Stack, insira o nome da Stack e os parâmetros.
  5. Escolha Avançar, Avançar e Criar Stack.
Para implantar o Template de provisionamento de instâncias EC2 Windows

Esse modelo provisiona uma instância EC2 Windows criada especificamente em uma VPC existente. Ele provisionará uma instância do EC2 para a CA do Windows, com KMS para criptografar o volume do EBS, um IAM Instance Profile e instalará automaticamente o agente SSM em sua instância.

Ele também tem recursos e flexibilidades opcionais. Por exemplo, o template pode criar automaticamente um novo target group ou adicionar uma instância ao target group existente. Ele também pode configurar listener rules, criar registros do Route 53 e ingressar automaticamente em um domínio do Active Directory.

Observação: a CMK do AWS KMS e a IAM Roles são necessárias para provisionar o EC2, enquanto o target group, as listener rules e os recursos de ingresso no domínio são opcionais.

  1. Navegue até o console do CloudFormation.
  2. Escolha Carregar um arquivo de Template.
  3. Selecione 07_PKI_Automated-EC2-servers-provisioning.yaml como o arquivo da Stack do CloudFormation e escolha Avançar.
  4. Na página Especificar detalhes da Stack, insira o nome da Stack e os parâmetros. Alguns parâmetros são preenchidos automaticamente ou têm uma lista suspensa que você pode usar para selecionar valores existentes.

Observação: a seção de propriedades opcionais no final da lista de parâmetros não é necessária se você não estiver associando a instância do EC2 a um domínio do Active Directory.

  1. Escolha Avançar, Avançar e Criar Stack.

Crie e inicialize um cluster do CloudHSM

Nesta seção, você cria e configura o CloudHSM nas VPC subnets provisionadas nas etapas anteriores. Depois que o cluster do CloudHSM for concluído e assinado pela CA raiz do Windows, ele será integrado aos servidores EC2 Windows provisionados nas seções anteriores.

Para criar um cluster do CloudHSM
  1. Faça login na conta da AWS, abra o console e navegue até o CloudHSM.
  2. Escolha Criar cluster.
  3. Na seção Configuração do cluster:

a.Selecione a VPC que você criou.

b. Selecione as três subnets privadas que você criou nas zonas de disponibilidade nas etapas anteriores.

  1. Escolha Avançar: Revisar.
  2. Revise a configuração do seu cluster e escolha Criar cluster.
Para criar um HSM
  1. Abra o console e acesse o cluster do CloudHSM que você criou na etapa anterior.
  2. Escolha Inicializar.
  3. Selecione uma AZ para o HSM que você está criando e, em seguida, escolha Criar.
Para baixar e assinar um Certificate signing request (CSR)

Antes de inicializar o cluster, você deve baixar e assinar um CSR gerado pelo primeiro HSM do cluster.

  1. Abra o console do CloudHSM.
  2. Escolha Inicializar ao lado do cluster que você criou anteriormente.
  3. Quando o CSR estiver pronto, selecione Cluster CSR para baixá-lo.

    Figure 5: Download CSR

    Figura 5: Baixe o CSR

Para inicializar o cluster
  1. Abra o console do CloudHSM.
  2. Escolha Inicializar ao lado do cluster que você criou anteriormente.
  3. Na página de solicitação de assinatura do certificado de download, escolha Avançar. Se Avançar não estiver disponível, escolha um dos links de CSR ou certificado e, em seguida, escolha Avançar.
  4. Na página Assinar solicitação de assinatura de certificado (CSR), escolha Avançar.
  5. Use sua CA raiz existente do Windows.
    1. Copie a CSR para a CA raiz e assine-a.
    2. Exporte o CSR assinado no formato base64.
    3. Também exporte o <RootCA>certificado .crt no formato base64.
  6. Na página Carregar os certificados, faça o upload da CSR assinada e dos certificados de CA raiz.
  7. Escolha Carregar e inicializar.

Integre o cluster CloudHSM ao Windows Server AD CS

Nesta seção, você usa um script que fornece instruções passo a passo para ajudá-lo a integrar com êxito sua CA do Windows Server com o AWS CloudHSM.

Para integrar o cluster CloudHSM ao Windows Server AD CS

Abra o script 09_PKI_AWS_CloudHSM-Windows_CA-Integration-Playbook.txt e siga as instruções para concluir a integração do CloudHSM com os servidores Windows.

Instale e configure o Windows CA com o CloudHSM

Quando a integração com o CloudHSM estiver concluída, instale e configure sua CA do Windows Server com o provedor de armazenamento de chaves CloudHSM e selecione RSA #Cavium Key Storage Provider como seu provedor criptográfico.

Conclusão

Ao implantar a solução híbrida neste post, você implementou uma PKI para gerenciar a segurança em todas as cargas de trabalho em suas contas da AWS e em sua rede on-premises.

Com essa solução, você pode usar uma CA privada para emitir certificados TLS (Transport Layer Security) para seus Application Load Balancers, Network Load Balancers, CloudFront e outras cargas de trabalho da AWS em várias contas e VPCs. A CA do Windows permite que você aprimore sua segurança interna vinculando seus usuários internos, dispositivos digitais e aplicativos às chaves privadas apropriadas. Você pode usar essa solução com TLS, Internet Protocol Security (IPsec), assinaturas digitais, VPNs, autenticação de rede sem fio e muito mais.

Recursos adicionais

Se você tiver comentários sobre esta postagem, envie comentários na seção Comentários abaixo. Se você tiver dúvidas sobre esta publicação, inicie um novo tópico no fórum do AWS Certificate Manager ou no fórum do CloudHSM ou entre em contato com o AWS Support.

 

Este artigo foi traduzido do Blog da AWS em Inglês.

 


Sobre o autor

Max Farnga é consultor de transformação de segurança da AWS Professional Services — equipe de segurança, risco e conformidade. Ele tem uma formação técnica diversificada em infraestrutura, segurança e computação em nuvem. Ele ajuda os clientes da AWS a implementar soluções seguras e inovadoras na nuvem da AWS.

 

 

 

 

Revisores

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 14 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

 

 

 

 

Thiago Paiva é Senior Technical Instructor no time da AWS Americas. Na maior parte de sua carreira tem atuado com workloads Microsoft e cloud computing. Como Technical Instructor, já está há mais de 3 anos na AWS se dedicando ao programa AWS TechU que consiste em oferecer aprendizado baseado em um projeto de 6 meses com instrutor, seguido por uma atribuição de aprendizado de 6 meses nas áreas de: Treinamento Técnico, Arquitetura de Soluções ou Consultoria de Serviços Profissionais para indivíduos recém formados em  universidade relacionadas com TI.