Home

Thursday, March 01, 2007

Effective Security Model for SharePoint

Creating an effective, scalable security model and governance plan for a SharePoint implementation is one of the most important and intricate aspects of a SharePoint deployment. Developing a security model usually requires cooperation from from a lot of different people. It requires communication with the business groups for articulating the security requirements of their content, the security people for communicating the policies (such as Sarbanes Oxley), interpreters of these requirements for designing a consistent roles based structure and naming convention (in AD and SharePoint) and IT staff responsible for managing the provisioning and deprovisioning.

Much like the user interface of SharePoint is an open canvas, the security model offers lots of room for creativity, though the efforts are mostly transparent to the end users. When designing a security model, I like to thing about things like what size is the user base, what is the organizational structure of the company, how do the business units interact with each other, what are the security policies in the company, how strict must the security on the content be, is the IT staff willing to accept the responsibilities, etc..

As a rule of thumb (with exceptions of course), I don't create SharePoint users, instead I create SharePoint groups and corresponding AD groups. I like to manage the memberships exclusively in AD. Another thing I try to avoid doing is creating roles based solely on org charts. If an organization is collaborative enough that they are implementing SharePoint, then chances people are interacting outside of their immediate department anyways. Most workspaces and content are custom and besides; departments change and reorganizations happen.

There is a significant effort that goes with keeping the security model in good shape. Limit SharePoint security to roles based groups, keep all of the group membership management in AD, and have a consistent organized pattern and naming convention. When that is all set, spend a some time developing the following two reports:


  • A report that shows Sharepoint Site, SharePoint group names, access levels
  • A report that shows AD groups, member names, and email addresses, nested groups and their members
...then you have an effective security model.

1 comment:

Anonymous said...

Hi Nicholas,
Nice post. Would like hear from you for the following scenario.

For internet MOSS sites , when client does not have AD/LDAP infrastructure but would like to use SQL Membership provider for authentication we need to consider following:
a) Maximum number of cross-site sharepoint groups possible with MOSS 2007
b) Maximum number of users a sharepoint group can hold
c) Currently SharePoint groups does not support nesting so we end up with flat groups ? Is there a way to support groups hierarchy solely with MOSS groups
d) Cross site groups will not be visible outside site collection
e) Does it worthwhile to create groups/roles in SQL server and just look them up in MOSS instead of creating MOSS groups?

Blog Archive

Followers