Integrated Security and Elevated Permissions
Running a report under an account that has elevated permissions exposes your SQL Server to a security threat if the report query contains malicious Transact-SQL statements (for example, statements that create unauthorized logons, modify or delete data, or introduce erroneous data), and the report is run by a user who has elevated permission on the server that hosts the data source. For example, if an attacker publishes a report that contains a malicious query, the query will be processed under administrator credentials if either of these conditions is present:
- The report data source is configured to use integrated security and the user running the report is logged on as an administrator.
- The report data source is configured to prompt for credentials and the user types his or her administrator credentials to run the report.
Best Practices for Mitigating an Elevation of Privilege Attack
To mitigate this threat, follow one or more of these recommended security practices:
- Use least-privilege accounts to access the external data sources that provide data to a report. You can configure report data sources to always use the stored credentials of a least-privilege account.
- Use shared data sources to specify data source connection information. You can use role assignments on the shared data source to control access to the connection string and to the settings that define how credentials are obtained at run time.
- Use role assignments and workflow processes to ensure that only trustworthy reports are published to a report server. Through role assignments, you can restrict report publication to specific folders, and then require administrators to inspect the RDL file (and the query) of a newly published report before moving it to a final location. Note that Reporting Services does not provide a way to enforce standard operating procedures that you define for your organization. There is no functionality in place to enforce an inspection requirement prior to publication.
- Disable integrated security as a report data source credential option.
The use of integrated security to access external data sources poses a special concern for report users who may not know that their security token is being passed to an external data source (users are not warned in advance of running a report that the report is configured to use integrated security). In addition, users may not have the same concerns about opening a report as they would if they were opening an e-mail attachment from an unknown source. However, the security risks are the same in both scenarios. A malicious query can damage or compromise a server in the same way a malicious script that is exposed through a hyperlink or hidden in an e-mail attachment can damage or compromise a workstation.
Note that if you disable integrated security, any report data source that is currently configured to use integrated security (or subsequently configured to use integrated security after the feature is disabled) will no longer run. The following error is returned when integrated security is not supported on your report server: "This data source is configured to use Windows integrated security but Windows integrated security is disabled for this server."
To disable integrated security, clear the check box for the Enable Windows integrated security for report data sources option in the SQL Server Surface Area Configuration tool. The option is available in the Reporting Services section of the Surface Area Configuration for Features dialog box. You can also use script or code to modify the EnableIntegratedSecurity system property. For more information, see SQL Server Configuration Manager and Report Server System Properties.