© 2022 ECSA.WORLD
Design do site

Projetando uma solução de PKI

Nos últimos dias, vários recrutadores me abordaram sobre um contrato que desejam preencher para projetar uma solução de PKI. Embora eu já tenha feito o design de PKI antes e esteja interessado em fazer o design de PKI novamente, estou descobrindo que mais e mais recrutadores estão tentando me rebaixar pelo que faço e, considerando como valorizo meu tempo, estou começando resistir a responder a esses recrutadores. Isso, combinado com o fato de eu ter mudado para o modelo de negócios de Taxa Fixa, Arquitetura de Segurança como um Serviço, me fez achar cada vez menos atraente passar por recrutadores. Eu prefiro trabalhar com parceiros (NOTA: Entre em contato RedBud Cyber se você estiver procurando por um bom recrutador de segurança cibernética. Eles são meus parceiros e revendem minha Arquitetura de Segurança como Serviço).

Dito isso, há bastante coisa que as pessoas devem entender sobre o design de soluções de PKI e, já que estou sendo solicitado a preencher um contrato, pensei em dar algumas ideias para aqueles que estão analisando designs de PKI. E se você estiver procurando por uma PKI projetada, me avise e podemos sentar e conversar.

Quando você está projetando uma solução PKI, não é tão fácil quanto instalar os Serviços de Certificados do Windows em seu servidor Windows. Na verdade, com a PKI, uma das piores coisas que você pode fazer é apenas olhar de uma perspectiva tecnológica. Lembre-se, sua solução PKI vai manter as chaves do seu reino, então você precisa dar uma olhada muito profissional e detalhada em como você vai gerenciar seus certificados e pares de chaves públicas/privadas.

Para começar, lembre-se de que todas as soluções têm 3 componentes principais; Pessoas, Processos e Tecnologia. Aqueles de vocês que me conhecem entendem que eu realmente acredito que há um 4º componente e isso é Governança. Mas deixarei a Governança de fora deste artigo, caso contrário, este artigo se transformará em um livro.

Depois de reunir os requisitos para sua solução (e estes devem ser do nível de negócios, não do nível técnico), comece a analisar as camadas de sua arquitetura. Vou começar com a Arquitetura de Negócios porque ela conterá tanto as arquiteturas de pessoas quanto de processos.

Com a arquitetura de pessoas, você desejará criar um RACI para todas as pessoas envolvidas em sua solução PKI. Não são apenas os administradores que precisam estar envolvidos. Algumas das outras funções que você precisa pensar são:

  • Solicitante de certificado/chave – Esta é a pessoa que precisa da saída da solução PKI. Se deixados em seus próprios dispositivos, eles acabarão fazendo uso de certificados autoassinados e, quando expirarem, você acabará solucionando o motivo pelo qual as soluções falharam. Portanto, certifique-se de entender quem é seu Solicitante e como ele fará suas solicitações.
  • Aprovador – Só porque alguém quer um certificado não significa que deva obtê-lo. Isso geralmente está vinculado à governança de seus certificados e chaves. Eles podem até ser os proprietários da solução PKI.
  • Auditores – Haverá funções que precisarão auditar seu sistema para garantir a integridade da solução PKI. Talvez você não precise de um alto nível de integridade – nesse caso, talvez esse papel não seja muito importante. Mas se você estiver analisando o PCI ou estiver no setor financeiro (ou lidando com infraestrutura crítica), precisará certificar-se de que a auditoria está ocorrendo.
  • Analistas de Segurança – Enquanto os administradores cuidam e alimentam o sistema, normalmente seus Analistas de Segurança são o Usuário Final da solução PKI. Entenda como eles irão interagir com sua solução e quais processos eles usarão para atender as solicitações.

Estes são apenas alguns dos papéis que você precisa pensar. E cada função terá seus próprios processos com os quais eles precisam lidar (alguns dos quais são sugeridos apenas nas descrições que forneci).

Já que estamos falando da Arquitetura de Negócios, certifique-se de entender o modelo financeiro que a solução PKI está suportando. Quais são os volumes de certificados ou chaves que precisam ser gerenciados? Se eles tiverem um volume alto o suficiente, você pode querer substituir as funções humanas listadas acima por algum tipo de sistema automatizado como o que a Venafi fornece (não um endosso da Venafi). Ou você deseja usar um provedor de serviços terceirizado, como Entrust ou Verasign? Às vezes, você desejará ter um terceiro confiável para verificar uma parte de um par de chaves públicas/privadas. Mas há custos associados a isso, portanto, equilibre os custos de usar certificados autoassinados, terceiros confiáveis (ou seja, provedores de serviços em nuvem) ou construir você mesmo. Essas são as chaves para seus ativos primários, portanto, tome a decisão com sabedoria.

Ok, vamos passar para os componentes técnicos. As soluções PKI são construídas em torno de um conceito conhecido como “Autoridade Certificadora”. A Autoridade de Certificação (ou CA) é um ponto de gerenciamento central para os certificados e chaves de uma empresa. Sem a CA, você não seria capaz de rastrear com eficiência todos os Certificados ou Chaves implementados, não seria capaz de garantir uma relação de confiança com os pares de chaves Públicas/Privadas e não seria capaz de garantir que a criptografia dentro da empresa está sendo aplicado de acordo com seus padrões de segurança.

