Security WatchImplantando o EFS: Parte 2

John Morello

Você pode considerar uma implantação do EFS (Sistema de Arquivos com Criptografia) como tendo essencialmente duas partes: a parte de design de back-end cujo foco está no gerenciamento de certificados e nos agentes de recuperação e a parte de implantação do EFS voltada para o usuário. No mês passado, discuti a parte de back-end e as opções para recuperação de dados e chaves,

bem como as opções para a provisão de certificados para os clientes. Agora, pretendo me concentrar nos aspectos da implantação que serão vistos pelos usuários finais, como os aprimoramentos no Windows® Explorer, a escolha dos locais do sistema de arquivos que serão criptografados e como gerenciar as opções de criptografia com a Diretiva de Grupo.

Determinando se o EFS já está em uso

Depois de optar pela implantação do EFS, a primeira etapa é determinar o estado atual do uso do EFS na sua organização. Lembre-se de que o EFS pode ser usado no modo autônimo, no qual o usuário final é unicamente responsável pela criação e pelo backup dessas chaves de criptografia. Talvez existam usuários avançados na sua organização que já tenham usado o EFS dessa maneira e, portanto, é importante determinar quem são eles de forma a garantir uma transição uniforme e fluente para uma implantação mais gerenciada.

Quando o EFS é implantado pela primeira vez por um determinado usuário em um computador, o Windows cria a seguinte entrada de registro em HKEY_CURRENT_USER:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash 

O Microsoft® SMS (Systems Management Server), os scripts de logon do Active Directory ou outras ferramentas podem ser usadas para verificar a presença dessa entrada em máquinas na sua empresa. Se um usuário tiver esse valor de registro presente, significa que ele usou o EFS em um determinado ponto. Entretanto, esse valor não indica necessariamente que alguém esteja atualmente usando o EFS ou que qualquer um de seus dados esteja criptografado. Portanto, quando uma máquina é encontrada com esse valor de registro, ela deve ser mais rigorosamente examinada para determinar se existem arquivos criptografados.

O uso de cipher.exe e a transmissão das opções /U e /N fornecerá instruções para que a codificação relate o estado de criptografia de arquivos e diretórios em um computador. Por exemplo, se você quiser determinar se os dados em um sistema estão criptografados, basta executar o seguinte comando:

cipher /U /N

A verificação do registro e o relatório de codificação podem ser combinados em um único script de forma a verificar a presença do valor do registro e, se presente, para gerar um relatório dos arquivos atualmente criptografados no computador. Após a geração desses relatórios, você saberá quais usuários têm quais arquivos criptografados e estará pronto para migrá-los até um design centralmente gerenciado.

Para controlar o aplicativo de Diretiva de Grupo durante a implantação, é útil criar dois grupos de segurança no seu domínio de forma a separar os computadores nos quais o EFS está em uso dos computadores nos quais o EFS não está em uso. Por exemplo, "SG-ComputersUsingEFS" conteria as contas de computador dos computadores nos quais o EFS já está em uso, enquanto "SG-ComputersNotUsingEFS" conteria todas as outras máquinas nas quais o EFS ainda não está em uso.

Controlando o uso do EFS com a Diretiva de Grupo

Depois que você souber quem está e não está usando o EFS, a próxima etapa na implantação do cliente será desabilitar o uso do EFS autônomo para qualquer usuário que não o esteja utilizando. Essa etapa é importante no processo de implantação porque é mais fácil habilitar e configurar o EFS corretamente na primeira vez do que migrar os usuários que estão usando certificados auto-assinados. Você apenas deve realizar essa etapa depois de determinar quais usuários já estão usando o EFS, porque, ao desabilitar o EFS por meio da Diretiva de Grupo, os usuários não serão capazes de acessar nenhum arquivo que esteja atualmente criptografado. Essa diretiva pode ser encontrada no Editor de Objetos de Diretivas de Grupos, em Configuração do Computador\Configurações do Windows\Configurações de Segurança\Diretivas de Chave Pública/Sistema de Arquivos com Criptografia.

Conforme mencionado anteriormente, esse valor deve apenas ser habilitado em computadores no qual o EFS não esteja em uso, para não prejudicar o trabalho de um usuário que já esteja usando o EFS. Portanto, no meu exemplo, a ACL (lista de controle de acesso) no GPO (objeto de diretiva de grupo) que desabilita o EFS permite apenas que o grupo "SG-ComputersNotUsingEFS" aplique a Diretiva de Grupo.

Criptografar ou não criptografar

