Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

SharePoint 2010 : Securing Information - Securing Sites

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
6/30/2011 3:37:26 PM
It is important for the end users in your organization to learn how to properly configure the security settings at the site level in your deployment. From a product design perspective, your nontechnical end users are the people who were meant to manage sites in SharePoint 2010. Because more and more security and site administration is being pushed to the desktop, it’s important for your users to be trained well in how to administrate security at the site level.

The following sections discuss several security configurations that are applied at the site level.

1. Indexing Site and List Content

Security concerns itself with access to a resource. In SharePoint 2010, security can involve not only preventing access to a resource by a given set of users and/or group; it can also be used to create barriers that make finding the content more difficult. You will find that the Index Site and List Content configurations can be helpful in ensuring that a site and/or list content does not appear in the search results for SharePoint 2010.

To prevent a site from being indexed, navigate to the Site Settings link in your site and click the Search and Offline Availability link to open the Search And Offline Availability page (Srchvis.aspx). As you can see in Figure 1, you select the No option for the Allow This Site To Appear In Search Results configuration to ensure that the entire site’s content is not indexed and will not appear in the search results.


Note:

Use this configuration option carefully, because if you choose not to index the content of a site, users won’t be able to use the local Search feature to find local content.


Figure 1. Search And Offline Availability page


At the list level, you can turn off indexing of individual lists by clicking the List Settings link and then clicking the Advanced Settings link. Among the various configuration options available is the setting to Allow Items From This List (Or Document Library) To Appear In Search Results. You can select either the Yes or No option (Yes is selected by default).

At both the list and the site levels (refer back to Figure 1), you will see the option to allow or deny Offline Client Availability. If you select the No option, the content of the site (or list) cannot be taken offline from the server. Because data breaches can occur when people unwittingly lose laptops or mobile devices while traveling or when they are otherwise not careful with information security when away from the office, disabling the offline capabilities of sensitive information provides another way to secure information in SharePoint 2010.

2. Site Permissions and Permission Inheritance

Site permissions and how permissions work in SharePoint 2010 are somewhat confusing topics, so the following sections simplify permissions for you, clearly illustrating what your users will need to know to successfully administer security in their sites. There are several parts to this discussion; first there is an overview of permission followed by a discussion of permission dependencies. Then you will learn about permission inheritance, followed by security groups, and then there is a discussion of using Active Directory groups in SharePoint.

2.1. Permission Overview

First, it is important to note that SharePoint only performs authorization of accounts to access resources. SharePoint does not perform authentication, which involves the creation of an access token that follows a user everywhere he goes on the network. This access token includes user’s name, the groups to which he belongs, his SID, and all of the SIDs for the groups to which he belongs. SharePoint then uses this information, in concert with the SharePoint specific permissions, to authorize or deny the user’s request for a given resource.

In addition to any Active Directory permissions that might exist for a user, SharePoint has a base level of permissions that are unique to this product and that are assigned to users and group accounts. Before you examine how this all works, you first need to understand what the base permissions are in SharePoint 2010; these are presented for you in Table 1.
Table 1. SharePoint Base Permissions
PERMISSION TYPEPERMISSION NAMEDESCRIPTION
List permissionsManage ListsCreate and delete lists, add or remove columns in a list, and add or remove public views of a list
 Override Check-OutCheck in a document that is checked out to another user
 Add ItemsAdd items to lists and add documents to document libraries
 Edit ItemsEdit items in lists, edit documents in document libraries, and customize Web Part Pages in document libraries
 Delete ItemsDelete items from a list and documents from a document library
 View ItemsView items in lists and documents in document libraries
 Approve ItemsApprove a minor version of a list item or document
 Open ItemsView the source of documents with server-side file handlers
 View VersionsView past versions of a list item or document
 Delete VersionsDelete past versions of a list item or document
 Create AlertsCreate alerts
 View Application PagesView forms, views, and application pages; enumerate lists
