Security WatchImplantando o EFS: Parte 1

John Morello

Todos já ouviram falar sobre relatórios de dados pessoais ou confidenciais perdidos devido ao furto e à perda de laptops. Laptops são perdidos regularmente. Com o roubo de identidade em crescimento e a conformidade a normas mais rígidas do que nunca, a proteção completa de dados em sistemas de computação móvel é essencial.

Uma resposta a isso é o uso de EFS (sistema de arquivos com criptografia) , incluído no Windows® desde o Windows 2000, que oferece criptografia interna de alto desempenho e baseada em disco. O EFS integra-se totalmente ao Windows Explorer, assim, o usuário final geralmente nem saberá quando um arquivo que está sendo usado é criptografado. Além disso, o EFS funciona igualmente bem com tecnologias nativas de autenticação e controle de acesso do Windows, de modo que o usuário final não precisa se lembrar de senhas distintas para acessar os próprios dados. Por fim, o EFS oferece opções gerenciáveis de recuperação de dados em casos onde o usuário pode perder o acesso às chaves de criptografia (por exemplo: quando um nome de usuário é excluído ou danificado ou o cartão inteligente do usuário é perdido).

O EFS usa a tecnologia de criptografia interna do Windows para gerar, armazenar e implantar chaves de criptografia fortes para proteção a dados. No Windows XP Service Pack 1 (SP1) e versões posteriores, o EFS utiliza o algoritmo EAS (Padrão Avançado de Criptografia) com uma chave de 256 bits para criptografar dados em disco. Essas chaves simétricas são então protegidas com um par de chaves assimétricas (RSA). O EFS criptografa cada arquivo com a chave AES; em seguida, criptografa essa chave com a chave RSA do usuário e armazena o resultado no arquivo. Para obter mais informações sobre criptografia EFS, consulte a barra lateral "EFS Resources" Por enquanto focarei não nas bases técnicas do EFS, mas em como implementá-lo e torná-lo viável em seu ambiente. Por esse motivo, o artigo supõe um conhecimento prévio dos conceitos de criptografia EFS.

Uma observação sobre segurança EFS

Existem alguns aplicativos que afirmam ser capazes de decifrar ou romper a criptografia EFS. Nenhum desses aplicativos verdadeiramente descriptografa o texto cifrado criptografado AES (ou o DES, Padrão de Criptografia de Dados, ou o DESX, Padrão de Criptografia de Dados); em vez disso, obtém acesso à chave particular EFS do usuário, usando “brute-forcing” (força bruta) para obter a senha do usuário. O importante a se ter em mente sobre criptografia EFS é que as chaves particulares usadas para gerar e proteger os dados criptografados utilizam a DPAPI (API de Proteção a Dados). A DPAPI usa derivados de credenciais de logon do usuário para proteger dados, assim, o resultado final é que a proteção a dados com o EFS iguala-se à proteção por senha do usuário. Com o Windows Vista™, você agora pode armazenar certificados de criptografia EFS em cartões inteligentes, o que altera esse paradigma e aumenta significativamente a segurança relativa de dados protegidos por EFS.

Qual deve ser o tamanho da senha para que ela seja resistente a esses ataques? Levando em consideração os recursos de hardware e os algoritmos modernos de ataque a senhas da atualidade, uma senha de 11 caracteres ou mais (ou, mais corretamente, uma passphrase (senha)) é o recomendado. Uma senha de 11 caracteres ou mais é altamente resistente aos métodos mais avançados da atualidade, incluindo ataques hash pré-calculados (como a Rainbow Table; consulte a postagem do blog "Why you shouldn't be using passwords of any kind on your Windows networks" (“Por que você não deve usar senhas de qualquer tipo em suas redes Windows”), listada na barra lateral "Recursos", para obter mais informações).

Optar por PKI ou não optar por PKI?

