Security WatchImplantação de uma PKI confiável globalmente

John Morello

Esta coluna inclui informações de pré-lançamento que estão sujeitas a alterações.

Uma infra-estrutura de chave pública, ou PKI, é um elemento fundamental no desenvolvimento de confiança entre diversos aplicativos, sistemas operacionais e territórios de identidade. Ela é criada sobre um modelo de confiança hierárquica no qual as entidades finais confiam em uma chave comum no nível mais alto da raiz e, portanto, quaisquer outras chaves assinadas por essa raiz são implicitamente confiáveis.

Devido a esta estrutura, uma PKI bem projetada pode ser dimensionada facilmente adicionando-se CAs (autoridades de certificação), sem introduzir alterações nas entidades finais.

Há duas maneiras típicas de implementação de PKIs. A abordagem mais comum é comprar certificados, conforme necessário, de um dos provedores de raízes globais implicitamente confiáveis, como a Cybertrust ou a VeriSign. Esses certificados são usados, freqüentemente, para proteger o tráfego em sites, mas também podem ser usados para VPNs (redes virtuais privadas), assinatura de email e tarefas similares. Como essas raízes globais são criadas em todos os navegadores da Web e sistemas operacionais modernos, esse método pode facilmente estender uma relação de confiança para além das fronteiras organizacionais. No entanto, como esses certificados são adquiridos conforme a necessidade, essa abordagem pode ser onerosa para implantação em larga escala em uma organização de grande porte.

O modelo de PKI interna tem sido mais usado ultimamente. Como o nome sugere, uma PKI interna é confiável apenas dentro da rede da própria organização. Esse modelo oferece uma maneira mais barata para uma organização prover certificados a todos os usuários e dispositivos de computação da rede. Essa abordagem costuma ser usada para facilitar tecnologias, como logon com cartão inteligente, EFS (sistema de arquivos com criptografia) e rede sem fio segura. A desvantagem é que, como esses certificados não são globalmente confiáveis, eles não servem para aplicativos direcionados para fora. Assim, a maioria das organização que implantou PKIs internas costuma adotar uma abordagem híbrida, adquirindo certificados para aplicativos públicos de uma das raízes globalmente confiáveis.

Mas, e se você pudesse se beneficiar dos dois mundos? E se a sua organização conseguisse executar a própria PKI – com a economia de custos referente à obtenção de certificados internos – e, ao mesmo tempo, conseguisse prover certificados publicamente confiáveis, tudo isso a partir de seu sistema local? Uma solução como essa ofereceria os benefícios de uma PKI interna (como integração com o Active Directory®, auto-inscrição e suporte de TI localizado) tendo, ao mesmo tempo, a principal vantagem de uma raiz globalmente confiável. A LSU (Universidade do Estado da Louisiana) tem esse sistema. Nesta edição do Security Watch, trato especificamente da solução que implementamos na LSU, discutindo seu projeto técnico e destacando as práticas recomendadas a serem usadas na instalação de um sistema similar. É importante observar que a solução que descreverei é uma solução que atendeu às necessidades específicas dadas pelo nosso ambiente, recursos e requisitos comerciais. Você deve avaliar todos esses aspectos de sua empresa com antecedência para determinar o tipo de solução certa para você.

Como a LSU cria PKI

A LSU é uma universidade de pesquisa de grande porte com um público de estudantes, professores e funcionários de mais de 40.000 pessoas. Ela tem muitos sites públicos, e muitos deles necessitam de TLS – o termo adequado para certificados SSL (secure sockets layer). A LSU gastava milhares de dólares anualmente com certificados de fornecedores de raízes globalmente confiáveis.

Enquanto isso, havia outros objetivos de segurança de TI que poderiam tirar grandes vantagens de uma PKI interna bem projetada. Com base nos objetivos e requisitos da LSU, você poderia esperar que decidíssemos adotar um modelo híbrido. Mas, em invés disso, tomamos uma decisão com base em uma abordagem mais inovadora.