Site permissionsManage PermissionsCreate and change permission levels on the website and assign permissions to users and groups
 View Web Analytics DataView reports on website usage
 Create SubsitesCreate subsites such as team sites, Meeting Workspace sites, and Document Workspace sites
 Manage Web SiteGrant the ability to perform all administration tasks for the website as well as manage content
 Add And Customize PagesAdd, change, or delete HTML pages or Web Part Pages and edit the website using a Microsoft SharePoint Foundation–compatible editor
 Apply Themes And BordersApply a theme or borders to the entire website
 Apply Style SheetsApply a style sheet (.CSS file) to the website
 Create GroupsCreate a group of users that can be used anywhere within the site collection
 Browse DirectoriesEnumerate files and folders in a Web site using SharePoint Designer and Web DAV interfaces
 Use Self-Service Site CreationCreate a website using self-service site creation
 View PagesView pages in a website
 Enumerate PermissionsEnumerate permissions on the website, list, folder, document, or list item
 Browse User InformationView information about users of the website
 Manage AlertsManage alerts for all users of the website
 Use Remote InterfacesUse SOAP, Web DAV, the Client Object Model, or SharePoint Designer interfaces to access the website
 Use Client Integration FeaturesUse features which launch client application; without this permission, users will have to work on documents locally and upload their changes
 OpenAllow users to open a website, list, or folder in order to access items inside that container
 Edit Personal User InformationAllow a user to change his or her own user information, such as adding a picture
Personal permissionsManage Personal ViewsCreate, change, and delete personal views of lists
 Add/Remove Personal Web PartsAdd or remove personal Web Parts on a Web Part Page
 Update Personal Web PartsUpdate Web Parts to display personalized information
 No Permissions Are SelectedPlease select at least one permission

Note that these permissions cannot be broken down into more granular permissions. For example, the Add And Customize Pages site level permission includes the ability to add, delete, or change HTML pages or Web Part Pages and edit the website using a compatible SharePoint website editor. But you can’t use this permission to assign someone the ability to add and change pages but not delete them. This permission can’t be broken into smaller, more granular permission sets.

Now, some people might respond to this statement by saying that at the Web application layer, you can explicitly deny portions of this permission by employing the explicit Deny permission, and they would be correct. For example, you could explicitly Deny the Delete permission for a user or group of users, and then even though they might have that permission at the site collection or site level, the permission at the Web application layer would override the local permission and they would be unable to delete documents or list items.

But even at the Web application layer, you can’t break down the permissions to their component parts. So the Add And Customize Pages site level permission cannot be broken down into Add, Delete, or Change permissions—it’s all or nothing.

In SharePoint, these base permissions are grouped into permission levels that are then assigned to users and/or groups directly. Table 2 outlines which permissions are assigned to the more common permission levels that you’ll discover in SharePoint.

Table 2. Permissions Level Assignments for the More Common Permission Levels in SharePoint 2010
PERMISSION TYPEPERMISSION NAMEFULL CONTROLDESIGNCONTRIBUTEREADLIMITED ACCESSAPPROVEMANAGE HIERARCHYRESTRICTED READVIEW ONLY
List permissionsManage Lists      
 Override Check Out     
 Add Items    
 Edit Items    
 Delete Items    
 View Items 
 Approve Items      
 Open Items  
 View Versions  
 Delete Versions    
 Create Alerts  
 View Application Pages 
Site permissionsManage Permissions       
 View Web Analytics Data       
 Create Subsites       
 Manage Web Site       
 Add And Customize Pages      
 Apply Themes And Borders       
 Apply Style Sheets       
 Create Groups        
 Browse Directories    
 Use Self-Service Site Creation   
 View Pages 
 Enumerate Permissions       
 Browse User Information 
 Manage Alerts       
 Use Remote Interfaces 
 Use Client Integration Features  
 Open
 Edit Personal User Information    
Personal permissionsManage Personal Views    
 Add/Remove Personal Web Parts    
 Update Personal Web Parts    

2.2. Permission Dependencies

The assignment of some permissions requires the assignment of other permissions. In other words, there are some permission dependencies that need to be understood if users are to effectively manage permissions and security for their sites. What follows is an outline of the permission dependencies in SharePoint 2010.

The Open permission has no other dependencies. This permission is included in every permission level. If you give only this permission to a user account, that user (in theory) will be able to open a website, list, or library to access the items in that site or list. However, this permission only grants access to the containers. Without additional permissions on the items within the site or container, the user will be denied access to the site or container. The Open permission affects the behavior of documents that have server-side handlers, such as .xls files when Excel Web Renderer is installed. Server-side handlers for a file type can be registered by adding a line to the Serverfiles.sml file in the SharePoint install location on the Web front-end server.

The View Pages permission, which grants the ability to view pages in a website, is dependent only on the Open permission. The combination of these two permissions will still not grant a user access to a site, because the permission to access content within the page or a list still has not been granted.