Depois de determinar quais sistemas estão atualmente usando o EFS e depois de ter desabilitado o EFS em todos os outros sistemas até o gerenciamento da implantação, a próxima etapa é determinar o que será criptografado nessa implantação gerenciada. Dependendo de como os sistemas clientes são gerenciados, esse processo pode variar desde simplista até bem complexo.

A primeira coisa a considerar ao cogitar os arquivos que devem ser criptografados é se os usuários são ou não administradores em seus sistemas. Se os usuários forem administradores locais, você de fato apenas poderá instruí-los e incentivá-los a criptografar os dados confidenciais, mas não poderá realmente controlar esses dados de maneira administrada. A razão disso é simples: um administrador local pode criar arquivos e diretórios em qualquer local no sistema de arquivos. Portanto, embora você possa criptografar os locais comuns, como Meus Documentos, se o usuário criar um novo diretório em outro local e salvar informações confidenciais, será difícil garantir que esses dados também ficarão protegidos. Além de todos os outros benefícios de segurança obtidos quando os usuários finais não são administradores locais, isso também torna o EFS bem mais gerenciável e seguro.

A próxima informação essencial que devemos lembrar sobre o EFS é que ele consiste em um sistema de criptografia por usuário. Em outras palavras, tudo o que for criptografado por um determinado usuário apenas poderá ser descriptografado pelo mesmo usuário e por mais ninguém, incluindo a conta SYSTEM (com a óbvia exceção do Agente de recuperação de dados, ou DRA). Isso significa que, se um executável ou uma DLL for criptografado com a chave de um usuário e outra entidade de segurança no sistema tentar acessá-lo, essa outra entidade de segurança receberá um erro de acesso negado. Dessa forma, em geral, você não deve criptografar arquivos ou diretórios que incluam um código executável que talvez precise ser executado por várias entidades de segurança em um sistema. O Windows impedirá a criptografia de arquivos em %SystemRoot% ou arquivos que contenham o atributo SYSTEM, mas não é incomum que alguns fornecedores de software instalem binários em %ProgramFiles% referentes a serviços que podem ser executados pela conta SYSTEM. Por exemplo, essa é uma abordagem comum que os fornecedores de laptop podem usar ao instalar softwares de gerenciamento de energia e dispositivos que são executados como um serviço.

Com esses dois fatos em mente, quais são as melhores práticas para alvos de criptografia do EFS? A resposta remonta para como os sistemas dos usuários são normalmente configurados. Em um ambiente bem gerenciado com uma imagem de sistema operacional padronizada, você provavelmente poderá automatizar o processo de criptografia para os usuários com base nos locais de armazenamento de dados pré-determinados a partir da sua imagem. Por exemplo, se os usuários apenas puderem salvar dados em %userprofile%\Meus Documentos, apenas será necessário criptografar esse diretório. (Observação: preste atenção ao criptografar Meus Documentos se usar a redirecionamento de pastas. Se Meus Documentos for redirecionado para um servidor, esse servidor precisará ser Confiável para Delegação e ter acesso ao perfil do usuário. Nesses casos, é geralmente mais fácil apenas criptografar o cache de Arquivos Offline, o que discutiremos mais tarde nesta coluna.)

Em um ambiente menos gerenciado (no qual os usuários podem gravar em vários locais do sistema de arquivos), é possível usar a abordagem de automatizar a criptografia de alguns locais de armazenamento comuns e depois de instruir os usuários a criptografar outros locais por conta própria. Independentemente do seu ambiente, você deve sempre criptografar em nível de diretório em vez de em nível de arquivo. Isso faz com que todos os arquivos criados nesse diretório, incluindo os temporários, sempre sejam criptografados.

Locais de criptografia recomendados

Como regra geral, os locais em que você deve criptografar normalmente são: %userprofile%\Meus Documentos, %userprofile%\Application Data\Microsoft\Outlook (supondo que você esteja usando o Microsoft Office Outlook® como cliente de mensagens) e %userprofile%\Desktop. Criptografar Meus Documentos protege o local padrão para arquivos salvos no Windows XP. A proteção do diretório do Outlook garante que os emails com conteúdo sensível armazenados localmente em cache também sejam criptografados, o que é particularmente importante para usuários que executam o Modo em Cache padrão do Outlook 2003 . Por fim, a área de trabalho costuma ser usada como um tipo de diretório temporário no qual os usuários podem inserir documentos atuais de trabalho ou apresentações dadas com freqüência. É claro que, na sua organização, você pode ter modificado os locais padrão de alguns desses diretórios e, portanto, as suas opções de criptografia do EFS deverão refletir os locais que são normalmente usados na organização.

