• Nenhum resultado encontrado

No final do parágrafo anterior eu descrevo o segundo problema com este método: ele não

No documento TUTORIALTCP-IP-Versãoparaimpressão (páginas 142-149)

permite a verificação da identidade de quem envio 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 ou, mais comum ainda, em um Smart Card. 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, dar acesso a 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 enviá-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 que será utilizada para

descriptografar os dados, 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. Os Certificados Digitais podem ser emitidos para uma série de funções, tais 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 quanto a sua autenticidade). 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 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 Services) 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 – Certificate 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 (incluindo aí uma série de documentos e comprovantes, os quais devem ser apresentados pelo solicitante do certificado) 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 Server ou do Windows Server 2003. 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, através da publicação de 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. Os clientes podem usar uma página 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 empresa 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, na Intranet da empresa. 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 e 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

No documento TUTORIALTCP-IP-Versãoparaimpressão (páginas 142-149)