Um dos erros de concepção mais comuns sobre o EFS é que ele requer uma PKI (infra-estrutura de chave pública) para funcionar. Embora o EFS possa integrar-se facilmente e beneficiar-se de uma PKI no caso de a organização já possuir uma, ela não é um requisito. Assim, a decisão quanto a usar ou não uma PKI em sua implantação EFS terá impacto sobre muitas decisões de implantação futuras, portanto, deve ser analisada primeiramente.

A vantagem principal do uso de uma PKI com o EFS é a possibilidade de executar arquivamento e recuperação de chave. Enquanto o EFS sozinho permite aos administradores executar a recuperação de dados, a recuperação de chave só é possível com a PKI e, ainda assim, apenas quando o Windows Server® 2003 Enterprise Edition estiver sendo executado como sua autoridade de Certificação (CA). Recuperação de dados é o processo pelo qual o usuário que perde o acesso à chave de criptografia pode fornecer seus dados criptografados a um administrador designado, conhecido como DRA (Agente de recuperação de dados), que pode, em seguida, descriptografar esses dados e retorná-los ao usuário ou criptografá-los novamente para uso com uma nova chave de criptografia. O DRA funciona como uma sombra para o processo de criptografia do usuário, por meio da qual tudo o que o usuário criptografa com a própria chave é também criptografado com uma cópia da chave DRA. Assim, quando a chave do usuário é perdida, o DRA pode interferir, obter os dados de texto cifrado, aplicar a eles a chave DRA para descriptografia (ou nova criptografia) e, em seguida, retornar os dados ao usuário. A abordagem do DRA funciona bem, mas pode ser difícil de gerenciar se o usuário tiver grandes volumes de dados criptografados ou se não tiver uma equipe de TI local para atuar como DRAs.

A recuperação de chave, por outro lado, requer que a autoridade de certificação faça uma cópia da chave de criptografia do usuário durante o processo de criação da chave e armazene com segurança a cópia dessa chave no banco de dados da autoridade de certificação. Então, quando um usuário perde o acesso a arquivos criptografados, o administrador de autoridade de certificação só precisa recorrer a esse banco de dados e recuperar a chave do usuário. Nesse ponto, o usuário terá acesso imediato a seus dados novamente, sem precisar que o DRA os recupere em seu lugar. Quando feita dessa forma, a recuperação de chave pode ser mais ágil e mais eficiente. Observe, contudo, que a prática recomendada é sempre ter DRAs no local, mesmo quando usar a recuperação de chave, para oferecer um mecanismo de backup em caso de perda da chave. Isso também permite às grandes organizações contar com um sistema de recuperação distribuído, em que administradores de TI locais possam recuperar dados de usuários sem jamais ter que envolver o grupo de administradores de PKI.

Outro benefício potencial de se usar uma PKI com o EFS é facilitar o compartilhamento de arquivos criptografados. Lembre-se de que o EFS não se limita apenas a laptops; ele pode ser igualmente valioso em qualquer situação onde a segurança física do computador não possa ser garantida. Nessas situações, pode haver a necessidade de vários usuários acessarem os mesmos dados criptografados. Embora o suporte do Windows para compartilhamento de arquivos criptografados seja um tanto limitado porque só permite o compartilhamento de arquivos individuais e não de diretórios, ele pode ser uma ferramenta útil. Para facilitar o compartilhamento de arquivos do EFS, o usuário que compartilha o arquivo deve ter acesso às chaves públicas dos usuários com que ele estiver compartilhando (que será mais fácil se esses usuários tiverem um certificado EFS válido publicado na conta respectiva no Active Directory®). Embora seja possível executar essa publicação manualmente, o uso do Windows CA instalado no modo Empresa (integrado ao Active Directory) torna o processo totalmente automatizado.

Gerenciamento de chave EFS

Se você tiver uma PKI baseada no Windows Server 2003 disponível para uso, gerar certificados EFS de usuários será um processo simples. A autoridade de certificação do Windows Server 2003 vem com um conjunto padrão de modelos de certificado, incluindo um modelo chamado EFS básico. Entretanto, esse modelo é um modelo de versão 1 e não oferece suporte a arquivamento de chaves. Portanto, antes de disponibilizá-lo em sua autoridade de certificação, é aconselhável duplicar o modelo para criar um novo modelo de versão 2 (por exemplo, você poderia chamá-lo EFS com Arquivamento de chaves, como mostra a Figura 1). Nesse novo modelo, vá até a guia Tratamento de solicitação e selecione a opção para arquivar a chave de criptografia do usuário. Observe que você precisará configurar o arquivamento de chaves corretamente na autoridade de certificação antes de habilitar essa opção. A seção de recursos inclui uma excelente orientação do processo. Você também deve configurar esse modelo para substituir o modelo EFS básico, a título de garantir que os clientes usarão a nova versão (consulte a Figura 2).

Figura 1** EFS com arquivamento de chaves **(Clique na imagem para aumentar a exibição)

Figura 2** Substituir o modelo EFS básico **(Clique na imagem para aumentar a exibição)

Em seguida, você precisará configurar as permissões adequadas no modelo, para permitir que o conjunto certo de usuários tenha acesso de registro a ele. Como o componente EFS no Windows solicita automaticamente um certificado na primeira vez que o EFS é usado, você geralmente não precisa permitir que usuários registrem-se automaticamente em relação ao modelo EFS. Na verdade, eu recomendaria contra permitir o registro automático para certificados EFS, a menos que você esteja certo de que todos os usuários registrados automaticamente estarão utilizando o EFS. A Figura 3 mostra as configurações de registro do EFS. Emitindo certificados para usuários que talvez nunca usem o EFS, você estará aumentando o tamanho do seu banco de dados da autoridade de certificação sem nenhum benefício. Embora o banco de dados da autoridade de certificação em si não tenha limite de tamanho, pode ser mais difícil gerenciá-lo (especialmente por meio do Console de gerenciamento Microsoft, ou MMC) quando você aumenta o número de certificados emitidos.

Figura 3** Configurando permissões de usuário do EFS **(Clique na imagem para aumentar a exibição)

Por fim, se você precisar dar suporte ao compartilhamento de arquivos criptografados, pode ser conveniente fazer com que a autoridade de certificação publique o certificado do usuário automaticamente no Active Directory.

Após configurar o modelo corretamente na autoridade de certificação, na primeira vez que o usuário criptografar um arquivo com o EFS, ele obterá o certificado de sua autoridade de certificação, e ela arquivará a chave particular desse usuário automaticamente.

Gerenciamento de chave DRA

A próxima questão a considerar se você tiver uma PKI em vigor é usar ou não os certificados DRA gerados pela autoridade de certificação. Por que você não desejaria usar certificados DRA em sua PKI? Considere um cenário onde se tem uma autoridade de certificação emissora com um período de validade de certificado bem pequeno (dois anos ou menos). A autoridade de certificação não será capaz de emitir nenhum certificado com tempos de vida útil mais longos do que o próprio, ou seja, seus certificados DRA teriam (no máximo) um tempo de vida de dois anos. Isso pode resultar em um cenário de recuperação de dados significativamente mais complexo. Esse exemplo hipotético é ilustrado no cenário a seguir.

1. O usuário criptografa um arquivo em janeiro de 2006; os certificados DRA enviados ao computador desse usuário por meio da Diretiva de Grupo têm um intervalo de tempo de dois anos (expiram em janeiro de 2008).
2. O usuário continua a trabalhar com o EFS, criptografando novos arquivos.
3. Em janeiro de 2008 os certificados DRA vencem e o administrador envia novos certificados por meio da Diretiva de Grupo.
4. Qualquer operação de criptografia desse ponto em diante usará os novos certificados DRA (incluindo qualquer arquivo aberto que era criptografado com os DRAs antigos; uma vez salvos, eles usarão os novos DRAs), mas qualquer arquivo que o usuário não mais alterar ainda estará protegido apenas pelos DRAs antigos.
5. O usuário danifica o próprio perfil acidentalmente e precisa da recuperação de dados.
6. O administrador de TI agora precisará dispor de dois conjuntos de certificados DRA: os novos, para todo arquivo alterado desde a Etapa 3, e o antigo, para todo arquivo que não tenha sido alterado desde então.

