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:
- Create a structure that will
allow you to add all of your users easily and to specify their rights clearly.
- Apply No Access to Everyone on
all top level folders.
- Never break inheritance.
- Never use explicit denial of
access.
- Enforce access rights on users
by adding them to groups.
- Never apply security individually
to users—only to groups.
- 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
