Back in March I posted “Five Reasons Why Ad Hoc Reporting Won’t Work In Some Organizations“. In that post, I listed some of the major concerns that I hear from potential clients when the subject of ad hoc reporting is broached. We’ve already addressed “Our people aren’t smart enough to create their own reports” and “We need to massage the data first.” Now let’s take a look at a typical concern from a security standpoint.
Data security is typically a really a big deal for organizations, and it SHOULD be. Thankfully, SAP BusinessObjects offers a number of ways to provide security around functionality, content and data. With some careful planning and a well-designed SAP BusinessObjects implementation, you can rest assured knowing that users will have access to only the information that they are supposed to see.
Content-level Security
Managing User Security in the Central Management Console
The easiest way to limit unnecessary information is to simply deny access to that universe (semantic layer), report or dashboard through the Central Management Console. For instance, unless an employee is in the Payroll Department, they shouldn’t have access to any payroll reports, dashboards, etc…
This method will work to restrict content at a high level. There are, however, instances where an end-user should have access to a set of information…but have a restricted view based on their particular role or access level.
For a more granular level, we turn to column-level and row-level security.
Column-level Security
Prior to founding Altek Solutions, I worked for a health insurance company developing a data warehouse using Business Objects. There were only handful of people in the organization that were permitted to see “sensitive” member information, such as a member’s Social Security Number.
The people who had the appropriate security level would see “123-45-6789″ as the SSN on a report, while everyone else would see “xxx-xx-xxxx”. Since this logic was implemented at the universe level, it was automatically applied whether a user was looking at a canned report, a corporate dashboard, or their own ad hoc report.
This approach works great for restricting sensitive columns, such as SSN, salary, margin, etc… as a whole. But sometimes you need to allow a user to see information, but only for a subset of the data. For that, we turn to our third approach: row-level security.
Row-level Security
Through row-level security, you can limit access to a particular segment of the data. For instance, in an extranet you can utilize row-level security to ensure that a customer only sees their own data. And internally, make sure that a salesperson only sees their results, a sales manager only sees results for their particular region, etc…
You can also incorporate security tables (whether standalone or from a ERP or CRM system, etc…) to provide customized security to meet your specific needs. And like Column-level security, since the logic is implemented at the universe level it will be applied no matter which tool is utilized to view the information.
Conclusion
Admittedly, I’ve only briefly touched on the power and versatility that SAP BusinessObjects provides to limit access to information. (We will touch on these three approaches and a few others in more technical detail in some upcoming posts.) Rather, this post is intended to provide a background of some of the approaches that you can take when applying security, and hopefully alleviate some concerns you may have about opening your data to your user base.
With some careful planning, you can develop a security methodology that will empower your users with the information they need to make better decisions – while safeguarding it from others who do not need access.
Related Posts:
- Why Ad Hoc Reporting Won’t Work (part 5): If I Give Them Ad Hoc Access to Data, They’ll Keep Asking For More
- Why Ad Hoc Reporting Won’t Work (part 4): I Pay People in IT to Create Reports
- Why Ad Hoc Reporting Won’t Work (part 1): Our People Aren’t Smart Enough
- Why Ad Hoc Reporting Won’t Work (part 2): We Need to Massage the Data First
- Five Reasons Why Ad Hoc Reporting Won’t Work in Some Organizations
Trackbacks/Pingbacks
[...] [...]