Embora seja possível para o administrador de TI executar um script após a Etapa 3 para atualizar todos os arquivos com o novo DRA (usando o cipher.exe /u), esse processo pode ser demorado. Além disso, a título de esclarecimento, os pares de chaves DRA não se tornam inúteis após atingirem a data de vencimento, embora o componente EFS não permita nenhuma nova operação de criptografia se um certificado DRA vencido estiver incluído na diretiva de recuperação. É claro que arquivos antigos criptografados com pares de chaves DRA vencidos ainda podem ser recuperados por eles. Portanto, pares de chaves DRA não devem ser descartados nunca, mesmo depois do vencimento do respectivo tempo de vida útil; a verdade é que você não sabe quando precisará utilizá-los.

Por esses motivos, recomendamos que ambientes com autoridades de certificação que dispõem de tempos de vida curtos de certificado empreguem certificados DRA auto-assinados, com tempos de vida mais longos. O utilitário de codificação inclui uma opção (cipher.exe /r) que cria automaticamente pares de chaves do agente de recuperação do EFS, com um tempo de vida de 100 anos (consulte a Figura 4). O certificado desse par de chaves pode então ser anexado aos GPOs (Objetos de Diretiva de Grupo) e usado como um DRA em toda a organização. Como o componente EFS não verifica a cadeia de confiança de certificados DRA, esses certificados auto-assinados funcionarão sem precisar fazer nenhuma alteração à lista de Autoridades de Certificação de raiz confiáveis nos sistemas. Independentemente do tempo de vida da autoridade de certificação de uma organização, sempre recomendo criar pelo menos um certificado DRA de vida longa útil e anexá-lo a um GPO por todo o domínio. Essa é a opção de recuperação de dados fallback a ser usada caso todas as demais opções falhem. Ela é especialmente vital se você estiver usando chaves DRA geradas pela autoridade de certificação na ausência de um arquivamento de chaves de autoridade de certificação. Na ocorrência de um certificado DRA comprometido, você poderá atualizar o GPO com um novo certificado e usar a opção cipher.exe/u, mencionada anteriormente, para atualizar seus arquivos.

Figura 4** Executando o Ciquer /R **(Clique na imagem para aumentar a exibição)

Recurso EFS

Obtenha mais informações sobre particularidades e práticas recomendadas do EFS visitando os sites a seguir:

• Why you shouldn’t be using passwords of any kind on your Windows networks
• Implementing Key Archival Walkthrough
• Encrypting File System in Windows XP and Windows Server 2003

Implantação de KRA e DRA

O arquivamento de chaves oferece aos administradores da autoridade de certificação a capacidade de recuperar chaves de criptografia caucionadas em nome do usuário. Obviamente, trata-se de um recurso muito confidencial e eficiente, porque pode permitir que um administrador de autoridade de certificação descriptografe qualquer dado que utilize uma chave assinada pela autoridade de certificação na organização. O arquivamento e a recuperação de chave, portanto, devem ser tratados com cuidado e apenas um pequeno número de pessoas confiáveis ligadas à segurança devem receber essa permissão. Em razão da natureza confidencial da recuperação de chave, se você desejar contar com esse recurso como o mecanismo principal de reobtenção de acesso a dados criptografados por EFS, é importante ter um processo de escalonamento claramente definido para que solicitações de recuperação sejam enviadas à sua equipe de administração da autoridade de certificação. Só depois que a solicitação tiver sido cuidadosamente verificada o processo de recuperação será iniciado. Então, após a chave ser recuperada efetivamente, ela deverá ser fornecida ao usuário, por um método seguro (ou seja, não por email), porque a chave recuperada oferece acesso a todos os dados protegidos por EFS do usuário.