Além dessas práticas gerais, você também deve determinar se existem aplicativos que possam salvar informações sensíveis em locais alternativos. Por exemplo, alguns aplicativos salvar informações do usuário em %ProgramFiles%\AppName em vez de no perfil do usuário. É importante determinar se os seus sistemas de clientes possuem esses aplicativos, para que você possa proteger adequadamente todos os dados utilizados. No cenário mais favorável, o aplicativo poderia ser configurado para salvar alterações em outro caminho específico para o perfil de usuário (como Meus Documentos), no qual nenhuma alteração adicional do EFS fosse necessária. Em um cenário mais desfavorável, se o aplicativo exigir que os dados sejam armazenados no diretório Arquivos de Programas, o EFS poderia ser usado para criptografar apenas o subdiretório específico de Arquivos de Programas.

Por fim, tome cuidado se você planeja criptografar o diretório temporário (%TMP% e %TEMP%). Muitos instaladores de aplicativos usam esse diretório para a expansão do conteúdo de pacotes de instalação e, depois, realizam operações de movimentação de arquivos nos arquivos expandidos para inseri-los no caminho apropriado de %ProgramFiles%. Como um arquivo movido no mesmo volume mantém seus atributos originais, o arquivo continuará a ser criptografado depois de ser inserido em %ProgramFiles%. Dessa forma, se um usuário diferente do que executa o instalador tentar usar esse arquivo, seu acesso a ele será negado. Muitas vezes, esses problemas não se manifestam em mensagens de erro de aplicativo evidentes que indicam a causa básica. Por causa disso, geralmente recomendo que %TMP% apenas seja criptografado em ambientes bem-gerenciado em que os usuários finais não instalam aplicativos por conta própria.

Protegendo arquivos offline

Arquivos offline são um recurso do Windows 2000 e posterior que permite aos usuários finais fazer uma cópia local dos dados armazenados em um servidor de arquivos. Dessa forma, esse recurso permite ao usuário trabalhar nesses dados enquanto estiver desconectado do servidor e sincronizar as alterações de volta ao servidor quando estiver conectado. Entretanto, o recurso Arquivos Offline não consiste em um diretório simples contendo cópias de arquivos do servidor. Trata-se de um banco de dados compartilhado em todo o sistema e que é executado no contexto da conta SYSTEM. No Windows XP, esse banco de dados pode ser protegido com o EFS. Considere o que isso significa tendo como base a discussão anterior sobre o fato que o EFS é específico para cada usuário. Como pode o EFS, que é específico para cada usuário, criptografar um banco de dados usado por várias entidades de segurança?

Quando um usuário que executa o Windows XP escolhe a opção no Windows Explorer para criptografar arquivos offline, a rotina de criptografia utilizada é diferente da usada para as outras operações de criptografia que o usuário pode iniciar. Em vez de utilizar o par de chaves pessoal do usuário para o processo do EFS (que impediria o acesso de SYSTEM aos arquivos), a conta SYSTEM gera automaticamente um par de chaves para uso com o EFS e usa esse par de chaves para criptografar o cache no lado do cliente. Isso apresenta uma crítica implicação de segurança já que, se alguém puder obter subseqüentemente o código para execução como SYSTEM, poderá descriptografar os dados no cache. Se um laptop for roubado, é comum que um atacante redefina a senha do administrador e faça logon como administrador. Após a execução como administrador, é correspondentemente muito simples forçar a execução do código como SYSTEM e então acessar o cache. (Observe que esse comportamento foi alterado no Windows Vista™. Agora, o Windows Vista usa a chave individual do usuário para criptografar Arquivos Offline específicos para cada usuário.)

Para proteger contra esse tipo de ataque, o laptop pode ser configurado para armazenar a chave de criptografia do banco de dados SAM (Gerenciamento de Contas de Segurança) offline, seja como uma entrada de senha no momento da inicialização (modo 2) ou em um disquete durante o processo de inicialização (modo 3). Ambas as abordagens podem ser excessivamente trabalhosas, já que exigem uma interação não automatizável com o computador durante o processo de inicialização, criando problemas potenciais com o gerenciamento de sistemas automatizados. Entretanto, se o EFS for ser usado em um computador com Arquivos Offline, é essencial que uma dessas opções seja usada para proteger os dados no cache. Eu costumo recomendar o uso da senha no momento da inicialização (consulte a Figura 1). O motivo para isso é que, se a maleta para laptop de um usuário for roubada, o disquete provavelmente já estará inserido no laptop ou então estará quase certamente na maleta junto com o laptop.

Figure 1** Automate EFS operations **

Habilitando o EFS

