 TechNet Magazine June 2007

TechNet Magazine June 2007

Segurança : Por dentro do UAC (Controle de Conta de Usuário) do Windows Vista

UAC, ou Controle de Conta de Usuário, é um dos novos recursos mais mal compreendidos do Windows Vista. Contudo seu objetivo, possibilitar que os usuários executem com direitos de usuário padrão, pode resolver muitos problemas de segurança. Veja os problemas que o UAC deve resolver e saiba exatamente como funciona esse novo recurso.

Mark Russinovich Segurança: Chaves para a proteção de dados com a criptografia de unidade de disco BitLocker

BitLocker tem duas finalidades muito importantes: ele oferece uma criptografia de dados de volume total e uma forma de validar a integridade dos componentes de inicialização antecipada, anterior à inicialização do Windows Vista. Obtenha uma visão geral de como o BitLocker funciona e veja como ele pode ajudar você a proteger a sua organização.

Byron Hynes Segurança: Explorando o Firewall do Windows

A mobilidade mudou as ameaças aos computadores e as técnicas que os protegem contra elas. Como os laptops entram e saem do perímetro da rede, você precisa de formas melhores de proteger os seus sistemas. Saiba como é possível usar o Firewall do Windows para proteger os computadores – na Internet e em sua própria rede interna.

Steve Riley Segurança: Novas ACLs aprimoram a segurança do Windows Vista

Embora não tenha havido grandes alterações nas ACLs, há algumas mudanças importantes que você precisará conhecer quando for gerenciá-las em um ambiente Windows Vista. Descubra como 30 ACLs foram alteradas para aprimorar a segurança, saiba como afetarão sua organização e aprenda a gerenciar essas mudanças na sua infra-estrutura.

Jesper Johansson Segurança: Gerenciando restrições de hardware por meio de Diretiva de grupo

Os pen drives USB e outros dispositivos removíveis podem tornar a sua vida pessoal mais fácil, mas também podem dificultar a sua vida profissional. Para obter mais segurança, você precisa de uma forma de controlar os dispositivos de hardware que os seus usuários estão instalados em seus sistemas de trabalho. Agora você pode usar a Diretiva de grupo para controlar os dispositivos que eles podem usar e os que eles não podem.

Jeremy Moskowitz Segurança: As 4 tecnologias de segurança que todas as organizações de TI devem ter

A maioria das empresas compartilha problemas de segurança similares. No mundo conectado de hoje, existem quatro tipos gerais de ferramentas de segurança que todas as organizações precisam ter. Descubra quais são essas ferramentas e veja como as tecnologias envolvidas poderão funcionar juntas no futuro para a criação da solução de segurança ideal.

Matt Clapham and Todd Thompson Segurança: Uma nova ferramenta avançada para o gerenciamento de certificados

Os certificados são um componente fundamental da sua infra-estrutura — sua expiração pode causar a paralisação da produtividade. Se você utiliza um ambiente de PKI da Microsoft, a nova solução ILM-CM (Identity Lifecycle Manager Certificate Management) poderá ajudá-lo a manter tudo funcionando perfeitamente. Descubra como essa ferramenta poderá ajudá-lo a aperfeiçoar os processos de autenticação e a reduzir os custos de gerenciamento de certificados.

Kevin Dallmann Do editor: Problemas de segurança

Joshua Trupin Toolbox: Novos produtos para profissionais de TI

Greg Steen P&R do SQL: Instalações de 64 bits, alocação da memória de cluster e muito mais

Edited by Nancy Michell Destaque de utilitário: PowerToys de elevação de script para o Windows Vista

Embora o Controle de Conta do Usuário ofereça um aperfeiçoamento importante na segurança, a possibilidade de elevar as permissões é essencial para a realização de determinadas tarefas administrativas e funções. Aqui estão alguns PowerToys de elevação que tornam a elevação mais flexível e eficiente.

Michael Murgolo The Cable Guy: O protocolo SSTP

Os protocolos VPN no Windows XP e no Windows Server 2003 não funcionam com algumas configurações. Obtenha uma visão aprofundada dos diversos problemas existentes e veja como o Windows Server “Longhorn” e o Windows Vista com Service Pack 1 usarão o protocolo SSTP para solucionar esses problemas.

Joseph Davies Windows PowerShell: Trabalhando com o Active Directory

O Windows PowerShell não oferece um cmdlet Get-ADSIObject, mas isso não o impede de oferecer um poderoso suporte a ADSI. Obtenha uma introdução aos adaptadores de tipo e saiba como o Windows PowerShell funciona com objetos de diretório.

Don Jones Ei, Equipe de Scripts!: Os scripts e a linha vermelha ondulada

Procurando por uma maneira mais fácil de adicionar termos ao dicionário do Microsoft Word sem ter de fazer isso à mão e uma palavra por vez? E quem não está? Neste mês, a Equipe de Scripts mostrará a você como criar dicionários personalizados no Microsoft Word e como configurar, por meio de programação, o Word para que ele utilize esses dicionários.

The Microsoft Scripting Guys Os arquivos da área de trabalho: Como evitar a perda dos seus dados

A freqüência com que dados importantes são perdidos é surpreendente. Mas a verdade é que as informações são perdidas porque as pessoas não as protegem corretamente. Explore as etapas importantes que você pode e deve seguir para proteger os dados da sua organização.

Wes Miller Anotações de campo: Converse com os seus desenvolvedores

Fazer com que os desenvolvedores criem aplicativos mais gerenciáveis é mais fácil do que você pensa. Tudo começa pela comunicação. Os desenvolvedores vêem o software de forma diferente dos administradores. No entanto, ao conversar com os desenvolvedores, os administradores podem explicar o que é importante para eles e os desenvolvedores poderão fazer um trabalho melhor ao projetarem o código adequadamente.

David Aiken Segredos do Windows: O que os novos usuários vêem no menu Iniciar

Imagine-se comprando um novo computador, iniciando o Windows, clicando no botão Iniciar e vendo um menu vazio. Há uma razão pela qual o menu Iniciar inclui aplicativos no ponto mais usado antes de você ter usado algum deles – para propiciar uma boa experiência pronta para usar. Saiba como esses aplicativos são escolhidos.

Raymond Chen Cartas: Respostas às suas perguntas


 Seguran&#231;a : Por dentro do UAC (Controle de Conta de Usu&#225;rio) do Windows Vista
Segurança Mark Russinovich

Por dentro do UAC (Controle de Conta de Usuário) do Windows Vista

Visão geral:
  • Executando como se fosse usuário padrão
  • Virtualização de arquivo e registro
  • Elevando o status da conta

UAC é um recurso em geral mal compreendido do Windows Vista. Em minha série de três partes na TechNet Magazine sobre alterações no kernel do Windows Vista, disponível online no endereço technetmagazine.com, não abordei o UAC porque considerei que o tema merecia um artigo exclusivo.
Neste artigo abordo os problemas que o UAC resolve e descrevo a arquitetura e a implementação de suas tecnologias de componente. Essas tecnologias incluem a refatoração de operações que anteriormente exigiam direitos administrativos, virtualização superficial para auxiliar os programas a executarem corretamente sem direitos administrativos, a capacidade para que os programas solicitem explicitamente direitos administrativos e isolamento de processos administrativos de processos não-administrativos sendo executados no mesmo desktop de usuário.

Objetivo do UAC
O UAC deve possibilitar que os usuários executem com direitos de usuário padrão, em vez de direitos administrativos. Os direitos administrativos possibilitam que os usuários leiam e modifiquem qualquer parte do sistema operacional, inclusive o código e os dados de outros usuários — e até mesmo o Windows® em si. Sem os direitos administrativos os usuários não podem acidentalmente (ou deliberadamente) modificar as configurações do sistema, malware não consegue alterar as configurações de segurança do sistema ou desativar o software antivírus, e os usuários não conseguem comprometer as informações confidenciais de outros usuários em computadores compartilhados. Executar com direitos de usuário padrão pode então reduzir chamadas urgentes para o suporte técnico em ambientes corporativos, mitigar o impacto de malware, manter os computadores domésticos funcionando com tranqüilidade, além de proteger dados confidenciais em computadores compartilhados.
UAC tinha que resolver vários problemas para que fosse mais prático executar com uma conta de usuário padrão. Primeiramente, antes do Windows Vista™, o modelo de uso do Windows pressupunha os direitos administrativos. Os desenvolvedores de software tinham como certo que seus programas poderiam ter acesso a qualquer arquivo, chave de registro ou configuração do sistema operacional, bem como modificá-los. Mesmo quando o Windows NT® introduziu segurança e fez diferenciação entre acessos concedidos a contas de usuário administrativas e padrão, os usuários eram orientados em um processo de configuração que os encorajava a usar a conta de administrador interna ou uma que fosse membro do grupo de administradores.
O segundo problema que o UAC tinha que resolver era que os usuários às vezes precisavam de direitos administrativos para realizar operações como instalar software, alterar a hora do sistema e abrir portas no firewall.
A solução do UAC para esses problemas é de executar a maioria dos aplicativos com direitos de usuário padrão, eliminar a necessidade de direitos de administrador a todo o momento e encorajar os desenvolvedores de software a criar aplicativos que são executados com direitos de usuário padrão. O UAC realiza isso quando exige direitos administrativos com menos freqüência, possibilitando que os aplicativos herdados sejam executados com direitos de usuário padrão, tornando conveniente o acesso a direitos administrativos para quando os usuários padrão precisam, e ainda possibilitando que mesmo os usuários administrativos executem como se fossem usuários padrão.

Executando como se fosse usuário padrão
Uma auditoria completa de todas as operações administrativas durante o desenvolvimento do Windows Vista identificou muitos itens que poderiam ser habilitados para usuários padrão sem comprometer a segurança do sistema. Por exemplo, mesmo as corporações que adotaram contas de usuário padrão para seus sistemas desktop Windows XP não conseguiram remover do grupo de administradores seus usuários em viagens, pelo simples fato de o Windows XP não estabelecer a diferença entre alteração de fuso horário e alteração de hora do sistema. Um usuário de laptop que deseja configurar seu fuso horário para que seus compromissos sejam exibidos corretamente no calendário quando viaja precisa ter o privilégio "Alterar a hora do sistema" (chamado internamente de SeSystemTimePrivilege), o que por padrão só é concedido a administradores.
A hora é normalmente usada em protocolos de segurança, como Kerberos, mas o fuso horário somente afeta o modo como a hora será exibida, então o Windows Vista adiciona um novo privilégio, "Alterar o fuso horário" (SeTimeZonePrivilege), e o atribui ao grupo Usuários, conforme se vê na Figura 1. Com isso, é possível que muitas empresas configurem os usuários de laptop dentro de contas de usuário padrão.
Figura 1 O privilégio "Alterar o fuso horário"
Figura 1 O privilégio "Alterar o fuso horário"
O Windows Vista também permite que usuários padrão definam as configurações WEP quando conectam-se em redes sem fio, criem conexões VPN, alterem as configurações de gerenciamento de energia e instalem atualizações críticas do Windows. Além disso, introduz configurações de Diretiva de Grupo, que possibilitam que os usuários padrão instalem drivers de impressoras e outros dispositivos aprovados por administradores de TI e instalem controles ActiveX® de sites aprovados pelos administradores.
E quanto aos aplicativos LOB (linha de negócios) e de consumo que não são executados corretamente em contas de usuário padrão? Por um lado, há software que exige legitimamente direitos administrativos, por outro há muitos programas que armazenam desnecessariamente dados do usuário em locais globais do sistema. A Microsoft recomenda que os instaladores de aplicativos globais que têm a expectativa de serem executados com direitos administrativos criem um diretório dentro de %ProgramFiles% para armazenar os arquivos executáveis do aplicativo, bem como dados auxiliares, e criem uma chave em HKEY_LOCAL_MACHINE\Software para as configurações do aplicativo. Quando um aplicativo é executado, ele pode estar em contas de usuários diferentes e deve portanto armazenar dados específicos de usuários no diretório %AppData% por usuário, além de salvar as configurações pessoais no perfil do registro do usuário em HKEY_CURRENT_USER\ Software. As contas de usuários padrão não têm acesso a gravação no diretório %ProgramFiles% ou em HKEY_LOCAL_MACHINE\Software, mas como a maioria dos sistemas Windows são de um único usuário e a maioria deles tem sido administradores até a chegada do Windows Vista, os aplicativos que salvarem incorretamente os dados e configurações de usuário nesses locais funcionam do mesmo jeito.
O Windows Vista habilita que esses aplicativos herdados sejam executados em contas de usuário padrão com a ajuda do sistema de arquivos e a virtualização do namespace do registro. Quando um aplicativo modifica um local global do sistema no sistema de arquivos ou registro e essa operação falha em função de acesso negado, o Windows redireciona a operação a uma área dividida por usuário: quando o aplicativo lê de um local global do sistema, o Windows primeiro verifica se há dados na área por usuário e, se não houver nada, permite que a tentativa de leitura no local global.
Para o objetivo desta virtualização, o Windows Vista trata um processo como herdado se for de 32 bits (em vez de 64 bits), não estiver executando com direitos administrativos, e não tiver um arquivo de manifesto indicando que foi escrito para o Windows Vista. Qualquer operação que não estiver originando de um processo classificado como herdado de acordo com essa definição, incluindo acessos de compartilhamento de arquivo em rede, não será virtualizada. O status de virtualização de um processo é armazenado como um sinalizador em seu token, que é a estrutura de dados de kernel que rastreia o contexto de segurança de um processo, incluindo sua conta de usuário, membros do grupo e privilégios.
Você pode ver o status de virtualização de um processo adicionando a coluna de Virtualização à página de processos do Gerenciador de Tarefas. A Figura 2 mostra que a maioria dos componentes do Windows Vista, incluindo o Gerenciador de Janelas da Área de Trabalho (Dwm .exe), o Subsistema do Tempo de Execução do Servidor do Cliente (Csrss.exe), e o Explorer, todos têm a virtualização desabilitada porque têm um manifesto de Windows Vista ou estão sendo executados com direitos administrativos e por isso não permitem a virtualização. O Internet Explorer® (iexplore.exe) tem a virtualização habilitada porque pode hospedar vários scripts e controles ActiveX e deve supor que esses itens não foram escritos para operar corretamente com direitos de usuário padrão.
Figura 2 O Gerenciador de Tarefas mostra o status da virtualização
Figura 2 O Gerenciador de Tarefas mostra o status da virtualização
Os locais do sistema de arquivos virtualizados para processos herdados são %ProgramFiles%, %ProgramData% e %SystemRoot%, excluindo alguns subdiretórios específicos. No entanto, qualquer arquivo com uma extensão executável, incluindo .exe, .bat, .scr, .vbs, e outros, é excluído da virtualização. Isso significa que programas que se atualizam a partir de uma conta de usuário padrão falham, em vez de criar versões privadas de seus executáveis que não são visíveis para um administrador que está executando um atualizador global. Para adicionar extensões adicionais à lista de exceções, insira-as na seguinte chave de registro e reinicialize:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
Use um tipo de seqüência múltipla para delimitar múltiplas extensões e não inclua um ponto no início do nome da extensão.
As modificações nos diretórios virtualizados por processos herdados redirecionam para o diretório raiz virtual do usuário, %LocalAppData%\VirtualStore. Por exemplo, se um processo virtualizado que está sendo executado em meu sistema cria um C:\Windows\Application.ini, o arquivo que ele cria de fato é C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini. O componente Local do caminho destaca o fato de que arquivos virtualizados não são carregados com o resto do perfil quando a conta tem um perfil de móvel.
Se você navega no Explorer para um diretório contendo arquivos virtualizados, o Explorer exibe um botão rotulado Arquivos de Compatibilidade em sua barra de ferramentas, conforme mostra a Figura 3. Clicar no botão o leva ao subdiretório VirtualStore correspondente para mostrar a você os arquivos virtualizados.
Figura 3 O botão Arquivos de Compatibilidade indica os arquivos virtualizados próximos
Figura 3 O botão Arquivos de Compatibilidade indica os arquivos virtualizados próximos
A Figura 4 mostra como o Driver do Filtro de Virtualização do Arquivo UAC (%SystemRoot%\System32\Drivers\Luafv.sys) implementa a virtualização de sistema de arquivos. Como é um driver de filtro de sistema de arquivos, ele vê todas as operações de sistema de arquivos, mas somente implementa a funcionalidade para operações de processos herdados. Você pode ver que ele altera o caminho de arquivo de destino para um processo herdado que cria um arquivo em um local global do sistema, mas não para um processo executando um aplicativo Windows Vista com direitos de usuário padrão. O processo herdado acredita que a operação é bem-sucedida quando realmente é criado o arquivo em um local totalmente acessível ao usuário, mas as permissões padrão no diretório \Windows negam acesso ao aplicativo escrito para Windows Vista.
Figura 4 Virtualização de sistema de arquivos
Figura 4 Virtualização de sistema de arquivos
A virtualização do registro é implementada de forma ligeiramente diferente do que a virtualização de sistema de arquivos. As chaves de registro virtualizadas incluem a maioria da ramificação HKEY_LOCAL_MACHINE\Software, mas há várias exceções, tais como as seguintes:
HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes
Somente são virtualizadas as chaves que são normalmente modificadas por aplicativos herdados, mas que não introduzem problemas de compatibilidade ou interoperabilidade. O Windows redireciona as modificações de chaves virtualizadas por aplicativos herdados para a raiz virtual de registro do usuário em HKEY_ CURRENT_USER\Software\Classes\VirtualStore. A chave está localizada na seção Classes do usuário, %LocalAppData%\Microsoft\Windows\UsrClass.dat, que como qualquer outro dado de arquivo virtualizado, não é carregado com um perfil de usuário móvel.
Em vez de manter uma lista fixa de locais virtualizados como o Windows faz para o sistema de arquivos, o status de virtualização de uma chave fica armazenado como um sinalizador, REG_ KEY_DONT_VIRTUALIZE, na chave em si. O utilitário Reg.exe pode mostrar o sinalizador, bem como os dois outros sinalizadores relacionados a virtualização, REG_KEY_ DONT_SILENT_FAIL e REG_KEY_ RECURSE_FLAG, vistos na Figura 5. Quando REG_KEY_DONT_SILENT_FAIL está definida e a chave não está virtualizada (REG_KEY_DONT_VIRTUALIZE está definida), um aplicativo herdado que teria acesso negado quando realiza uma operação na chave, na verdade recebe concessão de qualquer acesso que o usuário tenha à chave, em vez de os acessos que o aplicativo solicitou. REG_KEY_RECURSE_FLAG indica se as novas sub-chaves herdam os sinalizadores de virtualização do pai, em vez de apenas os sinalizadores padrão.
Figura 5 O utilitário Reg mostra sinalizadores de virtualização
Figura 5 O utilitário Reg mostra sinalizadores de virtualização
A Figura 6 mostra como a virtualização de registro é implementada pelo Gerenciador de Configurações, que gerencia o registro no kernel do sistema operacional, Ntoskrnl.exe. Assim como com a virtualização de sistema de arquivos, um processo herdado criando uma subchave de uma chave virtualizada é redirecionada à raiz virtual do registro do usuário, mas um processo do Windows Vista tem acesso negado por permissões padrão.
Além do sistema de arquivo e da virtualização de registro, alguns aplicativos requerem um suporte técnico extra para serem executados corretamente com direitos de usuário padrão. Por exemplo, um aplicativo que teste a conta na qual está executando com associação no grupo Administradores pode até funcionar, mas não será executada se não estiver naquele grupo. Sendo assim, o Windows Vista define várias correções de compatibilidade de aplicativo para que esses aplicativos funcionem de qualquer forma. As correções aplicadas com maior freqüência a aplicativos herdados para funcionar com direitos padrão são mostradas na Figura 7. Os profissionais de TI corporativa podem usar ferramentas como o ACT (Application Compatibility Toolkit , disponível em technet.microsoft .com/windowsvista/aa905066.aspx) e seu utilitário SUA (Standard User Analyzer), ou o LUA Buglight de Aaron Margosis para identificar os requisitos de correção para os aplicativos do tipo LOB. Eles atribuem correções a um aplicativo usando o Compatibility Administrator, que também faz parte do ACT, e em seguida implantam o banco de dados de compatibilidade resultante (arquivo .sdb) em seus desktops via Diretiva de Grupo. Observe que, se necessário, a virtualização pode ser completamente desabilitada em um sistema usando uma configuração de política de segurança local.
Figure 7 Correções comuns de usuário (Close Figure 7)

Correção | Finalidade
ElevateCreateProcess | Muda o CreateProcess para manipular erros de ERROR_ELEVATION_REQUIRED chamando o AIS para solicitar elevação.
ForceAdminAccess | Simula consultas de associação aos grupo de administradores.
VirtualizeDeleteFile | Simula a exclusão com êxito de diretórios e arquivos globais.
LocalMappedObject | Força objetos de seção global no namespace do usuário.
VirtualizeHKCRLite, VirtualizeRegisterTypeLib | Redireciona o registro global de objetos COM a um local por usuário.
Os efeitos da virtualização
Você pode alterar o status da virtualização de um processo, selecionando Virtualização no menu de contexto exibido quando se clica nele com o botão direito do mouse no Gerenciador de Tarefas. A Figura A mostra o comportamento de um prompt de comando quando seu status de virtualização muda. Ele começa com a virtualização desabilitada porque tem um manifesto do Windows Vista. Como está sendo executado com direitos de usuário padrão, não consegue criar um arquivo no diretório \Windows, mas depois de se tornar virtualizado com o Gerenciador de Tarefas, parece criar o arquivo com êxito. Quando sua virtualização retorna ao estado desabilitado, não consegue encontrar o arquivo, que na verdade está no armazenamento virtual do usuário.
Figura A Uma alteração no status da virtualização
Figura A Uma alteração no status da virtualização

Modo de Aprovação de Administrador
Mesmo se os usuários executarem apenas programas que são compatíveis com direitos de usuário padrão, algumas operações ainda requerem direitos administrativos. A vasta maioria das instalações de software requer direitos administrativos para criar diretórios e chaves de registro nos locais globais do sistema ou para instalar serviços ou drivers de dispositivos. Modificar as configurações de aplicativos e globais do sistema do Windows também requer direitos administrativos, assim como o recurso de controle dos pais do Windows Vista. Seria possível realizar a maioria dessas operações alternando para uma conta de administrador dedicada, mas a inconveniência de fazer isso provavelmente resultaria em manter a maioria dos usuários na conta administrativa para realizar suas tarefas cotidianas.
Por isso o Windows Vista inclui a funcionalidade aprimorada "executar como" para que os usuários padrão possam ter a conveniência de iniciar processos com direitos administrativos. Essa funcionalidade exigia que se desse aos aplicativos uma forma de identificar operações para as quais o sistema pudesse obter direitos administrativos em nome do aplicativo, se necessário, o que descreverei brevemente.
Além disso, para que os usuários atuando como administradores de sistema pudessem executar com direitos de usuário padrão, mas sem precisar informar nomes de usuário e senhas todas as vezes que quisessem ter acesso a direitos administrativos, o Windows Vista introduziu o AAM (Modo de Aprovação de Administrador). Esse recurso cria duas identidades para o usuário logon: uma com direitos de usuário padrão e outra com direitos administrativos. Como todos os usuários em um sistema Windows Vista são usuários padrão ou estão executando na maior parte como usuário padrão no AAM, os desenvolvedores devem assumir que todos os usuários do Windows são usuários padrão, o que irá resultar em mais programas funcionando com direitos de usuário padrão, sem virtualização ou correções.
Conceder direitos administrativos a um processo é chamado elevação. Quando é realizada por uma conta de usuário padrão, é chamada de elevação OTS (implícita ou "Over the Shoulder") porque exige a entrada de credenciais para uma conta que seja membro do grupo de administradores, algo que normalmente é realizado por outro usuário digitando "por trás" do usuário padrão. Uma elevação realizada por um usuário AAM é chamada Elevação com consentimento porque basta ao usuário aprovar a atribuição de seus direitos administrativos.
O Windows Vista considera administrador um usuário se esse usuário estiver associado a qualquer dos grupos de administrador listados na Figura 8. Muitos dos grupos listados são usados apenas em sistemas ingressados em domínio e não oferecem diretamente aos usuários direitos administrativos locais, mas permitem que modifiquem configurações de todo o domínio. Se um usuário for um membro de qualquer um desses grupos, mas não do grupo de administradores, o usuário acessa seus direitos administrativos via elevações OTS em vez de elevações com consentimento.
Figure 8 Grupos administrativos (Close Figure 8)

Administradores internos
Administradores certificados
Administradores de domínio
Administradores corporativos
Administradores de diretivas
Administradores de esquema
Controladores de domínio
Controladores de domínio somente leitura corporativos
Controladores de domínio somente leitura
Operadores de conta
Operadores de backup
Operadores de criptografia
Operadores de configuração de rede
Operadores de impressão
Operadores de sistema
Servidores RAS
Usuários avançados
Acesso compatível anterior ao Windows 2000
Quando um usuário pertencente a um dos grupos listados efetua login, o Windows Vista cria um token representando a versão de usuário padrão da identidade administrativa do usuário. O novo token é despido de todos os privilégios atribuídos ao usuário, exceto aqueles listados na Figura 9, que são os privilégios comuns de usuário padrão. Além disso, todos os grupos do tipo administrador estão marcados com o sinalizador USE_FOR_DENY_ONLY no novo token. A Figura 10 mostra o Process Explorer da Sysinternals (uma ferramenta de gerenciamento de processo que você pode baixar em microsoft .com/technet/sysinternals) exibindo os privilégios e as associações de grupo de um processo sendo executado com direitos administrativos na esquerda, e sem direitos administrativos na direita. (Para impedir o uso inadvertido, o modelo de segurança do Windows requer que um privilégio com o sinalizador desabilitado seja habilitado antes de ser usado.)
Figure 9 Privilégios de usuário padrão (Close Figure 9)

Nome amigável | Nome interno
Ignorar verificação completa | SeChangeNotifyPrivilege
Desligar o sistema | SeShutdownPrivilege
Remover o computador da base de encaixe | SeUndockPrivilege
Aumentar o conjunto de trabalho de um processo | SeIncreaseWorkingSetPrivilege
Alterar o fuso horário | SeTimeZonePrivilege
Figura 10 Administrador AAM e tokens de usuário padrão.
Figura 10 Administrador AAM e tokens de usuário padrão.
Um grupo com o sinalizador somente de negação só pode ser usado para negar acesso de usuário a um recurso, nunca para permiti-lo, fechando um buraco de segurança que poderia ser criado se o grupo fosse totalmente removido. Por exemplo, se um arquivo tivesse uma ACL (Lista de Controle de Acesso) que negasse ao grupo de Administradores todo o acesso, mas concedesse algum acesso a outro grupo que o usuário pertença, esse usuário passaria a ter acesso se o grupo de administradores estiver ausente do token, concedendo à versão de usuário padrão da identidade do usuário mais acesso do que sua identidade de administrador.
Sistemas autônomos, que são em geral computadores caseiros e sistemas ingressados em domínio tratam o acesso AAM por usuários remotos de modo diferente, porque os computadores conectados em um domínio podem usar grupos administrativos de domínio em suas permissões de recurso. Quando um usuário acessa um compartilhamento de arquivo de um computador autônomo, o Windows solicita a identidade de usuário padrão do usuário remoto, mas em sistemas que ingressaram em domínio, o Windows respeita todas as associações de grupo do domínio do usuário solicitando a identidade administrativa do usuário.

Acessando os direitos administrativos facilmente
Há vários modos de sistema e aplicativos identificarem uma necessidade de direitos administrativos. Um que aparece na interface de usuário do Explorer é a opção de atalho e entrada de menu de contexto "Executar como administrador". Esses itens incluem um ícone de escudo colorido que deve ser colocado em qualquer botão ou item de menu que irá resultar em uma elevação de direitos quando for selecionado. Escolher a entrada "Executar como administrador" faz com que o Explorer chame o API ShellExecute com o verbo "runas".
A grande maioria de programas de instalação requer direitos administrativos para que o carregador de imagem, que inicia um executável, inclua código de detecção de instalador para identificar prováveis instaladores herdados. Parte da heurística que ele usa são coisas tão simples quanto detectar se a imagem tem as palavras "setup", "install" ou "update" no nome de arquivo ou nas informações internas de versão; outros meios mais sofisticados incluem a verificação por seqüências de bytes no executável, comuns em utilitários de conteúdo adicional de instalação feitos por terceiros.
O carregador de imagem também chama a biblioteca de compatibilidade de aplicativo (appcompat) para ver se o executável de destino requer direitos de administrador. A biblioteca busca no banco de dados de compatibilidade de aplicativo para ver se o executável tem os sinalizadores de compatibilidade RequireAdministrator ou RunAsInvoker associados a ele.
A forma mais comum de um executável exigir direitos administrativos para si é incluir uma marca requestedElevationLevel em seu arquivo de manifesto de aplicativo. Os manifestos são arquivos XML que contêm informações suplementares sobre uma imagem. Eles foram introduzidos no Windows XP como uma forma de identificar dependências em assemblies DLL lado a lado e Microsoft .NET Framework. A presença do elemento trustInfo em um manifesto (que você pode ver no despejo de seqüência extraída de Firewallsettings.exe abaixo), denota um executável que foi escrito para Windows Vista e o elemento requestedElevationLevel está aninhado dentro dele. O atributo de nível de elemento pode ter um dos três valores a seguir: asInvoker, highestAvailable e requireAdministrator.
<trustInfo
 xmlns=”urn:schema-microsoft-com:asm.v3”>
 <security>
  <requestedPrivileges>
   <requestedExecutionLevel
    Level=”requireAdministrator”
    uiAccess=”false”/>
  </requestedPrivileges>
 </security>
</trustInfo>
Os executáveis que não têm necessidade de direitos administrativos, como o Notepad.exe, especificam o valor asInvoke. Alguns executáveis esperam que os administradores sempre queiram um máximo de acesso, então usam o valor highestAvailable. Um usuário que executa um executável com esse valor será solicitado a elevar apenas se estiver executando em AAM ou for considerado um administrador de acordo com as regras definidas anteriormente e devem elevar para ter acesso a seus direitos administrativos. Regedit.exe, Mmc.exe e Eventvwr.exe são exemplos de aplicativos que usam highestAvailable. Por fim, requireAdministrator sempre causa uma solicitação de elevação e é usado por qualquer executável que não irá funcionar sem direitos administrativos.
Os aplicativos de acessibilidade especificam "true" para o atributo uiAccess para conduzir a entrada de janela de processos elevados e eles também devem ser assinados e estar em um dos vários locais seguros, incluído %SystemRoot% e %ProgramFiles%, para ter essa capacidade.
Uma forma fácil de determinar os valores especificados por um executável é exibir seu manifesto com um utilitário Sysinternals Sigcheck como este:
sigcheck –m <executable>
Executar uma imagem que requer direitos administrativos faz com que o serviço de informações do aplicativo (também conhecido como AIS, contido em %SystemRoot%\System32\Appinfo.dll), que é executado dentro de um processo Host de Serviço (%SystemRoot%\System32\Svchost .exe), inicie Consent.exe (%SystemRoot%\System32\Consent.exe). O Consent captura um bitmap da tela, aplica um esmaecimento a ela, alterna para um desktop que só está acessível para a conta do Sistema Local, pinta o bitmap como plano de fundo e exibe uma caixa de diálogo de elevação que contém informações sobre o executável. Exibir em um desktop separado impede que qualquer malware que esteja presente na conta do usuário modifique a aparência da caixa de diálogo.
Figura 11 Caixas de diálogos de elevação OTS
Figura 11 Caixas de diálogos de elevação OTS
Se uma imagem é um componente do Windows assinado digitalmente pela Microsoft e a imagem está no diretório do sistema do Windows, então a caixa de diálogo exibe uma faixa azul na parte superior, conforme é mostrado na parte superior da Figura 11. A faixa cinza (no meio da caixa de diálogo) é para imagens que são assinadas digitalmente por alguém diferente da Microsoft, e a faixa laranja (parte de baixo da caixa de diálogo) é para imagens sem assinatura. O diálogo de elevação mostra o ícone da imagem, descrição, e editor de imagens assinadas digitalmente, mas apenas um ícone genérico, o nome do arquivo e "Editor Não Identificado" para imagens sem assinatura. Isso dificulta que malware imite a aparência de software legítimo. O botão Detalhes na parte inferior da caixa de diálogo expande para mostrar a linha de comando que será passada para o executável, caso seja iniciado. A caixa de diálogo de consentimento do AAM, mostrado na Figura 12, é similar, mas em vez de solicitar as credenciais de administrador, a caixa de diálogo tem os botões Continuar e Cancelar.
Figura 12 Caixa de diálogo de elevação AAM
Figura 12 Caixa de diálogo de elevação AAM
Se um usuário recusa uma elevação, o Windows retorna um erro de acesso negado ao processo que deu início à inicialização. Quando um usuário concorda com uma elevação, seja inserindo credenciais de administrador ou clicando em Continuar, o AIS chama CreateProcessAsUser para iniciar o processo com a identidade administrativa apropriada. Apesar de o AIS ser tecnicamente o pai do processo elevado, o AIS usa um novo suporte no API CreateProcessAsUser que define a identificação do processo pai do processo àquela do processo que o iniciou originalmente (veja a Figura 13). Essa é a razão pela qual os processos elevados não aparecem como filhos do processo de Hospedagem de Serviços AIS em ferramentas como o Process Explorer, que mostra as árvores de processo.
Figura 13 Fluxo de elevação
Figura 13 Fluxo de elevação
Apesar de as caixas de diálogo de elevação aparecerem em um desktop separado seguro, os usuários não têm nenhum modo por padrão de verificar se estão visualizando uma caixa de diálogo legítima e não uma apresentada por malware. Isso não é um problema para o AAM porque malware não consegue obter direitos administrativos com uma falsa caixa de diálogo de consentimento, mas o malware pode esperar por uma elevação OTS de usuário padrão, interceptá-la e usar uma caixa de diálogo de Cavalo de Tróia para capturar as credenciais de administrador. Com essas credenciais, eles podem obter acesso à conta de administrador e infectá-la.
Por esse motivo, as elevações OTS são altamente desencorajadas em ambientes corporativos. Para desabilitar elevações OTS (e reduzir chamadas de suporte técnico), execute o Editor de Diretivas de Segurança Local (Secpol.msc) e configure "Controle de Conta de Usuário:" O comportamento do prompt de elevação para usuários padrão como "Automaticamente" indefere as requisições de elevação.
Os usuários domésticos que têm preocupação com segurança devem configurar as elevações OTS para que solicitem uma SAS (seqüência segura) que o malware não consiga interceptar ou simular. Configure a SAS executando o Editor de Diretivas de Grupo (Gpedit.msc), navegando para Configuração do Computador| Modelos Administrativos | Componentes do Windows | Interface do Usuário de Credenciais, e habilitando "Necessário um caminho confiável para entrada da credencial". Depois de realizar essas ações, você será solicitado a pressionar as teclas Ctrl+Alt+Delete para ter acesso à caixa de diálogo de elevação.

