Tutorial de TCP/IP – Parte 19 – Certificados Digitais e Segurança

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
em uma PKI.

Nes
ta parte do tutorial você entenderá o que vem a ser uma PKI, aprenderá sobre os conceitos básicos de uso de um par de chaves para fazer a criptografia e proteção dos dados. Também mostrarei qual o papel do Microsoft Certification Service, que é o servidor da Microsoft para a emissão e controle de certificados digitais, serviço este disponível no Windows 2000 Server e também no Windows Server 2003. Com o uso do Microsoft Certificate Services, a empresa pode montar a sua própria infraestrutura de certificados digitais, sem depender de uma autoridade certificadora externa.

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
em Certificados Digitais.

Microsoft Certificate
Services e PKI

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 em pauta. De tempos em tempos um novo v√≠rus causa p√Ęnico na Internet, novos tipos de ataques s√£o notificados, sites ficam indispon√≠veis devido a ataques de hackers, problemas com a seguran√ßa no acesso a dados que facilitam a vida de fraudadores e por a√≠ vai.

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: