SharePoint Security Concepts
Security is a hot topic these days and it is obvious that data needs to be protected. At the same time, an amazing amount of data still remains largely unprotected. Why? If you read this article you might agree with me that it is (still) quite complex to implement security strategies. The good news is though, "Security and SharePoint" doesn't equate to "Mission Impossible".
SharePoint 2007 comes with a lot of important new security concepts and features. A good part of the credit actually goes to the ASP.NET team who delivered many of the concepts which now shine in SharePoint 2007.
Just as with SharePoint administration in general, security setup in SharePoint 2007 is handled by different groups of people at different levels. IT administrators determine which authentication and security policies are in effect, as part of the overall server farm configuration. They also need to configure authorization for the farm's shared services. Separately then, site collection administrators and site owners manage the content authorization. Both are equally important, as the best security measures fail if a content administrator accidentally gives access to the wrong person. Therefore even audits and logs are important to monitor usage, and to detect any loopholes and mistakes in the overall configuration.
One of the big steps forward with security in SharePoint 2007 are "fine grained permissions". That means that permissions can now be set even at the "Item" level, e.g. for individual documents, as well as folders within a library or list. This empowers the existing groups, roles and users concept quite a bit, i.e. it makes it much easier to make exceptions and to give (temporary) access to a single document, without the need the change the overall security rules.
At first glance it might seem odd that SharePoint, by default, installs a collaboration portal with security enabled, instead of an internet site with anonymous access. From a security stand-point this of course makes total sense. Microsoft even went a step further: even when activating anonymous access, by default, access is very much limited. Authoring documents and administration is completely impossible with anonymous access.
Authentication and Encryption
Security is a lot about Authentication and Encryption, and there is no shortage of choices for both with SharePoint 2007. So, planning authentication is a mandatory first step! "Out of the box", SharePoint 2007 supports nine authentication methods. NTLM (short for NT Lan Manager, which is simply the Windows authentication that everyone is familiar with) and Kerberos (also a Windows "standard" authentication) are offered during installation, but I recommend to get started with NTLM, as Kerberos requires "special configuration by the domain administrator", while NTLM works without further hassle.
For many installations, anonymous internet access will also be required. In these cases, forms-based authentication along with SSL encryption is the "de-facto standard" to be set up. In case a multi-server/service set-up is required, both Kerberos and Single Sign-on (SSO) might become necessary.
Let's have a look at Encryption first, as it can be utilized with several of the authentication methods. There are two kinds of connections that might need added security: the communication between servers in the farm (unless they're altogether in an already secure environment), as well as the client-server communication. Microsoft recommends the use of IPSec and SSL. You've probably already used https access on the internet, which uses SSL, but it might be helpful to get a bit more background on the TCP/IP technology stack in general and where IPSec and SSL/TLS fit in. The short version of comparing IPSec with SSL is that IPSec is very good for securing the entire communication between two servers while SSL can be used for much more granular protection on particular applications. As both can have a negative impact on performance it is also advisable to use them selectively rather than entirely.
Configuring SSL usage happens mostly within Internet Information Server and is quite straight-forward.
The IPSec implementation in Windows 2003 supports three different authentication methods: Kerberos V5, Public key certificate and also Preshared key. When using SSL you will most likely have to shell out the fees for a public key with one of the Certification Authorities (not all charge though), with one important exception: if you need SSL access only for your internal collaboration portal you can generate and use your own certificate at no cost with SelfSSL on Windows Server 2003.
SharePoint 2007 "inherits" a lot authentication providers from Windows and IIS (Internet Information Server): Basic, Digest, Certficates, NTLM and Kerberos. ASP.NET adds LDAP, SQL Server, Active Directory, as well as quite a bit of extensibility. A good example of how easy it is (for a programmer!) to extend the authentication provider choice is Willie Rust's blog post on "Using a SharePoint List as an Authentication Provider".
The user interface in the Central Administration for SharePoint offers Windows (which practically means NTLM and Kerberos in most cases), Forms (typically involving Basic in conjunction with SSL encryption) and Web single sign on (which most likely will be used in tandem with an Active Directory solution).
Knowing how often a forms-based authentication is required, it strikes me as odd how difficult it is in SharePoint 2007 to set it up! Microsoft states on one of its technical pages that it "Requires customization of the Web.config file." as a down-side. Sorry guys, that's a too easy way out!
In general I am a big fan of the very active blogging community around SharePoint and ASP.NET There's a lot of useful information available. The following two posts outline quite well how to set up forms-based authentication - and in the Feedback, their issues:
- Andrew Connell on: HOWTO: Configuring a Office SharePoint Server 2007 Publishing Site with Dual Authentication Providers and Anonymous Access
- Dan Attis on: Office SharePoint Server 2007 - Forms Based Authentication (FBA) Walk-through - Part 1
In the end, when you've set it up, you know that it's actually not that hard and not that much work either. So, why Microsoft's technical documentation department can't write up a step by step walk-through on something as important as this, but leaves it to the bloggers, is beyond me (or did I simply not find it?).
NTLM, the standard Windows login procedure and dialog everyone is familiar with on the desktop, has a big advantage: it works without any additional setup effort required. But it also has its limitations, like when using a multi-server farm, where a user needs to authenticate not just against the front-end web servers.
Kerberos is the default in a domain environment, and it has security and performance advantages over NTLM. Invented at MIT, Kerberos has gained wide-spread adoption across operating systems. It is not that easy to set up Kerberos the first time though, as you can take from Martin Kearn's blog.
Configuring Single Sign-on in SharePoint 2007 is a linear five step process. However, setting up SSO in general to start with is a more complicated matter. This time, I leave it to Dave Wollerman's blog post to make the point.
The other thing I don't appreciate is that SharePoint "nudges" you to use Active Directory with Single Sign-on. Don't get me wrong, I don't think AD is not good enough, but it would be nice if Microsoft would also make a it a little easier to plug in other federation services. As it stands, an additional HTTPModule is required to build the bridge. On top of an already complicated setup process it might be an extra step many will opt out on.
Policies for Web Application
Policies are a very powerful means of designing rights for an entire web application. As can be seen from the above screenshot, even the search crawl account is a good example of what they can be used for, as it benefits from an automatically assigned policy to grant read access on the content to be crawled.
Even better examples on how web application policies can help secure a SharePoint solution come to mind when recognizing that they can also be used to deny access to specific user groups at an overall web application level. Joel Oleson has a few more examples on his blog.
Information Management Policies
Contrary to Web Application Policies, Information Management Policies can be used to implement very granular access permissions and to create auditable trails on the data being managed. They are a very powerful overall feature in SharePoint 2007 and include assigning Labels for printing, Auditing rules, Expiration dates on assets, and Bar Codes that can even be used for searching.
Information Management Policies are activated by the IT administrators using the Central Administration and assigned typically by the site collection administrators.
Information Rights Management
The IRM leverages the Windows Rights Management Services (RMS) and is designed to prevent use or distribution without permission. It also is to be set up in the Central Administration.
The new "security trimmed user interface" is another good step forward with SharePoint 2007. It hides all links from users that can't resolve the link anyway.
SharePoint also has a feature to block specific file types in general.
Office 2007 and Internet Explorer implement Trusted Sites, Trusted Locations and Trusted Publishers. Using these features is highly recommended, especially when accessing central document libraries (typically through https access).
SharePoint 2007 also includes an API to plug in Antivirus scan engines. It is probably more likely and common though that customers will use the separate Forefront products to include virus scanning, along with other security measures.
Microsoft Forefront Security for SharePoint & Internet Security and Acceleration Server 2006 (ISA)
Forefront implements virus protection and content filtering. Microsoft claimed in its announcement that Forefront "integrates multiple scan engines from industry-leading vendors and content controls". To my knowledge Symantec offers support for SharePoint today, but MacAfee doesn't. So, you might want to check if your favorite scan engines are supported.
ISA is now part of the Forefront family of products and Microsoft calls it an "integrated edge security gateway". In more simple terms, it is a gateway that includes Firewall and VPN (Virtual Private Network) capabilities, Authentication, as well as Routing and Network Load Balancing functionality. It certainly adds a lot of value as first-line defense to your SharePoint solution.
Writing this post just confirmed my feeling again: SharePoint 2007 has all the bells and whistles required to implement a secure solution. I am especially a huge fan of the Alternate Access Mappings concept that allows to (somewhat) easily implement internet/intranet/extranet access to the same site(s).
In a small-scale collaboration environment, with only one server, setup can be as easy as using the built-in Windows Firewall, the default NTLM authentication and activating SSL certificates.
More likely though you'll need to configure multiple servers, Kerberos, Forms-based authentication, Single Sign-on, ADFS and more. To put it simply, if you're familiar with all these setup procedures, you face a good amount of work. If you're not, you're probably better off asking for help from a system integrator who is familiar with all this. You'll likely save yourself time and frustration. In case you do try, the links provided on this page should be sufficient to make you successful.