June 2008 June 2008
Segurança: O grande debate: segurança pelo disfarce
A segurança pelo disfarce envolve tomar medidas que não removem um vetor de ataque, mas que o ocultam. Alguns podem argumentar dizendo se tratar de uma prática ruim, enquanto outros reclamam que, como parte de uma estratégia maior, cada bit conta. O debate é bem acalorado, e alguns dos nossos melhores especialistas em segurança dão suas opiniões, explicando a segurança pelo disfarce e apresentando os dois lados da questão. Jesper M. Johansson and Roger Grimes
Segurança: Novos PowerToys de elevação para o Windows Vista
Michael Murgolo está de volta com uma atualização para seus PowerToys de elevação. Você encontrará funcionalidade aprimorada de Executar como Administrador que funciona com ferramentas de scripts de terceiros, uma maneira de substituir um recurso útil do Windows XP removido no Windows Vista e várias outras ferramentas úteis. Michael Murgolo
Segurança: Avanços na Criptografia de Unidade de Disco BitLocker
O Windows Vista SP1 e o Windows Server 2008 introduzem alterações significativas feitas no BitLocker, inclusive o suporte a volumes de dados e maior proteção contra ataques criptográficos. Byron Hynes explora os novos recursos, demonstra como usar o BitLocker em um servidor e descreve algumas abordagens recentes da mídia que afetaram o BitLocker. Byron Hynes
Segurança: Bloqueio do aplicativo com diretivas de restrição de software
Quando você deseja reduzir o custo total de propriedade das máquinas desktop na organização, o bloqueio de aplicativo pode ser uma grande ajuda, permitindo limitar os problemas de TI relacionados a aplicativos para os quais não há suporte. Veja como é possível usar as diretivas de restrição de software e a Diretiva de Grupo para controlar os aplicativos em execução em toda a infra-estrutura de TI. Chris Corio and Durga Prasad Sayana
Segurança: Gerenciando o firewall do Windows Vista
A recente atualização feita no firewall do Windows Vista oferece alguns recursos novos e impressionantes que o tornam uma opção atraente para o ambiente corporativo. Jesper Johansson apresenta uma visão geral resumida da evolução do Firewall do Windows e mergulha nas melhorias como, por exemplo, novas regras e perfis, isolamento de domínio e criptografia, que farão com que os administradores observem mais atentamente. Jesper M. Johansson
Segurança: Email seguro usando certificados digitais
As extensões S/MIME permitem ocultar informações em trânsito, validar remetentes e autenticar mensagens. Saiba como proteger o email usando certificados digitais e como solucionar problemas que você possa encontrar no sistema S/MIME. Matt Clapham and Blake Hutchinson
Columns
Do editor: O grande debate: | Cartas: A palavra está com os leitores: | Caixa de ferramentas: Novos produtos para profissionais de TI:
P+R SQL: Erros de E/S, espelhamento de banco de dados e muito mais: Paul Randal responde perguntas sobre SQL Server, mostrando como criar dano em um banco de dados de teste, ajudando a evitar um ciclo de efeito sanfona e explicando como é possível determinar quantos bancos de dados você pode espelhar antes que o desempenho comece a ser prejudicado.Paul S. Randal | Utilitário em destaque: Windows Vista Upgrade Advisor: Pronto para atualizar os sistemas da sua organização para o Windows Vista? Descubra como o Windows Vista Upgrade Advisor pode ajudá-lo a determinar se seus sistemas estão prontos para o Windows Vista e quais versões eles podem suportar.Lance Whitney | Explorando o SharePoint: Descentralizando a administração de sites: Explore as vantagens e as implicações de delegar controle administrativo em sites do SharePoint a departamentos individuais e, ao mesmo tempo, mantê-lo centralizado na infra-estrutura do SharePoint.Pav Cherny
Windows PowerShell: Uma boa aparência: Descubra como a natureza orientada a objeto do Windows PowerShell permite que você aplique formatação à sua saída.Don Jones | Ei, Equipe de Scripts!: Os trabalhos mais simples também têm suas recompensas: A Equipe de Scripts pondera sobre o trabalho árduo, a verdadeira felicidade e a geração de dados de saída na janela de comando em um formato tabular legível.The Microsoft Scripting Guys | Os arquivos da área de trabalho: Segurança X Conformidade: Os profissionais de TI muitas vezes se vêem diante de objetivos contraditórios. Repare em como estar em conformidade freqüentemente custa ser menos seguro.Wes Miller
The Business of IT: 10 segredos para se tornar um líder ambiental: Ao mesmo tempo em que departamentos de TI representam um papel cada vez mais importante em esforços ambientais corporativos, profissionais de TI estão encontrando uma oportunidade de conduzir mudanças e se tornarem líderes de idéias em suas empresas e indústrias. Aqui você terá uma visão geral de como se tornar um líder de idéias competente para iniciativas ambientais e de sustentabilidade na sua organização.Michael Walsh and Eliza Walsh | Anotações de campo: Compartilhando uma tela dividida: Desenvolvido pela Microsoft Research India, o Split Screen permite a dois usuários compartilhar um monitor, enquanto cada um executa uma instância separada do sistema operacional.Kentaro Toyama | Segredos do Windows: Os dois piores PCs de todos os tempos: Raymond Chen afetuosamente relembra de como foi trabalhar com os dois piores computadores já criados.Raymond Chen


Segurança
O grande debate: segurança pelo disfarce
Jesper M. Johansson and Roger Grimes
À primeira vista:
  • Definindo a segurança pelo disfarce
  • Avaliando a segurança por medidas de disfarce
  • Estimando o valor de renomear a conta Administrador
  • Tomando decisões fundamentadas quanto ao gerenciamento de risco

O termo "segurança pelo disfarce" costuma ser recebido com indiferença pelo pessoal da segurança, especialmente por aqueles que desejam se considerar especialistas. Praticamente um palavrão em alguns círculos, a segurança
pelo disfarce, como observado na Wikipedia (en.wikipedia.org/wiki/Security_through_obscurity), representa um dos aspectos mais verdadeiramente controversos da segurança. Muitas vezes, você verá referências jocosas a pessoas cujos esforços são tidos como sendo "apenas de segurança pelo disfarce".
A segurança pelo disfarce é, em poucas palavras, uma violação do Princípio de Kerckhoff, que sustenta que um sistema deve ser seguro por conta de seu design, e não porque este é desconhecido por um adversário. A premissa básica do Princípio de Kerckhoff é de que segredos não permanecem assim por muito tempo.
Como bom exemplo disso, considere o protocolo de autenticação NTLM (Windows NT® LAN Manager), que era inicialmente considerado um segredo de design. Para implementar o produto de interoperabilidade Samba destinado a sistemas operacionais baseados em UNIX, a equipe do Samba precisou fazer engenharia reversa no protocolo. O resultado foi a documentação mais abrangente sobre o protocolo NTLM disponível (monyo.com/technical/samba/translation/ntlm.en.html), bem como a descoberta de vários bugs. Como grande parte da segurança surgiu da criptografia e muitos designs secretos foram revelados, muitos praticantes da segurança acham que toda a segurança das informações deve seguir o Princípio de Kerckhoff.
Mas a segurança pelo disfarce é sempre ruim? Neste artigo, explicaremos o que é a segurança pelo disfarce, tentaremos esclarecer por que muitos consideram-na perda de tempo (e outros, não) e mostraremos por que a resposta, como sempre, é muito mais complicada do que parece à primeira vista.

Introdução à segurança pelo disfarce
Padrões da não-alteração por Steve Riley
Fico do lado dos que "não alteram" no problema da renomeação. Na verdade, nem se trata de uma questão de segurança; é um problema de gerenciamento de sistema. E como passei mais tempo pensando no espaço de gerenciamento dos sistemas (porque gerenciamento e segurança estão se tornando uma coisa só), me tornei cada vez mais adepto de não fazer nada que possa aumentar a fragilidade do sistema. Uma forma segura de aumentar a fragilidade é alterar os padrões das coisas. Há duas (tudo bem, três) razões pelas quais as pessoas alteram as configurações padrão:
  • Existe um requisito conhecido quanto à funcionalidade que a alteração fornece.
  • Há uma pressuposição de que a alteração melhorará a segurança.
  • (Alerta: bobagem à frente.) Alguém leu sobre isso em um artigo de revista.
Caso você precise alterar um nome padrão por conta do motivo número um, vá em frente. Esses tipos de alteração raramente resultam na instabilidade de um sistema, normalmente porque já foram testados.
Caso esteja alterando um padrão diante do motivo número dois, antes pare e reconsidere. Esses tipos de alteração quase nunca são testados pelo fabricante do software e, por isso, este não pode prever como o sistema se comportará depois que você fizer a alteração. Além disso, normalmente existem alternativas muito melhores que fornecerão efetiva segurança.
E se um mau elemento fica sabendo o nome de uma conta? E aí? É a senha e sua força que mantêm a pessoa mal-intencionada longe do sistema. A necessidade de alterar nomes de conta padrão como Administrador e Convidado para algo não tão difícil de adivinhar costuma ser, na realidade, um indicativo do desejo de evitar senhas fortes ou senhas. Corrija o problema efetivo (segredos perdidos), e será possível evitar a fragilidade (alterando os nomes padrão).

A segurança pelo disfarce não inclui medidas que não fazem absolutamente nada para reduzir um problema. Por exemplo, uma organização que bloqueie o protocolo NNTP nos roteadores de borda para impedir que os funcionários leiam grupos de notícias, mas que permita o protocolo SSH, não está usando a segurança pelo disfarce. Como o SSH pode encapsular todos os protocolos, o problema não é disfarçado; a redução inválida implementada deixa de fazer tudo senão impedir que usuários legítimos realizem tarefas legítimas sem violar as diretivas de segurança. Essas medidas não são de segurança pelo disfarce; elas são apenas inválidas e inúteis.
Como a própria palavra "segurança" na locução "segurança pelo disfarce" já diz, você tem alguma proteção com a medida. No entanto, o que também fica implícito – e esse é o problema – é que você, na verdade, não está fazendo nada a fim de parar um ataque em um ou mais vetores. (Um vetor de ataque é, essencialmente, um meio pelo qual um invasor pode acessar um sistema.)
Suponhamos que você tenha um servidor Web vulnerável, por exemplo, que possa ser atacado pela porta TCP 80 usando uma exploração pública. Para fechar esse vetor em especial, é possível corrigir o servidor Web ou desativá-lo; qualquer uma das ações pararia completamente esse vetor. Você poderia parar parcialmente o vetor de ataque usando um firewall ou IPsec para fechar a porta 80 em todos os computadores, exceto alguns selecionados. Isso não bloquearia completamente o vetor de ataque, mas reduziria o problema de maneira significativa.
Por outro lado, a segurança pelo disfarce envolve tomar algumas medidas que não param o vetor de ataque, mas meramente o ocultam. Por exemplo, você pode optar por mover o servidor Web para a porta 81, e não a 80, para que apenas aqueles que saibam onde encontrar o servidor Web consigam fazer isso. Ou é esse o argumento. Na verdade, mover o servidor Web para a porta 81 pára apenas alguns ataques, sendo, em grande parte, uma inconveniência para o usuário final. Um intruso competente simplesmente executaria um scanner de porta e um elemento de destaque de faixa da Web em um grande número de portas para descobrir servidores Web em portas que não fossem padrão. Assim que encontrar uma, ele poderá ativar a exploração no servidor porque você não eliminou, de fato, o vetor de ataque; você apenas (temporariamente) o ocultou.
Isso significa que você não deve ao menos tentar? A resposta... depende. Assim como acontece com quase tudo no campo da segurança das informações, tudo se resume ao gerenciamento de risco. Para compreender os principais fatores a serem considerados, observaremos rapidamente mais algumas medidas de segurança pelo disfarce e, em seguida, abordaremos uma – renomear a conta Administrador – mais detalhadamente.

Avaliando medidas de segurança
São inúmeros os exemplos de segurança pelo disfarce. Eles podem ser ações realizadas por gerenciadores de sistema e de rede ou iniciadas por desenvolvedores de software. No entanto, o que eles têm em comum é que pretendem reduzir uma vulnerabilidade a ocultando de invasores potenciais.
Alguns desses procedimentos não podem apresentar ao menos algum efeito benéfico? É mesmo justo dizer que a segurança pelo disfarce é de todo ruim? Você certamente encontrará propositores de pelo menos algumas dessas medidas. Por exemplo, no Windows®, é possível ocultar as letras da unidade no Windows Explorer. Muitos ambientes, notadamente laboratórios de computadores em escolas, usam essa técnica para evitar que os usuários salvem os dados no disco rígido. Obviamente, como a maioria dos aplicativos ainda pode salvar dados no disco rígido, isso agrega pouco valor como medida de segurança final. No entanto, as instituições que a implementaram normalmente dizem que ela reduz dados no disco rígido.
Outra prática do tipo de segurança pelo disfarce normalmente implementada no Windows é desativar os compartilhamentos de rede administrativos (como, por exemplo, C$, Admin$ etc.). Isso foi pensado para impedir que um invasor seja capaz de se conectar remotamente ao computador. De fato, isso não é apenas verdade, como um invasor com uma conta capaz de usar os compartilhamentos administrativos pode reabilitá-los remotamente. Ainda assim, muitas organizações juram que desabilitar esses compartilhamentos reduz a incidência de malware nas redes.
Um dos nossos exemplos favoritos de esforço mal empregado é a configuração "permitir desencaixe sem fazer logon" no Windows. Caso seja desabilitada, o botão "desencaixar" permanece oculto na tela de logon. A idéia por trás disso é que, dessa forma, um invasor não pode desencaixar o computador a tempo. Obviamente, qualquer intruso pode simplesmente colocar o computador e a base de encaixe em uma sacola e sair por aí com eles, independentemente da visibilidade desse botão. Essa possibilidade sequer é de segurança pelo disfarce.
Outro exemplo claro é a configuração "permitir que operadores do servidor agendem tarefas", que, exatamente como seu próprio nome diz, permite a usuários membros do grupo Operadores de Servidor agendar tarefas. Trata-se de um problema confidencial porque essas tarefas podem ser executadas como Sistema Local e apenas os administradores devem ser capazes de agendar tarefas executadas como Sistema Local. É claro que os operadores de servidor podem se fazer administradores por meio de um número qualquer de vetores diferentes, logo, impedi-los de agendar tarefas dessa maneira tem, na verdade, um valor mínimo.
Ainda assim, muitas organizações gostam dessa configuração porque ela permite que os engenheiros sejam operadores de servidor, e não administradores, o que significa ser menos provável que eles destruam acidentalmente o servidor. Isso, por si só, pode trazer algum benefício.
Então qual é o veredicto? Obviamente, alguns desses problemas podem ser bem complicados. Passamos momentos agradáveis debatendo esses tipos de medida. Roger segue firmemente no time dos que acham essas práticas importantes. Jesper, por outro lado, acha que elas são, na melhor das hipóteses, perda de tempo na maior parte dos casos. Exploremos um dos casos mais citados – e controversos – em termos de segurança pelo disfarce: renomear a conta Administrador. Roger argumentará em favor da medida; Jesper, contra. Nomes importantes da segurança como Aaron Margosis e Steve Riley também fazem suas ponderações nas barras laterais "Renomear a conta Administrador" e "Padrões da não-alteração", respectivamente.

Ocultando a conta Administrador
Renomear a conta Administrador, RID (identificador relativo) 500, para algo desconhecido pelo público geral costuma ser recomendado por profissionais de segurança e está entre os muitos guias de proteção da Microsoft. Até mesmo a Diretiva de Grupo inclui uma configuração para renomear a conta Administrador, como mostrado na Figura 1. A idéia é de que se a conta Administrador for renomeada, um invasor terá mais dificuldade ao fazer logon como sendo o verdadeiro administrador. É claro que o problema mais óbvio em relação ao uso da Diretiva de Grupo nessa operação é que a conta Administrador renomeada terá o mesmo nome em todos os computadores nos quais esse Objeto de Diretiva de Grupo foi aplicado. Isso diminui o valor de disfarce dessa medida de segurança em especial.
Figura 1 Renomeando a conta Administrador
Figura 1 Renomeando a conta Administrador (Clique na imagem para uma visão ampliada)
Neste contexto, também é importante observar que qualquer usuário com uma conta legítima pode recuperar o nome da conta Administrador, independentemente de ter sido renomeada ou não. O RID da conta Administrador é sempre 500. Solicitando o nome da conta cujo RID é 500, qualquer usuário com uma conta pode ver o que é realmente chamado, como mostra a Figura 2.
Figura 2 Localizando contas Administrador renomeadas
Figura 2 Localizando contas Administrador renomeadas (Clique na imagem para uma visão ampliada)

A vez de Roger
O principal argumento que ouço contrário à renomeação da conta Administrador é que é muito fácil converter qualquer nome de conta principal no SID (identificador de segurança) relacionado e descobrir seu RID. E o RID da conta Administrador verdadeira é sempre 500. Assim, caso um invasor possa facilmente converter nomes de conta de usuário nas combinações SID/RID e achar o RID 500, por que se preocupar?
Mas não é tão simples. Para conseguir conversões do nome da conta de usuário em SID/RID, você deve ter acesso às portas NetBIOS ou LDAP. Como a maioria dos firewalls de perímetro não permite esse tipo de acesso pela Internet, até ignorar totalmente o firewall, o invasor não converterá nada. Além disso, conversões anônimas de SID não funcionam no Windows XP e em versões posteriores do Windows, exceto nos controladores de domínio. Nos computadores mais externos (aqueles sob o maior risco), o invasor precisaria de credenciais autenticadas para fazer conversões de nome em SID.
Assim, há um número considerável de obstáculos de defesa reais que devem ser ignorados para que se inicie um ataque de conversão. E mesmo que chegue tão longe, o invasor acaba no mesmo ponto em que estaria se o nome da conta não tivesse sido renomeado. Renomear a conta Administrador só pode aumentar a segurança. Mal certamente não fará.
Trata-se de um outro segredo Caso o invasor não saiba o nome da conta Administrador, este se torna mais um rótulo "secreto", semelhante a uma senha, que um invasor precisa conhecer. Tudo bem, é provável que os nomes de conta de usuário sejam significativamente menos complexos do que uma senha administrativa, mas continua sendo mais um obstáculo que complica exponencialmente o problema da adivinhação/descoberta da senha. Caso já tenha feito testes de penetração de senha, você sabe como é muito mais difícil adivinhar tanto o nome de usuário quanto a senha. Isso constitui uma tarefa já difícil e a dificulta ainda mais.
Barra malware automatizado e script kiddies Tenho atuado na defesa da segurança do Windows há 22 anos e executado 8 iscas do Windows, expostas à Internet, nos últimos 5. Durante todo esse período, jamais vi um malware automatizado (que constitui a grande maioria de todos os ataques) ou sequer usei qualquer rótulo de conta que não fosse Administrador (ou raiz, no caso dos sistemas *NIX). Se renomear a conta Administrador, você interromperá imediatamente todo o malware dependente do nome de administrador. E isso se traduz em um menor risco de segurança.
O mesmo acontece com script kiddies. Todos os manuais de hackers do Windows "kewl" que conheço mencionam técnicas de conversão nome em SID, mas, por alguma razão, jamais vi um caso desses em minhas iscas, mesmo que também tivesse uma conta Administrador "falsa" como saída. Bons hackers devem sempre verificar se a conta Administrador encontrada é a real (RID 500), mas eles não fazem isso. Não sei por quê. Acho que a culpa está na preguiça dos hackers e no comportamento humano desprezível.
Além disso, pára a maioria dos profissionais Isso surpreende a maior parte das pessoas. Quando executa iscas já há alguns anos, você reconhece rapidamente as diferenças entre ataques automatizados, script kiddies e profissionais. Nos últimos cinco anos, com milhões de ataques informados em relação às minhas iscas, jamais vi os profissionais fazerem conversões de SID com a presença da conta Administrador falsa.
Não tenho certeza se alguns criminosos profissionais realizam a conversão de SID, mas estou propenso a apostar que se trata de uma pequena minoria, e uma que jamais documentei. Por que os profissionais não fariam isso? Acho que eles não vêem nenhum motivo para tentar algo quando quase todo o mundo não está.
Simplifica o alerta Agora, a oposição pode argumentar que, se a renomeação da conta Administrador sobressaísse, ela perderia seu valor como técnica de disfarce. O argumento é de que malware, script kiddies e profissionais mudariam suas táticas padrão para procurar nomes diferentes de apenas Administrador. E essa é uma preocupação válida. Felizmente, isso não altera a condição essencial. Primeiro, caso a conta super privilegiada não seja nomeada Administrador, o hacker mal-intencionado deve se esmerar mais. E isso é fato. E caso tenha de trabalhar mais arduamente, é menos provável que o hacker mal-intencionado tente essa avenida de ataque, o que talvez possibilite que uma das demais técnicas aprofundadas de defesa por deslocamento detecte a atividade mal-intencionada mais rapidamente.
E isso me leva à minha última observação em favor da renomeação. Caso a conta Administrador jamais tenha se chamado Administrador e você crie uma outra com esse nome, como mostrado na Figura 3, há aí um bom mecanismo de alerta. Caso o monitoramento de evento detecte uma tentativa de logon usando o nome padrão, trata-se de um evento a ser explorado imediatamente.
Figura 3 Tentativas de logon usando uma conta de nome Administrador falsa podem servir como um aviso antecipado
Figura 3 Tentativas de logon usando uma conta de nome Administrador falsa podem servir como um aviso antecipado (Clique na imagem para uma visão ampliada)
Os nossos logs de eventos estão repletos de logons "inválidos" que não significam nada. Normalmente, trata-se apenas de um usuário (ou o Windows) tentando fazer logon usando uma senha inválida ou algo do gênero. Porém, caso a conta se chame Administrador, como é possível separar facilmente as tentativas de logon válidas das mal-intencionadas? Se jamais teve uma conta de logon Administrador e detectar uma tentativa de logon usando esse nome de conta, você saberá que, provavelmente, existe má intenção. Um aviso antecipado silencioso é muito valorizado na defesa atual.

A vez de Jesper
Renomear a conta Administrador por Aaron Margosis
Jesper, em um mundo ideal, você estaria absolutamente correto. As senhas sempre seriam fortes o suficiente para inviabilizar a adivinhação por força bruta e as contas administrativas locais -500 só seriam usadas na recuperação de emergência. Porém, no mundo real, nada disso acontece.
Apesar da grande divulgação da segurança feita e, em especial, da série de senhas fantástica criada por você ("Grandes debates: Frases secretas X senhas", partes 1, 2 e 3, em go.microsoft.com/fwlink/?LinkId=113157; go.microsoft.com/fwlink/?LinkId=113159 e go.microsoft.com/fwlink/?LinkId=113160), muitos administradores de sistema não têm uma compreensão atualizada do que constitui uma senha forte.
Não faz muito tempo que uma senha composta por oito caracteres aleatórios tirados de vários conjuntos de caracteres era forte; a Lei de Moore tornou isso obsoleto. A educação do usuário (e do administrador do sistema) é um elo frágil e deverá continuar assim até que, pelo menos o tópico da senha forte se torne um item polêmico a ser debatido nos canais de notícias das redes de televisão.
Sendo assim, considerando que a adivinhação de senha no mundo real não demore 600 bilhões de anos e possa, pelo contrário, ser feita durante o almoço, adicionar um multiplicador x1000 pode ter um valor real. E contra os muitos ataques automatizados tendo em vista a conta Administrador, renomeá-la a torna invulnerável.
O tempo e o esforço normalmente envolvidos na renomeação da conta administrativa costumam ser baixos; geralmente, como você observou, trata-se de uma configuração de GPO simples. Na verdade, a U.S. Government's Federal Desktop Core Configuration (csrc.nist.gov/fdcc) exige a renomeação da conta -500. Renomear é apenas uma das muitas configurações obrigatórias, e não a que vi exigindo uma enorme quantidade de tempo ou atenção. Nem vi ninguém se acalmando com um falso sentido de segurança a respeito do valor – ainda tenho que ouvir alguém dizendo: "não precisamos de gerenciamento de patches porque renomeamos as nossas contas administrativas".
A renomeação tem algum valor quando a conta está renomeada da mesma forma em toda a organização? Embora não seja grande, existe um certo valor: primeiro, bloqueia ataques automatizados que esperam Administrador e, segundo, o conjunto de invasores potenciais não é necessariamente um subconjunto de "todos" aqueles que conhecem o novo nome. (O maior risco é quando contas administrativas locais – renomeadas ou não – compartilham uma senha em toda a organização. Gerenciá-las permanece sendo o maior e mais importante problema. Desabilitar a conta -500 é uma forma de resolver isso, embora bloqueie uma avenida de recuperação importante quando as contas de domínio não podem ser usadas.) Também indicarei que nossos guias de segurança recomendavam há muito a renomeação das contas padrão, logo, isso foi bem testado e é totalmente aceito.
Acho que, agora, todos nós sabemos que as medidas de disfarce – por si – não constituem uma defesa adequada. Porém, elas podem aprimorar outras medidas de segurança, e os dados de Roger mostram isso claramente. Desde que o custo da implementação seja baixo, as organizações não devem descartá-la.

Assim com acontece com os argumentos favoráveis, há argumentos válidos desfavoráveis em relação à renomeação da conta Administrador. Antes de entrar nisso, porém, devo admitir que a última observação feita por Roger é extremamente válida. No entanto, em um ambiente altamente gerenciado, qualquer logon com a conta Administrador deve ser investigado porque ela jamais deve ser usada senão em situações de recuperação de emergência.
Isso é supérfluo O principal risco que a renomeação da conta Administrador deve reduzir é o de alguém adivinhar a senha remotamente. Mas somente um usuário que não tivesse outra conta autorizada no computador seria barrado com a renomeação da conta Administrador. Esse invasor normalmente tentaria uma série de senhas aleatórias para fazer o logon na conta Administrador. No entanto, ele receberia a mesma mensagem de erro, independentemente de ter adivinhado ou não o nome da conta e a senha.
Isso sugere que um dos principais argumentos a favor da renomeação da conta Administrador – o de que os script kiddies vão embora – é fraco. Eles não vão embora antes com o nome original da conta Administrador alterado porque não sabem disso! Eles adivinharão o mesmo conjunto de senhas aleatórias, independentemente do que seja e, em seguida, passarão à próxima vítima potencial.
Isso significa que, enquanto a senha da conta Administrador for forte o suficiente para repelir ataques, renomear a conta não agregará valor algum. Digamos que haja uma senha com 15 caracteres em nossa conta Administrador, composta de letras maiúsculas e minúsculas, números e símbolos escolhidos de todo o teclado. Adivinhar essa senha pela rede levará aproximadamente 591.310.404.907 anos. Em termos comparativos, isso é cerca de 43 vezes mais do que a existência do universo.
Agora, digamos que a conta Administrador tenha sido renomeada, e criamos um dos 1.000 valores possíveis. Estenderíamos o tempo de adivinhação da senha para 591.310.404.906.787 anos, ou 43.161 vezes a existência do universo. Estamos mais seguros? Obviamente, estamos três mil vezes mais seguros. Conseguimos tornar mais improvável a adivinhação da nossa senha por parte do invasor? Bem, isso é infinitamente pequeno em ambos os casos. Em outras palavras, em termos reais, não estamos, de forma alguma, melhores do que com o nome original da conta Administrador. Não é só porque renomear a conta interrompe o malware que tenta usá-la que isso significa que haveria êxito do malware se você não tivesse renomeado a conta. Na verdade, se usasse uma senha forte, como deve, você poderia praticamente impedir que ele obtivesse êxito, independentemente do nome da conta.
Fica claro que grande parte das diretrizes de segurança exige a renomeação da conta Administrador, mas isso não faz dessa uma medida de segurança importante, ou mesmo válida. Ela simplesmente retira a possibilidade de tomar uma decisão apropriada quanto ao gerenciamento de risco. Os guias de segurança apresentam configurações que costumam ser muito exigidas, mas que não fazem diferença e que, em muitos casos, sequer existem. Para acabar progredindo no campo da segurança, precisamos dar um passo adiante em termos de requisitos e analisar efetivamente os problemas, além de avaliar se as reduções têm sentido ou não. É importante se lembrar de um ponto crítico aqui: o fato de um invasor estar se direcionando para um recurso não é, por si, motivo suficiente para modificar esse recurso. Você só deve modificar um recurso se tiver uma expectativa justificável de que um invasor terá êxito, a menos que você modifique o recurso.
Se nós pressupusermos uma senha forte, a probabilidade de êxito será efetivamente zero, independentemente da renomeação da conta. Por isso, desde que conte com uma senha forte, você não tem nenhuma razão especial de segurança para renomeá-la. Além disso, se você, assim como eu, operar de acordo com o princípio de que um computador será provavelmente mais estável quanto menos ajustes e alterações fizer nele (um fato bem estabelecido, a propósito), aí é que não haverá mesmo razão para renomear a conta Administrador.
Muda o foco para reduções de valor inferior Um problema com as reduções pela segurança de valor inferior pelo disfarce é que elas tiram o foco das reduções de valor superior na organização. Por exemplo, o tempo e o esforço colocados na renomeação da conta Administrador não podem ser usados em mais nada. Caso esse nada forneça valor superior à renomeação das contas Administrador, a organização perdeu uma oportunidade. Esse talvez não pareça ser um custo real, mas imagine renomear 50.000 contas Administrador, e você vai entender do que estamos falando.
Pior ainda é a possibilidade bem real de que a liderança da organização descanse assim que a redução de valor inferior esteja in-loco. A gerência talvez nem sempre compreenda o valor mínimo fornecido pelas reduções da segurança pelo disfarce e pode não executar etapas adicionais. Isso pode efetivamente oferecer um risco significativo para a organização, ainda que esse risco possa ser tranqüilamente evitado com o simples emprego de tempo e esforço na compreensão do valor das reduções que estão sendo implementadas.
Caro de gerenciar Por fim, dependendo da qualidade de implementação da redução, seu gerenciamento pode ficar bastante caro. Caso você defina apenas um GPO (Objeto de Diretiva de Grupo) para renomear a conta Administrador, o custo é bem baixo. Todos saberão o nome, e o custo da implantação é praticamente zero. No entanto, o valor que isso fornece também é praticamente mínimo porque, como disse, todos com uma conta saberão qual é o nome. Por isso, para obter um determinado valor dessa redução, você precisa usar nomes diferentes em hosts diferentes, e o gerenciamento do sistema acaba ficando caro.
Você estaria muito melhor usando uma ferramenta como passgen (protectyourwindowsnetwork.com/tools.htm) para definir uma senha totalmente aleatória de 100 caracteres em todas as contas Administrador em toda a rede e usar contas diferentes no gerenciamento diário. Considerando que a conta Administrador é essencialmente para fins de recuperação de desastre (exceto no Windows Small Business Server 2003), isso não deve causar muito impacto no sistema do gerenciamento de rede. Além disso, o invasor teria uma chance maior de encontrar uma agulha no fundo do Oceano Pacífico do que adivinhar a senha de qualquer uma das contas Administrador. Já se concentrando em senhas exclusivas e fortes, os script kiddies podem continuar adivinhando o que quiserem.

É tudo uma questão de gerenciamento de risco
Praticamente toda medida de segurança pelo disfarce pode ser analisada na forma que fizemos aqui. Há prós e contras em qualquer esquema, e a abordagem certa para uma organização não necessariamente se adapta a uma outra organização. No final das contas, esse acaba sendo um problema de gerenciamento de risco. Os riscos superam os custos da implementação da solução? Toda decisão tomada por você quanto à proteção dos ativos de informações deve ser uma decisão de gerenciamento de risco bem informada, e raramente as opções são preto e branco.
É verdade: algumas decisões já foram tomadas para você. Por exemplo, embora seja plenamente possível optar por não criptografar informações de cartão de crédito ou armazenar os códigos de verificação do cartão de crédito, qualquer uma das ações deverá resultar em uma perda da possibilidade de aceitar cartões de crédito como forma de pagamento. O provável impacto negativo dessa decisão para a empresa é que você não tem, de fato, uma opção. Em outras palavras, embora essa seja, em grande parte, uma decisão de gerenciamento de risco, se trata de uma fácil de tomar.
Da mesma forma, também é verdade que ninguém, em sã consciência, conectaria uma rede sem fio aberta ao back-end da rede em uma loja física. Porém, isso não significa que a decisão não seja de gerenciamento de risco. Ela é. Alguém pode optar por fazer isso e, se assim o fizer, deverá sofrer as conseqüências (que parecem jamais acontecer de fato, infelizmente).
A etapa chave a ser executada aqui é articular claramente o problema que precisa resolver, as soluções propostas para ele e os prós e os contras de cada uma. Tendo isso, você conta com as informações necessárias para tomar uma decisão de gerenciamento de risco. Sem essas informações, você está tomando decisões com base em uma desconfiança, e essas raramente são boas decisões.

Jesper M. Johansson é arquiteto de software e trabalha na segurança de software, além de ser editor colaborador da TechNet Magazine. Ele possui PhD em sistemas de informações sobre gerenciamento, tem mais de 20 anos de experiência em segurança e é MVP Microsoft em segurança corporativa. Seu livro mais recente é Windows Server 2008 Security Resource Kit.
Roger Grimes (CPA, CISSP, MCSE: segurança), consultor em segurança sênior da equipe ACE da Microsoft, é autor ou colaborador de oito livros sobre segurança de computadores e autor de mais de 200 artigos em revistas. Ele é assíduo palestrante em conferências sobre segurança e colunista de segurança da InfoWorld.
© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução parcial ou completa sem autorização..


Segurança
Novos PowerToys de elevação para o Windows Vista
Michael Murgolo
À primeira vista:
  • Executar como Administrador para Ferramentas de Scripts de Terceiros
  • Executar como Outro Usuário
  • Prompt Aqui como Sistema para CMD e Windows PowerShell
  • Gadget de Elevação Arrastar-e-Soltar
Faça o download do código deste artigo:: Elevation2008_06.exe (197KB)

