Protezione di report e risorse

Data aggiornamento: 14 aprile 2006

È possibile impostare la protezione per singoli report e risorse e controllare quindi i livelli di accesso concessi ai vari utenti per questi elementi. Per impostazione predefinita, solo i membri del gruppo Administrators predefinito possono eseguire report, visualizzare risorse, modificare proprietà ed eliminare elementi. Per tutti gli altri utenti è necessario creare assegnazioni di ruolo che consentano l'accesso a un report o a una risorsa.

Accesso basato sui ruoli a report e risorse

Per concedere l'accesso a report e risorse, è possibile consentire agli utenti di ereditare le assegnazioni di ruolo esistenti da una cartella padre oppure creare una nuova assegnazione di ruolo nell'elemento stesso.

Nella maggior parte dei casi, è probabilmente preferibile utilizzare autorizzazioni ereditate da una cartella padre. L'impostazione della protezione per singoli report e risorse è in genere necessaria solo se si desidera nascondere questi elementi agli utenti che non hanno necessità di conoscerne l'esistenza oppure aumentare il livello di accesso all'elemento o al report. Queste due finalità non si escludono a vicenda. È possibile limitare l'accesso a un report a un numero inferiore di utenti e concedere a tutti, o solo ad alcuni, privilegi aggiuntivi per la gestione del report.

Per ottenere i risultati desiderati, potrebbe essere necessario creare più assegnazioni di ruolo. Si supponga ad esempio che sia necessario rendere accessibile un determinato report agli utenti Ann e Fernando e al gruppo Responsabili risorse umane. Ann e Fernando devono essere in grado di gestire il report, mentre gli utenti del gruppo Responsabili risorse umane devono solo essere autorizzati a eseguirlo. Per gestire queste diverse tipologie di utenti, è necessario creare tre assegnazioni di ruolo distinte: una per assegnare ad Ann il ruolo Gestione contenuto per il report, un'altra per assegnare a Fernando il ruolo Gestione contenuto per il report e la terza per consentire attività di sola lettura al gruppo Responsabili risorse umane.

Quando si imposta la protezione per un report o una risorsa, le impostazioni rimangono associate all'elemento anche se lo si sposta in una nuova posizione. Se, ad esempio, si sposta un report accessibile solo da un numero limitato di utenti, il report rimarrà disponibile solo per tali utenti anche se viene spostato in una cartella con criteri di protezione meno restrittivi.

Riduzione del rischio di attacchi intrusivi nel codice HTML in un documento o in un report pubblicato

In Reporting Services i report e le risorse vengono elaborati con l'identità di protezione dell'utente che sta eseguendo il report. Se il report contiene espressioni, script, elementi del report personalizzati o assembly personalizzati, il codice viene eseguito con le credenziali dell'utente. Se una risorsa è un documento HTML che contiene script, lo script viene eseguito quando l'utente apre il documento nel server di report. La possibilità di eseguire codice o script contenuti in un report è una funzionalità potente che comporta un determinato livello di rischio. Se il codice è dannoso, il server di report e l'utente che sta eseguendo il report sono vulnerabili a un attacco.

Quando si concede l'accesso a report e risorse elaborati in formato HTML, è importante considerare che i report vengono eseguiti con attendibilità totale e pertanto potrebbero venire inviati al client script potenzialmente dannosi. In base alle impostazioni del browser, il codice HTML viene eseguito dal client con il livello di attendibilità impostato nel browser.

È possibile ridurre il rischio di esecuzione di script dannosi adottando le precauzioni seguenti:

• Essere selettivi quando si definiscono gli utenti che possono pubblicare contenuti in un server di report. Poiché esiste la possibilità di pubblicare contenuti dannosi, è necessario limitare gli utenti che possono pubblicare i contenuti a un numero ristretto di utenti trusted.
• Evitare in tutti i server di pubblicazione la pubblicazione di report e risorse provenienti da fonti sconosciute o non attendibili. Se necessario, aprire il file in un editor di testo e verificare se sono presenti URL o script sospetti.

Riduzione del rischio di attacchi intrusivi nel codice SQL in un report con parametri

In qualsiasi report che includa un parametro di tipo String accertarsi di utilizzare un elenco di valori disponibili, anche detto elenco di valori validi, e assicurarsi che ogni utente che esegue il report disponga solo delle autorizzazioni necessarie per visualizzare i dati del report. Quando si definisce un parametro di tipo String, viene visualizzata una casella di testo che può accettare qualsiasi valore. Un elenco di valori disponibili consente di limitare i valori che è possibile immettere. Se un parametro di report è correlato a un parametro di query e non si utilizza un elenco di valori disponibili, un utente potrebbe digitare nella casella di testo sintassi SQL, esponendo il report e il server a un potenziale attacco intrusivo nel codice SQL. Se l'utente dispone di autorizzazioni sufficienti per eseguire la nuova istruzione SQL, è possibile che nel server si verifichino risultati non desiderati.

Se un parametro di report non è correlato a un parametro di query e i valori del parametro sono inclusi nel report, un utente potrebbe digitare nel valore del parametro un URL o la sintassi di un'espressione ed eseguire il rendering del report in formato Excel o HTML. Se il report viene quindi visualizzato da un altro utente che fa clic sul contenuto dei parametri di cui è stato eseguito il rendering, potrebbe venire inavvertitamente eseguito il collegamento o lo script dannoso.

Per ridurre il rischio di esecuzione involontaria di script dannosi, aprire soltanto report visualizzabili provenienti da fonti attendibili.

Per ulteriori informazioni sugli attacchi intrusivi nel codice SQL e su come ridurre i rischi, vedere Protezione integrata e autorizzazioni elevate.

[!NOTA] Nelle versioni precedenti della documentazione è incluso un esempio di creazione di una query dinamica come espressione. Questo tipo di query crea una vulnerabilità agli attacchi intrusivi nel codice SQL e pertanto non è consigliabile.

Protezione di report con contenuto riservato

È consigliabile proteggere i report che contengono informazioni riservate in corrispondenza del livello di accesso ai dati, richiedendo agli utenti di specificare le credenziali per l'accesso ai dati riservati. Per ulteriori informazioni, vedere Impostazione di credenziali e informazioni di connessione. È inoltre possibile proteggere una cartella in modo da renderla inaccessibile agli utenti non autorizzati. Per ulteriori informazioni, vedere Protezione delle cartelle.

Vedere anche

Attività

Procedura: Specifica di credenziali archiviate per un'origine dei dati (Management Studio)

Concetti

Protezione integrata e autorizzazioni elevate
Creazione, modifica ed eliminazione di assegnazioni di ruolo
Ruolo server di pubblicazione
Assegnazioni di ruolo per l'accesso a Generatore report
Gestione delle autorizzazioni e della protezione per Reporting Services
Protezione delle origini dei dati condivise

Altre risorse

Utilizzo di parametri in Reporting Services

Guida in linea e informazioni

Assistenza su SQL Server 2005

Cronologia modifiche