Introdução:
Esta é a décima nona parte do Tutorial de TCP/IP. Na Parte 1 tratei dos aspectos básicos do protocolo TCP/IP. Na Parte 2 falei sobre cálculos binários, um importante tópico para entender sobre redes, máscara de sub-rede e roteamento. Na Parte 3 falei sobre Classes de endereços, na Parte 4 fiz uma introdução ao roteamento e na Parte 5 apresentei mais alguns exemplos/análises de como funciona o roteamento e na Parte 6 falei sobre a Tabela de Roteamento. Na Parte 7 tratei sobre a divisão de uma rede em sub-redes, conceito conhecido como subnetting. Na Parte 8 fiz uma apresentação de um dos serviços mais utilizados pelo TCP/IP, que é o Domain Name System: DNS. O DNS é o serviço de resolução de nomes usado em todas as redes TCP/IP, inclusive pela Internet que, sem dúvidas, é a maior rede TCP/IP existente. Na Parte 9 fiz uma introdução ao serviço Dynamic Host Configuration Protocol – DHCP. Na Parte 10 fiz uma introdução ao serviço Windows Internet Name Services – WINS. Na Parte 11 falei sobre os protocolos TCP, UDP e sobre portas de comunicação. Parte 12, mostrei como são efetuadas as configurações de portas em diversos aplicativos que você utiliza e os comandos do Windows 2000/XP/2003 utilizados para exibir informações sobre portas de comunicação. Na Parte 13 falei sobre a instalação e a configuração do protocolo TCP/IP. Na Parte 14 fiz uma introdução sobre o protocolo de roteamento dinâmico RIP e na Parte 15 foi a vez de fazer a introdução a um outro protocolo de roteamento dinâmico, o OSPF. Na Parte 16 você aprendeu sobre um recurso bem útil do Windows 2000: O compartilhamento da conexão Internet, oficialmente conhecida como ICS – Internet Conection Sharing. Este recurso é útil quando você tem uma pequena rede, não mais do que cinco máquinas, conectadas em rede, todas com o protocolo TCP/IP instalado e uma das máquinas tem conexão com a Internet. Você pode habilitar o ICS no computador que tem a conexão com a Internet. Na Parte 17, você aprendeu a utilizar o IFC – Internet Firewall Connection (Firewall de Conexão com a Internet). O IFC faz parte do Windows XP e do Windows Server 2003, não estando disponível no Windows 2000. O IFC tem como objetivo proteger o acesso do usuário contra “ataques” e “perigos” vindos da Internet. Na Parte 18 fiz uma apresentação sobre o protocolo IPSec. O IPSec faz parte do Windows 2000, Windows XP e Windows Server 2003. O IPSec pode ser utilizado para criar um canal de comunicação seguro, onde todos os dados que são trocados entre os computaodres habilitados ao IPSec, são criptografados.
Nesta décima nona parte, farei uma apresentação sobre o conceito de PKI – Public Key Infrastructure e Certificados Digitais. O Windows 2000 Server e também o Windows Server 2003 disponibilizam serviços para a emissão, gerenciamento e revogação de Certificados Digitais. Você também entenderá o papel dos Certificados Digitais em relação à segurança das informações.
Apresentarei o conceito de PKI - Public Key Infrastructure (Infraestrutura de chave pública). Você verá que uma Public Key Infrastructure (Infraestrutura de chave pública), abreviada simplesmente como PKI, nada mais é do que uma infraestrutura de segurança baseada em certificados digitais, em autoridades certificadores (CA – Certificate Authorities - que emitem e revogam os certificados) e autoridades de registro, as quais fazem a verificação da autenticidade de todas as estruturas envolvidas
Nes
Nota: Para aprender a instalar, configurar e a administrar o Microsoft Certificate Services, consulte o Capítulo 7 do meu livro: Manual de Estudos Para o Exame 70-216, 712 páginas.
O uso de Certificados e uma infra-estrutura de chave pública é uma alternativa de baixo custo, para ambientes que precisam de níveis de segurança elevados, como por exemplo departamentos de pesquisa de novos produtos e tecnologias, ou órgãos governamentais estratégicos, como os órgãos de defesa e de segurança. Com o uso do Microsoft Certificate Services é possível criar a administrar uma estrutura de segurança baseada
Microsoft Certificate
Neste tópico apresentarei o conceito de PKI e de criptografia baseada em um par de chaves de criptografia: uma chave pública e uma chave privada. Você verá que os Certificados digitais tem papel fundamental em uma estrutura de PKI. Neste tópico você também aprenderá a instalar e a configurar o Microsoft Certificate Services.
Uma introdução sobre Certificados e PKI – Public Key Infrastructure
Segurança mais do que nunca é um assunto sempre
No Windows 2000, Windows XP e no Windows Server 2003 existem diversas maneiras de proteger seus dados: permissões NTFS, criptografia, uso do NAT para acesso à Internet, uso de Group Policy Objects, uso de diretivas de segurança, direitos de usuários e por aí vai. Neste tópico, abordarei mais um assunto relacionado com segurança: Certificados Digitais.
Uma pergunta que o amigo leitor poderia fazer é a seguinte: “Por que existem tantos ataques de segurança e por que os hackers parecem conhecer tão bem os sistemas das empresas?”.
Um dos motivos é porque hoje o mundo inteiro (literalmente) utiliza o mesmo protocolo para comunicação e troca de dados: TCP/IP. Como o TCP/IP é amplamente conhecido e documentado, esta informação também é utilizada por hackers, para tentar descobrir falhas no próprio protocolo, falhas estas que permitam quebra de segurança dos sistemas informatizados das empresas. Evidentemente que, na maioria das vezes, os ataques são bem sucedidos, porque os programas foram instalados com as opções padrão (out of the Box – como saíram da caixa (a tradução é por minha conta e risco)), sem se preocupar em ajustar devidamente as configurações de segurança.
Nota: Um dos pontos onde o Windows Server 2003 melhorou, e muito, em relação ao Windows 2000 Server foi nas configurações de segurança out of the Box. Ou seja, as configurações padrão de segurança do Windows Server 2003, são bem mais severas, restringem bem mais o acesso do que as configurações padrão de segurança do Windows 2000 Server. A idéia é simples mas muito eficiente. Por padrão, o nível mínimo de acesso, necessário ao funcionamento do recurso. Se houver necessidade de modificações nas configurações de segurança, estas poderão ser feitas pelo administrador.
Com o uso do TCP/IP como protocolo de comunicação, os dados não são protegidos por padrão, isto é, não são criptografados. Ou seja, se um hacker interceptar uma transmissão, terá acesso aos dados sem maiores problemas, uma vez que não é usada criptografia, por padrão. Claro que para muitas situações, a criptografia e outros recursos de segurança são perfeitamente dispensáveis. Por exemplo, quando você acessa o site de uma empresa para obter informações gerais sobre a empresa. Estas informações são de domínio público (afinal estão no site da empresa) e não há necessidade de criptografá-las. Agora quando você faz uma compra pela Internet, usando o seu cartão de crédito, ou quando você faz transações bancárias usando o site do seu Banco, a coisa muda completamente de figura. Ou seja, você quer o máximo de segurança possível. De maneira alguma você gostaria que alguém pudesse interceptar o seu número de conta, agência e senha.
Inicialmente criou-se um método de criptografia, onde os dados eram criptografados usando uma determinada chave de criptografia. A chave é um código com um determinado número de bits. Usa-se este código, juntamente com operações lógicas, para “embaralhar”, ou seja, criptografar os dados. A seqüência de operações lógicas que é realizada com os dados, usando a chave de criptografia, é definida pelo algoritmo de criptografia. Em seguida os dados e a chave de criptografia são enviados para o destinatário. O destinatário recebe os dados e a chave de criptografia e utiliza esta chave para “descriptografar” os dados. Um método bem seguro, não?
Não. Este método tem dois problemas principais, os quais são descritos a seguir:
1. A chave de criptografia é enviada junto com os dados: Com isso, se um hacker interceptar os dados, terá também acesso a chave de criptografia. Usando a chave (os algoritmos de criptografia são de domínio público, a segurança é baseada normalmente no tamanho da chave. Usam-se chaves com um grande número de bits, para que seja difícil descobrir a chave que está sendo utilizada) o hacker poderá descriptografar os dados e ter acesso ao conteúdo da mensagem. Pior, o hacker poderia alterar a mensagem e envia-la, alterada, para o destinatário, o qual não teria como saber que a mensagem foi alterada.
2. No final do parágrafo anterior eu descrevo o segundo problema com este método: ele não permite a verificação da identidade de quem enviou a mensagem. Ou seja, um hacker interceptou a mensagem, usou a chave para descriptografá-la, alterou a mensagem e a enviou para o destinatário. O destinatário recebe a mensagem e não tem como verificar se a mensagem veio do emissor verdadeiro ou veio de um hacker. Com este método não é possível verificar e garantir que o emissor seja quem ele diz ser. Não há como verificar a identidade do emissor.
Vejam que somente o uso da criptografia, baseada em uma chave privada (chave enviada junto com a mensagem), não é tão seguro como pode parecer. Para solucionar esta questão é que surgiram os Certificados Digitais, com os quais é possível implementar uma infra-estrutura conhecida como PKI - Public Key Infrastructure (Infraestrutura de chave pública). Esta infra-estrutura é baseada no uso de certificados digitais e de um par de chaves: uma chave pública e uma chave privada. A seguir descrevo os princípios básicos de um infra-estrutura baseada em chaves pública e privada, para que você possa entender como esta infra-estrutura resolve os dois problemas apontados no método anterior.
Em uma rede que usa PKI, um Certificado Digital é criado para cada usuário. O Certificado Digital fica associado com a conta do usuário no Active Directory. Para cada usuário é criado um par de chaves: uma chave pública e uma chave privada. A chave pública fica disponível no Active Directory e a chave privada fica com o usuário. O mais comum é a chave privada ficar gravada no Certificado Digital do usuário, em um disquete que fica com o usuário. Agora vamos entender como funciona a criptografia baseada em um par de chaves: uma pública e outra privada.
Dados que são criptografados com uma das chaves, somente poderão ser descriptografados com a outra chave. Por exemplo, se você criptografar dados com a chave pública do usuário jsilva, estes dados somente poderão ser descriptografados com a chave privada do usuário jsilva.
Vamos imaginar que o usuário jsilva precisa enviar dados para o usuário maria. Os dados são criptografados com a chave pública do usuário Maria – chave pública do destinatário. Com a infraestrutura de PKI, as chaves públicas ficam disponíveis para serem acessadas por quaisquer usuário. A chave pública fica gravada no Certificado Digital do usuário e a lista de Certificados Digitais fica publicada para acesso em um servidor de certificados digitais (este é o papel do Microsoft Certificate Services, ou seja, emitir, publicar e revogar certificados digitais para os usuários).
A chave pública do usuário maria é utilizada pelo usuário jsilva para criptografar os dados, antes de envia-los para o usuário maria. Como os dados foram criptografados com a chave pública do usuário maria, a pergunta é: qual a única chave que poderá descriptografar estes dados? A chave privada do usuário maria, a qual somente o usuário maria tem acesso. Com este método, quando o usuário maria recebe os dados, ele utilizará a sua chave privada para descriptografá-los. Se um hacker interceptar os dados, ele não conseguirá descriptografá-los, pois não tem acesso a chave privada do usuário maria. Observe que com este método, a chave de criptografia não é enviada junto com a mensagem. Além disso, a mensagem é criptografada de tal maneira que somente o destinatário é capaz de descriptografá-la, ou melhor, a chave privada do destinatário. Como a mensagem é criptografada com a chave pública do destinatário, somente o próprio destinatário (que é quem tem acesso a sua chave privada), será capaz de descriptografar a mensagem.
Observe que com este método é solucionado o problema de ter que enviar a chave de criptografia junto com a mensagem. O problema de verificação da identidade, de ter certeza que o remetente é quem diz realmente ser, é solucionado com o uso de Certificados digitais. De uma maneira simples, podemos resumir uma PKI como sendo uma infra-estrutura de segurança, baseada no uso de um par de chaves (uma pública e uma privada) e de Certificados Digitais.
Um pouco sobre Certificados Digitais
De uma maneira simples, o Certificado Digital é a versão eletrônica da sua identificação de usuário na rede (usuário e senha). O Certificado Digital é como se fosse a “carteira de identidade” do usuário na rede. No Windows 2000 Server e no Windows Server 2003, o certificado digital do usuário também é conhecido (na documentação oficial), como um Certificado de chave pública, uma vez que uma das informações gravadas no certificado digital do usuário é justamente a sua chave pública.
Um certificado de chave pública, geralmente chamado somente de certificado, é uma declaração assinada digitalmente que vincula o valor de uma chave pública à identidade da pessoa (conta do usuário no Active Directory), dispositivo ou serviço que contém a chave privada correspondente.
Certificados podem ser emitidos para uma série de funções, como autenticação de usuário na Internet, autenticação de um servidor Web, correio eletrônico seguro (S/MIME), IPSec, para utilização com o protocolo Transaction Layer Security (TLS, segurança de camada de transação) e assinatura de códigos (por exemplo, todos os programas desenvolvidos pela Microsoft são assinados, digitalmente, com o Certificado digital da Microsoft. O Windows 2000 Server pode ser configurado para não instalar drives ou programas que não estejam assinados digitalmente ou cujos certificados com os quis foram assinados, não possam ser verificados).
Os certificados digitais tem que ser emitidos por uma Autoridade Certificadora (CA – Certificate Authority). Uma opção é usar uma autoridade certificadora externa, como por exemplo a Veri Sign, que é uma empresa especializada em segurança e em certificação digital (www.verisign.com). Com o Windows 2000 Server (e também com o Windows Server 2003), está disponível o Microsoft Certificate Services, que é um servidor que permite criar uma autoridade certificadora na própria rede da empresa, sem ter que fazer uso de uma entidade certificadora externa. Ao utilizar o Certificate Services para a emissão e gerenciamento de certificados, os certificados digitais poderão ser utilizados pelos usuários, para fazer o logon na rede. Os certificados também são emitidos de uma autoridade de certificação para outra a fim de estabelecer uma hierarquia de certificação. Usando o Certificate Services você poderá criar uma hierarquia de certificação na rede da empresa.
A maioria dos certificados em uso hoje em dia são baseados no padrão X.509. Esta é a tecnologia fundamental usada na public key infrastructure (PKI) do Windows 2000 e do Windows Server 2003.
Normalmente, os certificados contêm as seguintes informações:
? Chave pública do usuário
? Informações da identificação do usuário (como o nome e o endereço de correio eletrônico)
? Período de validade (o período de tempo em que o certificado é considerado válido)
? Informações sobre a identificação do emissor do certificado.
? A assinatura digital do emissor, que atesta a validade da ligação entre a chave pública do usuário e as informações de identificação do usuário.
Um certificado só é válido pelo período de tempo nele especificado, ou seja, o certificado tem prazo de validade e tem que ser renovado periodicamente. Esta é uma medida importante para garantir aumentar o nível de segurança, pois a cada renovação, um novo par de chaves é gerado. Cada certificado contém datas “Válido de” e “Válido até”, que limitam o período de validade. Depois que o período de validade de um certificado terminar, um novo certificado deve ser solicitado pelo usuário do agora expirado certificado.
Em situações em que seja necessário desabilitar um certificado, este pode ser revogado pelo emissor. Cada emissor mantém uma lista de certificados revogados (CRL – Certification Revocation List), a qual é usada pelos programas quando a validade de um determinado certificado está sendo verificada. Por exemplo, programas que usam certificados para autenticação, ao receberem uma tentativa de acesso, primeiro entram em contato com a autoridade certificadora (no caso do Windows 2000 Server um servidor com o Microsoft Certificate Service) para verificar se o certificado que está sendo apresentado para logon, não está na lista dos certificados revogados – CRL. Se o certificado estiver na CRL, o logon será negado.
Certificados e Autoridades de Certificação
Todo certificado é emitido por uma Autoridade de Certificação (CA – Certifcate Authority). A autoridade de certificação, a partir de agora denominada apenas CA, é responsável pela verificação sobre a veracidade dos dados do usuário que está requisitando o certificado. Por exemplo, qualquer usuário pode solicitar um certificado para utilizar na Internet. Para obter o certificado ele precisa utilizar os serviços de uma CA, como por exemplo a VeriSign (www.verisign.com).
Uma autoridade de certificação é uma entidade encarregada de emitir certificados para indivíduos, computadores ou organizações, sendo que os certificados é que confirmam a identidade e outros atributos do usuário do certificado, para outras entidades. Uma autoridade de certificação aceita uma solicitação de certificado, verifica as informações do solicitador e, em seguida, usa sua chave privada para aplicar a assinatura digital no certificado. A autoridade de certificação emite então o certificado para que o usuário do certificado o use como uma credencial de segurança dentro de uma infra-estrutura de chave pública (PKI). Uma autoridade de certificação também é responsável por revogar certificados e publicar uma lista de certificados revogados (CRL).
Uma autoridade de certificação pode ser uma empresa que presta o serviço de autoridade certificadora, como o VeriSign, ou pode ser uma autoridade de certificação que você cria para ser usada por sua própria organização, instalando os Serviços de certificados do Windows 2000. Cada autoridade de certificação pode ter requisitos diferentes de prova de identidade, como uma conta de domínio do Active Directory, crachá de empregado, carteira de motorista, solicitação autenticada ou endereço físico. Verificações de identificação como essa geralmente asseguram uma autoridade de certificação no local, de tal modo que as organizações possam validar seus próprios empregados ou membros.
As autoridades de certificação corporativas do Windows 2000 Server usam as credenciais da conta de usuário do Active Directory de uma pessoa, como prova de identidade. Em outras palavras, se você tiver efetuado logon em um domínio do Windows 2000 Server e solicitar um certificado de uma autoridade de certificação corporativa, a autoridade de certificação saberá que você é quem o Active Directory “diz que você é”.
Todas as autoridades de certificação têm um certificado para confirmar sua própria identidade, emitido por outra autoridade de certificação confiável ou, no caso de autoridades de certificação raiz, emitido por elas mesmas. É importante lembrar que qualquer pessoa pode criar uma autoridade de certificação. A questão real é se você, como um usuário ou um administrador, confia naquela autoridade de certificação e, por extensão, nas diretivas e procedimentos que ela emprega para confirmar a identidade dos certificados emitidos para entidades por essa autoridade de certificação.
Em uma rede baseada no Windows 2000 Server (ou no Windows Server 2003), o administrador também pode utilizar uma CA externa. Porém, com o uso do Microsoft Certificate Services, o administrador pode criar sua própria autoridade certificadora. O Certificate Services da Microsoft permite a criação de sofisticados ambientes de certificação, com a criação de uma hierarquia de CAs. Com o uso do Certificate Services podem ser criadas os seguintes tipos de autoridades certificadoras, os quais serão descritos mais adiante:
? Enterprise Root CA.
? Enterprise Subordinate CA.
? Standalone Root CA.
? Standalone Subordinate CA
Ao criar uma estrutura interna para criação e gerenciamento de certificados digitais, você deve definir os procedimentos que serão utilizados para verificar a veracidade dos dados dos usuários que estão solicitando certificados. Por exemplo, você pode utilizar as informações do Active Directory, como sendo as informações oficiais de cada funcionário, porém o funcionário tem acesso a alterar as informações da sua conta no Active Directory. Com isso você terá que montar uma metodologia formal de verificação (um pouco de burocracia as vezes se faz necessária). Por exemplo, você pode solicitar que o chefe imediato do funcionário confirme os dados em um formulário na Intranet da empresa (formulário de papel também já seria demais).
A existência de uma autoridade certificadora significa que você tem confiança de que a autoridade de certificação possui as diretivas corretas no local correto e ao avaliar as solicitações de certificado, irá negar certificados para qualquer entidade que não atender a essas diretivas. Esta é uma questão fundamental para garantir a identidade dos usuários. Ao fazer uma verificação rigorosa dos dados informados, antes de emitir um certificado para um usuário, servidor ou computador, a CA garante que quem obtém o certificado realmente é quem diz ser – prova de identidade. Por isso a importância fundamental de definir uma metodologia clara, simples e de fácil execução, para a verificação dos dados, antes de emitir os certificados.
Além disso, você confia que a autoridade de certificação irá revogar certificados que não devem mais ser considerados válidos publicando uma lista de certificados revogados, sempre atualizada (CRL – Certificate Revocation List). As listas de certificados revogados são consideradas válidas até expirarem. Logo, mesmo que a CA publique uma nova lista de certificados revogados com os certificados recém revogados listados, todos os clientes que possuírem uma lista de revogação de certificados antiga não irão procurar nem recuperar a lista nova até que a antiga expire ou seja excluída. Clientes podem usar as páginas da Web da CA para recuperar manualmente a lista de certificados revogados mais atual, caso seja necessário.
Para serviços, computadores e usuários do Windows 2000 Server, a confiança em uma autoridade de certificação é estabelecida quando você possui uma cópia do certificado raiz no armazenamento das autoridades de certificação raiz confiáveis e tem um caminho de certificação válido, significando que nenhum dos certificados no caminho de certificação foi revogado ou que seus períodos de validade expiraram. O caminho de certificação inclui todos os certificados emitidos para cada CA na hierarquia da certificação de uma CA subordinada para a CA raiz. Por exemplo, para uma CA raiz, o caminho de certificação é um certificado, seu próprio certificado auto-assinado. Para uma CA subordinada, abaixo da CA raiz na hierarquia, seu caminho de certificação inclui 2 certificados, seu próprio certificado e o certificado da CA raiz.
Caso sua organização esteja usando o Active Directory, a confiança nas autoridades de certificação da organização será estabelecida automaticamente, baseada nas decisões e configurações realizadas pelo administrador do sistema e nas relações de confiança criadas automaticamente pelo Active Directory.
Os diferentes tipos de Autoridades Certificadores
Conforme descrito anteriormente, podem ser criados diferentes tipos de autoridades certificadoras. Pode ser uma autoridade certificadora corporativa (Enterprise) ou Autônoma (Standalone). Cada um destes tipos pode ser uma autoridade certificadora root ou subordinada. Com isso ficamos com os quatro tipos possíveis de autoridades certificadores:
? Corporativa root CA
? Corporativa subordinada CA
? Autônoma root CA
? Autônoma subordinada CA
Uma autoridade de certificação raiz, mais conhecida como autoridade root, é encarada como o tipo mais confiável de autoridade de certificação na PKI de uma organização. Geralmente, tanto a segurança física como a diretiva de emissão de certificados de uma autoridade de certificação raiz são mais rigorosas do que as de autoridades de certificação subordinadas.
Se a autoridade de certificação raiz estiver comprometida ou emitir um certificado para uma entidade não autorizada, toda a segurança baseada em certificados, da sua organização, estará vulnerável e não será mais confiável. Enquanto as autoridades de certificação raiz podem ser usadas para emitir certificados para usuários finais em tarefas como enviar correio eletrônico seguro, na maioria das organizações elas são usadas apenas para emitir certificados para outras autoridades de certificação, chamadas de subordinadas.
Uma autoridade de certificação subordinada é uma autoridade de certificação que foi certificada por outra autoridade de certificação de sua organização, ou seja, está subordinada a uma outra entidade certificadora. Se a entidade principal deixar de ser confiável, todas as entidades subordinadas também o deixarão de ser. Geralmente, uma autoridade de certificação subordinada emitirá certificados para usos específicos, como correio eletrônico seguro, autenticação baseada na Web ou autenticação de cartões inteligentes. Autoridades de certificação subordinadas também podem emitir certificados para outras autoridades de certificação subordinadas em um nível abaixo delas. Com isso é possível criar uma hierarquia de entidades certificadores. Juntas, a autoridade de certificação raiz, as autoridades de certificação subordinadas certificadas pela raiz e as autoridades de certificação subordinadas que foram certificadas por outras autoridades de certificação subordinadas formam uma hierarquia de certificação.
Autoridades de certificação corporativas
Você pode instalar o Microsoft Certificate Services para criar uma autoridade de certificação corporativa. Autoridades de certificação corporativas podem emitir certificados para várias finalidades, tais como assinaturas digitais, correio eletrônico seguro usando S/MIME (extensões multipropósito do Internet Mail protegidas), autenticação para um servidor Web seguro usando Secure Sockets Layer (SSL, camada de soquetes de segurança) ou segurança da camada de transporte (TLS) e logon em um domínio do Windows 2000 Server ou Windows Server 2003, usando um cartão inteligente (smart card).
Uma autoridade de certificação corporativa apresenta as seguintes características/exigências:
? Uma autoridade de certificação corporativa exige o Active Directory.
? Quando você instala uma autoridade de certificação corporativa raiz, ela é automaticamente adicionada ao armazenamento de certificados das Autoridades de certificação raiz confiáveis, para todos os usuários e computadores do domínio. Você precisa ser administrador de domínio ou administrador com direito de gravação no Active Directory para instalar uma autoridade de certificação corporativa raiz.
? Todas as solicitações de certificados enviadas para a autoridade de certificação corporativa serão atendidas ou negadas com base no conjunto de diretivas e permissões de segurança do tipo de certificado solicitado. Autoridades de certificação corporativas nunca definem uma solicitação de certificado como pendente. Elas imediatamente emitem o certificado ou negam a solicitação.
? Os certificados podem ser emitidos para efetuar logon em um domínio do Windows 2000 Server ou Windows Server 2003, usando cartões inteligentes (smart cards).
? O módulo de saída corporativo publica certificados de usuários e a lista de certificados revogados (CRL), no Active Directory. Para publicar certificados no Active Directory, o servidor em que a autoridade de certificação está instalada deve ser membro do grupo de Certificates Publishers (Publicadores de certificados). Isso é automático para o domínio em que o servidor está, mas a autoridade de certificação precisará receber as permissões de segurança corretas para publicar certificados em outros domínios.
Uma autoridade de certificação corporativa usa tipos de certificados, que são baseados em um modelo de certificado. A seguinte funcionalidade é possível devido ao uso de modelos de certificado:
? As autoridades de certificação corporativas aplicam verificações de credenciais aos usuários durante o registro de certificados. Cada modelo de certificado tem uma permissão de segurança definida no Active Directory que determina se quem está solicitando o certificado está autorizado a receber o tipo de certificado solicitado.
? O nome do usuário do certificado é automaticamente gerado.
? O módulo de diretiva adiciona uma lista predefinida de extensões de certificados ao certificado emitido a partir do modelo do certificado. Isso reduz a quantidade de informações que a pessoa que solicita o certificado precisa fornecer sobre o certificado e sobre o uso pretendido.
Os servidores que desempenham o papel de autoridades certificadoras corporativas, desempenham um papel fundamental na estrutura de segurança da empresa. Por isso é importante que você implemente políticas de backup e de segurança bem rigorosas em relação a estes servidores.
Além da segurança lógica, no acesso aos dados, é muito importante cuidar também da segurança física, controlando quem tem acesso ao servidor configurado como servidor corporativo root.
Autoridades de certificação autônomas
Você pode instalar os serviços de certificados para criar uma autoridade de certificação autônoma. Autoridades de certificação autônomas podem emitir certificados para finalidades diversas, tais como assinaturas digitais, correio eletrônico seguro usando S/MIME (extensões multipropósito do Internet Mail protegidas) e autenticação para um servidor Web seguro usando camada de soquetes de segurança (SSL) ou segurança da camada de transporte (TLS).
Uma autoridade de certificação autônoma tem as seguintes características:
? Diferentemente de uma autoridade de certificação corporativa, uma autoridade de certificação autônoma não exige o uso do Active Directory. Autoridades de certificação autônomas se destinam principalmente a serem usadas quando extranets e a Internet estão envolvidas. Por exemplo, se parceiros de negócios precisam se conectar a rede da empresa para acessar determinados sistemas, você pode criar uma autoridade certificadora autônoma, para emitir certificados para os parceiros de negócio. Estes, por sua vez, usarão estes certificados para se identificar e ter acesso a rede da empresa. Além disso, se desejar usar um módulo de diretiva personalizado para uma autoridade de certificação, você deve, primeiramente, instalar os serviços de certificados usando diretiva autônoma e, em seguida, substituir a diretiva autônoma pela sua diretiva personalizada.
? Ao submeter uma solicitação de certificado a uma autoridade de certificação autônoma, o solicitador do certificado deve fornecer, explicitamente, todas as informações de identificação sobre si mesmo e sobre o tipo de certificado desejado na solicitação do certificado. (Não é necessário fazer isso ao submeter uma solicitação a uma autoridade de certificação corporativa, uma vez que as informações do usuário corporativo já estão no Active Directory e o tipo do certificado é descrito por um modelo de certificado).
Por padrão, todas as solicitações de certificados enviadas para a autoridade de certificação autônoma são definidas como pendentes até que o administrador da autoridade de certificação autônoma verifique a identidade do solicitador e dê OK para a solicitação. Isso é feito por razões de segurança, porque as credenciais do solicitador do certificado não são verificadas pela autoridade de certificação autônoma.
? Não são usados modelos de certificados, a exemplo do que acontece com as autoridades certificadores corporativas.
? Nenhum certificado pode ser emitido para efetuar logon em um domínio do Windows 2000 Server ou do Windows Server 2003 usando cartões inteligentes, mas outros tipos de certificados podem ser emitidos e armazenados em um cartão inteligente.
? O administrador tem que distribuir, explicitamente, o certificado da autoridade de certificação autônoma para o armazenamento de raiz confiável dos usuários do domínio, ou os usuários devem executar essa tarefa sozinhos.
Quando uma autoridade de certificação autônoma usa o Active Directory, ela tem esses recursos adicionais:
? Se um membro do grupo de administradores de domínio ou um administrador com direito de gravação no Active Directory instalar uma autoridade de certificação raiz autônoma, ela será automaticamente adicionada ao armazenamento de certificados das autoridades de certificação raiz confiáveis, para todos os usuários e computadores do domínio. Por essa razão, ao instalar uma autoridade de certificação raiz autônoma em um domínio do Active Directory, você não deverá alterar a ação padrão da autoridade de certificação até receber solicitações de certificados (o que marca as solicitações como pendentes). Caso contrário, você terá uma autoridade de certificação raiz confiável que automaticamente emite certificados sem verificar a identidade do solicitador.
? Se uma autoridade de certificação autônoma for instalada por um membro do grupo de administradores de domínio do domínio pai de uma árvore na empresa, ou por um administrador com direito de gravação no Active Directory, a autoridade de certificação autônoma publicará os certificados e a lista de certificados revogados (CRL) no Active Directory.
Não esqueça: Conheça bem as diferenças entre os diferentes tipos de autoridades certificadores. Lembre-se que autoridades certificadoras corporativas são integradas com o Active Directory, utilizam modelos de certificados para a criação de novos certificados. Já as autoridades certificadoras autônomas não dependem do Active Directory e não utilizam modelos de certificados. A seguir um pequeno resumo sobre cada um dos quatro tipos, para você fixar bem sobre a função e as características de cada um dos tipos de autoridades certificadores:
1. Enterprise root CA – Autoridade certificadora corporativa root: Um único servidor pode ser configurado como Enterprise root CA em uma floresta de domínios de uma empresa. Este servidor ocupa o topo da hierarquia de autoridades certificadoras. Normalmente não é utilizado para emitir certificados para usuários ou computadores, mas sim para autoridades certificadores corporativas subordinadas. Os certificados para usuários e computadores são emitidos pelas autoridades subordinadas. Com isso você pode criar uma hierarquia de autoridades certificadoras, de tal maneira que a emissão de certificados seja efetuada por um servidor do próprio domínio do usuário. Outro detalhe importante é que a autoridade certificadora root é responsável por assinar o seu próprio certificado (afinal não há nenhuma autoridade acima dela). Isso é que caracteriza esta autoridade como uma autoridade certificadora root.
2. Enterprise subordinate CA – Autoridade certificadora Corporativa subordinada: Para instalar uma autoridade certificadora corporativa subordinada, você deve ter acesso ao certificado da autoridade certificadora corporativa root. O uso deste certificado é que liga a autoridade certificadora que está sendo instalada, como um autoridade subordinada a autoridade certificadora root, formando uma hierarquia de entidades certificadoras. Este tipo de autoridade pode emitir certificados para usuários e computadores do Active Directory ou para outras autoridades certificadores subordinadas de níveis mais baixo, aumentando desta maneira, o número de níveis da hierarquia de autoridades certificadoras.
3. Stand-alone root CA – Autoridade certificadora autônoma root: Este tipo de autoridade certificadora não depende do Active Directory. Pode ser utilizado, por exemplo, para emitir certificados para parceiros de negócio e prestadores de serviço, que precisam de certificados digitais para acessar determinadas áreas da Intranet ou da Extranet da empresa. Uma vantagem adicional é que um servidor configurado como autoridade certificadora autônoma root, pode ser desconectado da rede, como uma garantia adicional de segurança. Este tipo de autoridade certificadora também é responsável por emitir os certificados de registro das autoridades certificadoras autônomas subordinadas.
4. Stand-alone subordinate CA - Autoridade Certificadora Autônoma Subordinada: Este tipo de autoridade certificadora está subordinada a uma autoridade certificadora autônoma root. O processo normalmente é o mesmo utilizado para o caso das autoridades certificadoras corporativas, ou seja, a autoridade certificadora autônoma root não é utilizada para emissão de certificados para usuários e computadores, mas sim para a emissão de certificados para as autoridades certificadoras autônomas subordinadas. As autoridades certificadoras autônomas subordinadas é que são responsáveis pela emissão dos certificados para usuários e computadores.
Conclusão
Nesta parte do tutorial fiz uma breve apresentação sobre PKI, Certificados Digitais e Autoridades Certificadores. Você também aprendeu sobre a criptografia baseada no uso de um par de chaves: pública e privada e como utilizar o Microsoft Certificate Services para criar uma autoridade certificadora na própria rede da empresa.
Livros do autor:
