Peer to Peer Magazine

best practices Fine-Tune Security for SharePoint by Sheetal Jain of Prosperoware LLC Microsoft SharePoint can be deployed as your own private cloud, so it is a popular platform for building extranets in professional services firms. Based on a Web interface, a SharePoint extranet portal is a proven, user-friendly solution for managing external business activities and providing useful, transparent interactions with your clients. However, SharePoint was not designed to function as an extranet out-of-the-box, and it could leave you vulnerable to security issues unless you take specific precautions to fine-tune the configuration. Partitioning the Partition While your extranet is secure within the partition that is your private cloud, your firm's challenge is to maintain the security and privacy of individual client data maintained within that partition. There are a number of approaches. The simplest and most obvious approach to maintain security is to create a SharePoint site collection for each client, which establishes a secure database for each client. However, unless you have very few clients, this model is not scalable. Think of the difficulty of maintaining hundreds or thousands of separate databases. There are other alternatives, such as creating a Web application for every customer, but each would require sharing the infrastructure and taking extra steps to secure the data. Rarely will an organization be able to deploy a SharePoint extranet out-of-the-box without leaving themselves open to the accidental exposure of client data. Inadvertent Authorization Bypass Depending on how you design your site hierarchy, you can inadvertently give access to certain aspects of your sites that you'd rather not expose. For example, let's say you want to store a list of courts in a SharePoint list. You would typically store this list at the top-level site and give "read" access to all users so that the list can be used as a lookup for all subsites. Users won't access this list directly, and, even if they do, all they will see is the list of courts, which is public information. However, once users have access to the list, they also have access to other URLs associated with the list. For example, a user can directly access the following pages: • /_layouts/user.aspx • /_layouts/People.aspx • /_layouts/groups.aspx • /_layouts/aclinv.aspx This means, depending on how you configure these pages, you could expose information about other users and groups. What's wrong with this? There are two major risks: • Business Risk — The client user could see information about other client users and potentially see their email addresses as well. • Security Risk — If an attacker gains access to this page, they have the user IDs of everyone who accesses the site. The 18 Peer to Peer

• Cover