Bem-vindo a outra edição do PowerToys de elevação para Windows Vista. Dei uma olhada de perto nesse assunto na edição de junho de 2007 da TechNet Magazine. Aqui estamos um ano depois. Dessa vez, quero mostrar a você como expandi a funcionalidade de Executar como Administrador para algumas
das minhas ferramentas de scripts de terceiros favoritas, quero demonstrar como você pode substituir um bom recurso do Windows® XP removido no Windows Vista® e olhar algumas das ferramentas úteis incluídas nos PowerToys de elevação.

Executar como Administrador para Ferramentas de Scripts Adicionais
Um tópico que discuti no artigo anterior (disponível em technet.microsoft.com/magazine/cc162321.aspx) foi habilitar a opção Executar como Administrador para as ferramentas nativas de script do Windows. Para esse artigo, criei PowerToys Executar como Administrador para algumas ferramentas de script de terceiros:
  • AutoIt v3 (www.hiddensoft.com)
  • AutoHotkey (www.autohotkey.com)
  • ActivePerl (www.activestate.com)
  • KiXtart 2010 (www.kixtart.org)
O código de cada um deles está incluído no download deste artigo, que você encontrará em technetmagazine.com. Os arquivos reais são chamados ElevateAutoIt3.inf, ElevateAutoHotKey.inf, ElevatePerlScript.inf e ElevateKiXtart.inf, respectivamente. Para AutoIt v3, AutoHotkey e ActivePerl, a configuração é bem simples. Basta baixar o aplicativo correspondente e instalá-lo no local padrão. Após ter instalado os aplicativos nos quais está interessado, você pode instalar o PowerToy Executar como Administrador apropriado para cada ferramenta.
Infelizmente, o KiXtart 2010 não fornece um instalador. Portanto, para certificar-se de que o KiXtart está instalado em um local padrão para que meu PowerToy funcione adequadamente, eu forneci um arquivo INF que instalará o KiXtart 2010 (v 4.60) em Arquivos de Programas\KiXtart e registrará a extensão de arquivo .kix.
Vá para www.kixtart.org/?p=downloads, baixe o KiX2010_460.zip e descompacte-o em uma pasta. Copie o arquivo Install_KiXtart.inf (incluído no download de código que acompanha este artigo) na mesma pasta. Em seguida, clique com o botão direito do mouse em Install_KiXtart.inf e selecione Install (Instalar). Depois, você pode simplesmente instalar o PowerToy ElevateKiXtart.inf.

PowerToy Executar como Outro Usuário
O UAC (Controle de Conta de Usuário) foi criado para tornar o sistema operacional menos vulnerável a malware por fazer com que os usuários, até mesmo os Administradores, executem a maioria dos aplicativos com privilégios de usuário padrão. O UAC oferece potencial de elevação para tarefas administrativas e outras funções de aplicativos. Esse potencial de elevação é fornecido pela opção Executar como Administrador, que você obtém ao clicar com o botão direito do mouse em arquivos executáveis. Os PowerToys de elevação que discuti na edição de junho de 2007 estenderam esse recurso de trabalhar em outro arquivo e tipos de objetos.
A funcionalidade criada no Windows Vista funciona bem para várias tarefas administrativas. No entanto, um cenário importante ficou de fora para o Windows Vista. Vários departamentos de TI possuem uma política na qual os administradores de rede usam uma conta de usuário para suas tarefas diárias (usando email, criando documentos e assim por diante) e outra conta é usada apenas para a administração da rede (ou administração dos computadores locais).
Isso é feito para ajudar a diminuir o risco de que, se um administrador de rede acidentalmente executar malware fazendo suas tarefas diárias, ele não comprometerá seu sistema inteiro — ou o domínio no qual se encontra. Isso foi atingido no Windows XP usando a opção de atalho Executar como... Mas essa opção foi eliminada no Windows Vista porque foi substituída pela opção Executar como Administrador.
A ferramenta de linha de comando runas, no entanto, ainda existe no Windows Vista. Infelizmente, ela não pode ser usada para as tarefas de conta dupla mais comuns — executando snap-ins MMC (Console de Gerenciamento Microsoft®). Por exemplo, digamos que tenham sido delegadas a você algumas tarefas de gerenciamento de conta no Active Directory®. Você está executando como um usuário padrão para as tarefas diárias e sua conta de administração da rede também é membro do grupo de administradores locais (então, você pode instalar ferramentas de gerenciamento da rede quando necessário) em um computador com Windows Vista com UAC habilitado. Agora você deseja iniciar o ADU&C (Usuários e Computadores do Active Directory) com sua conta administrativa do Active Directory, então você tenta o comando runas, como abaixo:
runas /user:mydomain\admin
"mmc.exe %windir%\system32\dsa.msc"
Infelizmente, isso não faz com que o ADU&C seja iniciado. Em vez disso, você recebe um erro de runas que diz "A operação solicitada requer elevação". O que está acontecendo neste caso é que o MMC executável está marcado para ser executado no nível de privilégio highestAvailable. Como o nível highestAvailable para sua conta de administração da rede é como administrador, iniciar o ADU&C dessa maneira exigiria elevação. Como runas não causa um prompt para elevação, o erro ocorre.
Então, o Windows Vista dificulta esse cenário, pois não fornece um item de menu de contexto para Executar como... e, por não fornecer nenhum meio incorporado para executar um processo como outro usuário, isso requer elevação.
Este seria um artigo frustrante se não houvesse solução para isso, mas, por acaso, um dos meus PowerToys de Elevação originais fornece a chave para resolver o segundo problema e eu incitei outra para resolver o primeiro. (Gostaria de poder reivindicar que eu pensei na solução para o problema da elevação, mas isso foi descoberto por Gov Maharaj da equipe do Windows AppCompat.)
Acontece que o PowerToy de comando de elevação pode ser usado com o comando runas. Onde o comando anterior falhou em causar um prompt de elevação, o seguinte causará o prompt:
runas /user:mydomain\admin
"elevate mmc.exe%windir%\system32\dsa.msc"
Isso faz com que runas inicie elevate.cmd (tecnicamente, o processo sendo lançado é cmd.exe) como o outro usuário e o comando de elevação cuida de iniciar mmc.exe com um prompt de elevação.
Finalmente, eu adotei esse truque, o combinei com associações de arquivos para arquivos .exe e .msc e forneci a ele uma interface de usuário de aplicativo HTML para criar um PowerToy que cria uma opção Executar como Outro Usuário disponível pelo menu de atalho. Quando você selecionar Executar como Outro Usuário, obtém um aplicativo HTML como o exibido na Figura 1.
Figura 1 Ferramenta Executar como Outro Usuário
Figura 1 Ferramenta Executar como Outro Usuário (Clique na imagem para uma visão ampliada)
Aqui, apenas digite o nome de usuário e domínio — para uma conta no computador local, marque a caixa de seleção Usar Conta Local. Você pode clicar no botão Executar para iniciar o aplicativo como um usuário padrão ou clicar no botão Executar como Administrador para iniciar o aplicativo com privilégios elevados. Após clicar em um desses dois botões, runas.exe será executado e solicitará uma senha ou PIN do cartão inteligente.
Como esse PowerToy usa o PowerToy do comando de elevação, você precisa instalá-lo primeiro. Em seguida, clique com o botão direito do mouse no arquivo RunAs.inf, selecione Instalar e aprove a elevação. Para desinstalar a ferramenta, use Programas e Recursos do Painel de Controle.
Você descobrirá que alguns dos atalhos para arquivos .msc nas Ferramentas Administrativas (como Gerenciamento do Computador) funcionará com esse PowerToy. Mas observe que se você instalar as ferramentas administrativas do Windows Server® 2003 usando adminpak.msi, os atalhos criados não são atalhos padrão para os arquivos .msc. Em vez disso, eles são atalhos do Windows Installer e, como resultado, o Windows Explorer não exibirá a opção Executar como Outro Usuário para esses atalhos.
Para esses atalhos, você terá que encontrar os arquivos reais .msc e clicar neles com o botão direito do mouse ou criar novos atalhos para os arquivos .msc. Além disso, runas não funciona com o Internet Explorer® devido à maneira com que o Internet Explorer foi rearquitetado para Modo Protegido no Windows Vista (você pode encontrar informações adicionais com relação a esse problema em support.microsoft.com/?id=922980).
Observação: entre o tempo em que concluí esses PowerToys e a publicação deste artigo, o Windows Sysinternals lançou uma nova ferramenta que é funcionalmente muito semelhante ao meu PowerToy Executar como Outro Usuário. Ela é chamada de ShellRunas e pode ser encontrada no site do Windows Sysinternals: technet.microsoft.com/sysinternals/cc300361.
Como a equipe do Sysinternals realmente escreve códigos reais para viver, você pode preferir a ferramenta deles para seu próprio uso. Eu decidi deixar a minha no artigo como um exemplo de como essa tarefa em particular e extensões do shell em geral podem ser feitas usando aplicativos HTML com código de script.

CMD e Prompt Aqui do PowerShell como Sistema
Existem momentos em que é necessário executar programas no contexto do Sistema Local. Por exemplo, várias ferramentas de distribuição de software, como o SCCM (System Center Configuration Manager), usam um agente cliente executado como Sistema Local para realizar suas tarefas.
Para testar o comportamento de um programa de instalação de software executando como Sistema Local, antes de tentar uma distribuição com um produto como o SCCM, pode ser útil iniciar o instalador usando um prompt de comando executando como Sistema Local. Portanto, eu me propus a criar meus PowerToys CMD e Prompt Aqui do PowerShell como Sistema.
Ao usar o Windows XP, com um script de shell de comando, eu costumava alcançar uma função como esta:
@echo off
sc create CmdAsSystem type= own type= interact
binPath= "cmd /c start cmd /k (cd c:\ ^& color ec ^&
title ***** SYSTEM *****)"
net start CmdAsSystem
sc delete CmdAsSystem
No entanto, se você tentar executar isso a partir de um prompt de comando elevado no Windows Vista, receberá a seguinte mensagem de erro e o prompt de comando executando como Sistema não será exibido:
AVISO:  O serviço CmdAsSystem é configurado
como interativo no suporte que está sendo substituído.
O serviço pode não funcionar adequadamente.
O problema é que esse script tenta criar e iniciar um serviço interativo. Serviços interativos não funcionarão corretamente devido ao Isolamento de sessão 0 no Windows Vista. (Para obter uma explicação sobre o Isolamento de sessão 0, consulte o whitepaper "Serviços no Windows Vista" disponível em microsoft.com/whdc/system/vista/Vista_Services.mspx.)
Para resolver essa limitação, usei a ferramenta Psexec desenvolvida pelo Sysinternals (consulte technet.microsoft.com/sysinternals/bb897553.aspx). Essa ferramenta permite que processos sejam iniciados no contexto do Sistema. Infelizmente, a maioria das ferramentas do Sysinternals não inclui um instalador. Portanto, forneci um arquivo INF (disponível no download do código) para instalar todo o Sysinternals Suite (que inclui Psexec) em Arquivos de Programas\Sysinternals Suite. Como um bônus adicional, esse arquivo INF cria atalhos no menu Iniciar para as ferramentas gráficas do conjunto.
Para instalar o conjunto, baixe primeiro SysinternalsSuite.zip em technet.microsoft.com/sysinternals/bb842062.aspx e descompacte-o em uma pasta. Copie meu arquivo INF (Install_SysinternalsSuite.inf) nessa pasta, clique com o botão direito do mouse em Install_SysinternalsSuite.inf e selecione Instalar. Como esses novos PowerToys usam o PowerToy do comando de elevação, instale esse em seguida. Após fazer isso, você pode instalar CmdHereAsSystem.inf e PowerShellHereAsSystem.inf. Depois que esses PowerToys forem instalados, você terá as opções Prompt CMD Aqui como Sistema e Prompt Aqui do PowerShell como Sistema disponíveis como itens de atalho para pastas e unidades no Windows Explorer, como pode ver na Figura 2.
Figura 2 Opções Prompt CMD Aqui como Sistema e Prompt Aqui do PowerShell como Sistema
Figura 2 Opções Prompt CMD Aqui como Sistema e Prompt Aqui do PowerShell como Sistema
A Figura 3 mostra um prompt CMD executando um sistema. Selecionei as cores vivas como um lembrete de que esse prompt está executando como Sistema e pode fazer coisas inesperadas (e prejudiciais) ao sistema se os comandos incorretos forem inseridos.
Figura 3 O Prompt CMD como Sistema deve ser usado com responsabilidade
Figura 3 O Prompt CMD como Sistema deve ser usado com responsabilidade
Finalmente, esses PowerToys adicionam comandos ao sistema para que esses prompts possam ser iniciados na caixa de diálogo Executar ou em um prompt CMD. Por exemplo, executar o seguinte comando a partir de Executar iniciará um prompt CMD como Sistema na pasta do Windows:
cmdassystem "c:\windows"
O comando equivalente para o Windows PowerShellTM é psassystem. Você deve observar que eu também modifiquei os PowerToys Prompt CMD Aqui e o Prompt Aqui do PowerShell como Administrador para instalar comandos similares — cmdasadmin e psasadmin, respectivamente.

Gadget de Elevação
A maioria dos meus PowerToys requer o clique no botão direito do mouse. Mas, como um bônus para essa atualização, eu inclui algo um pouco mais divertido. Esse é um gadget da Barra Lateral do Windows, que chamo de Gadget de Elevação (mostrado na Figura 4). Ele é um gadget de arrastar-e-soltar. Basta arrastar um executável ou um script do Windows Explorer que possui uma ação de runas definida e ele lançará como elevado.
Figura 4 O Gadget de Elevação Arrastar-e-Soltar
Figura 4 O Gadget de Elevação Arrastar-e-Soltar
Se você instalou meus PowerToys de Elevação anteriores, isso funcionará para scripts do Windows Script Host, scripts do Windows PowerShell, aplicativos HTML e pacotes e patches do Windows Installer (bem como executáveis e scripts do shell de comando com uma ação runas definida por padrão no Windows Vista). E você também pode arrastar mais de um item de uma vez. (Apenas tente arrastar uma pasta até o gadget e veja o que acontece.)
Para instalar o gadget, clique duas vezes em Elevation.gadget (disponível no download do código). Se gostaria de olhar o código para o gadget, basta adicionar a extensão .cab ao nome do arquivo. Você pode então extrair o conteúdo do arquivo Cab.

Conclusão
O download deste artigo contém os novos PowerToys e alguns do artigo original. Fiz alterações pequenas em alguns dos antigos. Por exemplo, as versões originais do Prompt Aqui do Windows PowerShell como Administrador e do Script do WSH de Elevação instalavam suas próprias cópias de elevate.cmd e elevate.vbs. Como vários dos novos PowerToys também dependem desses arquivos, eu alterei essas ferramentas para exigirem que o PowerToy do comando de elevação seja instalado (e eles podem compartilhar essa cópia). Para determinar se um PowerToy requer a instalação do PowerToy do comando de elevação, verifique o cabeçalho no arquivo INF.
Alguns outros PowerToys originais também possuam alterações não-funcionais mínimas. Sempre desinstale a versão antiga de um PowerToy antes de instalar a mais recente. Como essa coleção agora foi expandida para 17 ferramentas, eu incluí scripts de shell de comando para instalar e desinstalar toda a coleção (InstallAllPowerToys.cmd e UninstallAllPowerToys.cmd, respectivamente). Você pode personalizá-los para instalar e desinstalar apenas as ferramentas que precisa usar.
Você deve ter em mente que InstallAllPowerToys.cmd não instala os PowerToys Executar como Administrador para ferramentas de script de terceiros por padrão. Você pode modificar esse script para instalar apenas esses PowerToys para os quais você instalou o software. Quando você executa um deles, ele se iniciará novamente como elevado. UninstallAllPowerToys.cmd deve remover todas as versões antigas dessas ferramentas também.
Como ocorre com todos os meus PowerToys, essas são ferramentas não suportadas, do tipo “use por sua conta e risco”. E não são produtos oficiais da Microsoft — são minhas próprias criações pessoais. Elas apenas foram testadas por mim e alguns outros voluntários com Windows Vista de 32 bits com inglês americano como o idioma padrão. Finalmente, é possível que algum ou todos esses PowerToys não funcionem com futuras atualizações, service packs ou versões do sistema operacional Windows.

Michael Murgolo é consultor sênior de infra-estrutura dos Serviços de Consultoria Microsoft. Ele está focado nas áreas de sistemas operacionais, implantação, serviços de rede, Active Directory, gerenciamento de sistemas, automação e gerenciamento de patches. Ele é um especialista na área de implantação e migração de desktops.


Segurança
Avanços na Criptografia de Unidade de Disco BitLocker
Byron Hynes
À primeira vista:
  • Melhorias feitas no BitLocker
  • Obtendo e instalando o BitLocker
  • Usando o BitLocker em um servidor
  • Considerações quanto à proteção completa dos dados

Na última edição sobre segurança da TechNet Magazine, fizemos um pequeno tour em alguns dos recursos da Criptografia de Unidade de Disco BitLocker do Windows e vimos como ela foi implementada na versão inicial do Windows Vista. Agora com o lançamento do Service Pack 1 para o
Windows Vista® e o novo sistema operacional Windows Server® 2008, chegou o momento de revisitarmos o BitLocker®.
Neste artigo, abordarei algumas das alterações encontradas na versão mais recente, apresentarei uma visão geral de como instalar e usar o BitLocker em um servidor e chegarei a algumas considerações feitas recentemente a serem lembradas. (A propósito, para ler o artigo publicado no ano passado, "Chaves para a proteção de dados com a criptografia de unidade de disco BitLocker", vá até technet.microsoft.com/magazine/cc138009.aspx.)

Novidades
As alterações introduzidas com essa versão do BitLocker oferecem flexibilidade nova sem alterar nenhuma operação básica. As alterações que examinarei são o suporte a volume de dados – que permite a autenticação de três fatores no acesso à máquina –, o suporte à UEFI (Unified Extensible Firmware Interface) – o novo firmware padrão do setor para sistemas de 64 bits –, maior proteção contra ataques criptográficos em metadados de volume e maior uso do TPM (Trusted Platform Module).

Volumes de dados
Quando o Windows Vista foi originalmente lançado, o painel de controle do BitLocker só permitia ativar a criptografia para o volume do sistema operacional Windows® (normalmente a unidade C: ). Para muitos consumidores, isso era perfeitamente adequado, porque computadores domésticos costumam ser configurados com todos os dados e programas do usuário armazenados no mesmo volume do sistema operacional. Porém, nas empresas, e certamente em servidores, normalmente não é esse o caso. Dessa forma, uma das solicitações mais comuns que ouvíamos dos consumidores era a da possibilidade de criptografar volumes de dados – que não fossem o volume do sistema operacional instalado no computador (observe que o BitLocker não foi projetado para criptografar mídia removível).
Como se pode ver na Figura 1, tenho três volumes utilizáveis no computador. (Na verdade, tenho quatro, caso você inclua a pequena partição ativa usada na inicialização.) O meu sistema operacional está instalado na unidade C: (na verdade, isso é mostrado pela "bandeira" do Windows no ícone) e também estão presentes dois volumes de dados, E: e P:. O volume P: já foi criptografado com BitLocker, estando bloqueado no momento. Já o volume E: ainda não está criptografado. No Windows Vista SP1 e no Windows Server 2008, posso criptografar e desbloquear esses volumes de dados no miniaplicativo Painel de Controle do BitLocker.
Figura 1 A interface do Bitlocker
Figura 1 A interface do Bitlocker (Clique na imagem para uma visão ampliada)
Caso o volume do sistema operacional esteja criptografado com BitLocker, o comportamento padrão é de que os volumes de dados criptografados sejam desbloqueados sempre que o volume do sistema operacional é desbloqueado. Caso você use o painel de controle para desbloquear um volume de dados, é possível ver essa opção apresentada como uma caixa de seleção, como mostrado na Figura 2.
Figura 2 Salvando chaves para desbloqueio automático
Figura 2 Salvando chaves para desbloqueio automático (Clique na imagem para uma visão ampliada)
Para ativar ou desativar o "bloqueio automático" de um volume de dados, use a ferramenta de linha de comando manage-bde.wsf. Manage-bde.wsf é um script eficiente incluído no Windows que usa os provedores WMI (Instrumentação de Gerenciamento do Windows) subjacentes instalados com o BitLocker.
Por exemplo, para marcar o volume de dados P: de forma que ele deva ser desbloqueado manualmente, use o seguinte comando:
manage-bde.wsf –autounlock –disable P:
Para reativar o desbloqueio automático para P:, use:
manage-bde.wsf –autounlock –enable P:
Como o painel de controle do BitLocker não expõe tudo o que é possível fazer com o BitLocker e os volumes de dados, você deve usar a opção -? para explorar os comandos de manage-bde.wsf. A sintaxe de manage-bde.wsf também está incluída no "Guia de design da Criptografia de Unidade de Disco BitLocker do Windows" e no "Guia de implantação do BitLocker do Windows", disponíveis no Centro de Download da Microsoft em go.microsoft.com/fwlink/?LinkId=115215.

TPM+USB+PIN
Os clientes também queriam ser capazes de usar fatores de autenticação adicionais usando BitLocker. O BitLocker usa o chip TPM do computador para verificar a integridade da plataforma – em outras palavras, para determinar se os primeiros componentes de inicialização, inclusive o BIOS, não foram adulterados ou corrompidos. No entanto, desde a versão do Windows Vista, agora também é possível exigir um PIN ou a presença de uma unidade flash USB contendo uma chave criada durante a habilitação do BitLocker.
Com o Windows Server 2008 e o Windows Vista SP1, agora é possível combinar todos os três. O TPM continua verificando a integridade da plataforma, a chave USB representando "algo que só você tem" e o PIN, "algo que só você sabe". Essa configuração fornece uma ótima proteção em relação a usuários não autorizados capazes de iniciar o computador e desbloquear as unidades protegidas pelo BitLocker.
No entanto, assim como acontece com muitas coisas na segurança, isso representa uma desvantagem. É claro que, quando o BitLocker é configurado dessa forma, um computador não pode ser reiniciado automaticamente. No caso de um servidor, por exemplo, você deve decidir o que é mais importante: uma reinicialização direta ou níveis mais elevados de proteção.

Suporte à UEFI
Com o Windows Server 2008 e o Windows Vista SP1, o suporte também foi adicionado para computadores equipados com UEFI. A UEFI é uma especificação que representa uma modernização do BIOS tradicional usado pela maioria dos computadores durante a inicialização. Para obter mais informações sobre a especificação UEFI, visite www.uefi.org.

Proteção aprimorada
Quando o BitLocker detecta que houve uma alteração no sistema ou caso um PIN ou chave USB obrigatórios não estejam disponíveis durante a inicialização, o BitLocker entra no modo de recuperação. Na recuperação, os volumes habilitados para BitLocker permanecem bloqueados, e uma caixa de diálogo em modo de texto chamada Console de Recuperação é apresentada para o usuário.
Para desbloquear a unidade, o usuário deve digitar uma senha de recuperação (um número com 48 dígitos) no teclado ou na unidade flash USB. (Quando armazenada em uma unidade flash USB, a senha é, às vezes, chamada de senha de recuperação por estar em um formato binário, e não de texto.)
O BitLocker usa a senha de recuperação para descriptografar as chaves armazenadas nos metadados do volume – a VMK (chave mestra de volume) e, em seguida, a FVEK (chave de criptografia de volume completo) – para desbloquear a unidade. Para que haja êxito na recuperação, uma cópia da senha de recuperação deve estar disponível.
Por isso, além do armazenamento por parte do usuário (como, por exemplo, em uma unidade flash USB), é altamente recomendável que você também armazene a senha de recuperação de maneira centralizada. O sistema operacional inclui a funcionalidade para armazenar senhas de recuperação nos ADDS (Serviços de Domínio Active Directory®).
Os segredos armazenados nos metadados do volume como, por exemplo, a VMK, são criptografados e a integridade de todos os metadados do volume, protegida por criptografia. Se detectar que os metadados do volume foram adulterados, o BitLocker se recusará a usar qualquer um dos metadados e não desbloqueará nenhum dos volumes protegidos. Observe que, sozinha, a senha de recuperação não desbloqueará uma unidade nesse estado.
É importante ressaltar que essa situação só ocorre com um ataque de segurança deliberado contra o computador. Caso isso aconteça, existe uma boa chance do computador já estar nas mãos de alguém mal-intencionado e fora do seu controle. Isso não surgirá de uma simples alteração não planejada feita na plataforma ou caso você se esqueça do PIN.
Para desbloquear o volume, você precisará destes três itens:
  • A senha de recuperação (como texto a ser digitado ou em uma unidade flash USB)
  • O pacote de chaves binárias que inclui versões criptografadas da FVEK e da VMK
  • A ferramenta de reparo do BitLocker
Em suma, você precisa verificar se a empresa tem acesso permanente a todas essas coisas.
É possível fazer o backup manual ou automático da senha de recuperação. Recomendo usar a configuração da Diretiva de Grupo para fazer o backup automático da senha de recuperação nos Serviços de Domínio Active Directory.
Ao configurar essa definição, como mostrado na Figura 3, inclua a opção para fazer o backup do pacote de chaves binárias. O pacote de chaves binárias inclui versões criptografadas da VMK e da FVEK, o que permite usar a ferramenta de reparo do BitLocker, se necessário.
Figura 3 Configurando a Diretiva de Grupo para incluir pacotes de chaves nas informações de recuperação
Figura 3 Configurando a Diretiva de Grupo para incluir pacotes de chaves nas informações de recuperação (Clique na imagem para uma visão ampliada)
A ferramenta de reparo do BitLocker foi projetada para ajudar a recuperar dados de discos danificados habilitados para o BitLocker. Observe que se trata de uma ferramenta avançada, o que significa que deve ser usada por administradores experientes. Para obter mais informações sobre a ferramenta de reparo do BitLocker, leia o artigo da Base de Dados de Conhecimento Microsoft em support.microsoft.com/kb/928201 ou assista ao meu webcast, "Microsoft BitLocker na empresa: ferramentas do BitLocker para simplificar a vida" (que inclui uma demonstração ao vivo), em go.microsoft.com/fwlink/?LinkId=114985.
Esse é um bom momento para destacar que o BitLocker não substitui a necessidade de backup dos dados. Caso o disco seja danificado ou tenha sido atacado deliberadamente, não há certeza de que a ferramenta de reparo do BitLocker será capaz de recuperar algum, quanto mais todos os dados.

Maior uso do TPM
Tecnicamente, não se trata de uma alteração feita no BitLocker, mas interessante o suficiente para mencioná-la. Antes do SP1, a única parte do sistema operacional Windows que usava o TPM era o BitLocker, mas agora ele também é usado em outras funções. Em uma delas, quando o Windows vê que um TPM está disponível, ele usa o TPM como uma origem de maior entropia ao gerar números aleatórios. Isso aumenta a qualidade de todos os tipos de criptografia (e pode até mesmo melhorar seu jogo também).
No entanto, isso também significa que nem todos os eventos relacionados ao TPM mostrados no Visualizar eventos são necessariamente relacionados ao BitLocker. Como profissional de TI, você deseja reconhecer os demais componentes do sistema – e possivelmente o software de outros fornecedores – que podem e usarão o TPM e, assim, causarão o registro dos eventos em log.

BitLocker no Windows Server 2008
Por conta da codebase entre o Windows Vista e o Windows Server 2008, as alterações feitas no BitLocker que aparecem no SP1 fazem parte do Windows Server 2008. Mas por que o BitLocker é relevante em um servidor? Afinal de contas, o BitLocker, por projeto, protege um computador de ataques offline. Em outras palavras, o BitLocker não oferece nenhuma proteção para um sistema em execução, e os servidores, obviamente, devem estar em execução o tempo todo.
Acontece que há ocasiões em que um servidor ou um disco rígido de um servidor podem estar expostos a um ataque offline. Mesmo que isso aconteça, o BitLocker pode ajudar muito quando chegar o momento de descomissionar um servidor ou um disco rígido, como você verá. Primeiramente, vejamos como instalar e executar o BitLocker em um servidor.

Obtendo e instalando o BitLocker
O BitLocker está presente em todas as edições do Windows Server 2008, embora seja um componente opcional, ou recurso, que deve ser instalado no Gerenciador de Servidores ou na linha de comando. O BitLocker é implementado, em parte, como um driver do filtro NTFS. Como instalar esse driver de filtro exige a reinicialização do computador, saiba que ativar o BitLocker em um servidor exigirá uma reinicialização. Além disso, assim como acontece com o Windows Vista, o BitLocker exige uma configuração com carga dividida, em que a partição é usada para iniciar o computador que permanece descriptografado. A ferramenta de preparação da unidade do BitLocker está disponível para ajudar a configurar corretamente os discos rígidos a fim de dar suporte ao BitLocker caso o servidor não tenha sido previamente configurado pelo fabricante. No entanto, caso você se sinta à vontade com o particionamento do disco rígido, é possível configurar os discos rígidos manualmente.
Para instalar o BitLocker no Windows Server 2008, é possível usar a interface gráfica do Gerenciador de Servidores para selecionar BitLocker na lista de recursos, como mostrado na Figura 4, ou usar a interface da linha de comando do Gerenciador de Servidores, emitindo o comando:
Figura 4 Selecionando BitLocker no Gerenciador de Servidores
Figura 4 Selecionando BitLocker no Gerenciador de Servidores (Clique na imagem para uma visão ampliada)
ServerManagerCmd –install BitLocker –restart
Quando você usa o Gerenciador de Servidores, ele instala o BitLocker e as ferramentas de gerenciamento do BitLocker. Também é possível instalar os componentes de gerenciamento sem instalar o próprio BitLocker. Isso evita a necessidade de reinicialização porque o driver de filtro não está incluído. O nome desse componente é "RSAT-BitLocker".
O BitLocker funciona bem em computadores que estejam executando a opção de instalação Núcleo do Servidor, mas não é possível usar o Gerenciador de Servidores para instalar o BitLocker no Núcleo do Servidor ou usar a interface gráfica do usuário para gerenciar o BitLocker no Núcleo do Servidor . Na verdade, para instalar os componentes, use as ferramentas de linha de comando pkgmgr ou ocsetup.
Após a instalação dos binários do BitLocker e da configuração dos discos usando a divisão de carga, é possível habilitar o BitLocker no volume do sistema operacional. No Windows Server 2008, o miniaplicativo do painel de controle do BitLocker tem os mesmos ícones e opções do Windows Vista SP1. Para habilitar os modos avançados do BitLocker, você precisará ajustar as configurações padrão usando o Editor de Diretiva Local ou um Objeto de Diretiva de Grupo que se aplique ao servidor.
No Núcleo do Servidor, ou caso simplesmente não queira usar o painel de controle, é possível usar manage-bde.wsf para habilitar o BitLocker. Para habilitar o BitLocker na unidade C:, digite
manage-bde.wsf –on C: -RecoveryPassword –RecoveryKey F:\
em que C: é o volume a ser criptografado e F:\, uma chave USB ou outro volume no qual uma cópia da chave de recuperação será armazenada (em formato binário). Também é possível usar um caminho UNC para armazenar a chave de recuperação em uma unidade de rede. Também será gerada e exibida uma senha de recuperação (em formato de texto numérico). Você talvez queira adicionar o parâmetro –skiphardwaretest caso tenha a certeza de que a plataforma do hardware atenda a todos os requisitos do BitLocker. Isso evitará uma reinicialização.

Cenários de servidor
Agora, abordemos alguns cenários específicos em que o BitLocker é útil para os servidores. Lembre-se de que, como mencionei, o BitLocker foi projetado para ajudar a protegê-lo de ataques offline – o tipo de ataque realizado quando o Windows não está em execução.
Filiais Um dos primeiros e mais importantes usos do BitLocker em um servidor é como parte da estratégia de filial do Windows Server 2008. Entre um quarto e um terço dos servidores são instalados em filiais, ou seja, escritórios que podem apresentar menor segurança física, menos acesso ao suporte a TI e talvez menos conectividade com data centers. As filiais também são um alvo atraente para ataques. Com recursos como, por exemplo, RODCs (controladores de domínio somente leitura), o BitLocker pode ajudar a proteger dados confidenciais que devem ser armazenados em uma filial para que permaneçam úteis, mas que não seriam tão facilmente protegidos em termos físicos como se estivessem, talvez, em um data center.
Trata-se de uma boa oportunidade de apresentar algumas idéias sobre o nível certo de proteção. O que é mais importante: impedir o acesso não autorizado aos dados ou exigir que um servidor se levante imediatamente e sem nenhuma intervenção? A minha sugestão é de que, em muitas filiais, seria aceitável exigir a entrada de um PIN para reiniciar um servidor, mas essa é uma decisão que cada empresa deve tomar.
Discos na entrega Costuma ser necessário entregar dados em um disco rígido para um local distante. Isso pode incluir a entrega de um disco único ou pré-configurar e entregar um servidor inteiro. Durante a remessa, os dados nesses discos estão fora de controle, podendo ser copiados, perdidos ou roubados.
Para reduzir esse risco, habilite o BitLocker nos volumes do computador antes da entrega e, em seguida, remova todos os protetores de chave, exceto a chave ou a senha de recuperação. Essa chave ou senha pode ser transportada manualmente em separado do servidor ou até mesmo informada ao telefone ou criptografada em email para a equipe na extremidade receptora. Após o recebimento do computador ou do disco, a senha de recuperação é usada para desbloquear a unidade. A unidade pode permanecer descriptografada (adicione outros protetores de chave) ou o disco pode ser totalmente descriptografado após a entrega, se desejado.
Trata-se de uma forma especialmente efetiva de testar os controladores de domínio ou servidores destinados a filiais.
Roubo de um servidor Como observamos na seção anterior, existe um perigo bem real de roubo de um servidor (especialmente de um controlador de domínio). Os ladrões podem levar um laptop diante de uma oportunidade, mas um servidor talvez seja um alvo escolhido mais cuidadosamente. Se o BitLocker estivesse configurado para exigir apenas a verificação de integridade TPM, bastaria o servidor roubado ser ligado e inicializado. Por outro lado, caso as unidades de um servidor estejam protegidas pelo BitLocker e este esteja configurado em um modo avançado – exigindo uma chave USB, um PIN ou ambos –, é muito difícil para que os ladrões consigam obter qualquer informação útil em um período mínimo razoável.
Roubo de um disco No entanto, se apenas um disco for roubado, aí o TPM continuará fornecendo uma grande proteção. Apenas o TPM no servidor original pode ser usado para desbloquear a unidade protegida pelo BitLocker, logo, o disco não pode ser simplesmente inserido em outro computador e lido.
Exposição reduzida Ordenando o hardware do servidor que inclui um chip TPM e usando a verificação de integridade da plataforma do BitLocker, você aumenta a defesa contra algumas formas de malware. Em especial, o BitLocker detectará as alterações feitas enquanto o Windows permanece offline ou as alterações feitas nos primeiros componentes de inicialização, especialmente caso o malware como, por exemplo, um rootkit exija uma reinicialização para que seja instalado. Não se trata de uma solução completa, mas combinada com recursos como, por exemplo, a integridade do código do Windows e produtos como o Microsoft® ForefrontTM Client Security, é mais uma camada de defesa aprofundada efetiva.
Descomissionamento seguro Um dos cenários mais úteis para o BitLocker surge ao final do ciclo de vida de um servidor ou disco. Com que freqüência você ouve falar de servidores, ou seus discos, sendo descartados sem que sejam corretamente descomissionados? Você sabia que discos rígidos usados às vezes valem mais do que novos em sites de leilão, porque compradores inescrupulosos esperam conseguir informações importantes neles?
Felizmente, em vez de passar por um processo caro e demorado de limpeza dos dados úteis no disco, o BitLocker possibilita outra abordagem. Basicamente, nenhuma informação é sequer gravada no disco em um formato útil. Como os dados criptografados são inutilizáveis, trata-se de uma etapa rápida, simples, remover todas as informações principais. Depois disso, não importa o que acontece com o hardware do disco; ele pode ser vendido, reciclado, realocado ou qualquer coisa, sem que haja o medo de que os dados caiam em mãos erradas.
No Windows Vista e no Windows Server 2008, o comando format foi atualizado para limpar as chaves do BitLocker, inclusive várias substituições. Agora você conta com uma forma simples e efetiva de descomissionar uma unidade.

