Tuesday, June 24, 2014

SAP BusinessObjects Security - The Wonders of a Top-Down Methodology

By Rick Epstein

Forget the 7 Wonders of the World: these 7 wondrous tips will help you get started with building your own highly effective security model. Taken together, these best practices constitute a "top-down" methodology. That is, starting from these principles, we can easily drill down to enable efficient and effective management of the most granular aspects of SAP BusinessObjects security. They lay the groundwork. As every project manager knows, the more efficiently you prepare upstream, the less thrashing you'll do downstream.

So, here we go:

  1.  Create a structure that will allow you to add all of your users easily and to specify their rights clearly.
  2. Apply No Access to Everyone on all top level folders.
  3. Never break inheritance.
  4. Never use explicit denial of access.
  5. Enforce access rights on users by adding them to groups.
  6. Never apply security individually to users—only to groups.
  7. If you are using Active Directory authentication (with or without Single Sign On), never assign permissions directly on imported AD groups.

Let’s delve into these a little bit more:

1. Create a structure that will allow you to add all of your users easily and to specify their rights clearly;
There are many ways to structure your groups.  I would recommend having the groups mirror the structure of your folders.  In this way, users can inherit rights from parent groups and parent folders.  If you allow inheritance from both parent groups and folders and you haven’t set up one of their permission settings (the folder or group) correctly, a user will inherit unintended permissions.

2. Apply No Access to Everyone on all top level folders;
We’ve discussed the importance of this concept in a previous blog post.  I can’t stress enough how important it is to start with a clean slate.  Set the Everyone group to “No Access” for all top level folders and all applications.  Likewise, make sure that the Administrators group has “Full Control” in all of these areas.

3. Never break inheritance
Never is a strong word.  I was always taught in school that, on a multiple choice question, if one of the answers used the words always or never to not choose that choice as it would likely be wrong.  How true that advice was.  Let’s rephrase this tip by saying that most of the time you shouldn’t break inheritance.  If you follow tip 1 above, then it would be appropriate to break inheritance on each folder when assigning 1 group access to 1 folder and not wanting that to cascade down.  For example, let’s say that we have 3 folders:  A, B, & C.  B is a subfolder of A and C is a subfolder of B.  Likewise, we have 3 groups GroupA, GroupB, and GroupC.  We have arranged these groups hierarchically to inherit from their parent.  GroupB is beneath GroupA and GroupC is beneath GroupB.  We assign GroupA view access on Folder A.  By inheritance, GroupA would be able to have view access on Folders B and C.  Therefore, we would want to remove the inheritance on Folder B for GroupA.

4. Never use explicit denial of access;
In this case, the never is true.  The only circumstance under which you would consider setting an explicit denial is if you had a custom group set up where you wanted to deny its users the ability to do something that was granted by their other group memberships.  For example, I have occasionally created a group that denies a user to export a report’s data.  We assign this group to certain folders. We add users to this group.  When these users access any report in these folders, they are not able to export the report’s data.  The scope for this explicit denial should be viewed with a very narrow and specific focus.

5. Enforce access rights on users by adding them to groups
6. Never apply security individually to users—only to groups
Tips 5 and 6 are flipsides of the same coin. These are 2 simple rules that should make a lot of sense.  Apply security on groups and their access to folders/applications.  By adding users to these groups, the users will inherit the rights of the groups to which they belong.

7. If you are using Active Directory authentication (with or without Single Sign On), never assign permissions directly on imported AD groups
I talked about this in my last post.  The problem with applying security directly on an Active Directory group is that it moves security outside of the BI deployment, creating a very large potential for unintended consequences.

If there is an Active Directory server upgrade, or service pack, or other maintenance, Active Directory communication may be interrupted, and groups can be "reset". While such a reset doesn’t affect the Windows environments, it can have an adverse effect on SAP BusinessObjects Active Directory integration. For example, an Active Directory group mapped in SAP BusinessObjects may become "unreadable" by SAP BusinessObjects. When you re-import or re-map that Active Directory group, you would need to set up all permissions on that group all over again. A far easier and better solution is to make Active Directory groups part of SAP BusinessObjects Enterprise groups and have security assigned on those Enterprise groups only.

Next in the security blogging series: Remediation, or how to find and repair gaping holes in your current security model

Monday, June 23, 2014

Webinar: SAP BusinessObjects Security Management & Impact Analysis for Epic Deployments

When: June 25, 2014, 2pm EDT
Guest Presenter: Rick Epstein, President, ResolvIT Inc.

Healthcare business intelligence has many unique challenges. For healthcare providers, practice management, financial management, and the tracking of "meaningful use" information can be simplified by tight integration of the BI and EMR platforms. However, this integration has serious implications for security management and the safeguarding of electronic Protected Health Information (ePHI).

For organizations using Epic solutions, there is often a recurring need to update SAP BusinessObjects reports when an Epic update is implemented. We will look at ways to perform efficient and effective impact analysis of Epic updates, and to update your SAP BusinessObjects deployment accordingly.

Join security expert Rick Epstein of ResolvIT Inc. and Fred Walther of APOS Systems as they examine issues around SAP BusinessObjects security management and impact analysis for Epic deployments.

Register for this webinar…

Friday, June 13, 2014

2 Easy (Free) Ways to Get More from Your SAP BusinessObjects Deployment

If you're planning upgrades to your BI deployment, or planning your migration to BI 4, you'll first need to take stock of your current deployment's objects, schedules and instances. APOS Insight Elements is an excellent place to start your planning inventory.

If you've already migrated to BI 4, then you know that it was designed with mobile in mind. The APOS BI Mobile app for iPad / iPhone is an excellent, easy, and free way to realize that potential.

Check out both of these products, with our compliments:

2 Easy Ways to Get More from Your SAP BusinessObjects Deployment...

Wednesday, June 11, 2014

Common SAP BusinessObjects Security Mistakes - Miscellaneous

For information on using APOS solutions to help you bolster and manage security, visit our more recent series of security posts.

By Rick Epstein

This post concludes the list of most common security mistakes begun in these earlier posts:
We end our discussion of common SAP BusinessObjects security mistakes a couple of miscellaneous items.


Mistake #8: Allowing too many people to be able to see the SAP BusinessObjects License Key(s)
Allowing all administrators to see license keys is NOT a good practice. Only 1 or 2 people should have rights to see this as well as your company’s purchasing dept.

Mistake #9: Applying security on an Active Directory group directly
The problem with applying security directly on an Active Directory group is that it moves security outside of the BI deployment, creating a very large potential for unintended consequences.
If there is an Active Directory server upgrade, or service pack, or other maintenance, Active Directory communication may be interrupted, and groups may be "reset". While such a reset doesn’t affect the Windows environments, it can have an adverse effect on SAP BusinessObjects Active Directory integration. For example, an Active Directory group mapped in SAP BusinessObjects may become "unreadable" by SAP BusinessObjects. When you re-import or re-map that Active Directory group, you would need to set up all permissions on that group all over again. A far easier and better solution is to make Active Directory groups part of SAP BusinessObjects Enterprise groups and have security assigned on those Enterprise groups only.

Are you aware of other common security mistakes, or do you have questions about what is written here? Use the Comments section for this post, or email me directly at repstein@resolvitinc.com.

In my next post, I'll look at "top-down methodology and best practices."