programming4us
programming4us
SECURITY

SharePoint 2010 : Planning Your Security Model - Defining and Documenting SharePoint Security

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

This section describes a process you can use to work through the steps required to properly secure your site (or site collection). We recommend that you complete and document your security model before actually creating groups or assigning permission levels in a site collection. The following are the steps described in this process:

Step 1.
List and describe where unique security is required.

Step 2.
List and describe who needs access.

Step 3.
List and describe the permission levels.

Step 4.
Define and create the SharePoint Security Groups you need.

Step 5.
Apply security permissions.

Step 1: List and Describe Where Unique Security Is Required

A well thought out security model is crucial for the successful assignment of security in any SharePoint site collection. To simplify the ongoing management of security of each site collection, it is important to determine which parts of a site collection have common security requirements and which parts have unique requirements. This should happen in a review of security with your business sponsor. You need to carefully consider the implications of “over-securing” content. If every site is locked down for Read access, it will be hard to achieve your knowledge management objectives. Also remember that SharePoint security is inclusive—you need to fully understand the requirements associated with protecting highly secured content and know what should never happen (for example, security breaches).

As you think about creating the permission structure for each site collection, you need to carefully balance the ease of maintaining and administering the security model with the need to control specific permissions for individual securable objects. As a general rule, try to manage security at the site level. If there are particular items that contain sensitive information that must be even more secure than the site as a whole, you can apply security to individual securable objects. But remember, applying detailed security permissions at the object level can be a very time-consuming task. SharePoint 2010 includes the capability to identify how permissions have been assigned in your site collection , but “unpacking” permissions is a group by group, site by site, object by object process, so the more complex your model, the more complex it will be to examine and maintain security. You will not be able to tell just by looking at a document library or site whether unique security has been applied (without the use of third-party administration tools)—you will have to examine the settings for the object or group to see how it has been secured. This is why it is easier to maintain security at the site level: You have only one place to look when you need to understand how security has been applied.

Consider each part of a site when determining the security assignments for the top level site, the subsite, and document libraries and lists. Document the overall site security model and note the parts that require unique security levels. One way to initially document the security that will need to be applied is to start with the site architecture diagram and add a visual indicator to define where unique security is needed. There are several tools you can use to create a site architecture diagram, including PowerPoint or Word if the diagram is not very complex. Figure 1 shows a simple site architecture diagram that includes an indicator (the words UNIQUE or INHERIT) to show where unique security permissions will be applied.

Figure 1. Site architecture diagram with security indicator


Notice that the Discussion Board on the home page is in bold. This is a visual cue that the Discussion Board will have different security than the rest of the home page—all employees have Read access to most of the content on the home page, but they can contribute to the Discussion Board. The same would be required for surveys. You could also create a “node” in your diagram for each object in the site and use dotted lines or different colors to indicate where unique security is required. Planning security is an iterative process, and you may find that you need a more text-based approach to evolve your model. The remaining examples show a series of tables you can use to design and document your security model. Table 1 shows an example of the first level of your security model for an intranet—where you describe each securable object and document whether it needs unique or inherited permissions. Starting with a table like the one shown in Table 8-3, facilitate a conversation with the business sponsor about the types of permissions that are needed for the site. In general, a similar approach can be used to prepare the security model for an extranet (that is, externally accessible site for content presentation or collaboration with partners or customers), but more care would be required to define shared and exclusive partner/client areas.

Table 1. Sample Security Table
Securable ObjectDescriptionUnique or Inherited Permissions
HomeTop level site in the hierarchyUnique
 Everyone in the company can see the home page, but only the people in the marketing department can edit most content on the page 
Home/Discussion BoardDiscussion board on the home page that anyone can contribute toUnique
Home/Subsite for Team ASubsite for just the Finance TeamUnique
Home/Subsite for Team BSubsite for the Marketing Team where only a few people will editUnique
Home/Subsite B/Document Library 2Private library where Marketing Department will work on documents before everyone else in the company can see themUnique
Home/Subsite for Team CSubsite for Human Resources where all users can Read but only members of HR can editUnique

Note that this example assumes a home page where a small number of individuals can contribute content but a large number can read content. The home page is a site where the primary purpose is communications. On the home page, there is a discussion board that every user can contribute to even though they only have Read permissions for the rest of the content on the home page. We use this example in the description of the security planning process in the remaining steps in this section. As we go through the steps, we expand the columns in the table. At the end of the steps, we will have documented our security model for this site collection.

When planning security keep in mind the following:

  • Security of each object is inherited from its parent unless inheritance is explicitly broken. For example, by default, every object (for example, list or library) on a site has the same security as the site itself. If a user has Contribute access to the site, they have Contribute access to every object on the site. Similarly, if a user has Contribute access to a document library, she has Contribute access to every document in the library unless unique permissions have been applied to a document.

  • Permissions from the parent can be reapplied if previously broken. However, any special permission levels that were previously created at the object level will be removed when permissions from the parent are reapplied.

Given these characteristics, think about the following regarding security as the site is designed:

  • Try to design the site to allow assignment of permissions at the site level.

  • If security at the object level is required, consider security for an entire object (an entire list or library, for example) before securing individual items. This may mean creating a second document library (or a folder within a library) if you need unique permissions for a particular group of documents.

  • Always consider navigation. If you assign unique security to a nested subsite, you must ensure that the user has a navigation path to it. That is, if a user has access to a subsite but does not have any access to the parent site he/she will have no way to get to this site. This is why it is good practice to examine your security model from the top down (that is, home page to lowest level subsite) then in the reverse (lowest level site back to home page).

Step 2: List and Describe Who Needs Access

The next step is to carefully consider who needs access to a site collection or part of a site collection. The easiest way to document this is to add columns to the table created in Step 1 to identify who needs what type of access to each securable object in the site collection. This is shown in Table 2.

Table 2. Sample Security Table with Access Defined
Securable Object (level in the site hierarchy)DescriptionUnique or Inherited Permissions?People or Roles that Need AccessWhat Do These Users Need to Do?
HomeTop level site in the hierarchy Everyone in the company can see the home page, but only the people in the marketing department can edit most content on the pageUniqueEntire Company

Members of the Marketing Team

Fred and Sally
Read

Contribute content

Design or manage the entire site collection
Home/Discussion BoardDiscussion board on the home page that anyone can contribute toUniqueEntire CompanyContribute content
Home/Subsite for Team ASubsite for just the Finance TeamUniqueMembers of the Finance teamContribute content
   John (Site Owner for this site)Design or manage this site
Home/Subsite for Team BSubsite for the Marketing Team where only a few people will editUniqueMembers of the Marketing Team

Bob, Jane, Seth

Sarah (Site Owner for this site)
Read

Contribute content

Design or manage this site
Home/Subsite B/Document Library 2Private library where Marketing Department will work on documents before everyone else in the company can see themUniqueMembers of the Marketing TeamContribute content
Home/Subsite CSubsite for Human Resources where all users can read but only members of HR can editUniqueEntire Company Members of the HR TeamRead Contribute content

This step may require several revisions as the plan is reviewed with key stakeholders for the site and as the site design evolves. It should account for expected functional growth and anticipated security changes.

Step 3: List and Describe the Permission Levels

Next, evaluate the out-of-the-box permission levels to ensure that that they meet your needs. As described earlier, permission levels are the collection of individual permissions that describe what users can and cannot do with the securable objects on a site. You can use a table structure like that shown in Table 3 to describe the permission levels needed for your site. In our scenario, we do not need any custom permission levels, but you can use the example in Table 3 as a reference.

Table 3. Permission Levels for this Site
What Are the Permission Levels for This Site?Describe Each Permission Level
Full ControlAdministrator rights—all permissions.
DesignCreate lists and document libraries, edit pages and apply themes, borders, and style sheets in the site.
ContributeAdd, edit, and delete items in existing lists and document libraries.
ReadRead-only access to the site—view items and pages, open items, and documents.
Manage PermissionsCUSTOM: Create and change permission levels on the site and assign permission to users and groups.
EditorCUSTOM: View, add, and edit items or documents in lists, document libraries, and discussion comments; cannot delete items.

Step 4: Define and Create the SharePoint Security Groups You Need

Create a custom SharePoint Group when there is a group of users in a site collection that need different permission levels in different areas of the site where it will be confusing to call the group Members in one part of the site and Visitors in another or where it is not possible or practical to create a Domain Group for these users. When you create a custom SharePoint Group, it is best to choose a group name with a business-oriented name—such as Marketing Team—rather than a permission-oriented name like Member or Visitor. Create your custom SharePoint Groups at the top level of the site with no permissions. Then, add specific permission levels to the custom group at the specific securable objects where unique access is needed within the site collection.

For simple sites and most team sites, you can begin by using the default SharePoint Groups (which are [Site Name] Owners, [Site Name] Members, and [Site Name] Visitors) and assign permissions at the site level. In our example, by examining the security requirements, we decide that we want to create a custom SharePoint Group called Marketing because we want to create a clearly named group of people that we can maintain as a group but assign different permission levels to this group depending on the securable object within the site. Whether or not you use custom or default security groups, you will generally follow a model similar to the inverted triangle shown in Figure 2. In general, you should assign users only the permissions they need to do their jobs.