Trabalhamos com uma das raízes globalmente confiáveis, a Cybertrust, para implantar uma CA subordinada a uma CA raiz da Cybertrust nas instalações da LSU (consulte a Figure 1). A Cybertrust oferece esse serviço no programa OmniRoot. Nesse cenário, a LSU cria e opera uma CA que é executada localmente nos equipamentos da própria LSU. Entretanto, diferentemente do modelo interno tratado anteriormente, a CA da LSU não é auto-assinado e sua chave (bem como as chaves assinadas) é implicitamente confiável em praticamente todos os sistemas operacionais e navegadores modernos. Tecnicamente, esse projeto é uma extensão lógica da abertura dos padrões x.509. Como uma PKI é criada de acordo com esses padrões, é possível conectar sistemas criados por fornecedores diferentes com a mesma hierarquia geral. Posto isso, o que é particularmente interessante na solução OmniRoot são os termos de uso do serviço.

Figura 1** Certificado de raiz global Cybertrust **(Clique na imagem para aumentar a exibição)

O serviço OmniRoot foi projetado especificamente para o tipo de implantação de PKI implementado na LSU. No programa OmniRoot, as organizações pagam à Cybertrust uma taxa anual predefinida para participar do programa e pagam uma taxa por certificado apenas para os certificados criados para uso público. Em outras palavras, a LSU pode emitir tantos certificados quantos forem necessários para uso interno, sem se preocupar com taxas por certificado. Enquanto isso, o custo dos certificados públicos agora é significativamente menor do que pagávamos quando a universidade comprava certificados cada vez que eles eram necessários.

Para esclarecer, os certificados internos e os públicos são idênticos, do ponto de vista técnico. Eles são emitidos pela mesma cadeia de CA, têm a mesma proteção de criptografia e são fornecidos pelo mesmo sistema de autoridade de registro. A única diferença entre os dois são os termos de licenciamento.

Em última instância, conseguimos expandir e aprimorar a plataforma de segurança de TI da LSU com um custo mais baixo. Essa conquista tornou-se um grande caso comercial para esse tipo de solução de PKI na LSU. Agora, vamos examinar os detalhes mais técnicos da implantação.

Hierarquia da PKI

A hierarquia da PKI da LSU baseia-se em um projeto em duas camadas, com a camada raiz gerenciada pela Cybertrust e uma CA de emissão online sendo executada na LSU (consulte a Figura 2). A camada raiz forma a âncora para a confiabilidade na hierarquia. Em outras palavras, a relação de confiança de todos os certificados emitidos por qualquer CA na hierarquia está sob a CA raiz (consulte a Figura 3). Assim, a CA raiz forma o vínculo comum entre todas CAs, certificados e entidades finais na hierarquia. Como a raiz global da Cybertrust já está incorporada no Windows® e em praticamente todos os outros sistemas de computação modernos, esse vínculo comum se estende automaticamente além da rede da LSU.

Figure 2 Hierarquia de PKI em duas camadas

Figura 3** Certificado emitido pela CA da LSU **(Clique na imagem para aumentar a exibição)

A Cybertrust gerencia a CA raiz em uma de suas instalações de hospedagem segura. A instalação de hospedagem usa fortes controles de segurança física, inclusive armadilhas, fechaduras biométricas e um cofre de armazenamento totalmente revestido com cobre. A Cybertrust emite certificados apenas para as CAs emissoras de organizações que demonstram compatibilidade com suas diretivas de segurança e certificação.

A CA emissora da LSU é um sistema voltado para a entidade final responsável pelo fornecimento de certificados ao público de usuários e máquinas da LSU. Seu certificado é assinado pela CA da Cybertrust acima dela na hierarquia e emite certificados que se encadeiam para a CA raiz da Cybertrust (consulte a Figura 3).

SO e hardware emissores

A LSU usa o Windows Server® 2003 Enterprise Edition com Service Pack 1 para sua CA emissora. O serviço de Autoridade de certificação do Windows Server 2003 oferece muitos recursos novos, incluindo arquivamento de chaves, CRLs (listas de revogação de certificado) delta e modelos "versão 2". A instância do Windows usada como CA emissora é criada de acordo com a diretiva de criação do Windows Server da LSU. Ela é atualizada com todas as atualizações de segurança relevantes e gerenciada com as práticas de gerenciamento de alterações padrão da LSU, inventário de software e ferramentas de atualização. Resumindo, enquanto há alguns aspectos particulares no gerenciamento do serviço da CA em si, o sistema operacional e hardware de servidor básicos são facilmente integrados nas operações de TI existentes da organização.