If you add the View Lists permission, which is dependent on the Open and View Pages permissions being granted, then the combination of these three permissions will grant a user access to a site, its pages, and its lists and the content items in the list. However, the combination of these three permissions is much less than is given in the View Only permission level. For example, if you combine these three permissions into a permission level that allows users to quite literally view—and only view—information, then they will be forced to view this information from the browser (since the ability to use remote interfaces such as SOAP or WebDav is not granted), and they will not be able to create alerts nor will they be able to view versions on the content items. If you have any application pages, under this permission set being discussed here, the user would not be able to view those pages. When viewing documents in a library, the user will see the documents and will be able to view and open them, but as you can see in Figure 2, the user will be able to perform limited actions on the document using the Ribbon after the document is selected. Those actions include

  • E-mail a link to the document

  • Download a copy of the document

  • Use the Send To features

  • View the document’s properties

  • Use the social tagging features

Figure 2. Viewing documents in a library with only the Open, View Pages, and View Items permissions


The View Application Pages permission is dependent only on the Open permissions, and it also requires a View Items permission before the user can access anything in a site or list. The View Application Pages is for form pages and most of the application pages. Specifically, it controls the application pages that inherit from the LayoutsPageBases class. This is the right that, for example, is removed from the Anonymous user when the lockdown feature in turned on, so that Anonymous users cannot open application pages. Other permission dependencies for SharePoint permissions are outlined in Table 3.

Table 3. Permission Dependencies
PERMISSIONDEPENDENCIES
Manage ListsOpen, View Items, and View Pages
Override Check OutOpen, View Items, and View Pages
Add ItemsOpen, View Items, and View Pages
Edit ItemsOpen, View Items, and View Pages
Delete ItemsOpen, View Items, and View Pages
View ItemsOpen and View Pages
Approve ItemsOpen, View Items, View Pages, and Edit Items
Open ItemsOpen, View Items, and View Pages
View VersionsOpen, View Items, View Pages, and Open Items
Delete VersionsOpen, View Items, View Pages, and View Versions
Create AlertsOpen, View Items, and View Pages
View Application PagesOpen and View Items
Manage PermissionsOpen, View Items, View Pages, Open Items, View Versions, Browse Directories, Enumerate Permissions, and Browse User Information
View Web Analytics DataOpen and View Pages
Create SubsitesOpen, View Pages, and Browse User Information
Manage Web SiteOpen, View Items, View Pages, Add And Customize Pages, Browse Directories, Enumerate Permissions, and Browse User Information
Add And Customize PagesOpen, View items, View Pages, and Browse Directories
Apply Themes And BordersOpen and View Pages
Apply Style SheetsOpen and View Pages
Create GroupsOpen, View Pages, and Browse User Information
Browse DirectoriesOpen and View Pages
Use Self-Service Site CreationOpen, View Pages, and Browse User Information
View PagesOpen
Enumerate PermissionsOpen, View Pages, View Items, Open Items, View Versions, Browse Directories, and Browse User Information
Browse User InformationOpen
Manage AlertsOpen, View Pages, View Items, and Create Alerts
Use Remote InterfacesOpen
Use Client Integration FeaturesOpen and Use Remote Interfaces
OpenNone
Edit Personal User InformationOpen and Browse User Information
Manage Personal ViewsOpen, View Pages, and View Items
Add/Remove Personal Web PartsOpen, View Pages, View Items, and Update Personal Web Parts
Update Personal Web PartsOpen, View Pages, and View Items

For the most part, the permission dependencies are sparse, meaning that selecting one permission doesn’t involve selection of a complex set of other permissions. This gives you and your site owners a great deal of flexibility in combining permissions into permission levels that are useful for a given situation. It also means that you can create permission levels that are more “lean” in what is granted to the user. You need not rely on the default permission levels if you want a more secure experience than what comes out of the box. Finally, security teams and compliance officers should be made aware of the robust and effective permissions that can be applied to accomplish a particular task in SharePoint and should have confidence that SharePoint is a secure system when configured properly.


Note:

There are two things that no software company—not Microsoft or Sun or Oracle or Novell or any other company—can guard against when it comes to security. No matter how well any software developers might write security features into their products, the reality is that they cannot—through technology alone—help you guard against an untrustworthy administrator and an unwise administrator. Those charged with securing information should be well trained, so that they can make good security decisions, and they should be trustworthy, so that you know they are not disseminating information to those who should not see it.


The default permission levels that are provided in SharePoint 2010 are there to enable people to be productive and to use the product’s features as designed by the product team. The default groups are not there to ensure you have a highly secure experience. Instead, the groups represent the product team’s assessment of general roles and responsibilities across a broad range of organizations, both in size and industry vertical. This is why, in many scenarios, you’ll want to use the default groups when possible, but you should not be afraid to create new permission levels and assign them as needed to ensure that SharePoint is at the level of security needed for your environment.

Tips for Hardening a SharePoint Implementation