Figure 2. Assign users only the permissions they need to do their jobs


Most of your users will belong to a group with Read permissions. Fewer users will belong to groups with Contribute permissions. Do not add every user as a member of the [Site Name] Owners SharePoint Group. Only a few users should have Full Control privileges. Because Full Control users can change other’s permissions, it is easy to lose control of the site if too many people have Full Control permissions. Do not confuse business ownership of a site with the default security group called [Site Name] Owners. In most cases, the business executive who is the “owner” or sponsor of the site is not going to have Full Control privileges for the site. Use the naming best practices described earlier to name the custom security groups you create for your site.

SharePoint allows you to quickly give everyone in your company access to a site collection by assigning Read privileges to “all authenticated users.” Before doing this, think about the impact. This gives everyone with credentials Read access. This may include contractors, consultants, and other temporary help. If this is not appropriate, you will need to adjust your security application. This would hold true for other areas of your intranet like a Human Resources site or an employee directory.

Step 5: Apply Security Permissions

Security is assigned from the perspective of the securable object. Therefore, in the last step of the process, permissions and objects that need security are combined with any existing Domain Groups and Default or Custom SharePoint Groups.

In this step, extend the security table to include the securable objects requiring unique security (from Step 1), the security group name (owners, members, visitors from this Step 4), the permission level (from Step 3), and the people who need access (from Step 2) in a table similar to Table 4. This complete security table example is shown in Table 4. Note that as a best practice, you should save your security plan and any other administrative documents for your site in a secure document library only visible to users with Full Control or Design privileges.

Table 4. Sample Complete Security Model
Securable ObjectDescriptionUnique or Inherited PermissionSecurity GroupPermissions LevelWho Is in This Group?
HomeTop level site in the hierarchy Everyone in the company can see the home page, but only the people in the marketing department can edit most content on the pageUniqueHome Visitors

Home Members

Marketing Team
Read

Contribute

Contribute
AD Group for the entire company or AD group that contains employees only.

No one—so this default group can be deleted.

People who work in Marketing. Users are added and maintained by the Site Owner in SharePoint.
   Home OwnersFull ControlFred (IT Resource). Sally (SharePoint Super User).
Home/Discussion BoardDiscussion board on the home page that anyone can contribute toUniqueDiscussion Board VisitorsReadNot explicitly used—Read access inherited from parent.
   Discussion Board MembersContributeAD Group for the entire company.
   Discussion Board OwnersFull ControlNot explicitly used—inherited from parent.
Home/Subsite for Team ASubsite for just the Finance TeamUniqueTeam A Site VisitorsReadNo Visitors for this site—need to remove permissions for the “parent” Visitors group when this site is created.
   Team A Site MembersContributeIndividual members of the Finance team added to this “default” SharePoint Group for this subsite. There is no need to create a custom SharePoint Group for the Finance Team because they only have unique privileges on this one site.
   Team A Site OwnersFull ControlJohn (Team Leader or Project Manager).
   Home Site OwnersFull ControlInherited from the parent level, includes Fred and Sally. It’s usually a good idea to share this group across all subsites and ask the subsite owner not to remove permissions for this group on an individual subsite.
Home/Subsite for Team BSubsite for the Marketing Team where only a few people will edit most of the contentUniqueMarketing TeamReadPeople who work in Marketing. Set up and managed at the top of the site collection. Note that the “parent” SharePoint Groups will be removed from access for this subsite because it is an exclusive, private site for the Marketing Team.
   Team B Site MembersContributeBob, Jane, Seth (Implementers, Content Creators).
   Team Site B OwnersFull ControlSarah (Site Owner for this site).
   Home Site OwnersFull ControlInherited from the parent level, includes Fred and Sally.
Home/Subsite B/Document Library 2Private library where Marketing Department will work on documents before everyone else in the company can see themUniqueMarketing Team

Team Site B Owners

Home Site Owners
Contribute

Full Control

Full Control
People who work in Marketing.

Sarah (Site Owner for this site)—inherited from subsite.

Inherited from the parent level, includes Fred and Sally.
Home/Subsite CSubsite for Human Resources where all users can Read but only members of HR can editUniqueEntire Company

HR Team

Home Site Owners
Read

Contribute

Full Control
AD Group for the entire company.

Members of the HR Team.

Inherited from the parent level, includes Fred and Sally.

In this example, two custom SharePoint Groups are created for Marketing and HR because these groups of people have different levels of access in different areas of the site collection. For all other securable objects, the default groups created by SharePoint are used. In addition, we explicitly removed permissions for any security group that was initially inherited from the parent (top level) site but should not have permissions for the uniquely secured object.

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