As chaves do Agente de Recuperação de Chave ou KRA são geradas e mantidas pelos administradores da autoridade de certificação e não são divulgadas pela Diretiva de Grupo. Na verdade, o próprio EFS não pode determinar se uma chave que ele utiliza foi ou não arquivada; ele simplesmente executa as operações de criptografia, como normalmente o faria. Além disso, as chaves KRA criadas na autoridade de certificação não são específicas de forma nenhuma do EFS. Uma autoridade de certificação que use o arquivamento de chaves terá um número n de chaves KRA anexadas no nível da autoridade de certificação que serão usadas para proteger qualquer chave arquivada pela autoridade de certificação. Essas chaves podem incluir as chaves usadas com o EFS, email seguro ou qualquer outra finalidade de certificado que inclua criptografia. As chaves do KRA devem ser armazenadas de modo seguro pelos agentes de recuperação de chave individuais, e deve haver pelo menos dois KRAs usados para fornecer fallback em caso de perda de uma das chaves.

Na primeira vez que um administrador fizer logon no controlador de domínio de um domínio recém-criado, uma diretiva de recuperação padrão será criada no nível do domínio, usando um certificado auto-assinado e um par de chaves armazenado no perfil do administrador, no controlador de domínio. Esse certificado DRA terá um tempo de vida útil de três anos. A abordagem recomendada é remover esse certificado padrão e substituí-lo por certificados auto-assinados com vida útil mais longa ou certificados emitidos em sua PKI. Se você não remover esse certificado auto-assinado padrão, três anos após a criação dele o EFS deixará de criptografar novos arquivos em todo o seu domínio. Isso ocorre porque o certificado terá vencido e o EFS impedirá a criptografia de todos os dados posteriores quando um certificado DRA for incluído em sua diretiva de recuperação. Embora seja possível operar o Windows XP e sistemas posteriores sem nenhuma diretiva de agente de recuperação em vigor, isso é altamente desencorajado. Fazer isso significa que, se o usuário perder o acesso à chave de criptografia por algum motivo e a recuperação de chave não for possível, todos os dados desse usuário serão irremediavelmente perdidos.

Conforme dissemos anteriormente, chaves DRA podem ser auto-assinadas ou emitidas de uma autoridade de certificação. Na maioria dos casos, uma abordagem híbrida é melhor, com pelo menos dois DRAs de vida útil longa e auto-assinados, usados em toda a empresa como um agente de recuperação de último recurso. Como os certificados DRA são implementados por meio dos Objetos de Diretiva de Grupo, eles possuem os mesmos recursos de herança de outros GPOs. Em outras palavras, o algoritmo de acumulação e aplicativo padrão de GPO Local, de Site, Domínio e UO que controla o aplicativo de outras configurações do GPO também se aplica aos DRAs. Portanto, uma organização pode implementar facilmente uma abordagem em camadas, onde o grupo de TI central tenha acesso ao DRA em qualquer lugar da empresa, mas onde grupos de TI locais também mantenham a capacidade nas respectivas áreas específicas de responsabilidade. Trata-se de um ativo especialmente valioso em organizações de grande porte e dispersas geograficamente, porque minimiza a necessidade de transferir grandes volumes de dados criptografados por links WAN, para facilitar a recuperação de dados. A Figura 5 ilustra uma implantação DRA típica com várias camadas.

Figura 5** Implantação DRA em várias camadas **

