Proteja e Implante Soluções de Negócio com o Microsoft Visual Studio Tools for Office

Clique aqui para ler todos os artigos desta edição

Protegendo e implantando soluções de negócios no Microsoft Visual Studio Tools for Office

por: Brian A. Randell e Ken Getz

O Microsoft Visual Studio Tools para o Microsoft Office System é uma nova tecnologia que traz os recursos avançados do Visual Studio .NET e do .NET Framework para aplicativos criados para Microsoft Office Word 2003 e Microsoft Office Excel 2003. Desenvolver soluções criadas com essa tecnologia requer que você compreenda como a seguran­ça do runtime é reforçada nos aplicativos gerenciados e como configurar sistemas de usuários para executar suas soluções sem introduzirem falhas na segurança. Este artigo demons­trará como estabelecer confiança, descreverá considerações e permissões de segurança, explicará a função do código confi­ável e a implantação de um assembly seguro.

No artigo da edição de novembro de 2003 da MSDN® Magazine Brasil, mostramos como o Microsoft® Visual Studio® Tools for Microsoft Office System facilita criar soluções docu­ment-centric para Microsoft Excel 2003 e Word 2003 usando código gerenciado. Desde que você começasse do nada e per­mitisse que o New Project Wizard fizesse o trabalho “sujo”, as coisas funcionavam perfeitamente. No entanto, no momen­to em que você movia seu documento e o assembly para um novo diretório ou computador, nada mais funcionava. Para entender por que, você precisa estar familiarizado com o CAS (Code Access Security) do Microsoft .NET Framework. O CAS permite que você tire proveito de um dos recursos mais irresistíveis do Visual Studio Tools for Office, a capacidade de fazer com que um documento consuma um assembly com­partilhado que possa ser atualizado sem que seja necessário implantá-lo em cada desktop. Além disso, você precisará saber como compartilhar seu código com outros desenvolvedores. Você precisará ser um membro do grupo de administradores locais (local Administrators group) ou de um grupo de usuá­rios avançados (Power Users group) para alterar a política de segurança do runtime.

No artigo de novembro de 2003, apontamos algumas ra­zões por que os desenvolvedores deveriam se interessar pelo Visual Studio Tools for Office. Duas delas merecem ser repe­tidas e constituem o foco deste artigo. Em primeiro lugar, os desenvolvedores podem tirar proveito do CAS que é incluído no CLR (common language runtime). Diferentemente das macros Visual Basic® for Applications, o código gerenciado simplesmente não funcionará a não ser que seja explicitamen­te confiável. A política padrão impede que o assembly seja executado e protege usuários contra vírus e outros códigos maliciosos. Antes que os usuários possam carregar um docu­mento com extensões de código gerenciado, o administrador precisará conceder explicitamente confiança total ao assem­bly correspondente ou à sua localização. Segundo, os desen­volvedores que utilizam Visual Studio Tools for Office podem tirar proveito da distribuição no-touch. Os usuários podem receber automaticamente atualizações no aplicativo sem in­tervenção de desenvolvedores ou administradores.

Figura 1 Não é possível encontrar o assembly (Can’t Find Assembly)

É ótimo compartilhar

Mesmo que programe para si próprio, fre­qüentemente você precisa mover uma solução de uma máquina para outra ou mesmo de um dire­tório para outro. A primeira coisa da qual você deve estar a par é que, para fins de depuração (debugging), cada projeto tem informações inseridas no có­digo sobre o local onde o aplicativo host (Excel 2003 ou Word 2003) foi instalado. A segunda questão preocupante envolve a segurança.

Para acompanhar a discussão neste artigo, inicie o Visual Studio .NET 2003 e crie um novo projeto Microsoft Office System. Para nosso teste, criamos um projeto Visual Basic .NET usando uma nova pasta de trabalho Excel 2003 (Excel 2003 workbook). Nomeie seu projeto como VSTOXLVB. Caso não saiba como criar o projeto, consulte nosso artigo na edi­ção de novembro de 2003 da MSDN Magazine Brasil.