Depois de determinar o que criptografar no cliente, a próxima etapa consiste em realizar a operação de criptografia propriamente dita. Esse processo pode ser obtido por meio de um script de logon ou outro processo que executará um script no cliente que chama cipher.exe para realizar a operação de criptografia. Se você tiver usuários autônomos existentes do EFS no seu ambiente, conforme discutido no exemplo anterior, recomendo a migração desses usuários primeiro.

Para migrar esses usuários autônomos, a primeira etapa é fornecer certificados gerenciados aos sistemas de clientes, conforme discutido no fascículo de fevereiro de 2007 desta coluna (microsoft.com/technet/technetmag/issues/2007/02/SecurityWatch). Após a inscrição de todos os sistemas para obtenção desses certificados gerenciados, cipher deverá ser executado com a opção /U para atualizar todos os arquivos existentes com as novas chaves de agente de recuperação e de criptografia. Nesse ponto, todos os sistemas no grupo SG-ComputersUsingEFS estariam utilizando o EFS de forma gerenciada, incluindo chaves centralmente emitidas (e potencialmente arquivadas) e agentes de recuperação centralmente gerenciados.

Para implantar o EFS para usuários que não utilizam o EFS no momento, primeiro você deve remover a Diretiva de Grupo que impede o uso do EFS. Quando esse procedimento estiver concluído e os usuários estiverem inscritos para certificados gerenciados, um script de logon poderá ser executado para criptografar os caminhos de chaves discutidos anteriormente. Este é um exemplo de script bem simples:

cipher /e /s /a "%userprofile%\My Documents"

cipher /e /s /a "%userprofile%\Application Data\Microsoft\Outlook"

cipher /e /s /a "%userprofile%\Desktop"

Depois de habilitar o EFS nos diretórios desejados, considere a definição de duas opções adicionais para aumentar a segurança da implantação do EFS, ambas relacionadas aos dados paginados da memória para o disco. Observe que, para cada um desses cenários, a quantidade de dados que pode ser recuperada por um usuário com más intenções está limitada ao que foi carregado na memória ou paginado em disco durante o uso legítimo. Em outras palavras, se um usuário tiver dados sensíveis protegidos pelo EFS na máquina e não tiver visualizado esses dados (e, portanto, não os tiver carregado na memória), eles não serão um risco em casos de ataques.

O arquivo de página é usado pelo Windows como memória virtual (muitas vezes indicada como espaço de troca em outros sistemas operacionais) e contém seções brutas de dados na memória gravados em texto simples na unidade de disco rígido. Isso pode colocar em risco os dados sensíveis em um sistema protegido pelo EFS, já que, se um atacante for capaz de recuperar o arquivo de página, poderá potencialmente utilizar ferramentas de laboratório para extrair dados usáveis desse arquivo. Como o arquivo de página propriamente dito não pode ser criptografado no Windows XP (observe que ele pode ser criptografado no Windows Vista), a melhor opção será forçar o Windows a apagá-lo quando o sistema for desligado. Isso pode ser feito por meio da Diretiva de Grupo, conforme ilustrado na Figura 2.

Figure 2** Setting group policy **(Clique na imagem para aumentar a exibição)

A desvantagem dessa configuração é o aumento significativo do tempo necessário para desligar uma máquina, particularmente se ela tiver muita memória. (Por padrão, o tamanho do arquivo de página está diretamente relacionado à quantidade de memória física no computador.) Isso porque, para apagar o arquivo de página, o Windows deve gravar fisicamente em cada página da unidade de disco antes do desligamento.

A hibernação do arquivo no Windows contém um despejo da memória física da máquina quando o modo de gerenciamento de energia está definido de forma a habilitar a hibernação. Quando a hibernação ocorre, o Windows grava todo o conteúdo da memória física em disco no arquivo de hibernação, permitindo que o computador seja restaurado exatamente para o mesmo estado no momento em que o usuário estiver pronto para continuar a trabalhar. Como o arquivo de página, o arquivo de hibernação não pode ser criptografado no Windows XP. Entretanto, ao contrário do arquivo de página, a hibernação não pode ser diretamente desabilitada a partir de um GPO. Em vez disso, você deve usar um script para chamar powercfg.exe com a opção /HIBERNATE de forma a desabilitar (ou reabilitar) a hibernação.