Isolando processos elevados
O Windows Vista coloca uma barreira em torno de processos elevados para protegê-los de malware que esteja em execução no mesmo desktop com direitos de usuário padrão. Sem uma barreira, malware pode conduzir um aplicativo administrativo, enviando-o entradas de janela e mouse sintetizadas, via mensagens de janela. E apesar de o modelo de segurança padrão do Windows impedir que malware em execução em um processo com direitos de usuário padrão faça violações a um processo elevado executando como um usuário diferente, esse modelo não impede que o malware dentro de uma versão de direitos padrão de um usuário administrativo abra os processos elevados do usuário, injetando código a eles e iniciando threads nele para executar o código injetado.
A proteção do Windows Vista para mensagens de janela é chamada UIPI (User Interface Privilege Isolation). Ela baseia-se no novo Mecanismo de Integridade do Windows que o Windows Vista também usa como a barreira em torno de processos elevados. Nesse novo modelo de segurança, todos os processos e objetos têm níveis de integridade e a diretiva de integridade de um objeto pode restringir os acessos que em outra situação seriam concedidos a um processo pelo modelo de segurança DAC (Controle de Acesso Condicional) do Windows.
Os ILs (Níveis de Integridade) são representados por SIDs (Identificadores de Segurança), que também representam usuários e grupos, em que o nível está codificado no RID (Identificador Relativo) do SID. A Figura 14 mostra o nome de exibição, o SID, e a versão hexadecimal do RID do SID para os quatro primeiros ILs. Os números hex revelam lacunas de 0x1000 entre cada nível que possibilita que níveis intermediários para uso de aplicativos de acessibilidade de interface de usuário, bem como para um futuro crescimento.
Figure 14 Níveis de integridade primários (Close Figure 14)

Nome | SID | RID
Nível Obrigatório Baixo | S-1-16-4096 | 0x1000
Nível Obrigatório Médio | S-1-16-8192 | 0x2000
Nível Obrigatório Alto | S-1-16-12288 | 0x3000
Nível Obrigatório do Sistema | S-1-16-16384 | 0x4000
A Figura 15 lista as diretivas de IL de objeto e os tipos de acesso que eles restringem, que correspondem aos acessos genéricos definidos para um objeto. Por exemplo, Sem Gravação impede que um processo de IL inferior obtenha qualquer dos acessos representados pelos acessos GENERIC_WRITE. A diretiva padrão para a maioria dos objetos, incluindo arquivos e chaves de registro, é Sem Gravação, o que impede que um processo obtenha acesso de gravação em objetos que tem um IL superior ao processo, mesmo que a DACL (lista de controle de acesso condicional) do objeto conceda ao usuário tal acesso. Os únicos objetos com uma diretiva diferente são os objetos de thread e processo. Sua diretiva, Sem Gravação somada a Sem Leitura, impede que um processo executado com um IL inferior faça injeção de código e leitura de dados — como senhas — em um processo com um IL superior.
Figure 15 Diretivas de nível de integridade (Close Figure 15)

Diretiva | Efeito
Sem gravação | Um processo com IL baixo não pode modificar um objeto IL superior
Sem leitura | Um processo com IL baixo não pode ler de um objeto IL superior
Sem execução | Um processo com IL baixo não pode executar um objeto IL superior
O Windows atribui um IL a cada processo, que é colocado no token do processo em conjunto com as SIDs dos grupos aos quais pertence o usuário executando o processo. A Figura 16 lista exemplos de processos atribuídos a diferentes ILs. Os processos normalmente herdam o IL de seu pai, mas um processo pode também iniciar um processo com um IL diferente, como faz o AIS quando inicia um processo elevado. Você pode exibir os níveis de integridade de um processo com o utilitário interno Whoami especificando a opção "/all" ou com o Process Explorer ou AccessChk da Sysinternals. O Process Explorer pode exibir ILs de processos com a adição da coluna de Nível de Integridade.
Figure 16 Atribuição de nível de integridade de processo de amostra (Close Figure 16)

Nível de integridade | Processos de exemplo
Nível Obrigatório Baixo | Modo Protegido do Internet Explorer e processos iniciados pelo Modo Protegido do Internet Explorer
Nível Obrigatório Médio | Usuário padrão e processos AAM não elevados
Nível Obrigatório Alto | Processos em execução com direitos administrativos
Nível Obrigatório do Sistema | Processos de Sistema Local, Serviço Local e Serviço de Rede
Cada objeto protegido tem um IL explícito ou implícito. Objetos de processo, thread e token sempre têm um IL atribuído explicitamente que normalmente é o mesmo que o IL armazenado no token do processo correspondente. A maioria dos objetos não tem IL explícita e portanto usam como padrão o IL médio. Os únicos objetos criados com um IL diferente de médio são os objetos criados por um processo executando com IL baixo, que portanto têm um IL baixo. Você pode usar a ferramenta interna iCacls (%SystemRoot%\System32\iCacls.exe) para exibir os ILs de arquivos e o utilitário Sysinternals AccessChk para exibir os ILs de arquivos, chave de registro, serviços e processos. A Figura 17 revela que o IL de um diretório que precisa estar acessível pelo Modo Protegido do Internet Explorer é baixo.
Figura 17 AccessChk mostrando o IL de um diretório de favoritos do usuário
Figura 17 AccessChk mostrando o IL de um diretório de favoritos do usuário
Se um objeto tem um IL explícito, é armazenado em uma ACE (entrada de controle de acesso) de um tipo novo para o Windows Vista, o Rótulo ACE, na SACL (lista de controle de acesso do sistema) do descritor de segurança do objeto (veja a Figura 18). A SID na ACE corresponde ao IL do objeto e os sinalizadores da ACE codificam a diretiva de integridade do objeto. Antes do Windows Vista, as SACLs só armazenavam ACEs de auditoria, que requerem o privilégio "Gerenciar a auditoria e o log de segurança" (SeSecurityPrivilege), mas a leitura de um Rótulo ACE requer apenas um acesso de permissões de leitura (READ_CONTROL). Para que um processo modifique o IL de um objeto, ele deve ter acesso Alterar proprietário (WRITE_OWNER) ao objeto e um IL igual ou superior ao objeto e o processo só pode definir o IL a seu próprio IL ou inferior. O novo privilégio "Modificar rótulo de objeto" (SeRelabelPrivilege) propicia a um processo a capacidade de trocar o IL de qualquer objeto que o processo tenha acesso e até mesmo elevar o IL para que fique superior ao IL do próprio processo, mas por padrão esse privilégios não estão atribuídos a nenhuma conta.
Figura 18 O Rótulo ACE de um objeto
Figura 18 O Rótulo ACE de um objeto
Quando um processo tenta abrir um objeto, a verificação de integridade acontece antes da verificação padrão de DACL do Windows na função SeAccessCheck do kernel. Dadas as diretivas de integridade padrão, um processo só pode abrir um objeto para acesso de gravação se seu IL for igual ou superior ao IL do objeto e o DACL também conceder ao processo os acessos que ele deseja. Por exemplo, um processo de IL baixo não pode abrir um processo de IL médio para acesso de gravação, mesmo que o DACL conceda acesso de gravação ao processo.
Com a diretiva de integridade padrão, os processos podem abrir qualquer objeto -- com a exceção dos objetos de thread e processo -- para acesso de leitura, contanto que a DACL do objeto conceda a eles acesso de leitura. Isso significa que um processo executando um IL baixo pode abrir qualquer arquivo acessível à conta do usuário no qual está executando. O Modo Protegido do Internet Explorer usa ILs para ajudar a impedir que o malware que o infecta modifique as configurações de conta do usuário, mas não impede que o malware leia os documentos do usuário.
Os objetos de thread e processo são exceções porque sua diretiva de integridade também inclui Sem Leitura. Isso significa que o IL de um processo deve ser igual ou superior ao IL do processo ou thread que deseja abrir e o DACL deve conceder a ele os acessos que ele deseja para que a abertura tenha êxito. Supondo que as DACLs permitam o acesso desejado, a Figura 19 mostra os acessos que os processos têm a outros processos e objetos, executando em IL médio e baixo.
Figura 19 Acessos a processos e objetos
Figura 19 Acessos a processos e objetos
O subsistema de mensagens do Windows também honra os níveis de integridade para implementar a UIPI impedindo que um processo envie tudo menos algumas mensagens de janelas informacionais para as janelas de um processo com um IL superior. Isso proíbe que os processos de usuário padrão conduzam uma entrada em janelas de processos elevados ou destrua um processo elevado por enviar a ele mensagens mal formadas que disparam estouros de buffer internos. Os processos podem escolher permitir que mensagens adicionais passem a proteção chamando a API ChangeWindowMessageFilter. A UIPI também bloqueia os ganchos da janela, impedindo que afetem as janelas de processos IL superiores de forma que um processo de usuário padrão não possa registrar as teclas digitadas que os usuários pressionam em um aplicativo administrativo, por exemplo.

Limites de segurança e elevações
É importante estar ciente que as elevações UAC são conveniências e não limites de segurança. Um limite de segurança requer que a diretiva de segurança defina o que pode passar pelo limite. As contas de usuário são um exemplo de um limite de segurança no Windows, porque um usuário não pode acessar os dados pertencentes a outro usuário sem ter a permissão daquele usuário.
Como as elevações não são limites de segurança, não há garantias de que o malware em execução em um sistema com direitos de usuário padrão não possam comprometer um processo elevado para obter direitos administrativos. Por exemplo, as caixas de diálogo de elevação somente identificam o executável que será elevado; elas não dizem nada sobre o que será feito quando ele executar. O executável irá processar argumentos de linha de comando, carregar DLLs, abrir arquivos de dados e comunicar-se com outros processos. Qualquer uma dessas operações pode perfeitamente permitir que malware comprometa o processo elevado e assim obter direitos administrativos.
Executando em uma área de segurança com IL baixo
O Modo Protegido do Internet Explorer executa em IL baixo para criar uma cerca em torno do malware que pode infectar seu processo. Isso impede que o malware altere as configurações de conta de usuário e se instale em um local de inicialização automática. Você pode usar o utilitário PsExec da Sysinternals, em conjunto com o -l switch, para iniciar processos arbitrários com IL baixo para explorar a área de segurança. A Figura B mostra como um prompt de comando executando com IL baixo não pode criar um arquivo no diretório temporário do usuário, que tem um IL médio, mas pode fazer isso no diretório temporário do Internet Explorer, que tem um IL baixo.
Figura BO prompt de comando só pode criar arquivos em IL similar

Processos AAM elevados são especialmente suscetíveis a serem comprometidos porque executam na mesma conta de usuário que os processos de direito padrão do usuário AAM e compartilham o perfil de usuário. Muitos aplicativos lêem configurações e carregam extensões registradas no perfil de um usuário, oferecendo oportunidades para que malware faça elevação. Por exemplo, as caixas de diálogo de controle comum carregam extensões Shell configuradas na chave de registro de um usuário (em HKEY_CURRENT_USER), portanto o malware pode se adicionar como uma extensão para carregar em qualquer processo elevado que use essas caixas de diálogo.
Mesmo processos elevados de contas de usuário padrão podem perfeitamente ser comprometidos em função do estado compartilhado. Todos os processos executando em uma sessão de logon compartilham o namespace interno onde o Windows armazena objetos como eventos, exclusões mútuas, semáforos, e memória compartilhada. Se o malware sabe que um processo elevado tentará abrir e ler um objeto de memória compartilhado específico quando o processo é iniciado, pode criar o objeto com conteúdos que disparam um estouro de buffer para injetar código no processo elevado. Esse tipo de ataque é relativamente sofisticado, mas sua possibilidade impede que elevações OTS sejam um limite de segurança.
O resultado é que elevações foram introduzidas como uma conveniência que encoraja usuários que desejam acessar direitos administrativos a executarem por padrão com direitos de usuário padrão. Os usuários aguardando as garantias de um limite de segurança podem compensar a conveniência usando uma conta de usuário padrão para tarefas cotidianas e o FUS (Troca Rápida de Usuários) para uma conta de administrador dedicada para realizar operações administrativas. Por outro lado, os usuários que desejam abdicar de segurança em favor da conveniência podem desabilitar o UAC em um sistema na caixa de diálogo Contas de Usuário no Painel de Controle, mas devem estar cientes de que isso também desabilita o Modo Protegido do Internet Explorer.

Conclusão
Executar como usuário padrão tem vários benefícios, incluindo ajudar a proteger sistemas de danos acidentais ou deliberados e proteger de acesso não autorizado os dados e a integridade de usuários compartilhando um sistema. As várias alterações e tecnologias do UAC resultarão em uma grande mudança no modelo de uso do Windows. Com o Windows Vista, os usuários do Windows podem pela primeira vez realizar tarefas cotidianas e executar a maioria do software usando direitos de usuário padrão, e muitas empresas agora podem implantar contas de usuário padrão.

Mark Russinovich é um colega da área técnica da Microsoft na divisão de plataforma e serviços. Ele é co-autor do livro Microsoft Windows Internals (Microsoft Press, 2004) e palestrante assíduo em conferências de desenvolvedores e TI. Russinovich uniu-se à Microsoft com a recente aquisição da empresa de que foi co-fundador, a Winternals Software. Ele criou também a Sysinternals, onde publicou os utilitários Process Explorer, Filemon e Regmon.
© 2007 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..


 Seguran&#231;a: Chaves para a prote&#231;&#227;o de dados com a criptografia de unidade de disco BitLocker
Segurança Byron Hynes

Chaves para a proteção de dados com a criptografia de unidade de disco BitLocker
Visão geral:
  • Criptografia de volume total
  • Chaves BitLocker
  • Configurando BitLocker

A Criptografia de Unidade de Disco do Windows BitLocker é certamente um dos recursos mais comentados do Windows Vista. No entanto, a maioria das pessoas ainda não teve oportunidade de testar o BitLocker e saber, em primeira mão,
o que ele faz e como funciona – especialmente em um computador com um Trusted Platform Module (TPM). Neste artigo, eu apresento as noções básicas do BitLocker™ para que você possa avaliar seu potencial e incluí-lo em seu planejamento de atualizações. Começarei com algumas informações contextuais e conceituais e, em seguida, analisarei a habilitação do BitLocker, a recuperação dos dados, a administração e a forma como ele pode ajudar no fim da vida útil de um computador. Para compreender melhor a terminologia usada aqui, consulte a barra lateral "Discos e Volumes".
Discos e volumes
Muitas vezes, a terminologia relacionada a discos e volumes pode ser confusa. A seguir está um glossário resumido para consulta.
Partição Partição é uma seção de um disco rígido físico. Trata-se de uma estrutura lógica definida em uma tabela de partição armazenada no disco.
Volume Volume é uma estrutura lógica do Windows formada por uma ou mais partições e definida por um componente do Windows chamado gerenciador de volumes. Exceção feita ao gerenciador de volumes e aos componentes de inicialização, o restante do sistema operacional e os aplicativos trabalham com volumes, e não com partições. No caso dos sistemas operacionais clientes Windows, inclusive o Windows Vista, as partições e os volumes normalmente têm uma relação um-para-um. Nos servidores, um volume costuma ser formado por várias partições como, por exemplo, em uma configuração RAID típica.
Partição Ativa Apenas uma partição pode ser marcada como sendo a partição ativa por vez. Trata-se da partição que contém o setor de inicialização usado para iniciar o sistema operacional. Às vezes, a partição ativa é chamada de partição do sistema ou de volume do sistema, mas não confunda esses termos com o Volume do sistema operacional Windows.
Volume do sistema operacional Windows Este volume contém a instalação do Windows, inclusive as pastas System e System32. Antes do lançamento do Windows Vista, era usado o termo partição de inicialização (e ainda costuma ser). O termo Volume do sistema operacional Windows é mais claro e evita a confusão permanente entre partição de inicialização e partição do sistema. Antigamente, os instrutores costumavam pedir para que os alunos não se esquecessem de que você "inicializa a partir da partição do sistema e encontra os arquivos de sistema na partição de inicialização".
Antes do Windows Vista, o volume do sistema operacional Windows (também conhecido como a partição de inicialização) e a partição ativa (também conhecida como a partição do sistema) eram a mesma coisa, porque os discos rígidos na maioria dos clientes eram configurados como uma única partição grande. Na Figura A, é possível ver as funções atribuídas a cada partição ou volume no console do Gerenciamento de Disco do Windows Vista.
Figura A Funções da Partição
Figura A Funções da Partição

O BitLocker realmente faz duas coisas que se complementam, mas distintas. Primeiramente, o BitLocker fornece a criptografia de volume total ao volume do sistema operacional Windows®. Em seguida, em computadores com um TPM compatível, o BitLocker oferece uma forma de validar a integridade dos componentes de inicialização antecipada, antes de permitir que o Windows Vista™ seja iniciado.
Para usar toda a funcionalidade do BitLocker, o seu computador deve ter um microchip TPM compatível e um BIOS. Compatível quer dizer um TPM versão 1.2 e um BIOS compatível com TPM e STRM (Static Root of Trust Measurement) conforme a definição do TCG (Trusted Computing Group). No entanto, mesmo computadores sem um TPM compatível e BIOS podem usar a criptografia do BitLocker.

Criptografia de volume total
O BitLocker fornece a criptografia de volume total para garantir que todos os dados gravados no volume do sistema operacional Windows sejam criptografados. Ele é fundamental para proteger as informações confidenciais armazenadas nos computadores da sua organização, especialmente laptops e computadores móveis.
Computadores móveis são perdidos ou roubados diariamente. Com o aumento da capacidade da computação portátil e uma força de trabalho móvel cada vez maior, um único funcionário pode transportar centenas de gigabytes dos segredos comerciais da sua organização, documentos confidenciais ou PII (informações de identificação pessoal) dos clientes. Qualquer pesquisa lhe dirá que grande parte desses dados está sendo perdida. (A Privacy Rights Clearinghouse informa que mais de 104 milhões de registros contendo informações pessoais foram perdidos ou divulgados somente desde 2005.)
A maioria das organizações já cumpre mandatos legais e corporativos para a proteção de vários tipos de informações privadas e, mesmo que ainda não tenha sido legalmente solicitado, é provável que você tenha um bom interesse comercial nisso.

Por que criptografar todo o volume?
Caso seja um administrador do Windows experiente, você certamente já está familiarizado com as opções de criptografia baseadas no Windows como, por exemplo, o EFS (Sistema de Arquivos com Criptografia) e talvez com a criptografia e a proteção oferecidas pelo RMS (Rights Management Services). A grande diferença do BitLocker é que, uma vez habilitado, ele é automático, transparente e inclui todo o volume.
Por exemplo, com o EFS, você precisa indicar especificamente os arquivos e as pastas a serem protegidos. No Windows Vista, há algumas opções novas que tornam o EFS mais flexível, e o EFS e o RMS abordam alguns cenários deixados de lado pelo BitLocker. Tanto o EFS quanto o RMS exigem uma configuração significativa do administrador e não foram projetados para proteger tudo o que está armazenado no volume.
Por outro lado, o BitLocker criptografa tudo o que for gravado em um volume protegido por ele, inclusive o próprio sistema operacional, o Registro, os arquivos de hibernação e de paginação, os aplicativos e os dados usados pelos aplicativos.
Há três itens não criptografados: o setor de inicialização, todos os setores defeituosos já marcados como sendo ilegíveis e os metadados do volume. Os metadados do volume consistem em três cópias redundantes dos dados usados para gerenciar o BitLocker, inclusive informações estatísticas sobre o volume e cópias protegidas de algumas chaves de descriptografia. Esses itens não exigem criptografia porque não são exclusivos, importantes ou identificáveis em termos pessoais.
A criptografia de volume total protege contra ataques offline – o tipo de ataque montado com a tentativa de ignorar o sistema operacional. Por exemplo, um ataque offline comum é roubar um computador, remover o disco rígido e instalá-lo como uma unidade secundária em outro computador (executando uma cópia diferente do Windows ou um outro sistema operacional) para evitar permissões NTFS e senhas de usuário. Não é possível ler um volume protegido por BitLocker usando esse tipo de ataque.

Como o BitLocker criptografa os dados
O BitLocker usa o algoritmo AES (Padrão Avançado de Criptografia) com chaves de 128 bits. Tendo em vista maior precisão, as chaves podem ser aumentadas para 256 bits usando a Diretiva de Grupo ou o provedor do WMI do BitLocker.
Todos os setores do volume são criptografados individualmente, com uma parte da chave de criptografia sendo derivada do próprio número do setor. Isso significa que dois setores que contenham dados descriptografados idênticos resultarão na gravação de bytes criptografados diferentes no disco, o que torna muito mais difícil a tentativa de descobrir as chaves criando e criptografando informações conhecidas.
Antes dos dados serem criptografados usando o AES, o BitLocker também usa um algoritmo chamado difusor. Sem abordar a criptografia, uma descrição simples do difusor é que ele garante que mesmo alterações feitas de última hora no texto não criptografado resultem na alteração de todo o setor no texto cifrado criptografado. Isso dificulta muito mais a descoberta de chaves ou dados por parte um invasor.
Caso você esteja interessado nos detalhes do algoritmo de criptografia do BitLocker, leia o documento de Neil Ferguson a respeito, "AES-CBC + Difusor Elefante: um Algoritmo de Criptografia de Disco para o Windows Vista".

Chaves do BitLocker
Sempre que se lida com criptografia, você precisa conhecer as chaves, e com o BitLocker não é diferente. O BitLocker usa uma arquitetura de chaves elegante, embora um pouco complexa.
Os próprios setores são criptografados usando uma chave chamada FVEK (chave de criptografia do volume total). No entanto, a FVEK não é usada pelos usuários ou permanece acessível a eles. Ela é, por sua vez, criptografada com uma chave chamada VMK (chave mestre de volume). Esse nível de abstração oferece alguns benefícios exclusivos, embora possa dificultar um pouco mais a compreensão do processo. A FVEK é mantida no mais absoluto segredo porque, se ela fosse comprometida, todos os setores precisariam ser criptografados novamente. Por ser demorada, essa é uma operação que você deseja evitar. Na verdade, o sistema funciona com a VMK.
A FVEK (criptografada com a VMK) é armazenada no próprio disco, como parte dos metadados do volume. Embora seja armazenada localmente, a FVEK jamais é gravada no disco sem criptografia.
A VMK também é criptografada, ou "protegida", mas por um ou mais protetores de chave. O protetor de chave padrão é o TPM. O uso de um TPM é abordado na seção seguinte sobre a verificação da integridade. Uma senha de recuperação também é criada como sendo um protetor de chave, para emergências. A recuperação também é abordada depois.
É possível combinar o TPM com um Nº de senha ou com uma chave parcial armazenada em uma unidade USB, tendo em vista uma maior segurança. Essas são formas de autenticação de dois fatores. Caso o computador não tenha um chip TPM compatível e BIOS, o BitLocker pode ser configurado para armazenar um protetor de chave integralmente em uma unidade USB. Isso é chamado de chave de inicialização.
O BitLocker pode ser desabilitado sem a descriptografia dos dados; nesse caso, a VMK só é protegida por um novo protetor de chave armazenado sem criptografia. Observe que essa chave limpa permite ao sistema acessar a unidade como se ela estivesse desprotegida.
Durante a inicialização, o sistema procura um protetor de chave apropriado consultando o TPM, verificando as portas USB ou, se necessário, avisando o usuário (o que é chamado de recuperação). Encontrar um protetor de chave permite que o Windows descriptografe a VMK, que descriptografa a FVEK, que descriptografa os dados armazenados em disco. O processo é mostrado na Figura 1.
Figura 1 Processo de inicialização padrão do BitLocker
Figura 1 Processo de inicialização padrão do BitLocker

Verificação da integridade
Como os componentes na parte anterior do processo de inicialização devem estar disponíveis sem criptografia de forma que o computador possa ser inicializado, um invasor poderia alterar o código desses componentes de inicialização antecipada (pense no rootkit) e obter acesso ao computador, mesmo que os dados no disco tenham sido criptografados.
Ao usar esse tipo de ataque, um invasor poderia obter acesso a informações confidenciais como, por exemplo, chaves do BitLocker ou senhas do usuário, e utilizá-las para burlar outras proteções de segurança.
Evitar esse tipo de ataque era uma das metas originais do programa, e a equipe criou o BitLocker. De alguma forma, a criptografia era quase o meio para um fim. A criptografia de volume total permite que o BitLocker proteja a integridade do sistema e impeça a inicialização do Windows caso os componentes da inicialização antecipada tenham sido alterados.
Em computadores equipados com um TPM compatível, sempre que o computador é inicializado, todos os componentes de inicialização antecipada – como o BIOS, o MBR (registro mestre de inicialização), o setor de inicialização e o código do gerenciador de inicialização – examinam o código a ser executado, calculam um valor de hash e armazenam o valor em registros específicos do TPM, chamados de PCRs (registros de configuração de plataforma). Uma vez armazenado em um PCR, o valor não pode ser substituído ou apagado, a menos que o sistema seja reinicializado. O BitLocker usa o TPM e os valores armazenados nos PCRs para proteger a VMK.
Um TPM pode criar uma chave vinculada a valores de PCR específicos. Quando esse tipo de chave é criado, o TPM criptografa a chave e somente ele pode descriptografá-la. Além disso, porém, o TPM só descriptografa a chave caso os valores atuais do PCR correspondam aos valores especificados quando a chave foi criada. Isso se chama vinculação da chave ao TPM.
Por padrão, o BitLocker vincula as chaves às medidas da CRTM (Core Root of Trust Measurement), ao BIOS e a todas as extensões da plataforma, ao código ROM de opção, ao código MBR, ao setor de inicialização NTFS e ao gerenciador de inicialização. Se algum desses itens for alterado inesperadamente, o BitLocker bloqueará a unidade e impedirá que ela seja acessada ou descriptografada.
Por padrão, o BitLocker é configurado para procurar e usar um TPM. É possível usar uma Diretiva de Grupo ou uma configuração de diretiva local para permitir que o BitLocker funcione sem um TPM e armazene chaves em uma unidade flash USB externa, ainda que, sem o TPM, o BitLocker não possa verificar a integridade do sistema.

Habilitando o BitLocker pela primeira vez
O BitLocker está disponível no Windows Vista Enterprise e no Windows Vista Ultimate. (O BitLocker também será um componente opcional incluído na próxima versão do Windows Server®, codinome "Longhorn".)
A seguinte descrição pressupõe que você tenha um computador com um TPM compatível e disponível para teste. Caso você queira habilitar o BitLocker em um computador sem um TPM, siga as etapas listadas na barra lateral "Usando o BitLocker sem um TPM".
Usando o BitLocker sem um TPM
O BitLocker está configurado, por padrão, para usar um TPM e, se você não tiver um, o Windows pronto para ser usado não permitirá a habilitação do BitLocker. No entanto, o seguinte procedimento, retirado do Windows BitLocker Drive Encryption Step-by-Step Guide (Guia Passo a Passo da Criptografia de Unidade do Windows BitLocker), permitirá que você use o BitLocker sem um TPM.
Para realizar essas tarefas, você dever feito o logon como administrador. Mesmo sem um TPM, o computador deve ser compatível com a leitura a partir de uma unidade flash USB durante o processo de inicialização. Além disso, você deve ter uma unidade flash USB disponível ao habilitar o BitLocker e sempre que reiniciar o computador.
Siga estas etapas para ativar a Criptografia de Unidade de Disco BitLocker em um computador sem um TPM compatível:
  1. Clique em Iniciar, digite gpedit.msc na caixa Iniciar Pesquisa e pressione ENTER.
  2. Se a caixa de diálogo Controle de Conta de Usuário for exibida, verifique se a ação proposta é a que foi solicitada e, em seguida, clique em Continuar.
  3. Na árvore do console Editor de Objeto de Diretiva de Grupo, clique em Diretiva do Computador Local, em Modelos Administrativos, em Componentes do Windows e, em seguida, clique duas vezes em Criptografia de Unidade de Disco BitLocker.
  4. Clique duas vezes em Configuração do Painel de Controle: Habilitar opções avançadas de inicialização. A caixa de diálogo Configuração do Painel de Controle: Habilitar opções avançadas de inicialização é exibida.
  5. Selecione a opção Habilitadas, marque a caixa de seleção Permitir BitLocker sem um TPM compatível e clique em OK. Como você alterou a configuração da diretiva, é possível usar uma chave de inicialização em lugar de um TPM.
  6. Feche o Editor de Objeto de Diretiva de Grupo.
  7. Para forçar a aplicação imediata da Diretiva de Grupo, é possível clicar em Iniciar, digitar gpupdate.exe /force na caixa Iniciar Pesquisa e, em seguida, pressionar ENTER. Aguarde a conclusão do processo.