Neste ponto, você terá um projeto novo, pronto para ser trabalhado. Se pressionar F5 no Visual Studio, você obte­rá um assembly compilado que será automaticamente car­regado quando o Excel 2003 carregar sua pasta de trabalho (workbook). Fechar o Excel 2003 descarrega o assembly e fecha o documento. Se você compartilhar essa solução com outro desenvolvedor, é possível que ele precise modificar uma configuração do projeto. De volta ao Visual Studio, você pode localizar essa configuração clicando com o botão direito do mouse no projeto da janela Solution Explorer, selecione o fol­der Configuration Properties e, em seguida, o nó Debugging. Na folha de propriedades, você verá a opção “Start external program” selecionada. Na textbox ao lado dela, estará listado o caminho completo para o Excel 2003 em seu computador. Se você tem o Excel 2003 instalado na unidade C: de seu com­putador, mas seu colega de trabalho instalou o programa na unidade D:, será necessário alterar a opção para que ele possa depurar o aplicativo localmente. Agora que o Visual Studio .NET pode encontrar o Excel 2003, você precisa lidar com as implicações relacionadas à segurança.

No seu computador de desenvolvimento, use o Windows® Explorer para copiar o arquivo do documento e o novo assem­bly recém-compilado para outro diretório do computador. Por padrão, o documento host (neste caso, VSTOXLVB.xls) está localizado no mesmo diretório que o arquivo da solução (solution) de seu Visual Studio .NET. O assembly está armaze­nado em dois locais: na pasta bin e na pasta VSTOXLVB_bin, ambas encontradas abaixo da pasta da solução. Copie os dois arquivos para o mesmo novo diretório. Abra o arquivo VS­TOXLVB.xls diretamente do Windows Explorer. O primeiro problema que você verá é que o carregador (loader) não con­seguirá encontrar o assembly, mesmo este estando no mes­mo diretório da pasta de trabalho do Excel 2003 (workbook). Você receberá um erro semelhante ao da caixa de diálogo exi­bida na Figura 1.

Conforme mencionado no artigo de novembro 2003, o documento host foi modificado para que contivesse duas propriedades auxiliares (helper): _AssemblyName0 e  _AssemblyLocation0. As propriedades são usadas pela DLL do carregador do Visual Studio Tools for Office, OTKLOADR.DLL, para localizar o assembly. No Excel 2003, com o docu­mento VSTOXLVB.xls carregado, selecione File | Properties para exibir a caixa de diálogo Document Properties. Na guia Custom, altere a propriedade _AssemblyLocation0 para um ponto, a fim de indicar que o carregador deve procurar o as­sembly dentro da pasta atual. Salve o documento, feche-o e abra-o novamente no Excel 2003. Desta vez, você obterá uma mensagem de erro diferente, como a que segue:

A atual política de segurança do .NET (.NET security policy) não permite que VSTOXLVB seja executado na pasta .\ . Não altere a política de segurança do seu computador. A política de segurança do .NET é controlada pelo administrador ou desenvolvedor que escreveu as macros personalizadas. Você ainda pode editar e salvar o documento. Contate o adminis­trador ou o autor deste documento para auxílio adicional.

Estabelecendo confiança

Por padrão, o carregador do Visual Studio Tools for Office só carrega os assemblies que recebem explicitamente con­fiança total. Se mover o assembly, você o removerá de uma localização confiável. Existem três níveis de confiabilidade disponíveis no Microsoft .NET Framework: total, parcial e não-confiável. A não ser que especificado de outra maneira, o carregador do Visual Studio Tools for Office considera todos os assemblies gerenciados como não-confiáveis. Além disso, ele carrega apenas os assemblies que receberam o nível de confia­bilidade total. O carregador do Visual Studio Tools for Office não suporta cenários de confiança parcial porque a interação com o host (Excel 2003 ou Word 2003) requer interoperabili­dade COM e, desse modo, o CLR não pode verificar se todo o código executado é seguro.