In most organizations, there is a healthy tension between allowing users to utilize a collaborative system like SharePoint and maintaining security at a level that meets organization and compliance requirements. Obviously, the more secure a resource is, the more effort required to access the resource. In a highly collaborative platform like SharePoint, users expect minimal effort to access the resources they need to do their jobs. So the art of hardening your SharePoint implementation involves balancing quick and painless access to resources with ensuring that the information in the farm is secured properly.

Here are some tips that you might consider when it comes to securing your SharePoint deployment.

  • Recognize that not all of your SharePoint deployment will be secured at the same level or by the same people.

  • Realize that some content in SharePoint will be highly secured and other content will be loosely secured.

  • Since nontechnical end users are responsible for securing much of the information in SharePoint, ensure that they are well trained in how to secure their information, including the ability to create new permission levels and assign them appropriately.

Finally, if you need to provide minimum permissions to a site, take the time to look through the permission list and test a minimum set of permissions that are required to perform a particular task. For example, if browser access to content with view-only capabilities is sufficient, then you only need to grant Open, View Pages, and View Items permissions. The process of mapping minimum permission levels to user actions in SharePoint is something you and your users will learn over time and should be considered an iterative process.


2.3. Permission Level Inheritance

The site collection is the security boundary in SharePoint. Permissions within a site collection are inherited from the root site and, by default, all lists and pages inherit the same permission sets. Permissions can be broken at the site or list level so that unique permissions can be set at either level.

Note that for some templates, when the site is created, if a user chooses to use Unique Permissions, the creator is presented with a page (Figure 3) to create new security groups and populate them with user and/or group accounts. The Setup Groups For This Site page (Permsetup.aspx) allows you to create three new groups. But by default, the visitors group is configured to use the parent sites’ Visitors group. The creator will need to select the Create A New Group option to completely sever inheritance from the parent site.

Figure 3. Set Up Groups For This Site page


The permission level inheritance is tied to user and group inheritance in SharePoint 2010. This is a change from SharePoint Server 2007, in which you could inherit or break inheritance for users and group and/or permission levels. When permission inheritance is broken, or if permissions are being assigned explicitly, as is the case for a root site of a site collection, then you’ll see check boxes next to the security groups and users, but not next to the permission levels. Figure 4 illustrates explicit permissions for a workspace that is a subsite in a site collection. Note the check boxes next to the security groups and the reminder in the Ribbon that “This Web Site Has Unique Permissions.”

Figure 4. Explicit permissions where inheritance has been broken


Because this site is not inheriting permissions and it is a subsite in a site collection, there is an icon to Inherit Permissions in the Security Ribbon. If you click this icon and then follow the instructions on the page that displays, you can change the permissions of this site from explicitly set to inherited. Figure 5 illustrates this change.

Figure 5. Site Permissions page with permission inherited


One of the more confusing aspects of inheritance is the inheritance of permission levels. On a subsite that has broken inheritance, you will see a Permissions Level icon in the Security Ribbon. When you select that icon, the Permissions Level page will display. Note that in Figure 6, you can see that you are inheriting permission levels, even though you have broken inheritance for the security groups. You might be tempted to look for a way to stop permission level inheritance, but you won’t be able to do it through the user interface. However, permission level inheritance can be broken through the Object Model using custom code.

Figure 6. The Permissions Level page on a subsite that has broken inheritance


To break permissions between a site and a list, navigate to the list settings, click Permissions For This List, and then click the Stop Inheriting Permissions icon in the Security Ribbon. You can also use this same location to inherit permissions by clicking the Inherit Permissions icon in the Ribbon. These two icons—Stop Inheriting Permissions and Inherit Permissions—are context sensitive and will appear based on whether or not your site or list is inheriting permissions. For the root site in a site collection, that icon position will display a Grant Permissions icon, which you can use to grant permissions to a user or group.

Any time permissions are explicitly applied, you will see an icon labeled Check Permissions. Clicking this icon will present what is known as the “people picker” input box into which you will enter a user or group name and then click Check Now. SharePoint will show you, for the local site, all of the permissions for that user as well as how that user’s permissions were obtained. Figure 7 illustrates the Check Permissions dialog box.

Figure 7. The Check Permissions dialog box opens when you click the Check Now button.


2.4. Groups

Groups are used to assign permission levels to multiple users or Active Directory groups in a single administrative action. SharePoint groups can be populated with other SharePoint groups, individual user accounts, and Active Directory groups. Different site templates (which are really nothing more than pre-built combinations of features) will have different default security groups. Table 4 lists the default groups that install with the more common site templates. Note that for most templates, you will find that only the site owners, site members, and site visitors groups will be created.