Além das práticas recomendadas padrão da LSU para instalação de servidor a seguir, aproveitamos o SCW (assistente de configuração de segurança), disponível no Windows Server 2003 Service Pack 1. O SCW usa um banco de dados que contém as matrizes de dependência das diversas cargas de trabalho que podem ser executadas no Windows Server e a configuração de segurança necessária para essas cargas de trabalho. Esse banco de dados inclui duas funções principais que a CA oferecerá - o serviço de CA em si e o IIS (que fornece o site de auto-atendimento de PKI).

Usando o SCW, criamos, facilmente, um modelo de segurança que desabilitou todos os serviços, exceto os necessários para executar essas cargas de trabalho, bem como protegemos a pilha de rede do servidor. Usamos então scwcmd.exe para transformar esse modelo em um GPO (objeto de diretiva de grupo), de modo que pudéssemos aplicá-lo no servidor no nível de unidade organizacional. Essa abordagem simplifica o dimensionamento e a recuperação de desastres, já que a configuração de segurança baseada em função para uma CA da LSU agora está armazenada dentro do Active Directory e não em uma máquina específica.

A CA emissora da LSU está instalada em um servidor IBM xSeries 346, com processadores dual 3.2GHz Intel Xeon, 4GB de RAM e cinco discos rígidos de 146GB SCSI. Considerando-se as necessidades de desempenho do serviço de CA e o fato de que a LSU usa um nódulo de segurança de hardware, essa plataforma deve oferecer longevidade significativa e espaço para crescimento.

Seguimos práticas recomendadas padrão para separar bancos de dados e arquivos de log em eixos físicos distintos, criando duas matrizes RAID 1. O quinto disco rígido é mantido como reserva quente e está disponível para as duas matrizes. Montamos a primeira matriz como nosso volume do sistema, onde mantemos o banco de dados da CA. A segunda matriz é usada para arquivos de log e vários outros arquivos de dados, como os CRLs. O banco de dados da CA é baseado na mesma tecnologia Jet encontrada em outras áreas do Windows, como o Active Directory, de modo que as mesmas práticas recomendadas de manutenção e configuração de disco para outras soluções de armazenamento em Jet se aplicam aqui.

Um HSM (módulo de segurança de hardware) é um dispositivo de hardware dedicado gerenciado separadamente a partir do sistema operacional. Normalmente, os HSMs são fornecidos como adaptadores PCI, mas também estão disponíveis como aplicativos com base na rede. Esses módulos fornecem um armazenamento de hardware seguro para chaves de CA, bem como um processador criptográfico dedicado para acelerar operações de assinatura e criptografia. O Windows usa o HSM por intermédio das interfaces CryptoAPI – o HSM é visto como um dispositivo CSP (provedor de serviços de criptografia). O programa OmniRoot requer que cada CA use pelo menos um HSM com certificado FIPS 140-2 nível 3 (dispositivos de nível 4 são bastante raros) para geração e armazenamento de chaves. Como um dispositivo exclusivo e de alta segurança, um HSM requer um investimento financeiro notável, os preços de tabela para HSM com base em PCI ficam geralmente entre US$10.000 e 15.000.

No projeto da LSU, um nCipher nShield 500 TPS (modelo 500 transações por segundo) é usado como um HSM de acesso direto. ("Acesso direto" significa que é interno ao servidor e está disponível para uso apenas por esse servidor, em contraste com um HSM com base em rede que pode ser compartilhado por vários hosts). O HSM é um dispositivo FIPS 140-2 nível 3 e oferece proteção K de N para o material de chaveamento. O HSM oferece proteção significativa contra o comprometimento das chaves privadas - um invasor precisaria possuir tanto o armazenamento HSM quando uma quantidade definida de tokens de acesso e PINs para acessar a chave.

