Distribuzione protetta (System 2003)
Aggiornamento: novembre 2007
Si applica a |
|---|
Le informazioni contenute in questo argomento riguardano solo i progetti Visual Studio Tools per Office e le versioni di Microsoft Office specificati. Tipo di progetto
Versione Microsoft Office
Per ulteriori informazioni, vedere la classe Funzionalità disponibili in base ai tipi di progetto e applicazione. |
Quando si crea una soluzione Visual Studio Tools per Office, i criteri di sicurezza locali vengono aggiornati automaticamente per consentire l'esecuzione del codice nel progetto. Tuttavia, quando si distribuisce la soluzione è necessario aggiornare esplicitamente il criterio di sicurezza in tutti i computer in cui viene utilizzata la soluzione, per autorizzare il codice dell'assembly all'esecuzione e all'accesso al modello a oggetti di Office.
Nel caso di personalizzazioni a livello di documento, se il documento viene distribuito in un percorso di rete, è necessario aggiornare anche i criteri di sicurezza per il documento. Per ulteriori informazioni su come impostare i criteri di sicurezza nei computer degli utenti finali, vedere Distribuzione dei criteri di sicurezza. Per ulteriori informazioni sulle personalizzazioni a livello di documento, vedere Architettura delle personalizzazioni a livello di documento.
Nomi sicuri e certificati
Per distribuire con sicurezza le soluzioni si consiglia di assegnare un nome sicuro agli assembly, firmarli con un certificato Authenticode (x.509) o eseguire entrambe le operazioni per una maggiore protezione e gestibilità. I nomi sicuri e le firme Authenticode garantiscono un livello di protezione elevato, poiché è quasi impossibile riuscire ad alterare il codice senza invalidare il nome sicuro o la firma. Le firme Authenticode comportano ulteriori vantaggi:
È possibile impostare l'indicatore di data e ora delle firme Authenticode.
È possibile revocare i certificati.
Il certificato fornisce l'identità dell'editore.
Per ulteriori informazioni sugli assembly con nome sicuro, vedere Assembly con nomi sicuri e Creazione e utilizzo degli assembly con nome sicuro.
Per ulteriori informazioni sulle firme Authenticode, vedere Distribuzione e firma Authenticode.
Scelta del livello di protezione
È necessario confrontare i vantaggi in termini di sicurezza offerti dall'impostazione di regole rigide con i vantaggi in termini di amministrazione offerti da regole permissive e quindi scegliere il livello di attendibilità più appropriato. Se ad esempio le soluzioni verranno sempre distribuite in un server denominato \\appserver\ e verranno sempre firmate con un certificato aziendale, è possibile impostare una regola che consideri attendibile solo il certificato aziendale caricato su \\appserver\. In questo modo è possibile proteggersi da utenti malintenzionati che potrebbero sottrarre il certificato e pubblicare il codice su Internet, poiché è considerato attendibile solo il codice proveniente da \\appserver\). Tuttavia, se successivamente si decide di archiviare gli assembly in un altro server, sarà necessario aggiornare nuovamente i criteri di sicurezza.
Se non si conosce esattamente il percorso in cui verranno distribuite le soluzioni, è possibile adottare una soluzione meno restrittiva, considerando attendibile il certificato o il nome sicuro del codice situato nel computer locale o nella rete Intranet locale. Se si prevede di distribuire il codice sul Web, è anche possibile utilizzare l'area Siti attendibili nelle opzioni di protezione di Internet Explorer. Non è consigliabile considerare attendibili i certificati provenienti dall'area Internet, dall'area Siti con restrizioni o al primo livello (tutto il codice), a meno che non esista un valido motivo per farlo. In questo caso, prendere le precauzioni appropriate per verificare la sicurezza del codice, anche nel caso in cui pervenisse a utenti malintenzionati. Per ulteriori informazioni, vedere la classe Protezione dall'accesso di codice.
Per informazioni sui possibili rischi, vedere Considerazioni specifiche sulla protezione per le soluzioni Office.
Concessione dell'accesso all'assembly
Una delle opzioni di distribuzione per personalizzazioni a livello di documento consiste nel distribuire il documento in locale a ciascun utente e l'assembly in un percorso di rete. Analogamente, per i componenti aggiuntivi a livello di applicazione è possibile distribuire l'assembly del componente aggiuntivo in un percorso di rete. L'assembly non può essere eseguito in una soluzione Office finché non viene considerato attendibile. Firmare digitalmente l'assembly e concedere l'accesso in scrittura al percorso solo agli amministratori del sistema e a coloro che devono modificare l'assembly. Per ulteriori informazioni sulla protezione dell'assembly prima della distribuzione, vedere Considerazioni sulla protezione degli assembly.
Per impostare criteri a livello di organizzazione necessari per considerare attendibile l'assembly, è possibile utilizzare lo strumento Microsoft .NET Framework 2.0 Configuration o lo strumento Criteri di sicurezza per l'accesso al codice, ovvero Caspol.exe.
Per ulteriori informazioni sullo strumento .NET Framework Configuration, vedere Strumento .NET Framework Configuration (Mscorcfg.msc). Per ulteriori informazioni su Caspol.exe, vedere Strumento criteri di protezione dall'accesso di codice (Caspol.exe) e Configurazione dei criteri di protezione tramite lo Strumento criteri di protezione dall'accesso di codice (Caspol.exe).
Prima di distribuire un assembly nel percorso definitivo o prima di aggiornare un assembly distribuito, esaminare i criteri di sicurezza e determinare il tipo di prova da utilizzare per ridurre al minimo il rischio. Per ulteriori informazioni, vedere la classe Requisiti di sicurezza per l'esecuzione delle soluzioni Office (System 2003).
Protezione di documenti in rete
Nel caso di personalizzazioni a livello di documento, se il documento si trova in un server o in una condivisione di rete, è necessario concedere l'attendibilità totale all'URL del documento. Questa è la soluzione ideale per i modelli o i singoli documenti che possono essere modificati solo da parti attendibili. Assicurarsi che gli utenti non attendibili non dispongano di autorizzazioni per la modifica o la sostituzione del documento presente nella condivisione.
Se l'amministratore desidera consentire agli utenti l'accesso a documenti situati in una condivisione pubblica, ad esempio un portale SharePoint, deve modificare il criterio in modo da includere un nuovo gruppo di codice per i documenti. Il gruppo di codice viene aggiunto alla condizione di appartenenza, che cerca i documenti di Office come evidenza, e consente agli amministratori di prendere decisioni sull'attendibilità, come se fosse necessario aggiungere un gruppo di codice per considerare esplicitamente attendibile l'assembly. Per ulteriori informazioni, vedere la classe Procedura: concedere autorizzazioni per documenti e cartelle di lavoro archiviati in percorsi condivisi (System 2003).
Distribuzione di posta elettronica
Nel caso di personalizzazioni a livello di documento, per impostazione predefinita l'assembly non viene eseguito se il documento viene aperto direttamente da un messaggio di posta elettronica. È tuttavia possibile salvare il documento nel disco rigido locale, quindi aprirlo normalmente. Se nel manifesto di applicazione del documento è specificato il percorso completo di un assembly completamente attendibile, la soluzione verrà eseguita.
È possibile, sebbene non sia consigliabile, consentire l'hosting di codice per i documenti contenuti nella cartella temporanea di Outlook. Questo comporta un rischio medio-basso per la protezione poiché, se un assembly distribuito a cui è stata concessa l'attendibilità totale contiene un punto debole, un utente malintenzionato potrebbe riuscire a sfruttarlo allegando a un messaggio di posta elettronica un documento che fa riferimento a tale assembly e invitando il destinatario ad aprirlo. Se l'attacco riesce, l'aggressore potrebbe, ad esempio, accedere a un sito Intranet protetto utilizzando le credenziali del destinatario. L'assembly deve essere comunque considerato totalmente attendibile, poiché l'autore dell'attacco non può creare un documento e un assembly e indurre l'utente a eseguirlo.
Modifica dei criteri di sicurezza
Se l'amministratore modifica le autorizzazioni per un documento o un assembly, gli utenti devono uscire e quindi riavviare tutte le applicazioni di Office per rendere effettive le modifiche.
A volte il processo applicativo di Office continua a funzionare anche dopo che l'utente è uscito dall'applicazione, impedendo così di rendere effettive le modifiche apportate ai criteri di sicurezza. Verificare in Task Manager che l'applicazione di Office non sia inclusa nell'elenco dei processi attivi.
L'applicazione delle nuove autorizzazioni può essere impedita anche da altre applicazioni che ospitano applicazioni Office. Quando vengono modificati i criteri di sicurezza, è consigliabile che gli utenti escano da tutte le applicazioni che utilizzano Office, in modo autonomo o tramite hosting, incluso Internet Explorer.
Impedire l'esecuzione del codice da parte delle personalizzazioni a livello di documento
Gli amministratori possono utilizzare il Registro di sistema per impedire l'esecuzione delle personalizzazioni a livello di documento in un computer. Quando viene aperto un documento di Word o una cartella di lavoro di Excel contenente estensioni di codice gestito, il runtime di Visual Studio Tools per Office verifica l'esistenza di una voce denominata Disabled in una delle seguenti chiavi del Registro di sistema nel computer.
HKEY_CURRENT_USER\Software\Microsoft\VSTO
HKEY_LOCAL_MACHINE\Software\Microsoft\VSTO
Per impedire l'esecuzione di codice da parte delle personalizzazioni a livello di documento, creare una voce Disabled in una o in entrambe queste chiavi del Registro di sistema e specificare uno dei seguenti tipi di dati e valori per Disabled:
A REG_SZ o REG_EXPAND_SZ impostato su qualsiasi stringa diversa da "0" (zero).
A REG_DWORD impostato su qualunque valore diverso da 0 (zero).
Gli utenti potranno comunque aprire i documenti e apportare modifiche quando le personalizzazioni a livello di documento sono disattivate, ma il codice dell'assembly non verrà eseguito. Per consentire l'esecuzione del codice da parte delle personalizzazioni a livello di documento, impostare entrambe le voci Disabled su 0 o eliminare le voci del Registro di sistema.
Vedere anche
Attività
Procedura: distribuire le soluzioni Office (2003 System)
Procedura: rimuovere estensioni di codice gestito da documenti (System 2003)
Procedura: distribuire soluzioni per l'utilizzo non in linea di documenti (System 2003)
Concetti
Modelli di distribuzione (2003 System)
Distribuzione delle personalizzazioni a livello di documento (2003 System)
Distribuzione di soluzioni Office (System 2003)
Distribuzione di componenti aggiuntivi a livello di applicazione (System 2003)