Para conceder confiança, você precisará investigar as ferra­mentas do .NET Framework que possibilitam a criação e o gerenciamento de políticas de segurança. Você pode fazer isso de três maneiras diferentes: por linha de comando, usando CASPOL.EXE; por meio de ferramentas GUI administrativas; ou de forma programática. Nós usamos ferramentas GUI.

Feche o Excel 2003 (e exclua as versões copiadas de seu do­cumento e assembly). Abra o snap-in Configuration MMC do Microsoft .NET Framework 1.1. Entre outras coisas, essa fer­ramenta de configuração lhe permite gerenciar a política de segurança do runtime para código gerenciado em seu com­putador. Iniciando pelo nó Runtime Security Policy, expanda o nó User, depois o nó Code Groups e, por fim, o nó All_Code. No grupo All_Code, encontre o nó Office_Projects. Você verá uma entrada exclusiva para cada documento de cada solu­ção do Excel 2003 ou Word 2003 criada até aqui.

Figura 2 Diretório de teste

A Figura 2 mostra um computador de teste após a criação do exemplo deste artigo.

Essas entradas informam ao carregador qual código é confi­ável e permitem que você escreva, depure e execute seu código no seu computador de desenvolvimento. O código só será exe­cutado se for carregado na localização exata que você especifi­cou ao criar o projeto. Para facilitar as coisas, o Office Project Wizard modifica a política de segurança de seu runtime local e adiciona uma política que concede ao assembly os direitos de que ele necessita para ser executado. Essa etapa só ocorre em computadores de desenvolvimento. Para fazer com que as coisas funcionem nos computadores de seus usuários ou no computador de outro desenvolvedor, você precisará mo­dificar a política de segurança do runtime do computador de destino.

Política, evidência, permissões e grupos de códigos

O runtime do .NET (o CLR) possui uma política de segu­rança bem definida para código gerenciado. A política de se­gurança do runtime define permissões e permite que o CLR tome decisões sobre o que o código tem permissão para fazer. As permissões concedem acesso a recursos (tais como arqui­vos, bancos de dados etc) e permitem que o código execu­te alguma ação (como, por exemplo, chamar componentes COM). As políticas permitem que o CLR seja proativo em proteger seus recursos.

O CLR usa diversos critérios, chamados de evidência, para tomar as decisões sobre permissão. A evidência pode ser a URL a partir do qual o código é carregado, uma criptografia hash baseada no assembly propriamente dito, ou informações sobre o autor do código.

Seja qual for a evidência, o CLR precisa de uma forma para fazer a correspondência com um conjunto de permissões — ou seja, um agrupamento lógico de permissões. Essa veri­ficação é obtida através de grupos de código e de condições de afiliação. Um grupo de código consiste em um agrupamento lógico de código que corresponde a uma condição de usuário especificada, que por sua vez é uma estipulação do que deve ser feito para que um assembly seja afiliado a um grupo de código. Cada grupo de código é associado a um con­junto de permissões específico.

A política de segurança do runtime é dividida em quatro níveis: Enterprise, Machine, User e AppDomain. Todos eles, exceto AppDomain, podem ser gerenciados visualmente por meio do snap-in Configuration MMC do Microsoft .NET Framework 1.1, mostrado na Figura 2. Cada nível da política contém um ou mais grupos de có­digo, aninhados em uma hierarquia. Em tempo de exe­cução, o CLR avalia todas as evidências disponíveis para identificar de quais grupos de código o assembly é mem­bro. Em seguida, ele concede ao assembly as permissões especificadas pelo tipo de afiliação (membership).

