programming4us
programming4us
SECURITY

SharePoint 2010 : Planning Your Security Model - Overview of SharePoint Security Elements

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

Securing SharePoint sites consists of granting permissions to people who usually belong to groups and then assigning those permissions to securable objects. Simple, right? We review each of these key security elements, which are shown in Figure 1, in the discussion that follows.

Figure 1. SharePoint security elements


Securable Objects

Securable objects consist of all of the solution elements to which permissions can be applied. For example, you can apply permissions uniquely to a site collection, a subsite or site within a site collection, a list or library, a folder, or an individual item in a list or library. By default, permissions are inherited in your site hierarchy. For example, security permissions for the top-level site are inherited by all subsites unless you explicitly “break” the inheritance. Permissions for the site are inherited in each object (list or library) on the site, and permissions for documents or list items are inherited from the library as shown in Figure 2.

Figure 2. Permissions in SharePoint are “inherited” by default


As a general best practice, you always want to apply security at the “highest” level possible in your solution because it’s easier to manage and maintain security in fewer places. The menu option used in SharePoint to apply unique permissions is Manage Permissions. It’s easiest to understand how security permissions have been applied if permissions are the same for all elements of the site. This is clearly not always possible or practical, but it should be a guiding principle for your security model. Another reason for minimizing security exceptions in SharePoint is that the interface does not easily show you where permissions have been “broken.”

Because there is no visual trigger that highlights a specific item (or list or site) that is secured differently than its peers, it can be difficult to quickly identify or change where item-level security has been applied. For example, if you are the site or list “owner” (with Full Control permissions), the only way to tell if a document has unique permissions is to examine permissions in the context of the document. If you need to update security permissions for individually secured items, you will need to update each item independently. If you are the “help desk” person trying to help an end user navigate to a list or library, you will need to remember that your permissions may be different than the end user’s permissions inside the same list or library, so you may see more or fewer documents than the person you are trying to assist. If you find that you have a security model that contains many item-level exceptions, you may want to consider documenting the exception in the item metadata or using a third-party solution for SharePoint security analysis and management.

Because security permissions are shared in all documents in a document library, if you have permissions to edit one document in a library, you have permissions to edit all documents in that library unless security has been “broken” (managed) for an individual document in the library. By editing we mean the ability to alter or delete those documents. If you store documents in folders, security in the folder is inherited into each document in the folder. This is one reason that you may want to use folders in a document library—to apply shared editing permissions to separate groups of documents and minimize the use of item-level permissions. This is one example of how security has an impact on your user experience and content topology. Introducing folders to manage collective security may solve authorization issues but may introduce an inconsistency in how content is managed (for example, other libraries may group documents by metadata). Consider this when balancing security management and usability.

Security Trimming

Any object that you secure in SharePoint is secure in both a “browse” and “search” scenario. If a document, list, or site has unique permissions, users who do not have access to the object will not see it in lists or search results. This is called security trimming. If an unauthorized user attempts to access this content directly via a URL link, that user will be denied access and prompted for alternate credentials. Security trimming also impacts search results. If two different users execute the same exact search, they may see different results based on their permissions. Security does not affect the relevancy of results; only the number of items that are returned.

Security Exceptions

While not technically part of SharePoint, Information Rights Management (IRM) offers another way to secure items stored in SharePoint. Microsoft IRM allows users to create a persistent set of access controls that live with the content itself rather than the location where the item is stored. IRM services can be used, for example, to protect an individual item from being downloaded or printed. When enabled, IRM security takes precedence in a list or library. For example, if an authorized user opens a rights-managed document from a document library where the IRM protection does not allow documents to be e-mailed, the user would not be able to send that document to another user, even if that person also has access to the SharePoint library. Instead, the person would have to go to the library and download the document directly. For more information about IRM and SharePoint 2010, refer to http://msdn.microsoft.com/en-us/library/ms458245(office.14).aspx.

There are several objects in SharePoint that cannot be secured. These include views, Audiences, Web Parts, and list Columns. Be sure to consider the following implications about which objects can be secured and how security is inherited:

  • Because you cannot secure an individual view of a document library, you cannot use unique views to “get around” the fact that you cannot secure an individual Column in a list. For example, you may want to have a Column in a list that shows financial numbers that you don’t want all users to see. You cannot secure the financial Columns using Manage Permissions or secure a view that doesn’t display the financial Columns. In this scenario, you should consider using an alternate means of sharing the sensitive data. For example, one approach might be to use Excel to store the information and secure the Column in Excel. You can then use Excel services to display the information in a SharePoint Web Part. Another approach would be to show the protected data in a separate list, using an event handler to keep the two lists synchronized.

  • You cannot secure a Web Part, but you can use an Audience to target a Web Part so that it only shows up to users who “belong” to that Audience. (Note that the content displayed in a Web Part is always secure, but security cannot be applied to the Web Part itself.) Targeting a Web Part using an Audience does not secure the content displayed in the Web Part—you must secure the object displayed in the Web Part by managing permissions on the content. This is an important distinction. Audiences are used to “personalize” presentation and effectively manage screen real estate with relevant content. Use Audience targeting to feature information, not to protect it.

People and Groups

In the context of SharePoint, “people” are individual users who need access to a SharePoint site and can be defined individually or as a member of a group. A group is a named collection of people (users) in SharePoint.

While individual people can be granted permissions inside of SharePoint, it is generally more desirable to first add that person to a group and then grant permissions to the group. That way, new users can be added in one place, the SharePoint or Active Directory Group, and they will automatically get all the permissions associated with that group. This methodology is also helpful in two other ways: 1) it is easier to replicate security (for example, our new resource should have the same access as Mary) and 2) it reduces the amount of legacy security that accumulates over time (Tom has left the company but his name is still associated with a collection of sites across our environment).

In SharePoint, there are two types of groups that you will work with:

  • A Domain Group is created outside SharePoint in Active Directory.[1] A Domain Group (also called an Active Directory or AD Group) is defined for the entire enterprise and can be used in any site collection in SharePoint or to manage access for other applications used by your organization. Domain Groups are generally created by a security administrator in your IT group, but some organizations allow business teams to request the creation of a new Domain Group that they can manage themselves. Domain Groups are most often created to represent persistent roles or geographic groups of people inside your organization. If you can, you should take advantage of existing, automatically maintained Domain Groups to assign permissions for your site. For example, if there is already a Domain Group for Managers and you have content or sites that are for Managers only, you should use this existing group in your site. When new managers are added or if someone is no longer a manager, you will not need to worry about (or be responsible for) adding or deleting them from the group. If your organization allows you to create Domain Groups that are not automatically populated, you may have to manage “comings and goings,” but you will still only need to do so in one place. It is not always possible or practical to have an Active Directory group for individual sites in SharePoint. This is especially true if you are creating highly granular, low membership groups. You should not clutter AD with SharePoint-specific groups. You should also avoid creating AD groups that cannot be repurposed (that is, used in multiple security applications in and out of SharePoint). In these instances, you are better served leveraging SharePoint security groups.

    [1] Active Directory is the Microsoft directory service used to manage access to a network and many applications including SharePoint. Active Directory includes profile information about the employee such as name and e-mail address. Individual entries in Active Directory are combined into Active Directory Groups.

  • A SharePoint Group can be defined by a Site Collection Administrator or a user with Manage Permissions privileges and can be used to secure objects within a single site collection only. Groups created in SharePoint for one site collection can only be used within that individual site collection and must be separately created and maintained if needed in another site collection. All SharePoint Groups are created at the site collection level and are available to any subsite or other securable object in the site collection.

SharePoint Groups can include Active Directory Groups and/or individual users. However, SharePoint Groups cannot include other SharePoint Groups. There are two types of SharePoint Groups: Default Groups and Custom Groups. The primary advantage of SharePoint Groups is in situations when you chose to deviate from the inherited security of a parent site and assign unique permissions to a site. In this case, SharePoint will create the appropriate groups for Owners, Members, and Visitors, and the administrator can manage security by assigning membership for these groups.

Figure 3 summarizes the different types of security groups in SharePoint and describes the characteristics of each group.

Figure 3. SharePoint Security Groups


Default SharePoint Groups

SharePoint provides several default SharePoint Groups for team sites as shown in Table 1. Each of these SharePoint Groups is associated with a default permission level.

Table 1. SharePoint Groups and Default Permission Levels for Team Sites
Group NameDefault Permission Level
OwnersAssigned Full Control permission level for [Site Name]. Generally, there will be a small number of users in this group.
DesignersAssigned Design permission level for [Site Name]. You might use this group to give users permissions to design the structure of the site without giving them permission to assign security or create subsites. In practice, we don’t find this default group used very often.
MembersAssigned Contribute permission level for [Site Name]. More users will be in this group. For team sites, it’s likely that all eam members will also be included in the site’s Members group.
VisitorsAssigned Read permission level for [Site Name]. Generally, the largest number of users will be in this group.
ViewersAssigned View permission level for [Site Name].

Additional default security groups are created if you use templates other than the Team Site template in SharePoint or if you activate publishing features for a site. Table 2 shows the additional default SharePoint Groups provided in sites created with the Publishing template or when publishing features are enabled. You may enable publishing features for your site but decide that you do not need any of these security groups. If that is the case, you can leave these groups with no members. In most cases, we discourage the deletion of any default security groups as requirements may change and these groups may be brought to bear further in a site’s evolution.

Table 2. SharePoint Groups and Default Permission Levels for Publishing Sites
Group NameDefault Permission Level
Restricted ReadersAssigned Restricted Read permission level for [Site Name]. This group is rarely used and is most often leveraged when users should have a very limited visibility into presentation page content only.
Style Resource ReadersAssigned permissions that allow the member to have read access to the Master Page Gallery and Restricted Read to the Style Library. This group is used for design team members who may want to see associated styling elements.
Quick Deploy UsersAssigned permissions that allow the user to contribute to the Quick Deploy Items library plus Limited Access to the rest of the site.
ApproversAssigned Approve permission level for [Site Name]. This group is used for content publishing purposes. Members have the authority to see, validate, publish, or reject/ propose content changes prior to public consumption.
Hierarchy ManagersAssigned Manage Hierarchy permission level for [Site Name].

In addition, SharePoint includes several special users and groups for administering SharePoint sites:

  • Site Collection Administrators have an “all-access pass” to every element of content and all site permissions. In addition, they are recorded as the contact for the site collection and can audit site content, enable site collection features, and monitor site and search usage. You cannot hide content from a Site Collection Administrator, so if you have content that needs to be visible only to members of the executive committee, you will need to designate a member of the executive committee as the Site Collection Administrator. You need to designate individual people, not a group, as Site Collection Administrators, with the ideal number being more than one, but no more than a handful of users. It is recommended that Site Collection Administrators (or any administrator) be named users and not service accounts. Using service accounts eliminates auditing capabilities as you can’t track changes to specific resources.

  • Farm Administrators control which users can manage settings for the server farm. By default, Farm Administrators do not have access to site content, though they can take ownership of a site if they want to view content. This group is used only in Central Administration; you won’t see this group in any individual site collection.

  • Administrators have the same privileges as Farm Administrators, but they can also install new products and applications, deploy Web Parts to the entire farm, create new Web applications, and start services (such as a search crawl). This group does not have access to site content by default and is not visible in an individual site collection.

Custom SharePoint Groups

The out-of-the-box security groups in SharePoint are essentially a combination of “role” and “permissions.” Also, the SharePoint model is inclusive and not exclusive. That is, you cannot define activities that users or groups are not allowed to perform. For example, the Members group has the Contribute permission level by default, so people often associate the Members group with Contribute permissions, even though this doesn’t have to be the case. There may be situations where you have different groups of people who need different access permissions to various objects in your solution, and it may not be possible or practical to create an Active Directory group for them. While you can add multiple Active Directory Groups to a SharePoint Group, you cannot “nest” SharePoint Groups. If the same group of people need different permissions in different sites (for example, Contribute in one and Read in another) and you can’t use an Active Directory Group, you will want to create a custom SharePoint Group. You may also want to create a custom group because the terms Visitors, Members, and Owners just don’t make sense in your organization. As a best practice, when you create a custom SharePoint Group, choose a name for the group to reflect the people in the group and their collective “role” in the organization, not their security permissions. This is hard to explain without an example. As a general practice, you always want to give a person or group the least amount of permissions to effectively achieve the required business functionality ... and no more. This certainly creates additional administrative overhead, but it is a core tenet of ensuring the stability and security of a SharePoint environment.

Permissions

Individual permissions (such as view items, open items, edit items, and delete items) are grouped together into permission “levels,” such as Contribute, which allow users to perform specific actions. You can also create custom permission levels, but when you do this you may make managing a site more difficult, and you will also make it more difficult to audit your site’s security. That doesn’t mean that you shouldn’t create custom permission levels, but it does mean that you should carefully document all the permissions levels that you create for your site. In addition, you should validate any custom security groups as being essential. One we have seen often is a custom security group that offers content contribution but does not have deletion rights. (Note that the Recycle Bin may minimize the need for this type of customization.) Individual permissions are assigned to one or more permission levels, which are in turn assigned to individual users (if you absolutely have to) and/or SharePoint Groups (the preferred approach).

The out-of-the-box or default permission levels for team sites include

  • Full Control provides administrator access to the site. This permission level contains all permissions. This permission level cannot be customized or deleted. As a general rule, you will only allow a user to have Full Control privileges when they have demonstrated an understanding of how SharePoint works, SharePoint best practices, and, most importantly, your organization’s governance model. This user can give anyone else permissions, including Full Control.

  • Design allows the user to create lists and document libraries, edit pages, and apply themes, borders, and style sheets in the site.

  • Contribute allows the user to add, edit, and delete items in existing lists and document libraries.

  • Read allows read-only access to the site. Users and groups with this permission level can view items and pages, open items, and download documents.

  • Limited Access is a special permission level that is automatically assigned to users who have access to some areas of the site but not all areas. For example, a user with Contribute access to a document library on a subsite will appear in the permissions list of the home page as having limited access permissions. This does not allow him to view anything on the home page unless he belongs to a group that has home page access. Limited Access is automatically assigned by SharePoint when a user or group is provided unique access to a specific securable object. This permission level cannot be customized or deleted.

The out-of-the-box or default permission levels for publishing sites include

  • Manage Hierarchy allows users to create sites and edit pages, list items, and documents. This permission level does not include permissions to approve items, apply themes and borders or style sheets, or create groups. However, this permission level is otherwise very similar to Full Control.

  • Approve allows users to edit and approve pages, list items, and documents. You will most likely use this permission only in publishing sites.

  • View allows users to view pages, list items, and documents. Document types with server-side file handlers can be viewed in the browser but not downloaded.

  • Restricted Read is designed to give users access to a specific list, document library, item, or document without giving them access to the entire site. Previous document versions and user rights information are not available to people and groups with this permission level.

It is possible to create “custom” permission levels based on business needs. Custom permission levels, like securable objects that require unique security, will add complexity to the maintenance of your security model. Some individual permissions have dependencies, but in general, SharePoint will not allow you to delete an individual permission from a permission level if other individual permissions depend on it. With 32 individual permissions, you can see that creating custom permission levels can get very complicated. If you do create custom permission levels, be sure to carefully document and describe what you have done and why you have created the custom levels. Examples of possible “custom” permission levels that we have seen in practice include

  • Editor (or Restricted Contributor). For users who can upload and edit documents but cannot delete documents. This custom permission level can help ensure that users cannot accidentally delete a document but still have the capability to upload and edit them. To create a custom Editor permission level, start by creating a copy of the Contribute permission level and then remove (uncheck) the Delete Items and Delete Versions permissions. Users without delete permissions will not be able to edit the document Name (file name) after uploading the document. If the Name needs to be changed, a user with Contribute, Design, or Full Control permissions will have to make any necessary changes to the Document Name. Users with custom Editor permissions (add, change, but not delete) can edit other metadata properties.

  • Manage Permissions. For users who need to manage permissions for the site or library but not necessarily have Full Control access. By default, a user must have Full Control permissions to manage security for a site. However, you may want to delegate the responsibility for managing security to a user who should not have Full Control access to the site. In this case, create a custom permission level that starts with the Contribute set but adds the Manage Permissions user permission. This custom permission level will allow users to upload, edit, and delete documents and manage user access without having full control. You’ll want to be careful about creating this type of access because in addition to allowing a group with this custom permission set to add and remove users from Groups, they can also create new groups and change permissions on existing objects. As with Full Control, only highly trusted and trained users should have the ability to manage permissions on your site.

Use the following best practices for creating and managing permission levels:

  • If a custom permission level is needed for a SharePoint site collection, always start with an existing permission level and then either add to or delete from that set of permissions to create the custom permission level.

  • Try to create short, meaningful names for each custom permission level and be sure to add a description that summarizes what type of access is associated with the permission level. In some cases, it is helpful to prepend your organization’s name to customizations to have them stand out as unique and personalized.

  • As a general rule, do not change the “default” permission levels. Remember the saying “You touch it, you own it.” SharePoint does not offer any indicator that shows alterations to native security levels. If a similar permission level is needed and you are tempted to modify one of the default permission levels, follow this process instead:

    • Start with a copy of that permission level and make a custom permission level.

    • After copying the default permission level, make additions or deletions to individual permissions.

Other  
 
Top 10
Free Mobile And Desktop Apps For Accessing Restricted Websites
MASERATI QUATTROPORTE; DIESEL : Lure of Italian limos
TOYOTA CAMRY 2; 2.5 : Camry now more comely
KIA SORENTO 2.2CRDi : Fuel-sipping slugger
How To Setup, Password Protect & Encrypt Wireless Internet Connection
Emulate And Run iPad Apps On Windows, Mac OS X & Linux With iPadian
Backup & Restore Game Progress From Any Game With SaveGameProgress
Generate A Facebook Timeline Cover Using A Free App
New App for Women ‘Remix’ Offers Fashion Advice & Style Tips
SG50 Ferrari F12berlinetta : Prancing Horse for Lion City's 50th
- Messages forwarded by Outlook rule go nowhere
- Create and Deploy Windows 7 Image
- How do I check to see if my exchange 2003 is an open relay? (not using a open relay tester tool online, but on the console)
- Creating and using an unencrypted cookie in ASP.NET
- Directories
- Poor Performance on Sharepoint 2010 Server
- SBS 2008 ~ The e-mail alias already exists...
- Public to Private IP - DNS Changes
- Send Email from Winform application
- How to create a .mdb file from ms sql server database.......
programming4us programming4us
programming4us
 
 
programming4us