David Lai's Business Intelligence Blog

In the previous article, we talked about how to implement data masking using data security profiles at the universe level to prevent users from viewing sensitive data.

Data Masking in SAP BusinessObjects

However we can also use business security profiles to limit users from accessing certain objects.

In this article, I’d like to present my thoughts on both methods.

End User Experience

Object level security

When a user is limited from seeing certain objects, they won’t even know that those objects exist, thus there is no room for confusion.

Data Masking

However when data is masked to 0, and a user sees all 0s because they don’t have access to see the real data, they may get confused and start asking unnecessary questions.

Implementation and Robustness

Data Masking

• create appropriate views that masks the appropriate fields
• create data security profiles that point data groups to the corresponding masked views

Object level security

• we only need to create business security profiles with the appropriate object level access
• Now the main show stopper with object level security, is that any reports using restricted objects will not work for users having lower level access. This really limits the ability to create generic re-usable reports since we will need to create multiple report version based on data security. Using data masking, we can still re-use generic reports containing restricted objects, the only difference is that users who have lower level access will see 0s for those special fields.
• In addition, there will be many where Report power users may create reports intended for multiple audiences and not know that a certain object is restricted. This will cause headaches in the future when a report is executed by users who do not have access to certain objects, as they will complain that the report is throwing errors and is thus broken.
• Note: You can set the parameter “AUTO_UPDATE_QUERY” to “Yes” from the universe settings so that an error doesn’t pop up when executing a query that contains denied objects, however any columns that contain the denied object on the report will be removed and any formulas or variables will display an error.

Maintenance

Data Masking

• Maintaining data masking requires that the structure of each view is maintained. For example if you were to add an extra field to the masked table, you would need to modify every view so that it contains the extra field.
• For reports, the good news is that you do not have to maintain multiple reports

Object level security

• Since security is implemented at the object level, we do not need to maintain multiple versions of a table.
• However if we were to create multiple versions of a report, each report would need to be modified if any report changes arise in the future. This would translate to a significant amount of work required.

Conclusion

Data masking isn’t perfect, but in my opinion is a more robust solution to prevent users from seeing sensitive data, as it provides the flexibility of using objects without having to worry about report errors appearing due to object security restrictions.

Feel free to share your opinions/thoughts in the comments below as I would love to hear your opinions.