Reporting Services Security

When Bill Vaughn and I were researching our book, Hitchhiker's Guide to SQL Server 2000 Reporting Services (2004, Addison-Wesley), we were pleased to discover that Microsoft's developers considered security features in Reporting Services to be crucial. Reporting Services is generally installed with high-level privileges in the heart of your business domain, so you need to be aware of its security implications. The weakest link in security is the people—administrators, developers, or users—you must add to the mix. People can compromise your security configurations through ignorance, laziness, or malice. Here's a quick security checklist for those charged with administering, installing, and configuring Reporting Services.

Disable integrated security on the Report Server. I recommend disabling integrated security on the Report Server for most situations. Reporting Services Service Pack 1 (SP1) introduced a way that you can run a configuration script to disable integrated security in report data sources. Effectively, reports are programs, and when you use integrated security in a report's data source, certain components execute under the privileges of the user who runs the report. However, disabling integrated security significantly hinders the ability of a malicious report author to deploy seemingly innocuous reports that, behind the scenes, can abuse the domain privileges of users who try to run them.

Install an SSL certificate on the Report Server Web site. Installing a Secure Sockets Layer (SSL) certificate will ensure that confidential information (including encrypted credentials) passing to and from the Report Server is more difficult for attackers to sniff, harvest, and abuse. You need to run the IIS Certificate Wizard and present a request either online to a Certificate Server in your domain or offline to a public certification body. If you're unfamiliar with this process, see the MSDN article "Using Secure Sockets Layer (SSL) for SQL Server 2000 Reporting Services" (msdn.microsoft.com/library/en-us/dnsql2k/html/sslsetup.asp), which leads you through it step by step.

Give only one domain user account access to the Report Server database. Use Enterprise Manager to check that the ReportServer and ReportServerTempDB databases permit access to only one domain user (besides the dbo and sysadmin accounts). If the ASPNET or NT AUTHORITYNetwork Service accounts have access, you know that during installation, you enabled access for the service accounts (unfortunately, this is the default). Be aware that anyone who has privileges to deploy an ASP.NET application to the IIS Server hosting Reporting Services can also get at all data and resources on the network simply by using the credentials of any accounts embedded in data sources. To correct this setup, you need to use the rsconfig.exe command-line utility.

Be wary of passing parameters to a Report Server. You can pass parameters for a report to a Report Server in two ways. One way is to put the parameters in the request URL, which users can see and meddle with. Or, you can embed the parameters in an HTML Web form, sending the parameters back to the server through an HTTP POST method in the header. However, even if you use the second technique, when the Report Server receives the POST, it refactors all the parameters when creating the HTTP GET URL strings for any of a report's resources. Consequently, even when you use POST to pass parameter values, users can still right-click any resources a report renders in the browser and inspect their properties to see the HTTP GET URL strings—and thus any values you passed as parameters. If you have parameters that you want to keep confidential, you need to encrypt them or wait until SP2.

Be careful with prompted credentials. This is a corollary of the previous item, but it's worthy of a separate mention. Reports that use prompted credentials encrypt the credentials before passing them to the Report Server as parameters. Unfortunately, those credentials then appear in the HTTP GET request strings of a report's resources and lodge in the user's Web browser cache with URL addresses containing the encrypted credentials. A malicious user can harvest and replay the credentials to do anything that those credentials have permission to do. Microsoft is fixing this problem in SP2.

Embed accounts with only low (read-only) privileges for data sources. Use the principle of assigning an account with the least privilege necessary to do the job. And never embed the administrator's credentials in a data source or custom data source.