As coisas se tornam mais interessantes quando você começa a investigar a maneira como os documentos do Office 2003 que usam extensões de código gerenciado in­corporam esses recursos de segurança. Por padrão, os níveis Enterprise e User contêm apenas um grupo de código cada: All_Code. O grupo All_Code tem uma condição de afiliação de All Code com o conjunto de permissões FullTrust. Todas as políticas interessantes são definidas no nível Machine, que fornece um conjunto de grupos de códigos que restringe o que o código pode fazer com base principalmente nas condi­ções do Zone membership. As zonas usadas como condições de afiliação nos grupos de código padrão mapeiam para as zonas usadas pelo Microsoft Internet Explorer: Internet, Lo­cal Intranet, Trusted sites e Restricted sites. Elas são definidas como Internet, Local Intranet, Trusted Sites e Untrusted Sites, respectivamente, na política de segurança do runtime. Além disso, a Microsoft fornece uma zona My Computer para as unidades de disco rígido locais.

Os níveis de política são avaliados em conjunto entre si. Desse modo, as permissões fornecidas a um assembly são ba­seadas na interseção das condições de afiliação (membership) do assembly. Todos os níveis de política precisam concordar em relação aos direitos que concedem. Se o nível de política Machine nega explicitamente direitos de execução a um có­digo proveniente da Internet, o nível de política Enterprise não pode conceder explicitamente essa permissão. Se exami­nar o nível de política Machine de sua máquina, você verá que todo aquele código executado na zona My Computer roda com confiança total (full trust). No entanto, conforme mostrado anteriormente, quando você copiou seu arquivo .xls e o assembly para um novo diretório, eles não rodaram. Por que não?

Embora existam quarto níveis de política (Enterprise, Machine, User e AppDomain), o carregador do Visual Studio Tools for Office aplica a política AppDomain em tempo de exe­cução. Por exemplo, o Visual Studio Tools for Office não aceita afiliações confiáveis na zona My Computer. Seu assembly pre­cisa fornecer alguma outra evidência que corresponda a um código de grupo que forneça confiança total. O que ocorre é que existem muitos tipos de evidência que você seleciona quando modifica uma política. Você pode escolher dentre as seguintes opções: All Code, Application Directory, Hash, Publisher, Site, Strong Name, URL, Zone e Custom.

Como o carregador do Visual Studio Tools for Office não aceita evidência de zona, você precisa usar alguma outra coi­sa. Pense nisso desta maneira: se você quiser alugar um vídeo em uma locadora e pagar em dinheiro, seu cartão de afiliação seria bom o bastante. Mas se você quisesse comprar 20 DVDs e pagar com cartão de crédito, a locadora exigiria sua carteira de identidade. São dois tipos de evidência, com dois níveis diferentes de confiança.

Na primeira vez que você criar um projeto Visual Studio Tools for Office em seu computador, o assistente adicionará um grupo de código Office_Projects com uma condição de afiliação de All Code para o nível User Policy. Em seguida, para cada solução adicional que você criar no Microsoft Office Project Wizard, o Visual Studio .NET definirá um novo grupo de código abaixo do grupo Office_Projects. O novo grupo é um grupo hierárquico com dois níveis. O primeiro nível usa o caminho completo de seu assembly (excluindo o nome do assembly). O segundo grupo de código usa o caminho com­pleto de seu assembly, incluindo o nome do assembly (confor­me mostrado na Figura 2).

Ambos os grupos usam a condição de afiliação de URL (URL membership), que permite que o código seja executa­do com base em sua localização. O primeiro nível atribui o conjunto de permissões Execute ao grupo de código. O se­gundo nível atribui o conjunto de permissões FullTrust ao grupo de código, que possui uma condição de afiliação para o assembly específico que você criou quando compilou o proje­to. Esse ajuste à política de segurança do runtime permite que você pressione F5 e execute o projeto sem precisar modificar por conta própria as políticas CAS. Ele satisfaz o carregador (loader) do Visual Studio Tools for Office na medida em que fornece evidência adicional — neste caso, a evidência de URL, verificando se seu assembly é confiável para ser carregado em um host do Office 2003.

Você deve se perguntar por que existe segurança em dois níveis dentro do sistema de arquivos. Afinal, se você foi solici­tado a conceder ao assembly direitos de FullTrust para que ele fosse executado, por que a política permite a execução de ou­tro código no mesmo diretório? Existem duas razões. Em pri­meiro lugar, permitir que assemblies satélites que contenham recursos como tabelas de strings localizadas possam ser carre­gadas. Em segundo lugar, permitir que você faça referência a outros assemblies na mesma pasta, de modo que eles possam ao menos ser carregados e executados. Se os assemblies se­parados tentarem fazer qualquer coisa que requeira mais que uma simples execução (tal como acessar um arquivo) e você não tiver concedido permissão para isso (através de um grupo de código), eles falharão. Isso significa que qualquer código que você deseje usar como parte de uma solução Visual Studio Tools for Office (exceto código com o strong name Microsoft ou ECMA) deve atender à condição de afiliação de algum gru­po de código (diferente de My_Computer_Zone) e esse grupo de código deve conceder direitos FullTrust.

Código de confiança

Neste ponto, talvez você já tenha tramado uma solução sim­ples para o problema de mover o código de um local para ou­tro: você poderia atribuir direitos FullTrust usando evidência de URL a toda a sua unidade C:\ e acabar com o problema de uma vez por todas! Mas isso seria realmente uma idéia muito, muito ruim. Imagine, por exemplo, o que aconteceria se você baixasse um assembly de um website que contivesse códigos maliciosos. Como a sua pasta temporary Internet folder está provavelmente em algum lugar de sua unidade C:\, você aca­bou de conceder ao assembly direitos de fazer a maldade para a qual ele foi originalmente criado.

Existem muitas maneiras de atribuir confiança a um código, e o mecanismo que você escolher em seu computador de de­senvolvimento deverá ser mais uma questão de conveniência do que qualquer outra coisa. Quando se trata de instalação, no entanto, você deverá fazer o que for melhor para os usu­ários. Isso exige que você selecione evidências mais seguras, como certificados X.509 ou strong names.

Ao usar certificados ou arquivos de chave, é recomendável como melhor prática que você proteja suas versões. Na hora de publicar o código, deverá haver algum processo out-of-band por meio do qual apenas os membros confiáveis de sua orga­nização possam assinar o código. No caso do desenvolvimen­to, você tem duas opções. A primeira é definir um arquivo de chave com strong name que você use em seu computador. Se você tiver uma equipe trabalhando no projeto, só precisará de um arquivo de chave. O ponto importante é que esse arquivo de chave é usado para assinar código apenas para fins de teste ou desenvolvimento. No caso do release, você assina o código novamente usando um arquivo de chave diferente. A segunda opção é usar delay signing. Quando um assembly usa delay signing em tempo de criação, o espaço é reservado no arquivo PE (portable executable) para a assinatura de strong name, mas a assinatura real é adiada até um estágio posterior.

Você cria arquivos de chave usando o utilitário Strong Name do .NET Framework, sn.exe, fornecido com o .NET Framework SDK e com o Visual Studio .NET. Continuando com o exemplo anterior, abra o Prompt de comando do Visual Studio .NET 2003 e altere para um diretório onde você prefira armazenar o arquivo de chave. Para este exemplo, vamos colo­cá-lo na pasta C:\TestKeys. Nessa pasta, digite “sn -k vsto_dev.snk” e pressione Enter. Observe que todas as chaves usadas pelo utilitário Strong Name fazem distinção entre maiúsculas e minúsculas (case sensitive).

Antes de prosseguir, você deve fazer backup de suas confi­gurações de segurança. Seus arquivos de política Enterprise e Machine são armazenados no diretório Windows Drive:\Windows Directory\Microsoft.NET\Framework\v1.1.4322\CONFIG, em dois arquivos XML: enterprisesec.config e se­curity.config. O arquivo de política de usuário é chamado security.config e está armazenado em um local específico ao usuário. Em nosso computador de teste, executando Windo­ws XP Professional SP1 e conectado como Administrator, o arquivo de política User é armazenado no C:\Documents and Settings\Administrator\Application Data\Microsoft\CLR Se­curity Config\v1.1.4322. Lembre-se sempre de fazer backup desses três arquivos antes de começar a modificar suas confi­gurações de segurança.

Uma vez feito backup desses arquivos, retorne ao .NET Framework 1.1 Configuration snap-in e exclua o grupo de código que lista apenas o caminho para sua solução. Esse pro­cedimento, por sua vez, excluirá o grupo de código-filho do assembly. Certifique-se de que não possa mais executar ou de­purar a solução. Você deve receber a mesma mensagem de erro de política de segurança do .NET descrita anteriormente.

E como você pode executar o aplicativo sem a política baseada em URL? Simples. Você adicionará agora suporte para uso de um strong name como evidência de seu assembly. Retorne ao Visual Studio .NET e abra o arquivo AssemblyInfo.vb. Adicio­ne o seguinte atributo AssemblyKeyFile abaixo do número da versão, de modo que, quando seu assembly for compilado, ele utilize um strong name:

‘ Visual Basic

// C#

[assembly: AssemblyKeyFile(@”c:\testkeys\vsto_dev.snk”)]

Incluímos o código C# para mais abrangência. Se você esti­ver criando uma solução em C#, o arquivo AssemblyInfo.cs já conterá o atributo; você só precisa preencher o caminho.

Recompile a solução e retorne ao .NET Framework 1.1 Con­figuration MMC snap-in. De modo geral, você deseja definir suas políticas no nível do computador. Isso permite que você, como o Administrador local, defina a política que poderá en­tão ser testada por meio de uma conta não administrativa.

Começando pelo nó Runtime Security Policy, expanda o nó Machine, depois o nó Code Groups e, por fim, o nó All_Code. No grupo All_Code, encontre o nó My_Computer_Zone. Cli­que com o botão direito em My_Computer_Zone e selecione New para iniciar o Create Code Group Wizard.

No campo Name, digite “VSTO_Dev”. Caso deseje, preen­cha o campo Description e clique em Next. Na página Choose a Condition Type, escolha Strong Name na combobox Condition type. Escolher uma opção de Strong Name altera a página para que você possa importar a chave pública de seu assembly compilado. Clique em Import e na caixa de diálogo do arquivo exibido, navegue até o subdiretório que contém o assembly assinado. Selecione-o e clique em OK.

Embora esta página lhe ofereça a opção de atribuir con­fiança a qualquer versão desse assembly específico, ou apenas em uma versão específica, você deseja que qualquer código que seja assinado com sua chave de teste seja confiável, então clique em Next. Na página Assign a Permission to the Code Group, verifique se FullTrust está marcado na combobox Use existing permission, clique em Next e, em seguida, clique em Finish na última página. Neste ponto, você deve abrir o documento do Excel 2003 e verificar se ele abre sem erros.

Pelo fato de ter atribuído um strong name ao seu assembly e ter criado uma política de acesso a código que permite que qualquer assembly com esse strong name seja executado, você poderá agora mover os projetos em seu computador sem se preocupar com essas questões de segurança. Se criar um novo projeto, você precisará assiná-lo com o mesmo arquivo de chave usado na criação de sua política. Naturalmente, você pode ter vá­rios grupos de código representando diferentes strong names.

Uma última observação sobre o desenvolvi­mento: ao criar novos projetos, você pode selecionar a opção Security Settings e desmarcar a opção de atua­lização da política de segurança local, a fim de que o assistente não configure uma política baseada em URL que permita que seu projeto seja executado automaticamente (veja a Figura 3). Nesse caso, você pode adicionar o atributo AssemblyKeyFile por conta própria. Se você estiver trabalhando em um am­biente de equipe, será menos trabalhoso se todos usarem o mesmo arquivo de chave, especialmente se você puder criar um script que use CASPOL.EXE para configurar essas con­figurações e, em seguida, distribuir esse script para todos os integrantes da equipe.