Uma parte importante da habilitação do BitLocker é ter a certeza de que os volumes estão configurados corretamente. O BitLocker exige que a partição ativa esteja descriptografada para que o setor de inicialização, o gerenciador de inicialização e o programa de carregamento do Windows possam ser lidos (esses componentes estão protegidos pelas etapas de integridade do sistema descritas anteriormente). Como os demais componentes do Windows talvez exijam o uso temporário da partição ativa, a Microsoft recomenda que a partição ativa seja de pelo menos 1,5 GB. Também é uma boa idéia configurar as permissões NTFS para que os usuários não possam gravar dados acidentalmente no volume.
O próprio Windows será instalado em um volume secundário maior, que pode ser criptografado. Caso você esteja instalando o Windows em um sistema novo, é possível configurar os volumes seguindo as instruções disponíveis em Guia Passo a Passo da Criptografia de Unidade do Windows BitLocker.
É possível usar a Ferramenta de Preparação de Unidades de Disco BitLocker para ajudar você a configurar o sistema para o BitLocker. Essa ferramenta acaba com o trabalho pesado de configuração das unidades, e está disponível como um Windows Vista Ultimate Extra ou para os clientes que estejam implantando o Windows Vista Enterprise. Para obter instruções detalhadas sobre a Ferramenta de Preparação de Unidades de Disco BitLocker, visite support.microsoft.com/kb/930063.
A Ferramenta de Preparação de Unidades de Disco BitLocker diminui automaticamente o volume (caso você tenha apenas um), cria e ativa a segunda partição, faz todas as alterações necessárias na configuração e move os arquivos de inicialização para o lugar certo.
Uma vez configurados os volumes, habilitar o BitLocker é simples. Na seção Segurança do Painel de Controle, clique no ícone Criptografia de Unidade BitLocker. Depois que você confirma o recebimento do aviso de consentimento do UAC, uma tela semelhante à Figura 2 aparece.
Figura 2 Habilitando o BitLocker
Figura 2 Habilitando o BitLocker
A seqüência exata do que acontece em seguida irá variar de acordo com o estado do chip TPM do computador. Se o chip TPM não for inicializado, o Assistente de Inicialização do TPM será executado. Siga as instruções para inicializar o TPM, o que incluirá a reinicialização do computador.
Após a inicialização do TPM, a página Salvar senha de recuperação aparece, conforme mostra a Figura 3. Para poder recuperar os dados em caso de falha do TPM ou outro problema, você precisa de uma senha de recuperação. Essa página permite que você salve uma senha de recuperação em uma unidade flash USB ou em um disco local ou na rede, ou imprima-a para mantê-la em segurança. Você deve escolher pelo menos uma dessas opções, sendo possível optar por salvar várias cópias. Depois que a senha de recuperação for salva, o botão Avançar será habilitado. Clique nele.
Figura 3 Salvando a senha de recuperação
Figura 3 Salvando a senha de recuperação
A página Criptografar o volume de disco selecionado aparece, e você pode optar executar ou não uma verificação do sistema antes do início da criptografia. A verificação do sistema exigirá a reinicialização, mas se trata da melhor forma de verificar ser o TPM, o BIOS e as portas USB funcionarão corretamente com o BitLocker. Após a reinicialização, se algum problema for detectado, você verá uma mensagem de erro. Do contrário, a barra de status Criptografia em Andamento é exibida.
É isso. A criptografia será concluída em segundo plano, e você pode continuar usando o computador. Depois que a criptografia inicial for concluída, uma mensagem o informa a respeito disso. Também é possível monitorar permanentemente o status de conclusão da criptografia do volume do disco, passando o cursor sobre o ícone Criptografia de Unidade BitLocker da barra de ferramentas na parte inferior da tela. Para obter mais detalhes, você pode consultar o Guia Passo a Passo mencionado anteriormente.
Alguns usuários ficaram surpresos ao notar que o BitLocker não faz solicitações ao usuário ou qualquer outro tipo de interrupção óbvia durante a inicialização do computador. Isso porque, em sua configuração padrão, o BitLocker depende do TPM para confirmar a integridade do sistema antes de desbloquear o volume. Isso é automático e transparente ao usuário.
É possível configurar o BitLocker para exigir a entrada de um Nº da senha ou a presença de uma chave armazenada em uma unidade flash USB durante a inicialização. Isso aumenta a segurança e é o recomendável nas situações em que a maior segurança é mais importante do que a entrada incômoda do Nº da senha. Na minha opinião, ela sempre é. (Em outras palavras, o meu desktop exige um Nº da senha e o meu laptop, uma chave USB.)

Recuperação do BitLocker
Quando se lida com a criptografia – especialmente em ambientes comerciais ou corporativos –, é essencial que você tenha uma forma para que um usuário autorizado obtenha novamente seus dados, mesmo que os métodos de acesso normais ou as chaves não estejam disponíveis. O BitLocker chama isso de recuperação.
Se algo for alterado inesperadamente nos componentes de inicialização antecipada, se você perder uma chave de inicialização USB ou se um usuário esquecer seu Nº da senha, o BitLocker não poderá concluir o processo normal de inicialização. O BitLocker manterá o volume bloqueado, e não será possível inicializar o Windows. Na verdade, o código do BitLocker no gerenciador de inicialização apresentará um texto na tela. Caso uma senha de recuperação tenha sido salva em uma unidade flash USB (às vezes, chamada de chave de recuperação), uma tela semelhante à Figura 4 aparece.
Figura 4 Procurando uma chave de recuperação
Figura 4 Procurando uma chave de recuperação
Para que o BitLocker leia a partir de uma unidade flash USB, ela precisa estar conectada durante a inicialização. Dessa forma, caso você tenha uma unidade flash USB com uma senha de recuperação, insira-a e pressione ESC. Caso você não tenha, pressione Enter para ver a tela mostrada na Figura 5. Essa tela também aparece caso uma chave de recuperação jamais tenha sido salva em uma unidade USB.
Figura 5 Digitando uma senha do BitLocker
Figura 5 Digitando uma senha do BitLocker
O BitLocker agora está procurando uma senha numérica de 48 dígitos capaz de desbloquear a unidade. Esse número aparece na página caso você tenha optado por imprimir a senha de recuperação, e ele também será armazenado em um arquivo se você salvar a senha de recuperação em uma pasta.
A forma mais simples de gerenciar senhas de recuperação em uma empresa é armazenando-as automaticamente no Active Directory®. É possível obter todos os detalhes sobre como fazer isso em go.microsoft.com/fwlink/?LinkId=87067.
Em um próximo artigo, falarei a respeito da gerenciabilidade do BitLocker, mas, como parte desta visão geral, você deve saber que o BitLocker é acompanhado de um provedor WMI completo que permite que o BitLocker (e o TPM) seja gerenciado por meio de qualquer sistema WBEM (Web-Based Enterprise Management) compatível com o WMI. Isso significa que também é possível criar scripts para o BitLocker usando qualquer linguagem capaz de acessar objetos do WMI como, por exemplo, VBScript ou Windows PowerShell™.
O BitLocker também é acompanhado de uma ferramenta de linha de comando chamada manage-bde.wsf que usa o provedor WMI para permitir que você gerencie o BitLocker em computadores locais ou remotos. Para obter mais informações, abra um prompt de comando com execução privilegiada e digite manage-bde.wsf /?.

Descomissionamento seguro
Há um momento em que todo computador precisa ser descomissionado. As empresas costumam gastar quantias significativas e fazer várias tentativas para garantir que as unidades de disco estejam totalmente corrigidas antes de serem liberadas. A maioria dos processos que removem dados confidenciais das unidades de disco é demorada, cara ou resulta na destruição permanente do hardware. O BitLocker oferece outras opções mais econômicas.
Em vez de se preocupar com a remoção dos dados após o fato, o BitLocker ajuda a garantir que os dados confidenciais não estão armazenados no disco de maneira insegura, em primeiro lugar. Como tudo o que está gravado no disco está criptografado, os dados podem se tornar total e permanentemente inacessíveis com a destruição de todas as cópias das chaves de criptografia. O disco rígido propriamente dito permanece totalmente intacto para reutilização.
É possível escolher uma dentre várias abordagens para o descomissionamento de volumes que foram protegidos pelo BitLocker. Você pode optar por excluir todas as cópias das chaves dos metadados do volume enquanto as mantém arquivadas em um local centralizado e seguro. Isso pode permitir que os sistemas sejam transportados com segurança ou sejam descomissionados temporariamente caso permaneçam inutilizados por períodos longos. Isso garante que, ainda assim, os usuários autorizados possam acessar os dados, mas não os usuários não autorizados como, por exemplo, novos proprietários do equipamento.
Também é possível optar por excluir todas as cópias das chaves dos metadados do volume e de todos os arquivos como, por exemplo, do Active Directory (talvez criando novas chaves não armazenadas). Como não há nenhuma chave de descriptografia, ninguém pode recuperar os dados.
Em ambos os casos, a remoção e a destruição das chaves contidas nos metadados do volume são praticamente instantâneas e podem ser realizadas em vários sistemas por um administrador. É preciso dedicar um tempo mínimo e algum esforço, mas isso resulta em um nível bem alto de proteção permanente. O utilitário de formatação do Windows Vista foi atualizado para que um comando de formatação exclua os metadados do volume e substitua esses setores a fim de excluir com segurança todas as chaves do BitLocker.

Algumas considerações finais
O BitLocker é uma ferramenta eficiente, projetada para a proteção contra ameaças específicas e realiza um excelente trabalho. No entanto, seria um equívoco esperar que o BitLocker proteja contra todas as ameaças. É absolutamente essencial que você continue usando defesas e controles apropriados como, por exemplo, senhas fortes.
Saiba que o BitLocker está voltado para ataques offline. Isso significa que, caso o Windows esteja em execução, é sinal de que o BitLocker desbloqueou o volume. Em outras palavras, o BitLocker não oferece proteção para um sistema em execução. Tecnologias como, por exemplo, EFS e RMS complementam o BitLocker protegendo as informações com o sistema operacional em execução.
Para obter mais informações sobre o BitLocker, visite o site da Microsoft em technet.microsoft.com/windowsvista/aa905065.aspx. Para obter mais especificações do TPM e do TCG, visite a seção Especificações do TPM do site do TCG em go.microsoft.com/fwlink/?LinkId=72757.

Byron Hynes trabalha no grupo de Assistência ao usuário do Windows Server da Microsoft. Ele já trabalhou como consultor e instrutor. Você pode contatá-lo pelo email bhynes@microsoft.com.


 Seguran&#231;a: Explorando o Firewall do Windows
Segurança Steve Riley

Explorando o Firewall do Windows
Visão geral:
  • Proteção de entrada X proteção de saída
  • A Plataforma de Filtragem do Windows
  • A interface de Segurança Avançada
  • Perfis de rede

Nos idos da era paleocomputacional, ninguém jamais pensou em instalar firewalls em computadores individuais. E quem precisava? Praticamente ninguém tinha ouvido falar da Internet, não havia TCP/IP à vista e os protocolos de LAN não iam além do prédio ou do campus. Os dados importantes permaneciam
no mainframe ou os servidores de arquivos – as informações que as pessoas mantinham em seus computadores desktop dificilmente eram de missão crítica, e o próprio peso do computador assegurava um certo nível de segurança física. Se havia uma conexão com a Internet disponível, era bem provável que houvesse alguns conversores de protocolo no caminho e um roteador de filtragem de pacotes (quero dizer, "firewall") na borda, possivelmente configurado com muitas regras e exceções.
Os ambientes computacionais modernos são totalmente diferentes dos oriundos dos velhos tempos. Tudo está conectado à Internet (compatível com TCP/IP agora), e os dispositivos portáteis agora são o padrão. É possível que o seu empregador tenha lhe dado um laptop não porque ele se preocupa com você, mas porque ele está preocupado em conseguir mais de você – eles esperam que você trabalhe sempre que tiver cinco minutos sobrando e uma conexão Wi-Fi. Os laptops podem custar mais do que os desktops, mas esse investimento é certamente recuperado em produtividade. Veja, é a portabilidade que os torna tão atraente – para você e para os seus adversários.
Pense nisso: do tempo total em que o seu laptop permanece ligado e conectado a alguma rede, qual é a porcentagem de conexão com a sua rede corporativa? Se você for como eu, talvez 20 por cento, no máximo. Isso significa que em apenas 20 por cento do tempo o meu laptop está seguro dentro dos limites da rede corporativa da Microsoft, protegido pelas defesas no perímetro da rede contra ataques externos. Mas e os 80 por cento do tempo em que o meu laptop está, para todos os fins práticos, conectado diretamente à Internet? (E eu costumo estar conectado com freqüência às redes mais perigosas do mundo: a LAN do hotel durante uma conferência sobre segurança de computadores!) E naqueles momentos em que eu estou conectado à rede corporativa, e as ameaças oferecidas aos demais computadores dentro desse ambiente?
Os controles de segurança passam a seguir – às vezes, a uma grande distância – as ameaças. Como os vírus eram um problema do cliente, porque as pessoas trocavam disquetes, os programas antivírus apareceram primeiramente nos clientes. Depois, como o email se tornou popular e o malware evoluiu até worms que contavam com a distribuição dos emails, surgiram os programas anti-malware nos gateways de email. Com o crescimento da Web, o malware se expandiu até os Cavalos de Tróia e o anti-malware seguiu até os servidores proxy de acesso à Internet. Trata-se de uma linha evolutiva bem compreendida que ninguém contesta.
Agora apliquemos a mesma lógica aos firewalls. Embora um firewall na borda da sua rede oferecesse proteção suficiente contra as ameaças do passado, este não é mais o caso, uma vez que elas são diferentes, estando mais sofisticadas e mais predominantes. Isso sem mencionar que os dispositivos e os estilos de trabalho são muito diferentes em relação aos do passado. Muitos computadores transportam informações sigilosas armazenadas localmente e eles passam muito tempo longe da rede corporativa (ou seja, fora da borda). Por isso, o firewall deve evoluir até um mecanismo de proteção do cliente individual. Não se confunda: os firewalls para cliente não são mais opcionais. Para proteger os computadores da sua própria rede corporativa e da Internet, os firewalls para cliente são obrigatórios.

Firewalls para cliente e teatro da segurança
Muitas pessoas não perceberam que a versão inicial do Windows® XP incluía um firewall para cliente. Isso não é surpreendente, porque o firewall permanecia desativado por padrão e também estava em meio a muitos cliques do mouse. Com sua maneira própria às escondidas, o firewall apenas aparecia sem nenhuma indicação real de sua finalidade ou orientações sobre como usá-lo. Mas funcionava. Se tivesse habilitado esse firewall, você estaria a salvo do Nimda, Slammer, Blaster, Sasser, Zotob e de tudo o que tentasse forçar um tráfego não solicitado em sua porta de rede. Percebendo a importância da proteção ao cliente, o Windows XP Service Pack 2 (SP2) habilitou o firewall por padrão, criou dois perfis (Internet e rede corporativa) e permitiu a habilitação da Diretiva de Grupo.
Infelizmente, duas barreiras reduziram a adoção do firewall do Windows XP SP2: as preocupações quanto aos aplicativos e o teatro da segurança. Muitas pessoas tinham o receio de que o firewall faria com que seus aplicativos deixassem de funcionar corretamente. Porém, isso dificilmente acontecia por conta do design do firewall. O firewall permitia que todo o tráfego de saída deixasse o computador, mas bloqueava todo o tráfego de entrada que não vinha como resposta a alguma solicitação de saída anterior. A única vez em que esse design interrompia um aplicativo em um cliente era quando o aplicativo criava um soquete de escuta e esperava receber solicitações de entrada. O firewall do Windows XP possibilitava configurações simples das exceções para programas ou portas (mas, infelizmente, não por uma Diretiva de Grupo).
O maior empecilho era o teatro da segurança feito pelos fabricantes dos demais firewalls para cliente. Algumas pessoas achavam que o design do firewall do Windows XP – ao permitir, especificamente, que todo o tráfego de saída deixasse o computador de maneira irrestrita – tinha funcionalidade insuficiente para um firewall de cliente. O argumento era de que um firewall para cliente deveria ao menos bloquear todo o tráfego, de entrada e de saída, a menos que o usuário concedesse especificamente uma permissão.
Agora pensemos nisso por um instante. Surgem dois cenários.
  • Se você for o administrador local e estiver infectado por um malware, este simplesmente desabilitará o firewall. 0wn3d para você.
  • Se você for o administrador local e for infectado por um malware, este fará com que um firewall de terceiros mostre uma caixa de diálogo em um idioma estrangeiro relacionado a portas e endereços IP e com uma pergunta muito séria: "Deseja permitir isso?" É claro que a única resposta é "Sim, seu computador idiota, e veja se para de me encher!". E, junto com essa caixa de diálogo, some também a sua segurança. Ou, o que é mais comum, o malware seqüestrará uma sessão existente de um programa já autorizado, e você sequer verá a caixa de diálogo. Mais uma vez, 0wn3d para você.
Existe uma máxima importante da segurança que você deve compreender: a proteção deve estar no ativo que você deseja proteger, e não na coisa da qual está tentando se proteger. A abordagem correta é executar o simples, porém efetivo, firewall do Windows em todos os computadores da sua organização, para protegê-los de todos os demais computadores do mundo. Se tentar bloquear as conexões de saída de um computador já comprometido, como você poderá ter a certeza de que o computador está realmente fazendo o que você pediu? A resposta: você não poderá. A proteção de saída é um teatro da segurança – trata-se de um artifício que só lhe dá a impressão de aumentar a segurança sem fazer nada que efetivamente aumente-a. É por isso que não havia proteção da saída no firewall do Windows XP e é pelo mesmo motivo que ela não está presente no firewall do Windows Vista™. (Falarei mais a respeito do controle da saída no Windows Vista daqui a pouco.)

O que há de novo no Windows Vista?
A Plataforma de Filtragem do Windows, parte da nova pilha de rede, é a base do firewall do Windows Vista. Assim como o Windows XP, o Windows Vista bloqueia o tráfego de entrada por padrão. Dependendo do perfil usado pelo computador, talvez haja algumas exceções padrão para os serviços de rede (abordarei os perfis posteriormente). Se quiser, você pode escrever regras para permitir conexões de entrada. E também como o Windows XP, o Windows Vista permite, por padrão, todo o tráfego de saída de processos interativos, mas restringe o tráfego de saída dos serviços que participam da restrição do serviço. E, mais uma vez, é possível escrever regras para bloquear conexões de saída adicionais.
A grande diferença entre o Windows XP e o Windows Vista é a nova interface de Segurança Avançada e o suporte completo da Diretiva de Grupo à configuração e às regras (consulte a Figura 1). A interface do usuário do Painel de Controle ainda está lá, inalterada em grande parte, exceto pelas configurações de logon e do protocolo ICMP (Internet Control Message Protocol), que agora estão na nova interface do usuário. Essa nova interface do usuário, o snap-in do MMC de Segurança Avançada, oferece todos os novos recursos e a flexibilidade. Também há um novo contexto no comando de netsh, netsh advfirewall, por meio do qual é possível criar scripts para inclusões ou exclusões de regras, definir e mostrar diretivas globais e por perfil, além de exibir o estado ativo do firewall. E para vocês, desenvolvedores, FirewallAPI.dll e Netfw.h oferecem controle por programação a todas as configurações do firewall.
Figura 1 Firewall do Windows com Segurança Avançada
Figura 1 Firewall do Windows com Segurança Avançada
O MMC de Segurança Avançada é orientado a assistente. Ao criar uma regra, você pode escolher um destes quatro tipos: programa, porta, predefinida ou personalizada. Eles são explicados na Figura 2.
Figure 2 Quatro tipos de regras (Close Figure 2)

Tipo | Finalidade
Programa | Usado para permitir ou bloquear o tráfego de um determinado programa.
Porta | Usado para permitir ou bloquear o tráfego em determinadas portas TCP ou UDP.
Predefinida | Usa um grupo preexistente de regras para habilitar a funcionalidade do Windows na rede (como, por exemplo, o compartilhamento de arquivos e de impressoras ou a assistência remota).
Personalizada | Expõe todos os botões, indicadores e opções para que você possa configurar uma regra com a especificidade desejada.
Há muitos elementos que você pode consultar ao escrever as regras, todos eles estão disponíveis para regras locais e regras aplicadas por meio da Diretiva de Grupo. São eles: contas e grupos de usuários e computadores do Active Directory®, endereços IP de origem e de destino, portas TCP e UDP de origem e de destino, números do protocolo IP, programas e serviços, tipos de interfaces (com fio, sem fio ou de acesso remoto), além de tipos e códigos ICMP.
Uma vez configurado, o firewall processa as regras na seguinte ordem:
Restrições de serviço Alguns dos serviços no Windows Vista se restringirão para limitar a probabilidade de um outro ataque no estilo Blaster. Uma das restrições é uma lista das portas exigidas pelo serviço. O firewall reforça isso e impede que o serviço use (ou seja configurado para usar) qualquer outra porta.
Regras de segurança da conexão O MMC de Segurança Avançada incorpora o IPsec e o firewall. Todas as regras que incluem as diretivas IPsec são processadas em seguida.
Desconhecimento autenticado Elas permitem que computadores autenticados ignorem outras regras.
Regras de bloqueio Elas bloqueiam explicitamente o tráfego de entrada ou de saída especificado.
Regras de permissão Elas permitem explicitamente o tráfego de entrada ou de saída especificado.
As regras do firewall estão armazenadas no Registro, mas não falarei exatamente onde. Ah, tudo bem, tudo bem... você as encontrará nestes locais:
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy\FirewallRule
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System
Só não edite as regras diretamente no Registro. Se editar, nós acharemos você e venderemos o seu bicho de estimação em um site de leilões! Bem, talvez não, mas a única forma compatível de edição das regras é usar o MMC de Segurança Avançada.

Perfis de rede
O Windows Vista define três perfis de rede: domínio, particular e público. Quando o computador está associado a um domínio e faz o logon com êxito nesse domínio, o computador aplica automaticamente o perfil do domínio – você jamais faz essa opção por conta própria. Quando o computador está conectado a uma rede interna sem um domínio (como uma rede doméstica ou de pequena empresa), você (ou um administrador) deve aplicar o perfil particular. Por fim, quando o computador está conectado diretamente à Internet, você deve aplicar o perfil público.
Como o Windows Vista decide onde colocar o seu computador? Sempre que há uma alteração na rede (digamos que ela receba um novo endereço IP, veja um novo gateway padrão ou obtenha uma nova interface), um serviço chamado NLA (Reconhecimento de Local da Rede) detecta a alteração. Ele cria um perfil de rede – que inclui as informações sobre as interfaces existentes, independentemente de o computador ser autenticado em um controlador de domínio, do endereço MAC do gateway e assim por diante – e atribui um GUID a ele. Em seguida, o NLA notifica o firewall, que aplica a diretiva correspondente (há uma diretiva definida para cada um dos três perfis).
Se esta for uma interface nova que o computador jamais viu e o NLA não escolheu o perfil do domínio, você verá uma caixa de diálogo que lhe pede para indicar a qual tipo de rede você está se conectando. Misteriosamente, há três opções: Residência, Trabalho e Pública. Você pode pensar que Trabalho significa o perfil do domínio, mas não é este o caso. Lembre-se de que você jamais vê o perfil do domínio porque o NLA o seleciona automaticamente quando o computador faz logon em um domínio. Na verdade, tanto Residência e Trabalho correspondem ao perfil particular. Em termos funcionais, eles são equivalentes – apenas os ícones são diferentes. (Observação: para selecionar o perfil particular, você deve ser um administrador local ou poder se elevar a um). Como você esperava, público corresponde ao perfil público.
No Windows Vista, um perfil de rede se aplica a todas as interfaces do computador. Aqui está um resumo rápido da árvore de decisão do NLA:
  1. Examine todas as redes conectadas.
  2. Há alguma interface conectada a uma rede classificada como pública? Em caso positivo, defina o perfil do computador para público e saia.
  3. Há alguma interface conectada a uma rede classificada como particular? Em caso positivo, defina o perfil do computador para particular e saia.
  4. Todas as interfaces vêem um controlador de domínio e o computador fez o logon com êxito? Em caso positivo, defina o perfil do computador para domínio e saia.
  5. Também defina o perfil do computador para público.
O objetivo é selecionar o perfil mais restritivo possível. No entanto, há dois efeitos colaterais óbvios. Primeiro, se a porta Ethernet do computador estiver conectada à rede corporativa e a NIC (placa de interface de rede) estiver conectada a um cybercafé, o computador selecionará o perfil público, e não o perfil do domínio. Segundo, se o computador estiver conectado diretamente à Internet (no perfil público) ou à LAN doméstica (no perfil particular) e você estabelecer uma conexão VPN com a rede corporativa, o computador permanecerá no perfil público ou particular.
O que isso pode significar? A diretiva do firewall para o perfil do domínio inclui regras de assistência remota, administração remota, compartilhamento de arquivos e impressoras etc. Se depender dessas regras para chegar remotamente a um cliente, você não conseguirá caso o cliente tenha escolhido outro perfil. Mas não se desespere – é possível escrever regras de firewall para permitir todas as conexões de entrada necessárias e, em seguida, aplicá-las apenas às conexões VPN. Agora você pode até mesmo administrar os clientes pela VPN, mesmo quando eles não estiverem no perfil do domínio.

Controlando conexões de saída
Anteriormente, eu disse que a forma típica de proteção de saída em firewalls para cliente é apenas um teatro da segurança. No entanto, uma forma do controle de saída é muito útil: controlar administrativamente determinados tipos de tráfego que você sabe que não deseja permitir. O firewall do Windows Vista já faz isso para as restrições de serviço. O firewall permite que um serviço se comunique apenas nas portas que ele afirma serem necessárias e bloqueie todas as demais tentativas do serviço. É possível criar a partir disso, escrevendo regras adicionais que permitam ou bloqueiem tráfego específico de acordo com a diretiva de segurança da organização (consulte a Figura 3).
Figura 3 Novo Assistente de Regras de Entrada
Figura 3 Novo Assistente de Regras de Entrada
Digamos, por exemplo, que você queira proibir os usuários de executar um determinado cliente de mensagens instantâneas. É possível criar uma regra (na Diretiva de Grupo, obviamente) para bloquear as conexões com os servidores de logon desse cliente.
Porém, há limitações práticas nessa abordagem. Por exemplo, o Windows Live™ Messenger (que você ainda deve conhecer como MSN® Messenger) tem vários servidores que podem ser usados no logon, e a lista está sempre em alteração. Além disso, ele retornará à porta 80/tcp se a porta padrão 1863/tcp for bloqueada. Uma regra para bloquear a conexão do Windows Live Messenger com seus servidores de logon seria muito complexa e sempre constante. Digo isso para ilustrar que o controle de saída administrativo pode ser útil, mas não substitui as Políticas de Restrição de Software caso você precise manter um controle firme sobre os usuários do software com permissão para instalação e execução.

Proteja o computador
O perímetro já era. Agora todos os computadores assumem a responsabilidade por sua própria proteção. Assim como o anti-malware passou do cliente para a borda, os firewalls devem passar da borda para o cliente. É possível tomar uma ação imediata habilitando o firewall que você acabou de instalar.
Independentemente dos sistemas executarem o Windows XP ou de você já ter feito a transação para o Windows Vista, o firewall do Windows está disponível a todos clientes e oferecerá a proteção de que você precisa para melhorar a segurança dentro da sua organização – mesmo quando os trabalhadores móveis estiverem a quilômetros de distância do escritório.

Onde aprender mais
  • TechCenter do Windows Vista: Introdução ao Firewall do Windows com Segurança Avançada
  • TechCenter do Windows Vista: Firewall do Windows com Segurança Avançada – Diagnósticos e Solução de Problemas
  • Apresentação da TechEd de Steve Riley para Europa: Firewall do Windows Vista e Aprimoramentos de IPSec
  • The Cable Guy: o Novo Firewall do Windows no Windows Vista e no Windows Server "Longhorn"
  • Laboratórios Virtuais do Firewall do Windows Vista

Steve Riley, estrategista de segurança sênior do Grupo de Computação Confiável da Microsoft e editor colaborador da TechNet Magazine, viaja pelo mundo dando palestras em conferências e ajudando clientes a alcançar e manter a segurança. O último livro que escreveu foi Protect Your Windows Network (Proteja a sua Rede do Windows) (Addison-Wesley, 2005). Você pode contatá-lo pelo email steve.riley@microsoft.com.


 Seguran&#231;a: Novas ACLs aprimoram a seguran&#231;a do Windows Vista
Segurança Jesper Johansson

Novas ACLs aprimoram a segurança do Windows Vista
Visão geral:
  • Novidades nas ACLs
  • Controles mais rígidos sobre o administrador
  • Permissões para instaladores confiáveis
  • Usuários e grupos modificados

A estrutura fundamental das ACLs (listas de controle de acesso) não mudou muito no Windows Vista, mas há algumas alterações pequenas, porém importantes que você precisa conhecer. Algumas alterações
eram necessárias porque, no Windows® XP, as ACLs tinham participação em vários problemas. Em primeiro lugar, a maioria dos usuários executa o Windows XP como administrador. Isso significa que usam uma conta pertencente ao grupo interno Administradores. No caso dos usuários domésticos, isso é praticamente uma certeza, pois todas as contas adicionadas durante a instalação tornam-se contas de administrador. Assim, todos os programas que esses usuários executarem serão também executados com privilégios administrativos, com acesso irrestrito ao sistema operacional. Claro que isso é especialmente problemático se os programas não forem recomendáveis.
O segundo problema a ser solucionado era o incômodo causado pelas ACLs padrão das versões anteriores do Windows, que incluíam ACEs (entradas de ACL) para Todos, Usuários Avançados e assim por diante. Por exemplo, a ACL padrão na raiz do volume de inicialização (normalmente C:\) do Windows XP dava acesso de leitura a Todos e concedia permissão para criar pastas a membros do grupo Usuários. Por fim, no Windows XP havia limitações no que era possível fazer com as ACLs. Por exemplo, não havia no Windows XP forma alguma de atribuir permissões ao proprietário atual de um objeto. Era possível atribuir permissões ao proprietário mas, se o proprietário mudasse, essas permissões não eram transferidas. Do mesmo modo, os proprietários sempre tinham direitos implícitos sobre um objeto, independentemente das permissões atribuídas àquele objeto.
Com o Windows Vista™, a Microsoft lançou-se em um projeto para solucionar vários desses problemas e para habilitar o suporte a outros recursos, como o UAC (Controle de Conta de Usuário). Este artigo se concentra nas principais alterações relacionadas ao controle de acesso no Windows Vista. No próximo mês continuarei a análise das ferramentas que você pode usar para gerenciar o controle de acesso.