É fundamental observar que os HSMs foram projetados para evitar que seu conteúdo seja alterado por partes mal intencionadas. Assim, os HSMs forçam severamente um limite para tentativas consecutivas de logon com falha. No projeto da LSU, o armazenamento é irrevogavelmente apagado após 10 tentativas com falha.

Temos uma única CA em nossa configuração, de modo que o preço de um HSM com base em rede não se justifica. No entanto, se uma organização planeja implementar duas ou mais CAs, pode ser significativamente mais barato comprar um único HSM com base em rede e compartilhá-lo entre as CAs. Essa abordagem também facilita o gerenciamento de tokens, já que todo o armazenamento de chaves pode ser protegido pelo mesmo conjunto de tokens.

Active Directory e registro

Uma das principais vantagens de uma solução de PKI com base no Windows é que o fornecimento de certificados é obtido sem a necessidade de instalar software adicional em entidades que participam da PKI. Em vez disso, através de uma combinação de auto-registro e Diretiva de grupo, a maior parte do fornecimento de certificados pode ser gerenciada de forma autônoma, invisível para o usuário final. A LSU usa essa tecnologia para distribuir certificados eletrônicos automaticamente para computadores membros de seu Active Directory. E usamos um site personalizado para fornecer recursos de requisição de certificados de auto-atendimento para hosts não baseados em Windows.

Como já foi dito, o programa OmniRoot distingue os certificados usados publicamente daqueles usados internamente. Os certificados serão considerados públicos se forem usados por sistemas e usuários que não fazem parte da organização da LSU (por exemplo, quando um estudante em potencial envia uma inscrição para matrícula através de um site com segurança SSL). Certificados usados dentro da organização da LSU (como os que são usados para criptografar dados nos servidores da LSU) são considerados internos.

Como o custo do programa OmniRoot é baseado no número de certificados públicos, precisamos rastrear quantos certificados públicos são emitidos, e para quem. Assim, para qualquer certificado cujo propósito seja público, o nome distinto do modelo começa com "PublicCertificate" e o nome para exibição começa com "Public Certificate". Por exemplo, o modelo de certificado público TLS da LSU é baseado no modelo padrão do Windows Web Server e é denominado Public Certificate LSU Web Server. Para servidores Web usados internamente, temos um segundo modelo chamado Internal Certificate LSU Web Server. Tecnicamente, os dois modelos são idênticos, a diferença no nome serve apenas para facilitar a contabilidade.

Para fins de registro em massa – como o registro de departamentos inteiros para certificados a serem usados com IPSec – usamos o auto-registro. Essa é uma ferramenta simples e altamente eficiente interna do Windows. Do ponto de vista de um administrador de PKI, a única ação necessária é alterar a lista de controle de acesso no modelo, concedendo a qualquer grupo de usuários ou computadores que precisarem de certificados o direito de se auto-registrarem. Essas entidades conferirão o Active Directory automaticamente, definirão para quais modelos terão acesso de auto-registro, encontrarão as CAs com esses modelos e se registrarão automaticamente nos certificados. Além disso, o recurso de auto-registro garantirá que os certificados sejam substituídos, se um modelo for substituído, e sejam renovados automaticamente antes de expirarem.

Para propostas sem trabalho em massa, como fornecer certificados para servidores da Web, usamos um site de auto-atendimento que permite que usuários solicitem certificados através de um navegador da Web. Esse site é uma versão personalizada das páginas de registro da Web que acompanham o Windows Server 2003 (o diretório virtual /certsrv); nossa implementação inclui a marca padrão da Web da LSU e preenche as entradas padrão corretas na página de solicitação. E usamos o módulo de saída padrão do serviço Windows CA para enviar automaticamente um email para a equipe de administração de PKI quando uma solicitação enviada através desse site necessitar de aprovação.

Projeto de revogação