Figura 3 Desativando a opção de segurança padrão

Modelos de implantação para usuários

Você sabe como mover o código em seu computador e compartilhá-lo com outros desenvolvedores, mas e seus usu­ários? Como eles farão para localizar seu aplicativo? Existem três maneiras de implantar uma solução criada com o Visual Studio Tools for Office:

• Assembly na rede, documento no computador local

• Assembly e documento no computador local

• Assembly na rede, documento na rede

Todas as três opções requerem alterações na política de segu­rança do runtime local do usuário. Além disso, se o documen­to host for carregado diretamente de um compartilhamento de rede, ele deverá ser explicitamente confiável também. Por fim, não se esqueça de que a instalação de qualquer solução criada com o Visual Studio Tools for Office requer que os se­guintes itens sejam instalados em todos os computadores:

• Microsoft .NET Framework 1.1

• Microsoft Office Word 2003 e/ou Excel 2003

Cada opção de implantação tem suas vantagens e desvan­tagens. As escolhas para a sua solução e para os ajustes de po­líticas  de segurança de runtime podem variar da distribuição do aplicativo em disquetes e da instalação manual destes em cada computador cliente individual à distribuição de arqui­vos em lote (batch) que invocam CASPOL.EXE, ou às distri­buiçõs completas de setups usando arquivos *.msi padrão e objetos do Active Directory® Group Policy. Dito isso, os ad­ministradores de sua rede devem decidir o que funciona melhor para eles.

Opções de instalação para usuário

A instalação do assembly em uma localização compartilha­da (acessada por meio de protocolos HTTP ou de arquivo) é uma opção popular. Depois que os usuários configurarem as políticas de segurança corretamente, eles poderão execu­tar documentos do Excel 2003 ou do Word 2003 e receber a última versão do assembly sem saber que estão recuperando uma nova cópia. Além disso, até mesmo os usuários móveis poderão usar esse recurso, desde que eles executem a solução ao menos uma vez, porque o carregador do Visual Studio Tools for Office (via CLR) copia o assembly para o cache do assembly off-line depois que ele foi baixado para o cache do Internet Explorer. Para trabalhar off-line, o usuário precisa abrir o Internet Explorer e indicar que deseja trabalhar desco­nectado. Se o usuário limpar o cache de download do Internet Explorer, a solução não será carregada.

Modificar a política de segurança do runtime do usuário para que o código baixado seja executado é um pouco mais complicado. Caso esteja usando uma localização intranet (in­dependentemente do protocolo usado para localizar o assem­bly), siga as etapas descritas anteriormente e coloque o grupo de código-filho abaixo do nó LocalIntranet_Zone, em vez de sob o nó My_Computer_Zone.

Naturalmente, você deve usar um strong name de produção (no lugar de uma versão de teste) para seus usuários, como fizemos anteriormente neste artigo. Além de atribuir um strong name ao assembly, você pode querer usar um certificado X.509 (do tipo usado na assinatura Authentico­de) e uma assinatura Publisher como a evidência. Embora o uso de strong names ou de certificados X.509 seja mais seguro porque ambos dependem de assinaturas criptografadas (signifi­cativamente mais difíceis de falsificar do que evidências de Site ou de URL simples), a evidência Publisher forne­ce a vantagem adicional de informar quem criou o código. Em contrapar­tida, os strong names são totalmente anônimos. Somente através de técni­cas out-of-band você será capaz de ve­rificar se um strong name vem de um publisher específico.

Caso o assembly precise ser acessa­do sobre HTTP por meio de um en­dereço (endereço IP ou entrada DNS como msdn.microsoft.com), você precisará aumentar o grupo de código do Internet_Zone do usuário ou criar um novo grupo de código. Embora você possa autorizar a exe­cução de código a partir de qualquer local da Internet com seu strong name (ou assinatura X.509), geralmente é melhor criar um grupo de código especial com uma condição de afiliação que corresponda apenas ao seu site. Isso reduz a possibilidade de ataque para os usuários mal-intencionados.