Usuários e grupos novos e modificados
Há alguns usuários e grupos novos no Windows Vista, e alguns antigos do Windows XP foram removidos. Além disso, a forma como alguns deles funcionam foi modificada. Cada alteração terá algum impacto sobre a forma como você gerencia o controle de acesso.
Administrador — conta desabilitada por padrão A conta interna Administrador, com um RID (identificador relativo) de 500, agora é desabilitada por padrão na maioria dos casos. Ela deveria ser uma conta de emergência, usada para o salvamento do computador quando tudo o mais falhar. Só que com muito mais freqüência passou a ser usada como conta administrativa padrão, violando vários princípios de segurança. O mais notável deles — a responsabilidade — significa que você perde a capacidade de controlar quem está fazendo alterações no seu sistema. Por isso, a conta foi parcialmente preterida. A Microsoft poderá, por fim, preterir completamente a conta, mas agora ela é desabilitada por padrão. Se você não tiver outras contas locais no grupo Administradores, ainda será possível usar o RID 500 no console de recuperação e no modo de segurança, mas ele não pode e não deve ser usado de outra forma.
Observe que existe uma diferença entre a conta interna Administrador e as outras contas do grupo Administradores. Normalmente escrevemos "Administrador" com inicial maiúscula quando nos referimos à conta com o RID 500, para distingui-la de "administrador", que é qualquer outra conta pertencente ao grupo interno Administradores. Os nomes de grupos também são escritos com inicial maiúscula.
No Windows XP, a conta interna Administrador tinha vários direitos especiais e privilégios que não eram concedidos a nenhum outro administrador. Muitos deles foram removidos do Windows Vista, mas há duas exceções dignas de nota: em primeiro lugar, uma conta Administrador desabilitada pode ser usada no console de recuperação se não houver outros administradores locais. Em segundo lugar, o Administrador não está sujeito ao UAC e sempre terá um token administrativo completo. O mesmo vale para o Administrador de Domínio (RID 500 em um domínio).
Permissões de Usuários Avançados removidas O antigo grupo Usuários Avançados foi abolido para todas as finalidades práticas. O grupo ainda existe, mas a maioria das permissões concedidas a ele foi removida. Não era exatamente um segredo que um usuário pertencente ao grupo Usuários Avançados era, na realidade, um administrador que simplesmente ainda não se tornara um administrador. Uma vez assumi o controle de uma máquina com todos os patches, executando Windows XP SP2 (Service Pack 2), em menos de 45 minutos, concedendo a mim mesmo privilégios administrativos. Isso incluiu o reconhecimento, escrever um pequeno programa em C++, fazer logoff e logon novamente para concluir a tomada de controle — com todos esses recursos habilitados, pois eu era membro do grupo Usuários Avançados.
Muitas organizações concederam permissões sofisticadas ao grupo Usuários Avançados e contam com o fato de seus usuários pertencerem a ele. Por isso, não era viável remover o grupo do Windows Vista. No entanto, é provável que a Microsoft remova completamente o grupo Usuários Avançados em uma versão futura do Windows. Seria aconselhável que você começasse a planejar a migração para deixar o grupo Usuários Avançados.
Instalador Confiável O Instalador Confiável é na verdade um serviço, e não um usuário, embora você veja permissões concedidas a ele em todo o sistema de arquivos. O sistema de proteção de serviços permite que cada serviço seja tratado como uma entidade de segurança completa, que pode ter permissões concedidas como qualquer outro usuário. Para obter uma visão geral desse recurso, consulte a edição de janeiro de 2007 da TechNet Magazine. O livro Windows Vista Security (Grimes e Johansson, Wiley Press, 2007) explora detalhes do sistema de proteção de serviços, inclusive de que forma ele é aproveitado por outros recursos, como firewall e IPsec.
Os SIDs de serviço não são emitidos pelas mesmas autoridades de antes, como NT AUTHORITY ou um domínio. O nome completo da conta virtual TrustedInstaller é NT SERVICE\TrustedInstaller e seu SID é:
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
Você pode ver o SID de qualquer serviço, mesmo daqueles que não existem, executando o comando sc showsid, como mostrado na Figura 1.
Figura 1 O comando sc showsid mostra o SID de qualquer serviço, inclusive daqueles que ainda não existem
Figura 1 O comando sc showsid mostra o SID de qualquer serviço, inclusive daqueles que ainda não existem
Esse SID começa com S-1-5-80. Observe que a primeira subautoridade aqui é 80, que representa SECURITY_SERVICE_ID_BASE_RID, o que significa que esse SID foi emitido pela subautoridade NT SERVICE para um serviço. O mesmo se aplica a qualquer serviço. As subautoridades restantes e os RIDs se baseiam no próprio nome do serviço. Isso permite que um desenvolvedor conceda permissões a seu serviço sem precisar criá-lo e instalá-lo primeiro, uma vez que o nome é determinístico e não irá variar de máquina para máquina.
Caso você não encontre o serviço TrustedInstaller no gerenciador de serviços, seu nome de exibição é "Instalador de Módulos do Windows".
Contas de ajuda e suporte removidas As contas Support_xxxxxx e HelpAssistant foram removidas das instalações limpas do Windows Vista, embora sejam retidas quando é feita a atualização de uma versão anterior do Windows. A conta Support_xxxxxx era usada para executar scripts do centro de suporte. Alguns OEMs que forneciam conteúdo próprio de ajuda talvez fornecessem também suas próprias contas de suporte. Não está claro o que acontecerá com as contas de OEMs, mas é muito provável que eles simplesmente deixem de criá-las. A rigor, não são mais necessárias. Na verdade, do ponto de vista da segurança, não era mesmo uma boa idéia permitir que usuários executassem scripts do centro de ajuda como se fossem outros usuários, então seria melhor se essas contas desaparecessem. O Windows Vista tem um novo mecanismo para realizar essa tarefa.
A conta HelpAssistant era usada durante a assistência remota. Assim como o centro de ajuda, o recurso de assistência remota foi reprojetado para evitar a necessidade da conta HelpAssistant, que conseqüentemente foi removida.
Novos SIDs de locais de rede Os sistemas operacionais baseados em Windows NT® sempre tiveram alguns SIDs baseados em locais de rede, como NETWORK e INTERACTIVE, denotando usuários fazendo logon a partir da rede e interativamente. Há também um SID REMOTE INTERACTIVE LOGON atribuído aos usuários fazendo logon via Serviços de Terminal (observe que os usuários dos Serviços de Terminal na verdade terão REMOTE INTERACTIVE LOGON e INTERACTIVE LOGON em seus tokens). No Windows Vista, são adicionados mais dois: DIALUP e INTERNET. Não são claras as razões exatas da adição de uma conta denotando um logon via dial-up, especialmente porque cada vez mais usuários deixarão de conectar-se caso a única rede disponível seja uma linha telefônica, mas essa conta existe. INTERNET logicamente se destina a indicar qualquer usuário que fez logon fora da rede local. NETWORK, no entanto, ainda designa qualquer usuário que fez logon na rede, incluindo a Internet.
OWNER RIGHTS e direitos do proprietário Existe agora um SID OWNER RIGHTS, que se aplica ao proprietário de um arquivo no momento em que ele for acessado. É usado principalmente para restringir o que o proprietário pode fazer com o arquivo. Há duas alterações dignas de nota na forma como os direitos do proprietário se comparam ao Windows XP. Em primeiro lugar, se você for o proprietário do objeto, mas houver nele uma ACE aplicável a você, os direitos na ACE prevalecerão sobre o fato de você ser o proprietário. Essa é uma alteração importante e exercerá um impacto considerável sobre certos aspectos da administração de sistemas, pois estamos acostumados com o fato de o proprietário ter direitos implícitos. Em segundo lugar, o SID OWNER RIGHTS pode ser usado para restringir ainda mais o que o proprietário pode fazer com um objeto.
Suponhamos que temos uma pasta cujo proprietário é o usuário Jesper, com uma ACL como a mostrada na Figura 2. O usuário, Jesper, tem apenas permissão de leitura sobre a pasta, embora seja o proprietário. Se ele tentar copiar um arquivo para ela, a cópia falhará porque Jesper não tem permissão para gravar na pasta. No entanto, isso não é totalmente intuitivo nas mensagens de erro. Se você tentar copiar um arquivo para uma pasta da qual é proprietário, mas sem permissões de gravação para usar o Windows Explorer®, eis o que acontecerá: primeiro, o Explorer informará que você precisa elevar as permissões para copiar o arquivo e solicitará que você os eleve, mas a cópia do arquivo falhará porque você não tem direitos para copiar nada nessa pasta. Você receberá uma mensagem de erro dizendo "Você precisa de permissão para executar esta ação" e botões para "Tentar novamente" (como se isso pudesse ajudar) e "Cancelar". Isso acontecerá apesar do fato de você ser o proprietário.
Figura 2 Somente o Sistema Local e um outro usuário têm acesso a esta pasta
Figura 2 Somente o Sistema Local e um outro usuário têm acesso a esta pasta
Se Jesper tentar alterar a ACL no arquivo, será solicitado que eleve seu token para fazê-lo. Como ele é o proprietário do arquivo, pode fazer isso. O proprietário retém direitos implícitos de ler e alterar a ACL (READ_CONTROL e WRITE_DAC), a menos que haja uma ACE para OWNER RIGHTS especificando o contrário.
Para entender o efeito do SID OWNER RIGHTS, vamos adicioná-lo à ACL acima. Agora temos as permissões mostradas na Figura 3.
Figura 3 Adicionar as permissões de OWNER RIGHTS à pasta altera as permissões de Jesper
Figura 3 Adicionar as permissões de OWNER RIGHTS à pasta altera as permissões de Jesper
Com essas permissões, se a conta de Jesper tentar copiar alguma coisa para a pasta, essa ação terá sucesso imediato, pois Jesper é o proprietário e tem os direitos adequados. No entanto, se Jesper tentar alterar a ACL no objeto, a ação falhará! A ACE para OWNER RIGHTS especifica que o proprietário terá apenas o privilégio de modificação, e não a capacidade de modificar a DACL (lista de controle de acesso condicional). Assim, OWNER RIGHTS é usado principalmente para remover do proprietário WRITE_DAC, a capacidade de modificar o descritor de segurança.
Se um administrador alterar o proprietário do objeto, as permissões de OWNER RIGHTS não serão automaticamente transferidas para o novo proprietário. Nesse caso a ACE OWNER RIGHTS é desabilitada, sendo marcada como somente herdada, mas não aplicada a contêineres ou objetos — em outras palavras, não sendo aplicada a nada. Isso é feito para garantir que o objeto não fique completamente bloqueado para os administradores. Para fazer com que a ACE OWNER RIGHTS entre novamente em vigor, o Administrador precisa reabilitá-la manualmente. Para isso, é preciso marcá-la como aplicável à pasta, às subpastas e aos arquivos, conforme desejado.
Há vários cenários interessantes nos quais o SID OWNER RIGHTS pode ser útil. Por exemplo, quando o administrador quer que os usuários sejam capazes de criar arquivos e pastas em um servidor de arquivos, mas não quer que possam alterar as ACLs nessas pastas. Outra situação provável é quando certos usuários criaram objetos em algum momento como membros de um grupo, mas depois, talvez por motivos relativos a empresas, foram removidos do grupo. Agora, eles não devem ser capazes de modificar as configurações dos objetos.
OWNER RIGHTS é usado de forma bastante ampla no sistema de proteção de serviços. Quando um serviço cria um objeto transitório em runtime, o criador do objeto é o SID principal do processo de serviço, geralmente LocalSystem, NetworkService ou LocalService, e não o SID do serviço em si. Isso significa que qualquer outro serviço executado no mesmo contexto de processo poderia modificar o objeto, o que seria quase certamente algo indesejável. Definindo um SID OWNER RIGHTS nesses objetos, o sistema operacional pode impedir que outros serviços tenham acesso a eles.

ACLs padrão
As ACLs padrão do Windows XP eram, na verdade, relativamente boas. Com a exceção de alguns pequenos problemas, como permitir que os usuários colocassem arquivos na raiz do volume de inicialização, eram, de modo geral, sensatas. No entanto, alguns OEMs aparentemente decidiram que tinham uma idéia melhor do que constituiria uma segurança razoável. A tela na Figura 4 mostra uma imagem da ACL no diretório Windows de um computador de um grande OEM executando Windows XP Media Center Edition. Basicamente, o OEM desabilitou a segurança do sistema de arquivos.
Figura 4 Uma ACL configurada por OEM
Figura 4 Uma ACL configurada por OEM
A Microsoft fez alguns ajustes nas ACLs do Windows Vista. Em primeiro lugar, se você está acostumado com o Windows XP, sabe que todos os arquivos do sistema operacional são propriedade do grupo Administradores, e que os administradores têm total controle sobre esses arquivos. Como membro do grupo, você tinha acesso irrestrito a esses arquivos. Não é assim no Windows Vista.
Instalador Confiável No Windows Vista, a maioria dos arquivos do sistema operacional tem como proprietário o SID TrustedInstaller, e somente esse SID tem total controle sobre eles. Isso faz parte do trabalho de integridade do sistema empreendido no Windows Vista, e destina-se especificamente a impedir que um processo executado como administrador ou Sistema Local substitua automaticamente os arquivos. Para excluir um arquivo do sistema operacional, você precisa, então, assumir a propriedade do arquivo e adicionar a ele uma ACE que lhe permita excluí-lo. Isso fornece alguma proteção contra processos executados como LocalSystem, com rótulo de integridade do sistema; um processo com integridade inferior não deve ser capaz de elevar-se para alterar a propriedade. Alguns serviços, por exemplo, podem ser executados com integridade média, embora sejam executados como Sistema Local. Tais serviços não podem substituir arquivos do sistema, portanto um explorador que assuma o controle de um deles não poderá substituir arquivos do sistema operacional, dificultando um pouco a instalação de um rootkit ou de outro malware no sistema. Também fica mais difícil que os administradores de sistema incomodados pela simples presença de algum binário de sistema façam sua remoção.
ACEs de negação Você descobrirá que vários objetos do sistema de arquivos têm ACEs de negação para Todos, o que tem causado o descontentamento de muitos administradores. Se você ativar a opção "Mostrar arquivos ocultos", verá o familiar diretório Documents and Settings (Documentos e Configurações). Mas, se você clicar nele, obterá um erro de "Acesso negado". Para entender o que está acontecendo com Documents and Settings, dê uma olhada na lista de diretórios na Figura 5.
Figura 5 Documents and Settings é um ponto de junção, e não um diretório
Figura 5 Documents and Settings é um ponto de junção, e não um diretório
Documents and Settings, na verdade, não é um diretório, mas sim um ponto de junção! Lembre-se de que os pontos de junção são semelhantes a links simbólicos que simplesmente redirecionam o acesso a algum outro lugar. Nesse caso, a junção vai para um diretório chamado C:\Users. Na verdade, a Microsoft modificou consideravelmente o namespace do sistema de arquivos no Windows Vista, e agora os dados do usuário são movidos para C:\Users. Outros elementos sob o antigo namespace "C:\Documents and Settings\<Nome_Usuário>" também foram movidos. Por exemplo, "C:\Documents and Settings\<Nome_Usuário>\Application Data" foi movido para C:\Users\<nome_usuário>\appdata\roaming. Você poderá ver claramente as alterações se entrar em uma linha de comando e usar o comando dir /a como usei na Figura 5. O motivo de alterações tão drásticas no namespace é torná-lo mais intuitivo para os usuários e gerar uma separação mais clara entre documentos e dados. Em vez de armazenar todos os arquivos de dados na pasta Meus Documentos, os desenvolvedores agora podem criar pastas próprias no perfil do usuário, que as verá ali. Os dados de aplicativos de todos os usuários agora ficam em uma pasta oculta chamada de %systemroot%\ProgramData, e não em Documents and Settings\All Users\Dados de Aplicativos.
A Microsoft não removeu o namespace "C:\Documents and Settings" porque pode haver aplicativos antigos codificados para usar esse nome em vez das variáveis de ambiente preferenciais, como %USERPROFILE%. Esses aplicativos teriam seu funcionamento interrompido se "C:\Documents and Settings" desaparecesse. Em vez disso, agora é representado por pontos de junção ou links simbólicos, para compatibilidade retroativa. Ainda assim, os aplicativos que têm esses caminhos codificados podem deixar de funcionar, dependendo da forma como acessam os dados contidos neles, mas já não funcionam nas versões do Windows em idiomas diferentes do inglês. Isso é realmente fundamental. Quando uma atualização do Windows, como o Windows XP SP2 ou o Windows Vista, interrompe o funcionamento de programas de terceiros, isso quase sempre acontece porque os desenvolvedores desses programas fizeram suposições inválidas ou usaram o Windows de forma inadequada.
Por exemplo, se você tentasse abrir um arquivo digitando "C:\Documents and Settings\<Nome_Usuário>\Meus Documentos\foo.txt", provavelmente funcionaria, desde que você tivesse um arquivo denominado foo.txt nesse local. No entanto, se você tentar navegar até "C:\Documents and Settings\<Nome_Usuário>\Meus Documentos", obterá a mensagem de erro "Acesso negado". Para entender o que está acontecendo, dê uma olhada na ACL na Figura 6.
Figura 6 Há uma ACE de negação em Documents and Settings
Figura 6 Há uma ACE de negação em Documents and Settings
Veja a primeira ACE da lista. É uma ACE de negação para Todos para listar o conteúdo da pasta. Programas podem atravessar os pontos de junção e abrir documentos com caminhos absolutos, pois Todos têm o privilégio "Ignorar a verificação completa" (também conhecido como SeChangeNotifyPrivilege). As tentativas de enumerar os diretórios que eles representam, por parte de um usuário ou processo, falharão devido à ACE de negação. É por isso que, na verdade, você não pode ver o que há dentro de C:\Documents and Settings, nem excluir o "diretório". O motivo principal da existência dessa ACE de negação é impedir que os usuários excluam a junção e interrompam o funcionamento de aplicativos antigos. Isso serve também para lembrar aos desenvolvedores que não devem codificar aplicativos para usar o namespace antigo. Em vez disso, devem começar a usar variáveis de ambiente ou cadeias de caracteres do Registro para isolar o aplicativo de alterações futuras e diferenças de idioma.
Observe que todos esses pontos de junção ficam ocultos por padrão, então a grande maioria dos usuários jamais os verá. Para impedir aqueles que os vêem de excluí-los, a Microsoft incluiu uma ACE de negação para "Listar pastas".
Ignorar a verificação completa O motivo pelo qual os usuários podem acessar arquivos sobre os quais têm direitos dentro de pastas (ou pontos de junção) sobre os quais não têm direitos é que todos têm o privilégio "Ignorar a verificação completa". "Ignorar a verificação completa" ou SeChangeNotifyPrivilege é, na verdade, o privilégio mais básico do Windows, sendo concedido a um processo que teve todos os outros privilégios removidos, a menos que o processo solicite especificamente que ele também seja removido. É isso o que acontece quando você inicia um processo usando a linha runas /trustlevel:0x10000 < no Windows Vista. O programa especificado em <command> será executado com um token restrito e todos os privilégios, exceto SeChangeNotifyPrivilege, serão removidos do token do processo.
Como ponto de interesse, trustlevel 0x20000 fornece um token com o conjunto normal de SIDs, mas com privilégios removidos. 0x40000 fornece um token completamente normal.

Permissões padrão
As permissões padrão no sistema de arquivos do Windows Vista foram um pouco alteradas em relação ao Windows XP. Se você examinar a ACL em %systemdrive% (normalmente a unidade C: — o volume de inicialização), no Windows XP ou no Windows Server® 2003, verá isto (ou algo muito semelhante nas versões mais antigas do Windows XP):
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
Eis aqui a mesma ACL no mesmo diretório do Windows Vista:
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
Há algumas diferenças dignas de nota. Em primeiro lugar, agora há duas ACEs para BA (BUILTIN\Administrators), em vez de apenas uma. Contudo, o resultado é o mesmo. No Windows Vista, uma ACE não é herdada e concede acesso total à raiz; a outra é uma ACE IO (somente herdada), herdada por contêineres e objetos, que concede GA (todos genéricos) ou controle total. O mesmo se aplica no caso da substituição da ACE para SY (LocalSystem) por duas no Windows Vista. No Windows XP, a única ACE concedia acesso total e era herdada por objetos e contêineres. Mais uma vez, não há alteração no resultado. A ACL foi alterada principalmente para esclarecer e separar os privilégios, tornando-a mais fácil de gerenciar e, potencialmente, de restaurar.
O mais interessante é que a ACE para CO (Proprietário/Criador) deixou de existir. Isso significa que, se um usuário criar um objeto na raiz do sistema de arquivos, não haverá mais permissões especiais acumuladas para o criador.
Você pode ver também que a ACE para WD (Todos) foi removida. Muitas pessoas interessadas em segurança, embora talvez não tivessem total entendimento das implicações de suas ações, se preocupavam indevidamente com essa ACE. A Microsoft tentou em vão, durante anos, explicar que Todos tinha a mesma função do grupo interno Usuários, mas parece que finalmente desistiu e removeu totalmente a ACE. Como existe uma ACE idêntica para BU (BUILTIN\Users), que também é herdada por contêineres e objetos, o resultado é que nada mudou.
Além disso, duas das ACEs para BU (grupo interno Usuários) foram substituídas por ACEs para AU (Usuários Autenticados). O motivo para isso é que a conta Convidado é membro do grupo interno Usuários (devido ao fato de que INTERACTIVE é membro do grupo interno Usuários), mas não de Usuários Autenticados. Para permitir que a conta Convidado leia e execute arquivos, a ACE 0x1200a9 (efetivamente, leitura e execução) permanece concedida a BU. No entanto, as ACEs que concedem permissões para criar arquivos e pastas são concedidas a Usuários Autenticados. Essa é uma divergência em relação ao Windows XP. No Windows XP, um Convidado podia criar arquivos na raiz. No Windows Vista, um Convidado não pode criar esse tipo de arquivo. Lembre-se, contudo, de que isso não faz muito sentido, a menos que a conta Convidado seja habilitada e os convidados tenham acesso à raiz do volume de inicialização. A conta Convidado é desabilitada por padrão.
Deixando o melhor para o final, há algumas ACEs muito interessantes e aparentemente problemáticas nas duas listas acima. No Windows XP, há uma ACE herdada por contêineres, especificando 0x100004 para o grupo interno Usuários. Essa ACE concede aos Usuários o direito de criar subpastas, subsubpastas e assim por diante, por ser herdada pelos contêineres. Há também uma ACE somente herdada que é herdada por subpastas para 0x100002. Essa ACE concede aos usuários o direito de criar arquivos e subpastas em pastas que criarem na raiz. Em outras palavras, essas duas ACEs permitem que os usuários, inclusive Convidados, criem arquivos e pastas na raiz, como já mencionei.
No Windows Vista, as ACEs correspondentes são somente herdadas, sendo herdadas tanto por contêineres quanto por arquivos, concedendo GR (leitura genérica), GX (execução genérica) e GW (gravação genérica), juntamente com o SD (descritor de segurança de leitura) e com uma ACE que se aplica somente à raiz em si, concedendo o privilégio LC. LC é na verdade um termo de atalho, pertencente às ACEs do Active Directory®. No Active Directory, isso significa que um usuário pode listar objetos filho. No entanto, o valor hexadecimal de LC é 0x4. Aplicado a um diretório, 0x4 significa FILE_ ADD_SUBDIRECTORY, o que funcionalmente equivale a 0x100004, como já temos 0x100000 (a capacidade de usar o objeto para sincronização) na ACE 0x1200a9. Em outras palavras, gera exatamente o mesmo efeito que no Windows XP — os usuários podem criar subdiretórios na raiz.
De onde vêm os valores hexadecimais? E o que são, afinal? Como você já deve ter percebido, o controle de acesso está repleto de números hexadecimais (base16), como 0x1200a9. São, na verdade, representações de máscara de bits dos bits em uma máscara de acesso definidos como "ativados"; isso significa que são usados em uma ACE específica. Quando você usa uma ferramenta como icacls, sc ou secedit para listar uma ACL, as máscaras de bits são representadas por cadeias de caracteres de texto muito mais amigáveis, se houver uma correspondência de 1:1.
Portanto, para determinar o que LC significa, basta que você vá ao site do MSDN®, encontre a cadeia de caracteres LC e procure na coluna "Access right value" (Valor de direito de acesso) para encontrar ADS_RIGHT_ACTRL_DS_LIST. Se você abrir o arquivo de cabeçalho Iads.h e procurar essa cadeia de caracteres, descobrirá que corresponde a 0x4. No caso de cadeias de caracteres que não são do Active Directory (não precedidas por "ADS_RIGHT"), geralmente você encontrará o valor hexadecimal em AccCtrl.h. Após obter o valor hexadecimal, será uma tarefa fácil procurá-lo na máscara de acesso em WinNt.h ou AccCtrl.h para ver o que realmente significa.
Se precisar de ajuda para fazer isso, talvez seja bom obter um exemplar do livro Protect Your Windows Network (Proteja sua rede Windows), de Jesper Johansson e Steve Riley, Addison-Wesley, 2005. O capítulo 17 explica em profundidade como analisar cadeias de caracteres SDDL (linguagem de definição do descritor de segurança) e ACEs.
As permissões concedidas para esses subdiretórios são regidas exclusivamente pela ACE (A;OICIIO;SDGXGWGR;;;AU) no Windows Vista, sendo essa a maior diferença entre ele e o Windows XP. Em vez de conceder controle total ao criador dos subdiretórios, como no Windows XP, no Windows Vista as concessões modificam os privilégios dos usuários autenticados.
O resultado dessa nova ACL é que o criador de um objeto não tem mais direitos especiais e que as coisas ficaram um pouco mais claras. Talvez a maior mudança seja que os Usuários Autenticados têm privilégios de modificação até mesmo em subpastas criadas pelos administradores, o que é muito diferente do Windows XP. No Windows XP, Usuários e Usuários Autenticados não têm direitos sobre objetos criados por administradores na raiz. No entanto, de forma geral, embora essas ACEs possam parecer problemáticas, o efeito não é tão diferente do Windows XP.
Resumindo, no Windows Vista todos, inclusive o usuário Convidado, podem ler e executar arquivos na raiz. Somente usuários autenticados podem criar novos arquivos e pastas e, quando o fazem, obtêm permissões de modificação sobre esses arquivos e pastas. Em outras palavras, as permissões são relativamente mais rígidas no Windows Vista do que no Windows XP, embora seja digno de nota que a conta Convidado é desabilitada por padrão.

Alterações em tokens
Quando um usuário membro do grupo Administradores no Windows XP faz logon, seu token contém o SID do grupo Administradores e ele pode fazer qualquer coisa que o grupo Administradores pode fazer. Por outro lado, no Windows Vista, devido ao Controle de Conta de Usuário, esse não é mais o caso. O SID Administradores ainda está presente no token, mas é definido somente para negação, conforme ilustrado na captura de tela do Process Explorer na Figura 7.
Figura 7 Com o UAC, o SID Administradores é usado somente para negar acesso, a menos que você o eleve
Figura 7 Com o UAC, o SID Administradores é usado somente para negar acesso, a menos que você o eleve
Ao realizar o controle de acesso, essa entrada no token é usada somente para negar acesso — em outras palavras, para a correspondências com as ACEs DENY. As ACEs de permissão para esse SID são ignoradas. Isso significa que você não é realmente um administrador o tempo todo, mesmo se fizer logon no sistema como tal.

Nível de integridade
Agora o Windows oferece suporte à rotulagem de processos e objetos com níveis de integridade. Esses níveis de integridade são, na verdade, representados também por ACEs, mas não na DACL. Em vez disso, fazem parte da SACL (lista de controle de acesso do sistema), com alguns sinalizadores especiais. O sinalizador NW, por exemplo, é usado para denotar o bloqueio de um processo com um nível inferior de integridade para a gravação de objetos em um nível superior de integridade (SDDL_NO_WRITE_UP). Mark Russinovich aborda esse assunto em detalhes em seu artigo "Por dentro do UAC (Controle de Conta de Usuário) do Windows Vista", nesta edição da TechNet Magazine.

Conclusão
Embora não haja uma modificação revolucionária no controle de acesso do Windows Vista, como havia no Windows 2000, há várias pequenas alterações. Podem não parecer muito importantes individualmente, mas, em conjunto, significam que é preciso repensar várias atitudes adotadas no gerenciamento do sistema. Além disso, essas alterações dão suporte a diversas outras iniciativas, especialmente o UAC e o sistema de proteção de serviços. Talvez alguns administradores fiquem bastante frustrados quando começarem a usar o Windows Vista. Já ouvi comentários sobre "sistemas operacionais tirânicos", que restringem a capacidade de excluir partes do sistema operacional que, por um ou outro motivo, parecem ofensivas. Contudo, existem motivos concretos para todas as alterações e, provavelmente, se você dedicar algum tempo à análise do que foi feito, entenderá o porquê.

Jesper Johansson é arquiteto de segurança de uma grande empresa de comércio eletrônico, responsável por uma estratégia de segurança de aplicativos que engloba todas as propriedades e serviços. Ele trabalha há 20 anos na área de segurança, sendo autor de vários artigos e de dois livros sobre o assunto. Quando não está trabalhando com segurança da informação, é professor de mergulho submarino.


 Seguran&#231;a: Gerenciando restri&#231;&#245;es de hardware por meio de Diretiva de grupo
Segurança Jeremy Moskowitz

Gerenciando restrições de hardware por meio de Diretiva de grupo
Visão geral:
  • Restringindo instalações de hardware
  • Restringindo dispositivos específicos
  • Restringindo classes de dispositivos

Você sabe que é verdade: aqueles pen drives USB e todos os outros dispositivos removíveis tornam a sua vida pessoal mais fácil, mas também dificultam a sua vida profissional. Você precisa de uma forma de controlar os
dispositivos de hardware que podem ser instalados e os que não podem. Felizmente, com a Diretiva de grupo do Windows Vista™ e da próxima versão do Windows Server®, cujo codinome é "Longhorn", você tem a opção de aprovar a conexão de um mouse USB mas desaprovar os pen drives USB, permitir leitores de CD-ROM, mas não gravadores de DVD ou permitir Bluetooth e impedir a conexão de PCMCIA.
Duas seções da Diretiva de grupo podem ajudá-lo a proteger o seu hardware: Configuração do Computador | Modelos Administrativos | Sistema | Acesso de Armazenamento Removível (consulte a Figura 1) e Configuração do Computador | Modelos Administrativos | Sistema | Instalação de Dispositivo | Restrições de Instalação de Dispositivo (consulte a Figura 2).
Figura 1 Restrições de hardware predefinidas da Diretiva de grupo
Figura 1 Restrições de hardware predefinidas da Diretiva de grupo
Figura 2 Personalize os tipos de hardware que você deseja restringir
Figura 2 Personalize os tipos de hardware que você deseja restringir
O primeiro conjunto (Acesso de Armazenamento Removível) é bastante auto-explicativo: se você habilitar uma definição de diretiva para aquele tipo de armazenamento removível (CD/DVD, disquete, entre outros), poderá restringir a leitura e/ou a gravação para todo o tipo de dispositivo, se desejado. Mas ele não possui os superpoderes de Restrições de Instalação de Dispositivo.
Em Acesso de armazenamento removível, há grupos de definição de diretiva chamados Classes personalizadas: Negar acesso de leitura e Classes personalizadas: Negar acesso de gravação. Isso parece bom, mas a diretiva Acesso de Armazenamento Removível não evita que os drivers sejam instalados — o driver da classe já estará instalado quando o hardware for detectado. O que a diretiva faz é evitar que haja leitura ou gravação no dispositivo. Na próxima seção, onde vou explorar as configurações da diretiva Restrições de Instalação de Dispositivo, impedirei a utilização do próprio driver.

Manipulando classes e IDs
Primeiro, o mais importante: você precisa saber o que deseja restringir. É possível pensar grande ou pensar pequeno. Ou seja, você pode restringir uma "classe" de dispositivos específica ou obter uma super-específica e restringir um único tipo de hardware. Ou pode fazer o contrário e permitir somente algumas classes específicas de dispositivo, como um mouse USB. No entanto, este é o truque: para ser realmente eficiente, você precisa rastrear o hardware que deseja restringir.
Assim, se você quer dizer "Nenhum driver de joystick pode ser instalado" e "O único mouse que poderá ser instalado é o USB", precisa encontrar um joystick e um mouse USB. A alternativa é usar a Internet para rastrear a ID do Hardware, a identificação compatível ou a classe de dispositivo. Entretanto, será muito mais fácil se você tiver um desses dispositivos na sua frente. Dessa forma, você poderá conectá-lo à sua máquina e verificar o ID do Hardware, a identificação compatível ou a classe de dispositivo. Depois de descobrir essa informação, você saberá exatamente como restringi-los (ou como disponibilizá-los).
No exemplo a seguir, impedirei a utilização de uma família específica de placas de som: uma Creative AutoPCI ES1371/ES1373. Se você quiser restringir algum outro recurso específico (como dispositivos USB, portas USB etc.), basta acompanhar o procedimento e substituir pelo dispositivo desejado.
Abra o Gerenciador de dispositivos em uma máquina que já tenha os itens de hardware instalados. Quando encontrar o dispositivo, clique-o com o botão direito do mouse e selecione Propriedades e a guia Detalhes. Por padrão, você verá uma "Descrição do dispositivo"; ela é interessante, mas não é muito útil. Selecione a lista suspensa Propriedade e escolha "IDs de Hardware", como mostrado na Figura 3.
Figura 3 A guia Detalhes do dispositivo
Figura 3 A guia Detalhes do dispositivo
A página IDs de Hardware exibe, de cima para baixo, as identificações de dispositivo da mais específica para a menos específica. Se você examinar mais de perto o item superior da lista de valores IDs de Hardware, verá que esta placa de som é, especificamente, uma Ver 2 da placa de som ES1371. Isso é bastante específico. À medida que percorremos a lista, a descrição vai se tornando menos específica para englobar toda a família.
Além disso, você pode alterar a Propriedade para identificações compatíveis. Elas também descrevem o hardware e são consideradas menos específicas do que as IDs de Hardware. Você pode optar por utilizar as informações das identificações compatíveis e tentar obter mais tipos de hardware que sejam similares aos presentes em sua lista dos que não podem ser usados — uma vez que elas são menos específicas e podem capturar mais resultados. A desvantagem é que você pode restringir algo que não deveria ser restringido.
E, finalmente, a categoria menos específica pode ser encontrada por meio da seleção de Classe de Dispositivo na lista suspensa Propriedade. No meu caso, a placa de som é exibida simplesmente como Mídia. Mas alguns itens podem ser considerados como Mídia e, novamente, ao optar pelo menos específico, você deve tomar ainda mais cuidado.
Depois de decidir o valor a ser usado, clique sobre ele com o botão direito do mouse, selecione Copiar e cole-o no Bloco de notas. O fato de copiá-lo diretamente, como é apresentado, é importante, já que nas próximas etapas o valor precisará ser inserido com exatidão. Todos os caracteres em maiúsculas e minúsculas do valor devem ser transferidos com precisão.
Se você quiser utilizar um comando da linha de comando em vez de usar o Gerenciador de dispositivos para capturar os IDs de Hardware ou as classes de dispositivo, consulte o utilitário de linha de comando Devcom em support.microsoft.com/kb/311272. Observe que a Microsoft possui alguns identificadores para classes comuns que podem ser úteis caso você não tenha acesso físico ao dispositivo; consulte as informações em go.microsoft.com/fwlink/?LinkId=52665.