Neste caso, um usuário da UO Baton Rouge acabaria com seis DRAs para cada arquivo criptografado: dois dos administradores locais, dois do grupo de TI da América do Norte e dois do nível do domínio. Assim, se o usuário perdesse o acesso aos dados criptografados, ele poderia recuperá-los em um DRA local no Baton Rouge ou no grupo de TI da América do Norte. Como fallback final, se esses quatro DRAs estivessem indisponíveis ou fossem perdidos, os DRAs no nível do domínio poderiam igualmente assumir e recuperar os dados. Independentemente do DRA que executou a recuperação, o processo seria essencialmente o mesmo. O usuário primeiramente disponibilizaria os dados para o DRA. É importante que o DRA cumpra as etapas necessárias para garantir que a solicitação é legítima e se origine do verdadeiro proprietário dos dados. Uma vez feito isso, o DRA carregaria o certificado DRA, descriptografaria os dados (e, de preferência, faria uma nova criptografia) e, em seguida, os enviaria de volta ao usuário final. Algumas organizações também optam por executar a recuperação local, em que o DRA visitaria fisicamente o usuário com problema, carregaria o par de chaves DRA desse usuário no perfil e, então, descriptografaria os dados e removeria o par de chaves. O usuário teria então acesso aos dados em formato não criptografado e poderia criptografá-los novamente, com uma nova chave. Deve-se observar que essa abordagem é muito menos segura, pois o par de chaves DRA é copiado (embora temporariamente) no computador local; apesar disso, pode economizar algum tempo, especialmente se um grande volume de dados deve ser recuperado.

Observe que, se a recuperação fosse fornecida ao usuário por meio de arquivamento e da recuperação de chave, a solicitação de recuperação seria manipulada inteiramente à parte desse processo. Em vez de usar o DRA, a solicitação de recuperação de chave do usuário iria para os administradores da autoridade de certificação, que deve verificar a solicitação; em seguida, iria para o arquivamento e recuperaria a chave particular do usuário. Eles então disponibilizariam essa chave particular para o usuário, de maneira segura, como, por exemplo, colocando-a em um site seguro para ser obtida por download. (Se o usuário estivesse se beneficiando de um cartão inteligente para armazenar a chave EFS, disponível com o Windows Vista, essa chave também precisaria ser emitida novamente). O usuário carregaria a chave no perfil respectivo e, em seguida, teria acesso imediato a todos os dados criptografados.

Como os pares de chaves DRA e KRA podem ser usados para descriptografar dados confidenciais, é importante que eles sejam bem protegidos. Os pares de chaves DRA e KRA não devem ser armazenados nos perfis de área de trabalho normal de administradores (perfis em que eles executam as respectivas atividades diárias normais). Em vez disso, esses pares de chaves devem ser armazenados de maneira segura, offline, em mídia tipo disquete, ótica ou flash, mantida em um local fisicamente seguro. Quando então a recuperação se fizer necessária, o agente de recuperação poderá carregar o par de chaves em uma estação de trabalho de recuperação a partir dessa mídia, executar a operação de recuperação e, em seguida, remover o par de chaves. Em algumas organizações especialmente sensíveis à segurança, são criadas estações de trabalho dedicadas de recuperação, para aumentar ainda mais a segurança desses pares de chaves. Isso, no entanto, não é um requisito de todas as organizações.

Da próxima vez

Agora que examinamos o gerenciamento de chave, a recuperação de dados e os aspectos do Active Directory relacionados ao planejamento, focarei nas questões de implantação do cliente, na Parte 2 deste tópico, a ser liberada no próximo mês. Na ocasião, abordarei tópicos como o controle de uso do EFS por meio de Diretiva de Grupo, a escolha do que criptografar, a criptografia automática de dados através de scripts de logon e os aprimoramentos do lado do cliente no Windows Explorer, para tornar mais fácil o trabalho de dados protegidos por EFS.

John Morello graduou-se com louvor na LSU (Universidade do Estado da Louisiana) e trabalha na Microsoft há seis anos, em várias funções. Na condição de consultor sênior, Morello criou soluções de segurança para as empresas da Fortune 100 e clientes civis federais e da defesa. Atualmente, ele é gerente de programa do grupo Windows Server e trabalha em segurança e tecnologias de acesso remoto.

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