Últimas notícias
Enquanto escrevo isso, provavelmente muitas semanas antes desta publicação chegar às suas mãos, vários artigos, documentos e relatos já abordaram algumas características interessantes de hardware e como elas afetam o BitLocker, os demais recursos de segurança do Windows e os outros produtos de criptografia de vários fornecedores. Gostaria de reservar um momento para abordar algumas das descobertas.
Um desses itens foi publicado por pesquisadores da Universidade de Princeton que demonstraram (com muita eficiência!) uma característica da memória de computador moderna chamada "remanência de DRAM" (disponível em citp.princeton.edu/pub/coldboot.pdf). Em termos simples, o conteúdo da memória do computador pode ser acessado durante um determinado período após a remoção da energia da memória. O BitLocker, obviamente, mantém as chaves para descriptografar os dados na memória durante a execução do Windows, e a preocupação é de que as chaves pudessem ser obtidas por usuários não autorizados.
Outra demonstração de Adam Boileau (security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf) mostrou que o IEEE 1394 (muitas vezes chamado de FireWire) permite o DMA (acesso direto à memória), que pode ser usado para conhecer os segredos do Windows como, por exemplo, senhas ou chaves de descriptografia. O que é interessante a respeito disso é que o DMA é praticamente 1394; não se trata de uma falha, mas do propósito do Firewire.
Mas o que ambos os ataques têm em comum é que exigem o acesso físico a um computador em execução (ou pelo menos em execução até recentemente). O BitLocker não foi projetado para oferecer proteção contra ataques, e isso não elimina a necessidade de alguma segurança física. A defesa aprofundada apropriada exige o uso de várias ferramentas e recursos, criando um ambiente de segurança física, indicando as diretivas corporativas essenciais e instruindo continuamente os usuários.
Bem, essas descobertas não são novas. Elas já são conhecidas há algum tempo e, na verdade, abordadas no DET (Microsoft® Data Encryption Toolkit). A análise de risco fornecida no DET se destina a ajudar os clientes a equilibrar a segurança com a usabilidade, além do custo da implementação e do gerenciamento. E isso não é pouco. Achamos que os clientes instruídos são os mais indicados para tomar decisões quanto às desvantagens da segurança, da usabilidade e do custo.
Além do DET, alguns dos meus colegas fizeram comentários excelentes e apresentaram boas diretrizes. Primeiro, Russ Humphries abordou desvantagens de segurança no contexto da remanência DRAM na entrada no blog go.microsoft.com/fwlink/?LinkId=115217. Depois, Douglas MacIver escreveu sobre as etapas de configuração específicas adicionais e contramedidas que é possível tomar atualmente no blog da equipe da SI (Integridade do Sistema) em go.microsoft.com/fwlink/?LinkId=115218. É altamente recomendável a leitura de ambas essas entradas em blog muito úteis. Você também deve ler o DET.
A chave dentre essas recomendações é usar um modo avançado (ou seja, um que exija uma chave USB ou PIN) e não deixar um computador autônomo no modo de suspensão (use a hibernação em seu lugar).

Conclusão
O BitLocker permanece sendo um dos recursos mais úteis do Windows Vista. Com o lançamento do SP1, ele foi aprimorado diante dos comentários feitos por clientes tendo em vista a habilitação de mais cenários e o atendimento a mais necessidades quanto à proteção de dados. Expandir essa proteção de dados até o Windows Server 2008 oferece mais formas de proteger dados e manter a conformidade, independentemente do armazenamento dos dados em servidores ou estações de trabalho do cliente, no data center, na filial ou com um trabalho móvel.

Byron Hynes é estrategista em tecnologia corporativa do EPG (Microsoft Enterprise and Partner Group), voltado para recursos e produtos de segurança. Antes de ingressar no EPG, ele trabalhou na divisão do Windows Server e está muito ligado ao BitLocker (integridade do sistema) desde 2005. Comentários e dúvidas são bem-vindos. Entre em contato com ele durante a Tech•Ed 2008 ou envie um email para bhynes@microsoft.com.


Segurança
Bloqueio do aplicativo com diretivas de restrição de software
Chris Corio and Durga Prasad Sayana
À primeira vista:
  • Como funcionam as diretivas de restrição de software
  • Inventariando aplicativos no ambiente
  • Criando e impondo diretivas

Quando os profissionais de TI procuram reduzir o custo total de propriedade, ou TCO, das máquinas desktop, existem duas estratégias principais que normalmente vêm à mente. A primeira é retirar as contas dos usuários de desktop
do grupo Administradores. E a segunda é limitar os aplicativos que os usuários podem executar. Abordar esses problemas pode ser um desafio e tanto em um ambiente corporativo, mas o Windows Vista® oferece algumas tecnologias capazes de ajudá-lo a alcançar essas metas.
O Windows Vista e seu recurso UAC (Controle de Conta de Usuário) deram um enorme passo na direção de ajudar os profissionais de TI na execução dos usuários corporativos como membros do grupo Usuários (Usuários Padrão). O UAC alterou o contexto de segurança padrão para que todos os aplicativos fossem um usuário, e não um administrador. Essa migração para o grupo Usuários continua sendo uma tarefa formidável, mas à medida que o setor se ajustar a esse novo paradigma, a tarefa ficará mais fácil com o passar do tempo.
Depois de analisar os desafios da migração dos usuários para o grupo Usuários ou, às vezes, durante esse processo, muitos administradores catalogam quais aplicativos os usuários precisam executar e consideram as etapas necessárias para permitir exclusivamente esses aplicativos. O recurso da diretiva de restrição de software foi projetado para ajudar os profissionais de TI a fazer exatamente isso.
Basta você especificar quais são os aplicativos que têm permissão de execução e, em seguida, implantar a diretiva usando a Diretiva de Grupo. A imposição dessa diretiva em toda a empresa pode reduzir o TCO, porque esse bloqueio limitará os problemas relacionados a aplicativos para os quais não há suporte. (Além disso, é possível usar as diretivas de restrição de software de formas interessantes e extremadas, como abordamos na barra lateral "A diretiva de restrição de software básica".)

Como funciona a diretiva de restrição de software
A diretiva de restrição de software pretende controlar exatamente o código que um usuário pode executar em uma máquina com Windows Vista. Você, o administrador, cria uma diretiva que define o que pode (ou não pode) ser executado no ambiente. Depois, essa diretiva será avaliada sempre e onde o código for executado. Isso inclui o momento de criação do processo, em uma chamada para ShellExecute, e quando um script for executado. (Veremos isso mais detalhadamente daqui a pouco.)
Se for determinado que um aplicativo tem permissão de execução, ele será iniciado. Mas, se for determinado que um aplicativo não tem permissão de execução, ele será bloqueado e o usuário, notificado. Por exemplo, se tentasse executar Paciência no menu Iniciar e isso não fosse permitido, você receberia uma caixa de diálogo semelhante à mostrada na Figura 1.
Figura 1 Uma caixa de diálogo é exibida quando um aplicativo é bloqueado
Figura 1 Uma caixa de diálogo é exibida quando um aplicativo é bloqueado (Clique na imagem para uma visão ampliada)
A interface do usuário para definir uma diretiva de restrição de software é exposta no GPOE (Editor de Objeto de Diretiva de Grupo), onde a diretiva de bloqueio é criada. Há vários métodos para definir qual código pode ser executado e qual não pode. Assim que a diretiva for concluída e testada, você poderá implantá-la.

Definindo a diretiva de restrição de software
A primeira grande decisão que você tomará, uma decisão que afetará drasticamente a forma como a diretiva de restrição de software funcionará no ambiente, é escolher um tipo de regra padrão. As diretivas de restrição de software podem ser implantadas de dois modos: lista de permissões ou lista de negações. Basicamente, você está escolhendo se deseja criar uma diretiva que descreve todos os aplicativos com permissão de execução no ambiente ou uma diretiva que define todos os aplicativos que não podem ser executados.
No modo Lista de Permissões, a regra padrão na diretiva é Restrito, que bloqueará todos os aplicativos que não tenham permissão de execução explícita. No modo Lista de Negações, a regra padrão na diretiva é Irrestrito, que restringe apenas os aplicativos listados explicitamente por você.
O modo Lista de Negações, como você pode imaginar, é uma abordagem irreal caso você esteja em busca de uma redução maior do TCO e mais benefícios de segurança resultantes de um bloqueio de aplicativo. Criar e manter uma lista extensa que bloqueie todo malware e demais aplicativos problemáticos seria praticamente impossível; por isso, recomendamos que a diretiva de restrição de software seja implementada no modo Lista de Permissões, que significa uma regra padrão Restrito.

Inventariando aplicativos no ambiente
Caso pretenda criar uma diretiva que especifique o que os aplicativos podem executar, você precisa determinar exatamente quais são os aplicativos dos quais os usuários precisam. O recurso da diretiva de restrição de software oferece um recurso de registro em log avançado com uma diretiva muito simples para compreender exatamente quais são os aplicativos em execução no ambiente.
Em um conjunto de máquinas de exemplo no ambiente, implante a diretiva de restrição de software com a regra padrão definida como Irrestrito e não se esqueça de remover todas as demais regras adicionais. O plano é habilitar a diretiva de restrição de software, mas não permitir que ela restrinja aplicativos; pelo contrário, você a está usando apenas para monitorar o que está em execução.
Em seguida, crie o seguinte valor do Registro para habilitar o recurso do registro em log avançado e defina o caminho em que o arquivo de log deve ser gravado:
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>
Agora, quando um aplicativo é executado e a diretiva de restrição de software, avaliada (avaliada mesmo que haja permissão de execução para tudo), uma entrada é gravada no arquivo de log.
Cada entrada de log inclui o chamador da diretiva de restrição de software e a PID (identificação do processo) do processo de chamada, o destino avaliado, o tipo de regra de restrição de software atingido e um identificador da regra. Eis uma entrada de exemplo gravada quando um usuário clica duas vezes em notepad.exe:
explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}
Esse arquivo de log representa todas as partes do código executável que a diretiva de restrição de software verificará quando for habilitada e definida para bloquear aplicativos. Isso significa que você deve optar por uma das entradas no arquivo de log, independentemente de serem levadas em conta na Lista de Permissões. Observe que você verá vários binários verificados que fazem parte do Windows® e que são obrigatórios ao funcionamento do sistema.
A técnica de registro de log que descrevemos aqui oferece uma forma clara para que você compreenda exatamente quais aplicativos a diretiva de restrição de software encontrará no ambiente. Mas essa não é a única maneira de realizar essa tarefa.
O Inventory Collector incluído como parte do Kit de Ferramentas de Compatibilidade de Aplicativos da Microsoft® 5.0 oferece a possibilidade de inventariar os aplicativos que estão sendo usados no ambiente. Essa ferramenta oferece várias formas diferentes para que você saiba quais são os aplicativos instados no ambiente, além de também consolidar os resultados em um banco de dados central.

Criando regras adicionais
Agora que conta com uma lista dos aplicativos que devem ter permissão de execução no ambiente, você está pronto para criar as regras reais que permitirão a execução desses aplicativos. O recurso da diretiva de restrição de software usa duas formas para identificar a diretiva – uma baseada nas propriedades criptográficas de um aplicativo (como, por exemplo, seu hash) e outra que define um caminho confiável ou pasta em que os aplicativos confiáveis devem residir.
A Figura 2 mostra onde você adicionaria regras a fim de permitir a execução dos aplicativos no nó Diretivas de Restrição de Software do GPOE (gpedit.msc). A forma mais direta de definir os aplicativos no ambiente é criando uma regra de hash para todos os binários únicos encontrados durante a fase de registro em log.
Figura 2 Usando gpedit.msc para criar diretivas de restrição de software
Figura 2 Usando gpedit.msc para criar diretivas de restrição de software (Clique na imagem para uma visão ampliada)
Como o hash é um valor exclusivo retornado para um determinado conjunto de bits, cada binário da diretiva terá um hash diferente. Essa abordagem é especialmente segura e só permitirá a execução dos binários específicos da diretiva.
Obviamente, existem algumas desvantagens nessa abordagem. Por exemplo, o ambiente poderia ter facilmente muitos milhares de binários. Poderia ser difícil criar todas essas regras na interface do usuário da diretiva de restrição de software e, na medida em que o número de regras fica especialmente grande, o desempenho pode ser afetado. Além disso, cada atualização feita no aplicativo exigirá a implantação de uma ou mais regras de hash novas no ambiente. Atualizar uma diretiva tão grande à medida que os aplicativos são atualizados pode ser uma tarefa gigantesca.
Felizmente, isso pode ser evitado porque há outras duas formas de identificar regras que facilitam o uso de diretivas de restrição de software no ambiente. Indo mais além na rota de segurança criptográfica, é possível criar uma regra que permitirá a execução de qualquer binário assinado por um determinado certificado.
Fazer isso ajuda a simplificar a manutenção da lista de diretivas porque, quando um aplicativo é atualizado, os novos binários serão normalmente assinados pelo mesmo certificado dos anteriores. No entanto, se não quiser que uma versão anterior do binário seja executada no ambiente, você precisará adicionar uma regra de hash Restrito para impedir a permissão do arquivo.
Por padrão, a avaliação das regras de certificado permanece desabilitada para diretivas de restrição de software. Há duas razões pelas quais isso tinha que ser feito.
A primeira: as regras de certificado nas diretivas de restrição de software são definidas pelo que se encontra no repositório Editores Confiáveis do sistema. Como o repositório Editores Confiáveis é usado para outros fins que não sejam o de regras da diretiva de restrição de software, isso exige mais tempo e consideração quando usado no recurso das diretivas de restrição de software.
A segunda razão é que, para determinar se a assinatura de um arquivo é válida, você deve usar um hash do arquivo e compará-lo com as informações da assinatura. O hash de um arquivo é uma operação muito cara – todo o arquivo deve ser lido no disco e processado para calcular esse hash.
Para habilitar as regras de certificado, navegue até o nó Diretivas de Restrição de Software e selecione Objeto de Imposição no painel de resultados. Em seguida, clique duas vezes para abrir a caixa de diálogo de propriedades e selecione a opção de regras de certificado.
A outra forma comum de identificar o código é usando seu caminho na máquina local. Trata-se de uma técnica efetiva e eficiente, mas com uma desvantagem: você deve tomar o cuidado de garantir que as configurações de segurança estejam definidas corretamente na pasta.
Se você adicionasse uma determinada regra de caminho e esse caminho permitisse aos usuários gravar arquivos (na área de trabalho, por exemplo), eles poderiam executar o que quisessem apenas colocando o executável nessa pasta. No entanto, caso não sejam do grupo Administradores, os usuários normalmente não têm a possibilidade de modificar nada em Arquivos de Programas ou nos diretórios do Windows. Isso significa que caso todos os aplicativos estejam no diretório Arquivos de Programas e os usuários não sejam Administradores, você deve observar as regras de caminho para contar com uma diretiva bastante simples e eficiente.
As regras de caminho oferecem outros recursos que as fazem mais adequadas a alguns ambientes. Isso possibilita curingas e permite que você use variáveis do sistema para facilitar a definição de regras portáteis no ambiente – afinal, %systemdrive% talvez não seja﻿ c:\ para todos os usuários.
Em relação ao desempenho e à manutenção, essa talvez seja a forma mais fácil de identificar códigos. Certamente, as regras de caminho são algo a ser considerado, mas você precisa estar atento a considerações adicionais quanto à segurança.

Regras da zona de rede
A diretiva da restrição de software não inclui um tipo de regra chamada de zona de rede, embora esse tipo de regra esteja sendo preterido. A intenção original dessas regras se baseava na idéia de que a origem do código executável em especial poderia ser identificada e era confiável, o que permitia a execução do código. Infelizmente, isso é especialmente difícil de fazer e, assim, nunca funcionou muito bem. Atualmente, esse tipo de regra não é imposto na maioria dos locais dos pontos de entrada da diretiva de restrição de software.
Nos casos em que a maior parte dos aplicativos está instalada no diretório %Program Files%, mas há outros arquivos executáveis instalados nos demais lugares e assinados por um certificado específico, talvez faça sentido usar regras de tipos diferentes. Algumas regras de hash, outras regras de caminho, e você saberá que encontrou a diretiva certa.
Apenas se lembre de que existe uma ordem na qual as regras são processadas (como mostrado na Figura 3). As regras de certificado são as mais específicas, depois vêm as regras de hash e, em seguida, as regras de caminho e as regras de caminho com curingas. Dessa forma, se um código for identificado por uma regra de hash e por uma regra de caminho, o nível de segurança da regra de hash terá prioridade.
Figura 3 Ordem de processamento da regra
Figura 3 Ordem de processamento da regra (Clique na imagem para uma visão ampliada)

Imposição de diretivas
O recurso das diretivas de restrição de software fornece uma ampla cobertura no sistema que está sendo protegido. A idéia é de que qualquer local no qual o código possa ser executado deva ser integrado à diretiva de restrição de software e, assim, verificar a diretiva para saber se o código executável tem permissão de execução.
Embora haja vários locais que verifiquem a diretiva de restrição de software, o ponto de entrada mais direto é CreateProcess. Em CreateProcess, a diretiva é verificada para se determinar se o binário que representa o aplicativo tem permissão de execução. A verificação da diretiva é feita pela API SaferIdentifyLevel, documentada publicamente. O processo geral é ilustrado na Figura 4. (Abordaremos SaferIdentifyLevel mais detalhadamente daqui a pouco.)
Figura 4 Usando SaferIdentifyLevel para determinar se um binário pode ser executado
Figura 4 Usando SaferIdentifyLevel para determinar se um binário pode ser executado (Clique na imagem para uma visão ampliada)
Depois de CreateProcess, a API mais usada em que a diretiva de restrição de software é imposta é ShellExecute. Trata-se da API chamada quando o usuário clica em um aplicativo do menu Iniciar ou clica duas vezes em algo na área de trabalho.
ShellExecute pode ser chamada em vários formatos de arquivo. Em casos como, por exemplo, um arquivo .txt, chamar ShellExecute no arquivo não resulta efetivamente na execução do arquivo – tecnicamente, é claro, o arquivo é aberto. Por esse motivo, a diretiva de restrição de software contém uma lista dos tipos de arquivo executáveis para que possa controlar quais tipos são verificados quando ShellExecute é chamada. É possível personalizar essa lista de tipos de arquivo executáveis na interface do usuário da diretiva de restrição de software.
Além de CreateProcess e ShellExecute, há outros dois pontos de integração principais: LoadLibrary e hosts de script. LoadLibrary é, obviamente, um local importante para verificar o código executável, mas infelizmente apresenta algumas restrições especiais.
A maior parte dos aplicativos tem um executável e várias DLLs carregadas. E normalmente há muitos aplicativos em execução no sistema. Isso significa que LoadLibrary exigiria muita verificação em relação à diretiva. Dependendo da diretiva de identificação do código, esse poderia ser um ponto de entrada cuja imposição é cara – imagine verificar o hash de todas as DLLs carregadas no sistema, que inclui o hash do binário e sua comparação com uma lista de, talvez, milhares de hashes.
Por padrão, essa funcionalidade permanece desabilitada, mas pode ser habilitada manualmente. Para isso, navegue até o nó Diretivas de Restrição de Software em gpedit.msc e clique duas vezes em Imposição. Depois, selecione o botão de opção Todos os arquivos de software.
Como mencionamos, a diretiva de restrição de software é integrada à maioria dos hosts de script do sistema. Isso inclui cmd, VBScript, Cscript e JScript®. Esses pontos de entrada, bem como os demais, usam a API de imposição da diretiva de restrição de software principal: SaferIdentifyLevel.
A API SaferIdentifyLevel determina se um executável especificado deve ter permissão de execução, procurando as informações de identificação nas diretivas de restrição de software relevantes. Trata-se de uma API documentada publicamente. Os hosts de script de terceiros e os ambientes executáveis podem e devem usá-la na integração com a diretiva de restrição de software de forma que a diretiva possa determinar se uma parte do código executável deve ter permissão de execução.

Executando como um usuário padrão
Um recurso não tão conhecido da diretiva de restrição de software é sua capacidade de filtrar os privilégios de determinados aplicativos quando eles são iniciados. Essa funcionalidade foi introduzida no Windows XP, mas não foi exposta na interface do usuário da diretiva de restrição de software até o Windows Vista.
Dessa forma, ela foi uma precursora da UAC do ﻿Windows Vista porque você poderia usá-la na execução de um aplicativo como Usuário Padrão mesmo quando o usuário fosse membro do grupo Administradores. É isso o que acontece quando você cria uma regra e define o Nível de Segurança como Usuário Normal na interface do usuário Regras Adicionais.
A funcionalidade de filtragem de token da UAC e as regras de Usuário Normal das diretivas de restrição de software usufruem uma API subjacente que implementa o mesmo comportamento da API CreateRestrictedToken. No entanto, as diferenças arquitetônicas gerais das tecnologias são bastante significativas. Mas a UAC difere da diretiva de restrição de software de várias formas significativas.
Primeiro, no Windows Vista com a UAC habilitada, por padrão, todos os aplicativos são iniciados com um token de segurança semelhante ao de um membro do grupo Usuários, mesmo quando o usuário é um administrador. Isso é conseguido com a diretiva de restrição de software, embora não haja nenhum modo de iniciar um aplicativo com o token Administrador real do usuário – por exemplo, quando o usuário precisa instalar um aplicativo. A alteração feita no contexto de segurança padrão e a facilidade de acesso ao token de administrador completo de um usuário são os principais benefícios da UAC.
A segunda diferença é que, no caso dos executáveis, o próprio código expressa o nível de privilégio necessário ao funcionamento. Trata-se de uma distinção importante porque ISVs (fornecedores independentes de software) e desenvolvedores compreendem a necessidade do código. Por exemplo, caso precise editar algo que exija privilégio administrativo, um aplicativo de painel de controle pode especificar esse requisito em seu manifesto. Dessa forma, o ISV pode descrever os privilégios exigidos por um aplicativo, em vez de impor um determinado nível de privilégio sem que haja qualquer meio disponível para alterar esse nível.
Por enquanto, você deve evitar usar as regras de Usuário Normal até compreender, de fato, como elas funcionam. A UAC é uma forma excelente de ajudar os usuários de desktop do grupo Administradores, e você deve considerar seriamente deixar a UAC no ambiente corporativo.

Diretivas de restrição de software usadas atualmente
Há várias partes móveis que você precisa levar em conta ao usar a diretiva de restrição de software. Mas não é como você deve pensar e, na verdade, você talvez esteja usando diretivas de restrição de software até mesmo sem perceber. Caso, por exemplo, execute Controles dos Pais em um sistema com Windows Vista, você está usando diretivas de restrição de software para controlar a execução dos aplicativos.
A diretiva de restrição de software foi um desenvolvimento tecnológico importante quando lançado pela primeira vez no Windows XP. Mas o bloqueio do aplicativo só está chamando mesmo a atenção dos profissionais de TI agora.
O recurso da diretiva de restrição de software no Windows Vista ainda tem algumas arestas a serem aparadas, mas está claro que os administradores desejam contar com esse controle maior sobre o que está em execução em seus ambientes. Felizmente para todos nós, essa tecnologia continuará evoluindo e facilitando o gerenciamento dos sistemas em nome dos profissionais de TI, o que reduz o custo da execução do ambiente do Microsoft Windows.﻿
A diretiva de restrição de software básica
Uma aplicação da diretiva de restrição de software é criar uma diretiva que bloqueie o Windows em um modo de quiosque. Na verdade, a Microsoft produz um kit de ferramentas chamado SteadyState™ para a criação desse quiosque. No entanto, caso você esteja interessado apenas em bloquear os aplicativos que possam ser executados, isso pode ser conseguido mais facilmente.
Para permitir que o conjunto mínimo de aplicativos necessários faça logon no Windows Vista, crie uma diretiva que permita a execução de logonui.exe e userinit.exe em %windir%\system32. É provável que a maior parte dos usuários também precisará dos seguintes aplicativos com permissão de execução:
dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....
Se quisesse o shell do Windows padrão, você também desejaria adicionar %windir%\explorer.exe.
Você também poderia optar por inicializar diretamente um aplicativo como, por exemplo, o Internet Explorer®. Nesse caso, seria necessário que você listasse iexplore.exe, e não explorer.exe.
Outro aspecto dessa diretiva básica é que os usuários não devem fazer parte do grupo Administradores. Isso é importante para que eles não consigam ignorar a diretiva. No entanto, como eles só podem executar um conjunto muito básico de aplicativos e não têm os privilégios de um Administrador, os usuários não terão os privilégios para instalar aplicativos ou manter o sistema.
Você precisará encontrar alguma forma de fazer isso nessas máquinas. Caso pretenda atualizar e manter essas máquinas fazendo logon localmente com uma conta Administrador, você deve selecionar o botão de opção que aplica a diretiva de restrição de software a todos os usuários, exceto os administradores locais. A diretiva também deve incluir consent.exe e cmd.exe. Isso permitirá ao administrador iniciar qualquer opção administrativa em um prompt de comando de administrador.
Observe que a UAC limita os privilégios do token de segurança do usuário por padrão para que ele seja semelhante ao token que não é membro do grupo Administradores. Mesmo que você defina a configuração acima para não aplicar a diretiva a Administradores, ela continuará sendo aplicada aos usuários. É somente quando você passa pela experiência de elevação da UAC que o Administrador efetivamente recebe os privilégios de administrador completos e a diretiva de restrição de software deixa de ser aplicada.

Chris CorioChris Corio foi membro da equipe de segurança do Windows na Microsoft durante mais de cinco anos. Na Microsoft, a sua atenção estava voltada principalmente para as tecnologias de segurança do aplicativo e de gerenciamento para a proteção do Windows. É possível entrar em contato com Chris pelo email winsecurity@chriscorio.com.
Durga Prasad Sayana﻿Durga Prasad Sayana é engenheiro de criação de software/teste na equipe de segurança básica do Windows. Seus interesses principais são tecnologias de segurança e testes de software. É possível entrar em contato com Durga pelo email durgas@microsoft.com.


Segurança
Gerenciando o firewall do Windows Vista
Jesper M. Johansson
À primeira vista:
  • Tipos de regra e cenários
  • Perfis de firewall
  • Regras de isolamento do domínio
  • O problema da filtragem de saída

Há pouco tempo, escrevi um artigo no meu blog sobre o firewall do Windows Vista. Essa postagem simplesmente indicava alguns dos recursos interessantes, mas não oferecia muito em termos de auxílio quanto à implantação.
Neste artigo, entro em mais detalhes sobre alguns dos recursos no firewall do Windows Vista® projetados especificamente para facilitar o gerenciamento corporativo. Além disso, também auxiliarei na forma como é possível usá-los para simplificar o trabalho e garantir mais segurança para os usuários.
Com o lançamento recente do SP1 para o Windows Vista, você poderia esperar a implantação corporativa do Windows Vista. (É comum que as empresas aguardem o lançamento do primeiro service pack até migrarem para um novo sistema operacional.) Caso seja um dos profissionais de TI que agora estejam mais seriamente em busca do Windows Vista para o ambiente corporativo, você deve observar com atenção o firewall. Depois de perceber do que o firewall do Windows Vista é capaz, você talvez queira renegociar o contrato que tem com aquele pacote de segurança de terceiros a fim de remover o firewall do pacote.

Firewalls do Windows – agora e sempre
O firewall, na versão original do Windows® XP, deixava muito a desejar. Embora atendesse adequadamente a funcionalidade de segurança em firewalls baseados em host comerciais naquele momento, ele não acrescentava nada de novo ou inovador.
A substituição que acompanhou o Windows XP SP2 foi totalmente modificada. Ela foi projetada especificamente para facilitar a capacidade de gerenciamento corporativo. O firewall do Windows XP SP2 é muito atraente, por ser leve, gerenciável de maneira centralizada, efetivo e não intrusivo. Mas, talvez o mais importante, ele faz algo muito importante: o firewall do Windows XP SP2 protege o sistema durante a inicialização.
O último aspecto é crucial. No passado, vi muitos sistemas serem infectados durante a inicialização, mesmo com um firewall ativado. Na verdade, em meio ao ponto máximo da epidemia Blaster, os índices de ataque chegavam a um a cada quatro minutos. Em outras palavras, se você deixasse um computador desprotegido na Internet, ele poderia ser infectado, em média, em quatro minutos. E se estivesse contando com um firewall que não protegesse o sistema durante a inicialização, 1 a cada 12 sistemas seria infectado nesse momento. Esses números levaram a Microsoft a garantir que o firewall do Windows XP SP2 protegesse o sistema durante a inicialização.
No Windows Vista, o firewall recebeu uma roupagem totalmente diferente. A alteração mais óbvia, do ponto de vista do gerenciamento, é que as interfaces de gerenciamento do protocolo IPsec e do firewall foram mescladas. Trata-se de uma alteração bastante lógica. O IPsec e o firewall foram projetados para bloquear coisas não permitidas. A diferença é que, no firewall, os parâmetros que definem o que é permitido não são muito granulares, e bloquear ou permitir grandes espaços de endereçamento no IPsec é complicado.
Com os dois recursos localizados em uma única interface de gerenciamento, os administradores podem usar ambas as tecnologias diretamente, menos preocupados se algo exige uma regra de IPsec ou deve ter um filtro de firewall. Você tem, essencialmente, uma única visão da superfície de ataque na rede do sistema, e isso ajuda a minimizar o risco de haver enganos.
O SP1 para o Windows Vista adiciona algumas melhorias em termos de confiabilidade aos recursos de firewall. Ele também adiciona algoritmos novos, notadamente os algoritmos do Pacote B, a serem usados em IPsec. Trata-se de um conjunto de algoritmos relacionados à criptografia, formado por AES (Advanced Encryption System), ECC (Elliptic Curve Cryptography) e SHA (Secure Hash Algorithm) 256 e 384.
Porém, o mais importante: o Service Pack 1 adiciona o suporte à NAP (Proteção de Acesso à Rede). A NAP é uma ferramenta de imposição de diretiva que garante que clientes gerenciados e não comprometidos estejam atualizados em relação às diretivas de segurança, atualizações e definições antimalware mais recentes antes de receberem a permissão para se conectar à rede. A NAP não pode impedir a conexão de hosts mal-intencionados com a rede, mas garante a total compatibilidade de todos os hosts gerenciados enquanto não estiverem ativamente comprometidos.
O firewall do Windows Vista, chamado de Firewall do Windows com Segurança Avançada, também está incluído no Windows Server® 2008. Todos os recursos também são gerenciáveis remotamente, podendo ser configurados em uma rede usando a Diretiva de Grupo.