Cada certificado tem um tempo de vida útil. Com uma certa freqüência, a LSU precisa invalidar determinados certificados antes do final de seu período de validade (por exemplo, se um funcionário recebe um certificado com um período de validade que expira em maio de 2007, mas deixa a LSU em janeiro de 2007). Esse tipo de revogação é obtido com CRLs, arquivos que contêm uma lista de números de série de certificados assinados por uma CA. Os números de série presentes em um CRL se referem a certificados cujo tempo de vida útil não tenha expirado, mas que a LSU já não considera confiáveis. Os clientes podem fazer o download desse CRL e fazer sua verificação para determinar a validade dos certificados.

Qualquer certificado x.509 v3 (exceto o próprio certificado raiz da CA) deve ter um ponteiro para um CRL válido. Esse ponteiro é conhecido como ponto de distribuição de CRL, ou CDP. O ponto de distribuição de CRL é fornecido no próprio certificado (consulte a Figura 4) e não pode ser modificado após a emissão do certificado. O CRL é uma parte essencial para garantir que os certificados de uma CA sejam válidos. Assim, verificamos se os CRLs da LSU são fisicamente redundantes, altamente disponíveis e acessíveis por partes externas.

Figura 4** Ponto de distribuição de CRL da LSU **(Clique na imagem para aumentar a exibição)

Uma CA com base no Windows Server integrada com o Active Directory (como a da LSU), publica automaticamente o seu CRL no Active Directory, tornando-o acessível através do protocolo LDAP. O local de publicação padrão é o contêiner CDP (consulte a Figura 5) no contêiner de Serviços de chave pública na floresta. Esse local de publicação é uma excelente opção, já que oferece replicação automática, tolerância a falhas e localidade para pesquisas CDP.

Figura 5** Contêiner CDP **(Clique na imagem para aumentar a exibição)

No projeto da LSU, no entanto, há muitos computadores que não usam o Windows nem o Active Directory e usam a PKI. E como a LSU é uma organização de grande porte, a grande maioria de seus usuários se encontra na mesma rede do campus, com um backbone de 10Gbps, tornando mínimas as vantagens da publicação de CDP com base no Active Directory.

Dessa forma, publicamos nosso CRL apenas em um caminho HTTP, facilitando a criação de uma plataforma de hospedagem redundante (nosso site principal já está espelhado). Isso também remove as possíveis complexidades associadas à habilitação de buscas LDAP de cliente. Publicamos nosso CRL diariamente e publicamos CRLs delta de hora em hora.

Seguindo adiante

Enquanto nossa PKI atual fornece uma solução de segurança forte para a comunidade universitária, planejamos o aprimoramento de seus recursos. O Windows Vista™ e a próxima versão do Windows Server (codinome "Longhorn") fornecerão diversos recursos novos de gerenciamento de chaves que queremos investigar. Estamos particularmente interessados nos recursos de cliente e respondente do OCSP (protocolo de status de certificado online), no suporte para criptografia em curva elíptica e algoritmos SHA-256 e em uma interface de auto-registro mais aprimorada. Além disso, o Windows XP Service Pack 3 está programado para incluir um recurso conhecido como credential roaming, que fornecerá mobilidade com segurança de pares de chaves sem a sobrecarga associada aos perfis móveis. Finalmente, estamos investigando o uso do Certificate Lifecycle Manager (que já está disponível em beta) para melhorar nossos recursos de relatório e gerenciamento.

Resumindo, a PKI da LUS oferece à universidade um serviço de segurança básico usado para muitas funções críticas de TI. Usando o serviço OmniRoot da Cybertrust, podemos executar uma PKI integrada com os outros sistemas de TI da LSU, mas com confiabilidade global. E, construindo a solução no serviço de CA do Windows, temos recursos de fornecimento e gerenciamento de certificados eficientes e excelente integração com nosso sistema de diretórios e gerenciamento de identidades existente. Enfim, a visão PKI de segurança forte e confiabilidade contínua já está se tornando uma realidade na LSU.

John Morello graduou-se com louvor na Louisiana State University e passou seis anos na Microsoft como consultor sênior da Microsoft Consulting Services. Com a MCS, ele projetou PKIs para clientes estratégicos, como a Deloitte, GE e várias organizações federais. Hoje, ele é o representante CISO na LSU (Universidade do Estado da Louisiana).

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..