Table 4. Site Template and Default Group Matrix
GROUP NAMEPUBLISHING SITETEAM SITEBLANK SITEBLOG SITERECORDS CENTERDOCUMENTS CENTERENTERPRISE WIKIGROUP WORKSTIEVISIO PROCESS REPOSITORYBUSINESS INTELLIGENCE SITE
Approvers        
Designers        
Hierarchy Managers        
Site Owners
Site Members
Site Visitors
Restricted Readers        
Style Resource Readers        
Viewers        
Contributors         
Records Center Web Service Submitters For Records         

The activation of some features will install additional security groups if they don’t exist at the time the feature is activated. For example, a Team Site template, by default, has four groups (refer back to Table 16-5) instantiated when the site is created (assuming it is not inheriting permissions from a parent site). When the SharePoint Server Publishing Infrastructure feature is activated, these additional security groups are created. In fact, this feature essentially “installs” the following security groups (unless they already exist).

  • Approvers

  • Designers

  • Hierarchy Managers

  • Restricted Readers

  • Style Resource Readers

What is interesting is that if you activate and then deactivate this feature, the security groups that were created through the feature activation process will persist past the deactivation process. SharePoint security is built in such a way that after a group is created, you must manually delete it to remove it from the site.

SharePoint groups can be populated with Active Directory users and security groups. You cannot populate SharePoint groups with other SharePoint groups or with Active Directory distribution groups. When a SharePoint group is populated with an Active Directory group, all of the nested Active Directory groups will also be granted permissions to SharePoint through the SharePoint group. The people picker in SharePoint does not enumerate nested groups for the site owner’s consideration when adding an Active Directory group to a SharePoint group. This can represent a security danger because, by default, end users who are managing sites normally do not have access to Active Directory or a way to enumerate group memberships or a nested group chain in Active Directory. Best practice in this case is to purchase a third-party product that will plug into SharePoint and provide the additional security administration tools that end users need to effectively manage security for their sites.


Note:

MORE INFO Two third-party products that will accomplish this task for you are DeliverPoint (Lightening Tools) and ControlPoint (Axeler). Be sure to include one of these tools in your budget when you plan your SharePoint deployment, because these tools are invaluable in security management at the site level.


Permission levels can be applied directly to Active Directory user or group accounts without first adding the users or groups to a SharePoint group. The base SharePoint permissions cannot be applied to either an Active Directory user or group or to a SharePoint group without first being grouped into a permission level. To assign a permission level directly to an Active Directory user or group, click the Site Actions menu and then click Site Permissions. Click the Grant Permissions icon in the Ribbon, select the Grant Users Permission Directly option (Figure 8), and then select the combination of permission levels you want to assign to this user and/or group.

Figure 8. Grant Users Permission Directly page


To grant permissions to Active Directory users and/or groups within a SharePoint group, from the Site Permissions page, click the link of the group you want to populate and then use the people picker to find the users and/or groups you need to assign to the SharePoint group. When you have finished, those users and/or groups will have the SharePoint group’s permissions to the site or list.

2.5. Using Active Directory Groups for SharePoint Security

It is common in IT teams to assume that SharePoint will be secured through the use of Active Directory security groups. Some people think that this method gives the IT department more control over who is being granted permissions in SharePoint as well as that it is easier to use an Active Directory group to assign permissions once instead of having the site owner assign the same permissions (potentially) multiple times through individual account permission assignments.

Except for those sites that have wide audiences, such as the intranet or a divisional portal, however, it is a best practice to allow site owners to populate their SharePoint groups with user accounts and not group accounts.

Other -----------------
- SharePoint 2010 : Securing Information - Securing Site Collections
- WCF and BizTalk 2009 (part 2) - Publishing Your WCF Service from the Command Line & Consuming WCF Services
- WCF and BizTalk 2009 (part 1) - Exploring the Built-in WCF Adapter Transport Support & Using the WCF Service Publishing Wizard
- SQL Server 2008 : Working with Synonyms
- SQL Server 2008 : Working with Views -Partitioned Views, Updateable Views & Indexed Views
- SQL Server 2008 : Post-Installation - Preproduction Tasks
- Microsoft PowerPoint 2010 : Expanding PowerPoint Functionality - Simplifying Tasks with Macros
- Microsoft PowerPoint 2010 : Enhancing a Presentation with VBA & Setting Developer Options
- Windows Server 2008 R2 : Manage Disk Storage - Manage Disk Storage Quotas
- Windows Server 2008 R2 : Work with RAID Volumes - Understand RAID Levels & Implement RAID
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server