Controle de acesso ao hardware por meio de Diretiva de grupo
Mesmo explorando todas as configurações de diretiva de Configuração do Computador | Modelos Administrativos | Sistema | Instalação de Dispositivo | Restrições de Instalação de Dispositivo (mostrado na Figura 2), só uma delas será necessária para concluirmos este primeiro exemplo.
Primeiro, crie um GPO (Objeto de diretiva de grupo) e vincule-o a uma OU (ou a um domínio, entre outros) que contenha máquinas com o Windows Vista que você deseja controlar. Agora edite o GPO e vá até Configuração do Computador | Modelos Administrativos | Sistema | Instalação de Dispositivo | Restrições de Instalação de Dispositivo | Impedir a instalação de dispositivos que correspondam a qualquer destas identificações de dispositivo. Selecione Habilitado na configuração da diretiva, clique em Mostrar (também na configuração da diretiva) e selecione Adicionar na caixa de diálogo "Mostrar conteúdo". Em seguida, na caixa de diálogo "Adicionar item", cole as informações do dispositivo salvas anteriormente como mostrado na Figura 4.
Figura 4 Cole a identificação do dispositivo para capturar a sua descrição exata
Figura 4 Cole a identificação do dispositivo para capturar a sua descrição exata
Aqui temos o problema. Se uma máquina já tiver o dispositivo instalado, ela não o desinstalará e restringirá o acesso a ele em um passe de mágica. Assim, ser você quiser restringir o hardware, terá de fazer isso antes da implementação do seu Windows Vista. No entanto, é preciso observar que o Windows Vista fará uma nova verificação sempre que um dispositivo for removido e reinstalado. Portanto, itens como pen drives USB (que são removidos e reinseridos novamente) são excelentes candidatos para esse processo. Uma vez que o Windows Vista só faz uma nova verificação quando o dispositivo é reconectado, o dispositivo será restringido nesse momento (mesmo que o seu driver já tenha sido carregado na máquina). O problema mais difícil está relacionado aos dispositivos que vêm com a máquina e que não são removidos e reconectados. Para eles, não há uma solução instantaneamente óbvia.
Quando você liga uma máquina que nunca viu o dispositivo de hardware antes, o Windows tentará instalá-lo, oferecendo as informações de status à medida que for progredindo. Se você configurou uma diretiva restringindo esses dispositivos, obterá o resultado mostrado na Figura 5.
Figure 5Figura 5 A instalação de um dispositivo foi impedida
Figure 5Figura 5 A instalação de um dispositivo foi impedida

Mais restrições de hardware
No exemplo anterior, nós restringimos somente um dispositivo. Se quisesse, você poderia ter tomado o caminho inverso, restringindo todo o hardware por padrão e então permitindo somente alguns. Novamente, você pode ver uma lista dessas configurações de diretiva na Figura 2, que mostra a ramificação Configuração do Computador | Modelos Administrativos | Sistema | Instalação de Dispositivo | Restrições de Instalação de Dispositivo da Diretiva de grupo. É possível escolher entre diversas configurações disponíveis.
Primeiro, há "Permitir que os administradores substituam as diretivas de Restrição de Instalação de Dispositivos". Por padrão, os administradores locais do Windows Vista devem seguir as restrições configuradas. Se você habilitar essa configuração, os administradores locais poderão substituir a restrição e instalar qualquer hardware que desejarem.
Em seguida, há "Permitir a instalação de dispositivos usando drivers que correspondam a essas classes de instalação de dispositivo". Ao inserir descrições de dispositivo nessa configuração de diretiva, você está permitindo expressamente que esses dispositivos de hardware sejam instalados no sistema. Observe que essa configuração de diretiva considera somente as classes de instalação, e não as identificações de dispositivo (como as usadas no exemplo).
Para obter o efeito contrário, você pode definir "Impedir a instalação de dispositivos usando drivers que correspondam a essas classes de instalação de dispositivo".
As duas configurações "Exibir uma mensagem personalizada quando a instalação for impedida pela diretiva (texto do balão)" e "Exibir uma mensagem personalizada quando a instalação for impedida pela diretiva (título do balão)" ajudam na personalização da mensagem, como mostrado na Figura 5.
Como mencionado anteriormente, a forma menos específica de descrever o hardware se baseia na classe de hardware. Devemos observar que a configuração de diretiva "Permitir a instalação de dispositivos que correspondam a qualquer destas identificações de dispositivo" não considera as descrições de identificação de classe. Para usar as descrições de identificação de classe, você pode escolher "Permitir a instalação de dispositivos usando drivers que correspondam a essas classes de instalação de dispositivo" ou "Impedir a instalação de dispositivos usando drivers que correspondam a essas classes de instalação de dispositivo". Essa última diretiva é melhor quando usada em conjunto com a configuração "Impedir a instalação de dispositivos não descritos por outras configurações de diretiva". Ao impedir tudo (por padrão) e então optar por essa configuração, você poderá especificar, com precisão, quais são os dispositivos que deseja permitir.
No exemplo, utilize a diretiva "Impedir a instalação de dispositivos que correspondam a qualquer destas identificações de dispositivo" para restringir um tipo específico de hardware com base nas identificações de dispositivo". Se você quiser implementar restrições usando as classes de dispositivo, deve utilizar outras configurações de diretiva específicas, como "Permitir a instalação de dispositivos usando drivers que correspondam a essas classes de instalação de dispositivo" ou "Impedir a instalação de dispositivos usando drivers que correspondam a essas classes de instalação de dispositivo".
"Impedir a instalação de dispositivos removíveis" é uma forma rápida e genérica de restringir qualquer dispositivo de hardware que se descreva como removível, incluindo os dispositivos USB. Essa configuração é bem geral, por isso é melhor não usá-la com muita freqüência. Em vez dela, utilize as técnicas descritas anteriormente para obter identificações de dispositivo moderadamente restritivas e para bloquear os dispositivos de forma específica.
Finalmente, "Impedir a instalação de dispositivos não descritos por outras configurações de diretiva" é a configuração geral de diretiva que, basicamente, restringe todos os dispositivos de hardware, a menos que você informe que alguns deles poderão ser instalados. Essa diretiva, em conjunto com as várias diretivas "Permitir" (como "Impedir a instalação de dispositivos que correspondam a qualquer destas identificações de dispositivo"), formam uma ferramenta realmente poderosa que permitirá a você instalar em seu ambiente somente o hardware desejado.

Conclusão
A Diretiva de grupo do Windows Vista possui alguns superpoderes, extremamente úteis e que permitirão a você instalar em seu ambiente somente o hardware desejado. Basta implementar as configurações de diretiva antes da sua implementação para que o hardware indesejado que esteja em sua rede nunca encontre uma forma de se conectar.
Entrevista com Michael Dennis, gerente-chefe de programa para Diretiva de grupo da Microsoft
Recentemente, tive a oportunidade de entrevistar Michael Dennis, que comandou o lançamento da Diretiva de grupo na Microsoft desde a sua concepção. Michael está deixando a equipe de Diretiva de grupo para buscar novas oportunidades na Microsoft. Conversei com Michael para refletir sobre os últimos nove anos de Diretiva de grupo, onde ela está e para onde está indo.

Jeremy Moskowitz Michael, acho que muita gente gostaria de saber o que você considera como a sua maior realização durante o tempo em que você comandou a equipe de Diretiva de grupo na Microsoft.

Michael Dennis As maiores realizações datam de algum tempo, quando nos concentramos no desenvolvimento do que seria conhecido como Diretiva de grupo. Nós já tínhamos a Diretiva do Sistema no Windows NT® 4.0 e, portanto, a examinamos junto com seus problemas. Já que isso foi durante o período de desenvolvimento do Active Directory®, vimos onde que precisávamos melhorar a gerenciabilidade de clientes e de servidores.
A idéia de criar a Diretiva de grupo em uma hierarquia e o fato de que isso nunca tinha sido feito antes eram muito importantes para nós. Assim, nos concentramos na infra-estrutura principal, nos processos cliente e na integração com o Active Directory.
O subproduto de nossa melhor realização também foi a nossa pior realização. Isso aconteceu porque a GUI lançada com o Windows 2000 era problemática. As pessoas precisavam ter um doutorado em Diretiva de grupo para usá-la de forma eficiente, já que os administradores precisavam saber como tudo funcionava. Eu queria ter criado o GPMC (Console de Gerenciamento de Diretiva de Grupo) e o RSoP (Conjunto de Diretivas Resultante) e os lançado na época (eles estavam nas especificações)

JM Que itens você gostaria de ter incluído na experiência da Diretiva de grupo?

MD A boa notícia é que tudo o que eu queria desde a versão do Windows 2000 agora está aqui no Windows Vista — coisas como RsoP, o GPMC, mais configurações e assim por diante. Eu gostaria de ter criado esses recursos muito mais cedo.
Além disso, eu queria que a infra-estrutura da Diretiva de grupo pudesse ser estendida com mais facilidade pelos parceiros. O nosso modelo de extensão lado servidor/lado cliente requer uma boa dose de trabalho dos desenvolvedores. No entanto, poderíamos argumentar que a nossa estrutura de modelo ADM/ADMX oferece um framework facilmente extensível. Mas teria sido ainda mais fácil se essa parte do sistema permitisse que as pessoas estendessem mais tipos de configurações.
Eu também gostaria que os relatórios do GPMC fossem mais extensíveis para parceiros e para desenvolvedores de ferramentas de terceiros. É uma área em que os fornecedores de ferramentas de terceiros têm sido bem atuantes.

JM O que as pessoas ainda não sabem sobre a equipe da Diretiva de grupo?

MD Algumas vezes, não fica claro para as pessoas onde a equipe da Diretiva de grupo se encaixa no quadro geral. A idéia é que criamos a infra-estrutura, o transporte e as partes do lado servidor e do lado cliente. Somente no Windows Vista, trabalhamos em conjunto com cerca de 120 equipes diferentes na Microsoft para criarmos as novas configurações para essa versão.
Os leitores devem observar que a Diretiva de grupo não tem culpa dos problemas de lentidão do sistema na inicialização ou no logon. Se houver lentidão, a culpa será da carga da Diretiva de grupo. Se você mandar a Diretiva de grupo fazer algo pesado, é justamente isso que ela fará. Por exemplo, se você mandá-la instalar o Microsoft Office em todas as máquinas, tudo bem. Mas saiba que ela fará o que você pediu; ela instalará todo o Office antes da exibição do prompt de logon. Podemos chamar isso de lentidão? Pode apostar que sim, mas, como um administrador que acabou de fazer essa implementação, isso é exatamente o que você queria que o sistema fizesse.

JM O que você mais gosta de exibir usando a Diretiva de grupo?

MD Ultimamente, gosto de exibir algumas das novas configurações feitas no Windows Vista. As configurações de dispositivos removíveis (para restringir cartões USB, entre outras coisas) são aquelas que todos estavam pedindo. Existem cerca de 2.400 configurações disponíveis no Windows Vista, o que traz um nível significativo de controle para os administradores. Gosto de perguntar os clientes o que eles desejam controlar e então mostro a eles como fazê-lo.

JM Por que você trocou os arquivos ADM para ADMX?

MD Tecnicamente, não precisávamos fazer isso para chegarmos ao novo recurso de armazenamento central do Windows Vista. O grande incentivo para a conversão para ADMX foi a capacidade de suportarmos vários idiomas de forma apropriada.
Antes, nos ambientes multilíngües, com freqüência você se deparava com uma situação em que o conteúdo dos arquivos ADM de um GPO estava, inadvertidamente, escrito em outro idioma. Historicamente, pegamos emprestado o formato ADM do Windows NT 4.0, que o tinha pegado do Windows 98 e que fora emprestado pelo Windows 95. Se o XML já existisse, teria sido um bom candidato para o nosso formato de arquivo.
Mas, agora que temos o XML, ficou mais fácil oferecer suporte a vários idiomas, além de representar oportunidades futuras de melhorarmos o registro e as configurações com a nossa nova linguagem esquematizada.

JM Qual foi o maior desafio interno que você teve de superar quando trabalhava na equipe da Diretiva de grupo?

