Protezione di report e risorse

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.

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 Specifica di credenziale e informazioni sulla connessione per le origini dati del report. È inoltre possibile proteggere una cartella in modo da renderla inaccessibile agli utenti non autorizzati. Per ulteriori informazioni, vedere Protezione delle cartelle.

Vedere anche

Attivitá

Concetti