EFS – sistema de arquivos com criptografia
O EFS apareceu pela primeira vez no Windows 2000, e foi melhorando a cada nova versão, oferecendo uma criptografia forte e fácil de usar. Criptografia é um assunto complexo, e este artigo ficaria muito longo e complicado se fossemos descrever a teoria toda. Para mais detalhes, consulte este link e este link. É um pouco difícil aprender a configurar a criptografia em uma rede, mas para um PC só é fácil. Dependendo de suas necessidades pessoais e profissionais, a criptografia pode ser essencial.
Podemos definir a criptografia por arquivo ou por pasta (incluindo novos arquivos que forem criados dentro da pasta em questão), mas a criptografia não pode ser usada junto com a compactação. Vamos ver como ativar a criptografia básica: No Explorer, clique com o botão direito em um arquivo ou pasta e selecione Propriedades, Geral, Avançados, Criptografar o conteúdo para proteger os dados. Depois de criptografados, os arquivos e pastas aparecem com nome em verde no Explorer. No caso de um único PC, só quem estiver logado na sua conta poderá descriptografar o arquivo, e quando você estiver logado o arquivo será descriptografado automaticamente. Já em um servidor do Active Directory, a criptografia pode envolver servidores confiáveis, usuários confiáveis, agentes de recuperação, certificados, políticas de senha e múltiplos algoritmos de criptografia, e aí as coisas ficam mais complicadas.
Você também deve configurar as permissões de arquivo de forma apropriada. Certifique-se de que um intruso não possa ler ou gravar em seus arquivos criptografados.
Alguns problemas do EFS:
-
O primeiro problema da criptografia é que se você perder sua chave ou senha, pode dizer adeus aos seus arquivos criptografados. Quando as senhas são criadas da maneira certa, leva um bocado de tempo para se conseguir quebrá-las;
-
Se você usar uma senha óbvia, um intruso pode adivinhá-la e descriptografar seus arquivos;
-
Se seu PC não estiver em um domínio e alguém obtiver acesso a ele, é muito simples redefinir sua senha do Windows e fazer login;
-
Se você copiar um arquivo criptografado para uma partição não NTFS, o arquivo vai ser copiado sem criptografia. Isso pode acontecer se você copiar o arquivo para um disquete, um pendrive ou um CD-RW;
-
Se a chave privada de um agente de recuperação não for arquivada e removida do perfil do agente, um intruso pode fazer login na conta do agente de recuperação e criptografar e descriptografar arquivos;
-
O EFS não vai proteger o disco todo, caso seu laptop seja roubado. Se é isso o que você quer, confira o Bitlocker;
-
O EFS não está disponível nas versões Home, Starter e Basic do Windows.
E sim, o Sysinternals tem um utilitário chamado EFSDump que inspeciona um arquivo criptografado e lhe permite saber quem mais tem acesso a ele.
Discos de formato avançado
E esses novos discos de formato avançado com setores de 4096 bytes? Como o NTFS lida com eles? Os novos discos de formato avançado são maiores, mais velozes e mais confiáveis, contando com setores de 4096 bytes em vez dos tradicionais setores de 512 bytes. Há boas chances de um futuro PC seu vir com um desses. A Microsoft começou a fazer planos para esses discos durante o desenvolvimento do Vista, logo o Vista e o Windows 7 sabem lidar com eles, ao contrário das versões anteriores do Windows. Como os setores de 512 bytes se encaixam perfeitamente em setores de 4096 bytes, esses discos oferecem emulação de 512 bytes, mantendo a compatibilidade com sistemas operacionais mais antigos. O problema é quando uma partição é criada e não se alinha a uma fronteira de 4096 bytes, resultando em um desempenho muito mais lento no Windows XP. Para evitar isso, use os utilitários que acompanham os discos novos. A Seagate tem o Smart Align, e a Western Digital tem o WD Align. Os discos de formato avançado são maiores, mais rápidos e melhores.
NTFS Transacional (TxF)
Junto com o Windows Server 2008 veio um recurso chamado NTFS Transacional, ou TxF. O TxF permite que as operações do sistema de arquivos sejam realizadas em grupos como transações, como acontece em bancos de dados. Isso é importante quando você tem um grupo de atualizações que precisam ser realizadas no estilo “tudo ou nada”, como por exemplo, quando você precisa atualizar um conjunto de arquivos de dados que dependem uns dos outros. Você não pode atualizar um sem atualizar os outros. Atualizar todos ou não atualizar nenhum seria uma transação. Geralmente uma transação tem começo, fim e um commit ou reversão. O commit conclui a transação; a reversão desfaz a transação toda, caso ela não possa ser concluída.
Isso parece ótimo para a criação de scripts de instalação e para operação em documentos e coisas do gênero, certo? Infelizmente, o TxF só está disponível por meio de chamadas de API e do acesso do PowerShell ao registro. Em outras palavras, quem quiser a funcionalidade do TxF vai ter que criar o código por conta própria. A API inclui diversas chamadas de transações, como CreateFileTransacted, DeleteFileTransacted, CommitTransaction e RollbackTransaction.
Até que mais utilitários e aplicativos compatíveis com as transações sejam lançados, o TxF vai ser mais útil para desenvolvedores mesmo. O TxF só funciona em partições em discos SCSI e Fiber Channel.
O que poderia ter sido o WinFS
Imagine se um sistema de arquivos tivesse um banco de dados integrado, e se cada aplicativo que precisasse armazenar e pesquisar dados não tivesse que escrever seu próprio banco de dados, mas sim usar uma API padrão. Sua coleção de MP3 estaria sempre atualizada; seria fácil exibir e fazer backup de seus vídeos; seria moleza achar aquelas fotos que você bateu anos atrás. E se os emails fossem armazenados diretamente no sistema de arquivos, e não em arquivos PST, podendo ser acessados por outros aplicativos?
O WinFS foi uma tentativa de se adicionar funções reais de bancos de dados ao sistema de arquivos por meio de uma API flexível e eficiente. Tratava-se de um novo sistema de arquivos e de uma extensão do NTFS, que deveria sair para o Longhorn (ou Windows Vista). O WinFS seria implementado por meio de objetos .NET e acessado com o T-SQL. Um arquivo específico, como um MP3, poderia existir e ser atualizado em múltiplos arquivos, por meio de uma view de banco de dados. O WinFS seria capaz de sincronizar as alterações nos dados em múltiplos sistemas usando a replicação de banco de dados. A atualização de metadados de um tipo de arquivo específico seria realizada de forma robusta usando funções de banco de dados.
A promessa era a de que o usuário, afogado em seus próprios dados, tivesse acesso rápido, limpo e ortogonal a eles.
Mas não era para ser. O primeiro beta do WinFS foi lançado em setembro de 2005. O segundo beta foi cancelado em junho de 2006. Nenhuma explicação foi prestada publicamente, mas provavelmente os atrasos no lançamento do Vista contribuíram. O Vista atrasou anos. Ele seria lançado originalmente no fim de 2003, mas só saiu em janeiro de 2007. O WinFS deve ter sido sacrificado em prol de uma data de lançamento para o Vista.
Entrevista com o doutor Gary Kimura, co-desenvolvedor do NTFS
O doutor Gary Kimura é professor do Departamento de Ciência da Computação e Engenharia da Universidade de Washington.
Qual era o seu histórico antes de começar a trabalhar no NTFS?
Eu era membro da equipe do Windows NT, do grupo do kernel. Nós também convertemos o FAT e o HPFS para o primeiro lançamento do NT.
Quais ferramentas foram usadas na criação do NTFS?
O sistema operacional era novo, então havia poucas ferramentas. Só o habitual depurador do kernel. DBG.
Quanto tempo levou?
Alguns anos a mais do que nós imaginávamos. Formamos o grupo e começamos a nos reunir em 1989, e o primeiro SDK saiu em 1992. Ou seja, uns três anos.
Quantas pessoas estavam envolvidas?
Eu, Tom Miller, Brian Andrew e David Goebel.
Quais foram os maiores desafios?
Foi mais fácil porque pudemos criar nossas próprias APIs, e já tínhamos convertido o sistema FAT para o NT. Havia nuances na interface com o NT. O código tinha que operar próximo ao gerenciador de cache e ao gerenciador de memória.
O NTFS hospedava a si próprio, e isso foi um desafio para um sistema de arquivos. É diferente do que acontece com software, onde um problema de memória corrompida é resolvido com uma reiniciailzação do computador. Se o sistema de arquivos for corrompido, a perda é total. Nosso sistema de arquivos persistia mesmo com as reinicializações, e nós precisávamos ter muito cuidado com isso.
Você se lembra de bugs particularmente difíceis de resolver?
Nenhum em especial, até porque esse já era nosso terceiro sistema de arquivos. O journaling deu bastante trabalho. Se o sistema desse uma pane, o log de recuperação do NTFS tinha que ser revisto para que pudéssemos seguir em frente. Nessa versão, só havia transação de metadados de arquivos do sistema, e não de metadados dos arquivos do usuário.
O que você aprendeu com essa experiência?
Em retrospecto, a arquitetura foi criada para aquilo que imaginávamos ser um computador muito poderoso. Os PCs ainda não tinham nem 1 GB de RAM. Dá para imaginar isso? O maior disco disponível era pequeno, e não grande como hoje. Projetamos o NTFS para 64 bits, mas o resto do sistema não havia sido projetado para isso, então não foi preciso refazer a arquitetura dessa parte.
Você tem acompanhado as novidades do NTFS?
Na verdade, não.
O que tem lhe interessado ultimamente?
Eu gosto de dar aula para estudantes universitários. Tento transmitir as lições que aprendi por experiência própria.
Que conselho você daria para quem desenvolve sistemas operacionais hoje em dia?
Não dou nenhum conselho técnico. Só mantenha o equilíbrio da sua vida. O trabalho é sedutor e pode consumir todo o seu tempo livre. Não deixe que ele consuma uma parte muito grande do seu tempo e da sua vida.
Você ainda mantém o contato com a equipe original do NTFS?
Sim, a gente se encontra para tomar umas cervejas e bater um papo. Volta e meia chamo um deles como professor convidado para uma aula.
Resumo
O NTFS é complexo, e ainda assim tem uma elegância altamente funcional. Ao longo dos anos, ele foi beneficiado pelos testes e pelo desenvolvimento constante.
Referências
-
Russinovich, Mark E.; Solomon, David A.; Ionescu, Alex (2009). “Storage Management”. Windows Internals (5th ed.), Microsoft Press. ISBN 978-0-7356-2530-3.
-
Custer, Helen, (1994) “Inside the Windows NT File System”, Microsoft Press. ISBN 155615660X.
-
Ragar, Najeev, (1997) “Windows NT File System Internals : A Developer’s Guide”, O’Reilly Media ISBN 1565922492.
Créditos a Andrew Hudson – osnews.com
Tradução por Roberto Bechtlufft <info at bechtranslations.com.br>
Veja também
Sobre o Autor
Deixe seu comentário