MD O maior problema contínuo que a equipe enfrenta é a tentativa de habilitar os recursos de diretiva do Windows nos recursos de outros componentes.
A Equipe X poderia responder &quot;Acabamos de criar esse novo recurso incrível. Por que alguém poderia querer desligá-lo?&quot; E nós podemos entender isso. Mas resolvemos muitos desses problemas.
Há também os desafios técnicos relacionados à habilitação de alguns recursos por meio de diretivas, como, por exemplo, o WFAS (Firewall do Windows com Segurança Avançada. A criação do WFAS foi difícil. Não é fácil ou direto habilitá-lo para diretivas de forma correta. A interface criada pela equipe do WFAS para o Windows Vista é magnífica, mas acertar foi bem complicado.
Nas versões anteriores ao Windows Vista, as equipes de produto nem sempre pensavam em habilitar seus componentes para diretivas. Porém, durante o desenvolvimento do Windows Vista, um número bem razoável de equipes nos perguntou como fazê-lo. Isso foi ótimo!
JM E quais são seus planos?

MD Estou mudando para a equipe &quot;Mobile Information Worker&quot;, responsável pelos Smart Phones, Pocket PCs, entre outros. Minha função será estender algumas das tecnologias de gerenciamento do Sistema do Windows Server para dispositivos Windows Mobile®.
Tentarei levar a minha visão e a minha paixão por gerenciabilidade e aplicá-las nesse novo espaço. Enquanto isso, estou deixando a equipe da Diretiva de grupo em uma ótima posição para tudo prossiga sem mim.

JM Há algo mais que você gostaria de dizer aos nossos leitores?

MD Durante o desenvolvimento da Diretiva de grupo, uma etapa importante foi a ouvirmos o cliente para realmente entendermos o que eles estavam tentando fazer. Se os clientes tiverem uma opinião bem estruturada sobre os cenários que podem ser cobertos pela Diretiva de grupo e se tiverem um caso comercial, eles precisam comunicar isso para nós.
Temos um bom mecanismo de feedback disponível em WindowsServerFeedback.com. Procure pelo botão Group Policy.
Se a sua equipe puder nos dizer &quot;este é o meu problema, este é o meu caso comercial e eu preciso que o sistema possa fazer por este motivo&quot;, esse é o tipo de informação que é muito, muito valioso para nós. Aqueles tomam decisões sobre o destino da Diretiva de grupo lêem cada entrada vinda desse site.
Novamente, se você deseja ter influência no futuro da Diretiva de grupo, diga-nos de que precisa. Mas não basta nos dizer &quot;Precisamos de uma configuração de diretiva que faça X&quot; sem nos contar o porquê. A nossa função é descobrir &quot;como&quot;. O que a equipe da Diretiva de grupo realmente precisa saber é o &quot;porquê.&quot;
JM Obrigado por passar um tempo nos contando sobre as suas experiências na equipe de Diretiva de grupo da Microsoft. Desejo a você muita sorte!
MD Obrigado, Jeremy.

Jeremy Moskowitz, MCSE e MVP em Diretiva de grupo, administra o GPanswers.com, um fórum comunitário sobre Diretivas de grupo. Ele também ministra uma série de workshops de treinamento intensivo sobre Diretiva de grupo. Seu livro mais recente foi lançado pela editora Sybex em 2007 e se chama Group Policy: Management, Troubleshooting and Security (Diretiva de grupo: gerenciamento, solução de problemas e segurança). Entre em contato com Jeremy pelo endereço www.GPanswers.com.


 Seguran&#231;a: As 4 tecnologias de seguran&#231;a que todas as organiza&#231;&#245;es de TI devem ter
Segurança Matt Clapham and Todd Thompson

As 4 tecnologias de segurança que todas as organizações de TI devem ter
Visão geral:
  • Painel de gerenciamento de riscos
  • Anti-malware
  • Detecção de anomalias de rede

Quando se trata de segurança de TI, a maioria das empresas precisa lidar com problemas semelhantes. A Microsoft não é exceção. Passamos dois anos na equipe de gerenciamento de riscos e compatibilidade do
MMS (Microsoft® Managed Solutions) (consulte "Microsoft Gives Energizer a Recharge for Its IT Division" (A Microsoft recarrega as pilhas da Energizer em sua divisão de TI) para obter mais informações sobre o MMS).
A função da equipe de gerenciamento de riscos e compatibilidade é definir, monitorar e corrigir as condições de risco de todos os ambientes de MMS (tanto para os serviços ao cliente como para a coordenação de infra-estrutura). Desde o início, o nosso gerente, Arjuna Shunn, reconheceu que precisávamos de uma solução de tecnologia que oferecesse os controles e o monitoramento desejado de uma forma centralizada e coesa. As tecnologias que discutiremos aqui são um resultado direto de nossas primeiras idéias, associadas a dois anos de experiência com vários produtos da Microsoft e de terceiros em nossas operações.
Primeiro, precisávamos de tecnologias de segurança que envolvessem os três principais tipos de controle — preventivo, investigador e corretivo — e que também oferecessem auditoria e relatórios. Vimos que esse conjunto de ferramentas está dividido em quatro categorias: painel de gerenciamento de riscos, anti-malware, detecção de anomalias de rede e gerenciamento da configuração desejada. Tentamos incluir pelo menos um representante de cada uma delas em nossas operações de gerenciamento de riscos. E descobrimos que, ao aproveitar as tecnologias de cada uma das quatro áreas, a equipe de segurança de TI pode obter um equilíbrio razoável entre custo e eficiência.
As nossas duas operações de gerenciamento de riscos principais — resposta a incidentes de segurança e gerenciamento de compatibilidade — foram bastante beneficiadas com essa abordagem, mas ainda temos um longo caminho até alcançarmos a coordenação desejada entre as ferramentas. Um conjunto de tecnologias coeso pode oferecer muito mais na forma de eficiência operacional, mas, infelizmente, o mercado ainda não possui esse sistema integrado.
Felizmente, nem tudo está perdido para as equipes de segurança de TI; é simplesmente uma questão de tempo antes que os quatro sistemas comecem a funcionar juntos e interoperem para a obtenção de um efeito maior. Quando esses sistemas estiverem trabalhando juntos, eles não só permitirão o monitoramento ativo das situações de segurança do sistema, como também serão muito convenientes durante auditorias ou em outras operações rotineiras de TI. Neste artigo, descreveremos a função ideal de cada sistema, mostrando alguns exemplos de nossa utilização em runtime.

Painel de gerenciamento de riscos
Em nossa opinião, a existência de um RMD (Painel de Gerenciamento de Riscos) é absolutamente essencial. Essa é a tecnologia mais importante para a operação de uma equipe de segurança de TI. Quase sempre os riscos de confidencialidade, de integridade, de disponibilidade e de responsabilidade (CIA2) em uma empresa são monitorados por sistemas e processos diferentes sem uma interface única para agregação dos dados, correlação e redução de riscos. Além disso, as exigências normativas especificam níveis de dificuldade cada vez maiores para a transparência dos dados empresariais e não há um sistema simplificado para rastrear prontamente diretivas desde a criação até a execução na empresa. Isso fica evidente pelas dificuldades encontradas por todas as empresas na aquisição, correlação, avaliação, correção e compatibilidade de dados (embora não seja uma solução de RMD completa como a que destacaremos aqui, o System Center Operations Manager 2007, mostrado na Figura 1, oferece uma interface única para o monitoramento de vários recursos e para a reunião de alertas relacionados).
Figura 1 O System Center Operations Manager 2007 oferece uma interface única para a exibição de alertas e para o gerenciamento de recursos da rede
Figura 1 O System Center Operations Manager 2007 oferece uma interface única para a exibição de alertas e para o gerenciamento de recursos da rede
A aquisição de dados é violada pela incapacidade de juntar e normalizar dados de origens distintas. A agregação de dados é, por si só, desafiadora, uma vez que exige a divisão da abordagem já comumente separada de reunião e da informação de dados. Mesmo onde a agregação de dados é executada, a normalização continua a representar um desafio ainda maior, já que é extremamente difícil estabelecer o framework comum necessário ao suporte da normalização de dados. Sem ela, é impossível fazer uma comparação entre os eventos de segurança e relacionados à integridade vindos de sistemas diferentes de uma forma significativa.
Para executarmos a automação necessária, o painel de gerenciamento de riscos deve ter acesso a fontes de dados de origens diferentes das tecnologias de segurança descritas aqui. Muitos dados não relacionados a segurança podem ser usados na determinação da situação geral de risco. Os logs de roteador, inventário de bens, status de patches, usuários atualmente conectados, relatórios de desempenho e dados de gerenciamento de alterações podem fornecer informações relevantes a quem investiga os incidentes. Portanto, o sistema geral precisa ter acesso a todos esses dados. Sabemos que mesmo as infra-estruturas empresariais que mais utilizam produtos Microsoft ainda assim incluem tecnologias que não são da empresa e, portanto, o RMD precisa aceitar fontes de tecnologias que não sejam da Microsoft por meio de alguma interface comum.
Se os dados puderem ser adquiridos e normalizados, a próxima etapa será correlacioná-los. O objetivo é fazer a correlação de uma seqüência de eventos — como um evento de anomalia de rede, um evento de relatório de antivírus e um evento de variação da configuração desejada — em uma parte dos dados relacionados ao risco que permita uma ação. Isso requer um trabalho manual intensivo para a criação da lógica de correlação que resultará em um alerta baseado em risco significativo. Com as tecnologias disponíveis atualmente, essa lógica de correlação é, no máximo, difícil de obter.
A avaliação dos dados também exige um trabalho manual intensivo. Mesmo após a correlação, um analista ainda precisa verificar os dados correlacionados para determinar a sua eficácia. A eficácia dos dados correlacionados é tão forte quanto as regras em que se baseia. Isso nos leva a mais uma análise humana dos dados correlacionados para a avaliação dos riscos no ambiente de TI. Um framework de gerenciamento de riscos limpo e codificado poderia ajudar a reduzir a intervenção manual necessária até alcançarmos um nível de triagem. Sem esse framework, o desenvolvimento de um conjunto prático de regras de correlação em uma determinada implementação é muito difícil.
Supondo que um sistema tenha atingido o ponto de avaliação de riscos, a próxima etapa é a correção automatizada. Hoje, essa correção só está realmente disponível para empresas, e mesmo assim ela só é feita para um conjunto limitado de tecnologias, como o gerenciamento de patches ou o antivírus. A correção automatizada liderada pelo sistema RMD oferecerá ao administrador de TI uma tremenda capacidade de manter um nível aceitável de riscos de TI. Quando diversos riscos são identificados simultaneamente, a lógica de correlação deve ser capaz de auxiliar a priorização da resposta aos incidentes com base nos dados de classificação de bens.
Finalmente, oferecer provas de compatibilidade com várias exigências normativas é um desafio gigante para departamentos de TI e, como mencionamos, esse sistema deve oferecer suporte a essa funcionalidade. Um sistema de gerenciamento de riscos centralizado ligado a uma diretiva poderia ser de grande ajuda na produção de relatórios e de provas de compatibilidade. Mas a diretiva precisa ser mais do que simplesmente ondes e porquês. Para facilitar a correção automatizada, a diretiva precisa ser traduzida para um conjunto de padrões que possa ser monitorado, reforçado e comentado pelo painel.
Assim, poderíamos resumir o painel de gerenciamento de riscos ideal como uma forma de oferecer uma interface unificada para a avaliação da integridade, para compatibilidade com normas e diretivas e para processos de gerenciamento de riscos da empresa. Isso pode ser obtido pela combinação de informações vindas de produtos de segurança diferentes e relacionados à integridade e de fontes em uma exibição coesa relacionada a risco. Uma boa solução de RMD precisa fazer o seguinte:
  • Agregar, normalizar e fazer a correlação de dados a partir de fontes distintas
  • Oferecer a obtenção automatizada de informações e a avaliação de riscos
  • Mapear as exigências normativas para diretivas e oferecer suporte a auditoria e a geração de relatórios
  • Oferecer um framework unificado que possa ser modificado para atender às necessidades de uma empresa
O painel deve permitir que os dados sejam organizados e exibidos com significado, mostrando, por exemplo, os principais incidentes agrupados por tipo ou por sistema de origem, incidentes pendentes, incidentes resolvidos e assim por diante. Ele também deve permitir que você consiga detalhar cada item de linha de relatório. Quando examina um evento, o usuário deve ter um acesso fácil a todos os dados relacionados. Esse recurso o ajudará a tomar decisões melhores e mais rápidas.
Devemos destacar que o RMD também é útil para os administradores que não estão na equipe de segurança. Uma vez que o painel oferece uma visão holística do ambiente, o RMD pode agir como um ponto central para que toda a equipe veja o status atual. Ele pode, por exemplo, alertar a equipe de mensagens sobre um ataque de negação de serviço no gateway de SMTP. Enquanto que para a equipe de gerenciamento de riscos esse é um incidente de segurança, a equipe de mensagens o tratará como um incidente de disponibilidade. Embora a equipe de mensagens não seja a responsável por apresentar e resolver tal incidente, eles querem, pelo menos, ser informados sobre os incidentes que afetam os ativos que gerenciam.

Tecnologias anti-malware
Um sistema anti-malware abrangente é importante para a proteção da sua infra-estrutura contra ameaças inesperadas ocultas em código e em ações de usuário. No momento, há geralmente dois tipos separados de ferramentas para a proteção contra o malware: o antivírus e o anti-spyware (por exemplo, o Windows® Defender, mostrado na Figura 2, faz parte da segunda categoria). Ambos evitam, detectam e corrigem com eficiência diferentes tipos de infecções. No entanto, é somente uma questão de tempo antes que esses dois tipos de proteção sejam unificados em uma única solução, fazendo com que haja somente uma pilha anti-malware nos sistemas.
Figura 2 O Windows Defender ajuda a proteger o cliente contra o spyware
Figura 2 O Windows Defender ajuda a proteger o cliente contra o spyware
Uma solução anti-malware minuciosa precisa executar o monitoramento em tempo real e fazer verificações periódicas. Ele deve gerar, de forma centralizada, relatórios sobre as ameaças mais conhecidas (incluindo vírus, spyware e rootkits) e sobre as desconhecidas com base em comportamentos arriscados típicos. A tecnologia anti-malware robusta vigia todos os pontos de entrada clássicos (incluindo o sistema de arquivos, o registro, o shell, navegadores, email e aplicativos conectados) por meio de uma alta integração com o SO e com os aplicativos.
Além disso, uma solução anti-malware precisa abordar muito mais além da segurança do host. Ela precisa vigiar os serviços de mensagens e de colaboração comuns, por onde geralmente passam arquivos infectados, como o SharePoint® e as mensagens instantâneas. Precisa também oferecer uma prevenção automatizada ao interromper operações (as conhecidas e as suspeitas), além de verificar cuidadosamente os dados do usuário para remover vírus de macro ocultas em documentos de usuário e que ainda não infectaram o sistema.
Não é preciso dizer que o anti-malware é inútil se não houver atualizações. O sistema deve manter seus sistemas de assinatura e de remoção atualizados para estar um passo à frente das ameaças mais recentes. Se uma ameaça emergente aparecer, o fornecedor deve obter proteções adicionais antes do lançamento da nova ameaça. Uma solução anti-malware fácil de gerenciar também deve ser configurada e atualizada de forma centralizada.
É claro que essa proteção não pode afetar o desempenho. Se o desempenho piorar, a produtividade cairá. Nesse caso, os usuários podem até tentar desabilitar a solução anti-malware, resultando em nenhuma proteção.
Finalmente, não subestime a importância das tecnologias auxiliares para a assistência ao sistema anti-malware. Os firewalls, que limitam os privilégios do usuário, e outras estratégias também aumentam a proteção contra código malicioso e ações do usuário.

Detecção de anomalias de rede
Enquanto o anti-malware fica de olho nos sistemas, a NAD (detecção de anomalias de rede) monitora os caminhos comuns, verificando indicadores conhecidos de comportamento suspeito e repassando essas informações ao RMD para correção (um firewall, por exemplo, como o mostrado na Figura 3, estaria nessa categoria). Os comportamentos suspeitos poderiam um tráfego de ataque conhecido (como um worm ou uma negação de serviço) ou dados que atendam a um certo padrão (como números de CPF) enviados por email.
Figura 3 O firewall é uma parte importante de uma solução de detecção de anomalias de rede.
Figura 3 O firewall é uma parte importante de uma solução de detecção de anomalias de rede.
Apesar dos melhores esforços feitos em gerenciamento de TI, qualquer rede de uma empresa grande terá, inevitavelmente, um incidente ocasional com malware. A NAD oferece um sistema de avisos antecipados que pode ajudar a acelerar a correção. Além disso, seus recursos de monitoramento de dados e a capacidade de identificar e de interromper o vazamento de informações confidenciais são ferramentas convenientes para a proteção das informações em um ambiente preocupado com vazamentos de dados e com a conformidade normativa.
Assim como as tecnologias anti-malware, a NAD deve se adaptar constantemente ao conjunto mais recente de ameaças e aos tipos de dados confidenciais, ou o seu valor será muito reduzido. Um bom sistema NAD também deve compreender o suficiente sobre as anomalias reais para minimizar o número de falsos positivos informados. Caso contrário, os administradores podem começar a ignorar seus relatórios, presumindo que sejam somente mais um alarme falso.
Depois de um pouco de ajuste e de treinamento, o sistema NAD deve ser capaz de reconhecer e de monitorar os padrões de uso de tráfego típicos. Isso é importante, já que novos tipos de malware e de outros ataques podem se revelar por meio de uma alteração nos padrões de uso. O equipamento de rede tem uma função significativa no sistema NAD geral, uma vez que a solução deve processar dados de roteadores, de switches e de firewalls. Os alertas da NAD podem, então, ser processados pelo mecanismo de correlação do RMD.
Uma possibilidade interessante aqui é criar os detectores de anomalias de rede no software anti-malware do host ou no firewall, lançando uma rede de proteção onde todos os computadores ajudariam a verificar e potencialmente interromper ataques antes de sua disseminação.

O gerenciamento de configuração desejado
Um dos maiores desafios enfrentados pelos departamentos de TI das grandes empresas é a manutenção da configuração apropriada dos sistemas. Existem diversas motivações para querermos manter as configurações dos sistemas — facilidade de gerenciamento, simplificação da escalabilidade, garantia de compatibilidade, bloqueio contra várias formas de invasão e promoção da produtividade, para citarmos alguns. Muitas dessas razões incluem a segurança.
O gerenciamento da configuração desejada é uma área amplamente ignorada na maioria das empresas devido à sua complexidade e aos custos iniciais. Mas estudos mostram que, a longo prazo, a manutenção dos sistemas leva à economia de custos e a uma confiabilidade maior. Uma solução DCM (Monitoramento da Configuração Desejada) pode ajudar.
Um bom sistema DCM deve examinar a rede automaticamente para garantir a implementação de sistemas novos como desejado e também deve verificar se os sistemas já estabelecidos ainda são compatíveis. Seja garantindo que o último patch foi implementado ou minimizando o número de usuários com privilégios de domínio, uma solução DCM completa deve configurar sistemas, analisá-los e informar o quanto cada configuração está próxima do ideal. As correções podem ser simples (como a aplicação de patches em sistemas novos na rede em que são implementados) ou forçadas (como impor configurações de clientes de email para usuários). O segredo é associá-los novamente às diretivas e às regras da organização (o DCM também pode auxiliar na identificação de infecções causadas por malware e na sua remoção, já que os tipos simples serão localizados na verificação do sistema).
O DCM é um dos recursos que gera relatórios sobre os dados principais para o mecanismo de correlação do RDM, além de oferecer detalhes importantes sobre a variação do host em questão em relação ao normal. O grau de atualização de seus dados pode fazer a diferença entre um incidente de segurança de um ou de cinco alarmes para que um ativo seja examinado em uma freqüência proporcional ao seu valor; por exemplo, um ativo de baixa confidencialidade pode ser verificado somente uma vez por mês, enquanto que um ativo de confidencialidade moderada é verificado semanalmente e um ativo de grande confidencialidade é verificado pelo menos uma vez diariamente.
A configuração de um DCM também é uma parte fundamental de um bom mecanismo NAP (Proteção de Acesso à Rede). Assim, o sistema pode verificar se todos os sistemas conectados estão configurados de forma apropriada ou pode bloquear sistemas novos ou desconhecidos até que sejam validados. Além disso, o DCM deve procurar por vulnerabilidades de configuração (como listas de controle de acesso fracas em um compartilhamento) para que os administradores possam tomar a ação apropriada.
Não pense que o DCM só se aplica a hosts como clientes ou servidores. Os dispositivos de rede e o próprio diretório principal são candidatos para a inclusão do DCM. Se houver um design de rede razoavelmente bem compreendido, a imposição de padrões para os dispositivos associados será trivial para o sistema DCM ideal. Imagine as possibilidades! Em vez de ajustar as configurações do roteador manualmente, o DCM poderá manipular a implementação. Ou digamos que um conjunto de configurações de uma Diretiva de Grupo padrão esteja associado a um determinado conjunto de servidores ou de clientes. O DCM poderá monitorá-los e enviar um alerta caso as configurações do domínio mudem.
Os dados coletados pelo DCM devem ser robustos o suficiente para serem usados em uma auditoria de TI. Um bom DCM deve estar ligado aos controles de gerenciamento de alterações e da conformidade normativa para que as preocupações da auditoria sejam tratadas de forma imediata e quase contínua. Por exemplo, uma de nossas verificações de controle de rotina é comprovar se a associação do administrador local aos servidores MMS não foi alterada. O DCM foi feito para impor esse tipo de regra!
Mesmo que o seu departamento de TI não esteja pronto para um sistema DCM auto-corretivo, uma variação conhecida como monitoramento da configuração desejada ainda pode ser implementada e também oferece grandes resultados. Ela também oferece relatórios e alertas sobre problemas de configuração, mas a mesma economia de escala não será necessariamente obtida, uma vez que as correções são quase sempre manuais. No entanto, o importante é que as notificações e os dados necessários ao RMD estarão disponíveis para a correlação.
Porém, é preciso ter cuidado. O DCM, em ambas as formas que acabei de descrever, precisa ter seu escopo definido somente com o mínimo de itens de configuração importantes, combinados aos dados de coleção do ativo padrão. Caso contrário, ele afetará a flexibilidade de que a equipe de TI pode precisar. Se os guias de configuração do DCM ficarem desatualizados, ele será rapidamente considerado como uma taxa operacional, em vez de uma ferramenta útil. Assim, é importante manter-se atualizado sobre a forma de configuração ideal dos ativos. Além disso, sugerimos que o sistema DCM inclua atualizações regulares em seus manuais de configuração de acordo com as práticas recomendadas para o ativo ou para o aplicativo em questão.

Conclusão
Seja criado internamente ou comprado de um fornecedor bem conceituado, o painel é essencial, pois agirá como a principal ferramenta da sua equipe para respostas a incidentes. O anti-malware também é essencial, já que o protegerá de ameaças que se multiplicam diariamente. A detecção de anomalias de rede está para mudar de simples detecção de assinaturas de malware e de invasão de hosts para incluir a descoberta de vazamento de dados — e essa última função pode ajudar a evitar a próxima falha de rede a ser descoberta. O gerenciamento da configuração desejada, embora ainda seja bem recente, logo será um suporte para o monitoramento e para a manutenção de configurações. A despeito de quem ofereça essas ferramentas, você precisa ter pelo menos uma para cada categoria!
Do que vimos até aqui, nenhum fornecedor (incluindo a Microsoft) oferece uma única solução holística que envolva cada um desses quatro espaços. Cabe a você encontrar uma seleção de produtos que atenda às suas necessidades específicas. Nós só queríamos que este artigo oferecesse uma visão do que você precisa considerar, o que deve procurar alcançar e o que a solução ideal faria.

Matt Clapham é engenheiro de segurança do grupo de infra-estrutura e segurança da divisão de TI da Microsoft. Antes disso, trabalhou por dois anos na equipe de gerenciamento de riscos e compatibilidade do grupo Microsoft Managed Solutions.
Todd Thompson é engenheiro de segurança do grupo de infra-estrutura e segurança da divisão de TI da Microsoft. Antes disso, trabalhou por dois anos na equipe de gerenciamento de riscos e compatibilidade do grupo Microsoft Managed Solutions.


 Seguran&#231;a: Uma nova ferramenta avan&#231;ada para o gerenciamento de certificados
Segurança Kevin Dallmann

Uma nova ferramenta avançada para o gerenciamento de certificados
Visão geral:
  • Arquitetura ILM-CM
  • Administração e modelos
  • Criando um fluxo de trabalho

É um dia calmo no trabalho quando, subitamente, você é chamado pela equipe de help desk e de suporte — há um certificado expirado em um dos seus sistemas de produção. Agora, o sistema está inativo e a sua empresa perderá produtividade (e dinheiro) até você renovar o certificado.
Se você for responsável pelo gerenciamento de um ambiente de PKI (Infra-estrutura de Chave Pública), tenho certeza de que já foi surpreendido pela expiração inesperada de um certificado. Aquele dia calmo — bem, agora é só um sonho.
Quando a Microsoft adicionou serviços de PKI ao Windows® 2000 e ao Windows Server® 2003, as empresas passaram a ter uma forma boa e barata de implementar seu próprio ambiente interno de PKI. Infelizmente, os serviços de PKI da Microsoft® não tinham a capacidade de gerenciar o ciclo de vida dos certificados gerados. No entanto, a Microsoft adquiriu recentemente um produto de gerenciamento de certificados e lançou o ILM (Identity Lifecycle Manager), que combina o gerenciamento de certificados ao provisionamento de identidade e aos recursos de controle do MIIS (Microsoft® Identity Integration Server). Este artigo discutirá o que o ILM pode fazer para auxiliar o gerenciamento de certificados e de cartões inteligentes em sua empresa.

Arquitetura ILM-CM
O núcleo da arquitetura ILM-CM é composto pelo servidor ILM-CM e por seus componentes relacionados (consulte a Figura 1). O servidor ILM-CM pode ser instalado em um único servidor configurado para fazer a interface com uma ou com diversas CAs (Autoridades de Certificação). O ILM-CM requer o SQL Server™ para armazenar as informações, as diretivas e outros dados relacionados ao certificado e assim gerenciar o seu ambiente. Para gerenciar permissões de usuário e de segurança, o servidor ILM-CM também precisa do Active Directory®. Consulte a Figura 2 para ver quais são os componentes e as versões necessárias.
Figure 2 Oferecendo suporte à infra-estrutura do ILM-CM (Close Figure 2)

Componentes | Versões
Active Directory | Windows Server 2003
Servidor de banco de dados | SQL Server 2000 SP3 ou superior ou SQL Server 2005
Autoridade de Certificação | Windows Server 2003 Enterprise Edition ou Data Center Edition
SMTP | Servidor de SMTP
Figura 1 Arquitetura ILM-CM
Figura 1 Arquitetura ILM-CM
Após a instalação completa do ambiente ILM-CM, todas as solicitações de certificado se comunicarão com o servidor ILM-CM. Ele é responsável pelo armazenamento de todas as informações relacionadas ao certificado no banco de dados do SQL Server, que poderão ser usadas para criação de relatórios, de alertas e pela manutenção de um ambiente de fluxo de trabalho.
Essencialmente, a arquitetura do software ILM-CM consiste em três partes de alto nível: o servidor ILM-CM, plug-ins de CA e os componentes do lado cliente. O software do servidor pode ser instalado e executado em uma CA ou em um servidor utilizado principalmente para o ILM-CM. O servidor ILM-CM se comunicará com as CAs, com o banco de dados do SQL Server e com o Active Directory. Ele também oferece um portal utilizado pelos gerentes de certificados na configuração de diretivas e de fluxos de trabalho de certificado, assim como pelos assinantes do certificado para a solicitação de certificados de software e de sua renovação.
Para que a CA possa se comunicar com o servidor ILM-CM, a diretiva ILM-CM e os módulos de saída devem ser instalados e configurados em todas as CAs que você desejar gerenciar. Esses dois módulos são usados para o registro das informações do certificado no banco de dados. Quando um certificado é emitido pela CA, o módulo de saída é responsável por enviar essas informações ao servidor ILM-CM, que, por sua vez, registra as informações do certificado no banco de dados.
Se você planeja gerenciar cartões inteligentes em seu ambiente, será preciso instalar o software cliente de cartões inteligentes do ILM-CM. Esse software deve ser instalado em todos os computadores clientes que terão de interagir com o servidor ILM-CM.

Instalação do ILM-CM
A instalação do servidor ILM-CM é, na verdade, bastante simples — um assistente orienta você por todo o processo. Mas antes de executar esse assistente, é preciso cuidar de algumas funções de pré-instalação.
Os primeiros recursos exigidos pelo ILM-CM são o Active Directory e uma extensão de esquema ILM-CM. A extensão de esquema acrescenta alguns atributos de segurança adicionais do Microsoft .NET Framework de que o ILM-CM necessita para implementar os modelos de perfil.
Você também precisa instalar o .NET Framework 2.0 e os componentes mencionados anteriormente — o SQL Server e as CAs, além de um servidor de SMTP. Caso você esteja pensando em instalar o ILM-CM em um servidor separado da CA, então deverá instalar os módulos do ILM-CM nas CAs executando seu assistente de configuração nelas. Quando a instalação estiver concluída, você poderá se conectar ao portal do ILM-CM ao apontar o seu navegador para http://hostname/CLM.
Para habilitar a notificação de expiração/renovação de certificados, é preciso configurar o serviço ILM-CM no servidor ILM-CM. Comece pela criação de uma conta apropriada no Active Directory. Nos serviços ILM-CM, adicione essa conta como a conta de logon. Em seguida, adicione esse usuário aos administradores locais e ao grupo IIS_WPG no servidor ILM-CM, assim como a "Funcionar como parte do sistema operacional, Gerar auditorias de segurança e Substituir um token no nível de processo ", usando as diretivas de grupo. Após a configuração do serviço ILM-CM, o servidor ILM-CM poderá verificar a existência de certificados expirados no banco de dados do SQL Server e fornecer uma notificação por email aos proprietários ou gerentes do certificado.

Administração do ILM-CM
O ILM-CM é gerenciado por meio de uma interface Web, dividida em áreas funcionais relacionadas ao usuário, ao certificado e às tarefas de gerenciamento de cartões inteligentes. Quando você estiver conectado ao portal ILM-CM com os privilégios administrativos apropriados, serão exibidas algumas tarefas administrativas que permitirão o gerenciamento do ambiente ILM-CM (consulte a Figura 3). A seção Common Tasks (Tarefas Comuns) oferece opções de administração, incluindo o registro de usuários para um novo conjunto de certificados ou para um cartão inteligente. Também é possível gerenciar e aprovar solicitações.
Figura 3 Tarefas de gerenciamento do ILM-CM existentes no portal
Figura 3 Tarefas de gerenciamento do ILM-CM existentes no portal
Para localizar usuários ou certificados, utilize a área de tarefas Manage Users and Certificates (gerenciar usuários e certificados). Essas tarefas permitem que você encontre, recupere, revogue ou renove certificados. Você também poderá encontrar uma lista de revogação.
Se a sua empresa utiliza cartões inteligentes, Manage User Smart Cards (gerenciar cartões inteligentes do usuário) será bastante útil. Se, por exemplo, usuário tiver bloqueado seu cartão, o gerenciador de certificados o desbloqueará aqui. Também é possível procurar e exibir cartões inteligentes no leitor de cartões local.
A área Requests (Solicitações) da interface permite que os gerentes de certificados revisem e aprovem solicitações de certificados feitas por usuários. Por exemplo, você pode ver todos os certificados contidos em uma solicitação com o estado pendente. A área Administration (Administração) permite a criação e o gerenciamento de modelos de perfil. Por fim, a área Reports (Relatórios) é, como você poderia esperar, usada para o desenvolvimento e para a criação de relatórios sobre usuários e certificados.
Se a sua conta não tiver privilégios administrativos quando estiver tentando se autenticar no portal ILM-CM, você verá uma página de assinante oferecendo funções de gerenciamento de auto-atendimento para usuários de certificados (consulte a Figura 4). Nesse portal, os usuários podem exibir e gerenciar seus certificados e cartões inteligentes com base em sua configuração particular de diretivas. Exemplos de tarefas comuns incluem a solicitação de certificados ou de um cartão inteligente, a revisão de certificados existentes e a alteração dos PINs dos cartões inteligentes.
Figura 4 Subscriber (Assinante) página do portal para auto-administração do usuário
Figura 4 Subscriber (Assinante) página do portal para auto-administração do usuário
O fornecimento de um processo de fluxo de trabalho delegado de alta qualidade para a emissão, renovação, substituição, revogação e substituição de certificados ou de cartões inteligentes pode ser um desafio em qualquer organização. Com o ILM-CM, agora você pode delegar essas tarefas para oferecer uma garantia maior de segurança. Digamos que você tenha um usuário que esqueceu o PIN do cartão inteligente. Usando o modelo de fluxo de trabalho delegado, ele poderia ligar para o help desk e a equipe de suporte faria algumas perguntas de verificação. Caso as perguntas fossem respondidas corretamente, a equipe de suporte poderia desbloquear o cartão inteligente para o usuário. Outro exemplo de fluxo de trabalho delegado seria a recuperação de um certificado de EFS (Sistema de Arquivos Criptografados) em caso de exclusão acidental ou de perda de um laptop.

Modelos de perfil
Um modelo de perfil é o componente fundamental que habilita um processo de gerenciamento de fluxo de trabalho completo para o ILM-CM. Um modelo de perfil é considerado um objeto administrativo único que contém um ou mais modelos de certificado. Os modelos de perfil são criados e configurados para gerenciarem a forma como o processo de fluxo de trabalho deve operar em seu ambiente de certificação. O aspecto fundamental de um modelo de perfil é que ele pode conter vários modelos de certificado que podem ser gerenciados como um único item, o que significa que os usuários podem ser gerenciados por um modelo que pode rastrear o processo de certificação em todo o seu ciclo de vida.
Os modelos de perfil podem ser configurados para armazenar certificados em um computador (baseados em software) ou em um cartão inteligente (baseados em hardware). Você pode criar esses modelos duplicando um exemplo retirado do portal de administração do ILM-CM. No modelo de perfil, é possível definir diversos componentes de diretiva de gerenciamento diferentes (consulte a Figura 5).
Figura 5 Um modelo de perfil
Figura 5 Um modelo de perfil
Muitos dos componentes da diretiva são aplicáveis tanto aos perfis de software como aos de cartão inteligente (consulte a Figura 6). Vale a pena fazer alguns comentários adicionais sobre alguns desses componentes. Durante o processo de registro do certificado, você pode usar o componente de diretiva de registro para definir certos critérios sobre a forma como gostaria que esse processo fluísse. Por exemplo, você poderia configurar uma coleção de dados, o que significa que o usuário precisaria inserir informações como códigos departamentais, endereços de e-mail e quem é o gerente. Também seria possível criar definições para a exibição automática de um documento oficial assim que o usuário concluísse a registro de um certificado.
Figure 6 Diretivas de perfil de software (Close Figure 6)

Componente | Descrição
Detalhes do perfil | Fornece os detalhes gerais sobre o modelo de perfil. Aqui você pode adicionar um ou mais modelos de certificado ao modelo de perfil.
Diretiva de duplicatas | Define as entidades de fluxo de trabalho de um certificado existente.
Diretiva de registro | Define o fluxo de trabalho do processo de registro.
Diretiva de atualização on-line | Similar à diretiva de renovação, exceto que pode atualizar os certificados que estejam expirando, o conteúdo do certificado, os modelos e os miniaplicativos de cartões inteligentes.
Diretiva Recover on behalf | Recupera a chave privada ou os certificados de um usuário.
Diretiva de renovação | Define o fluxo de trabalho de renovação quando um certificado expira.
Diretiva de restabelecimento | Define o processo de restabelecimento de um certificado.
Diretiva de recuperação | Define o fluxo de trabalho para a recuperação de um certificado de usuário armazenado em um computador que foi apagado, reinstalado ou furtado.
Diretiva de revogação | Define o fluxo de trabalho para a revogação de todos os certificados de um perfil.
A diretiva de atualização on-line pode ser muito útil para a sua organização. Ela é similar à diretiva de renovação, exceto que pode atualizar o conteúdo do certificado, os modelos do certificado, miniaplicativos em cartões inteligentes, além de atualizar o próprio certificado quando ele estiver para expirar. Para aproveitar ao máximo essa diretiva, você deve habilitar o serviço ILM-CM e o arquivo web.config para permitir o acesso a um atributo que aceite diversos valores no Active Directory. Também será necessário instalar o serviço de atualização on-line no computador cliente.
A diretiva Recover on behalf (Recuperar em nome de) pode ser conveniente caso a sua empresa utilize a criptografia EFS. Suponha que alguém apague, acidentalmente, o certificado de criptografia que possui. Você poderia usar esse componente de diretiva para configurar um fluxo de trabalho em que a equipe de segurança do help desk solicite a chave privada do usuário. Em seguida, o usuário poderia recuperar sua chave privada ao receber um email com uma senha secreta gerada pelo servidor ILM-CM. Finalmente, ele iria para um link secreto no servidor ILM-CM para recuperar o certificado com suas chaves privadas associadas. A diretiva Recover on behalf também é particularmente útil quando um funcionário deixa a empresa, mas é necessário recuperar seus dados para fins de arquivo, regulamento, entre outros.
Para oferecer um processo de renovação mais seguro, a diretiva de renovação permite que você configure e envie por email uma senha secreta gerada uma única vez e que será usada pelos usuários na renovação de seus certificados. Se você revogar um certificado e então quiser restabelecê-lo e removê-lo da CRL (Lista de Certificados Revogados), a diretiva de restabelecimento poderá definir esse processo de fluxo de trabalho.
A diretiva de recuperação e a diretiva de revogação são dois componentes de diretiva exclusivos que só pode ser associados às diretivas de certificado de software, e não às de cartões inteligentes. Se um certificado de usuário armazenado em um computador for apagado ou se o próprio computador for reinstalado ou roubado, a política de recuperação poderá definir o processo de restauração do certificado ou das chaves se estiver arquivado na CA. A política de revogação permite que o administrador defina um motivo de revogação estático ou permita que a pessoa que esteja fazendo a solicitação de revogação indique o motivo no momento da revogação.
Existem cinco diretivas de gerenciamento adicionais que são específicas de modelos de perfil de cartão inteligente, como mostra a Figura 7.
Figure 7 Diretivas de perfil de cartão inteligente (Close Figure 7)

Componente | Descrição
Diretiva de substituição | Define o perfil caso o cartão inteligente de um usuário tenha sido perdido ou furtado.
Diretiva de desabilitação | Define o processo de desabilitação de certificados de um cartão inteligente antes da sua expiração.
Diretiva de aposentadoria | Define o processo para a revogação de todos os certificados de um cartão inteligente.
Diretiva de desbloqueio | Define quem pode desbloquear o PIN do usuário de um cartão inteligente.
Diretiva de cartões temporários | Define um cartão inteligente para uma substituição temporária. O usuário recebe novos certificados assinantes mas é capaz de descriptografar seus dados ao obter os certificados de criptografia do perfil existente.
É possível definir diversas operações diferentes para a política de aposentadoria, como a exclusão dos dados de usuário do cartão inteligente, o bloqueio dos PINs administrativo e do usuário e a redefinição do PIN administrativo. A política de desbloqueio é normalmente usada quando um usuário esquece seu PIN ou quando um novo cartão é enviado com um PIN atribuído pelo ILM-CM. O usuário precisa, então, solicitar o desbloqueio do cartão inteligente.
Assim como acontece com qualquer produto administrativo, a geração de relatórios é um recurso bastante útil. A capacidade de capturar um instantâneo do ambiente do seu certificado ou do seu cartão inteligente é muito importante para qualquer organização. O ILM-CM vem com vários relatórios internos que incluem inventários de cartão inteligente, resumos de solicitações, uso e expiração de certificados e muitos outros. Assim como qualquer outro sistema de relatórios, se você precisar de relatórios adicionais poderá escrever uma consulta personalizada, desde que todos os dados estejam armazenados em um banco de dados do SQL Server.

Desenvolvendo um fluxo de trabalho
Agora vamos examinar como o ILM-CM pode auxiliar a definição de um processo de fluxo de trabalho produtivo. Digamos que você tenha vários administradores de sistema responsáveis pelo gerenciamento e pela manutenção de certificados SSL para seus sistemas. A primeira pergunta a ser feita é: quais são os aspectos fundamentais do processo?
Dependendo do tipo do sistema, o processo poderá exigir métodos diferentes para a criação do arquivo de solicitação do certificado. Assim, a primeira tarefa será desenvolver uma página de intranet que possua instruções detalhadas sobre como criar a solicitação do certificado para todos os sistemas.
Depois que o administrador criar o arquivo de solicitação, poderá enviá-lo ao portal de usuário do ILM-CM para a aprovação do certificado. Usando o processo de fluxo de trabalho do ILM-CM, o administrador pode definir diversos aprovadores, que precisam verificar e aprovar uma solicitação de certificado. Após a aprovação de um certificado, o usuário poderá recuperá-lo no ILM-CM. Uma vez que o ILM-CM armazena as informações de certificado em um banco de dados do SQL Server, os administradores são capazes de recuperar informações históricas.
Um ano mais tarde, quando o certificado se aproximar de seu período de expiração, o ILM-CM enviará uma notificação por email ao solicitador informando que o certificado está para expirar e deve ser renovado. A criação desse processo de fluxo de trabalho ajudará a evitar as ocasiões em que os certificados expiram inesperadamente, arruinando o seu dia.

Resumo
Se a sua empresa estiver usando um ambiente de PKI da Microsoft, o ILM-CM pode ajudar a gerenciá-lo. O ILM-CM permite que as empresas aperfeiçoem os processos de autenticação de segurança e reduzam os custos e a complexidade do gerenciamento de certificados digitais e de cartões inteligentes. O ILM-CM também será a fundação para o desenvolvimento de processos de fluxo de trabalho de certificados e de cartões inteligentes que muitas empresas ainda não possuem.
A Microsoft também implementou o suporte externo de API para o ILM-CM. Se a sua organização utiliza aplicativos personalizados, talvez você possa criar uma interface para eles e assim aproveitar o suporte à API do ILM-CM.
Para obter mais informações sobre o ILM-CM, consulte microsoft.com/technet/clm. Há também um guia rápido de introdução em (go.microsoft.com/fwlink/?LinkId=87336).

Kevin Dallmann é engenheiro de sistemas sênior que atua como consultor da Accenture e é responsável, principalmente, pelo suporte aos ambientes do Active Directory e da PKI para grandes empresas. Ele possui os certificados MCSE e MCT e também leciona em cursos da Microsoft.


 Do editor: Problemas de seguran&#231;a
Do editor
Problemas de segurança
Joshua Trupin

Você já percebeu como as preocupações com a segurança têm se tornado mais gerenciáveis recentemente? É claro que nós, da TechNet Magazine, gostaríamos de ter todo o crédito por isso, mas há alguns outros fatores a serem considerados. Os dois maiores são a percepção e robustez.
A percepção é simplesmente estarmos conscientes das ameaças potenciais e dos truques de engenharia social, além de instalarmos os patches e atualizações regulares que protegem o software instalado. A robustez é o outro lado da moeda, a idéia de que o software pode ser criado para ser mais seguro e que possa minimizar sua superfície de ataque ao desligar os recursos expostos por padrão.
Ah, e há mais um fator: a leitura regular da TechNet Magazine. Não se esqueça disso! Você tem em suas mãos a nossa já quase famosa edição de Segurança, e ela contém sete artigos que o ajudarão a se tornar um analista/profissional de segurança melhor para a sua empresa. Mark Russinovich examinará os aspectos internos do UAC, enquanto que Steve Riley mergulhará no Firewall do Windows e Jesper Johansson fará uma exploração das mudanças de ACL ocorridas no Windows Vista. Também teremos Jeremy Moskowitz falando sobre Diretiva de grupo e bloqueios de hardware, Michael Murgolo contribuindo com PowerToys de elevação de script e muito mais. Esta edição que está agora em suas mãos pode ser a melhor revista jamais publicada por qualquer um em qualquer lugar.
E, uma vez que você já está em estado de alerta, precisa conhecer o mais novo recurso de segurança da Microsoft. O Microsoft Forefront representa o fator de "robustez"; é uma linha de produtos de segurança comercial que oferece proteção em três áreas: sistemas operacionais clientes, servidores de aplicativos e borda da rede. Ele inclui ferramentas de segurança para o Exchange Server e para o SharePoint, além de incorporar o ISA Server e o Intelligent Application Gateway para tráfego de rede. O Microsoft System Center incorpora a parte de &quot;percepção&quot; do quebra-cabeça, já que permite a você obter conhecimentos sobre os seus sistemas, simplificar operações e gerenciamento, gerar relatórios e aperfeiçoar a entrega dos serviços. Ele inclui a próxima geração das tecnologias de gerenciamento de configuração e de monitoramento de operações, entre outras ferramentas.
Para saber mais sobre o Forefront e sobre o System Center, visite o site de infra-estrutura da Microsoft, Microsoft.com/infrastructure. E para obter as melhores soluções para os seus problemas de segurança, leia sobre percepção e robustez na TechNet Magazine.
– Joshua Trupin

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Conrad Bayer, David Cross, Michael Dennis, Shon Eizenhoefer, Jason Garms, Russ Humphries, Jesper Johansson, John Lambert, Eric Perlin, Mark Russinovich, Jon Schwartz, David Solomon, Greg Stemp, John Stephens, Kevin Sullivan, Jim Truher e Buck Woody.


 Toolbox: Novos produtos para profissionais de TI
Toolbox Novos produtos para profissionais de TI and Greg Steen
O myLittleAdmin tem uma interface ajustável
A interface do usuário com base na Web oferece suporte a maioria das operações do banco de dados, inclusive a criação de novos bancos de dados, o gerenciamento de bancos de dados existentes e de seu conteúdo e o trabalho com instantâneos e esquemas. Editar as propriedades dos objetos do banco de dados existente é simples, e o myLittleAdmin tem uma boa grade de dados editável para a modificação de linhas individuais das tabelas. Como a interface de exibição em árvore é muito semelhante à exibição encontrada no SQL Server Management Studio, o aplicativo exige pouco aprendizado. O único incômodo é que alguns cliques com o botão direito do mouse muito conhecidos não abrirão o menu de contexto esperado.
Também é possível usar o myLittleAdmin para editar os logins, as funções do servidor e as credenciais da sua instância do SQL. Ele até mesmo deixa você criar e editar dispositivos de backup e servidores vinculados – tarefas muito úteis quando realizadas em um local remoto.
O myLittleAdmin também permite que você realize tarefas como fazer consultas ad-hoc, conectar e desconectar bancos de dados, fazer backup e restaurar, importar dados CSV e reduzir bancos de dados. É possível até mesmo navegar até o log de erros e o monitor de atividades para realizar a solução de problemas.
Preço: Começa com US$ 590 para uma única licença de servidor. Como parte do seu conjunto de ferramentas para hospedagem na Web para os clientes, começa com US$ 990 para uma única licença de servidor.


 P&amp;R do SQL: Instala&#231;&#245;es de 64 bits, aloca&#231;&#227;o da mem&#243;ria de cluster e muito mais
P&R do SQL Instalações de 64 bits, alocação da memória de cluster e muito mais and Editado por Nancy Michell
Figura 1Pesquisa nos Manuais Online do SQL Server usando o Windows Live
Mas digamos que o SQL Server tenha toda a RAM em um servidor e uma nova instância do SQL Server seja iniciada. O que acontecerá à memória da instância original do SQL Server? Parece-me que devo fazer um planejamento tendo em vista o cenário mais desfavorável — somente um nó ativo e todas as instâncias do SQL Server executadas nele.
R Há uma concordância geral quanto ao fato de que é melhor definir um valor máximo de memória do servidor inferior à memória total disponível na máquina. No entanto, é improvável que o valor de um terço da memória total seja a melhor configuração para a sua situação.
Você está preocupado com a possibilidade de três dos quatro servidores no seu cluster ficarem inativos ao mesmo tempo e de três instâncias do SQL Server precisarem ser executadas no quarto nó. Esse cenário, no entanto, é improvável.
Na maioria dos casos, é mais indicado configurar cada instância para usar a maior parte da memória disponível em cada nó. Digamos que cada nó tenha 32 GB de RAM. Definir a memória máxima do servidor como algo em torno de 28 GB para cada instância seria razoável.
Em caso de falha em um nó, a instância executada nele realizaria o failover no nó passivo e poderia ter acesso à memória de 28 GB. As outras duas instâncias não seriam afetadas; continuariam em execução nos outros dois nós do cluster.
Você indicou a existência de um cluster de failover de quatro nós com cinco instâncias do SQL Server e uma instância do Analysis Services. Se estiver executando o SQL Server 2000 com extensões AWE, você precisará definir algumas legendas de memória cuidadosamente selecionadas para suas instâncias de mecanismo relacional, pois elas não renunciarão à memória adquirida. É diferente em uma situação mais flexível, com o SQL Server 2005 e instâncias de 64 bits com acesso a um espaço de endereço amplo, com ou sem extensões AWE; até mesmo quando você usa extensões AWE nessa situação, elas são dinâmicas e podem liberar memória quando solicitadas. Então, a resposta para a pergunta sobre o que acontece à instância original do SQL Server e à memória que ela adquiriu em uma situação de failover, quando uma nova instância é iniciada na máquina, é que depende de você estar executando o SQL Server 2000 ou o SQL Server 2005 e de estar ou não usando extensões AWE.
Em tese, é uma boa idéia planejar-se para o cenário mais desfavorável. Só que, na prática, a menos que você tenha realmente planejado o sistema com recursos extras, é improvável que resista à inatividade de três nós em um cluster de quatro nós executando cinco instâncias de mecanismo relacional do SQL Server e uma do Analysis Services. O nó restante não terá recursos suficientes de CPU para atender às instâncias originais com um nível de desempenho comparável. Sendo esse o caso, geralmente será melhor projetar a solução de forma que o desempenho ideal seja mantido com a perda de um nó, podendo exigir alguma intervenção manual caso mais de um nó seja perdido. Isso provavelmente resultará em uma boa combinação de suporte de alta disponibilidade, permitindo ao mesmo tempo obter uma utilização razoável de recursos dispendiosos.
Por fim, com o SQL Server 2005 o usuário final pode dimensionar o cluster para oito nós. No SQL Server 2000, um cluster de quatro nós era o máximo possível.

Limites do espelhamento
P Lendo sobre o espelhamento de banco de dados do SQL Server 2005, descobri que existe uma limitação nesse espelhamento, que só oferece suporte ao máximo de 10 bancos de dados por instância de servidor. Meus requisitos são duas instâncias separadas do SQL Server com armazenamento separado, failover automático entre as duas e redundância de dados.
Meu plano era usar a replicação de transações P2P (ponto a ponto) do SQL Server 2005 combinada com o MSCS (Microsoft® Cluster Server). Assim, eu teria um IP de cluster com origem em um dos dois nós, de forma que todo o tráfego de inserção, atualização, exclusão e leitura fosse para um único nó do cluster. Eu trataria o nó secundário como passivo, mas as transações seriam replicadas nele. Em caso de falha, o MSCS executaria o failover daquele IP no outro nó e, com a configuração P2P bidirecional, não seria necessário nenhum processo manual para começar a publicar transações no outro nó (por tratar-se de um backup). Eu usaria a configuração de MNS (conjunto de nós principais) no MSCS para reduzir a necessidade de um recurso de disco compartilhado para o quorum.
A opção do espelhamento ainda está de pé. Reduzimos o número de bancos de dados por cluster do SQL Server de 1000 para 100. Ainda assim, eu deveria colocar esse tipo de carga de recursos nos sistemas?
R Para obter informações ou orientação sobre o espelhamento do SQL Server, consulte os Manuais Online ou o SQL Server Tech Center em microsoft.com/technet/prodtechnol/sql e msdn2.microsoft.com/sql.
Sua pergunta gerou bastante discussão. Após uma seleção, eis aqui as melhores respostas referentes ao seu cenário:
A primeira resposta é que não há um limite imposto para o número de bancos de dados que podem ser espelhados em uma determinada instância. Imagino que você se refira a um artigo mencionando que uma prática recomendada consiste em espelhar no máximo 10 bancos de dados por instância, mas isso é apenas uma aproximação e não há um limite específico imposto; tudo depende dos recursos disponíveis em determinado sistema.
O espelhamento pode ser uma opção, mas 1.000 bancos de dados certamente serão uma sobrecarga, a menos que você tenha um servidor de altíssima potência. Se não quer usar o armazenamento compartilhado, mas sim as tecnologias internas do SQL Server, você pode experimentar o espelhamento, o envio de log ou a replicação. Os prós e os contras de cada opção variam.
A segunda resposta é que, se você tem uma grande quantidade de bancos de dados sem o uso do armazenamento compartilhado e quer uma solução de recuperação de desastres fornecida pela Microsoft, deve analisar o envio de log usando um conjunto de pequenos programas auxiliares personalizados para diminuir a sobrecarga administrativa. Um programa pode fazer o backup e a restauração de cada banco de dados em ordem, evitando que você precise executar vários agentes de envio de log. Observe que isso gera alguma possibilidade de perda de dados. Não existe uma solução interna que dispense tanto o armazenamento interno quando um DBMS e ainda assim garanta que não ocorrerá perda de dados.
Claro que existe o problema de como o MSCS fará a detecção e o failover. Normalmente as configurações de MNS em um cluster não eliminam totalmente a necessidade do armazenamento compartilhado; elas simplesmente eliminam a necessidade de ter um LUN compartilhado dedicado para o quorum. A única forma para que o plano funcionasse seria com o cluster configurado para gerenciar apenas os IPs e os nomes de redes. O SQL Server não pode ser agrupado sem armazenamento compartilhado, então você não poderia agrupar o serviço SQL. Isso significa que o cluster não seria capaz de detectar e monitorar serviços SQL Server em uma configuração típica.
Você poderia agrupar o serviço SQL Server adicionando-o como um serviço genérico a ser monitorado, mas então o problema surgiria no failover: como o serviço estaria em cluster, o MSCS tentaria colocá-lo online no nó passivo durante o failover, mas algum serviço SQL já estaria em execução lá. É claro que você poderia usá-lo simplesmente para agrupar os IPs e os nomes de redes, fazendo o failover manual quando necessário. Você poderia fazer o mesmo usando o NLB (balanceamento de carga da rede), realizado em outro local. Consulte o artigo em microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog04.mspx para obter mais informações.
Talvez uma solução de envio de log funcionasse melhor, devido à quantidade de bancos de dados aos quais você está tentando dar suporte. É claro que você precisaria automatizar o processo usando um pacote de DTS/SSIS (Data Transformation Services/SQL Server Integration Services), do contrário provavelmente seria necessário muito tempo para fazer backup manualmente, mover e aplicar os logs ativos durante uma falha.

Meus agradecimentos aos seguintes profissionais de TI da Microsoft por seus conhecimentos técnicos: Boris Baryshnikov, Chad Boyd, Alan Doby, Patrick Gallucci, Cindy Gross, Chuck Ladd, Pat Martin, Vipul Shah, Nelson Taggart, Kartik Tamhane, Ken Tanner, Chuck Timon, George Walters, Kevin Warren e especialmente Buck Woody.


 Destaque de utilit&#225;rio: PowerToys de eleva&#231;&#227;o de script para o Windows Vista
Destaque de utilitário PowerToys de elevação de script para o Windows Vista and Michael Murgolo
Faça download do código deste artigo: Utility2007_06.exe (159KB)
Embora o Controle de Conta do Usuário ofereça um aperfeiçoamento importante na segurança, a possibilidade de elevar as permissões é essencial para a realização de determinadas tarefas administrativas e funções. Aqui estão alguns PowerToys de elevação que tornam a elevação mais flexível e eficiente.
Dentre os muitos recursos que o Windows Vista apresentou como abordagem às preocupações quanto à segurança, o UAC (Controle de Conta do Usuário) é um dos mais significativos. Com ele, até mesmo os usuários administradores executam a maioria dos aplicativos com privilégio padrão, embora tenham "potencial de elevação" para tarefas administrativas específicas e
funções de aplicativo. Depois de usar o Windows Vista™ durante muitos meses, elevar uma tarefa ou aplicativo conforme o necessário se tornou algo comum. No entanto, também enfrentei várias deficiências ao tentar elevar alguns tipos de tarefa no Windows Vista, e isso se tornou frustrante.
Então, com o espírito do antigo Windows® PowerToys, criei alguns PowerToys de elevação de script para superar essas limitações. É possível encontrar todos os PowerToys dos quais falaremos no download de código em technetmagazine .com/code07.aspx. E você pode ler sobre como o UAC funciona no artigo "Realize o sonho não-administrador com o controle de conta do usuário" de novembro de 2006 de Alex Heaton (consulte a barra lateral "Recursos adicionais").

PowerToy do comando de elevação
O primeiro aborrecimento era que não havia método para elevar um aplicativo a partir da linha de comando ou da caixa de diálogo Executar. E depois de fazer pesquisas dentro da Microsoft, encontrei um script de exemplo de John Stephens (um engenheiro de design de software da Microsoft) que fornecia as informações de que eu precisava. Acontece que, se você passar o verbo "runas" para a API ShellExecute ou seu equivalente COM, o método ShellExecute de Shell.Application, o aplicativo pedirá a elevação (consulte a barra lateral para obter detalhes). Isso permitiu que eu criasse o primeiro PowerToy de elevação – o PowerToy do comando de elevação.
Essa ferramenta (que consiste nos arquivos ElevateCommand.inf, elevate.cmd e elevate.vbs) adiciona um comando de elevação ao sistema. Ele permite que você inicie aplicativos que pedem a elevação a partir da linha de comando, de um script, ou da caixa de diálogo Executar. Por exemplo, o seguinte comando abre Win.ini com o Bloco de Notas (após solicitar a elevação):
elevate notepad c:\Windows\Win.ini
Ao usar o comando de elevação com o WSH (Windows Script Host), o Windows PowerShell™ ou outros scripts, você precisa especificar o executável de host do script (como wscript, cscript ou powershell) como sendo o aplicativo. Para executar um vbs, por exemplo, você usaria:
elevate wscript “C:\windows\system32\
slmgr.vbs” –dli
Figura 2Prompts com privilégio elevado

Instalação e implementação
Para instalar esses PowerToys, clique com o botão direito do mouse em um arquivo INF, selecione Instalar e aprove a elevação. Para desinstalar, use a seleção Programas e Recursos do Painel de Controle.
Caso você se perca em meio aos arquivos INF e se pergunte por que três PowerToys instalam elevate.cmd e elevate.vbs em locais diferentes, eu explico. A maioria dos PowerToys são implementados com a inclusão de uma subchave runas na chave HKEY_CLASSES_ROOT\objecttype\Shell para o tipo de objeto no Registro.
No entanto, para alguns PowerToys havia tipos de objeto que eu gostaria que tivessem duas entradas no menu de contexto que causassem a elevação ("Prompt CMD aqui como administrador" e "Prompt do PowerShell aqui como administrador" para os tipos de objeto Unidade e Diretório; "Executar como Administrador" e "Executar como Administrador com Prompt de Comando" para todos os tipos de objeto WSH). Como só pode haver uma única chave runas para cada tipo de objeto, eu tive que implementar a segunda ação chamando o comando de elevação. Mas como queria que cada INF fosse instalado e desinstalado independentemente, eu tive que colocar as cópias associadas elevate.cmd e elevate.vbs em locais diferentes. (É possível incrementar os contadores de uso do arquivo a partir de um arquivo INF bruto. Sim, os instaladores MSI ficariam melhores, mas eu queria que eles pudessem ser criados e modificados com um editor de texto.) Um efeito colateral disso é que apenas as entradas do menu de contexto implementadas usando a chave runas exibirão um escudo no menu.

Resumo
Espero que essas ferramentas lhe sejam úteis e melhorem a sua experiência em relação ao UAC. Talvez elas inspirem você a criar os seus próprios PowerToys. (Para aqueles que usam outras linguagens de script como Perl ou Python no Windows Vista, também deve ser fácil criar um PowerToy "de script de elevação" para elas.) Assim como acontece com todos os PowerToys, essas ferramentas não têm suporte, sendo "de uso por sua própria conta e risco". De qualquer forma, divirta-se com a elevação!
Recursos adicionais
  • Realize o sonho não-administrador com o controle de conta do usuário
  • Visão geral da Conta de Controle do Usuário
  • Elevação com ShellExecute
  • Método ShellExecute
  • Verbos e associações de arquivo
  • Um PowerToy antigo está de volta


 The Cable Guy: O protocolo SSTP
The Cable Guy O protocolo SSTP and Joseph Davies
Esta coluna se baseia em uma versão de pré-lançamento do Windows Server, de codinome "Longhorn". Todas as informações contidas aqui estão sujeitas a alterações.
Os protocolos VPN no Windows XP e no Windows Server 2003 não funcionam com algumas configurações. Obtenha uma visão aprofundada dos diversos problemas existentes e veja como o Windows Server “Longhorn” e o Windows Vista com Service Pack 1 usarão o protocolo SSTP para solucionar esses problemas.
O suporte a VPN (rede virtual privada) no Windows XP e no Windows Server 2003 permite a conexão à sua intranet particular via Internet, como se o seu computador estivesse conectado a uma porta Ethernet local. No entanto, os protocolos VPN no Windows XP e no Windows Server 2003 não funcionam com algumas configurações de firewall
e com algumas configurações indiretas — por exemplo, quando o computador está protegido por um NAT (conversor de endereços de rede) ou um servidor proxy da Web — nas quais o tráfego das conexões VPN é bloqueado. Para resolver essas dificuldades, a próxima versão do Windows Server®, codinome "Longhorn", e o Windows Vista™ com Service Pack 1 (ambos em fase de teste beta) incluem suporte para o novo protocolo SSTP.

Problemas no acesso à VPN
No Windows® XP e no Windows Server 2003, os protocolos VPN que habilitam as conexões de acesso remoto a uma intranet via Internet são o PPTP e o L2TP/IPsec. Eles fornecem o encapsulamento dos pacotes enviados entre um cliente de acesso remoto e a intranet à qual ele está conectado.
O tráfego de VPN baseado em PPTP consiste em uma conexão TCP com a porta TCP 1723 do servidor VPN para realizar a manutenção do encapsulamento e em pacotes encapsulados com GRE (encapsulamento de roteamento genérico) para os dados de VPN. Mas o tráfego PPTP pode ter problemas com firewalls, NATs e proxies da Web. Para evitar problemas, os firewalls precisam ser configurados para permitir a conexão TCP e os dados encapsulados com GRE. Embora o GRE seja um método padrão para o encapsulamento de pacotes IP, muitos provedores descartam esses pacotes, o que resulta em perda de dados. Além disso, as conexões existentes em hotéis e lanchonetes são normalmente configuradas para o tráfego normal de Web e email, e podem não permitir o tráfego PPTP. E ainda, se o seu computador estiver protegido por um NAT, ele terá de ser capaz de converter o tráfego GRE. Se não for, você conseguirá estabelecer a conexão TCP, mas não poderá enviar ou receber dados encapsulados com GRE. Por fim, o tráfego PPTP não pode fluir por um proxy da Web.
O outro protocolo VPN em funcionamento no Windows XP e no Windows Server 2003, o L2TP/IPsec, usa o protocolo IKE para negociar a proteção do tráfego VPN com o protocolo ESP IPsec, podendo também ter problemas com firewalls, NATs e proxies da Web.
Nessa configuração, os firewalls precisam ser configurados para permitir o tráfego IKE e os dados encapsulados com ESP. Se o seu computador cliente VPN estiver protegido por um NAT, o cliente e o servidor VPN precisam oferecer suporte ao IPsec NAT-T (NAT-Traversal). No entanto, observe que o servidor VPN não pode estar protegido por um NAT e que o tráfego L2TP/IPsec não pode fluir por um proxy da Web.

A nova solução para VPN
Como você pode perceber, há vários problemas associados à operação de protocolos VPN no Windows XP e no Windows Server 2003. A boa notícia é que o SSTP no Windows Vista com Service Pack 1 e no Windows Server "Longhorn" soluciona esses problemas de conectividade VPN usando HTTP sobre SSL. O SSL também é conhecido como TLS (segurança da camada de transporte). O HTTP sobre SSL na porta TCP 443 é o protocolo que vem sendo usado há algum tempo na Web para coletar números de cartão de crédito e outros dados particulares. Sempre que você se conecta a um endereço da Web que começa com https:, está usando HTTP sobre SSL.
Usar HTTP sobre SSL soluciona vários problemas de conectividade dos protocolos VPN — firewalls, NATs e proxies da Web normalmente permitem esse tipo de tráfego, por ser muito difundido.
O SSTP usa uma sessão de HTTP sobre SSL entre clientes e servidores VPN para trocar pacotes IPv4 ou IPv6 encapsulados. Observe que uma conexão VPN de acesso remoto baseada em HTTP sobre SSL é diferente da conexão estabelecida por um aplicativo que use HTTP sobre SSL. Por exemplo, o OWA (Outlook® Web Access) permite acessar seu email do Microsoft Exchange na empresa via Internet. O OWA usa uma sessão criptografada com HTTP sobre SSL, mas isso não é o mesmo que uma conexão de acesso remoto. Embora você possa exibir seu email com o OWA, não pode acessar o local de um URL de intranet incorporado em uma mensagem de email do Exchange.
O SSTP não oferece suporte a configurações autenticadas de proxy da Web, nas quais o proxy exige alguma forma de autenticação durante a solicitação de conexão HTTP.
Uma implementação de HTTP sobre SSL no Windows pode reduzir consideravelmente o custo de manter sua solução de acesso remoto. O HTTP sobre SSL resulta, por exemplo, em menos problemas para o suporte técnico, além de eliminar os problemas relacionados a servidores VPN protegidos por NATs. E como o SSTP funciona praticamente em qualquer lugar, os usuários ficam mais satisfeitos e produtivos.
Como o SSTP é interno ao Windows, você não precisa se preocupar com software cliente VPN de terceiros a ser instalado e gerenciado nos computadores clientes, nem com software extra a ser instalado no servidor VPN. Além disso, o SSTP é capaz de fornecer melhor balanceamento de carga das conexões VPN por meio dos balanceadores de carga SSL disponíveis.
Novos recursos do SSTP
  • O SSTP tem suporte integrado para NAP (proteção de acesso à rede), o que pode ser usado para proteger melhor os ativos de rede, impondo a conformidade com os requisitos de integridade do sistema. Para obter mais informações sobre a NAP, consulte microsoft.com/nap.
  • O SSTP também oferece suporte ao tráfego IPv6 nativo enviado dentro do encapsulamento SSTP e às conexões SSTP baseadas em IPv6 na Internet IPv6.
  • O SSTP estabelece ainda uma única sessão HTTP sobre SSL, do cliente para o servidor SSTP. Outras soluções VPN baseadas em SSL de terceiros usam duas sessões HTTP sobre SSL. O uso de uma só sessão HTTP sobre SSL permite a menor utilização da rede e o melhor balanceamento de carga.
  • Por fim, o SSTP é totalmente integrado aos componentes do cliente VPN do Windows Vista com Service Pack 1, do Windows Server &quot;Longhorn&quot; e do roteamento e acesso remoto no Windows Server &quot;Longhorn&quot;. O SSTP é mais um protocolo VPN e pode usar os mesmos protocolos de autenticação e métodos de conexão — como a pasta Conexões de Rede e o Gerenciador de Conexões — usados para conexões baseadas em PPTP ou L2TP/IPsec.
Ao contrário dos protocolos PPTP e L2TP/IPsec no Windows XP e no Windows Server 2003, o SSTP não oferece suporte a conexões VPN site a site.

O SSTP no Windows
Um computador executando o Windows Server "Longhorn" e o Roteamento e Acesso Remoto é um servidor VPN baseado em SSTP. Você não precisa instalar o IIS, pois o Roteamento e Acesso Remoto escuta as conexões de entrada no URI (Uniform Resource Identifier) específico /sra_{BA195980-CD49-458b-9E23- C84EE0ADCD75}/. No entanto, o Roteamento e Acesso Remoto e o IIS podem coexistir no mesmo servidor.
Um computador executando o Windows Vista (com aprimoramentos planejados para o Service Pack 1, que tem lançamento agendado para este ano) ou o Windows Server "Longhorn" é um cliente VPN baseado em SSTP, capaz de iniciar conexões SSTP com um servidor VPN baseado em SSTP. O servidor SSTP precisa ter um certificado de computador com a autenticação de servidor ou com a propriedade EKU (uso avançado de chave) para todas as finalidades. Esse certificado de computador é usado pelo cliente SSTP para autenticar o servidor SSTP quando a sessão SSL é estabelecida. O cliente SSTP valida o certificado de computador do servidor SSTP. Para confiar no certificado de computador, a CA (autoridade de certificação) raiz da CA emitente do certificado de computador do servidor SSTP precisa estar instalada no cliente SSTP.
A Figura 1 compara os atributos de diferentes protocolos VPN no Windows Server "Longhorn" e no Windows Vista com Service Pack 1. A barra lateral "Novos recursos do SSTP" descreve os recursos do SSTP.
Figure 1 Comparando os diferentes protocolos VPN (Close Figure 1)

Atributos | PPTP | L2TP/IPsec | SSTP
Encapsulamento | GRE | L2TP sobre UDP | SSTP sobre TCP
Criptografia | Criptografia MPPE com RC4 | ESP IPsec com 3DES (padrão de criptografia de dados triplo) ou AES (padrão avançado de criptografia) | SSL com RC4 ou AES
Protocolo de manutenção do encapsulamento | PPTP | L2TP | SSTP
Quando ocorre a autenticação do usuário | Antes do início da criptografia | Após o estabelecimento da sessão IPsec | Após o estabelecimento da sessão SSL
Certificados necessários para estabelecer o encapsulamento VPN | Nenhum | Certificados de computador no cliente e no servidor VPN | Certificado de computador no servidor VPN e certificado da CA raiz no cliente VPN

Como o SSTP funciona
Quando o usuário de um computador executando o Windows Server "Longhorn" ou o Windows Vista com Service Pack 1 inicia uma conexão VPN baseada em SSTP, ocorre o seguinte:
  1. O cliente SSTP estabelece uma conexão TCP com o servidor SSTP entre uma porta TCP alocada dinamicamente no cliente e a porta TCP 443 no servidor.
  2. O cliente SSTP envia uma mensagem de saudação para o cliente SSL, indicando que o cliente deseja criar uma sessão SSL com o servidor SSTP.
  3. O servidor SSTP envia seu certificado de computador para o cliente SSTP.
  4. O cliente SSTP valida o certificado de computador, determina o método de criptografia para a sessão SSL, gera uma chave de sessão SSL e a criptografa com a chave pública do certificado do servidor SSTP.
  5. O cliente SSTP envia o formulário criptografado da chave de sessão SSL para o servidor SSTP.
  6. O servidor SSTP descriptografa a chave de sessão SSL com a chave particular do seu certificado de computador. Todas as comunicações futuras entre o cliente e o servidor SSTP serão criptografadas com o método de criptografia negociado e com a chave de sessão SSL.
  7. O cliente SSTP envia uma mensagem de solicitação de HTTP sobre SSL para o servidor SSTP.
  8. O cliente SSTP negocia um encapsulamento SSTP com o servidor SSTP.
  9. O cliente SSTP negocia uma conexão PPP com o servidor SSTP. Essa negociação inclui a autenticação das credenciais do usuário com um método de autenticação PPP e a definição de configurações para o tráfego IPv4 ou IPv6.
  10. O cliente SSTP começa a enviar o tráfego IPv4 ou IPv6 pelo link PPP.
A Figura 2 mostra a estrutura dos pacotes IPv4 ou IPv6 enviados via conexão VPN baseada em SSTP.
Figura 2Estrutura dos pacotes SSTP
Primeiro, um pacote IPv4 ou IPv6 é encapsulado com um cabeçalho PPP e um SSTP. A combinação do pacote IPv4 ou IPv6, os cabeçalhos PPP e SSTP é criptografada pela sessão SSL. Um cabeçalho TCP e um IPv4 (para conexões SSTP via Internet IPv4) ou IPv6 (para conexões SSTP via Internet IPv6) são adicionados, completando o pacote.
Para obter mais informações sobre o SSTP, consulte o Blog de roteamento e acesso remoto em blogs.technet.com/rrasblog.


 Windows PowerShell: Trabalhando com o Active Directory
Windows PowerShell Trabalhando com o Active Directory and Don Jones O Windows PowerShell não oferece um cmdlet Get-ADSIObject, mas isso não o impede de oferecer um poderoso suporte a ADSI. Obtenha uma introdução aos adaptadores de tipo e saiba como o Windows PowerShell funciona com objetos de diretório.
Se você já passou um tempo brincando com o Windows PowerShell, é provável que tenha experimentado o cmdlet Get-WMIObject — também conhecido por um alias mais conveniente, gwmi. Como descrevi na coluna do mês passado, esse cmdlet comprova como o Windows PowerShell é muito melhor do que as linguagens de script e os shells de linha de comando
anteriores (consulte technetmagazine.com/issues/2007/05/PowerShell). O gwmi habilita o acesso rápido e fácil ao WMI (Instrumentação de Gerenciamento do Windows®), permitindo que você faça um número incrível de coisas sem que seja necessário escrever scripts complexos.
O Get-WMIObject é um bom exemplo do que o Windows PowerShell™ pode fazer e sempre que eu o mostro em uma de minhas aulas, os alunos invariavelmente extrapolam a sua funcionalidade para outras áreas da administração do Windows. Normalmente, uma das primeiras perguntas que eles me fazem em seguida é "existe algum cmdlet Get-ADSIObject"?

O suporte a ADSI no Windows PowerShell
ADSI significa Active Directory® Services Interface (Interface de Serviços do Active Directory). Apesar do nome, a ADSI não é específica do Active Directory. Uma leitura mais precisa do seu nome seria "Active (pausa) Directory Services Interface", uma vez que a ADSI pode se conectar a uma variedade de serviços de diretório, incluindo os diretórios do estilo do Windows NT® — e não somente a domínios do Windows NT, como também ao SAM (Gerenciador de Contas de Segurança) local em computadores membros ou autônomos. Com tanta flexibilidade, um cmdlet Get-ADSIObject certamente seria bastante útil. Infelizmente, a equipe do Windows PowerShell não teve tempo de incluir esse cmdlet na primeira versão.
Entretanto, isso não quer dizer que o Windows PowerShell não possua suporte a ADSI. Na verdade, o suporte a ADSI do Windows PowerShell é tão bom que talvez você nem ligue para a falta do cmdlet Get-ADSIObject!
Tudo começa com o adaptador de tipos [ADSI]. Os adaptadores de tipo precisam de uma pequena explicação. Lembre-se de que o Windows PowerShell foi criado no Microsoft® .NET Framework (2.0 ou superior, para sermos específicos). Como resultado, quase tudo nele — dos objetos WMI aos arquivos e pastas — é representado como um objeto do Framework. No entanto, a equipe do Windows PowerShell não estava confortável em expor somente objetos brutos do Framework para os administradores do Windows. Por exemplo, muitos dos objetos do Framework funcionam de forma inconsistente e a consistência foi o principal objeto de design do Windows PowerShell. Outro motivo é que alguns dos objetos do Framework são um exagero quando se trata da administração do Windows, e a simplicidade também foi uma das principais considerações de design do Windows PowerShell. Como resultado, nasceram os adaptadores de tipos.
Como o nome implica, um adaptador de tipos "adapta" um tipo de objeto do .NET Framework para um formato mais consistente e, em algumas ocasiões, mais simples. Por exemplo, suponha que você crie uma nova variável de seqüência de caracteres como esta:
[string]$var = “Hello”
Você usou uma instância do tipo System.String manipulada pelo adaptador .NET. O adaptador de tipos [ADSI] está conectado às classes DirectoryServices do .NET Framework, incluindo o tipo DirectoryEntry.

Recuperando objetos do diretório
A conexão com objetos de diretório é razoavelmente simples. Por exemplo, para se conectar a um usuário chamado Don, na OU (unidade organizacional) de TI do domínio Contoso.com, você usaria algo assim:
$user = [ADSI]”LDAP://cn=Don,ou=IT,dc=
Contoso,dc=com”
Se você já trabalhou com ADSI em VBScript ou em outra linguagem, isso lhe parecerá bem familiar. É uma seqüência de caracteres de consulta LDAP (Lightweight Directory Access Protocol), que é o meio nativo de acesso ao Active Directory. Não é necessário especificar um nome de DC (controlador de domínio) ou qualquer outro detalhe; há informações suficientes nesse FQDN (Nome de Domínio Totalmente Qualificado) para localizar um DC e recuperar o objeto (partindo do pressuposto de que você tem permissão de fazer isso, é claro).
O trabalho com contas de segurança locais passa um processo quase idêntico, exceto que o provedor WinNT é usado em lugar do provedor LDAP:
$user = [ADSI]”WinNT://don-pc/don”
Observe que ambos os identificadores de origem LDAP e WinNT diferenciam maiúsculas de minúsculas. Enquanto que o Windows PowerShell é, geralmente, agnóstico quanto a casos, esses recursos ADSI não o são — portanto, preste atenção à forma como irá digitá-los.
A Figura 1 mostra o que acontece se eu pegar a variável e canalizá-la para Get-Member: obtenho uma lista de propriedades do objeto. Infelizmente, essa não é uma lista completa de todas as propriedades de usuário e não inclui nenhum dos métodos do objeto de usuário. A classe do Framework System.DirectoryServices.DirectoryEntry subjacente funciona de uma forma um pouco estranha nesse contexto, e o Windows PowerShell só pode me mostrar o que a classe do Framework oferece.
Figura 1Recuperando uma lista de propriedades de um objeto
A recuperação de objetos é, principalmente, uma questão de saber como criar uma seqüência de caracteres de consulta. É muito fácil usar o provedor WinNT. Basta especificar um computador ou um nome de domínio, uma barra e então um nome de objeto. Essa técnica funciona muito bem com domínios do Active Directory (afinal, eles são compatíveis com os domínios do Windows NT). E, na verdade, usar o provedor WinNT para recuperar objetos do Active Directory algumas vezes pode ser a rota mais fácil, já que ele oferece a você uma visão plana do domínio. Isso significa que você não precisa saber em qual OU o objeto está localizado, uma vez que o provedor WinNT não as enxerga.
A recuperação de objetos LDAP requer um pouco mais de precisão. Você começa pela informação mais específica possível, como o cn (nome canônico) de um objeto ou o nome de uma OU. Em seguida, você fornece o caminho completo para o objeto, começando pelo contêiner pai e trabalhando até o próprio domínio. Por exemplo, o usuário Don, localizado na OU Sales, que está na OU West do domínio Contoso.com, seria assim:
LDAP://cn=Don,ou=Sales,ou=West,dc=Contoso,
dc=com
Esse formato necessita de um pouco de prática e requer que você saiba onde o objeto está localizado. A Figura 2 resume os diversos componentes de um FQDN.
Figure 2 Componentes do FQDN (Close Figure 2)

Componente | Finalidade | Exemplo:
cn | Nome canônico de um objeto. Também utilizado para contêineres que não são OUs, como Usuários e Computadores. | cn=Don
ou | Unidade organizacional. | ou=Sales
dc | Componente do nome de domínio. Cada componente de um nome de domínio DNS tem seu próprio componente "dc=". | dc=domain, dc=com

Um amigo pode ajudá-lo
A criação e a exclusão de objetos normalmente requer que primeiro você se conecte ao contêiner do objeto, como uma OU, e que depois peça a ele para criar ou excluir o objeto. Eu sempre me esqueço da sintaxe correta, mas felizmente a equipe de Scripts da Microsoft pode nos dar uma mãozinha com o ADSI Scriptomatic.
Embora tenha sido originalmente criado para o VBScript, o ADSI Scriptomatic ainda é um guia muito útil para o Windows PowerShell, já que a sintaxe real do ADSI é a mesma. Por exemplo, depois de baixar a ferramenta, eu seleciono a opção para criar um novo usuário. Ignoro todo o código de script gerado pela ferramenta até "End connect to a container" (Encerrar conexão com o contêiner), que tem esta aparência:
Set objUser =
 objContainer.Create(“user”, “cn=” & strName)
objUser.Put “sAMAccountName”, strName
objUser.SetInfo
A tradução para o Windows PowerShell é fácil. Primeiro, eu me conecto ao contêiner onde desejo criar o usuário. Para me manter consistente com o código do Scriptomatic, usarei a variável $objContainer para representar a OU. Criarei também uma variável, $strName, para armazenar o nome do novo usuário:
$strName = “Don”
$objContainer = “LDAP//ou=Test,dc=Contoso,
dc=com”
Em seguida, eu copio o código do Scriptomatic, removo todos os traços de qualquer instrução Set do VBScript e adiciono $ aos nomes das variáveis:
$objUser = $objContainer.Create(“user”,
 “cn=” & $strName)
$objUser.Put “sAMAccountName”, $strName
$objUser.SetInfo()
Isso é tudo — um novo usuário foi criado na OU Test do domínio Contoso.com.

Modificando objetos do diretório
Depois de se conectar a um objeto — como um usuário ou um grupo — é possível modificá-lo. Com o provedor WinNT, você pode modificar muitas propriedades de forma direta, como as mostradas na Figura 1. Por exemplo, para exibir e então alterar a propriedade Description de um usuário, é preciso fazer isto:
Write-Host $user.Description
$user.Description = “New Description”
$user.SetInfo()
O que devemos lembrar sobre isso é que as mudanças de propriedade são feitas no cache de propriedade local, que é uma área de armazenamento temporária que a ADSI mantém em seu computador. A chamada ao método SetInfo grava o cache no domínio ou no computador de onde o objeto foi recuperado, salvando as suas alterações no diretório.
Os objetos do Active Directory não oferecem propriedades diretas para a maioria dos atributos de objeto. Em vez disso, você utiliza os métodos Get e Put:
Write-Host $user.Get(“Description”)
$user.Put(“Description”,”New Description”)
$user.SetInfo()
Os objetos WinNT tendem a ser bem simplistas, já que os serviços de diretório do Windows NT não armazenam muitas informações sobre objetos como usuários e grupos. Por outro lado, o Active Directory armazena uma profusão de informações e a descoberta dos nomes de atributo corretos pode ser difícil. Por exemplo, se você quiser alterar o sobrenome de um usuário, terá de mudar a propriedade Sn. Por que Sn? Porque vem da palavra inglesa surname.
Felizmente, a Microsoft oferece uma boa referência cruzada, disponível de forma on-line em msdn2.microsoft.com/ms677286.aspx. Essa referência mostra os nomes de atributo para cada uma das principais áreas do console Usuários & Computadores do Active Directory e, portanto, se você sabe o que deseja alterar no console, pode descobrir o nome de atributo subjacente. Observe que existe uma referência cruzada do tipo console para atributo mais completa no livro ADSI Scripting: TFM (Scripts ADSI: TFM), de Cade Fassett (SAPIEN Press, 2007).

O que você não pode fazer
Infelizmente, o suporte a ADSI do Windows PowerShell não é tão poderoso quanto o suporte a outras tecnologias, como WMI. Por exemplo, é difícil enumerar os membros dos grupos de um computador local. Algumas situações difíceis também aparecem quando lidamos com o Active Directory. Minha experiência tem sido que a recuperação, a criação e a exclusão de objetos básicos funcionam bem. A modificação de propriedades dos objetos funciona razoavelmente bem, embora algumas delas sejam inacessíveis. Tive mais dificuldade ao trabalhar com objetos e grupos locais por meio do provedor WinNT.
Isso sem falar naquilo que não consegui fazer de jeito nenhum. Algumas coisas são simplesmente mais difíceis ou menos intuitivas. Considere o exemplo a seguir:
$group = [ADSI]”LDAP://cn=Techs,cn=users,
 dc=contoso,dc=com”
$group.Member.Add(“cn=user1,cn=users,
 dc=contoso , dc=com”)
$group.psbase.CommitChanges()
Ele adiciona o usuário chamado User1 ao grupo Techs. Seu início é bem direto. Ele recupera o grupo usando o FQDN. Em seguida, utiliza a coleção Member do grupo — mais especificamente, o método Add da coleção — para adicionar o FQDN do usuário desejado. No entanto, a última etapa não é nem um pouco intuitiva. Ela chama o método CommitChanges da classe PSBase oculta para salvar as alterações.
PSBase é uma classe especial que representa diretamente o objeto .NET Framework básico. Nesse caso, CommitChanges não é diretamente exposto no Windows PowerShell (na verdade, nenhum método é exposto pelo adaptador ADSI) e, portanto, você precisa ir até a classe subjacente. Isso não é impossível, mas também não é intuitivo. Esse caso também ilustra que os recursos de serviços de diretório ainda não foram totalmente adaptados ao Windows PowerShell.
Existem muitas razões para isso. Primeiro, a equipe do Windows PowerShell adicionou o suporte a ADSI atual ao shell um pouco tarde no ciclo de desenvolvimento. Como Jeffrey Snover, o arquiteto do shell, sempre diz "lançar é optar". A equipe tinha um prazo para desenvolver e lançar o shell e teve de tomar decisões sobre o que teria de ser guardado para a próxima versão. Caso contrário, eles poderiam ter passado anos adicionando recursos e nunca lançariam um produto suportado.
Outra razão, porém, é o .NET Framework subjacente. Sua classe DirectoryServices é bastante complexa e adaptar essa complexidade ao Windows PowerShell levará muito tempo e exigirá um planejamento cuidadoso. As classes do Framework também são, em minha opinião, um pouco inclinadas em direção ao Active Directory e não oferecem muito suporte ao provedor WinNT — o Windows PowerShell, é claro, herdou tais limitações do Framework.
Espero que, eventualmente, o suporte a serviços de diretório do Windows PowerShell seja bastante expandido — e que talvez esse suporte não seja por meio da camada de ADSI, mas por meio de aperfeiçoamentos básicos feitos no .NET Framework. Enquanto isso, o suporte a ADSI disponível no Windows PowerShell permite que você execute a maioria das tarefas administrativas, como a criação de usuários, a modificação de propriedades comuns de usuário, entre outras.
Não se esqueça de que muitas tarefas dos serviços de diretório podem ser executadas por meio de WMI. Confira os scripts disponíveis em microsoft.com/technet/scriptcenter/scripts para obter alguns exemplos excelentes que utilizam WMI para oferecer mais informações sobre um grupo local além das fornecidas pela ADSI.


 Ei, Equipe de Scripts!: Os scripts e a linha vermelha ondulada
Ei, Equipe de Scripts! Os scripts e a linha vermelha ondulada and A Equipe de Scripts da Microsoft
Faça download do código deste artigo: HeyScriptingGuy2007_06.exe (151KB)
Procurando por uma maneira mais fácil de adicionar termos ao dicionário do Microsoft Word sem ter de fazer isso à mão e uma palavra por vez? E quem não está? Neste mês, a Equipe de Scripts mostrará a você como criar dicionários personalizados no Microsoft Word e como configurar, por meio de programação, o Word para que ele utilize esses dicionários.
Figura 1Documento do Word mostrando erros de ortografia.
Você observou algum aspecto peculiar? É isso mesmo: o Word desenhou linhas onduladas sob os termos de script como Msgbox. Por quê? Porque ele não reconhece esses termos. Não reconhece esses termos? O que é isso, Word? Afinal de contas, nos últimos anos a Equipe de Scripts tem digitado o termo Msgbox milhões de vezes. Muitas outras milhões de vezes eles executaram a correção ortográfica e disseram a você que Msgbox estava escrito corretamente. E ainda assim você marca Msgbox, StrReverse e Ltrim como palavras incorretas? O que você quer dizer com isso?
Antes que você corra em defesa do Word, sim, nós sabemos que podemos adicionar esses termos manualmente ao dicionário do Microsoft Word. Mas, veja bem, nós somos a Equipe de Scripts! O que nós sabemos sobre trabalhos manuais? Além disso, a adição manual de funções de VBScript e de nomes de classes WMI (Instrumentação de Gerenciamento do Windows®) e de atributos de objetos da ADSI (Active Directory® Security Interfaces) pode ser um pouco tediosa, para dizer o mínimo. E se quisermos fazer isso em todos os nossos computadores? E se quisermos compartilhar essa ortografia correta com os nossos devotados leitores? E se... Bem, você já entendeu.
A questão é esta: com certeza deve haver uma maneira mais fácil de adicionar termos de script (ou qualquer termo) ao dicionário sem que seja preciso fazer isso à mão e uma palavra por vez.
Acontece que existe uma forma de fazer isso. Vemos vocês todos no mês que vem.
Ei, espere, estamos brincando. É claro que há uma maneira mais fácil de adicionar termos ao dicionário. E em alguns momentos mostraremos a você como fazer isso. No entanto, primeiro vamos conversar um pouco sobre dicionários.
E, por falar neles, temos um fato interessante sobre dicionários. Por que os americanos escrevem color sem o u (color, e não colour) como fazem os ingleses? Por que os americanos escrevem center em vez de centre? Nós sabemos a resposta: porque Noah Webster, criador do primeiro dicionário americano, não gostava das regras de ortografia do inglês britânico e, portanto, alterou arbitrariamente a ortografia de várias palavras.
Tá bom. Isso não foi nada empolgante. Da próxima vez, tente você achar um fato interessante sobre dicionários!
Além do dicionário padrão interno do aplicativo, o Microsoft Word também permite a criação de qualquer número de dicionários personalizados. Por padrão, o Word vem com um dicionário personalizado chamado Usuario.dic, que normalmente pode ser encontrado na pasta Dados de aplicativos\Microsoft\Prova do perfil do seu usuário (por padrão, \Documents and Settings\nome do usuário no Windows XP). Se você clicar com o botão direito do mouse em uma palavra incorreta e selecionar Adicionar ao dicionário, ela será armazenada em Usuario.dic.
Acontece que Usuario.dic é somente um bom e velho arquivo de texto. Abra-o no Bloco de notas e você verá uma lista de palavras similar a esta:
Aaberg
Aalling
Abbas
Abercrombie
Abola
Abolrous
Abrus
E é assim que você pode adicionar temos de script ao dicionário do Microsoft Word por meio de programação. Tudo o que precisamos fazer é criar um arquivo de texto com esses termos e então configurar o Word para que ele utilize o arquivo como um dicionário personalizado. Isso vai ser muito difícil? Considerando o fato de que a Equipe de Scripts está querendo fazer isso por conta própria, obviamente será muito fácil.
Mas espere: precisamos fazer mais um pequeno desvio antes de criarmos o dicionário. No modelo de objeto do Microsoft Word, as informações sobre os dicionários personalizados são armazenadas na coleção CustomDictionaries. Por sua vez, essa coleção pode ser acessada programaticamente se fizermos referência ao objeto Word.Application e à propriedade CustomDictionaries. Por exemplo, a Figura 2 mostra um script que retorna informações sobre todos os dicionários personalizados associados à sua cópia do Microsoft Word.
Figure 2 Script que recupera informações sobre dicionário personalizado (Close Figure 2)
Set objWord = CreateObject(“Word.Application”)

Set colDictionaries = objWord.CustomDictionaries

For Each objDictionary in colDictionaries
 Wscript.Echo “Name: “ & objDictionary.Name
 Wscript.Echo “Language ID: “ & objDictionary.LanguageID
 Wscript.Echo “Language-specific: “ & objDictionary.LanguageSpecific
 Wscript.Echo “Location: “ & objDictionary.Path
 Wscript.Echo “Read-only: “ & objDictionary.ReadOnly
 intType = objDictionary.Type
 Select Case intType
  Case 0 Wscript.Echo “Type: Spelling”
  Case 1 Wscript.Echo “Type: Grammar”
  Case 2 Wscript.Echo “Type: Thesaurus”
  Case 3 Wscript.Echo “Type: Hyphenation”
  Case 4 Wscript.Echo “Type: Spelling (complete)”
  Case 5 Wscript.Echo “Type: Spelling (custom)”
  Case 6 Wscript.Echo “Type: Spelling (legal)”
  Case 7 Wscript.Echo “Type: Spelling (medical)”
  Case 8 Wscript.Echo “Type: Hangual-Hanja Conversion”
  Case 9 Wscript.Echo “Type: Hangual-Hanja Conversion (custom)”
 End Select
 Wscript.Echo
Next

objWord.Quit
Execute o script da Figura 2 e você obterá informações similares a estas:
Name: CUSTOM.DIC
Language ID: 0
Language-specific: False
Location: C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof
Read-only: False
Type: Spelling (custom)
Muito inteligente, não?
É claro que obter informações sobre dicionários existentes não é a mesma coisa do que criar um novo dicionário personalizado; é quase como a diferença entre ler sobre alguém que possui um milhão de dólares e ser alguém que tem um milhão de dólares. Portanto, vamos ver se conseguimos descobrir como podemos criar um novo dicionário personalizado do Word.
Vamos começar pela adição de todas as funções do VBScript a um novo dicionário, chamado Scripting.dic. Vamos começar pelas funções do VBScript porque teremos pouco trabalho a fazer aqui. Afinal, mostraremos a você como adicionar classes da WMI, atributos da ADSI e cmdlets do Windows PowerShell™ ao seu dicionário com o mínimo de trabalho possível (é desnecessário dizer que, quando se trata de ter pouco trabalho, a Equipe de Scripts sabe do que está falando).
Para começar, criar um dicionário personalizado no Microsoft Word é tão fácil como isto:
Set objWord = CreateObject _
 (“Word.Application”)

Set colDictionaries = _
 objWord.CustomDictionaries
colDictionaries.Add “Scripting.dic”

objWord.Quit
Como você pode ver, começamos pela criação de uma instância do objeto Word.Application. Talvez você note que nunca definimos a propriedade Visible como True e, portanto, nunca tornamos o Word visível na tela. Por que não? Bem, simplesmente porque a execução desse script leva em torno de um segundo. Por causa disso, não vimos um motivo para fazer o Word piscar rapidamente na tela e então desaparecer imediatamente. Mas se você gosta de instâncias piscantes do Word (se não for por outro motivo do que ter certeza de que o script está realmente fazer alguma coisa), então basta adicionar isto como a segunda linha de código do seu script:
objWord.Visible = True
Depois de criar o objeto Word.Application, usamos esta linha de código para criarmos uma referência de objeto à coleção CustomDictionaries:
Set colDictionaries = _
 objWord.CustomDictionaries
Então podemos chamar o método Add para adicionar o dicionário personalizado. Observe que esse arquivo não precisa existir; se o Word não encontrar um arquivo chamado Scripting.dic, ele simplesmente criará um arquivo novo e em branco com esse nome. Este é o código para a adição do dicionário personalizado:
colDictionaries.Add “Scripting.dic”
Talvez você também tenha notado que não especificamos um caminho quando adicionamos o novo dicionário. Em vez disso, simplesmente entregamos o nome do arquivo (Scripting.dic) ao método Add. Tudo bem. Nesse caso, Scripting.dic será criado na pasta padrão para dicionários e para outros revisores de texto (por exemplo, C:\Documents and Settings\kenmyer\Dados de aplicativo\Microsoft\Prova).
E se quiséssemos que o nosso dicionário ficasse em um local diferente? Sem problemas. Este comando cria Scripting.dic na pasta C:\Scripts:
colDictionaries.Add _
 “C:\Scripts\Scripting.dic”
E se, mais tarde, decidíssemos nos livrar desse dicionário personalizado? Novamente, isso não será problema. Nesse caso, podemos nos conectar ao dicionário em questão e usar o método Delete para nos livrarmos dele:
Set objWord = CreateObject _
 (“Word.Application”)
Set objDictionary = _
 objWord.CustomDictionaries _
 (“C:\Scripts\Scripting.dic”)
objDictionary.Delete

objWord.Quit
Figura 3Documento do Word após a adição de um dicionário personalizado
Isso é muito conveniente, se nós mesmos estamos dizendo, especialmente quando você considera o fato de que pode compartilhar Scripting.dic e o seu script de criação de dicionários personalizados com quem quiser. Faça isso e logo todas as versões do Word também verão Msgbox como uma palavra que foi digitada corretamente. A verdade é que se nós da Equipe de Scripts fôssemos preguiçosos, poderíamos simplesmente concluir a coluna deste mês por aqui e você ainda sairia com algo útil. Mas, como se diz, você ainda não viu nada.
Observação: na verdade, somos preguiçosos. Mas como ainda havia espaço a ser preenchido em nossa coluna, decidimos mostrar um ou dois scripts de bônus para você.
Como você provavelmente já sabe, o VBScript e o Windows Script Host são um pouco tímidos; na verdade, eles não gostam de falar deles mesmos. No entanto, isso não é verdade para a WMI, para a ADSI e para o Windows PowerShell. Tudo o que você precisa fazer é perguntar e essas tecnologias lhe dirão tudo sobre suas classes, propriedades, métodos — praticamente qualquer coisa e tudo o que você sempre quis saber.
Veja a ADSI, por exemplo. A Figura 4 mostra um script que se conecta ao esquema do Active Directory e recupera todos os atributos do objeto da conta de usuário. Em seguida, ele escreve esses atributos no arquivo C:\Scripts\Scripting.dic.
Figure 4 Adicionar nomes do atributo ADSI a um dicionário personalizado (Close Figure 4)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

Set objSchemaUser = GetObject(“LDAP://schema/user”)

For Each strAttribute in objSchemaUser.MandatoryProperties
 objFile.WriteLine strAttribute
Next

For Each strAttribute in objSchemaUser.OptionalProperties
 objFile.WriteLine strAttribute
Next

objFile.Close
Viu como é muito legal? Com somente algumas linhas de código, criamos um dicionário com todos os atributos do objeto de usuário do Active Directory. Compartilhe esse código seus colegas e ninguém nunca mais terá de se preocupar com nomes de atributos como streetAddress ou givenName marcados como palavras incorretas. E, é claro, isso é infinitamente extensível. Você quer adicionar as propriedades da classe de computador? Então substitua esta linha de código:
Set objSchemaComputer = _
 GetObject(“LDAP://schema/computer”)
E que tal as classes WMI? A Figura 5 mostra um script que recupera uma lista de todas as classes WMI encontradas no namespace root\cimV2 e grava essas informações em C:\Scripts\Scripting.dic.
Figure 5 Adicionar nomes da classe WMI a um dicionário personalizado (Close Figure 5)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

strComputer = “.”

Set objWMIService=GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

For Each objClass in objWMIService.SubclassesOf()
 objFile.WriteLine objClass.Path_.Class
Next

objFile.Close
Você se esqueceu dos nossos usuários do Windows PowerShell? A Equipe de Scripts nunca faria isso. Tudo bem, na verdade nós esquecemos de você. Mas nos lembramos de criar este script de uma linha, que retorna os nomes de todos os cmdlets e então os grava em C:\Scripts\Scripting.dic:
Get-Command | Foreach-Object `
{Add-Content c:\scripts\scripting.dic -value `
$_.Name}
A parte boa da coluna deste mês é que todos nós aprendemos algo. Você aprendeu a criar dicionários personalizados no Microsoft Word e a configurar, por meio de programação, o Word para que ele utilize esses dicionários. E a Equipe de Scripts aprendeu que, se você quiser que algo seja feito, bem, ainda há uma forma melhor de tentar que outra pessoa faça por você. Mas se todo o resto falhar, você sempre poderá fazê-lo por conta própria.


 Os arquivos da &#225;rea de trabalho: Como evitar a perda dos seus dados
Os arquivos da área de trabalho Como evitar a perda dos seus dados and Wes Miller A freqüência com que dados importantes são perdidos é surpreendente. Mas a verdade é que as informações são perdidas porque as pessoas não as protegem corretamente. Explore as etapas importantes que você pode e deve seguir para proteger os dados da sua organização.
As informações anseiam por liberdade. Não importa para quem você as entrega ou o quanto tenta bloquear aqueles zeros e uns, eles sempre encontrarão uma brecha. Todos os dias os noticiários exibem notícias sobre perdas de dados pequenas ou significativas. A idéia de perder dados importantes
Figura 2Esta é uma senha fraca, mesmo que você ame a sua mãe.
A integridade da senha e a autenticação local são fundamentais, mas é claro que os dados do sistema local não devem ser dados que não possam ser comprometidos, a menos que estejam fisicamente protegidos ou criptografados. As senhas, usadas de forma isolada, não são a solução. A senha de um usuário é somente uma ferramenta para garantir que os invasores que queiram comprometer o acesso interativo direto ao sistema e que não tenham boas intenções não sejam bem sucedidos.

Segurança física
Os dados críticos não devem ser armazenados em um sistema que pode ser fisicamente comprometido ou retirado do escritório. Se você teme que seus sistemas sejam comprometidos quando alguém conecta um Windows PE e recupera dados, existem outros problemas, o Windows PE não é o culpado. Em vez disso, uma das afirmações a seguir é verdadeira. Os seus sistemas não estão fisicamente protegidos de forma apropriada. Eles estão protegidos, mas você não confia nos usuários que os acessam, os seus dados estão em um sistema que não está fisicamente protegido, ou os sistemas não pode ser fisicamente protegidos e você não utilizou ferramentas de criptografia de volume, como o recurso BitLocker™ do Windows Vista, para diminuir o risco de comprometimento físico (para saber mais sobre o BitLocker, consulte o artigo de Byron Hynes nesta edição da TechNet Magazine).
Imagine quais são os seus sistemas que podem estar em risco. Você pode protegê-los fisicamente? Por que não colocá-los em um datacenter em alguma outra área com acesso limitado? Se isso não for possível, ou se for um sistema móvel, você utiliza um software de criptografia de volume? Se não puder passar por qualquer uma dessas etapas, mova os dados para um sistema que possa ser protegido ou criptografe-os. No caso do laptop furtado descrito anteriormente, se o volume tivesse sido criptografado com uma ferramenta de criptografia de volume, os dados estariam quase que totalmente protegidos do comprometimento.
Só porque um sistema está em um datacenter, isso não significa que esteja seguro; se houver um monte de conexões com a Internet, você ainda estará em risco. O acesso à Internet aproxima os bandidos do acesso físico, por isso é preciso considerar cuidadosamente as ameaças que pairam sobre os seus sistemas. Considere movê-los para um segmento separado da sua rede, onde você, pelo menos, terá outro nível de proteção de rede entre a Internet e os sistemas analisados.

Redução de risco dos dados
Outra medida de segurança disponível é oferecer aos usuários ao acesso por meio de aplicativos ou de ferramentas de cliente magro que isolem os dados em um servidor protegido fisicamente. Isso pode significar um acesso por meio de uma VPN, para que os usuários que não estejam no local possam se conectar. Você nunca deve permitir que os limites físicos de um usuário ditem como os dados deverão ser tratados. Só porque um usuário está em um local sem banda larga ou outro tipo de acesso de alta velocidade, isso não significa que você deve mover os dados para uma instância local em sua máquina. Se você não puder mover o sistema e precisa mantê-lo em um local inseguro, pelo menos proteja os dados usando a criptografia de volume.

Segurança no sistema
Você deve estar preparado para a possibilidade de, a despeito de seus melhores esforços, alguém invadir o seu sistema removendo o disco rígido e colocando-o em outro sistema Windows, onde as ACLs do NTFS podem ser redefinidas.
Para se preparar para isso, utilize a criptografia de volume incluída no Windows Vista. Para a maioria das outras versões do Windows, há muitas ferramentas de terceiros disponíveis. Elas variam em complexidade de uso, assim como na capacidade de executar a criptografia de todo o volume e/ou a criptografia de arquivos ou de diretórios individuais como permitido pelo EFS (Sistema de Arquivos com Criptografia). Se o volume for criptografado, os dados serão protegidos contra tudo, exceto contra um ladrão mais avançado.

Segurança de arquivamento
Os dados de backup também devem ser protegidos. A maioria das pessoas apresenta dois motivos por não fazer o backup de seus sistemas de forma segura: a criptografia durante o backup torna-o muito demorado e/ou o seu software de backup não oferece suporte para isso.
Mas se você estiver fazendo backup de sistemas, principalmente se estiver seguindo a prática recomendada de armazenar os backups em outro local, deverá proteger os dados contidos nesses backups. Criptografe-os usando o EFS, se estiver disponível, ou outro software de criptografia de volume (como o recurso BitLocker do Windows Vista ou outro software de terceiros) ou adquira um software de backup que inclua recursos de criptografia e que a execute em um nível aceitável. Só porque os dados são, de alguma forma, ofuscados em uma fita de backup ou embaralhados em uma solução de backup baseada em disco, isso não os torna protegidos. Parta do pressuposto de que o próprio mecanismo de transporte será comprometido.

Segurança de transmissão
Você precisa proteger quaisquer dados transportados por cabo. Use somente protocolos seguros para acessar o sistema remoto. Utilize versões criptografadas de protocolos e sempre esteja preparado para um ataque MITM (ataque intermediário). Não utilize protocolos com criptografia ou descriptografia fracas e, se utilizar a criptografia, não use um comprimento ou algoritmo de criptografia fraco. Você ou alguém em sua organização precisa compreender todos os protocolos de comunicação e algoritmos de criptografia usados entre sistemas da sua infra-estrutura.

Exclusão segura
Todos nós já ouvimos estórias sobre discos rígidos ou outros dispositivos de armazenamento comprados no eBay ou em lojas de equipamentos usados analisados por um software forense ou até mesmo recuperados com utilitários que desfazem exclusões, revelando grandes segredos — dados que deveriam ter sido totalmente apagados antes da venda das unidades.
Se você tiver UFDs em sua organização, considere os utilitários de criptografia forçada. Os discos que contêm dados de alto risco devem ser criptografados. A despeito da crença popular, eu não concordo que criptografar volumes antes de jogá-los fora seja uma forma segura de descarte de discos. Você se lembra da metáfora do lixo hospitalar mencionada anteriormente? Considere os dados desses sistemas como lixo tóxico e os utilitários de exclusão segura de dados como o tratamento. Utilize uma ferramenta de exclusão de dados que implemente a especificação DoD 5220.22-M, como o SDelete de Mark Russinovich, antes de liberar seus discos e sistemas para revenda, ou até mesmo antes de mudá-los de lugar em sua organização. Caso contrário, o próximo usuário ficará a par de todos os dados do usuário anterior.

Auditoria
Por fim, outro componente fundamental da segurança de dados é a auditoria, e até mesmo a modelagem contra ameaças, do ciclo de vida dos dados em sua organização. Entenda quais são os pontos fracos por onde os seus dados podem vazar e observe-os cuidadosamente. O Windows oferece várias ferramentas internas de auditoria. No entanto, a auditoria pode facilmente gerar uma sobrecarga de dados. Verifique se você está observando as áreas certas e se não está havendo saturação de dados. Procure por pontos fracos e preencha-os adequadamente com uma boa redução — não conserte as falhas na represa dos dados gerando mais fendas. Verifique também se os seus usuários foram devidamente instruídos sobre como devem tratar os dados. Eles são o vínculo fundamental em muitos níveis da sua organização. Você pode obter mais orientações na barra lateral "Recursos adicionais". Não se esqueça de seguir todas as sugestões apontadas aqui; você dormirá melhor à noite se o fizer.
Recursos adicionais
O "The Core Infrastructure Optimization Implementer Resource Guide—Basic to Standardized" (Guia de recursos do implementador de otimização da infra-estrutura central — do básico ao padronizado) mostrará a você como transformar a sua infra-estrutura de TI de um modelo básico altamente manual e reativo em um nível padronizado com mais automação, padrões de configuração impostos e operações aperfeiçoadas. Baixe o guia em go.microsoft.com/?linkid=5795711. "Additional Infrastructure Optimization Implementer Resource Guides" (Guias de recursos do implementador de otimização da infra-estrutura adicionais) podem ser encontrados em microsoft.com/io. Veja também o artigo "The 10 Immutable Laws of Security" (As 10 leis imutáveis da segurança) para obter mais dicas sobre segurança.


 Anota&#231;&#245;es de campo: Converse com os seus desenvolvedores
Anotações de campo Converse com os seus desenvolvedores and David Aiken Fazer com que os desenvolvedores criem aplicativos mais gerenciáveis é mais fácil do que você pensa. Tudo começa pela comunicação. Os desenvolvedores vêem o software de forma diferente dos administradores. No entanto, ao conversar com os desenvolvedores, os administradores podem explicar o que é importante para eles e os desenvolvedores poderão fazer um trabalho melhor ao projetarem o código adequadamente.
É estranho, mas os desenvolvedores vêem o software de forma diferente dos administradores. Os desenvolvedores trabalham com código, rastreamentos, arquivos de configuração XML, GUIDs e assemblies. Os administradores trabalham com scripts e com snap-ins do MMC (Microsoft® Management Console) ou, pelo menos, eles gostariam que fosse assim.
Na verdade, vamos retroceder uma etapa. Algumas vezes, acho que todo o processo de desenvolvimento de software está dividido. Gastamos milhares de recursos tentando descobrir o que o usuário final quer. Criamos protótipos, conduzimos estudos de usabilidade, entrevistas, entre outras coisas e, quando precisamos oferecer uma experiência de gerenciamento consistente e simples, nós falhamos. E falhamos feio.
Eu costumava achar que Xcopy, o Regedit e o Bloco de notas eram as melhores formas de se instalar um software. Agora eu sei que a melhor forma é por meio do MSI (Microsoft Installer), que pode ser personalizado, instalado e desinstalado. Eu sei que esperar que um administrador configure um Web service usando o Bloco de notas para editar o XML não é, provavelmente, uma idéia brilhante, e que o snap-in do MMC (ou um script do Windows PowerShell™) é, de longe, uma opção melhor. Eu sei que um rastreamento de pilha não ajuda um usuário ou administrador a encontrar a causa principal e as possíveis soluções de um problema, e que um evento bem escrito para os logs do aplicativo é melhor. Eu sei que, para criar um software que possa ser gerenciado e operado por administradores, preciso tratá-los como usuários.
Com um administrador como usuário, posso definir casos de uso, criar protótipos, conduzir estudos de usabilidade e assim por diante. Isso me permitirá oferecer a melhor experiência possível para os administradores. Em outras palavras, isso os ajudará a instalar, configurar, monitorar, corrigir problemas e o meu software sem que eles precisem me chamar. Se eu usar os recursos de gerenciamento internos do sistema operacional a que eles já estão acostumados, posso diminuir significativamente o custo da execução do meu aplicativo (menos encaminhamentos de problemas), aumentar o nível de satisfação do cliente (o aplicativo cairá com menos freqüência e eles poderão corrigir os problemas rapidamente) e ter mais chances deles comprarem outros programas meus e não os seus (resultando em um belo cruzeiro pelo Caribe).
OK, o cruzeiro é um sonho. Mas fazer com que os desenvolvedores criem aplicativos mais gerenciáveis não é meramente um sonho, é uma meta que pode ser atingida. E você também pode ajudar. Na próxima vez em que algo der errado, não basta encaminhar a mensagem de email e xingar as outras pessoas. Em vez disso, eu sugiro que eles escrevam um evento para o log do aplicativo ou que forneçam um contador de desempenho ou alguma outra indicação do problema. Melhor ainda, que sugiram uma causa e uma resolução possível. Peça a eles para criar um script do Windows PowerShell ou um console MMC para configurar o aplicativo. O problema é que os desenvolvedores nem sempre sabem que você existe, muito menos quais são as suas necessidades. Diga a eles.


 Segredos do Windows: O que os novos usu&#225;rios v&#234;em no menu Iniciar
Segredos do Windows O que os novos usuários vêem no menu Iniciar and Raymond Chen Imagine-se comprando um novo computador, iniciando o Windows, clicando no botão Iniciar e vendo um menu vazio. Há uma razão pela qual o menu Iniciar inclui aplicativos no ponto mais usado antes de você ter usado algum deles – para propiciar uma boa experiência pronta para usar. Saiba como esses aplicativos são escolhidos.
Inicialmente, pensamos em preencher o menu Iniciar vazio com texto. Algo como "Olá, é verdade, este espaço está vazio agora, mas à medida que você executar programas, eles aparecerão aqui, confie em mim". O espaço deixava de parecer estúpido. Passava a parecer estúpido e indelicado.
Foram necessárias mais experimentações, mas nós acabamos optando por aquilo que você vê no Windows XP. No mês passado, você viu que a lista dos programas mais usados baseia-se em um sistema de pontuação – os programas com o maior número de pontos aparecem nessa lista dinâmica. Para novos usuários, damos alguns pontos artificiais a vários programas. Dessa forma, o menu Iniciar inicial apresenta uma amostra dos programas para que os usuários tenham uma idéia do que podem fazer.
O número de pontos artificiais é escolhido cuidadosamente para que haja pontos o suficiente a fim de mostrar os programas desejados na lista dos programas mais usados, mas não tantos a ponto de ultrapassarem os pontos reais ganhos pelos programas quando os usuários iniciam os aplicativos.
No entanto, esses pontos artificiais não são concedidos caso o usuário tenha feito a atualização a partir do Windows 2000. Nesse caso, os pontos usados pelo menu Iniciar do Windows 2000 nos Intellimenus foram usados para alimentar o sistema de pontuação do Windows XP. Dessa forma, o menu Iniciar de uma instalação atualizada do Windows XP reflete os programas mais executados pelo usuário no Windows 2000 logo após o bat.
Na versão inicial do Windows XP, os pontos artificiais eram atribuídos de forma que os três primeiros dos seis espaços da lista de programas mais usados fossem escolhidos pelo Windows e os três últimos, pelo fabricante do computador. Caso você tenha comprado uma cópia de varejo, e não pré-instalada, do Windows XP, o Windows preenche dois desses três espaços e deixa o último vazio. Assim, o primeiro programa executado apareceria imediatamente no menu Iniciar.
Esses seis espaços passaram por algumas modificações no Windows XP Service Pack 1. Dois desses espaços eram escolhidos pelo Windows, um pelo Departamento de Justiça dos Estados Unidos e os três restantes pelo fabricante do computador. Assim como acontecia antes, se você comprasse uma cópia do Windows XP no varejo, dois dos espaços do fabricante do computador eram atribuídos pelo Windows e o restante permanecia vazio.
O menu Iniciar é uma das partes mais visíveis da interface do usuário do Windows e, como você pode ver, o trabalho é grande na tentativa de deixá-lo natural e intuitivo.


 Cartas: Respostas &#224;s suas perguntas
Cartas Respostas às suas perguntas
Noções básicas sobre o Windows PE
Depois de ler o artigo de Wes Miller, "Noções básicas sobre o Windows PE", na edição de setembro de 2006 da TechNet Magazine, criei um menu usando o assistente baseado em HTA (HTML para aplicativos). Tenho várias dúvidas sobre como fazer o menu funcionar com o Windows® PE 2.0.
— Andy

Estas são as suas perguntas e as respostas de Wes:

Como posso saber se os componentes de software opcionais HTA e WSH (Windows Script Host) estão sendo executados a partir do meu arquivo ISO?
Se você instalou os componentes opcionais em seu arquivo ISO de acordo com as instruções contidas na documentação, eles deverão funcionar. Já ouvi falar de dois cenários comuns em que eles não funcionam: se você não executou peimp /prep para preparar a imagem, ou se não usou o parâmetro /commit com ImageX para confirmar as alterações feitas na imagem do Windows PE quando ela é desmontada.

Eu preciso instalar o WMI (Instrumentação de Gerenciamento do Windows)? Os arquivos do assistente do artigo geraram um erro do Internet Explorer®.
Os arquivos do assistente devem funcionar, desde que os HTAs estejam instalados; eles são muito rudimentares. Eles não exigem o WMI, pois eu os escrevi antes que você pudesse adicionar WMI ao Windows PE.

Como posso incluir o OC.bat em meu arquivo startnet.cmd?
Não será necessário usar o OC.bat se você estiver usando o Windows PE 2.0 — ele só é necessário para a versão 1.x. O Windows PE 2.0 permite que você adicione componentes sem usar os ajustes feitos pelo OC.bat.

Posso usar parte do código do Wes em meu menu quando tudo começar a funcionar?
Sinta-se à vontade para pegar qualquer um dos exemplos de código e reutilizá-los como quiser, mas você não poderá revendê-los ou redistribuí-los como parte de um pacote de código de exemplo. Consulte o acordo de licenciamento no site da TechNet Magazine para obter mais detalhes.

Onde está o Windows PE?
Onde posso encontrar as ferramentas de compilação do Windows PE? Posso baixá-las ou terei de comprá-las?
— Franklin
As ferramentas de compilação do Windows PE para Windows Vista™ fazem parte do WAIK (Kit de Instalação Automatizada do Windows). Você o encontrará em go.microsoft.com/fwlink/?LinkId=85377.
O WAIK só é compatível com a família Windows Vista. Para a implementação no Windows XP, há diversas ferramentas similares disponíveis no Business Desktop Deployment Solution Accelerator. No entanto, o licenciamento do Windows PE mudou com o Windows Vista. Antes (para Windows XP), o Windows PE só podia ser adquirido por meio do licenciamento do Software Assurance (consulte microsoft.com/licensing/sa/benefits/winpe.mspx para obter mais detalhes).

Gerenciador de Recursos do Servidor de Arquivos
O pacote do Gerenciador de Recursos do Servidor de Arquivos será disponibilizado para download e poderá ser usado na versão original do Windows Server® 2003? Ou esse pacote só é compatível com a versão R2?
— Dan
O Gerenciador de Recursos do Servidor de Arquivos é um recurso do Windows Server 2003 R2. Devido a dependências existentes nessa versão, não há planos para disponibilizá-lo para versões anteriores.

Por dentro do kernel
Depois de ler o artigo de Mark Russinovich, "Dentro do kernel do Windows Vista: Parte 3", tenho duas perguntas. Primeira, notei que o Process Explorer mostra onde os arquivos exe ou DLL são posicionados aleatoriamente em cada sessão de boot. É possível que um malware utilize o mesmo mecanismo para determinar a localização do código que desejo explorar? Segunda, se há 256 posições iniciais possíveis para a escolha aleatória (se eu entendi o artigo corretamente), o que poderia impedir o teste de "força bruta" do malware caso o código visado permaneça estático para a sessão?
— Joe

Mark tem respostas para todas as suas perguntas:

O Process Explorer demonstra uma situação "o ovo ou a galinha": o malware não consegue saber onde estão as DLLs porque não pode descobrir onde está localizada a API que retorna essa informação. O teste de "força bruta" do malware não é um método de injeção confiável, porque se a sua suposição for incorreta, ele pode até travar o aplicativo que está tentando infectar. No mínimo, a escolha aleatória diminuirá a velocidade da disseminação do vírus. Na melhor hipótese, ela evitará que o malware infecte o sistema.

Fale conosco
Você tem algo a dizer? Não seja tímido! Adoramos ouvir os nossos leitores. Mande um email para nós: tnmag@microsoft.com.