Depois de concluir as tarefas iniciais de criptografia e configuração, considere a limpeza do espaço de lacuna nos discos da sua implantação. Esse processo pode causar interrupções e exigir bastante tempo, mas apresenta o benefício da segurança em ambientes de alta segurança. O espaço de lacuna é a área de um disco não contém dados atualmente ativos no sistema, mas que, devido ao modo de operação dos discos rígidos, pode conter algumas informações sensíveis de arquivos anteriormente usados. Em outras palavras, como uma operação de exclusão de arquivo não substitui na prática todos os setores ocupados por um arquivo no disco (apenas remove o ponteiro da tabela de arquivos), os dados excluídos podem continuar a existir no disco. Nesses casos, esses dados podem ser recuperados por ferramentas de laboratório capazes de ler esse espaço de lacuna e remontar os arquivos a partir dele. Para limpar seguramente esses dados residuais, execute cipher com a opção /W. Isso força cipher a substituir repetidamente todos os setores marcados como disponíveis no disco. Desde que todas as operações futuras de arquivos em dados sensíveis ocorram em diretórios protegidos pelo EFS, não será necessário executar esse comando regularmente.

Aprimorando o Windows Explorer para o EFS

Por padrão, as opções de criptografia e descriptografia para arquivos e diretórios estão de certa forma arraigadas nos menus de propriedades avançadas do Windows Explorer. É possível optar por aprimorar essas experiência do usuário com o EFS, colocando as opções "Criptografar" e "Descriptografar" no menu de contexto do Windows Explorer (exibido após um clique com o botão direito do mouse). Além disso, o Windows Explorer pode ser configurado para mostrar arquivos e diretórios protegidos pelo EFS com uma cor diferente (verde) dos outros arquivos. Isso pode ajudar os usuários a saber se um arquivo ou diretório está criptografado sem ter que fazer busca detalhada no menu de propriedades avançadas. Por fim, você pode adicionar uma opção para definir quais usuários têm acesso ao arquivo ou diretório. Para habilitar essas opções, faça as seguintes alterações no Registro através de um script que chama o reg.exe:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"EncryptionContextMenu"=dword:00000001

"ShowCompColor"=dword:00000001

[HKEY_CLASSES_ROOT\*\Shell\Encrypt To User...\Command]  
@="rundll32 efsadu.dll,AddUserToObject %1"

EFS no Windows Vista

O EFS passou por uma série de importantes melhorias no Windows Vista que o tornam mais fácil de implantar e gerenciar, além de aumentarem sua segurança. Entre essas melhorias, a principal consiste no suporte completo para o armazenamento de chaves EFS em cartões inteligentes. Trata-se de um recurso especialmente importante para operações que já utilizam o logon via cartão inteligente, pois o mesmo cartão também pode ser usado para armazenar as chaves EFS dos usuários. Esse suporte para cartões inteligentes também se estende a certificados de agentes de recuperação, de forma que os certificados sensíveis do DRA também possam ser armazenados em cartões.

O Windows Vista também suporte a criptografia de itens anteriormente impossível ou muito difícil de se fazer no Windows XP. O Windows Vista pode criptografar o arquivo de páginas, dispensando a necessidade de definir a opção de limpeza do arquivo de página da memória virtual. Todo o design do recurso Arquivos Offline novamente elaborado no Windows Vista. Além do desempenho e da estabilidade muito melhores (bem como uma interface em geral mais simplificada), o armazenamento em cache no lado do cliente ocorre para cada usuários, significando que é possível criptografar seguramente o cache sem o uso do modo 2 ou 3 de SYSKEY. Essas duas melhorias eliminam grandes obstáculos de implantação para os ambientes atuais com base no Windows XP.

Por fim, o Windows Vista permite que administradores configurem a criptografia para a pasta de documentos diretamente por meio da Diretiva de Grupo, sem precisar usar o script de separação. A Figura 3 ilustra as novas propriedades do EFS disponíveis por meio do GPO no Windows Vista.

Figure 3** EFS properties in Windows Vista **(Clique na imagem para aumentar a exibição)

Conclusão

O EFS fornece aos administradores do Windows uma opção altamente segura para proteger dados móveis. O EFS é escalável, gerenciável e fornece mecanismos flexíveis de recuperação de dados. No Windows Vista, o EFS é ainda mais aprimorado com recursos avançados para gerenciamento e implantação simplificados, bem como suporte para armazenamento de chaves com base em cartões inteligentes. Para organizações que desejam proteger dados, mesmo quando uma máquina estiver fisicamente perdida, o EFS fornece uma solução poderosa que já faz parte da sua plataforma Windows existente.

Onde procurar mais informações

Para obter mais informações sobre os tópicos discutidos nesta coluna, consulte os recursos a seguir:

• A coluna Security Watch de fevereiro de 2007
• Criptografando o sistema de arquivos no Windows XP e no Windows Server 2003
• Como usar o utilitário SysKey para proteger o banco de dados do gerenciador de contas de segurança do Windows

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..