A Fresh Look at Compliance in SharePoint Server 2007
By Joel Oleson
Sr. Technical Product Manager, Microsoft Office Servers
See other Viewpoint articles.
Between auditing, expiration, information management policies, content types, and reports, I'm pretty jazzed about the compliance features in Microsoft Office SharePoint Server 2007. Whether you’re building a secure intranet library with sensitive documents, a DMZ-based extranet deployment, or a high-scale Internet environment, you’ll be pleased to find SharePoint Server is a rock solid platform with open authentication and membership providers and rich and flexible auditing and compliance capabilities.
There are a few new security-related features in SharePoint Server 2007 that I’d like to highlight:
Secure by default
The out-of-the-box deployment is secure and locked down by default. System administrators trying to access random sites will find they can’t get in. A system administrator who wants to be the farm administrator would need to access the central administration and use the new Web application policies to explicitly allow him or her rights. These powerful policies can be used to temporarily allow read-only permission to legal or give rights to the support organization. These among other configurations and changes can easily be captured and reported by the enhanced logging, auditing, and reporting capabilities in SharePoint Server 2007.
Intranet Information Management Policies
Intranet deployments designed to host sensitive corporate assets often have compliance requirements, life cycle management issues, and legal holds, for example, that can now be handled by the records repository site. Information Management Policies apply to activities such as auditing, expiration, and enforcement of bar codes. Auditing allows the capture of common tasks such as deletions, viewing, moving, copying, and editing, which allows the site or list owner to get detailed reports in Microsoft Office Excel pivot reports right from their site. No longer does the site administrator need to contact IT to get the reports on who accessed, modified, or deleted that key document.
Site permissions management
Site permissions management has been simplified and streamlined. When you create your site, by default it is locked to the creator. To help the site creator to begin working quickly, a screen comes up with three permissions levels: visitors (the read-only group); members, who are the equivalent of contributors (a.k.a. the read/write group); and owners, those that are the site administrators and those responsible for site permissions, rights to create lists, and sites below this site. The simplified people-picker -- integrated with Active Directory service and a powerful search interface for searching across user attributes -- is easily extended to include additional forests.
Extranet security and authentication integration
How does one manage internal access or partner access for multiple partners in a sensitive environment? SharePoint Server 2007 ships with a Lightweight Director Access Protocol (LDAP) provider and has support for .NET pluggable authentication and membership providers. Thus, if your internal users are on Active Directory and you have your users in a database, these users can collaborate on the same content. Your company can now take advantage of investments it has made in third-party directories. Security infrastructure and extranet and corporate security policies can much more easily be integrated. Something that came late in the previous version was designed as fundamental from the beginning. SSL termination, SSL bridging, and secure Web publishing with hardware load balancers or security devices is a key topology. This does require that the path retain the same structure, but you can, for example, abstract hostnames.
Auditing, for example, is configurable at two levels: the site collection and at the list level. The best info I've found on this is on MSDN in Scoping and Updating Policies, but it is very applicable to IT Pros. (Note: Auditing is not turned on across the site collection by default, so be aware that you'll want to turn this on in your site templates.)
As it says on the Scoping and Updating Policies site:
“You can create information management policies at two scope levels:
As a site policy, at the level of the site collection
Site policies reside in the policy collection at the site collection level. An administrator can choose to make the site policy available within a given site collection. When you assign a site policy to a specific content type or list, a copy of the policy, named a policy instance, is copied locally into the content type or list.
As part of a specific content type or list
A policy created within a content type or list applies only to that content type or list. However, you can later export the policy as an XML document and add it to a policy collection or to another content type or list.”
Programmatically a developer could build a feature or solution deployment package by adhering to the policy schema as referenced in MSDN. "To add a site policy to a site collection's policy collection, pass XML that conforms to the Policy Schema as an argument when calling the Add method of the PolicyCollection class."
New to features? You should read the article on installing/uninstalling features, and for developers the sample on how to create a feature. Beyond working with features, it's even better to package the feature into a deployment package. See these great topics: Solutions Overview, Creating a Solution, Deploying a Solution, Upgrading a Solution, Retracting a Solution, Localizing a Solution, Solution Schema. This is what both developers and IT Pros should get excited about. SharePoint Solutions Deployment Packages rock! As an IT Pro/SharePoint Farm admin, I would create an agreement with my developers that they don't send me anything that can't be included in a solution package. It's amazing how much you can put in one. It's even a great way to roll up releases. Imagine incrementing your intranet in full development life-cycle releases such as 1.0, 1.1, 1.2, 2.0, etc.... Quite the change from a barrage of random dlls, web.config changes, customizations to pages, changes to templates, custom site defs, and xmls. Solutions are THE way to go!
I highly recommend reading "2007 Office System Document: Compliance Features in the 2007 Microsoft Office System." This document is a very comprehensive, all-up, Office System view of compliance, from the Document Information Panel (meta data capture in the client) to auditing, content types, Information Rights Management, and more in Office SharePoint Server, among others. This likely is “the doc” you've been looking for. I was impressed with the table "Description of the Products Relevant to Compliance." It nicely lays out the products, which are broken down by feature and by how they relate to compliance. Check out the architecture overview; it may be the first time you've seen the development tools, the client apps, SharePoint Products and Technologies, and Microsoft Exchange Server 2007 on the same diagram in a somewhat technical way. It breaks down the following features:
Auditing and logging
Barcodes and labeling
Information Rights Management
Included are great screenshots of key pages where you can configure auditing, information policies, the reports page, same reports, and what you can get at from what object model (Windows SharePoint Services 3.0 Object Model vs. Windows SharePoint Services 3.0 Admin Object Model). The section on workflows is probably the easiest-to-read, easiest-to-consume discussion of the subject I've seen. The records management piece really simplifies the template, what it is, and what it is used for. There's also a good diagram on portal search extensibility.
In addition, I came across some pretty cool sample code for getting at the logs for items: "SharePoint Server 2007 Code Sample: Item-Level Auditing." According to the Web page, "This code sample shows you how to create an item-level auditing view programmatically in three different ways: using a custom SharePoint list, through the Excel client, and by manipulating the open XML file format to display auditing history using Excel Services on an application page." I've been fairly impressed with simply being able to get at the audit logs on a site collection to see who's deleted what item and if someone happens to change my auditing settings I can see who did it. Reading the XML isn't that tough, and this sample code shows how reading it can be very useful.