Em nosso computador de teste, criamos um grupo de có­digo no mesmo nível de My_Computer_Zone. Atribuímos a ele o nome msdn.microsoft.com, definimos sua condição de afiliação (membership) para usar evidência de Site, defini­mos o nome do site como msdn.microsoft.com e definimos o conjunto de permissões como Nothing. Faça a mesma coisa em seu computador, mas substitua msdn.microsoft.com pelo site de sua empresa. Da mesma maneira como adicionou um grupo de código filho à My_Computer_Zone, você desejará criar um grupo-filho abaixo do grupo de código de site cria­do no setup anterior. Use sua assinatura Publisher ou strong name para a condição de afiliação e atribua FullTrust como o conjunto de permissões. A Figura 4 mostra nosso computador de teste configurado para suportar nosso strong name de pro­dução a partir de My_Computer_Zone, LocalIntranet_Zone e msdn.microsoft.com (que usa evidência de Site). Neste exem­plo, escolhemos atualizar o nível de política Machine. Você pode escolher qualquer um dos três níveis, de acordo com suas necessidades.

Se escolher instalar tanto o assembly como o documento nos computadores dos usuários, você precisará atualizar a política local deles. A vantagem de dar ao usuário tanto os documentos como o assembly é que ele não terá problemas relacionados ao uso on-line versus off-line. Dito isto, se pre­cisar implantar uma versão atualizada de seu assembly, você deverá distribuí-la ao computador de cada usuário.

A última opção permite que o usu­ário execute tanto o documento host como o assembly a partir de uma loca­lização de rede. Para executar o assem­bly, você precisará configurar a política de runtime do usuário, conforme dis­cutido anteriormente. Há uma etapa adicional: executar o documento do Office 2003 remotamente requer que você instale uma DLL especial (mso­sec.dll) no Global Assembly Cache do usuário. Uma vez feito isso, crie dois grupos de código personalizados. O grupo pai (superior) é a localização que você deseja tornar confiável usan­do evidência de URL ou Site. O segun­do grupo usa uma condição de afilia­ção personalizada definida no arquivo msosec.xml. Você encontrará detalhes passo a passo sobre essa condição na documentação do Visual Studio Tools for Office. Essas explicações estão além do escopo deste artigo. Quanto terminar as etapas, você po­derá executar tanto o documento como o assembly a partir de um compartilhamento de arquivos ou no servidor Microsoft SharePoint™ Services, por exemplo.

Figura 4 Suportando múltiplas localizações

Segurança é vital

Vale a pena todo esse esforço? Com certeza. Você se lembra da dor e do sofrimento causados pelo vírus Melissa às comu­nidades do Office e do Windows? O Microsoft Office 2003 é uma excelente plataforma para a criação de soluções, mas todo mundo precisa ter cuidado com o próximo Melissa. Ao criar um ambiente que só permita execução de códigos expli­citamente confiáveis, estaremos todos mais bem protegidos. O Visual Studio Tools for Office, juntamente com o Office 2003 e com o .NET Framework 1.1, fornece uma plataforma sólida e mais segura para criação de soluções irresistíveis centradas em documentos baseados em Excel 2003 e Word 2003.

Brian A. Randell é consultor-sênior para a MCW Technologies e instrutor da DevelopMentor. Brian palestra freqüentemente nas conferências da VSLive! e Tech—Ed. É também co-autor do livro Effective Visual Basic (Addison-Wesley, 2001).

Ken Getz (keng@mcwtech.com) é consultor-sênior da MCW Technologies. Ken é co-autor do ASP.NET Developer’s Jumpstart (Addison-Wesley, 2002), Access Developer’s Handbook (Sybex, 2001) e VBA Developer’s Handbook, 2nd Edition (Sybex, 2001).