Tipos de regra e cenários
A combinação do firewall e da funcionalidade IPsec na interface de gerenciamento significa que existem dois tipos de regra diferentes agora: regras direcionais e regras de conexão. As direcionais são regras de firewall padrão que definem o tráfego permitido na direção apropriada. As regras de conexão definem os parâmetros de proteção para conexões entre computadores. Para fazer uma analogia, as regras direcionais são um pouco parecidas com as regras de firewall que você conhece de firewalls anteriores, e as regras de conexão são mais semelhantes às regras de IPsec usadas com o firewall no Windows XP SP2.
Integrando o firewall e o protocolo IPsec na mesma interface, surgem vários cenários bastante interessantes. Por exemplo, isolar sistemas um do outro na rede é um dos conceitos de segurança mais importantes atualmente à disposição. A Microsoft chama isso de "isolamento de servidor e domínio".
O isolamento de servidor e domínio usa o protocolo IPsec e a funcionalidade de firewall. Reconhecendo isso, a nova interface de gerenciamento de firewall inclui uma funcionalidade específica nas regras de isolamento. Elas estarão adequadas se, digamos, você quiser restringir a conexão com base nos atributos dos sistemas de origem ou destino como, por exemplo, a associação do domínio.
Como se pode ver na Figura 1, o Assistente para Nova Regra de Segurança de Conexão é iniciado perguntando o tipo de regra que você deseja criar. Caso você selecione Isolamento, o assistente predefine determinadas configurações apropriadas a uma regra de isolamento.
Figura 1 Usando o Assistente para Nova Regra de Segurança de Conexão para criar uma regra de isolamento
Figura 1 Usando o Assistente para Nova Regra de Segurança de Conexão para criar uma regra de isolamento (Clique na imagem para uma visão ampliada)
Você também pode observar na Figura 1 que a regra de isolamento menciona o status da integridade. As regras usadas no isolamento de servidor e domínio são, na verdade, as mesmas usadas na NAP.
É possível impor a autenticação em alguns tipos de tráfego. Por exemplo, é provável que você não queira exigir a autenticação na resolução de DNS. Para os pontos de extremidade desse tipo de tráfego, você precisa de uma regra de isenção. Uma regra de isenção de autenticação é exatamente o que parece: ela isenta o tráfego dos requisitos do protocolo IPsec.
O nome de uma regra servidor-a-servidor está um pouco equivocado. Embora seja muito usada com servidores, ela também pode ser usada com clientes. Uma regra servidor-a-servidor simplesmente configura uma conexão para exigir autenticação. Isso é diferente de uma regra de isolamento em que ela exige não apenas a autenticação, mas também o cumprimento de alguns critérios adicionais como, por exemplo, a associação de domínio ou o estado de integridade.
Basicamente, uma regra de encapsulamento define uma VPN (rede virtual privada) site a site e o encapsulamento entre os gateways. As regras de encapsulamento raramente são usadas com o Windows Vista, porque é improvável que você use o Windows Vista em uma capacidade de gateway. É possível criar regras totalmente personalizadas. Isso permite a personalização de todos os parâmetros da regra.

Ordenação da regra
A ordenação da regra é um pouco complicada à primeira vista. A chave para compreendê-la é primeiro se esquecer da ordenação. Não é tanto uma ordenação, mas mais uma seleção correspondente. Considere o tráfego de entrada como exemplo. O tráfego de entrada que não corresponde a nenhuma regra que permita, por padrão, seu bloqueio. Você pode considerar que uma ordenação afirme "Regras de permissão são consideradas primeiro", mas essa pressuposição estaria incorreta. Se um pacote específico corresponder a regras de permissão e de bloqueio, esta última vencerá. Isso significa que a correspondência, em termos simples, é:
  1. Regras de bloqueio. Caso corresponda a uma delas, um pacote ou conexão é descartado.
  2. Regras de permissão. Caso corresponda a uma delas, um pacote ou conexão é permitido.
  3. Comportamento do perfil direcional padrão. Se nenhuma regra de bloqueio ou de permissão corresponder, o tráfego será tratado de acordo com o comportamento especificado como sendo o padrão para o tráfego naquela direção daquele perfil. Na direção de entrada em todos os perfis, isso significa bloquear o tráfego em uma configuração padrão. Na direção de saída, por padrão, isso significa permitir o tráfego na configuração padrão.
O processo correspondente é moderado por regras de bypass autenticado (IPsec). Usando esse tipo de regra, todo tráfego autenticado correspondente aos demais parâmetros da regra é permitido, independentemente da correspondência ou não em relação às demais regras. As regras de bypass autenticado são direcionais e têm a opção Substituir regras de bloqueio selecionada, como mostrado na Figura 2. Elas são consideradas primeiro a fim de permitir que o tráfego autenticado sempre chegue ao sistema. Trata-se da chave para permitir que você permita facilmente o tráfego de hosts autenticados, mas bloqueie todo o tráfego restante. É possível considerar a regra 0 na ordenação. Dessa forma, a lista da ordem de regra completa fica assim:
Figura 2 Marcando a opção Substituir regras de bloqueio para configurar uma regra de bypass autenticado
Figura 2 Marcando a opção Substituir regras de bloqueio para configurar uma regra de bypass autenticado (Clique na imagem para uma visão ampliada)

0. Regras de bypass autenticado
1. Regras de bloqueio
2. Regras de permissão
3. Comportamento do perfil direcional padrão

Não importa muito se há várias regras dentro de cada classe correspondente ao padrão de tráfego. Assim que uma regra corresponde ao tráfego, o processamento da regra pára.

Público, privado e no domínio
Recursos de rede
  • Central de Segurança do TechNet
  • Usando a ferramenta de linha de comando Netsh Advfirewall
  • Regras de segurança do Firewall do Windows e das conexões baseadas em IPsec no Windows Vista e no Windows Server 2008
  • Security Watch Usando o ACS no Windows Server 2008

O novo firewall tem três perfis: público, privado e domínio. Por outro lado, o firewall do Windows XP SP2 apresentava dois perfis de rede: padrão e domínio. O perfil de domínio é invocado automaticamente quando o computador consegue achar o controlador de domínio. No Windows XP, o perfil padrão era usado de outra forma. Isso fornecia uma funcionalidade eficiente para um administrador de segurança, que poderia bloquear completamente o computador quando estivesse móvel e, mesmo assim, permitir toda a funcionalidade de gerenciamento remoto necessária quando estivesse na rede da organização. Mas essa abordagem apresentava determinados problemas para alguns usuários – em especial, aqueles com redes pessoais domésticas. Como o perfil padrão sempre foi usado como se o sistema não conseguisse chegar ao controlador de domínio, o sistema era bloqueado na casa do usuário.
O novo perfil privado incluído no Windows Vista ajuda a resolver esse problema. Agora quando você conectar o sistema a uma rede nova, ele irá perguntar se essa rede é pública (trata-se simplesmente do novo nome do antigo perfil padrão) ou privada e configurar o sistema de acordo. O sistema se lembra disso sempre que se conecta a essa rede em especial, com base nos parâmetros de rede apresentados a ele pelos servidores de infra-estrutura na rede. Isso não é, de modo algum, à prova de falhas, mas ajuda ao permitir que mais redes sejam corretamente bloqueadas.
A lógica de detecção para saber se o sistema está no domínio também foi aprimorada. O resultado é uma transição mais rápida e confiável, além de menos sistemas pensando se devem usar perfis públicos ou privados quando efetivamente estão no domínio.
É possível vincular regras a um tipo de rede em especial, impedindo o sistema de transportar muitas informações e tentando se conectar a sistemas em redes não confiáveis. Essa é uma área em que a integração entre o firewall e o protocolo IPsec começa a compensar.
Usando essas regras novas, é possível fornecer algumas restrições que outrora não eram possíveis. Por exemplo, durante muitos anos os invasores tentaram ataques por sedução para que os usuários estabelecem conexões de protocolo SMB (Server Message Block) – do sistema de rede do Windows – com hosts não confiáveis, o que forçaria uma seqüência de autenticação que daria a eles um par desafio/resposta que poderia ser usado na descoberta de senhas. As versões anteriores desse ataque também eram usadas no downgrade para autenticação de texto não criptografado ou a fim de refletir o par desafio/resposta do usuário novamente no computador de origem. A técnica anterior foi quebrada há alguns anos. Esta última técnica foi reduzida com o Windows XP SP2 – mas não se esqueça de que transportar pares desafio/resposta não é algo sensato.
Para impedir isso, você poderia usar uma nova função do firewall do Windows Vista: filtragem de saída. Um administrador poderia optar, por exemplo, por bloquear todas as conexões SMB de saída (aquelas que terminam nas portas TCP 135, 139, 445 e UDP 137, 138, 445) no perfil público. Isso dificultaria muito o uso de um sistema em um ataque por sedução a fim de obter pares desafio/resposta ou impedi-lo de acessar compartilhamentos de arquivos do Windows não confiáveis na Internet.
Mais uma vez, isso certamente não é à prova de falhas. Por exemplo, se o sistema já tivesse sido comprometido, essa regra não impediria que o sistema se comunicasse, uma vez que bastaria ao invasor desabilitar a regra. No entanto, pode ser muito útil como medida proteger sistemas de bom comportamento, mas potencialmente expostos.
Nesse contexto, é importante mencionar que, assim como no Windows XP SP2, somente um perfil pode estar ativo por vez no Windows Vista e no Windows Server 2008. Se houver duas interfaces de rede ativas no sistema e uma delas estiver no domínio enquanto a outra está em uma rede pública, o perfil público do firewall será aplicado a ambas. Sempre será usado o perfil mais restritivo. Como você pode imaginar, o perfil público é mais restritivo que o privado, e este último é mais restritivo que o perfil de domínio. Portanto, saiba que a regra de bloqueio SMB de saída pode interromper grande parte do tráfego em conexões VPN.
Para habilitar o tráfego em uma conexão VPN quando o computador está em uma rede pública ou privada, você cria regras direcionais que só se aplicam a interfaces VPN. Para que isso funcione, as interfaces VPN devem ser reconhecidas como tal pelo Windows. Caso você não use o servidor VPN Serviços de Roteamento e Acesso Remoto Microsoft®, teste essa funcionalidade antes de implantá-la amplamente. Trata-se basicamente de um problema com o tráfego de entrada do cliente e de qualquer regra de saída criada.

Criando regras de firewall
Criar uma regra de firewall é muito mais fácil no novo firewall. O Assistente de Nova Regra, mostrado na Figura 3, permite que você defina todos os tipos habituais de regras. E isso inclui regras predefinidas para serviços específicos.
Figura 3 Regras predefinidas no Assistente de Nova Regra
Figura 3 Regras predefinidas no Assistente de Nova Regra (Clique na imagem para uma visão ampliada)
As regras predefinidas são especialmente importantes. O isolamento de servidor está essencialmente relacionado à restrição de serviços de forma que eles só estejam disponíveis para os sistemas que precisam usá-los. Em produtos de servidor, o SCW (Assistente de Configuração de Segurança do Windows) pode ser usado para simplificar isso, ainda que continue havendo algumas dificuldades. (Abordei o SCW na edição de março de 2008 da TechNet Magazine.)
Mas as versões do Windows do cliente não apresentavam funcionalidade semelhante até agora. Quando você usa o tipo de regra predefinida, grande parte do trabalho pesado é feita para você – a tarefa de determinar os pontos de extremidade usados por um serviço. O firewall não reconhece apenas o aplicativo, por saber qual programa o "Serviço iSCSI" representa; ele também contém regras predefinidas que descrevem uma determinada funcionalidade. Isso permite se concentrar nos computadores que precisam ser abordados em uma regra. Essa continua sendo uma tarefa difícil e demorada, mas pelo menos uma exclusiva do seu ambiente.
Também existe uma regra personalizada (disfarçada pelo menu suspenso na Figura 3) que oferece toda a flexibilidade esperada de um firewall de autenticação. Por exemplo, se quisesse uma regra que permitisse apenas o tráfego criptografado de IPsec, você selecionaria a opção para só permitir conexões seguras na página Ação do assistente mostrada na Figura 2.
Ao selecioná-la, você também tem a opção de ativar a criptografia. Se você deixar essa opção em branco, o tráfego usará ESP-NULL (carga de segurança encapsulada com uma chave NULA). Trata-se da maneira recomendável de usar o protocolo IPsec na autenticação. Ele permite que a maioria das ferramentas de gerenciamento de rede continue funcionando porque o tráfego está atravessando a rede sem criptografia, e caso você queira criptografar, basta marcar a caixa.
Em muitas situações, a criptografia do tráfego de rede não é tão importante quanto não aceitar qualquer tráfego de hosts mal-intencionados. Criptografar o tráfego na rede bloqueia um mau elemento que obteve acesso à rede por conta própria vendo o que havia no pacote. Em primeiro lugar, a exigência da autenticação pode impedir o envio do pacote e o ataque. Tudo bem, há muitas situações em que a criptografia no nível da rede é importante, mas também existem muitas outras nas quais você só precisaria de autenticação.

Criando regras de isolamento do domínio
Na maioria dos ambientes, você deseja que um número limitado de computadores possa enviar tráfego para uma estação de trabalho. Na pior das hipóteses, todas estações de trabalho devem ser configuradas com regras de isolamento do domínio. Isso era complicado no Windows XP, mas está fácil no Windows Vista.
Primeiramente, abra a ferramenta de gerenciamento de sua escolha e selecione o nó Regras de Segurança de Conexão. Em seguida, clique com o botão direito do mouse no nó e selecione Nova Regra para abrir a caixa de diálogo mostrada na Figura 1. Selecione a regra Isolamento e clique em Avançar. Agora você precisa selecionar se deseja impor ou não a regra. Em grande parte dos casos em estações de trabalho, você desejará exigir autenticação para o tráfego de entrada. Isso impede que qualquer computador que não tenha ingressado no domínio envie tráfego para a estação de trabalho. No entanto, para solicitar serviços da infra-estrutura, o sistema deve permitir a passagem não criptografada de parte do tráfego de saída. Por isso, a melhor opção é exigir a autenticação em conexões de entrada e solicitá-la em conexões de saída.
Em seguida, escolha o método de autenticação. A seleção padrão se chama, bem, Padrão – um título que não ajuda muito. É possível configurar o método de autenticação padrão de acordo com o computador nas propriedades do protocolo IPsec (acessadas clicando-se com o botão direito do mouse no nó Firewall do Windows com Segurança Avançada e selecionando as propriedades). O método de autenticação padrão sempre é Kerberos porque se trata do mais simples e mais seguro. No entanto, por uma questão de clareza, recomendo que você efetivamente o selecione ao criar suas regras. Normalmente, você deseja autenticar apenas o computador, e não o usuário também. Caso exija ambos, você talvez não consiga aceitar determinados tipos de tráfego de gerenciamento como, por exemplo, o tráfego SNMP transmitido de maneira anônima.
Depois de ter selecionado o método de autenticação, tudo o que você precisa fazer é selecionar os perfis nos quais essa regra deve estar disponível. Como se trata de uma regra que se aplica a computadores que ingressaram no domínio, os quais podem apresentar um tíquete Kerberos, não faz sentido abrir essa falha específica nos perfis Privado ou Público. Salve a regra e pronto.
As regras de isolamento básico não são mais complicadas do que isso. No entanto, para usufruir a eficiência do protocolo IPsec em termos de isolamento, você precisa implementar o isolamento de servidor até mesmo nas estações de trabalho. Fazendo isso, é possível evitar que as estações de trabalho ouçam os demais clientes. Na verdade, elas só responderão às estações de gerenciamento apropriadas. Imagine o impacto muito menor que várias interrupções de malware teriam se os sistemas do cliente tivessem se recusado a ouvir os demais clientes.

Criando scripts no firewall
O novo firewall acompanha uma API substancial que permite criar scripts para implantação e avaliação. O ideal é que você use a Diretiva de Grupo na implantação, mas como ela nem sempre está disponível, é importante contar com um conjunto apropriado de APIs para configurar o firewall. As APIs estão agrupadas no conjunto INetFWPolicy2 de APIs. O Software Development Kit e a MSDN® Library contêm mais detalhes completos sobre como usá-las, embora alguns exemplos ajudem a ilustrar o assunto.
Um exemplo comum é a necessidade de determinar se um grupo de regras está ativado. Digamos, por exemplo, que um aplicativo ou administrador precise determinar se o compartilhamento de arquivo e impressora está permitido em um sistema. Isso pode ser feito com INetFWPolicy2::IsRuleGroupCurrentlyEnabled. A Figura 4 fornece um exemplo de VBScript que demonstra essa função.
Figure 4 Usando INetFWPolicy2::IsRuleGroupCurrentlyEnabled
' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if
Agora, caso o compartilhamento de arquivo e impressora esteja desativado e você precise ativá-lo, primeiramente é necessário garantir que isso possa ser feito e que não será substituído pela Diretiva de Grupo. Isso é feito com a API INetFWPolicy2::LocalPolicyModifyState. Um esqueleto, que pode ser preenchido com código real, é mostrado aqui:
Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

Linha de comando e tipos de interface
Nenhum firewall estaria completo sem uma linha de comando apropriada ao gerenciamento. Há um subcontexto em netsh, chamado advfirewall. O contexto advfirewall oferece o acesso de linha de comando a tudo o que é possível fazer na interface gráfica do usuário. Por exemplo, caso você queira implementar o bloqueio de saída na porta 445, é possível executar o seguinte comando em um prompt de comando privilegiado:
netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any
Em seguida, você precisa executar o mesmo comando, substituindo TCP por UDP para completar o bloqueio. A essa altura, você já concluiu a implementação da regra.
Um recurso interessante do firewall é a possibilidade de configurar regras com base no tipo de interface da rede. Lembre-se de que algumas regras podem causar impacto sobre conexões VPN. Desde que o Windows reconheça a interface como sendo VPN, é possível usar esse tipo de regra para isentar o tráfego dessa interface:
netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS
Também é possível fazer isso na GUI, mas só após a criação da regra. Em seguida, você precisa clicar com o botão direito do mouse na regra, selecionar Propriedades e clicar na guia Avançado. Lá você encontra uma seção Tipos de Interface na qual é possível selecionar os tipos de interface corretos.

Filtragem de saída
A ausência da filtragem de saída no firewall do Windows XP SP2 era considerada uma das principais provas de que o firewall interno não era adequado à segurança. Talvez haja milhares de artigos escritos dizendo que a insegurança do firewall do Windows XP SP2 se deve à ausência da filtragem de saída. Isso apesar do fato de nenhum firewall no Windows XP poder fornecer com segurança a filtragem de saída.
A funcionalidade fundamental que transforma a filtragem de saída em um recurso de segurança útil rapidamente – ou ferramenta de imposição da diretiva, como usava anteriormente – simplesmente não existe no Windows XP. Mas ela existe no Windows Vista. Por isso, é mais do que lógico que o novo firewall use esse recurso. Por padrão, grande parte do tráfego de entrada é bloqueada e a maior parte do tráfego de saída, permitida.
Por padrão, a filtragem de saída no novo firewall do Windows Vista só bloqueia o tráfego desnecessário dos serviços. Isso é realmente tudo o que se pode fazer para fornecer proteção contra um comprometimento no host que ofereça os filtros de saída, e fazer isso no Windows XP seria inútil.
Os serviços no Windows Vista podem ser executados com um token altamente restrito. Basicamente, cada serviço tem seu próprio SID (identificador de segurança), exclusivo do serviço. Esse SID de serviço pode ser usado para restringir o acesso a recursos como, por exemplo, portas de rede. Trata-se da mesma funcionalidade que vimos anteriormente quando observamos a restrição do tráfego para usuários. Isso significa que, mesmo que dois serviços possam ser executados como NetworkService, eles não podem gerenciar os processos um do outro, e o firewall pode ser configurado para permitir que apenas um deles se comunique. Caso um que esteja bloqueado seja comprometido, ele não pode seqüestrar o serviço permitido e usar sua porta permitida para se comunicar porque a porta está restringida pelo SID de serviço.
Essa funcionalidade é outro dos recursos de segurança bem interessantes adicionados ao Windows Vista, e o novo firewall a usa para fornecer, de fato, segurança real por meio da filtragem do firewall de saída.
Na verdade, a filtragem do firewall nas SIDs de serviço está habilitada por padrão no novo firewall. No entanto, não há nenhuma GUI para configurá-la. As regras estão predefinidas na chave do Registro HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices. Porém, você deve tomar muito cuidado com a modificação manual dessa chave, porque não há suporte para isso.

Qual é o nível de segurança que a filtragem de saída pode fornecer?
Uma questão consideravelmente mal compreendida na comunidade de segurança é o nível do valor de segurança efetivamente oferecido pela filtragem de saída. Até agora mencionei dois cenários que fornecem segurança por meio da filtragem de saída, mas ambos dependem da nova funcionalidade do Windows Vista que até então não estava disponível. Apesar disso, existe uma percepção geral de que a filtragem de saída costuma ser boa e que deve ser um fator-chave nas decisões de compra de firewall.
Ironicamente, em muitas organizações, os recursos da filtragem de saída motivavam a decisão de compra e, dessa forma, a filtragem de saída não era usada após a implementação do firewall. Isso está mal orientado e leva a uma perda financeira e de esforço em relação ao grupo de segurança das informações. Isso parece estar mais ligado a um desejo de se sentir bem quanto a fazer algo relacionado à segurança do que propriamente uma análise real de uma ameaça. É muito comum que o desejo desse tipo de "teatro da segurança" motive decisões que deveriam ser tomadas, na verdade, com base em fatos.
Existe um fato bem simples a respeito da filtragem de saída que seus propositores se esquecem de levar em conta. O argumento habitual dos fornecedores de firewall baseado em host é de que, se um sistema for comprometido, independentemente de ser por um worm ou por um usuário mal-intencionado interativo, a filtragem de saída impedirá que o worm continue infectando os demais sistemas ou que o invasor continue se comunicando. E isso não é verdade.
A verdade é que, com tudo sendo igual, a filtragem de saída interromperia alguns malwares históricos. No entanto, se o Windows XP acompanhasse filtragem de saída, seria mais do que provável que os worms que vimos até hoje fossem escritos para desativar ou até mesmo contorná-la.
No Windows XP (e em versões anteriores do Windows), qualquer worm em execução como serviço (e todos os worms mais comuns que surgem em meio à conversação eram executados como serviço) poderia fazer isso. A única razão pela qual não fizeram isso é que praticamente não havia ambientes usando a filtragem de saída e, por isso, era desnecessário desabilitá-la. Em um ataque interativo, o invasor pode contornar filtros de saída como quiser. Caso o invasor tenha a possibilidade de executar código arbitrário, isso é fácil. Mas, se necessário, o invasor também pode seduzir o usuário a contornar os filtros.
O contorno de filtros de firewall baseados em host de saída pode ser feito de várias formas, dependendo do cenário do ataque real. A maneira mais simples de abordar isso é "pedir" a um usuário com muitos privilégios para fazer isso para você. Muitos ambientes continuam executando usuários como administradores. Esses usuários têm o direito de contornar diretivas de segurança a seu modo. Tudo de que o invasor precisa é apresentar ao usuário uma opção entre um benefício de segurança não imediato e, de certa forma, intangível e algo que ele valoriza muito – algo como duendes.
Em muitos casos, o usuário é tão inundado com esses tipos de caixas de diálogo que acaba clicando rapidamente sem saber, de fato, o que está acontecendo. Trata-se do problema número um em relação à filtragem de saída. Considerando a opção entre a segurança e as recompensas suficientemente atraentes, como os duendes, estes sempre ganharão porque a grande maioria das caixas de diálogo que pede aos usuários tomar decisões de segurança é destituída de qualquer informação que os permitisse realmente tomar essa decisão.
Apresentar caixas de diálogo, pedir decisões de segurança, com informações suficientes para fundamentar essa decisão, é muito mais difícil do que parece porque precisaria que o produto de segurança como, por exemplo, o firewall, compreendesse não apenas portas, protocolos e o aplicativo que está fazendo a solicitação, mas também o que a solicitação está realmente tentando fazer e o que isso significa para o usuário. Essas informações são muito difíceis de serem obtidas programaticamente. Por exemplo, o fato de o Microsoft Word estar tentando estabelecer uma conexão de saída não é tão interessante quanto o que o Word está tentando fazer com essa conexão exatamente.
Precisamos reduzir o número de caixas de diálogo sem significado, e não aumentá-lo, e os firewalls com filtragem de saída não ajudam nisso. Para ter uma idéia da última palavra no fornecimento de informações importantes para o usuário, observei a documentação de venda de um dos principais fornecedores de firewall baseado em host. Eles falam da capacidade de filtragem de saída do firewall e da capacidade de aviso. A capacidade de aviso detecta o que o usuário está tentando fazer e dá o aviso apropriado. Ou assim diz a teoria. O texto do folheto estava acompanhado de uma captura de tela que dizia: "O aviso ainda não está disponível para este programa. Escolha um abaixo ou clique em Mais Informações para obter ajuda". Parece que, até mesmo no material de marketing, os fornecedores não conseguem produzir caixas de diálogo informativas.
Como os usuários não têm informações o suficiente para tomar as decisões de segurança certas, caberia ao administrador configurar toda a filtragem de saída porque o usuário final é incapaz disso. Isso aumenta infinitamente a carga do administrador.
Mesmo que o usuário clique em "Não. Lembre-me mais tarde" quando perguntado pelo firewall, o malware poderia invadir normalmente o firewall. Desde que o usuário que está executando o código mal-intencionado consiga abrir conexões de saída em alguma porta, o código pode simplesmente usar essa porta. Por isso, qualquer processo pode acumular em um processo existente. Isso é permitido em sistemas operacionais de nível inferior. A partir do Windows Vista, os processos podem ser tranqüilamente restringidos, e é por isso que os serviços, aqueles restritos por padrão, são bloqueados usando os filtros de saída por padrão.
Infelizmente, a maioria das pessoas acha que a filtragem de firewall baseado em host de saída impedirá que um ativo comprometido ataque os demais. Isso não é possível. Implantar medidas protetoras em um ativo comprometido e pedir para que ele não comprometa nenhum outro simplesmente não funciona. A proteção pertence ao ativo que você está tentando proteger, e não do que você tentando se proteger! É improvável que pedir para que os maus elementos não roubem nada depois que eles já entraram na sua causa seja algo eficiente quanto impedir que eles invadam a casa antes.

Jesper M. Johansson é arquiteto de software e trabalha na segurança de software, além de ser editor colaborador da TechNet Magazine. Ele possui PhD em sistemas de informações sobre gerenciamento, tem mais de 20 anos de experiência em segurança e é MVP Microsoft em segurança corporativa. Seu livro mais recente é Windows Server 2008 Security Resource Kit.


Segurança
Email seguro usando certificados digitais
Matt Clapham and Blake Hutchinson
À primeira vista:
  • Criando uma identidade verificável
  • Atualizando o status do certificado
  • Obtendo e trocando os certificados
  • Solucionando problemas do sistema S/MIME

Por milênios, os humanos usaram vários métodos para ocultar informações em trânsito, validar o remetente e autenticar a mensagem. Conforme a civilização foi evoluindo, foi desenvolvido um método para realizar todas as três tarefas e que está sendo cada vez mais usado. S/MIME (Secure Multi-Purpose Internet Mail)
As extensões S/MIME formam um sistema para enviar email de maneira segura usando criptografia e assinaturas digitais.
As tecnologias de criptografia (ocultar) atuais são de dois tipos principais: algoritmos de chave simétrica (secreta) como, por exemplo, DES (padrão de criptografia de dados) ou AES (Advanced Encryption Standard) e algoritmos de chave assimétrica (pública/privada) como RSA ou ECC (Elliptical Curve Cryptography). As ferramentas modernas para validação do remetente são funções unidirecionais matemáticas chamadas hashes que criam assinaturas exclusivas. Os dois métodos de hash mais usados são MD5 (algoritmo Message Digest 5) e SHA (Secure Hash Algorithm). Os computadores podem usá-los para gerar um hash exclusivo ou número correspondente ao texto de origem individual (o hash de textos de origem idênticos tem o mesmo valor). Essas ferramentas simples são aproveitadas e combinadas para criar um sistema PKI (infra-estrutura de chave pública).

Uma identidade verificável
Recursos de autoridade de certificação
  • Usando uma autoridade de certificação no serviço de arquivos com criptografia
  • Não é possível renomear ou remover servidores de autoridade de certificação da rede
  • Como remover uma autoridade de certificação confiável dos computadores no domínio
  • Como descomissionar uma autoridade de certificação corporativa do Windows e remover todos os objetos relacionados do Windows Server 2003 e do Windows 2000 Server
  • Como mover uma autoridade de certificação para um novo servidor em execução em um controlador de domínio

As identidades dentro de um sistema PKI são gerenciadas usando-se certificados digitais, que não são diferentes da identificação federal que a maioria das pessoas carrega em viagens internacionais: o passaporte. O padrão passaporte no mundo do certificado digital é o formato X.509, sendo amplamente usado tanto na assinatura quanto na criptografia em tecnologias como, por exemplo, S/MIME, protocolo IPsec (Internet Protocol Security), SSH (Secure Shell), segurança de rede sem fio, VPNs (redes virtuais privadas) e até mesmo comunicações com servidor seguro (como sites SSL).
Os certificados se baseiam na criptografia assimétrica e nos hashes. Para criar um certificado, o solicitante (a entidade que deseja uma chave assinada por alguma autoridade superior) gera uma chave privada. A chave é mantida bloqueada para que sua autenticidade jamais seja desafiada. Com a chave privada, uma chave pública correspondente também é gerada. Como o próprio nome diz, a parte pública do par não é segredo, sendo distribuída livremente, ainda que, de alguma forma, garanta sua autenticidade.
Esse par de chaves permite duas operações fundamentais. Primeiro, qualquer um pode usar a chave pública para criptografar algo que só a chave privada pode descriptografar e, segundo, a chave pública pode ser usada para descriptografar algo criptografado com a chave privada. Isso é importante para verificar uma assinatura que somente uma chave privada pode ter criado.
A solicitação feita à autoridade de certificação inclui detalhes como, por exemplo, a identidade da pessoa ou do computador ao qual se destina a chave, a força e o tipo de algoritmo, além da parte pública do par de chaves. A CA (autoridade de certificação) recebe e valida as informações da solicitação e, usando um algoritmo de hash, cria um identificador exclusivo correspondente às informações.
Usando sua chave privada, a CA criptografa o hash das informações e as monta em um formato padrão (como, por exemplo, X.509), criando um certificado correspondente à solicitação original. O certificado X.509 conterá uma lista das declarações, inclusive a identidade do certificado (o assunto), um período de validade, a chave pública e as operações nas quais o certificado pode ser usado. Em seguida, o certificado retorna ao solicitante; trata-se de um token que afirma: "eu, a CA, concedo esta chave pública e sua parte privada correspondente, tendo em vista todos os usos aqui descritos".
Em CAs raiz (aquelas no nível mais alto da cadeia de confiança), os certificados são assinados automaticamente. A maioria das CAs raiz aceitáveis vem pré-instalada no sistema operacional base ou aplicativo, embora possa ser atualizada ou alterada por meio de pacotes ou da configuração corporativa. Entre a CA raiz e um nó folha (que normalmente descreve um indivíduo ou sistema), talvez haja uma ou mais CAs intermediárias.
A cadeia consiste em todos os nós e todos os certificados anteriores embutidos, assinados pela CA exatamente nesse nível. Um terceiro que esteja tentando validar o certificado pode verificar o hash calculado localmente e compará-lo com um descriptografado pelo certificado usando a chave pública correspondente a essa CA específica ou individual. É isso – uma cadeia de confiança totalmente validada, da folha à raiz – pressupondo, obviamente, que a raiz seja confiável.

Atualizando o status do certificado
Toda boa CA conta com meios para distribuir uma lista de certificados que devem deixar de ser confiáveis. Essa CRL (lista de certificados revogados) descreve quais itens emitidos foram especificamente negados pela CA. Como medida prática, o local da CRL costuma ser uma propriedade do certificado da CA.
As CAs quase sempre emitem CRLs baseadas em duas coisas: um cronograma (talvez a cada duas semanas) ou um evento (alguma ocorrência que indique que um certificado emitido deixou de ser confiável). Uma CA assinará as CRLs emitidas quando as publicar. Ao avaliar a validade de uma cadeia, um sistema de recepção normalmente tenta adquirir a CRL de cada CA emissora da cadeia (por meio dos detalhes embutidos nos próprios certificados ou de algum mecanismo de distribuição confiável predefinido). Caso alguma CRL não esteja disponível, o cliente pode retornar a uma cópia recente, armazenada com êxito em cache, desde que ela não seja anterior ao período de atualização da CRL especificada. No entanto, em caso de falha, os sistemas do cliente normalmente mostrarão algum tipo de erro indicando que o certificado aparenta ser válido, mas que o status de revogação não pode ser determinado.
Muitos aplicativos demoram significativamente mais para carregar um certificado caso não possam validar a cadeia ou a CRL de todos os nós da cadeia. Dependendo do que o certificado estava protegendo, o usuário pode ou não confiar nele. Um ponto de distribuição da CRL sempre atualizado e amplamente disponível é absolutamente necessário para todas as CAs, especialmente para as raízes públicas.
As raízes constituem a base da cadeia de certificados e a cadeia, a base de todas as hierarquias de certificados. Grande parte dos sistemas ou dos aplicativos só irá pressupor a validade de um certificado de nó folha se este estiver encadeado em uma raiz confiável. Ela pode ser uma CA corporativa, de propriedade e operada por uma empresa particular, ou uma CA raiz pública (como, por exemplo, a VeriSign).
No caso das CAs raiz públicas, existe a expectativa de uma experiência profissional significativa, logo, essa integridade é garantida. As empresas devem buscar o mesmo nível para suas operações internas, porque a segurança de uma CA raiz nesse contexto é tão importante quanto. Tendo em vista a proteção ideal, as CAs raiz devem, na verdade, ser mantidas offline e só serem usadas para emitir certificados e atualizar CRLs. Para obter mais informações sobre as práticas recomendadas sobre a CA operacional, consulte os artigos listados na barra lateral "Recursos de autoridade de certificação".
Um aspecto importante a ser considerado é a recuperação da chave. Para facilitar as investigações e garantir que os dados não sejam bloqueados por um usuário de modo que não possam ser recuperados, a empresa deve fazer cópias de backup de todas as chaves emitidas pelo usuário. Além disso, essas cópias de backup devem ser armazenadas em um repositório seguro. Dessa forma, caso a chave de um usuário desapareça, por exemplo, quando um cartão inteligente é esquecido em um táxi, todo conteúdo protegido pela chave continua sendo acessível.
Por fim, em todo bom sistema criptográfico está o conceito de gerenciamento do ciclo de vida. À medida que os computadores se tornam mais rápidos, os algoritmos ficam mais fracos. Todo bom sistema criptográfico precisa ter a capacidade de se renovar e recorrer a novos algoritmos e tamanhos de chave com o passar do tempo. As CAs deverão ser atualizadas corretamente quando forem identificadas deficiências criptográficas e determinadas funções forem introduzidas ou suprimidas.

