Quando um amigo do MBA me pediu para falar sobre ADCS, lembro-me de ter lhe respondido que esse seria tema para um livro. É realmente muita coisa e deveras difícil explorar todos os aspectos em artigos mensais.
Mas juro que ao menos tentarei. Entretanto, para ficar mais fácil para quem escreve (nesse caso, eu) e para quem ler, dividirei o conteúdo em algumas partes.
Uma infra-estrutura de chave pública (PKI) é composta por diversos componentes que juntos acrescentam uma camada de proteção às comunicações e transações diversas. Essa proteção ocorre através da distribuição, validação e gerenciamento de certificados digitais.
Em ambientes Microsoft, essa infra-estrutura é criada através da instalação e configuração do ADCS (Active Directory Certificate Services), que pode ser instalado e configurado como uma autoridade de certificação raiz ou uma autoridade de certificação subordinada em sua organização.
Em uma infra-estrutura de PKI, a primeira autoridade de certificação será uma autoridade de certificação raiz (Root CA) e a partir daí, pode-se configurar autoridade subordinadas para aplicar restrições de diretiva e emitir certificados.
O ADCS é figurinha carimbada no mundo Microsoft, e foi disponibilizado pela primeira vez no Windows 2000 (se não me engano). Esse serviço permite implementar a PKI de modo relativamente fácil, mas não é tão intuitivo assim. É importante entendermos bem os conceitos envolvidos para sermos bem sucedidos em nossas implementações.
Para iniciar, vamos tentar definir uma PKI. De forma simplista, podemos definir uma PKI como a combinação de software, tecnologias de criptografia, processos e serviços que permitem a proteção de comunicações e transações diversas e depende da troca de certificados digitais entre usuários autenticados e recursos confiáveis.
Visa atender aos seguintes requisitos de segurança:
Confidencialidade – Esse requisito é atendido pelo uso de criptografia de dados armazenados e transmitidos. Por exemplo, pode-se utilizar o EFS (sistema de arquivos com criptografia ativada para PKI) para criptografar e proteger dados, bem como manter a confidencialidade de dados transmitidos em redes públicas utilizando IPsec (Internet Protocol security) habilitado para PKI.
Integridade – Em dados assinados digitalmente ocorre a identificação de alteração de durante a transmissão. Para facilitar o entendimento, podemos tomar por exemplo uma mensagem de e-mail que tenha sido assinada digitalmente. Nesse caso há garantia de que o conteúdo da mensagem não foi modificado durante a trânsito entre remetente e destinatário.
Autenticidade – Esse requisito é atendido ao considerar que os dados de autenticação são submetidos a algoritmos hash, como por exemplo o Secure Hash Algorithm 2 (SHA-2), para produzir um resumo de mensagens assinadas digitalmente usando a chave privada do remetente do certificado, que prova que o remetente realmente produziu o resumo da mensagem.
Não-repúdio - Quando os dados são assinados digitalmente com o certificado de um autor, a assinatura digital fornece provas da integridade dos dados assinados, bem como prova a origem dos dados.
Disponibilidade – Pode ser atingida através da instalação de várias CAs em sua infra-estrutura de PKI para emissão de certificados. Em caso de falha de uma autoridade de certificação, as outras podem prosseguir coma emissão de certificados.
Através do Active Directory Certificate Services (AD CS) é possível implantar todos os componentes necessários em uma PKI. Embora trabalhem em conjunto, cada componente é responsável por uma parte específica da infraestrutura.
Entre esse componentes temos:
Autoridade de Certificação (Certification Authority) – Responsável pela emissão e revogação de certificados, bem como publicar informações de acesso a informações de autoridade (AIA). Pode-se ter uma ou mais CAs em uma rede, mas somente uma autoridade de certificação ocupará o ponto mais alto da hierarquia da autoridade de certificação, denominada “CA Raiz”. Também é possível possuir mais de uma hierarquia de CA, e consequentemente mais de uma CA raiz.
Depois que uma autoridade de certificação raiz emite um certificado para si mesmo, as autoridades de certificação subordinadas que são inferiores na hierarquia recebem certificados da autoridade de certificação raiz.
Inscrição na Web da Autoridade de Certificação (Certification Authority Web Enrollment) - Esse componente fornece um método para emitir e renovar certificados para usuários, computadores e dispositivos que não estão associados ao domínio, não estejam conectados diretamente à rede ou para usuários de sistemas operacionais que não sejamWindows.
Respondente Online (Online Responder) - Esse componente pode ser utilizado para configurar e gerenciar a validação e revisão de revogação do OCSP (Online Certificate Status Protocol). Um Respondente Online decodifica solicitações de status de revogação para certificados específicos, avalia o status desses certificados e retorna uma resposta assinada que contém as informações de status do certificado solicitadas.
Os dados de revogação de certificado podem vir de uma autoridade de certificação em um computador que esteja executando o Windows Server 2003 ou posterior.
Serviço de Registro de Dispositivo de Rede (Network Device Enrollment Service) - Através desse componente, roteadores, comutadores e outros dispositivos de rede podem obter certificados emitidos pelo AD CS.
Serviço Web de Registro de Certificado (Certificate Enrollment Web Service) – Disponibilizado no Windows 2008 R2, esse componente funciona como um cliente proxy entre um computador executando o Windows 7 ou posterior e a autoridade de certificação e exige que a floresta do Active Directory esteja, pelo menos, no nível funcional do Windows Server 2008 R2.
Ele permite que usuários, computadores ou aplicativos se conectem a uma CA usando os serviços da Web para solicitar, renovar e instalar certificados emitidos, bem como recuperar listas de revogação de certificado (CRLs).
Serviço Web da Política de Inscrição de Certificados (Certificate Enrollment Policy Web Service) - Este componente permite que os usuários obtenham informações de política de inscrição de certificado. Combinado com o CES, permite o registro de certificado com base em políticas quando o computador cliente não é membro de um domínio ou quando um membro do domínio não está conectado ao domínio.
Importante salientar que todos os serviços mencionados podem ser instalados na versão completa do Windows Server (Desktop Experience) ou no Server Core. Entretanto, o AD CS não pode ser executado no Nano Server.
Para implementação do AD CS, é fundamental projetar sua hierarquia de CA, determinando o design principal da PKI interna e determinar o objetivo de cada CA na hierarquia, considerando que cada hierarquia de CA geralmente inclui duas ou mais CAs.
Geralmente, a segunda autoridade de certificação e todas as outras depois disso são implantadas com um propósito específico. Apenas a CA raiz é obrigatória.
Não é obrigatório possuir uma hierarquia de CA de vários níveis para utilizar PKI e certificados. Em ambientes menores e menos complexos, você pode ter uma hierarquia de CA com apenas uma CA implantada. Essa CA geralmente é implantada como uma autoridade de certificação raiz corporativa (Enterprise Root CA).
Via de regra não é recomendado a criação de uma hierarquia de CA com mais que três níveis, a menos que esteja em um ambiente extremamente complexo e distribuído.
O mais comum são hierarquias de dois níveis, com a autoridade de certificação raiz no nível superior e a autoridade de certificação subordinada no segundo nível. Simples assim!!!
Um ponto recomendado e de certa forma polêmico refere-se à recomendação de se manter a autoridade de certificação raiz offline (desligada) enquanto a autoridade de certificação subordinada emite e gerencia certificados para todos os clientes.
Ocorre que pessoalmente, em mais de 20 anos de carreira, nunca encontrei (ou ao menos não me recordo) um ambiente onde essa recomendação fosse seguida.
Normalmente, ela é mantida ligada para que receba patches de segurança e atualizações de anti-vírus, por exemplo.
Em geral, as hierarquias da CA se enquadram em uma das seguintes categorias:
Hierarquias da CA com uma CA de política - CAs de política são autoridades de certificação subordinadas que estão diretamente abaixo da autoridade de certificação raiz. Você usa CAs de diretiva para emitir certificados à autoridades de certificação subordinadas que estão diretamente abaixo da autoridade de certificação da diretiva na hierarquia. A função de uma CA de política é descrever as políticas e procedimentos que uma organização implementa para proteger sua PKI, os processos que validam a identidade dos titulares de certificados e os processos que impõe os procedimentos que gerenciam certificados. Uma autoridade de certificação de política só emite certificados para outras autoridades de certificação, que recebem esses certificados e devem manter e impor as políticas definidas pela CA. O uso de CAs de política não é obrigatório, a menos que diferentes divisões, setores ou locais de sua organização exijam políticas e procedimentos de emissão diferentes. No entanto, se sua empresa exigir diretivas e procedimentos de emissão distintos, você deverá adicionar autoridades de certificação de diretivas à hierarquia para definir cada diretiva exclusiva. Por exemplo, uma organização pode implementar uma CA de política para todos os certificados que ela emite internamente para funcionários e outra para todos os certificados emitidos para terceiros.
Hierarquias de CA com confiança de certificação cruzada - Nesse cenário, duas hierarquias de autoridade de certificação independentes interoperam quando uma autoridade de certificação de uma hierarquia emite um certificado de autoridade de certificação cruzada para uma autoridade de certificação de outra hierarquia. Isso estabelece confiança mútua entre diferentes hierarquias de autoridade de certificação.
CAs com uma hierarquia de dois níveis - Em uma hierarquia de duas camadas, há uma CA raiz e pelo menos uma autoridade de certificação subordinada. Nesse cenário, a autoridade de certificação subordinada é responsável pelas diretivas e pela emissão de certificados para os solicitantes.
Basicamente pode-se implantar dois tipos de CAs: CAs autônomas e CAs corporativas.
Isso não se refere à hierarquia, e sim sobre armazenamento de funcionalidades e configuração.
O que difere ambas é a integração e a dependência do Active Directory.
Uma autoridade de certificação autônoma pode funcionar sem o Active Directory e não depende dele de nenhuma maneira.
Uma CA corporativa exige o Active Directory e fornece vários benefícios, incluindo o registro automático.
O recurso de registro automático permite que usuários e dispositivos membros do domínio se inscrevam automaticamente em certificados, se você tiver habilitado a inscrição automática de certificados por meio da Diretiva de Grupo.
A tabela a seguir detalha as diferenças mais significativas entre autoridades de certificação independentes e corporativas.
OBS: Geralmente implanta-se a CA Root, que é a primeira autoridade de certificação implantada, como uma autoridade de certificação autônoma, que em tese é colocada offline após emitir um certificado para si mesma e para uma autoridade de certificação subordinada.
Conforme mencionado acima, antes de implantar uma autoridade de certificação raiz, é necessário criterioso planejamento para decidir se implantará uma CA raiz off-line, se implantará uma autoridade de certificação raiz autônoma ou uma autoridade de certificação raiz corporativa.
Normalmente, se optar pela implantação de uma hierarquia de CA de camada única, é mais comum escolher uma autoridade de certificação raiz corporativa.
Se optar por implantar uma hierarquia de duas camadas com uma autoridade de certificação subordinada, o cenário mais comum é implantar uma autoridade de certificação raiz autônoma por prover maior segurança à CA raiz.
Um outro ponto importante é que não é possível alterar nomes de computador, nome de domínio ou associações a domínios de computador após implantar uma autoridade de certificação de qualquer tipo nesse computador. Portanto, é importante determinar esses atributos antes de instalar uma CA.
Se você decidir implantar uma autoridade de certificação raiz autônoma off-line, tenha em mente algumas considerações específicas:
- Antes de emitir um certificado subordinado da autoridade de certificação raiz, forneça pelo menos um ponto de distribuição de lista de revogação de certificado (CDP) e localização AIA que estará disponível à todos os clientes. Isso é necessário pois, por padrão, uma CA raiz autônoma tem o CDP e o AIA armazenados em si. Portanto, quando você tira a CA raiz da rede, uma verificação de revogação falhará porque os locais CDP e AIA estarão indisponíveis. Ao definir esses locais, você deve copiar manualmente as informações de CRL e AIA para esse local.
- Não defina um período de validade longo demais para CRLs que a autoridade de certificação raiz publica. Talvez um período máximo de um ano seja razoável. Assim, caso opte por manter a Root CA desligada, será necessário liga-la uma vez por ano para publicar uma nova CRL e, em seguida, copiá-la para um local que esteja disponível para os clientes. Se isso não for feito, quando a CRL na CA raiz expirar, as verificações de revogação de todos os certificados falharão.
- Utilize Diretivas de Grupo (GPO) para publicar o certificado da CA raiz em um armazenamento de CA raiz confiável em todos os servidores e computadores clientes. Você deve fazer isso manualmente caso utilize CA autônoma, ao contrário de uma autoridade de certificação corporativa. Outra possibilidade é publicar o certificado de CA raiz no AD DS utilizando o comando certutil.
Quando utiliza-se uma autoridade de certificação subordinada para emissão de certificados para usuários ou computadores que possuem uma conta no Active Directory, pode-se instalar a autoridade de certificação subordinada como uma autoridade de certificação corporativa (Enterprise CA).
Em seguida, você pode utilizar os dados das contas de cliente no AD DS para emitir, gerenciar e publicar certificados no AD.
Para isso é necessário ser membro do grupo Administradores local ou possuir permissões equivalentes e se a CA subordinada for corporativa é necessário ser membro do grupo Domain Admins ou ter permissões equivalentes.
Com a implantação de uma CA subordinada, as seguintes possibilidades se abrem:
Separação de políticas - Você pode emitir certificados para vários fins, como S/MIME (Secure / Multipurpose Internet Mail Extensions), EFS ou acesso remoto por exemplo e possuir políticas de emissão diferentes facilitando a administração.
Divisões organizacionais - Você pode ter políticas diferentes para emitir certificados que dependem da função de uma entidade na organização. Você pode criar autoridades de certificação subordinadas para separar e administrar essas políticas.
Segmentação geográfica – No caso da companhia possuir diversos escritórios (sites) e conectividade de rede limitada entre esses sites, pode-se utilizar CAs subordinadas individuais para essas localidades.
Balanceamento de carga - Se você usar sua PKI para emitir e gerenciar um grande número de certificados e tiver apenas uma autoridade de certificação, isso poderá resultar em uma carga de rede considerável para essa única autoridade de certificação. O uso de várias CAs subordinadas para emitir o mesmo tipo de certificado permite a divisão de carga de rede entre as CAs.
Tolerância a falhas – Possuir várias CAs diminui a possibilidade de indisponibilidade do serviço.
A instalação de uma estrutura de PKI exige ou pode exigir, de acordo com cada ambiente e necessidade, a configuração de parâmetros que não estão disponíveis através da instalação padrão.
Para esses casos, utiliza-se u arquivo CAPolicy.inf para implantar uma autoridade de certificação raiz ou subordinada e definir valores e parâmetros durante ou após a instalação.
Não é mandatório utilizar o arquivo CAPolicy.inf para instalar o AD CS, mas sem ele, as configurações padrões serão aplicadas e na maioria das vezes não suprirá as necessidades em ambientes mais complexos.
Tal arquivo é dividido em seções e possui uma estrutura bastante simples, descrita da seguinte maneira:
Sessão => É uma área no arquivo .inf que contém um grupo lógico de chaves. Uma sessão sempre aparecerá entre colchetes [] no arquivo.
Chave => É o parâmetro que está à esquerda do sinal de igual (=).
Valor => É o parâmetro que está à direita do sinal de igual (=).
Abaixo, exemplo simples do arquivo CAPolicy.inf.
Você também pode usar o arquivo CAPolicy.inf ao instalar o AD CS para definir o seguinte:
Instrução de prática de certificação - Isso descreve as práticas que a CA usa para emitir certificados. Isso inclui os tipos de certificados emitidos, informações sobre emissão, renovação e recuperação de certificados e outros detalhes sobre a configuração da autoridade de certificação.
Identificador de objeto - Isso identifica um objeto ou atributo específico.
Intervalos de publicação de CRL - Isso define o intervalo entre as publicações para a CRL de base.
Configurações de renovação da autoridade de certificação - Você pode definir as configurações de renovação da seguinte forma:
- Tamanho da chave => Isso define o comprimento do par de chaves usado durante uma renovação da autoridade de certificação raiz.
- Período de validade do certificado => Isso define o período de validade de um certificado de CA raiz.
- Caminhos CDP e AIA => Isso fornece o caminho para instalações e renovações de CA raiz.
Depois de criar o arquivo CAPolicy.inf, copie-o para a pasta %SystemRoot% do seu servidor (por exemplo, C:\Windows) antes de instalar a função do AD CS ou antes de renovar o certificado da autoridade de certificação.
Nota: O arquivo CAPolicy.inf é processado para instalações e renovações de CA raiz e subordinada.
No próximo artigo, tratarei um pouco sobre administração do AD CS.
Um abraço e até mais!!!
Mas juro que ao menos tentarei. Entretanto, para ficar mais fácil para quem escreve (nesse caso, eu) e para quem ler, dividirei o conteúdo em algumas partes.
Uma infra-estrutura de chave pública (PKI) é composta por diversos componentes que juntos acrescentam uma camada de proteção às comunicações e transações diversas. Essa proteção ocorre através da distribuição, validação e gerenciamento de certificados digitais.
Em ambientes Microsoft, essa infra-estrutura é criada através da instalação e configuração do ADCS (Active Directory Certificate Services), que pode ser instalado e configurado como uma autoridade de certificação raiz ou uma autoridade de certificação subordinada em sua organização.
Em uma infra-estrutura de PKI, a primeira autoridade de certificação será uma autoridade de certificação raiz (Root CA) e a partir daí, pode-se configurar autoridade subordinadas para aplicar restrições de diretiva e emitir certificados.
O que é o AD CS?
O ADCS é figurinha carimbada no mundo Microsoft, e foi disponibilizado pela primeira vez no Windows 2000 (se não me engano). Esse serviço permite implementar a PKI de modo relativamente fácil, mas não é tão intuitivo assim. É importante entendermos bem os conceitos envolvidos para sermos bem sucedidos em nossas implementações.
Para iniciar, vamos tentar definir uma PKI. De forma simplista, podemos definir uma PKI como a combinação de software, tecnologias de criptografia, processos e serviços que permitem a proteção de comunicações e transações diversas e depende da troca de certificados digitais entre usuários autenticados e recursos confiáveis.
Visa atender aos seguintes requisitos de segurança:
Confidencialidade – Esse requisito é atendido pelo uso de criptografia de dados armazenados e transmitidos. Por exemplo, pode-se utilizar o EFS (sistema de arquivos com criptografia ativada para PKI) para criptografar e proteger dados, bem como manter a confidencialidade de dados transmitidos em redes públicas utilizando IPsec (Internet Protocol security) habilitado para PKI.
Integridade – Em dados assinados digitalmente ocorre a identificação de alteração de durante a transmissão. Para facilitar o entendimento, podemos tomar por exemplo uma mensagem de e-mail que tenha sido assinada digitalmente. Nesse caso há garantia de que o conteúdo da mensagem não foi modificado durante a trânsito entre remetente e destinatário.
Autenticidade – Esse requisito é atendido ao considerar que os dados de autenticação são submetidos a algoritmos hash, como por exemplo o Secure Hash Algorithm 2 (SHA-2), para produzir um resumo de mensagens assinadas digitalmente usando a chave privada do remetente do certificado, que prova que o remetente realmente produziu o resumo da mensagem.
Não-repúdio - Quando os dados são assinados digitalmente com o certificado de um autor, a assinatura digital fornece provas da integridade dos dados assinados, bem como prova a origem dos dados.
Disponibilidade – Pode ser atingida através da instalação de várias CAs em sua infra-estrutura de PKI para emissão de certificados. Em caso de falha de uma autoridade de certificação, as outras podem prosseguir coma emissão de certificados.
Através do Active Directory Certificate Services (AD CS) é possível implantar todos os componentes necessários em uma PKI. Embora trabalhem em conjunto, cada componente é responsável por uma parte específica da infraestrutura.
Entre esse componentes temos:
Autoridade de Certificação (Certification Authority) – Responsável pela emissão e revogação de certificados, bem como publicar informações de acesso a informações de autoridade (AIA). Pode-se ter uma ou mais CAs em uma rede, mas somente uma autoridade de certificação ocupará o ponto mais alto da hierarquia da autoridade de certificação, denominada “CA Raiz”. Também é possível possuir mais de uma hierarquia de CA, e consequentemente mais de uma CA raiz.
Depois que uma autoridade de certificação raiz emite um certificado para si mesmo, as autoridades de certificação subordinadas que são inferiores na hierarquia recebem certificados da autoridade de certificação raiz.
Inscrição na Web da Autoridade de Certificação (Certification Authority Web Enrollment) - Esse componente fornece um método para emitir e renovar certificados para usuários, computadores e dispositivos que não estão associados ao domínio, não estejam conectados diretamente à rede ou para usuários de sistemas operacionais que não sejamWindows.
Respondente Online (Online Responder) - Esse componente pode ser utilizado para configurar e gerenciar a validação e revisão de revogação do OCSP (Online Certificate Status Protocol). Um Respondente Online decodifica solicitações de status de revogação para certificados específicos, avalia o status desses certificados e retorna uma resposta assinada que contém as informações de status do certificado solicitadas.
Os dados de revogação de certificado podem vir de uma autoridade de certificação em um computador que esteja executando o Windows Server 2003 ou posterior.
Serviço de Registro de Dispositivo de Rede (Network Device Enrollment Service) - Através desse componente, roteadores, comutadores e outros dispositivos de rede podem obter certificados emitidos pelo AD CS.
Serviço Web de Registro de Certificado (Certificate Enrollment Web Service) – Disponibilizado no Windows 2008 R2, esse componente funciona como um cliente proxy entre um computador executando o Windows 7 ou posterior e a autoridade de certificação e exige que a floresta do Active Directory esteja, pelo menos, no nível funcional do Windows Server 2008 R2.
Ele permite que usuários, computadores ou aplicativos se conectem a uma CA usando os serviços da Web para solicitar, renovar e instalar certificados emitidos, bem como recuperar listas de revogação de certificado (CRLs).
Serviço Web da Política de Inscrição de Certificados (Certificate Enrollment Policy Web Service) - Este componente permite que os usuários obtenham informações de política de inscrição de certificado. Combinado com o CES, permite o registro de certificado com base em políticas quando o computador cliente não é membro de um domínio ou quando um membro do domínio não está conectado ao domínio.
Importante salientar que todos os serviços mencionados podem ser instalados na versão completa do Windows Server (Desktop Experience) ou no Server Core. Entretanto, o AD CS não pode ser executado no Nano Server.
Opções para implementar hierarquias de CA
Para implementação do AD CS, é fundamental projetar sua hierarquia de CA, determinando o design principal da PKI interna e determinar o objetivo de cada CA na hierarquia, considerando que cada hierarquia de CA geralmente inclui duas ou mais CAs.
Geralmente, a segunda autoridade de certificação e todas as outras depois disso são implantadas com um propósito específico. Apenas a CA raiz é obrigatória.
Não é obrigatório possuir uma hierarquia de CA de vários níveis para utilizar PKI e certificados. Em ambientes menores e menos complexos, você pode ter uma hierarquia de CA com apenas uma CA implantada. Essa CA geralmente é implantada como uma autoridade de certificação raiz corporativa (Enterprise Root CA).
Via de regra não é recomendado a criação de uma hierarquia de CA com mais que três níveis, a menos que esteja em um ambiente extremamente complexo e distribuído.
O mais comum são hierarquias de dois níveis, com a autoridade de certificação raiz no nível superior e a autoridade de certificação subordinada no segundo nível. Simples assim!!!
Um ponto recomendado e de certa forma polêmico refere-se à recomendação de se manter a autoridade de certificação raiz offline (desligada) enquanto a autoridade de certificação subordinada emite e gerencia certificados para todos os clientes.
Ocorre que pessoalmente, em mais de 20 anos de carreira, nunca encontrei (ou ao menos não me recordo) um ambiente onde essa recomendação fosse seguida.
Normalmente, ela é mantida ligada para que receba patches de segurança e atualizações de anti-vírus, por exemplo.
Em geral, as hierarquias da CA se enquadram em uma das seguintes categorias:
Hierarquias da CA com uma CA de política - CAs de política são autoridades de certificação subordinadas que estão diretamente abaixo da autoridade de certificação raiz. Você usa CAs de diretiva para emitir certificados à autoridades de certificação subordinadas que estão diretamente abaixo da autoridade de certificação da diretiva na hierarquia. A função de uma CA de política é descrever as políticas e procedimentos que uma organização implementa para proteger sua PKI, os processos que validam a identidade dos titulares de certificados e os processos que impõe os procedimentos que gerenciam certificados. Uma autoridade de certificação de política só emite certificados para outras autoridades de certificação, que recebem esses certificados e devem manter e impor as políticas definidas pela CA. O uso de CAs de política não é obrigatório, a menos que diferentes divisões, setores ou locais de sua organização exijam políticas e procedimentos de emissão diferentes. No entanto, se sua empresa exigir diretivas e procedimentos de emissão distintos, você deverá adicionar autoridades de certificação de diretivas à hierarquia para definir cada diretiva exclusiva. Por exemplo, uma organização pode implementar uma CA de política para todos os certificados que ela emite internamente para funcionários e outra para todos os certificados emitidos para terceiros.
Hierarquias de CA com confiança de certificação cruzada - Nesse cenário, duas hierarquias de autoridade de certificação independentes interoperam quando uma autoridade de certificação de uma hierarquia emite um certificado de autoridade de certificação cruzada para uma autoridade de certificação de outra hierarquia. Isso estabelece confiança mútua entre diferentes hierarquias de autoridade de certificação.
CAs com uma hierarquia de dois níveis - Em uma hierarquia de duas camadas, há uma CA raiz e pelo menos uma autoridade de certificação subordinada. Nesse cenário, a autoridade de certificação subordinada é responsável pelas diretivas e pela emissão de certificados para os solicitantes.
CAs Autonomas X CAs Corporativas
Basicamente pode-se implantar dois tipos de CAs: CAs autônomas e CAs corporativas.
Isso não se refere à hierarquia, e sim sobre armazenamento de funcionalidades e configuração.
O que difere ambas é a integração e a dependência do Active Directory.
Uma autoridade de certificação autônoma pode funcionar sem o Active Directory e não depende dele de nenhuma maneira.
Uma CA corporativa exige o Active Directory e fornece vários benefícios, incluindo o registro automático.
O recurso de registro automático permite que usuários e dispositivos membros do domínio se inscrevam automaticamente em certificados, se você tiver habilitado a inscrição automática de certificados por meio da Diretiva de Grupo.
A tabela a seguir detalha as diferenças mais significativas entre autoridades de certificação independentes e corporativas.
OBS: Geralmente implanta-se a CA Root, que é a primeira autoridade de certificação implantada, como uma autoridade de certificação autônoma, que em tese é colocada offline após emitir um certificado para si mesma e para uma autoridade de certificação subordinada.
Considerações para implantar uma autoridade de certificação raiz
Conforme mencionado acima, antes de implantar uma autoridade de certificação raiz, é necessário criterioso planejamento para decidir se implantará uma CA raiz off-line, se implantará uma autoridade de certificação raiz autônoma ou uma autoridade de certificação raiz corporativa.
Normalmente, se optar pela implantação de uma hierarquia de CA de camada única, é mais comum escolher uma autoridade de certificação raiz corporativa.
Se optar por implantar uma hierarquia de duas camadas com uma autoridade de certificação subordinada, o cenário mais comum é implantar uma autoridade de certificação raiz autônoma por prover maior segurança à CA raiz.
Um outro ponto importante é que não é possível alterar nomes de computador, nome de domínio ou associações a domínios de computador após implantar uma autoridade de certificação de qualquer tipo nesse computador. Portanto, é importante determinar esses atributos antes de instalar uma CA.
Se você decidir implantar uma autoridade de certificação raiz autônoma off-line, tenha em mente algumas considerações específicas:
- Antes de emitir um certificado subordinado da autoridade de certificação raiz, forneça pelo menos um ponto de distribuição de lista de revogação de certificado (CDP) e localização AIA que estará disponível à todos os clientes. Isso é necessário pois, por padrão, uma CA raiz autônoma tem o CDP e o AIA armazenados em si. Portanto, quando você tira a CA raiz da rede, uma verificação de revogação falhará porque os locais CDP e AIA estarão indisponíveis. Ao definir esses locais, você deve copiar manualmente as informações de CRL e AIA para esse local.
- Não defina um período de validade longo demais para CRLs que a autoridade de certificação raiz publica. Talvez um período máximo de um ano seja razoável. Assim, caso opte por manter a Root CA desligada, será necessário liga-la uma vez por ano para publicar uma nova CRL e, em seguida, copiá-la para um local que esteja disponível para os clientes. Se isso não for feito, quando a CRL na CA raiz expirar, as verificações de revogação de todos os certificados falharão.
- Utilize Diretivas de Grupo (GPO) para publicar o certificado da CA raiz em um armazenamento de CA raiz confiável em todos os servidores e computadores clientes. Você deve fazer isso manualmente caso utilize CA autônoma, ao contrário de uma autoridade de certificação corporativa. Outra possibilidade é publicar o certificado de CA raiz no AD DS utilizando o comando certutil.
Quando utiliza-se uma autoridade de certificação subordinada para emissão de certificados para usuários ou computadores que possuem uma conta no Active Directory, pode-se instalar a autoridade de certificação subordinada como uma autoridade de certificação corporativa (Enterprise CA).
Em seguida, você pode utilizar os dados das contas de cliente no AD DS para emitir, gerenciar e publicar certificados no AD.
Para isso é necessário ser membro do grupo Administradores local ou possuir permissões equivalentes e se a CA subordinada for corporativa é necessário ser membro do grupo Domain Admins ou ter permissões equivalentes.
Com a implantação de uma CA subordinada, as seguintes possibilidades se abrem:
Separação de políticas - Você pode emitir certificados para vários fins, como S/MIME (Secure / Multipurpose Internet Mail Extensions), EFS ou acesso remoto por exemplo e possuir políticas de emissão diferentes facilitando a administração.
Divisões organizacionais - Você pode ter políticas diferentes para emitir certificados que dependem da função de uma entidade na organização. Você pode criar autoridades de certificação subordinadas para separar e administrar essas políticas.
Segmentação geográfica – No caso da companhia possuir diversos escritórios (sites) e conectividade de rede limitada entre esses sites, pode-se utilizar CAs subordinadas individuais para essas localidades.
Balanceamento de carga - Se você usar sua PKI para emitir e gerenciar um grande número de certificados e tiver apenas uma autoridade de certificação, isso poderá resultar em uma carga de rede considerável para essa única autoridade de certificação. O uso de várias CAs subordinadas para emitir o mesmo tipo de certificado permite a divisão de carga de rede entre as CAs.
Tolerância a falhas – Possuir várias CAs diminui a possibilidade de indisponibilidade do serviço.
O arquivo CAPolicy.inf
A instalação de uma estrutura de PKI exige ou pode exigir, de acordo com cada ambiente e necessidade, a configuração de parâmetros que não estão disponíveis através da instalação padrão.
Para esses casos, utiliza-se u arquivo CAPolicy.inf para implantar uma autoridade de certificação raiz ou subordinada e definir valores e parâmetros durante ou após a instalação.
Não é mandatório utilizar o arquivo CAPolicy.inf para instalar o AD CS, mas sem ele, as configurações padrões serão aplicadas e na maioria das vezes não suprirá as necessidades em ambientes mais complexos.
Tal arquivo é dividido em seções e possui uma estrutura bastante simples, descrita da seguinte maneira:
Sessão => É uma área no arquivo .inf que contém um grupo lógico de chaves. Uma sessão sempre aparecerá entre colchetes [] no arquivo.
Chave => É o parâmetro que está à esquerda do sinal de igual (=).
Valor => É o parâmetro que está à direita do sinal de igual (=).
Abaixo, exemplo simples do arquivo CAPolicy.inf.
Você também pode usar o arquivo CAPolicy.inf ao instalar o AD CS para definir o seguinte:
Instrução de prática de certificação - Isso descreve as práticas que a CA usa para emitir certificados. Isso inclui os tipos de certificados emitidos, informações sobre emissão, renovação e recuperação de certificados e outros detalhes sobre a configuração da autoridade de certificação.
Identificador de objeto - Isso identifica um objeto ou atributo específico.
Intervalos de publicação de CRL - Isso define o intervalo entre as publicações para a CRL de base.
Configurações de renovação da autoridade de certificação - Você pode definir as configurações de renovação da seguinte forma:
- Tamanho da chave => Isso define o comprimento do par de chaves usado durante uma renovação da autoridade de certificação raiz.
- Período de validade do certificado => Isso define o período de validade de um certificado de CA raiz.
- Caminhos CDP e AIA => Isso fornece o caminho para instalações e renovações de CA raiz.
Depois de criar o arquivo CAPolicy.inf, copie-o para a pasta %SystemRoot% do seu servidor (por exemplo, C:\Windows) antes de instalar a função do AD CS ou antes de renovar o certificado da autoridade de certificação.
Nota: O arquivo CAPolicy.inf é processado para instalações e renovações de CA raiz e subordinada.
No próximo artigo, tratarei um pouco sobre administração do AD CS.
Um abraço e até mais!!!