Normalmente, há 4 componentes em uma hierarquia de CA; a AC Raiz, a AC Subordinada Intermediária, a AC Subordinada Emissora e o certificado. Eles são mostrados no diagrama a seguir (retirado do TechNet da Microsoft):

Os certificados digitais criados por uma Autoridade de Certificação (CA) de Infraestrutura de Chave Pública (PKI) são verificados usando uma cadeia de confiança. A âncora de confiança para o certificado digital é a Autoridade de Certificação Raiz (CA), e qualquer Autoridade de Certificação (CA) que esteja sob a Autoridade de Certificação Raiz (CA Raiz) é conhecida como Autoridade de Certificação (CA) subordinada. A figura a seguir mostra a hierarquia da autoridade de certificação.

CA raiz:Uma CA Raiz é a Autoridade de Certificação (CA) mais alta em uma hierarquia de Autoridade de Certificação (CA). Cada hierarquia de Autoridade de Certificação (CA) começa com a CA Raiz e várias CAs se ramificam dessa CA Raiz em um relacionamento pai-filho. Todas as CAs filhas devem ser certificadas pela CA pai correspondente de volta à CA Raiz. A CA raiz é mantida em uma área segura e geralmente é uma CA offline autônoma (para torná-la a Autoridade de Certificação (CA) mais segura). A CA raiz fornece certificados para CAs intermediárias. Os certificados podem ser revogados se forem comprometidos. Eu recomendaria que você mantenha a CA raiz offline, se possível.

CAs intermediárias: Uma Autoridade de Certificação (CA) intermediária é uma CA subordinada a outra CA (CA raiz ou outra CA intermediária) e emite certificados para outras CAs na hierarquia de CA. As CAs intermediárias geralmente são CAs offline autônomas, como CAs raiz.

Emissão de CAs: As CAs emissoras são usadas para fornecer certificados a usuários, computadores e outros serviços. Pode haver várias CAs emissoras, e uma CA emissora pode ser usada para gerar certificados de computador e outra pode ser usada para gerar certificados de usuário.

Há também três outros componentes-chave a serem observados em uma solução PKI (algumas pessoas podem dizer mais, mas estou sendo simplista para os propósitos deste artigo. Esses são seu Active Directory (para as funções que estão interagindo com a solução PKI bem como onde você pode armazenar seus certificados/chaves), seus firewalls (para proteger as CAs) e seu HSM (armazenamento de chaves) BTW, configure seu HSM para ter uma partição para cada SubCA.

Uma recomendação que eu sugiro é que você tenha uma SubCA (emissão) para cada domínio. Isso permite que você estabeleça relacionamentos de confiança usando a troca de chaves se estiver envolvido em níveis mais altos de segurança.

Se você estiver configurando um servidor de certificados baseado em Windows, poderá usar modelos de certificado. Esses são modelos que permitem duplicar a configuração de certificados e chaves sempre que você precisar de um novo conjunto de certificados. Há uma lista padrão disponível por meio do Windows Server que você pode aproveitar, se desejar.

Quando chegar a hora de analisar os algoritmos aprovados, recomendo que você aproveite o trabalho que o NIST está fazendo. Dessa forma, você não precisa ficar por dentro dos diferentes algoritmos – deixe o NIST fazer isso por você. Você pode verificar os algoritmos aprovados em esta página do NIST.

Há um último conjunto de detalhes que você precisa determinar como parte do seu design (há MUITO o que lidar, então não deixe este artigo enganá-lo pensando que isso é tudo o que você precisa lidar). As coisas que você quer considerar são:

  • Comprimento da chave - normalmente, isso será definido como 2048, mas quanto maior, melhor (por exemplo, 4096 bits)
  • Período de validade – por quanto tempo os certificados ou chaves serão válidos. Isso depende do tipo de CA que está fazendo a emissão. Você gostaria que os certificados da CA raiz fossem muito mais longos do que as CAs emissoras (normalmente o dobro do tempo) e dependentes de quanto tempo o equipamento que está usando os certificados/chaves estará no local. As concessionárias, por exemplo, colocarão medidores inteligentes com vida útil de +30 anos para que as chaves/certificados sejam pelo menos tão longas.
  • Ponto de Distribuição de CRL – você precisa ser capaz de apontar para onde a Lista de Revogação de Certificados (CRL) está armazenada. Normalmente é o seu Active Directory, mas pode ser qualquer local acessível pelos dispositivos que recebem os certificados/chaves.
  • Estratégia de Backup e DR – Suas Autoridades de Certificação são extremamente importantes para sua organização, portanto, você precisa ser muito claro sobre como fará backup dos próprios servidores de CA e qual é a estratégia de DR para eles.

Como eu disse anteriormente, este é um artigo muito simplista sobre um assunto complexo. Certifique-se de ter considerado todas as áreas associadas ao seu certificado e gerenciamento de chaves. E se você precisar de alguma ajuda, certifique-se de perguntar a alguém que já fez isso antes.

Espero que isto ajude …

Neil