Implementando S/MIME
Há vários estágios para inicializar, redigir, enviar e receber emails assinados ou criptografados usando S/MIME. Abordaremos os detalhes, os problemas e as soluções potenciais à medida que avançarmos em um cenário de S/MIME típico: dois usuários enviando emails assinados e/ou criptografados um para o outro em duas florestas do Active Directory® e cadeias de autoridade de certificação diferentes (ou seja, em duas entidades separadas em termos operacionais, independentemente de ser na mesma empresa ou não) usando o Microsoft® Office Outlook® 2007.
Iremos pressupor que a infra-estrutura necessária já esteja in-loco para habilitar as operações que descreveremos. Em nosso caso, estamos usando um servidor de certificados corporativo integrado ao Active Directory.

Obtendo certificados
A primeira tarefa é obter os certificados apropriados. Para isso, abra o MMC Gerenciador de Certificados (certmgr.msc), clique com o botão direito do mouse na pasta Pessoal, selecione Todas as Tarefas na lista pop-up e Solicitar Novo na lista.
Isso inicia o assistente Registro de Certificado, como mostrado na Figura 1. Por padrão, várias opções centradas na empresa serão mostradas, mas o certificado Usuário é a mais importante. Ele será usado para habilitar os processos de assinatura e criptografia posteriormente. O certificado deve ser usado em:
Figura 1 Solicitando um certificado
Figura 1 Solicitando um certificado (Clique na imagem para uma visão ampliada)
  • Assinaturas digitais (criando uma mensagem com um selo de autenticidade do criador)
  • Codificação de chave (protegendo uma chave com outra em tecnologias como, por exemplo, o Encrypting File System)
  • Email seguro (sistema de mensagens criptografadas que só podem ser lidas pelo destinatário desejado de posse da chave privada correspondente)
Para enviar emails assinados S/MIME, a propriedade de codificação de chave não é obrigatória. No entanto, para enviar ou receber emails criptografados, essa propriedade é obrigatória, ainda que a propriedade da assinatura não seja. Por padrão, os modelos dos Serviços de Certificados do Windows® habilitam essas três propriedades. Se o usuário não tiver permissão para solicitar novos certificados, nenhum será mostrado quando o assistente for iniciado. Se nenhuma CA corporativa estiver disponível, o usuário receberá um "Erro no registro" indicando que não foi possível entrar em contato com o domínio ou a CA. Neste passo a passo, iremos pressupor um único certificado permitindo tanto a assinatura quanto a codificação.

Trocando certificados
A forma mais fácil para que dois usuários comecem a enviar emails criptografados é simplesmente enviando mensagens assinadas um para o outro. Depois de redigir uma mensagem, o usuário clica no botão Assinar. (Às vezes, o botão permanece oculto por padrão no Outlook até ser usado pelo menos uma vez. Ele pode ser encontrado clicando-se na configuração Opções para novas mensagens, no botão "Configurações de Segurança..." e, em seguida, marcando a caixa "Adicionar assinatura digital a esta mensagem" na caixa de diálogo Propriedades de Segurança.) O botão de assinatura (um pequeno envelope amarelo com uma faixa de opções vermelha com os dizeres Assinar) adiciona uma assinatura digital à mensagem para estabelecer a autenticidade de sua origem.
Ao pressionar o botão Enviar, o usuário pode ser solicitado a fornecer tokens adicionais de posse da chave como, por exemplo, inserir um cartão inteligente ou digitar um PIN. Isso depende dos métodos particulares de proteção da chave in-loco na organização.
O usuário que recebe a mensagem assinada com S/MIME precisará exibir e clicar com o botão direito no nome do remetente (depois do De:) e selecionar "Adicionar a Contatos do Outlook" no menu de contexto, que adiciona uma nova entrada de contato ou atualiza uma existente. Dessa forma, o certificado é associado a essa entrada de contato em especial. Observe que, em um mesmo ambiente do Active Directory (dois usuários na mesma floresta ou empresa), a distribuição do certificado de usuário público é feita automaticamente por meio dos atributos no objeto do Active Directory do usuário).
Outra forma de trocar certificados é cada usuário enviando seu(s) certificado(s) S/MIME como um anexo. Para isso, ambas as partes precisarão exportar seu(s) certificado(s) para um arquivo CER. Os usuários precisarão exibir o certificado e seguir o processo de exportação que abordaremos daqui a pouco, tomando o cuidado de não exportar a chave privada junto, como mostrado na Figura 2.
Figura 2 Ao trocar certificados, não exporte a chave privada
Figura 2 Ao trocar certificados, não exporte a chave privada (Clique na imagem para uma visão ampliada)
Em seguida, cada destinatário cria manualmente uma entrada de contato no Outlook e adiciona o certificado à entrada do destinatário. Depois de trocar os certificados, os dois usuários poderão trocar emails criptografados.

Solução de problemas
Às vezes, o destinatário tem dificuldade para abrir a mensagem criptografada. As três causas mais prováveis dos problemas que vimos em relação a isso são CAs raiz não confiáveis, CAs intermediárias que não podem ser validadas e CRLs não disponíveis.
Uma CA raiz não confiável costuma ser mostrada no Outlook como uma mensagem de erro associada à assinatura: "Há problemas com a assinatura. Clique no botão de assinatura para obter detalhes." Para resolver o problema, abra o certificado no Outlook e clique no botão "Exibir a Autoridade de Certificação" da caixa de diálogo pop-up. Observe a mensagem na guia Geral da caixa de diálogo das propriedades do certificado. Caso ela indique que o certificado da CA raiz não é confiável e que precisa ser instalado, vá até a guia Detalhes. Clique no botão "Copiar para Arquivo..." e siga o assistente, aceitando todos os padrões e fornecendo um nome de arquivo e pasta quando solicitado.
Agora abra um novo MMC (Console de Gerenciamento Microsoft) como administrador de máquina. Vá até Arquivo|Adicionar/Remover Snap-in (Ctrl+M), selecione Certificados e o adicione à conta do computador, escolhendo o computador Local quando solicitado. Em seguida, expanda o nó Certificados na árvore à esquerda e faça o mesmo com as Autoridades de Certificação de Raiz Confiáveis. Clique com o botão direito do mouse e selecione Todas as Tarefas|Importar no menu pop-up. Importe o arquivo de certificado exportado e mencionado anteriormente para Autoridades de Certificação de Raiz Confiáveis e clique em Concluir. Em seguida, peça que o usuário afetado reinicie o Outlook.
Essas instruções só devem ser usadas para adicionar uma CA raiz reconhecidamente confiável. Nem todas as raízes são criadas da mesma maneira. Considere atentamente quem é o proprietário e quem opera a CA raiz, antes de usar esse método para adicionar uma raiz ao repositório usando em todo o sistema. Se a empresa controlar a lista de raízes confiáveis por meio da Diretiva de Grupo, a configuração será levada até os sistemas do cliente. Nesse caso, as instruções podem não funcionar. Caso elas não funcionem, você talvez precise explorar alternativas como, por exemplo, sites seguros ou servidores para trocar os dados, uma vez que o email não será uma experiência direta e protegida.
O segundo problema observado acima, CAs intermediárias que não podem ser validadas, normalmente ocorre em duas situações: um cliente que está tentando validar o certificado não consegue chegar ao local AIA (Acesso a Informações da Autoridade) definido no certificado, ou o cliente tem uma versão do certificado da CA intermediária que não corresponde ao que a CA está emitindo (o cliente normalmente está uma ou duas versões atrasado). Essas condições aparentam ser muito semelhantes dentro da interface do usuário do Outlook. Só vimos isso em uma circunstância muito específica quando uma CA de nível intermediário na cadeia expirou e foi reemitida antes que outros certificados subordinados emitidos expirassem.
Basicamente, esse problema ocorre quando a cadeia apresenta lacunas. Alguns certificados pai talvez não estejam tão bem detalhados ou estejam corretamente embutidos no nó folha, o que complica ainda mais a situação.
Para resolver esse problema, o remetente precisará abrir uma nova mensagem e clicar em Opções da nova mensagem, no botão Configurações de Segurança e no botão Alterar Configurações. Agora clique no botão Escolher quanto ao certificado de assinatura e no botão Exibir Certificado na caixa de diálogo do menu pop-up. Vá até a guia Caminho do Certificado, selecione o emissor do nó folha (ou seja, um nível acima na cadeia) e clique no botão Exibir Certificado. Clique na guia Detalhes e no botão Copiar para Arquivo... e, em seguida, conclua o assistente de exportação, selecionando PKCS #7 (.P7B). Verifique se a opção "Incluir todos os certificados no caminho de certificação" está marcada, como mostrado na Figura 3. Por fim, envie o arquivo da cadeia exportado para o destinatário desejado.
Figura 3 Preenchendo as lacunas de uma cadeia de certificados
Figura 3 Preenchendo as lacunas de uma cadeia de certificados (Clique na imagem para uma visão ampliada)
Depois de obter a cadeia do certificado exportada, o destinatário precisará abrir e importá-la praticamente da mesma forma que importamos uma raiz anteriormente. A única diferença é que a pasta de armazenamento escolhida deve ser Autoridades de Certificação Intermediárias. Caso a mensagem seja aberta e o certificado, mostrado como válido no Outlook, é sinal de que as coisas estão funcionando corretamente.
Quanto ao terceiro problema, o das CRLs não estarem disponíveis, a correção é comparativamente simples. A resposta inicial do Outlook será bem semelhante à do problema anterior. Porém, o erro mostrará até mesmo se a CA de assinatura raiz ou intermediária é confiável. Para cada nível da cadeia de certificados acima da folha, abra as propriedades do certificado e, em seguida, a guia dos detalhes e observe um campo chamado "Pontos de Distribuição da Lista de Certificados Revogados".
Para cada ponto de distribuição da CRL listado (especialmente os acessíveis na Internet), verifique se a URL do arquivo da CRL pode ser aberta. Na medida em que cada nível for validado, suba um nível na cadeia. Caso nenhuma CRL possa ser adquirida, é provável que ela seja a origem do problema. Para resolvê-lo, você deve verificar se a diretiva de rede local não está bloqueando o seu acesso. Do contrário, tente entrar em contato com a empresa proprietária da CA ou aguarde o retorno do status operacional do ponto de distribuição da CRL da CA.

Distribuindo certificados
A distribuição é a parte mais fácil. Basicamente, a mensagem assinada é transmitida para um servidor de email, que acaba enviando-a de um local para outro usando um método de tentativa e acerto, SMTP. O único problema que vimos no email assinado ou criptografado em trânsito é que alguns sistemas de email rejeitam ou quebram mensagens assinadas ou criptografadas que passam por eles. A saída é trabalhar com o gerente de TI do sistema para que os tipos de mensagem sejam permitidos. Obviamente, você talvez tenha de conviver com o fato de alguns tipos de mensagem serem bloqueados. A parte destinatária pode ter uma boa razão para não permitir mensagens criptografadas em um determinado ambiente operacional.

Criptografando respostas
Para criar uma resposta criptografada (pressupondo que o processo de inicialização acima já tenha sido concluído), o remetente só precisa criar uma mensagem e, em seguida, clicar no botão Criptografar (o pequeno envelope amarelo com um cadeado azul com os dizeres Criptografar) na janela de redação da mensagem. Caso o botão não esteja disponível, execute as etapas para enviar uma mensagem assinada, exceto a última, e marque a caixa de seleção "Criptografar conteúdo da mensagem e anexos".
A assinatura S/MIME não é obrigatória para enviar uma mensagem criptografa a um destinatário, mas ambas se saem muito bem juntas, porque a assinatura permite ao leitor validar o remetente (a função de criptografia não faz nenhuma declaração quanto ao remetente). O processo de criptografia tentará criptografar a mensagem com as chaves públicas conhecidas de todos os destinatários. Se o sistema não conseguir encontrar os certificados de alguns destinatários desejados, estes serão sinalizados em uma caixa de diálogo pop-up que se oferece para enviar a mensagem descriptografada, como mostrado na Figura 4.
Figura 4 É possível optar por enviar uma mensagem descriptografada caso você tenha um problema com um certificado
Figura 4 É possível optar por enviar uma mensagem descriptografada caso você tenha um problema com um certificado (Clique na imagem para uma visão ampliada)
Por padrão, assinar e criptografar devem funcionar com os demais sistemas do cliente de configuração semelhante, mas o sistema de mensagens criptografadas ou assinadas em várias versões pode, às vezes, apresentar problemas caso não haja suporte para o nível inferior do algoritmo de hash ou de criptografia. Tivemos um problema assim ao enviar um email assinado (usando SHA-512 como algoritmo de hash) para um usuário com o Windows XP SP2 em execução. Como o sistema de recebimento não dava suporte ao hash, o usuário não conseguiu validar a assinatura nem ler a mensagem. No entanto, é improvável que os usuários tenham tantos problemas a essa altura, a menos que os padrões do Outlook tenham sido alterados.
Após receber a mensagem, o destinatário desejado deve ser capaz de abri-la, dada a disponibilidade da chave privada com o certificado público. Mais uma vez, o usuário talvez precise fornecer um token adicional a fim de provar a posse da chave privada, dependendo da forma com que ela foi implantada. Outros usuários que completaram um processo de inicialização semelhante podem participar da comunicação assinada e criptografada com o remetente. Se alterar sua chave privada em algum momento (talvez por conta da perda de um computador), um usuário precisará solicitar novamente os certificados e redistribuir uma mensagem assinada ou um arquivo certificado para as demais pessoas que queiram trocar emails criptografados.

Conclusão
Fazer com que as extensões S/MIME assinadas e criptografadas funcionem entre dois usuários em dois diretórios ou organizações diferentes não costuma ser muito mais complicado que o abordado aqui. A assinatura é muito prática, quando usada corretamente, por dar autenticidade à mensagem. Tendo em vista detalhes confidenciais, as mensagens criptografadas dão um nível a mais de segurança para os dados em trânsito. Juntas, as duas possibilitam a autenticidade da origem e a segurança dos dados. E com o processo que descrevemos aqui, não será um desafio para a maioria dos usuários usufruir esses recursos.

Matt Clapham, CISSP, é engenheiro de segurança de TI da Microsoft. Ele realiza revisões de segurança em aplicativos LOB durante o dia e brinca com tecnologia, jogos, música eletrônica ou segurança à noite. Ele ocasionalmente faz apresentações para a comunidade de segurança Puget Sound IT. Entre em contato com ele pelo email matt.clapham@microsoft.com.
Blake Hutchinson é analista de suporte do BOSG (Business Online Services Group) na Microsoft. A função que ele ocupa inclui o suporte operacional e a revisão do projeto de ferramentas LOB criadas internamente para os clientes corporativos do BOSG. Blake gosta de fotografia, esqui e jogos de computador. Entre em contato com ele pelo email blakeh@microsoft.com.


Do editor O grande debate
Joshua Hoffman

Adoro um grande debate. Não estou falando de uma discussão qualquer, em que diferentes opiniões e fortes personalidades causam conflitos insanos. Isso é perda de tempo. Estou falando de um verdadeiro debate, em que pessoas inteligentes com pontos de vista contrastantes se reúnem para expor apaixonadamente seus argumentos para reflexão. É maravilhoso. Pense no iluminismo. Pense em Sócrates.
Este mês, apresento um dos grandes debates do mercado de TI: segurança pelo disfarce. Poderia explicar o conceito aqui, mas imagino que, depois que ler essas três palavras, a maioria dos leitores já formou uma opinião a respeito do assunto e, provavelmente, bem forte. Também aposto que quase todos assumiriam uma destas duas posturas: "segurança pelo disfarce é totalmente inútil" ou "quando se trata de segurança, qualquer coisa ajuda".
Bem, este mês reunimos os renomados especialistas em segurança Jesper Johansson e Roger Grimes para apresentar os dois lados desse debate. Também incluímos comentários de apoio especiais de cada lado com dois outros eruditos, Aaron Margosis e Steve Riley. Embora, sem dúvida, tenha orgulho de cada página que publicamos, devo admitir que este é um de meus artigos favoritos nos últimos tempos. Espero que, independentemente do lado que você escolher nesta calorosa discussão, você leia o texto com a mente aberta. Tenho certeza de que irá gostar.
Como esta é a nossa edição de segurança anual, certamente, tem muito mais. Revisamos alguns tópicos que abordamos na edição do ano passado. Um dos artigos de maior sucesso no ano passado tratava de um conjunto de PowerToys de elevação de script do editor colaborador Michael Murgolo, que ajuda a executar scripts do VBScript ou do Windows PowerShell em um contexto elevado com o recurso Controle de Conta de Usuário do Windows Vista. Michael recebeu várias opiniões favoráveis com esse artigo, por isso voltou este ano com um novo conjunto de utilitários para estender seu código original. Recomendo que você experiente essas ferramentas superpoderosas.
Byron Hynes também esteve conosco ano passado, com uma introdução à Criptografia de Unidade de Disco BitLocker no Windows Vista. Byron repete a cena examinando o que mudou no BitLocker com o lançamento do Windows Vista SP1 e Windows Server 2008. Além disso, temos artigos sobre diretivas de restrição de software, gerenciamento do Firewall do Windows Vista, solução de problemas S/MIME, a segunda edição da nossa nova coluna Inside SharePoint, idéias de negócios para promover uma computação sustentável... e a lista não pára. Aproveite! – Joshua Hoffman

Meus agradecimentos aos seguintes especialistas técnicos da Microsoft: Troy Funk, Aaron Margosis, Michael Murgolo, Steve Peschka, Steve Riley, Mark Russinovich, Jon Schwartz e Jim Truher.


Cartas A palavra está com os leitores

Backups do Windows
Fiquei tão animado com sua matéria sobre o Windows Server® 2008 (TechNet Magazine, março de 2008, technet.microsoft.com/magazine/cc268370) que fui ao evento de lançamento e comprei uma cópia para minha rede doméstica. Tudo transcorreu normalmente na instalação. No entanto, fiquei espantado com os backups.
O NT Backup foi removido, e o novo Windows Server Backup não oferece suporte a unidades de fita, embora o SO ofereça. (Faço backup de meus dados pessoais, inclusive do Active Directory® e do Exchange Server 2007, em uma unidade de fita.)
Tentei baixar o Microsoft® Data Protection Manager (DPM) seguindo as dicas na Web, embora o DPM possa ser um exagero para minha instalação. Contudo, o DPM não instalou no Windows Server 2008, e não tive muita sorte nas instruções de instalação manual. Que benefício as pequenas instalações podem trazer aos backups?
—Ravi S.

O DPM realmente é a solução para backups em fita, pois a nova solução no Windows Server 2008 é otimizada para armazenamento baseado em disco. O DPM oferecerá suporte oficialmente ao Windows Server 2008 nos próximos dois meses.
—Karandeep Anand, gerente geral sênior de programa da Microsoft

Fluxos de trabalho de pesquisa
No artigo de fevereiro de 2008 "Criação de uma infra-estrutura de pesquisa avançada" (technet.microsoft.com/magazine/cc194407), a seguinte afirmação está na seção Como trabalhar somente com o WSS: "Você também tem a opção de atribuir um fluxo de trabalho à pesquisa."
Pelo que sei, o Windows® SharePoint® Services 3.0 (WSS) e o Microsoft Office SharePoint Server 2007 (MOSS) não oferecem suporte a fluxos de trabalho associados a respostas de pesquisa. Tentei associar um fluxo de trabalho a uma resposta de pesquisa e, embora o SharePoint Designer permita a associação, o fluxo de trabalho sempre emite um erro Falha ao iniciar. Há um artigo da Base de Dados de Conhecimento (support.microsoft.com/kb/926370) que afirma claramente que não há suporte aos fluxos de trabalho associados a respostas de pesquisa.
Sei que é possível vincular um receptor de eventos a uma pesquisa e iniciar outro processo, mas na verdade não se trata de um fluxo de trabalho como é normalmente mencionado no SharePoint. Aquela afirmação estava errada ou fui eu que não entendi direito?
—Matt B.

O parágrafo mencionado fala sobre como o WSS fornece um assistente para um processo passo a passo de criação de pesquisas. Também há uma discussão sobre as diversas opções (lógica de ramificação, questões abertas/fechadas etc.).
Uma das opções que o assistente realmente fornece é atribuir um fluxo de trabalho; portanto, de certa forma, não é totalmente incorreto dizer: "você tem a opção de atribuir um fluxo de trabalho a uma pesquisa". Foi possível atribuí-la. Entretanto, como você ressalta, os fluxos de trabalho em pesquisas não funcionam, embora, por algum motivo, essa opção seja incluída. Deixe-me explicar por que isso acontece.
Depois de associar um fluxo de trabalho a uma pesquisa e tentar iniciá-la, você recebe o erro Falha ao iniciar. Os logs dessa atividade mostram o seguinte:
RunWorkflow: System.ArgumentException: Invalid field name.
{<<< GUID>>>} at ...
Esse GUID representa a instância do fluxo de trabalho. Aparentemente, é uma excelente forma de se certificar de que o fluxo de trabalho seja disparado, a menos que o tipo de lista da "pesquisa" não ofereça suporte ao atributo de fluxo de trabalho. Simplesmente, não está no código. Por isso, quando o fluxo de trabalho tenta ativar com o método MakeActivation e faz algo do tipo:
internal static void MakeActivation(SPWorkflow workflow, SPWorkflowEvent e)
{e.EventData = new object[ ] { workflow.InstanceId, new SPWorkflowActivation
Properties(workflow, e.RunAsUserId, associationData, initiationData) };
...
}
ele chama SPWorkflowActivationProperties, que se parece com o seguinte:
internal SPWorkflowActivationProperties(SPWorkflow workflow,
int runAsUserId, string associationData, string initiationData)
{
...
this.m_itemGuid = new Guid((string)
this.Item[SPBuiltInFieldId.GUID]);
...
}
Portanto, já que ele espera a cadeia de caracteres do GUID como um atributo na pesquisa (que, ao que parece, deveria ser interno) e a pesquisa não tem o atributo para o GUID de fluxo de trabalho, isso nunca funciona.
Talvez haja uma solução, então, você acertou quando pensou nisso. A solução se resume à criação de uma lista personalizada que dispara um fluxo de trabalho e à vinculação de um receptor de eventos para a pesquisa com ItemEventReceiver. Esse receptor de eventos cria um item na lista personalizada, que dispara um fluxo de trabalho. Mas você está certo; na verdade, não é a mesma coisa. Para encurtar a história, sim, foi uma grande sacada da sua parte, mas na prática não funciona.
—Pav Cherny, colunista, Explorando o SharePoint, TechNet Magazine


Caixa de ferramentas Novos produtos para profissionais de TI
Greg Steen

Faça comunicados usando a rede
NetSupport Notify
www.netsupportnotify.com
O ambiente de trabalho baseado no PC é praticamente onipresente no espaço de trabalho corporativo. A maioria dos usuários permanece diante das telas durante o dia estando conectada a uma rede que você ajuda a gerenciar. Além de fornecer um transporte para recursos compartilhados, aplicativos e a Internet, a rede da empresa também pode ser usada como parte da estratégia da organização a fim de comunicar mensagens importantes aos usuários. Uma ferramenta que pode ajudar a entregar mensagens para usuários em toda a LAN e WAN (rede de longa distância) é o NetSupport Notify, da NetSupport Limited.
Esse servidor de aplicativos leve dá suporte a um sistema de mensagens de difusão rápido e confiável. Você poderia, por exemplo, alertar facilmente os usuários a respeito de uma perda de serviço inesperada para um recurso compartilhado, informar as pessoas de que o alarme de segurança que estão ouvindo foi ativado por acidente ou notificar os funcionários sobre uma emergência no prédio.
Algumas ferramentas de sistema de mensagens de difusão simples com as quais você talvez já tenha se deparado estão limitadas à LAN em que estão instaladas. No entanto, o NetSupport Notify se baseia em agente e, com seu componente de gateway para notificação, pode facilmente atravessar a topologia de rede, alcançando clientes do Windows® e do Mac, independentemente de estarem conectados diretamente, usando uma conexão sem fio ou conectados por uma rede virtual privada.
O serviço de notificação é executado como um serviço do Windows, e você se conecta a ele por meio do console de notificação administrativo, que pode ser instalado na mesma máquina ou em uma diferente. As notificações do serviço são classificadas em um destes três níveis de severidade: mensagem, alerta ou crítico. Assim que uma mensagem é recebida pelo cliente, é criada uma entrada no log de eventos e o servidor é notificado de que a mensagem foi recebida. Entre as demais opções de mensagem estão executar um alarme sonoro, além de mostrar a janela, forçar a visibilidade permanente da notificação e definir um tempo limite automático para que a mensagem se feche.
Também é possível optar por se dirigir exclusivamente a grupos de notificação específicos. O console de notificação pode se conectar a vários servidores de notificação, logo, um console pode ser o centro da difusão da mensagem.
Além do servidor e do console, o NetSupport Notify também inclui uma ferramenta de implantação que permite implantar remotamente o agente nos usuários finais, o que economiza uma visita até o desktop. É possível especificar máquinas de destino de acordo com um intervalo de endereços IP ou por meio da descoberta de domínios de rede e de grupos de trabalho do Windows.
O console de implantação também oferece uma exibição rápida da rede, mostrando a versão do agente instalado e os sinais vitais como, por exemplo, o nome DNS, o endereço MAC, o endereço IP, a plataforma e se o console tem acesso à máquina remota. Caso você use o Active Directory®, é possível gerenciar a configuração e a implantação por meio da diretiva de grupo.
Para se proteger contra difusões não autorizadas (como, por exemplo, "Psiu, tem festa no escritório às 16h!"), os agentes e os consoles empregam um código de segurança semelhante a uma cadeia de caracteres-chave da WMI (Windows Management Instrumentation). Além disso, é possível controlar a possibilidade de enviar alertas usando a diretiva do Active Directory.
Preço: a partir de US$ 180,00 para uma licença de 75 usuários.
Entregue comunicados para os funcionários usando o NetSupport Notify
Entregue comunicados para os funcionários usando o NetSupport Notify (Clique na imagem para uma visão ampliada)

Monitore a sua rede
NetOptics: Teeny Tap
www.netoptics.com
Usados com um bom aplicativo de monitoramento, os taps de rede passivos podem ser uma ferramenta vital na solução de problemas de redes falhas, corrigindo aplicativos que estejam se comportando mal e atenuando ameaças potenciais à sua infra-estrutura. Um tap interessante que me foi apresentado para redes 10/100 é o incrivelmente portátil Teeny Tap da NetOptics.
Esse dispositivo, bem, "fino", de 7,94 por 3,81 centímetros, fornece monitoramento de tráfego full duplex da camada 1 em diante, o que permite identificar facilmente ou monitorar continuamente a rede 10/100. O dispositivo consegue o monitoramento full duplex com suas duas portas RJ45, que proporcionam uma exibição aprofundada do tráfego que flui em ambos os lados das duas portas de rede quando estas estão conectadas ao monitor de rede, ao analista de protocolo, ao IDS/IPS ou a outra investigação.
O Teeny Tap não exige um endereço IP. Isolando-se da rede, você pode permanecer invisível àqueles que podem usar a sua presença como uma indicação para interromperem as brincadeiras na rede. Enquanto isso, o recurso Zero Delay garante que uma perda de energia no tap não afete o fluxo de tráfego que passa por ele – não deve haver atraso ou perda de pacotes.
O tap pode ser alimentado por USB ou com a fonte de alimentação incluída. Também é possível usar ambos tendo em vista a redundância, que se trata de uma funcionalidade notável para um dispositivo tão pequeno. O Teeny Tap também é compatível com a alimentação em serviços baseados na Ethernet como, por exemplo, câmeras de rede e telefones IP. Dessa forma, também seria possível monitorar o tráfego lá para garantir a segurança da comunicação.
O kit do Teeny Tap inclui o tap, uma fonte de alimentação universal, dois cabos cruzados e dois cabos RJ45 retos, além de uma caixa de transporte. Caso precise de mais potência no ambiente, você pode conferir alguns dos demais produtos para tap de rede oferecidos pela NetOptics. A linha de produtos abrange toda a gama, desde redes de pequenas empresas até grandes ambientes corporativos, com redes de cobre e de fibra, de 10 MB a 10 GB.
Preço:US$ 325,00 (para venda direta).
Monitore a sua rede com Teeny Tap
Monitore a sua rede com Teeny Tap (Clique na imagem para uma visão ampliada)

Otimize o seu computador
DTweak Pro
www.daoisoft.com
Como profissional de TI (e aficionado por tecnologia em geral), é claro que você tem o desejo de ajustar o seu sistema e conseguir o máximo em termos de desempenho e experiência personalizada, tendo em vista as suas atividades diárias. Há muitas ferramentas por aí que podem ajudá-lo a otimizar e a personalizar a experiência do usuário no computador com o Windows Vista® em execução. Uma opção de baixo custo é o DTweak Pro da Daoisoft. (Há uma nova versão disponível também para o Windows® XP e o Windows Server® 2003.)
O aplicativo oferece vários modos de exibição de acesso rápido a ferramentas e personalizações diferentes para o Windows Vista. Por exemplo, na seção Daily Tools, é possível executar uma limpeza de Registro, um utilitário de limpeza de arquivo, ferramentas de desfragmentação de Registro e disco, além de um monitor de desempenho do disco rígido.
Com o DTweak, também é possível ver e personalizar facilmente os itens de inicialização, obter informações de CPU (inclusive a identificação, a velocidade do barramento e a velocidade de clock da CPU) e obter informações do computador como, por exemplo, o fornecedor, o estado de inicialização, a configuração da memória e o tipo de sistema. É possível até mesmo ajustar a memória do cache de E/S e o tempo a ser aguardado até a finalização de programas com falha e serviços parados.
A seção GUI's Tools fornece links para ferramentas internas do Windows Vista, inclusive diskpart e system restore, bem como links para ferramentas de rede práticas como, por exemplo, finger, ping, netstat e nslookup. Entre outros ajustes de rede estão adaptar a unidade de transmissão máxima, TTL TCP/IP e configurações do tempo limite DNS, além de limitar a largura de banda com o serviço agendador de pacotes QoS.
Preço:US$ 29,95 (para download direto).
Ajuste e otimize o seu sistema com DTweak
Ajuste e otimize o seu sistema com DTweak (Clique na imagem para uma visão ampliada)

Resenha de livro
Microsoft Exchange Server 2007 Administrator's Companion
www.microsoft.com/mspress
O email pode ser um bicho enjoado. Por exemplo, você não tem controle real sobre o fluxo de mensagens de entrada. Caso protele a inundação de entrada suspendendo o servidor SMTP até que suas filas sejam reduzidas, você corre o risco de fazer com que o destinatário receba um aviso "mensagem não entregue". A analogia de um sistema de encanamento é muito precisa – a água está sempre fluindo e, caso feche uma válvula de uma seção, você corre o risco de pressionar outra. Uma infra-estrutura de email flexível, bem planejada e ajustada, é crítica caso você queira manter a sua empresa funcionando tranqüilamente.
Obviamente, o Microsoft Exchange Server® 2007 foi projetado para tratar volumes enormes de emails e permitir que você personalize a sua infra-estrutura para atender às necessidades da organização – tanto às de hoje quanto às de amanhã. Mas há muitas opções e decisões a serem tomadas em uma implantação do Exchange 2007. E o Exchange abrange muito mais do que email, o que complica ainda mais o risco.
Você realmente precisa contar com uma ou duas boas referências para tomar as decisões certas quanto à arquitetura e ao gerenciamento. Uma referência que pode ser indispensável é o Microsoft Exchange Server 2007 Administrator's Companion.
Esse livro aborda o ciclo de vida de implantação do produto, desde o planejamento e a implantação até a manutenção e a segurança. Ele também aborda vários clientes e opções de conectividade do cliente disponíveis para o Exchange 2007. Ele começa com uma visão geral das diferenças entre as várias versões e uma observação quanto às novidades no Exchange 2007. Você também terá uma visão geral dos componentes arquitetônicos diferentes do Exchange Server 2007.
A seguinte seção explica como planejar a implantação do Exchange e mostra como calcular os requisitos de armazenamento, servidor e processador, além de adicionar tolerância a falhas. Em seguida, o livro aborda a instalação real e a implantação, mostrando como deixar o servidor pronto para o Exchange e como instalar os diferentes componentes do software. Você tem até mesmo uma referência aprofundada quanto ao clustering dos serviços do Exchange para obter um nível mais elevado de disponibilidade.
Depois o livro aborda as muitas ferramentas de gerenciamento à sua disposição como, por exemplo, o painel MMC do Exchange e o Shell de Gerenciamento do Exchange baseado no Windows PowerShell™. Aqui você também saberá tudo, desde como criar caixas de correio até a criação de grupos de armazenamento, passando pelas operações de backup e restauração. Outro aspecto interessante dessa seção é que ela mostra como fazer todas essas operações usando tanto a GUI de gerenciamento quanto a linha de comando com o Windows PowerShell.
O Exchange 2007 conta com vários recursos de Unificação de Mensagens, que permitem gerenciar comunicações de dados e de voz usando um único sistema, e o livro também mostra como definir e usar o sistema de mensagens de voz, o sistema de mensagens de fax, o acesso à caixa de entrada baseado em voz, isso para mencionar alguns recursos.
Mergulhando na manutenção, o livro aborda técnicas e ferramentas para solução de problemas básicos, dano e recuperação de desastre, além do ajuste de desempenho. Obviamente, a segurança deve ser uma preocupação fundamental em qualquer sistema de mensagens unificadas – o livro apresenta informações aprofundadas que protegem a sua implantação. Você conhece a diretiva de segurança e as diretrizes, os recursos de antivírus e anti-spam, além da infra-estrutura de chave pública.
Por fim, o livro explora os clientes do Exchange e como dar suporte aos demais clientes dos protocolos POP3 e IMAP na organização. De modo geral, trata-se de uma boa referência geral para qualquer administrador, independentemente deste estar planejando, mantendo ou apenas interessado na plataforma do sistema de mensagens unificado do Exchange Server 2007.
Preço:US$ 49,99 (em catálogo).
(Clique na imagem para uma visão ampliada)

Greg Steen é profissional de tecnologia, empresário e entusiasta que está sempre em busca de novas ferramentas para facilitar as operações, o controle de qualidade e o desenvolvimento para os profissionais de TI.


