Report Builder 2.0 Security

Using Report Builder 2.0 to create reports against data from base tables, views, and stored procedures is easy—perhaps too easy. When users create reports, they can specify raw SQL code to fetch data for a report. Unfortunately, users don’t always write efficient queries.

Before you expose your company’s most precious data to end users, carefully consider which users need the information. Simply blocking access to base tables and granting limited (i.e., read-only) access to specific views and stored procedures might not be enough. Any application that uses Security Support Provider Interface (SSPI) authentication is vulnerable to Trojan attacks. Seemingly innocent queries embedded in reports can contain malicious SQL statements that extend rights to certain users or groups—or worse, actually destroy data. To prevent such security breaches, make sure you have no “super users” who might receive a report that surreptitiously executes SQL statements that are beyond the scope of the query used to return report data. DBAs themselves are the most tempting and obvious targets for these attacks.

To ensure security when deploying Report Builder 2.0, adhere to the following additional recommendations: