Once you've established your Microsoft SharePoint security best practices around access controls and permissions, you'll need to drill down into protecting specific groups, such as external users, figure out how you'll authorize users, and the security issues around SharePoint.
First, if you don't think you are going to have to deal with external users -- no extranet, no collaborating partners or contractors -- think again. You almost surely have employees working remotely and connecting to your SharePoint Server through a VPN.
Someone has to take responsibility for managing external user access control and authentication. IT needs to define the authentication policy, which may require putting external users in Active Directory using an established LDAP or perhaps a Web single sign-on (SSO) product. You also need policies controlling how external user accounts are removed when they are no longer needed and who is responsible for closing the loop.
"You have to have a lifecycle process around this," said Gartner Research Inc. vice president and analyst Neil MacDonald. "You need accountability around the ongoing maintenance of external users."
The other assumptions with external users are that you are dealing with unmanaged machines and that sensitive information may be going outside the company. That means you need to have antimalware scanning in place, and some way of simple monitoring for outgoing sensitive data. The latter can be simple pattern matching for credit card numbers, patient health records, customer information, etc. --what MacDonald calls "pragmatic DLP."
You'll need to invest in a SharePoint-compatible antimalware scanning product with some content-filtering capabilities. Think in similar terms of antimalware and content filtering for email. All the major antimalware vendors offer products, including Microsoft Forefront for SharePoint, McAfee PortalShield , Symantec Protection for SharePoint and Trend Micro PortalProtect For Microsoft SharePoint.
MANAGING HIERARCHIAL SHAREPOINT AUTHORIZATION
SharePoint sites have a hierarchical architecture with inherited rights. Rights can be set by site, library or list, folder or object/document.
Set rights at the highest possible levels. For IT at a midmarket company, that means setting permissions at the site level, and letting the site admin handle exceptions at lower levels, MacDonald said. The higher you set permissions, the easier they are to understand and manage, and you reduce the size of access control lists.
Below the site level, modifying privileges can best be handled by a simple folder structure, said Matt Ranlett, principal consultant in Intellinet's worker information practice and a Microsoft MVP for SharePoint Server.
"I work off the rule of thumb to keep all content in one place, if possible," he said. "If you have 1,000 documents, keep them in one library."
So you can set policies for information management and approval workflows based on the content of the libraries -- such as the IT document library on the SharePoint IT site or the HR library on the HR site. If you need to modify security, you can create broadly defined folders, such as an executive-level folder and a general employee folder. SharePoint allows you to hide folders completely from users who don't have access to them.
This is easier to grasp than making exceptions at the site level, and far easier to manage than making exceptions for each document. And, folder security is familiar to most users, who are used to working in file shares.
BEWARE OF SHAREPOINT SECURITY ISSUES
As a last note, SharePoint security is good, but not bulletproof.
First, you can't control access to information at the field level, even though SharePoint stores information in a SQL Server for information storage. The record is the lowest level you can mask information. Take the help desk for example. You want users to be able to see the status of items on an IT task list, but not a technician's notes to his manager. HR records can get a lot more dicey. IT and site admins need to be aware of this.
More important is the omniscience of the server farm admin and the site collection admin. The farm admin doesn't directly have access to site content, but can create himself as a site admin, who does. This is largely a matter of putting a trusted individual in this kind of position and, perhaps, applying the "trust but verify axiom" by monitoring for an admin who gives himself "peeking" privileges.
Since the site admin can view all content on a site, you don't want an IT manager in this role (except for an IT site, of course), especially for sensitive areas, such as an executive-level site.