P+R SQL Erros de E/S, espelhamento de banco de dados e muito mais
Paul S. Randal

P Comecei a executar verificações de consistência regulares nos bancos de dados que gerencio e até mesmo adicionei alguns alertas do SQL Agent para capturar erros de E/S encontrados por consultas do usuário. Não sei se a lógica que implementei em relação a verificações e alertas funcionará porque nenhum dos meus bancos de dados apresenta danos. Como é possível criar danos em um banco de teste para que consiga ter a certeza de que tudo o que configurei funcione corretamente? Além disso, há mais alguma coisa que devo fazer para detectar erros de E/S?
R No SQL Server® 2000, o velho truque de criar um banco de dados danificado tendo em vista o teste era excluir manualmente uma linha da tabela sysindexes de um banco de dados de teste. Mas com o SQL Server 2005, danificar uma tabela do sistema dessa maneira é muito difícil. A melhor forma de danificar um banco de dados de teste por conta própria é usando um editor hexadecimal para alterar um arquivo de dados enquanto o banco de dados é desligado. Eis o que fazer:
  • Desligue o banco de dados para que os arquivos de dados não sejam bloqueados. (Mas tome cuidado para não desanexar o banco de dados, porque caso danifique a página errada, você talvez não consiga anexá-la novamente.)
  • Escolha um deslocamento maior que, digamos, 100 páginas no arquivo (pelo menos 819.200 bytes), mas verifique se ele está de acordo com um limite de 8.192 bytes (um limite de página). Isso evita páginas de metadados críticos e bitmaps de alocação, o que permite iniciar o banco de dados e executar o DBCC CHECKDB nele.
  • Escreva alguns bytes de zeros no deslocamento escolhido do arquivo. Usar essa técnica é praticamente uma garantia de introdução de alguns danos no cabeçalho da página.
Dito isso, a forma mais rápida de criar um banco de dados de teste danificado é usar um já criado por alguém. É possível encontrar exemplos de bancos de dados do SQL Server 2000 e do SQL Server 2005 corrompidos (com explicações) no meu blog (em go.microsoft.com/fwlink/?LinkId=115151).
Quanto à sua segunda pergunta, sobre o que deve fazer para detectar erros de E/S, você deve habilitar somas de verificação da página. Esse recurso foi introduzido no SQL Server 2005 como uma forma de proteger toda a página do banco de dados de erros apresentados pelo subsistema de E/S.
Basicamente, quando uma página é gravada em disco, a última coisa que o SQL Server faz é calcular uma soma de verificação para toda a página de 8 KB e carimbar a soma de verificação nela. Quando uma página é lida no disco, caso ela tenha uma soma de verificação, esta é recalculada e comparada com a armazenada na página. Em caso de não haver correspondência entre elas, algo externo ao SQL Server que corrompeu a página, e um erro 824 foi suscitado. O erro é exibido para a conexão que causou a leitura da página, bem como registrado no log de erros do SQL Server e no log de eventos do aplicativo do Windows®.
Por padrão, as somas de verificação da página permanecem ativadas em todos os bancos de dados criados no SQL Server 2005 e no SQL Server 2008. No entanto, elas devem ser habilitadas manualmente para bancos de dados atualizados em relação a versões anteriores do SQL Server. É possível habilitar somas de verificação usando este código:
ALTER DATABASE mydb SET PAGE_VERIFY CHECKSUM;

Dica: altere a porta do SQL Server padrão
Por padrão, a porta configurada das instâncias do SQL Server é 1433. Assim que for usada por uma instância, essa porta não poderá ser ocupada por mais nenhuma outra. Por isso, se você instalar uma segunda instância que ouça a rede usando TCP, ela precisará de uma outra porta. E, em alguns casos, o administrador talvez queira alterar a porta por motivos de ofuscação (embora essa forma de ofuscação seja secundária e possa ser facilmente desfeita por um scanner de porta). Obviamente, você precisa configurar o cliente para usar uma porta diferente. Há três abordagens comuns para fazer isso.
Primeira, pressupondo que a administração tenha alterado a porta de uma instância para 5555, é possível especificar simplesmente o número da porta da instância no nome da máquina à qual você deseja se conectar usando a sintaxe MyServername,5555. Se a porta for alterada novamente, os clientes também terão de alterar connectionStrings novamente.
Outra opção é usar aliases do SQL Server, configurados no cliente. Além de especificar um nome de alias, o nome de servidor, o nome de porta e o protocolo também devem ser especificados. Uma vez configurado, o alias pode ser usado como um nome de servidor a ser conectado à instância do banco de dados. A vantagem dessa opção é que as alterações feitas na configuração do servidor podem ser implantadas por um administrador de domínio, porque as configurações são armazenadas no Registro.
A terceira opção para instâncias nomeadas em que o usuário só conhece o nome da instância e especifica o nome usando MachineName\InstanceName em connectionString é usar o serviço Navegador do SQL Server. Ele já está implementado no SQL Server 2000 como parte de um serviço em execução. No entanto, no SQL Server 2005, o serviço Navegador do SQL Server foi criado como um serviço separado. Além de realizar a descoberta da instância em nome da máquina, ele também responde solicitações UDP (User Datagram Protocol) na porta 1434 com o número da porta apropriado à instância solicitada, o que habilita o redirecionamento para o cliente e o suporte a uma conexão transparente.
– Jens K. Suessmeyer, consultor em banco de dados da Microsoft

P Para remover toda a fragmentação no meu banco de dados, configurei um plano de manutenção noturna que recria todos os índices do banco de dados de produção, em execução no SQL Server 2005 Enterprise Edition com SP2. Como percebi que isso faz com que o banco de dados cresça excessivamente, adicionei uma etapa para reduzir todo o espaço extra, já que não há muito espaço em disco. Agora parece que a etapa de recriação não está funcionando. O que está havendo?
R Você se deparou com um problema que as pessoas comumente enfrentam quando definem um plano de manutenção. Você sofreu do ciclo de efeito sanfona.
Quando um índice é recriado, uma nova cópia é criada antes da exclusão do índice existente. Esse procedimento exige espaço adicional nos arquivos do banco de dados – em geral, aproximadamente o mesmo espaço usado pelo índice atual. No SQL Server 2000, o espaço adicional também era necessário à classificação das linhas do índice (aproximadamente 20% do tamanho do índice), mas esse requisito também foi eliminado em uma recriação de índice simples no SQL Server 2005.
Às vezes, os administradores querem remover o espaço adicional criado durante a recriação do índice, e adicionam uma operação de redução ao plano de manutenção após a etapa de recriação. Porém, ainda não é amplamente sabido que essa redução causará a fragmentação do índice por conta da natureza de seu algoritmo. Isso significa que o índice recém-recriado e desfragmentado será fragmentado imediatamente – anulando, inicialmente, o efeito de sua recriação.
Considerando que o arquivo de banco de dados acabará crescendo novamente na próxima vez em que ocorrer a recriação, é melhor permitir que o banco de dados tenha o espaço adicional e evitar totalmente a execução da operação de redução. (Além disso, aumentar e reduzir continuamente os arquivos de banco de dados causará a fragmentação no nível do sistema operacional – o que pode contribuir para o mau desempenho da mesma forma que a fragmentação do índice.)
Por fim, algo que você deve considerar é a redução da freqüência com que recria índices. Você talvez até queira tentar usar um método alternativo como, por exemplo, o antigo DBCC INDEXDEFRAG que escrevi para o SQL Server 2000 ou a sintaxe ALTER INDEX REORGANIZE mais recente do SQL Server 2005 e do SQL Server 2008.
Existe um documento muito útil que aborda a fragmentação do índice e apresenta diretrizes em relação ao momento de remover a fragmentação (em go.microsoft.com/fwlink/?LinkId=115154). Ainda que esse documento tenha sido escrito para SQL Server 2000, os conceitos continuam os mesmos.

P Temos avaliado a estratégia de recuperação de desastre na minha organização e acho que o espelhamento de banco dados é a saída para a nossa situação. O servidor que estou tentando proteger tem muitos bancos de dados não relacionados (o resultado de um projeto de consolidação de servidor anterior) e gostaria de usar o espelhamento de banco de dados em todos eles. A pergunta que estou tentando responder é quantos bancos de dados poderei espelhar antes que o desempenho seja prejudicado?
R A resposta para essa pergunta é uma que uso muito: depende! As diretrizes publicadas dizem para não espelhar mais de 10 bancos de dados por instância, mas 10 é apenas uma estimativa quanto ao máximo em relação à maioria dos usuários. Você precisa considerar os seguintes fatores na configuração do hardware:
  • Quanta memória as instâncias principal e espelho têm? (O ideal é que elas sejam iguais.)
  • Quanto poder de processamento as instâncias principal e espelho têm? (Ele também deve ser igual.)
  • Quanta largura de banda o subsistema de E/S tem na instância espelho? (Ela deve ser a mesma da principal.)
  • Quantos logs de transação a carga de trabalho gera em cada um dos bancos de dados?
  • Quanta largura de banda de rede há disponível entre as instâncias principal e espelho?
Os últimos dois fatores são os mais críticos. Se a largura de banda da rede disponível entre as duas instâncias não for o suficiente para tratar a taxa de geração de log da transação combinada por segundo de todos os bancos de dados espelho, o desempenho cairá nos bancos de dados principais. O SQL Server 2008 ajuda a aliviar parte dessa carga com a compactação do fluxo de log.
O próximo aspecto mais crítico a ser considerado são os requisitos de memória e thread tendo em vista o espelhamento. Cada banco de dados espelhado usa um thread e mais alguma memória. Em servidores menos potentes, muitos bancos de dados espelhados podem significar muita carga no servidor quando combinados com a carga de trabalho regular.
Você também precisa considerar como executará o espelhamento do banco de dados. No modo síncrono, as transações no banco de dados principal não podem ser confirmadas até que todos os registros do log de transação tenham sido copiados para o log de transação do banco de dados espelhado. Por isso, qualquer atraso causado por uma rede sobrecarregada poderia causar um problema no desempenho da carga de trabalho no principal.
No modo assíncrono, as transações podem ser confirmadas no principal sem que seja preciso aguardar, mas um atraso de rede poderia fazer com que o volume do log de transações aguardando envio para o espelho crescesse. Isso pode causar problemas em relação ao tamanho do log da transação. O que é pior: qualquer log de transação não-enviado será perdido em caso de falha. Assim, quanto mais logs de transação não-enviados, maior será o potencial de perda de dados em uma situação de recuperação.
Os cenários podem variar muito, e vi alguns exemplos interessantes em ambientes de produção reais. Por exemplo, vi um ambiente com 150 bancos de dados, todos com volumes de atividade muito baixos e nem todos ao mesmo tempo. Todos os 150 bancos de dados são espelhados sem problemas.
Por outro lado, vi uma instalação com apenas três bancos de dados bastante carregados, mas sem uma boa conexão de rede. Nesse cenário, eles mal conseguem espelhar um banco de dados antes da falta de largura de banda da rede causar prejuízos à carga de trabalho.
A chave para o sucesso é, primeiro, fazer o cálculo da geração de log. Se a largura de banda da rede disponível aparentemente der suporte ao número de banco de dados que deseja espelhar, você talvez não tenha nenhum problema. Teste a configuração antes de colocá-la em produção e não se esqueça de incluir todas as operações que poderiam gerar o log de transação – especialmente uma possível manutenção do banco de dados.

Paul S. Randal é diretor administrativo da SQLskills.com e MVP SQL Server. Ele trabalhou na equipe do mecanismo de armazenamento do SQL Server da Microsoft entre 1999 e 2007. Paul escreveu o DBCC CHECKDB/repair para SQL Server 2005 e foi responsável pelo mecanismo de armazenamento principal durante o desenvolvimento do SQL Server 2008. Especialista em recuperação de desastre, alta disponibilidade e manutenção de banco de dados, Paul é apresentador regular em conferências. Ele bloga em SQLskills.com/blogs/paul.


Utilitário em destaque Windows Vista Upgrade Advisor
Lance Whitney

Finalmente chegou a hora de começar a planejar a atualização da sua organização para o Windows Vista® e, como com qualquer atualização, existem perguntas. Seus clientes de rede atendem aos requisitos de hardware e software? Quais problemas de compatibilidade você enfrentará? Para ajudar a responder essas e outras perguntas, a Microsoft fornece o gratuito Windows Vista Upgrade Advisor. Esse utilitário verifica todo o hardware e software instalado em um PC para determinar se uma atualização é viável. Se for, o Advisor recomenda a versão ideal do Windows Vista e revela qualquer problema a ser resolvido antes da atualização.
A verificação do Upgrade Advisor normalmente leva vários minutos. Enquanto a verificação é executada, um gráfico lista as diferentes versões do Windows Vista, comparando os recursos de cada uma. Você também pode selecionar uma edição específica — Ultimate, Home Premium, Business ou Home Basic — para exibir uma breve descrição e lista de recursos proeminentes. Após a verificação ser concluída, a tela Detalhes do Relatório informa se seu PC é compatível com Windows Vista e qual versão é aconselhável. Os detalhes incluem:
Requisitos do sistema Essa opção informa se seu hardware — CPU, RAM, memória de vídeo e unidade de CD/DVD — são suficientes. Se não for o caso, você verá detalhes sobre o que é necessário para atualizar seu PC, por exemplo, quanto de memória você precisa adicionar.
Dispositivos Essa opção examina todos os dispositivos externos e drivers, incluindo modem, impressora, scanner, placa de som, monitor e placa de vídeo. Se um dispositivo não passar no teste de compatibilidade, o relatório explica que ação tomar, como baixar os drivers mais recentes do site do fabricante. Um link para o site é convenientemente fornecido.
O Upgrade Advisor relata problemas de compatibilidade conhecidos e recomenda maneiras de resolvê-los
O Upgrade Advisor relata problemas de compatibilidade conhecidos e recomenda maneiras de resolvê-los (Clique na imagem para uma visão ampliada)
Programas Essa opção analisa o software instalado. Você aprenderá quais aplicativos podem ser executados no Windows Vista como estão e quais são incompatíveis ou precisam ser atualizados para passar no teste.
Se algum dos componentes falhar no teste de compatibilidade com uma versão mais avançada do Windows Vista, como a Ultimate, você pode voltar à tela introdutória e selecionar outra versão, como a Business. Em seguida, você poderá verificar se seu PC atende a todos os requisitos dessa versão.
Finalmente, uma Lista de Tarefas descreve a configuração de hardware do seu PC e relaciona as tarefas que precisam ser concluídas antes e depois da instalação do Windows Vista. Ela resume os itens das telas anteriores e oferece recomendações adicionais, como mostra a captura de tela. Você pode imprimir a Lista de Tarefas ou salvá-la como um arquivo HTML.
O Upgrade Advisor é executado no Windows Vista de 32 bits ou no Windows® XP Service Pack 2 e requer Microsoft® .NET Framework 2.0 e MSXML 6.0. Para saber mais e baixar a ferramenta, apenas vá até o site microsoft.com/windows/products/windowsvista/buyorupgrade/upgradeadvisor.mspx.

Lance Whitney é consultor de TI, instrutor e redator técnico. Ele passa incontáveis horas fazendo ajustes em estações de trabalho e servidores do Windows. Jornalista por formação, ingressou corajosamente no mundo de TI há 15 anos.


Explorando o SharePoint Descentralizando a administração de sites
Pav Cherny

Faça o download do código deste artigo:: SharePoint2008_06.exe (1160KB)

O Microsoft Windows SharePoint Services (WSS) 3.0 e o Microsoft Office SharePoint Server (MOSS) 2007 oferecem suporte a uma administração e a um modelo de segurança flexíveis que permitem às organizações de TI centralizar o controle com os componentes de infra-estrutura, como servidores Web e servidores de banco de dados, e descentralizar o controle com
conjuntos de sites e sites hospedados. A centralização da infra-estrutura do SharePoint® ajuda a reduzir a sobrecarga de manutenção, consolidar a lógica de negócios, fornecer um único ponto de acesso aos recursos do SharePoint e evitar investimentos desnecessários em tecnologia.
Ao mesmo tempo, a descentralização da administração do site permite garantir que departamentos individuais tenham controle autônomo sobre os conjuntos de sites departamentais do SharePoint, sites, bibliotecas de documentos, listas, soluções de fluxo de trabalho e outros recursos do SharePoint. Entretanto, um efeito indesejado de delegar a administração de site a departamentos individuais é o aumento da complexidade de manutenção para o departamento de TI. Por exemplo, como controlar o uso de recursos, sites do SharePoint vencidos e conteúdo ultrapassado em uma infra-estrutura centralizada se você não tem acesso aos conjuntos de sites e aos sites dentro do seu ambiente?
Neste artigo, falo sobre o modelo de segurança do WSS 3.0, incluindo as vantagens e as implicações de delegar controle administrativo em sites do SharePoint a departamentos individuais e, ao mesmo tempo, manter o controle administrativo centralizado na infra-estrutura do SharePoint. Mostro como a administração de sites delegados funciona, como as permissões de acesso e o corte de segurança no nível de site, lista e item ajudam a manter um ambiente seguro e amigável e como os administradores de Web farm podem obter acesso às estatísticas de site necessárias sem permissões elevadas do SharePoint.
Se quiser conhecer minhas explicações em um laboratório de teste, baixe o material que acompanha esta coluna em technetmagazine.com. O material inclui instruções detalhadas de implantação para uma Web farm baseada no Windows Server® 2008 que reflete, razoavelmente bem, um ambiente de produção para uma empresa com vários departamentos.

Infra-estrutura do SharePoint e administração de conjuntos de sites
Você pode criar uma infra-estrutura do SharePoint baseada em uma implantação em um único servidor ou em uma Web farm. Na verdade, em geral, as empresas usam as duas. A implantação de um único servidor é adequada para departamentos individuais que precisam de uma solução de colaboração rápida e direta. Os requisitos de desempenho e de confiabilidade são mínimos. Os usuários tendem a ser compreensivos quando um servidor departamental do SharePoint, com freqüência implantado em hardware de estação de trabalho, não está disponível, porque a manutenção do sistema é responsabilidade do próprio departamento e os usuários do departamento, afinal, não são administradores de TI.
A situação muda de figura completamente para recursos de servidor mantidos pelo departamento de TI. Desempenho e confiabilidade se tornam fatores críticos, muitas vezes exigindo a implantação de soluções de alta disponibilidade para garantir a conformidade com o SLA (Contrato de Nível de Serviço). Implantações de Web farm de carga balanceada, clusters de failover do SQL Server® e bancos de dados armazenados em SANs (Rede de Área de Armazenamento) podem ajudar a atender às necessidades de desempenho e alta disponibilidade da sua empresa. Consulte a Figura 1 para obter uma ilustração dessa arquitetura.
Figura 1 Uma infra-estrutura do SharePoint com cluster de failover do SQL Server e SAN
Figura 1 Uma infra-estrutura do SharePoint com cluster de failover do SQL Server e SAN (Clique na imagem para uma visão ampliada)
Como você pode ver na Figura 1, vários tipos de administradores devem trabalhar juntos para manter os recursos em uma infra-estrutura do SharePoint centralizada, embora cada um deles encare o ambiente de uma perspectiva diferente. Por exemplo, os servidores na infra-estrutura são transparentes para os administradores de conjuntos de sites. Os administradores de conjuntos de sites trabalham com a interface do usuário padrão do SharePoint. Essa interface não é alterada, não importa se você hospeda os sites em um computador de estação de trabalho executando o WSS 3.0 no seu escritório ou em uma Web farm em um data center.
A infra-estrutura do SharePoint também é transparente para os administradores de bancos de dados e engenheiros de armazenamento SAN. Para esses administradores, os bancos de dados do SharePoint não são diferentes de outros bancos de dados SQL, e os LUNs (números de unidade lógica) para o cluster de failover do SQL Server não são diferentes dos outros LUNs. A pessoa mais diretamente envolvida com a infra-estrutura do SharePoint é o administrador de Web farm, no entanto, ele não tem nenhum controle sobre os conjuntos de sites, bancos de dados ou LUNs.
Sabe-se que os administradores de conjuntos de sites departamentais em geral não conhecem os detalhes da infra-estrutura. Afinal, não é preciso conhecer esses detalhes para fornecer sites e delegar permissões de acesso a equipes e grupos dentro de um departamento. É fácil criar um novo site e começar a colaborar, e questões como os altos custos de armazenamento associados à tecnologia SAN, raramente são consideradas.
Em cada projeto e iniciativa, surgem novos sites de equipe, sites vencidos permanecem, conteúdo ultrapassado não é excluído e o ambiente do SharePoint cresce em um ritmo impressionante até alcançar uma escala que os administradores de sistema não podem mais ignorar. Por exemplo, o ambiente interno do SharePoint na Microsoft uma vez chegou a incluir mais de 180 mil sites até que a equipe de TI da Microsoft começou uma iniciativa de simplificação em 2006.
Instruir os administradores de conjuntos de sites pode ajudar a manter os problemas sob controle em uma infra-estrutura do SharePoint centralizada. Aplicar cotas e bloqueios de conjuntos de sites também é útil, no entanto, esses métodos não são muito eficientes ao lidar com sites ultrapassados de equipes e conteúdo que desperdiça preciosos recursos de armazenamento e backup.
O conteúdo ultrapassado não faz necessariamente um conjunto de sites exceder sua cota. Obviamente, você pode configurar o SharePoint para enviar notificações por email a proprietários de conjuntos de sites e excluir automaticamente conjuntos de sites não-utilizados depois de um período especificado, usando o recurso Confirmação e Exclusão de Uso do Site no site Administração Central do SharePoint 3.0, mas esse recurso não funciona no nível do site individual. Um conjunto de sites pode conter sites atuais e obsoletos, mas o recurso Confirmação e Exclusão de Uso do Site não funciona nesse nível de granularidade.
Posteriormente, mostrarei como identificar sites não-usados e conteúdo ultrapassado, verificando a data da última modificação de documentos e itens de lista, mesmo sem permissões de acesso ao conjunto de sites. Esse recurso de relatório não está disponível prontamente, mas felizmente não é difícil de implementar.

