Designing a Microsoft SharePoint 2010 Infrastructure Vol 1 part 29 ppsx

MCT USE ONLY. STUDENT USE PROHIBITED Designing a Security Plan 5-25 Planning Permission Assignment Key Points There are some key points that you must consider when you plan how to assign permissions for SharePoint sites. Assigning Permissions Consider the following points when you plan how to assign permissions for site collections and sites: • You must decide which groups to use to categorize and manage your users. Groups do not have any permissions until you assign them a permission level for a specific site or for specific site content. When you assign permission levels to SharePoint groups at the site collection level, by default, all sites and site content inherit those permission levels. • You can use either a Windows security group or a SharePoint group, such as Site Owners, Site Members, or Site Visitors. You create and manage SharePoint groups at the site collection level. SharePoint assigns each group a default permission level, but you can customize the permission level for any group. MCT USE ONLY. STUDENT USE PROHIBITED 5-26 Designing a Microsoft® SharePoint® 2010 Infrastructure • A site collection administrator or a user with Manage Permissions privileges can define a SharePoint group, and can use this group to secure objects in a single site collection only. SharePoint groups that you create at the site collection level are available to any subsite or other securable object in the site collection. You must decide whether to use Windows security groups or SharePoint groups. One benefit of using Windows groups is that the group membership is updated when the user account changes. For example, if you delete the user account, the Windows group membership is automatically updated. However, using Windows groups requires Windows or Active Directory administrative permissions. SharePoint administrators can manage SharePoint groups, but may not be able to view the membership of Windows groups, depending on their Windows or Active Directory permissions. To ensure that the structure of your security group is easily extensible and permissions are assigned consistently, use the following strategy: Make the user a member of an Active Directory group. Make that Active Directory group a member of a SharePoint group and then assign permissions to the SharePoint group. Alternatively, if a site collection administrator manages the structure of your security groups, make the user a member of a SharePoint group and then assign permissions to the SharePoint group. Inheriting Permissions Inheriting permissions is the default behavior for child objects within the SharePoint hierarchy and is the easiest way to manage a group of Web sites. However, if a subsite inherits permissions from its parent and the parent site’s permissions change, the subsite’s permissions will also change. This change may compromise security or prevent users from accessing content. If you want to change permissions for the subsite only, you must first stop inheriting permissions from the site and then create fine-grained permissions on the subsite. Creating unique permissions copies the groups, users, and permission levels from the parent site to the subsite and then breaks the inheritance. If you restore inherited permissions, the subsite will inherit its users, groups, and permission levels from the parent site. Checking Effective Permissions Many SharePoint sites give all authenticated users (the NTAUTHORITY\AUTHENTICATED USERS domain group) access to at least MCT USE ONLY. STUDENT USE PROHIBITED Designing a Security Plan 5-27 some site content. If you want more restricted access, you must determine exactly which permissions to give to authenticated users and which site content they can access. SharePoint 2010 uses effective permissions to determine permissions for a user or group on all resources in a site collection. You can now find both the user's directly assigned permissions and the permissions that are assigned to any groups of which the user is a member by using the Check Permissions command. Best Practices When you plan permissions, you must balance ease of administration and performance against the requirement to control access to individual items. If you use fine-grained permissions extensively, you will spend more time managing the permissions, and users may experience slower performance when they try to access site content. Although it is often necessary to apply individual permissions, it is generally recommended that you should avoid this approach if you can provide the same access by using a group. Additional Reading For more information about security planning for sites and content for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200879&clcid=0x409. MCT USE ONLY. STUDENT USE PROHIBITED 5-28 Designing a Microsoft® SharePoint® 2010 Infrastructure Planning Access for Authenticated Users and Anonymous Users Key Points When you design your security plan, you should consider how you can make the most effective use of specialized groups and users. Specifically, you must decide whether to allow access to authenticated users or anonymous users. Authenticated Users If your security plan requires all authenticated users in your domain to have access to a particular site, you should grant access to the site to the Domain Users security group. All members of your domain belong to the Domain Users group. Therefore, you must be cautious when you use this group to assign permissions, especially if you are granting permissions that enable the user to change the content of a site. By granting permissions to the Domain Users group, you may be able to avoid the riskier strategy of enabling anonymous access for the site. Anonymous Access You can enable anonymous access so that users can view pages anonymously. You typically configure anonymous access for publishing and extranet sites such as MCT USE ONLY. STUDENT USE PROHIBITED Designing a Security Plan 5-29 www and partner sites. You can design your SharePoint sites so that most allow for anonymous viewing but require authentication when someone wants to edit the site or browse into a restricted area. You grant anonymous access at the Web application level, and you generally configure it at the time that you create the Web application. It is possible to enable anonymous access later, but it is most convenient to do it while you create the Web application. If you enable anonymous access for the Web application, site administrators can decide whether to: • Grant anonymous access to a site. • Grant anonymous access only to lists and libraries. • Block anonymous access to a site completely. Anonymous access is based on the anonymous user account on the Web server. SharePoint does not create or maintain this account; IIS creates and maintains it. The default name for the anonymous user account is IUSR. Allowing access to a site, or to lists and libraries, grants the View Items permission to the IUSR account. To improve security for sites, lists, or libraries, you should not enable anonymous access. Enabling anonymous access allows users to contribute to lists, discussions, and surveys, which may reduce server disk space and adversely affect other resources. Anonymous access also enables anonymous users to discover potentially sensitive information—such as e-mail addresses—and any content that is posted to lists, libraries, and discussions. Additional Reading For more information about how to choose security groups for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200880&clcid=0x409. MCT USE ONLY. STUDENT USE PROHIBITED 5-30 Designing a Microsoft® SharePoint® 2010 Infrastructure Planning Policies Key Points A Web application is an IIS Web site that acts as a logical container for your site collections. Each Web application can contain thousands of site collections; managing permissions for these site collections individually would quickly become cumbersome, time-consuming, and prone to error. To avoid this scenario, you can use permission policies to help you to mange permissions for Web applications and hence the site collections that they contain. A permission policy is a set of permissions that you can apply to a subset of users or groups in a Web application. Permission Policy A permission policy specifies the permission level that applies to the users and groups that the policy affects. You can specify the following permission levels: • Full Control • Full Read • Deny Write • Deny All MCT USE ONLY. STUDENT USE PROHIBITED Designing a Security Plan 5-31 You can create a permission policy level to customize a set of permissions for a specific group. User Policy You can use a user policy to specify the permissions that apply to a user who accesses a site. If the site is in a Web application that has multiple zones, you can choose the zone where the policy applies. By extending the Web application into multiple zones, you create a separate IIS Web site that serves the same content, but with a unique URL and authentication type. A user policy enables you to add users to a permission policy, edit the policy settings, and delete users from a permission policy. For example, you may want to add users to a permission policy to ensure that all users are accessing content with the same set of permissions. Anonymous Policy The anonymous policy allows you to enable or disable anonymous access for a Web application. If you enable anonymous access for a Web application, site administrators can then grant or deny anonymous access at the site collection, site, or item level. If you disable anonymous access for a Web application, anonymous users cannot access sites in that Web application. Anonymous access is enabled in three places: IIS, the Web application anonymous access policy, and the site collection or site. Question: How do permission policies, user policies, and anonymous policies relate to each other? Additional Reading For more information about how to manage permission policies for a Web application for SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200881&clcid=0x409. MCT USE ONLY. STUDENT USE PROHIBITED 5-32 Designing a Microsoft® SharePoint® 2010 Infrastructure Lesson 4 Planning for SSL When you create a security policy, a priority area to consider is providing encryption between the client and SharePoint 2010. Without this encryption, your data will be vulnerable to interception in transit. Before you design a security plan that requires SSL communication, you must consider the possible performance impact and how to mitigate it. You must also consider some of the common configuration options such as obtaining certificates, identifying which Web applications you must secure, and deciding whether to change port mappings. Objectives After completing this lesson, you will be able to: • Describe the use of SSL in a SharePoint 2010 infrastructure. • List factors to consider when planning for SSL in a SharePoint 2010 infrastructure. MCT USE ONLY. STUDENT USE PROHIBITED Designing a Security Plan 5-33 Why SSL? Key Points In most scenarios, you should use SSL encryption to secure communication between client computers and servers. Secure client-server communication can be particularly important in the following situations: • You provide partners with access to an extranet environment. • Your employees require remote access to data. • You use basic authentication or forms authentication. • You store sensitive or mission-critical data in your SharePoint application. The use of SSL can create performance overheads on both your WFE servers and your client browsers. Therefore, it may not be appropriate to encrypt all client- server communication. However, if SSL encryption creates a performance bottleneck, you can use SSL acceleration devices to alleviate the burden that the encryption algorithms place on the processor. MCT USE ONLY. STUDENT USE PROHIBITED 5-34 Designing a Microsoft® SharePoint® 2010 Infrastructure SSL Planning Factors Key Points You should plan for the implementation of SSL as part of your overall SharePoint security plan. You must determine which of your Web applications require SSL encryption of network traffic. You must also decide whether you will provide certificates via an internal Certificate Authority (CA) or purchase them from an external vendor. Finally, you should consider whether to use standard port mappings for SSL or specify custom port mappings. Web Applications Not all sites and site collections will require SSL encryption. You must determine which sites and site collections require this type of security, such as sites that expose sensitive financial, HR, or research and development data. If you have Web applications for sites that expose sensitive data, you should configure them for SSL. To make this easier, you may be able to group the sites that require SSL into the same Web application, although this will depend on the nature of the sites. You must define your requirements for encryption when you design your security plan for SharePoint 2010. . PROHIBITED 5-26 Designing a Microsoft SharePoint 2 010 Infrastructure • A site collection administrator or a user with Manage Permissions privileges can define a SharePoint group, and can use this. PROHIBITED 5-30 Designing a Microsoft SharePoint 2 010 Infrastructure Planning Policies Key Points A Web application is an IIS Web site that acts as a logical container for your site collections. Each. you to enable or disable anonymous access for a Web application. If you enable anonymous access for a Web application, site administrators can then grant or deny anonymous access at the site