Administração descentralizada de sites do SharePoint
A tarefa de delegar privilégios de administração de sites do SharePoint é muito simples. Usando o site Administração Central do SharePoint 3.0, a ferramenta de linha de comando Stsadm.exe ou uma ferramenta de provisionamento, é possível criar aplicativos Web, caminhos gerenciados e conjuntos de sites na infra-estrutura. Como um administrador de Web farm, você pode especificar administradores de conjuntos de sites primários e secundários ao criar um conjunto de sites. Esses administradores de conjuntos de sites podem ser usuários de domínio comuns. Eles não necessitam de permissões administrativas nos servidores de Web farm ou em outros servidores de infra-estrutura. Eles usam um navegador da Web para executar as tarefas de administração de sites diretamente na interface do usuário do SharePoint.
A Figura 2 ilustra a administração de sites delegada de acordo com as instruções passo a passo que você encontrará nas planilhas do material complementar. Neste exemplo, o administrador de Web farm provisionou conjuntos de sites separados para os departamentos de RH (http://sharepoint/hr) e de TI (http://sharepoint/it).
Figura 2 Administração delegada de sites do SharePoint
Figura 2 Administração delegada de sites do SharePoint (Clique na imagem para uma visão ampliada)
Os administradores de RH e de TI podem usar o recurso Sites e Espaços de Trabalho disponível no menu Ações do Site da interface do usuário do SharePoint para criar sites de nível inferior e poder aplicar permissões a partir do site pai ou definir novas permissões de usuário e administrativas para sites de nível inferior. Observe que, a menos que seja configurado explicitamente, o administrador de Web farm não poderá acessar sites de nível superior ou inferior, o administrador de RH não poderá acessar sites de TI e o administrador de TI não poderá acessar sites de RH, embora todos os sites sejam hospedados no mesmo ambiente do SharePoint.
O design dos conjuntos e das hierarquias de sites depende dos requisitos organizacionais. No exemplo da Figura 2, não criei um site mestre acima de http://sharepoint/hr e http://sharepoint/it. Em outras palavras, não existe um conjunto de sites no caminho http://sharepoint. Mas você pode facilmente criar um conjunto de sites nesse caminho ou usar outros caminhos gerenciados, como http://sharepoint/sites/hr e http://sharepoint/sites/it.
Você também pode criar aplicativos Web separados para RH e TI a fim de estabelecer URLs base mais intuitivas, como http://hr e http://it, provisionar sites gerais de portal para os departamentos e usar Web Parts de rollup para listar informações de sites de nível inferior nesses sites mestres. Os conjuntos de sites separados facilitam a administração autônoma, ajudam a limitar o acesso às informações departamentais, fornecem recursos de personalização individual para Páginas Mestras, layouts de página, modelos, Web Parts e controles de navegação e podem ser usados para colocar dados confidenciais em bancos de dados de conteúdo dedicado, independentemente de outros conjuntos de sites ou bancos de dados de conteúdo.

Funções, permissões de site e remoção de segurança
Depois de criar os conjuntos de sites e delegar as permissões administrativas, um administrador de conjunto de sites pode abrir um site de nível superior e usar o recurso Configurações do Site disponível no menu Ações do Site para gerenciar o conjunto de sites. Isso inclui adicionar (ou remover) outros administradores de conjuntos de sites com permissões totais a todos os sites do conjunto de sites, criar grupos, associar esses grupos a funções e adicionar usuários a esses grupos para conceder permissões de leitura e de colaborador. Isso também inclui o provisionamento de sites de grupo de nível inferior e sites de equipe.
Embora você possa conceder permissões do SharePoint aos usuários individualmente, é melhor criar grupos do SharePoint de acordo com funções específicas. Por exemplo, o SharePoint inclui três grupos padrão para as funções Visitantes, Colaboradores e Proprietários. Os Visitantes têm acesso somente leitura, os Colaboradores podem adicionar itens a listas e bibliotecas de documentos e personalizar páginas da Web e os Proprietários têm controle total.
Um recurso digno de nota é que o SharePoint executa a remoção de segurança com base na função de usuário, o que significa que os usuários só vêem os links e itens na interface do usuário aos quais possuem permissões de acesso. Se você desabilitar um acesso de usuário a um recurso, como uma lista (configurando permissões explícitas em Configurações da Lista) ou um item de lista selecionado (usando o comando Gerenciar Permissões no menu de contexto do item), a lista ou o item desaparecerão para esse usuário. Se o usuário especificar a URL do item diretamente no navegador, ele obterá a página Erro: acesso negado.
A Figura 3 mostra a remoção de segurança em ação. O administrador de RH possui permissões totais e pode acessar o menu Ações do Site para executar tarefas administrativas. O Visitante de RH, por sua vez, possui apenas permissões somente leitura ao conjunto de sites e não vê esse menu.
Figura 3 Remoção de segurança com base nas funções de usuário da interface do SharePoint
Figura 3 Remoção de segurança com base nas funções de usuário da interface do SharePoint (Clique na imagem para uma visão ampliada)
A remoção de segurança é útil pois oculta recursos, links e itens inacessíveis, mas isso também significa que os administradores de Web farm não poderão usar a interface do SharePoint para listar sites e recursos de sites sem ter permissões de acesso. Você não poderá ver esses recursos em páginas da Web ou Web Parts. Além disso, os recursos inacessíveis não aparecem em resultados de pesquisa porque o SharePoint Enterprise Search executa a remoção de segurança em tempo de consulta com base na identidade do usuário que envia a consulta.

E quanto à linha de comando?
Se a interface gráfica do usuário não fornecer um caminho até as informações desejadas sem permissões elevadas no nível do conjunto de sites, talvez a ferramenta de linha de comando Stsadm.exe forneça a solução. Por exemplo, você pode pensar em usar o comando
Stsadm -o enumsites -url http://sharepoint
para listar todos os conjuntos e proprietários de sites no aplicativo Web de http://sharepoint. Depois, você pode listar todos os sites de nível inferior usando este comando:
Stsadm -o enumsubwebs -url <conjunto de sites>
No entanto, em um ambiente de Web farm, em geral, o Stsadm.exe recebe isso como uma mensagem de erro indicando que as permissões de acesso ao banco de dados estão faltando. O Stsadm.exe não pode enumerar os conjuntos de sites, muito embora você seja um administrador de Web farm e possa gerenciar conjuntos de sites na Administração Central do SharePoint 3.0. A seguir, veja a mensagem de erro que você receberá se usar Stsadm.exe em uma Web farm sem as permissões de acesso do SQL Server:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o enumsites -url http://sharepoint
<Sites Count="2">
<Site Error="Não é possível abrir o banco de dados &quot;WSS_Content&quot; solicitado pelo logon. Falha de logon.&#xD;&#xA;Falha de logon do usuário 'CONTOSO\SPAdmin'.">
<Site Error="Não é possível abrir o banco de dados &quot;WSS_Content&quot; solicitado pelo logon. Falha de logon.&#xD;&#xA;Falha de logon do usuário 'CONTOSO\SPAdmin'." />
O administrador de Web farm recebe essa mensagem de erro porque o Stsadm.exe é executado no contexto do usuário conectado, como CONTOSO\SPAdmin, enquanto que o site do SharePoint 3.0 acessa os bancos de dados do SharePoint no contexto da conta do sistema associada ao pool de aplicativos Administração Central v3, como CONTOSO\WssConfigAdmin. Embora a concessão de permissões db_owner à sua conta para o banco de dados de conteúdo no SQL Server permita executar o comando Stsadm -o enumsites -url http://sharepoint, ainda assim não será possível enumerar os sites de nível inferior dentro dos conjuntos de sites. O comando Stsadm -o enumsubwebs -url <conjunto de sites> retorna Acesso negado. (Exceção de HRESULT: 0x80070005 (E_ACCESSDENIED)) e você volta à estaca zero. Entretanto, existe um jeito melhor e mais preciso que não requer permissões elevadas do SQL Server.

Informações sobre o site em bancos de dados
Se você não puder obter as informações necessárias por meio das interfaces e ferramentas padrão do SharePoint, deve ir diretamente aos seus bancos de dados de conteúdo. Mas, antes, uma advertência: esta é sua última chance! Os bancos de dados de conteúdo contam com esquemas e estruturas de bancos de dados proprietários que a Microsoft documentou apenas parcialmente no SDK do WSS 3.0, em uma tentativa de desencorajar os clientes a trabalhar com os bancos de dados diretamente. Sempre que possível, use a interface do usuário do SharePoint, ferramentas de linha de comando, modelo de objeto ou serviços Web para acessar as informações desejadas.
Se não houver outra alternativa e tiver de ir diretamente aos bancos de dados, você deve pelo menos restringir a solução ao acesso somente leitura. Não há suporte à modificação do esquema e das estruturas do banco de dados, o que pode causar sérios problemas que exigirão que você restaure os conjuntos de sites a partir de backup ou reinstale a Web farm do SharePoint.
Uma alternativa possível à implementação de uma solução de relatório que acessa diretamente os bancos de dados de conteúdo é especificar a conta de administrador de Web farm como um proprietário secundário na configuração do conjunto de sites. Os administradores de Web farm podem executar essa etapa no site Administração Central do SharePoint 3.0. Você pode encontrar o link Administradores de conjunto de sites correspondente em Gerenciamento de Sites do SharePoint, na página Gerenciamento de Aplicativos.
Com um administrador secundário de conjunto de sites, você pode abrir o conjunto de sites no navegador da Web, exibir as Configurações do Site e clicar no link Relatório de Uso do Site em Administração do Site, desde que tenha habilitado Processamento da Análise de Uso na Administração Central do SharePoint 3.0. Veja se, em Log e Relatório na página Operações, deseja controlar os dados de uso em arquivos de log nos servidores do SharePoint. O recurso Relatório de Uso do Site é desabilitado por padrão.
Entretanto, criar manualmente relatórios de uso de site para conjuntos individuais de sites não é prático em ambientes com um grande número de conjuntos de sites ou com requisitos rígidos que proíbem a concessão das permissões necessárias a administradores de Web farm. Uma abordagem mais prática é implementar um aplicativo de relatório do ASP.NET simples que lista todos os conjuntos de sites do banco de dados de conteúdo com estatísticas importantes, como o número de itens, o tamanho total combinado de todos os itens e a data da última modificação dos itens, como ilustrado na Figura 4.
Figura 4 Obtendo estatísticas de sites diretamente de um banco de dados de conteúdo
Figura 4 Obtendo estatísticas de sites diretamente de um banco de dados de conteúdo (Clique na imagem para uma visão ampliada)
Se você executar esse aplicativo sob a identidade do pool de aplicativos Administração Central do SharePoint v3, poderá ter acesso aos bancos de dados de conteúdo sem a necessidade de permissões elevadas do SQL Server. Como mencionado anteriormente, a conta Administração Central já possui as permissões necessárias do SQL Server.
O material complementar inclui uma solução de relatórios simples que usa consultas SELECT para o banco de dados de conteúdo no servidor SQL e instruções passo a passo para implantar essa solução em um servidor Web. É importante notar que não implementei nenhuma verificação de segurança. A solução é executada com autenticação anônima.
Não é necessário autenticar o usuário porque a conta Administração Central fornece o contexto de segurança necessário para acessar os bancos de dados de conteúdo. Usei uma porta personalizada para o site da Web da solução, bloqueado por meio do Firewall do Windows® no Windows Server 2008, portanto, somente um usuário local pode abrir o aplicativo Web. Com isso, os requisitos de segurança no meu ambiente de teste foram atendidos, mas, em um ambiente de produção, você deve aumentar mais a segurança, por exemplo, habilitando a autenticação do Windows e configurando permissões de acesso restritivas ao diretório virtual do aplicativo ASP.NET.

Conclusão
O SharePoint fornece recursos de administração e conjunto de sites flexíveis que permitem centralizar a infra-estrutura do SharePoint e, ao mesmo tempo, descentralizar a administração de sites de acordo com as necessidades específicas da sua empresa. Uma infra-estrutura centralizada pode ser benéfica a empresas de qualquer porte porque um ambiente consolidado ajuda a reduzir custos, facilita o compartilhamento de informações dentro dos departamentos e entre eles, fornece a base para aplicar conhecimento especializado de forma direcionada para manter o ambiente com alta segurança, confiabilidade e escalabilidade e fornece aos usuários um único ponto de acesso a sites e recursos do SharePoint na rede da empresa.
Ao mesmo tempo, departamentos e unidades de negócios individuais podem manter o controle de seus recursos do SharePoint. Os administradores de Web farm podem designar administradores de conjuntos de sites que executem tarefas de administração de sites em suas áreas de responsabilidade sem qualquer envolvimento do departamento de TI.
Entretanto, com a mudança de controle para os departamentos, os administradores de Web farm também perdem a capacidade de monitorar a utilização de recursos na infra-estrutura usando os recursos e ferramentas padrão do SharePoint. Aplicar cotas a bancos de dados de conteúdo, enviar lembretes de email a administradores de conjuntos de sites e controlar dados de uso para fins de relatório são tarefas que podem ajudar a diminuir o problema, mas para gerenciar a infra-estrutura do SharePoint com eficiência, os administradores de Web farm precisam de outras ferramentas que extraiam os metadados do site necessários diretamente dos bancos de dados de conteúdo em um formato somente leitura.
As opções disponíveis incluem o uso do SQL Server 2005 Reporting Services ou de uma solução de relatório de nível empresarial semelhante. Como o exemplo no material complementar mostra, você também pode usar as consultas SELECT do SQL Server para obter as informações necessárias.

Pav Cherny é especialista em TI e autor especializado em tecnologias Microsoft para colaboração e comunicação unificada. Entre suas publicações estão white papers, manuais de produto e livros com foco nas operações de TI e na administração do sistema. Pav é presidente da Biblioso Corporation, empresa especializada em serviços de documentação gerenciada e de localização.


Windows PowerShell Uma boa aparência
Don Jones

Não é incomum querer que seus scripts produzam uma saída com uma boa aparência, e muitas vezes me perguntam sobre a melhor maneira de produzir coisas como tabelas. Existem realmente duas formas de fazer isso. A primeira etapa é escrever um script que coloque os dados — isto é, quaisquer dados que eu queira exibir de um modo formatado — em variáveis chamadas
$data1, $data2 e $data3. Agora posso falar da formatação dos dados.

O método baseado em texto
Na Web
Você está procurando uma demonstração rápida das técnicas discutidas na coluna do Windows PowerShell deste mês? Vá até technetmagazine.com/video para ver Don Jones colocar esses cmdlets em ação.

A maneira mais comum com que as pessoas tendem a abordar essa tarefa é a mesma forma que com tratariam dela se estivessem trabalhando em uma linguagem como VBScript, Perl, KiXtart ou outra linguagem orientada por texto. Eu poderia começar escrevendo um conjunto de cabeçalhos de coluna na tela:
Write-Host "ColumnA'tColumnB'tColumnC"
Observe que o`t é uma seqüência de escape especial no Windows PowerShellTM que insere um caractere de tabulação. Para escrever cada linha da minha tabela — lembrando que meus dados estão em $data1, $data2 e $data3 — possuo algumas opções. Uma é simplesmente escrever as variáveis, confiando na capacidade do shell de substituir variáveis pelo seu conteúdo entre aspas duplas:
Write-Host "$data1't$data2't$data3"
Outra maneira ligeiramente mais atraente para atingir esse objetivo usa o operador –f. Essa técnica separa a formatação dos dados e faz o que eu considero uma linha de código mais fácil de ler e de manutenção mais fácil:
Write-Host "{0}'t{1}'t{3}" –f $data1,$data2,$data3
Toda essa abordagem possui problemas significativos, no entanto. Primeiro, confiando nas paradas de tabulação fixas na janela do console, estou me preparando para uma formatação estranha. Por exemplo, se uma linha da tabela particular possuir um valor de 20 caracteres na primeira coluna, eu lanço toda a formatação dessa linha fora do lugar. Além disso, como estou enviando esse texto usando o Write-Host, estou bem limitado a uma exibição de console.
Não há maneira fácil de enviar essa saída a um arquivo ou colocá-la em outros formatos, se eu alguma vez desejar fazer isso. Mais importante, essa abordagem baseada em texto ignora completamente o shell inerentemente baseado em objeto no qual estou trabalhando, falhando em se beneficiar de todas as técnicas e recursos incríveis que o Windows PowerShell oferece.

O método baseado no Windows PowerShell
O Windows PowerShell é um shell orientado a objeto. Isso significa, idealmente, que tudo com que você trabalha deve estar em objetos, permitindo que o shell transforme as coisas em exibições de texto quando necessário. Mas como você cria objetos para partes arbitrárias de dados?
Continuando meu exemplo, eu começo criando um objeto personalizado em branco e armazenando-o em uma variável:
$obj = New-Object PSObject
Isso me fornece um objeto vazio e novo com o qual trabalhar. Em seguida, adiciono meus dados ao objeto na forma de propriedades. Para isso, simplesmente canalizo meu objeto para o cmdlet Add-Member. Adiciono algo chamado de NoteProperty, dou à propriedade um nome (uma boa idéia é usar os cabeçalhos da coluna como nomes de propriedade) e insiro os dados como os valores para as propriedades:
$obj | Add-Member NotePropertyColumnA $data1
$obj | Add-Member NotePropertyColumnB $data2
$obj | Add-Member NotePropertyColumnC $data3
Agora, simplesmente envio esse objeto — não ao console, mas ao pipeline:
Write-Output $obj
Posso então repetir essas etapas para cada linha da tabela que preciso enviar. A seguir, uma função curta que aceita uma cadeia de caracteres e envia uma versão em maiúscula e minúscula, juntamente com a cadeia de caracteres original:
functionStringVersions {
param([string]$inputString)
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty Original($inputString)
  $obj | Add-Member NoteProperty Uppercase($inputString.ToUpper())
  $obj | Add-Member NoteProperty Lowercase($inputString.ToLower())
  Write-Output $obj
}
$strings = @("one","two","three")
foreach ($item in $strings) {
StringVersions $item
}
Começa com uma matriz de variáveis de cadeias de caracteres, passando por cada uma delas por vez e enviando-as para a função. E a saída da função é escrita no pipeline.
Você deve observar que existem maneiras mais curtas de escrever esse código, mas escolhi essa técnica porque ela claramente ilustra o ponto que desejo fazer. O resultado, como mostra a Figura 1, é uma tabela perfeitamente formatada. Isso porque o shell já sabe como formatar objetos em uma tabela.
Figura 1 Saída do Windows PowerShell exibida em uma tabela
Figura 1 Saída do Windows PowerShell exibida em uma tabela (Clique na imagem para uma visão ampliada)
Sempre que um objeto possuir quatro ou menos propriedades, o Windows PowerShell escolhe uma tabela automaticamente. Então, sem nenhum trabalho qualquer da minha parte, agora possuo uma tabela com uma ótima aparência.

Mas, espere; tem mais!
Cmdlet do mês: Get-Command
Tenho certeza que você usou o Get-Command, ou seu alias útil (gcm), uma ou duas vezes para rever a lista de cmdlets disponíveis do Windows PowerShell. Mas você pode não saber como o gcm realmente é flexível. Por exemplo, se você deseja ver tudo o que o Windows PowerShell pode fazer com um serviço, execute o -noun service do gcm. Ou, se deseja ver todas as opções de exportação do Windows PowerShell, experimente o -verb export do gcm. Se apenas precisa ver quais cmdlets foram adicionados por um snap-in particular, como as Extensões de Comunidade do PowerShell, experimente o -pssnapin pscx do gcm. (Você pode substituir "pscx" por qualquer nome de snap-in para ver os cmdlets desse snap-in.)
Como você pode ver, o Get-Command desempenha um papel fundamental na capacidade de detecção do Windows PowerShell. Ele permite que você aprenda qual funcionalidade está disponível sem mesmo ter que ler um manual. E note que o gcm é uma maneira mais precisa de detectar a funcionalidade do que usar um comando como Help *. A função de Ajuda lista apenas tópicos de ajuda disponíveis. Qualquer cmdlet não enviado com a ajuda não é exibido na listagem da ajuda — embora os cmdlets estejam lá, se precisar deles.

O benefício dessa técnica vai bem além das tabelas. Quando você está trabalhando com objetos, o Windows PowerShell sabe como fazer uma enorme variedade de coisas. Quer seus dados em um arquivo CSV? Use o Export-CSV. Prefere uma tabela HTML? Canalize seus objetos para ConvertTo-HTML. Precisa de um formato de lista? Canalize-os para Format-List. Usando objetos, você pode utilizar todas essas coisas que o shell já sabe como fazer. Veja um exemplo revisado:
functionStringVersions {
  PROCESS {
   $obj = New-Object PSObject
   $obj | Add-Member NoteProperty Original($_)
   $obj | Add-Member NoteProperty Uppercase($_.ToUpper())
   $obj | Add-Member NoteProperty Lowercase($_.ToLower())
   Write-Output $obj
}
}
Desta vez, modifiquei a função para aceitar a entrada de pipeline — essa sempre é uma idéia melhor quando você está trabalhando com objetos — e para enviar ao pipeline.
Essa função agora possui seu código dentro de um scriptblock PROCESS. Isso significa que a função aceitará a entrada do pipeline e executará o scriptblock PROCESS uma vez para cada objeto canalizado.
No scriptblock PROCESS, a variável especial $_ é uma referência ao objeto do pipeline atual que está sendo processado. O resultado prático disso é que agora eu simplesmente posso canalizar em uma matriz de cadeias de caracteres:
@("one","two","three") | StringVersions
Eu obtenho uma tabela porque a função está colocando sua saída no pipeline. No final do pipeline, o shell sabe chamar seu subsistema de formatação, que toma a decisão de usar uma tabela porque os objetos no pipeline possuem menos de cinco propriedades (para mais propriedades, o shell usará uma lista por padrão).
Mas eu não preciso confiar no comportamento padrão. Posso simplesmente canalizar esses objetos em outro cmdlet para fazer algo diferente com eles:
@("one","two","three") | StringVersions | Format-List
@("one","two","three") | StringVersions | ConvertTo-HTML | Out-File "strings.html"
@("one","two","three") | StringVersions | Export-CSV "strings.csv"
@("one","two","three") | StringVersions | Select Uppercase,Lowercase -unique
A Figura 2 mostra o HTML resultante do segundo exemplo exibido em um navegador da Web. Simplesmente representando meus dados de saída em objetos, em vez de representá-los como texto simples, agora, de repente, eu possuo acesso completo a uma riqueza de funcionalidades incorporadas no shell — uma variedade de layouts de formatação; conversão HTML; opções de exportação; a capacidade de classificar, filtrar e agrupar e mais.
Figura 2 Saída de dados do Windows PowerShell em formato HTML
Figura 2 Saída de dados do Windows PowerShell em formato HTML (Clique na imagem para uma visão ampliada)
Isso é algo muito poderoso. Na verdade, pararei aqui para sugerir que todos os scripts escritos devem produzir um objeto como sua saída, de forma que você possa usar essa saída de várias maneiras diferentes quantas forem possíveis — tudo sem escrever uma única linha de código adicional.

Don Jones é especialista em automação administrativa em Windows e criou livros como Windows PowerShell: TFM e VBScript, WMI, and ADSI Unleashed (Liberando o potencial de VBScript, WMI e ADSI). Entre em contato com ele pelos fóruns em ScriptingAnswers.com.


Ei, Equipe de Scripts! Os trabalhos mais simples também têm suas recompensas
The Microsoft Scripting Guys

Faça o download do código deste artigo:: HeyScriptingGuy2008_06.exe (150KB)

Durante centenas de anos, as pessoas acreditaram que o trabalho árduo compensa; um dia de trabalho honesto produz uma grande satisfação; a verdadeira felicidade está no fim, e não no meio; o... bem, acho que já deu para entender. Trabalhe arduamente e sem reclamar (lembre-se da Cinderela) que, um dia, será recompensado.
Observação: será que é verdade que se você trabalhar muito não será apenas feliz, mas, um dia, seus esforços também serão recompensados? Por que você está perguntando isso para nós?
É claro que Cinderela teve sorte; afinal, se você mora com uma madrasta malvada e duas meias-irmãs perversas, terá muitas oportunidades de trabalhar muito. Mas e se você não tiver tanta sorte assim? E se você não viver com uma madrasta malvada e duas meias-irmãs perversas? O que fará para receber a graça de ter longos e exaustivos dias de trabalho? Como encontrará a verdadeira felicidade?
Bem, se você estiver compelido e determinado a trabalhar muito, a Equipe de Scripts sugere que tente escrever um script que gere dados de saída bem-acabados, organizados e em formato tabular, como a saída mostrada na Figura 1.
Figura 1 Saída tabular
Figura 1 Saída tabular (Clique na imagem para uma visão ampliada)
Como dissemos, Cinderela era muito afortunada: tinha de limpar a casa de cima a baixo e, quando terminava, tinha de descansar no chão da fornalha, em meio às cinzas e à fuligem. Mas até mesmo Cinderela se recusaria a escrever um script que exibisse dados em um formato tabular. Descansar sobre as cinzas e a fuligem não é nada agradável. Mas escrever um script que gera dados de saída em formato tabular é muito pior!
Observação: bem, a menos que você tenha de se sentar no chão da fornalha para escrever os scripts; aí, dá na mesma.
Por que Cinderela se recusaria a fazer essa tarefa? Por que não é brincadeira! A única maneira de exibir dados em um formato tabular em VBScript é fazer algo com estas linhas:
  • Comece determinando o tamanho máximo para cada coluna. Por exemplo, você pode querer exibir o nome de um serviço para preencher 52 espaços de caracteres.
  • Em seguida, tem de calcular o número de caracteres em um trecho de dados. Por exemplo, o nome de exibição Adobe LM Service possui 16 caracteres.
  • Se o nome de exibição exceder o limite de 52 caracteres, determine o número de caracteres que precisam ser cortados no fim da cadeia de caracteres para que ela se encaixe no espaço alocado. Se o nome de exibição não exceder o limite de 52 caracteres, determine quantos espaços em branco devem ser adicionados ao fim da cadeia de caracteres para que o comprimento seja exatamente de 52 caracteres.
  • Repita o procedimento para próximo o conjunto de dados. E o seguinte. E assim por diante.
Se você conhece a história de Cinderela, então sabe que sua fada madrinha pode aparecer de repente, transformar um mouse em um administrador de sistemas (nem vou dizer como é fácil isso acontecer) para que ele escreva o script para você. Mas talvez você não deva contar muito com isso. Provavelmente, está sozinho nessa.
Pensando no lado bom, você se sentirá a pessoa mais realizada do mundo. Isso porque também será a pessoa mais esforçada do mundo. A mais esforçada disparado.
É claro que há quem troque um pouco dessa satisfação pela oportunidade de não ter de trabalhar tanto. Se você concorda com isso, deve estar pensando: "Graças a Deus que a Equipe de Scripts existe; ela me diz como transformar um mouse em um administrador de sistemas para que ele formate a minha saída em uma tabela". Bem, temos más notícias para você: a Equipe de Scripts não faz a menor idéia de como transformar um mouse em um administrador de sistemas (embora saiba como transformar um administrador de sistemas em um covarde, se isso lhe interessa). Não sabemos o que você deve fazer para que alguém escreva scripts para você, muito menos com dados de saída em formato tabular.
Mas não tem problema. Contanto que execute o Windows® XP ou Windows Server® 2003 (que é o caso da maioria), você não precisa que um mouse escreva os scripts para você. (Não, lamentamos, mas isso não funciona no Windows Vista®.) Em vez disso, você pode fazer o trabalho sozinho, e com o mínimo de esforço, graças ao objeto Microsoft.CmdLib. Veja o script de exemplo na Figura 2.
Figure 2 Criando uma exibição tabular
Dim arrResultsArray()
i = 0

Set objCmdLib = _
  CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = _
  WScript.Application

arrHeader = Array("Display Name", _
  "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" _
  & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery _
  ("Select * FROM Win32_Service")

For Each objService In colServices
  ReDim Preserve arrResultsArray(i)
  arrResultsArray(i) = _
  Array(objService.DisplayName, _
    objService.State,objService.StartMode)
  i = i + 1
Next
objCmdLib.ShowResults arrHeader, _
  arrResultsArray, arrMaxLength, _
  strFormat, blnPrintHeader, arrBlnHide
Caso não saiba, Microsoft.CmdLib é um objeto COM que acompanha o Windows XP e o Windows Server 2003. Esse objeto apresenta diversos recursos; para obter mais informações, digite cmdlib.wsc /? no prompt de comando e leia os comentários no arquivo de script que é aberto na tela. Hoje, estamos interessados em apenas um recurso do Microsoft.CmdLib: a capacidade de exibir dados em um formato tabular.
Isso levanta uma questão óbvia: como exibir dados em um formato tabular? Vejamos se você consegue adivinhar. Como pode ver, nosso script de exemplo começa definindo uma matriz dinâmica chamada arrResultsArray:
Dim arrResultsArray()
Em um script comum, os dados são reproduzidos na tela com a mesma rapidez que são recuperados. Mas você acha que a Equipe de Scripts faria algo de forma usual? Neste script, não iremos reproduzir os dados assim que são recuperados. Iremos armazenar todos os dados retornados em uma matriz e permitir que Microsoft.CmdLib os formate e os exiba para nós.
Em outras palavras, é por isso que começamos criando uma matriz dinâmica (quer dizer, uma matriz que pode ser redimensionada no decorrer do script). Depois de definir a matriz, especificamos 0 como o valor de uma variável de contador chamada i; usaremos essa variável para controlar o tamanho atual da matriz.
Caso esteja curioso, definimos o valor de i como 0 porque o primeiro item em uma matriz sempre recebe o número de índice 0. Conseqüentemente, quando adicionamos o primeiro item à matriz, adicionamos o item 0 em vez de 1.
Em seguida, precisamos inicializar a instância do objeto Microsoft.CmdLib; é o que estas duas linhas de código fazem:
Set objCmdLib = _
CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = WScript.Application
E isso nos leva a este pequeno bloco de código:
arrHeader = Array("Display Name", "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)
Fazemos isso para definir alguns parâmetros de configuração da saída. Na primeira linha, atribuímos valores a uma matriz chamada arrHeader; como era de se esperar, eles são os cabeçalhos de cada coluna em nossa tabela de saída. Para este script de exemplo, iremos recuperar as informações sobre os serviços executados em um computador e, depois, exibiremos os valores das propriedades DisplayName, State e StartMode para cada serviço.
Obviamente, atribuímos à matriz os nomes de coluna Display Name, State e Start Mode (embora pudéssemos ter-lhes atribuído também os nomes A, B e C, Larry, Moe e Curly ou qualquer um que desejássemos; os nomes de coluna não precisam ser iguais aos nomes de propriedade).
Observação: há muitas versões da história da Cinderela, inclusive os nomes das meias-irmãs. Na versão da Disney da Cinderela, as meias-irmãs se chamam Drizela e Anastácia, que por acaso é o primeiro e segundo nomes da nossa Editora de Scripts!
Na segunda linha do código, atribuímos valores a outra matriz chamada arrMaxLength. Essa matriz mantém o tamanho de cada coluna na tabela. Na saída, queremos alocar 52 espaços de caracteres à coluna 1 (o nome de exibição do serviço); depois, queremos alocar 12 espaços ao estado de serviço e 12 ao modo de início (o Microsoft.CmdLib irá inserir automaticamente um espaço em branco entre as colunas). Para que o tamanho das colunas seja de 52, 12 e 12 espaços de caracteres (como desejamos), usamos este código:
arrMaxLength = Array(52, 12, 12)
A terceira linha especifica o formato de saída para nossos dados. Queremos que os dados sejam exibidos como uma tabela; assim, definimos o valor de strFormat (a variável que mantém o tipo de saída), como... ora, Table. Suponha que, em vez disso, desejássemos exibir os dados como uma lista de valores separados por vírgula. Nesse caso, definiríamos o formato como CSV, desta maneira:
strFormat = "CSV"
Então, teríamos uma saída semelhante a esta:
"Display Name","State","Start Mode"
"Adobe LM Service","Stopped","Manual"
"Adobe Active File Monitor V4","Stopped","Manual"
"Alerter","Stopped","Manual"
"Application Layer Gateway Service","Running","Manual"
"Apple Mobile Device","Running","Auto"
"Application Management","Stopped","Manual"
Observe que o Microsoft.CmdLib não apenas inseriu vírgulas entre os itens, mas também colocou os valores individuais entre aspas duplas. É um recurso muito mais interessante do que se pode imaginar. Afinal, para fazer isso manualmente, seria necessário usar um código como este:
Wscript.Echo Chr(34) & objService.DisplayName & Chr(34) & "," & Chr(34) & objService.State & Chr(34) & "," & Chr(34) & objService.StartMode & Chr(34)
Pois é.
O quê? Você não gosta de tabelas, mas também não quer o formato CSV? Bem, nesse caso, tente definir o formato como List, que fornece uma saída como esta:
Display Name: Adobe LM Service
State:        Stopped
Start Mode:   Manual
Display Name: Adobe Active File Monitor V4
State:        Stopped
Start Mode:   Manual
Mas nós vamos além (como costumamos fazer às vezes). Depois de definir o formato de saída, definimos o valor de uma variável chamada blnPrintHeader como True:
blnPrintHeader = True
Usaremos blnPrintHeader para instruir o Microsoft.CmdLib a imprimir os cabeçalhos de coluna. E se não quisermos imprimir os cabeçalhos de coluna? Não tem problema; nesse caso, definimos blnPrintHeader como False:
blnPrintHeader = False
Por fim, temos esta linha de código:
arrBlnHide = Array(False, False, False)
Quando se trata de exibir os dados, Microsoft.CmdLib oferece a opção de mostrar ou ocultar uma coluna. Para ocultar uma coluna (ou seja, suprimir os dados de uma propriedade específica), defina o valor para essa propriedade como True; para mostrar uma coluna, defina o valor como False.
Na nossa saída, mostraremos os valores para as propriedades DisplayName, State e StartMode, nessa ordem; por isso, usaremos os valores False, False, False na matriz. E se quiséssemos mostrar o DisplayName, ocultar o State e mostrar o StartMode? Nesse caso, usaríamos esta linha de código:
arrBlnHide = Array(False, True, False)
Lembre-se de usar False para mostrar uma coluna e True para ocultar uma coluna.
Agora, estamos prontos para gerar alguns dados de saída, ou melhor, estaríamos se realmente tivéssemos os dados. (Será que a Equipe de Scripts escreveria um script que falharia ao gerar dados de saída e ainda passaria um tempo extraordinário depurando esse script para, no fim, perceber que na verdade esqueceu de recuperar os dados? Não, claro que não; por que você acha isso?)
Com isso em mente, nossa próxima etapa é fazer a associação com o serviço WMI (Instrumentação de Gerenciamento do Windows) no computador local e usar o método ExecQuery para recuperar as informações sobre todos os serviços instalados no computador:
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery ("Select * FROM Win32_Service")
Talvez devamos mencionar que você não está limitado a trabalhar com os dados WMI aqui. Com era de se esperar, o Microsoft.CmdLib pode trabalhar com qualquer tipo de dado. O WMI é apenas uma maneira útil de recuperar um monte de dados.
Assim que obtemos a nossa coleção de dados relacionados a serviço, configuramos um loop For Each para percorrer todos os serviços na coleção. Entretanto, em vez de reproduzir os valores de propriedade para cada serviço, executamos este código:
ReDim Preserve arrResultsArray(i)
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
i = i + 1
O que estamos fazendo neste bloco de código? Bem, na linha 1, estamos redimensionando a matriz, usando o comando ReDim Preserve para não apenas redimensioná-la, mas também preservar quaisquer dados existentes nela. (Sem a palavra-chave Preserve, a matriz seria redimensionada, mas os dados já existentes seriam apagados.)
Qual será o tamanho da matriz? Na primeira vez que ocorre o loop, definimos o tamanho da matriz como 0; em outras palavras, criamos uma matriz contendo um elemento. E como ter certeza de que estamos criando uma matriz de tamanho 0? Porque usamos a variável de contador i, e ela é igual a 0.
Então, se estamos usando a variável i para representar o tamanho da matriz, isso significa que sempre iremos definir o tamanho como 0? Bem, deveria significar, a menos que, a cada loop, aumentássemos o valor de i em 1; como você pode ver, é isso que fazemos na linha 3 do bloco de código.
Agora, temos que nos preocupar apenas com uma linha de código:
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
Aqui, simplesmente usamos os valores de propriedade que nos interessam (DisplayName, State e StartMode) e os adicionamos à matriz arrResultsArray. Observe que não adicionamos os valores de propriedade individualmente, mas como uma matriz de valores. Concordo, não é muito comum: significa que cada item da matriz arrResultsArray será outra matriz; é assim que o Microsoft.CmdLib funciona.
Obviamente, isso pode despertar novamente certa preocupação. "Uma matriz de matrizes? Como vocês esperam que eu acesse todos os valores em uma matriz cheia de matrizes?". Calma. É fácil: deixe que o Microsoft.CmdLib cuide disso para você.
Observação: infelizmente, acessar todos os valores individuais em uma matriz de matrizes praticamente é a única coisa que o Microsoft.CmdLib pode fazer por você. Entretanto, as tarefas de limpar os aposentos da sua madrasta malvada, lavar os pratos e passar a roupa das suas meias-irmãs perversas serão consideradas para a próxima versão do objeto.
Na verdade, podemos gerar os dados de saída, em um formato tabular perfeito, simplesmente chamando o método ShowResults e passando-o para todas as matrizes e variáveis configuradas anteriormente no script:
objCmdLib.ShowResults arrHeader, arrResultsArray, arrMaxLength, strFormat, blnPrintHeader, arrBlnHide
Como tudo isso ficará? Ficará como a saída perfeitamente formatada que esperávamos encontrar na Figura 1.
Nada mal, hein? Você obtém uma bela saída sem ter de se esforçar muito para isso. (E o seu próximo script será ainda mais fácil, porque você só terá que fazer algumas pequenas alterações no primeiro script.)
Agora, sem dúvida, você não ficará tão satisfeito quanto a Cinderela ficaria se trabalhasse dia e noite só para exibir a saída do script em uma tabela. E, sejamos honestos, provavelmente, você também não se casará com um príncipe; pode ter certeza de que isso não faz parte do pacote. Mas parece que esse é um pequeno preço a pagar para obter uma saída tão perfeita como essa de um script VBScript, especialmente considerando como os príncipes são hoje em dia.
E quem sabe? Talvez você encontre um príncipe. Afinal, até a realeza precisa obter informações sobre os serviços instalados em seu computador, certo?

O desafio de script do Dr. Scripto
O desafio mensal que testa não apenas sua habilidade de resolver quebra-cabeças, mas também de criar scripts.

Junho de 2008: Caminho para o PowerShell
Em cada um desses quebra-cabeças, junte as letras horizontal, vertical e diagonalmente, para formar o nome de um cmdlet do Windows PowerShell. Cada letra será usada apenas uma vez. Por exemplo:
O cmdlet criado neste quebra-cabeça é New-Alias. Agora é a sua vez. Aqui, há mais três quebra-cabeças:

ANSWER:
O desafio de script do Dr. Scripto
Respostas: Caminho para o PowerShell, junho de 2008

Read-Host

Set-AuthenticodeSignature

The Microsoft Scripting Guys trabalham para a – bem, são empregados da – Microsoft. Quando não estão jogando/treinando/assistindo beisebol (e praticando diversas outras atividades), eles administram o Script Center da TechNet. Confira no site www.scriptingguys.com.


Os arquivos da área de trabalho Segurança X Conformidade
Wes Miller

Como um profissional de TI, você pode enfrentar objetivos que devem se complementar, mas muitas vezes, ao contrário, competem entre si. A segurança e a conformidade são dois objetivos organizacionais, nos quais a realização de um deve aprimorar o outro. Infelizmente, esse normalmente não é o caso. Minha intenção com esta coluna é fornecer a você
uma visão geral de por que estar seguro nem sempre significa estar em conformidade com as iniciativas exigidas de você, e por que estar em conformidade, muitas vezes, não significa estar seguro ou, pelo menos, não tão seguro como você deveria estar se a conformidade realmente se igualasse à segurança.

A segurança não é uma caixa de seleção
Recursos SDL
  • The Security Development Lifecycle (O ciclo de vida do desenvolvimento de segurança; Microsoft Press, 2006), de Michael Howard e Steve Lipner.
  • O blog do ciclo de vida do desenvolvimento de segurança
  • Uma olhada dentro do ciclo de vida do desenvolvimento de segurança da Microsoft
  • Security Developer Center
  • O ciclo de vida do desenvolvimento de segurança da Computação Confiável

A conformidade geralmente envolve requisitos (pessoas, processo, infra-estrutura, tecnologia, e assim por diante) impostos em uma organização, indústria, empresa ou produto externo. Às vezes, a conformidade tem a ver com padrões promulgados de dentro da indústria (como o PCI-DSS ou Payment Card Industry Data Security Standards). Em termos ideais, essas são iniciativas que se alinham com a maneira com a qual sua organização já trabalha, pelo menos até um certo grau. À medida que a adoção de um padrão prolifera, você descobre que não pode ignorá-la; não se deseja fazer negócios. Eventualmente, você precisa mergulhar de cabeça e tirar o melhor proveito disso.
É o outro tipo de conformidade que normalmente é mais problemático. Estou me referindo a iniciativas estabelecidas pelo governo, como a HIPAA (Health Insurance Portability and Accountability Act) e a Sarbanes-Oxley, onde a implementação e o tempo raramente são uma questão de escolha.
O ponto chave para compreender sobre a conformidade a normas é que ela muitas vezes envolve uma abordagem "descendente". Em geral, há um modelo simplista que define a iniciativa, e você deve olhar seus produtos e processos para tentar descobrir como eles podem se integrar com o estranho modelo transmitido a você. Você precisa estar ciente não apenas da intenção da iniciativa de conformidade, mas, talvez mais importante, de quais podem ser as ramificações legais ou financeiras para que você não as siga ou para não ser mal-sucedido (se realmente elas existirem).
Embora possamos concordar com a intenção de várias iniciativas de conformidade, a implementação é muitas vezes difícil e pode não atender ao objetivo desejado. E, lamentavelmente, várias são ineficazes (isto é, não existem ramificações diretas legais ou financeiras que podem ser impostas para falha).
Posso dizer que, como um paciente médico, não posso descrever completamente o benefício líquido da HIPAA para mim. O que posso dizer é que significa que eu tenho muito mais papelada para resolver quando vou ao médico. As conseqüências indesejadas podem ser ainda piores. Já tentou obter informações médicas importantes de um médico ou agência para uma outra? Se não existir uma permissão por escrito, você não conseguirá, não importa qual seja a urgência das informações necessárias.
A questão é que, em vários sentidos, algumas iniciativas de conformidade se tornam iniciativas de caixa de seleção. Isto é, você está projetando ou modificando seu processo ou seu produto apenas para atender a iniciativa de conformidade. Como sempre pergunto para o meu filho de três anos: "isso é uma boa idéia?".
A segurança, por outro lado, é uma iniciativa ascendente — quando feita corretamente. Esteja você projetando um produto de software ou a arquitetura para a nova rede da sua organização, o conceito principal a lembrar é meça duas vezes, corte uma. Quando você está projetando a arquitetura do produto, por exemplo, da mesma forma que um bom passo inicial descreveria a comunicação, localização, versões e assim por diante, ele também deveria descrever os elementos de segurança que precisam ser criados no aplicativo desde o primeiro dia (e quais você deveria continuar investigando e refinando durante todo o desenvolvimento).
Se estiver trabalhando com um aplicativo ou uma arquitetura herdada (tenho certeza de que a maioria de vocês está), é igualmente crítico executar o tipo de revisão de segurança detalhada que freqüentemente menciono nesta coluna. Se você não entende como algo funciona, como pode possivelmente entender se isso está seguro ou não? Para obter mais informações sobre o SDL (ciclo de vida do desenvolvimento de segurança) da Microsoft®, consulte o quadro "Recursos SDL".

A visão global
Eu me lembro de quando comecei a estudar que a segurança não se iguala simplesmente a implementar a criptografia, ACLs (listas de controle de acesso) ou TLS ou PKI (infra-estrutura de chave pública). A segurança real é toda sobre compreender a visão global: entender por que essa versão desse protocolo foi abandonada ou até mesmo nunca foi suportada; por que essa nova estrutura interrompe ataques intermediários; como a sua implementação do produto v2 é muito mais segura do que o v1, mesmo se o v1 era mais muito mais rápido. E também é necessário que você entenda como todas as partes da sua infra-estrutura se encaixam.
A conformidade, por outro lado, significa pegar sua tecnologia e certificar-se de que a infra-estrutura que você criou atende a certos critérios. Algumas iniciativas, como a PCI-DSS ou NERC (North American Electric Reliability Council), são bem intencionadas e podem terminar promovendo a alteração de segurança real. Mas, ao final do dia, com uma seleção de aperitivos de "iniciativas de conformidade" que você precisa integrar com seus próprios projetos particulares e recursos finitos disponíveis, as iniciativas de segurança perdem terreno.
A segurança tem por muito tempo sido a filha adotiva do desenvolvimento de software. Com certeza, vários de vocês estiveram em uma organização onde a segurança era algo que "faremos mais tarde". Bem, iniciativas de conformidade chegaram agora para ficar porque esse costume — de que a segurança pode esperar — não funciona e nunca funcionou.

Bom o suficiente
Recentemente eu mudei de emprego. Estou trabalhando agora para um novo grupo aqui em Austin, no Texas, que está criando uma tecnologia de lista de exceções para aplicativos um tanto similar à tecnologia que criamos na Winternals com nosso produto Protection Manager. Algo sobre o qual acho muito interessante falar com os clientes é como eles consideram a segurança de suas atuais tecnologias — ou, mais especificamente, de que forma eles acreditam que o conjunto de tecnologias usado por eles está tornando segura sua infra-estrutura. Embora seja totalmente provável que a maior parte deles esteja segura e não esteja se dividindo com as vulnerabilidades de segurança, a avaliação que muitas vezes ouço e que me deixa com um pouco de medo é que um sistema é "seguro o suficiente".
As iniciativas de conformidade são engraçadas — você pode conseguir atendê-las ou não. A responsabilidade é sua. O custo de não atender a uma iniciativa é normalmente uma multa, uma penalidade ou a remoção de uma organização. Muitas vezes, isso não é suficiente para garantir que algo realmente mude.
No caso de uma iniciativa estabelecida federalmente, eu regularmente me deparo com a atitude "boa o suficiente para agradar ao auditor" ou a disposição de executá-la sem realmente estabelecer nenhuma estrutura de conformidade porque a legislação de apoio (como HIPAA) não consolida de modo adequado a aplicação — significando que custa muito menos continuar sem seguro e enfrentar qualquer conseqüência possível posteriormente.
A segurança muitas vezes atinge as mesmas barreiras, mas, na minha opinião, pelo menos ela é mais concreta. Se você, como desenvolvedor ou implementador, diz ativamente ao gerenciamento que deixar a seção x fora da especificação deixará o produto acentuadamente mais vulnerável a violações, você pode, pelo menos, depois que o produto for enviado ou sua implantação estiver concluída, dizer "eu avisei". Com as iniciativas de conformidade, minha experiência é que o cumprimento é freqüentemente apressado, com um orçamento o mais limitado possível. O objetivo é simplesmente atender o mínimo absoluto requerido pela iniciativa — portanto, talvez, atendendo a forma da iniciativa, mas dificilmente o conteúdo, na minha opinião.

Decidindo onde você está
Recursos de segurança e conformidade
  • Diretrizes para soluções de segurança e conformidade
  • Diretrizes de segurança
  • Guia de planejamento de conformidade PCI-DSS
  • Conformidade a normas e atualizações de segurança
  • Alcançando a conformidade
  • Office for Civil Rights (Bureau de Direitos Civis) — HIPAA
  • PCI Security Standards Council (Conselho de Padrões de Segurança PCI)
  • North American Electric Reliability Council (Conselho Americano de Confiabilidade Energética)

Embora, para mim, possa ser idealista dizer que você deveria tornar o seu produto e a sua organização o mais seguros possíveis, a realidade é que a maioria das iniciativas de conformidade é realmente um compromisso que resulta de uma engenharia deficiente ou, mais freqüentemente, de complacência. Vivemos em um mundo onde "bom o suficiente" é, infelizmente, bom o suficiente. No mundo da segurança, no entanto, raramente "bom o suficiente" é inteligente. Nós, os profissionais de TI do mundo, podemos levar a sério as iniciativas de conformidade e tentar atendê-las no conteúdo e na implementação e, contudo, devemos nos certificar de que a infra-estrutura que estamos adotando não é meramente tão segura quanto ela poderia ser, mas sim tão segura quanto ela deve ser. Em outras palavras, estar em conformidade com a segurança real, não apenas para atender a iniciativa.
É importante dar um passo para trás e observar a tecnologia que você está criando, seja ela um fragmento de software comercial ou um conjunto de tecnologias que você procura integrar em um sistema maior. Não me canso de afirmar a importância de compreender as partes interconectáveis do sistema, como todas as partes trabalham juntas e as maiores ameaças que pairam sobre o seu sistema.
Dependendo da indústria na qual você trabalha, diferentes iniciativas de conformidade podem representar um papel no seu trabalho. Você pode se deparar com elas na sua vida diária ou apenas quando estiver projetando novas tecnologias ou projetos. Ou, pode ser o caso em que elas são apenas uma parte do seu trabalho durante revisões ou auditorias de conformidade especificamente designadas. Não importa. Não acredito que as iniciativas de conformidade devam ser ignoradas, mas eu o desafiaria a desafiar o status quo e, em vez de trabalhar apenas para atender as iniciativas de conformidade com as quais você está atarefado, executar uma revisão total de segurança para entender sua tecnologia por completo e modelá-la ao mesmo tempo que sua revisão de conformidade.

O que você tem a perder?
Ao final do dia, as penalidades para falhar ao atender uma iniciativa de conformidade podem parecer ambíguas. A falta de conformidade o expõe ao mesmo risco contra o qual foi adotada a proteção. As conseqüências podem parecer vagas ou distantes, mas são reais. Elas podem também não ser as suas conseqüências (individuais). Seja pragmático, mas sempre mantenha os piores cenários no fundo do coração.
Se você olhar o mesmo espaço, de uma perspectiva exclusivamente de segurança, a ameaça deve ser óbvia — e, mais importante, você deve poder identificar imediatamente o possível custo de deixar a vulnerabilidade aberta.
Muitas pessoas com as quais discuti sobre esse tópico enfatizaram o fato de que as iniciativas de conformidade são, às vezes, varridas para debaixo do tapete — uma vez que elas, muitas vezes, deixam margem a interpretações. Depois de ter conduzido uma revisão de segurança, no entanto, isso não deve ser verdadeiro sobre qualquer omissão de segurança. As ameaças imediatas da segurança ignorada devem ser claramente visíveis. Se não forem, convém reconsiderar quem você está envolvendo nas suas revisões de segurança. Você pode estar deixando escapar membros importantes da equipe que podem ajudar a encontrar os problemas reais na sua solução.

Seguindo a cauda
Na coluna focada em segurança do ano passado, discuti "Como evitar a perda dos seus dados" (technet.microsoft.com/magazine/cc162325). Um ano se passou, mais sistemas foram comprometidos, mais laptops não-criptografados foram perdidos e mais informações pessoais foram colocadas em mãos potencialmente questionáveis. É difícil dizer se algum progresso realmente foi feito. Por que ainda estamos no mesmo lugar? Os projetos freqüentemente atrasam, em um orçamento minúsculo, com recursos ridiculamente forçados demais, tentando entregar muitos recursos em um intervalo de tempo muito curto.
Esse tipo de ambiente, infelizmente, leva a uma situação onde o mínimo absoluto de trabalho se torna a norma. Isso certamente não é uma maneira de garantir que uma solução esteja segura ou em conformidade e também não é fatal a uma linha de tempo ou aos custos de um projeto.
Pessoalmente, acredito decididamente que:
  1. Você não deve criar uma solução se não está disposto a protegê-la.
  2. Sempre que você adicionar novos recursos, precisará projetar a segurança antes de começar.
  3. Se sua organização não está disposta a criar a segurança como uma etapa no seu processo de engenharia, você deve questionar quais são os objetivos gerais da sua empresa ou organização.
As organizações possuem cada vez mais dados pessoais de clientes ou parceiros por cuja segurança elas são responsáveis. Infelizmente, vivemos em um mundo onde, muitas vezes, a segurança não é o padrão e os funcionários não se sentem seguros questionando a dedicação da organização com a segurança.
A real falha de segurança (e não de conformidade) muitas vezes se torna o disparador que indica "é hora de proteger o sistema agora" e o "seguro contra roubo de identidade" se tornou uma tática de responsabilidade padrão para satisfazer clientes, estudantes, pacientes e funcionários, cujos dados pessoais, e um possível bem-estar financeiro, foram comprometidos.
Estamos todos sendo solicitados para fazer muitas coisas, muitas vezes por muito pouco e, normalmente, em um tempo muito curto. Mas é nossa responsabilidade que os profissionais de TI questionem por que a segurança não é o foco principal, por que muitas vezes o gerenciamento pensa na segurança apenas diante de iniciativas de conformidade ou, mais provavelmente, diante de falhas de segurança e suas ameaças legais reais ou potenciais (que poderiam potencialmente preocupar e, até mesmo, arriscar a organização).

Aceite o meu desafio
Mais do que qualquer coisa, eu o convido a desafiar o status quo. Se estiver sendo solicitado que você apenas atenda aos objetivos de conformidade — tente garantir que enquanto você o faça, não está simplesmente perdendo tempo atendendo ao conceito de segurança de outra pessoa. Esteja certo, mais exatamente, de que seu objetivo é proteger o sistema e, durante o caminho, definir uma parte suficiente do processo ou da sua infra-estrutura para atender a iniciativa de conformidade. Para obter mais informações sobre este tópico, consulte o quadro "Recursos de segurança e conformidade".
Em resumo, lembre-se de que a conformidade muitas vezes não é um caminho para a segurança. A segurança, no entanto, se implementada e instrumentada corretamente, pode freqüentemente ser um caminho para a conformidade.

Wes Miller é gerente sênior de produto técnico na CoreTrace (www.CoreTrace.com) em Austin, no Texas. Anteriormente, ele trabalhou na Winternals Software e como gerente de programa na Microsoft. Entre em contato com ele pelo email technet@getwired.com.


The Business of IT 10 segredos para se tornar um líder ambiental
Michael Walsh and Eliza Walsh

Parece que todas as empresas estão falando sobre seus esforços ambientais. A TI pode representar um papel principal nesses esforços — criando uma grande oportunidade para você conduzir mudanças e se tornar um líder de idéias na sua empresa e indústria. Mas por onde começar? A seguir, você verá 10 segredos para se tornar um líder competente para iniciativas ambientais e de sustentabilidade.
Familiarize-se com os problemas
A primeira etapa é desenvolver um conhecimento ampla e profundo sobre os temas sustentabilidade ambiental e computação. Como um profissional de TI, você deveria começar compreendendo o que fazer para reduzir o impacto ambiental da computação, como gerenciamento de energia, consolidação de hardware e gerenciamento de desperdício ambiental.
Como um líder ambiental, você também deve prever como o software e o hardware podem ajudar a reduzir o impacto de operações além do departamento de TI. Você pode se encontrar trabalhando intimamente com gerentes de RH, advogados e gerentes de negócios para definir políticas que resolvam o impacto ambiental total da empresa — talvez tudo de políticas de viagens de negócios a regulamentações globais de emissão de carbono.
Pessoas de dentro e fora da empresa irão esperar que você seja especialista no ambiente, na empresa e nas indústrias nas quais sua empresa opera. Então, você precisará avaliar sua compreensão da sustentabilidade do ambiente e da computação sustentável, bem como as necessidades únicas da sua empresa a curto e longo prazo.
Se for novo na empresa ou estiver assumindo uma nova função, provavelmente haverá pressão (real ou percebida) para que você aja rapidamente. Isso é especialmente verdadeiro em empresas que possuem pouquíssimo histórico de se posicionarem de uma maneira ambientalmente consciente (e agora estão ansiosas para fazê-lo).
Você deve resistir a essa tentação de mudar muito rapidamente. Isso pode arriscar sua credibilidade, bem como a da empresa. A curto prazo, concentre-se em problemas urgentes e adie a comunicação de iniciativas estratégicas até estar pronto ou seu período de crescimento tiver expirado.

Avalie objetivamente a sua empresa
A próxima etapa é avaliar de forma crítica o aspecto ambiental e a sustentabilidade da sua empresa ou linha de negócios. Para isso, você precisará envolver as principais partes interessadas e outras pessoas influentes de dentro e fora da empresa.
Você precisará desenvolver uma rede de contatos internos e externos — pessoas que podem permitir que você defina o ecossistema das partes interessadas. Elas podem ajudá-lo a desenvolver uma compreensão de onde a empresa se encontra na sustentabilidade ambiental.
Dependendo das suas responsabilidades, você pode precisar descobrir onde sua empresa está situada na conformidade (atual e futura) com regulamentações ambientais, padrões e leis. Pode ser necessário medir a posição da sua empresa com relação à sua concorrência e às expectativas de analistas. Você também deve entender como clientes, parceiros, organizações governamentais e defensores influentes dos consumidores enxergam a sua empresa e seus esforços ambientais. E você pode precisar determinar as restrições tecnológicas atuais e futuras, financeiras e ambientais com relação à sua iniciativa.
Dependendo do tamanho e do orçamento da sua empresa, pode valer a pena considerar uma pesquisa adicional. Idéias construtivas podem surgir de pesquisas internas, grupos de discussão e pesquisas de terceiros. Elas podem ajudá-lo a entender melhor a satisfação do funcionário com relação à ação ambiental corporativa passada, onde a sua empresa se encontra com respeito à concorrência e onde existem as oportunidades de mercado latente. O maior valor potencial aqui, no entanto, é a capacidade que a pesquisa de terceiros possui de validar ou refutar as opiniões mantidas pelas suas principais partes interessadas.

Preveja onde deseja estar e quando
Agora você pode começar a compreender onde a sua empresa precisa estar, a curto e a longo prazo. Para começar, você pode aproximar estes prazos para um e cinco anos, respectivamente, e dar início ao ajuste desses intervalos de tempo às suas necessidades específicas. A principal pedida é que o ambiente definitivamente não é um problema de curto prazo e aqueles que se posicionam apenas a curto prazo causam sério dano à sua empresa, às partes interessadas, aos parceiros e aos clientes.
Para determinar onde a sua empresa precisa estar nos períodos de um ano e de cinco anos, você deve estabelecer o modelo atual e futuro do cenário de negócios em que se encontra. Isso inclui a cultura da empresa, os objetivos comerciais a curto e longo prazo da empresa, restrições orçamentárias atuais e futuras, planos de expansão geográficos e o ambiente legal e regulatório em mudança da indústria.
Por exemplo, um centro de processamento de dados fornece um contexto sobre o conflito entre a tomada de decisões tática e o posicionamento estratégico. No passado, o espaço servia como a principal consideração para o desenvolvimento de um centro de processamento de dados. No entanto, nos últimos anos, a energia desafiou significativamente o espaço como um fator limitante para o crescimento e se tornou um custo operacional em elevação. Operadores de centro de processamento de dados, que perceberam as implicações a longo prazo da importância cada vez maior do fator energético, tomaram medidas para atenuar as ineficiências de consumo de energia, o que incluía mudanças radicais no gerenciamento do centro de processamento de dados que se contrapunham ao fator "espaço", que antes prevalecia na tomada de decisão. Em alguns casos, os investimentos feitos para mitigar a energia suportaram custos a curto prazo significativos quando comparados com a manutenção do paradigma existente. No entanto, com o aumento significativo nos preços da energia, os operadores dos centros de processamento de dados que alteraram de modo proativo o curso do gerenciamento do centro de processamento de dados, alguns anos atrás, agora são vistos como visionários e suas empresas mais do que compensaram os investimentos iniciais.

Desenvolva uma visão e uma estratégia
Agora você precisa desenvolver uma visão e uma estratégia. Obviamente, isso deve surgir da sua compreensão de onde os negócios estão e onde precisam estar. Ao definir a visão e a estratégia, você não deve considerá-las como sendo perpétuas por natureza. Embora o seu comprometimento com a empresa quanto ao ambiente possa ser duradouro, sua visão e estratégias provavelmente não serão. Elas enfrentarão grandes revisões devido a variáveis internas e externas, como a mudança de requisitos regulatórios, alterações na percepção do cliente e o desenvolvimento de necessidades comerciais. Com o aumento da iniciativa ambiental corporativa, é importante alinhar a visão e a estratégia de TI com qualquer visão e estratégia corporativa mais ampla.
Quando você define a visão, está definindo a direção dos seus negócios. Você deve escolher cuidadosamente suas palavras para que elas sejam refletidas, concisas e coerentes, mas não exaustivas. A visão não tem o objetivo de resolver tudo o que a sua empresa fará com relação ao ambiente. Ela deve resolver apenas aqueles problemas que precisam ser mencionados para orientar corretamente seus funcionários e parceiros. Uma declaração de missão (ou declaração de visão) é muitas vezes usada para transmitir a visão. É essencial que você comece a comunicar sua visão dentro dos primeiros seis meses.
Definindo a estratégia, você não está apenas definindo a direção, mas também estabelecendo as metas e os objetivos explícitos dos negócios, bem como esboçando os investimentos que serão feitos para atingir essas metas e objetivos. Existem modelos que podem ajudá-lo a formular um plano estratégico. Dois dos melhores modelos para problemas ambientais e de sustentabilidade são os modelos SWOT (forças, fraquezas, oportunidades e ameaças) e PESTLE (político, econômico, social, tecnológico, legal e ambiental). Você pode então definir a estratégia em um documento, como um plano estratégico.
Observe que os líderes que amplamente solicitam comentários sobre sua visão e estratégia das partes interessadas resistivas e adotantes percebidas, antes do lançamento de uma declaração escrita, têm mais probabilidade de serem bem-sucedidos. Isso é especialmente verdadeiro quando falamos daqueles que resolvem os comentários dos resistivos em seu plano final.

Evangelize a imperativa dos negócios
O evangelismo não precisa esperar até que você lance uma visão e uma estratégia. Pelo contrário, ele deve começar no dia em que você assume a função. Após o lançamento da sua visão e estratégia, no entanto, precisará adotar uma função mais pública — interna e externamente. Inicialmente, você ou um representante seu precisará comunicar sua visão a grupos influentes, como funcionários, analistas, a mídia, parceiros, clientes e defensores de clientes. Você precisará inspirar e motivá-los para acreditarem na sua visão e estratégia e fazer um argumento persuasivo de que a sua estratégia é voltada para os melhores interesses da empresa e do seu público-alvo.
No devido tempo, você precisará mudar seu foco para os elementos individuais da estratégia. No decorrer desse tempo, você deve também atualizar periodicamente esses públicos-alvo, salientando marcos significativos que demonstram sucesso, comunicando mudanças na estratégia e falando francamente sobre os desafios que a sua empresa ou indústria possui em geral.
Esteja pronto para que cada público apresente diferentes interesses e necessidades. Embora você precise falar às necessidades e aos interesses específicos de cada público, sua visão e estratégia subjacentes devem permanecer consistentes. Isso o ajudará a ganhar adesão com mais eficácia dos vários públicos-alvo.
Resista ao impulso de comunicar "necessidades comerciais" conflitantes para satisfazer diferentes públicos. Líderes que fazem isso não irão estabelecer credibilidade sobre os problemas. No mínimo, isso pode limitar sua eficiência ao liderar mudanças. Na pior das hipóteses, isso pode arriscar a credibilidade de toda a empresa. A Figura 1 destaca sete segredos para comunicar sua mensagem com eficiência.
Figura 1 Sete segredos para comunicar sua mensagem
Figura 1 Sete segredos para comunicar sua mensagem (Clique na imagem para uma visão ampliada)

Gerencie suas mensagens
À medida que você evangeliza sua visão e estratégia, considere o profissionalismo e a integridade de suas mensagens internas e externas. O ambiente e a sustentabilidade estão ligados à responsabilidade social corporativa tanto quanto estão ligados ao desenvolvimento do produto, serviços, vendas e marketing. Mesmo se sua organização tiver atribuído a liderança ambiental a você funcionalmente — sem oferecer a propriedade direta sobre os esforços de cidadania da sustentabilidade ambiental — você deverá operar sob a suposição de que será mantido nos mesmos padrões de um líder de cidadania.
Não subestime a paixão do seu público externo por problemas ambientais e sua familiaridade com práticas comerciais ambientais. Mais importante, você não deve subestimar a capacidade que eles possuem de desconstruir sua comunicação se ela carecer de integridade ou prometer muito ou muito pouco. Caso contrário, sua empresa pode ser rotulada como "ecológica de fachada".
Therefore, you need a communications strategy that incorporates a review process that includes internal pundits who can provide feedback before you take a public position. Sua estratégia de comunicação deve traçar os principais elementos da sua mensagem, como, por exemplo, um folheto informativo ambiental corporativo, uma estrutura da mensagem, uma lista de porta-vozes aprovados e temas de discussão. A estratégia de comunicação, fundamental para uma estrutura e consistência claras, deve ser concluída logo depois do desenvolvimento da visão e da estratégia. Você pode se beneficiar colocando responsabilidades pessoais nos proprietários primários da mensagem.

Permita o gerenciamento pela medição
É importante que você gerencie as responsabilidades incluídas no escopo da visão e da estratégia. Sejam as operações, o desenvolvimento do produto ou as vendas e o marketing, você deve definir os fatores que influenciam sua habilidade de atingir suas metas e objetivos. Esses fatores devem ser organizados em uma lista concisa e mapeados para o plano estratégico global. Você precisará então definir a linha de base qualitativa e/ou quantitativa desses fatores e estabelecer métricas de controle que permitam uma análise futura. Essas métricas devem ser gerenciadas ativamente.
As responsabilidades para relatar com essas métricas de controle devem ser claramente definidas e você deve organizar reuniões regulares que incluam todas as partes interessadas principais. As partes interessadas podem então discutir o impacto da métrica de controle na integridade do plano estratégico, o que é possível pelo mapeamento da métrica em relação aos fatores e, por sua vez, os fatores em relação aos elementos individuais do plano estratégico.
Infelizmente, vários líderes ambientais descobrirão que suas organizações não estão preparadas para suportar tais métricas de controle com as ferramentas de medição. Mas essas ferramentas são necessárias para fornecer os dados qualitativos e quantitativos de que você precisa para analisar e relatar adequadamente os esforços ambientais e de sustentabilidade. Você, portanto, deve desenvolver ferramentas de medição especializadas, seja por um novo projeto do processo comercial, pela implantação de tecnologia de medição e colaboração ou pelo desenvolvimento de ferramentas internas personalizadas.
Sem o apoio da liderança sênior, com relação ao investimento da empresa nessas ferramentas de medição, você provavelmente enfrentará sérias decisões de custo—benefício quanto a fazer das ferramentas de medição corretas uma prioridade às custas de mais força de trabalho.

Analise e relate o impacto ambiental
A coleta dos dados quantitativos e qualitativos permite uma análise aprofundada. Essa análise é fundamental para os líderes que desejam entender o sucesso de suas iniciativas e qual foi o impacto de suas ações na empresa ou em sua linha de negócios.
A paisagem de relatório corporativo voluntário, regulatório, de padronização e legal em constante mudança, com relação ao ambiente, empregou uma pressão cada vez maior nas empresas para que elas lançassem informações detalhadas sobre suas áreas de cobertura ambiental. Ter as ferramentas e os processos necessários em funcionamento para apoiarem o gerenciamento, a medição e a análise facilita a coleta das informações exigidas para relatórios anuais estabelecidos, arquivamentos necessários e relatórios de sustentabilidade corporativos voluntários. É importante que você entenda quais são seus requisitos de relatórios e quais serão eles no futuro, de forma que você possa investir em uma infra-estrutura integrada de gerenciamento, medição, análise e relatório que aumentará suas necessidades comerciais.
A tecnologia para análise e relatório é muito importante para as empresas que procuram surgir como líderes de idéias. O software representa um papel fundamental nesse espaço — especialmente o software usado para gerenciamento ambiental, design de processo, coleta de dados, manipulação de dados, leitura remota, colaboração, visualização e apresentação.
O software comercialmente disponível precisará, às vezes, ser personalizado para aplicações específicas no espaço ambiental. Portanto, um investimento significativo em tecnologia pode ser necessário para permitir uma infra-estrutura integrada de gerenciamento, medição, análise e relatório.

Seja um líder de idéias
A liderança de idéias é algo que todos os líderes ambientais devem aspirar alcançar. Embora existam vários tipos de líderes de idéias (consulte a Figura 2 para obter alguns exemplos), todos eles têm isto em comum: seu conhecimento especializado é derivado não de um título, mas sim de seu registro de agir e liderar a mudança com integridade e franqueza.
Figura 2 Tipos de líderes de idéias
Figura 2 Tipos de líderes de idéias (Clique na imagem para uma visão ampliada)
O ecossistema de sustentabilidade ambiental global conta com líderes de idéias para conduzir mudanças. Com uma rede expansiva de contatos por organizações governamentais, não-governamentais, indústria e organizações defensores dos consumidores, um líder de idéias pode conectar partes influentes para resolver problemas que exigem uma colaboração próxima. Um líder de idéias também está familiarizado com vários dos problemas ambientais em surgimento, que são de preocupação para a comunidade global, e pode erguer a bandeira desses problemas para um público global.
Finalmente, um líder de idéias prevê soluções para problemas importantes que ainda cairão no foco da indústria em geral. O desenvolvimento dessas soluções pode exigir influência e colaboração com outras pessoas — incluindo concorrentes — e pode empurrar a sua própria empresa para mercados ainda não atendidos, mas o resultado é que os líderes de idéias podem executar alterações globais.

Permaneça atual
Essa é uma disciplina em surgimento e existem mudanças regulares no corpo do conhecimento. A credibilidade contínua exigirá uma compreensão erudita das diversas perspectivas científicas, políticas, legais, econômicas, tecnológicas e comerciais promovidas por outros líderes ambientais. Ela também exigirá não necessariamente a conformidade com as opiniões predominantes do dia, mas sim a promoção de perspectivas únicas com base na compreensão especializada da computação e da sustentabilidade ambiental. Essa integridade será o principal diferenciador, dado o número cada vez maior de líderes ambientais (ou pessoas que se autodenominam líderes de idéias) na indústria.
Um líder estabelecido deve ter a segurança em delegar responsabilidades aos subordinados que possuem conhecimento específico sobre um tópico de interesse e em ceder a representantes mais antigos da política ambiental da empresa quando um compromisso exigir. Embora reuniões regulares com seus seniores e relatórios garantam que você mantenha um conhecimento abrangente nos esforços da sua empresa com relação à sustentabilidade ambiental, a chave é saber quando você precisa falar em nome da empresa. Isso requer uma compreensão clara de seus compromissos principais e é um traço que reflete a responsabilidade sincera que você possui de defender as convicções no ambiente que seus públicos interno e externo esperam.

Michael Walsh é gerente de produtos ambiental sênior na Microsoft.
Eliza Walsh é consultor de estratégia de comunicações e anteriormente atendia como especialista em comunicações para a Microsoft na China.


Anotações de campo Compartilhando uma tela dividida
Kentaro Toyama

Estender o acesso ao PC a tantas pessoas quanto possível é a meta louvável da Microsoft Research India, que obteve êxito com o MultiPoint (discutido na edição de maio de 2008 da TechNet Magazine), um programa que permite aos usuários interagir com um PC usando vários mouses.
O Split Screen é outra forma de computação de acesso compartilhado simultâneo concebida pela Microsoft Research India. O programa configura um único PC com dois teclados e dois mouses, e adapta os Serviços de Terminal ao monitor dividido ao meio. Assim, duas pessoas podem compartilhar o monitor, executando instâncias separadas do sistema operacional e o software de sua escolha de forma independente (﻿research.microsoft.com/users/udaip/splitscreen.htm). Por exemplo, uma pessoa pode trabalhar com processamento de texto enquanto outra trabalha em uma planilha.
Para habilitar o Split Screen, usamos três instâncias separadas do Terminal Server executadas no Windows Server® 2003 (agora estamos atualizando para o Windows Server 2008). A primeira é um contêiner que captura e redistribui todos os eventos de mouse e teclado. Essa camada usa o mesmo recurso que o MultiPoint, em que todos os eventos de mouse e teclado são capturados com suas IDs de dispositivo (o Windows® atribui automaticamente IDs exclusivas aos dispositivos USB assim que são conectados; elas não são exclusivas para o dispositivo de hardware, mas sim dentro da instância atual de operação — é o que basta para saber se dois cliques de mouse partem do mesmo mouse ou de mouses diferentes). O contêiner também desenha os cursores de mouse.
Dentro dele, abrimos duas instâncias adicionais do Terminal Server, sendo que cada uma recebe apenas os eventos relevantes para uma tela. No modo padrão, todos os eventos do mouse com a ID x, por exemplo, irão para a tela dividida à esquerda enquanto os da ID y irão para a tela dividida à direita.
O Split Screen usa os Serviços de Terminal para dividir um monitor de PC ao meio
O Split Screen usa os Serviços de Terminal para dividir um monitor de PC ao meio (Clique na imagem para uma visão ampliada)
É importante que a instância de contêiner do Terminal Server exista para que tenhamos controle total de onde os eventos acontecem e para permitirmos recursos mais avançados. Por exemplo, podemos permitir que o cursor à direita passe para a tela à esquerda e simplesmente aponte para a outra janela (talvez para uso de tutorial) ou mesmo interaja com ela.
Nesse caso, parte dos eventos do mouse à direita também alimentaria a tela à esquerda. Também consideramos o uso da tecnologia de virtualização no Windows para executar funções semelhantes; isso pode ser feito, mas achamos que consome muitos recursos.
Os pesquisadores se preocuparam achando que as pessoas poderiam ficar frustradas por ter apenas metade de uma tela. Realizamos estudos em Bangalore, Índia, com a Hope Foundation que ensina a jovens urbanos de baixa renda noções básicas de informática. Ao que parece, a aprendizagem dos alunos com o Split Screen não foi diferente do que se, cada um, tivesse um PC exclusivo para si, pelo menos, para uma matriz limitada de tarefas de treinamento em TI. Também pensamos em problemas ergonômicos, mas eles não aconteceram, mesmo com telas de 14". Acima de tudo, o centro de treinamento em TI ficou feliz em poder acomodar o dobro de alunos com o mesmo número de PCs.
A Microsoft Research India está conversando com os Serviços de Terminal e outros grupos da Microsoft para determinar se o Split Screen é uma tecnologia que vale a pena ser comercializada. Se você acha que usaria o Split Screen, diga-nos em quais cenários você gostaria de empregá-lo. Envie um email para splitscr@microsoft.com.

Kentaro Toyama é diretor administrativo assistente da Divisão de Pesquisa da Microsoft da Índia (research.microsoft.com/india) e pesquisador-chefe do grupo de tecnologias destinadas a mercados emergentes (research.microsoft.com/research/tem), que desenvolve tecnologias para comunidades de baixo poder econômico de todo o mundo.


Segredos do Windows Os dois piores PCs de todos os tempos
Raymond Chen

Em março de 2007 , quando a PC World desenvolveu sua lista dos 10 piores PCs de todos os tempos, as duas primeiras posições da lista me chamaram a atenção porque realmente usávamos ambos no trabalho. Bem, "usávamos" é um termo forte. Talvez eu devesse dizer que testemunhei essas máquinas, uma vez que elas passaram a maior parte das suas vidas produtivas no escritório de um funcionário da Microsoft.
O PC da Barbie, da marca Mattel, ficou classificado como o segundo pior na lista da PC World. Esse computador foi uma vasta melhoria em relação àqueles computadores baratos de cor enfadonha. Em vez disso, ele era um computador barato de cor enfadonha que você decoraria com adesivos cor-de-rosa aplicados ao gabinete, ao monitor, aos alto-falantes — deu para ter uma idéia. Ele também vinha com softwares com tema da Barbie pré-instalados.
Nós adquirimos um como máquina de teste e o coitado do testador que ficou preso a esse computador pelo menos teve o senso de humor de mergulhar de cabeça com entusiasmo para fazer gozação, aplicando todos os adesivos e decorações incluídos para garantir que o computador estivesse instalado "como projetado". Ele foi colocado em uma mesa com uma visão clara da entrada e qualquer pessoa que passasse e visse o desastre da computação em rosa brilhante seria bem-vinda a entrar e brincar com ele.
O PC da Barbie serviu como uma fonte contínua de entretenimento. Sempre que a máquina encontrava problemas e os desenvolvedores precisavam visitar o escritório para depurar a máquina, você sempre poderia contar com uma reação atrasada ou um grito de "legal!" depois que eles se davam conta do tipo de computador no qual precisavam trabalhar. Fiquei sabendo que, em um verão, os estagiários da faculdade instalaram uma cópia do Windows Server® Datacenter Edition no PC da Barbie só para distorcê-lo.
A primeira posição — ou talvez, mais precisamente, a última posição — ficou com o PC da Packard Bell. Ah, as memórias. Apenas um exemplo de como esse computador foi bem projetado: a configuração pronta tinha todos os slots de expansão preenchidos. Talvez eles pensaram: "Nosso computador é tão perfeito que você nunca precisará atualizá-lo!".
De volta à época do projeto Windows® 95, um executivo sênior comprou uma máquina dessas para usar em casa e regularmente instalava a compilação mais recente do Windows 95 nela como parte do esforço de “dogfood”. Como era de se esperar, ele passou por todos os tipos de problemas e teve que ser trazido freqüentemente para ser depurado.
O gerente de desenvolvimento do projeto Windows 95 era um homem inteligente que assumia uma abordagem corajosamente direta para resolver problemas. Por exemplo, para certificar-se de que o Windows 95 era enviado com ampla cobertura para compatibilidade de aplicativos, ele dirigia sua caminhonete até a loja de computadores local e comprava uma cópia de cada programa de PC da loja. Em seguida, ele despejava o software em mesas da lanchonete e convidava os membros da equipe do produto Windows 95 a se aproximarem e pegarem dois softwares — com a condição de que eles tinham que instalar e executar qualquer software que pegassem, bem como bugs de arquivos, com tudo o que não funcionava direito, sem importar se o problema fosse mínimo. Em troca, eles poderiam ficar com o software. A cena na lanchonete era como um mercado de pulgas, com as pessoas procurando nas mesas um bom negócio e perguntando com entusiasmo aos colegas: "O que você pegou?".
Envergonhado com a freqüência com a qual o executivo sênior tinha que trazer seu computador doméstico para ser depurado, o gerente de desenvolvimento do projeto Windows 95 mais uma vez adotou uma abordagem direta. Ele foi até a loja de computadores local e comprou um PC da Packard Bell idêntico ao do executivo sênior.
O fato de que dois desses computadores ainda existiam era ruim o suficiente. Mas o pior foi que o segundo computador foi dado a mim com a tarefa de instalar todas as novas compilações do Windows 95 nele e depurasse qualquer problema que surgisse. Dessa maneira, quando o executivo sênior instalasse a compilação mais recente no seu computador doméstico, ela estaria sem problemas.
Se você acompanhou a história e ligou os pontos, deve ter notado um obstáculo nesse plano. Como não havia nenhum slot de expansão aberto no PC da Packard Bell, não havia lugar para instalar uma placa de adaptador de rede. Eu tive que recorrer a outros meios tortuosos para obter a conectividade de rede. Realmente odiei esse computador.

Raymond Chenpossui um site, The Old New Thing, e escreveu um livro homônimo para tratar do histórico do Windows e da programação Win32. Os objetos do retrovisor dele são mais próximos do que parecem.