260 likes | 358 Views
About. Chris Welch Synergy – Global Reach. Local Service. Email - cwelch@synergyonline.com Cell - 808 255 9431 Online - www.synergyonline.com USA | South Africa | United Kingdom | Asia Pacific. SharePoint 2010 End User Security - Standardization and Customization.
E N D
About Chris Welch Synergy – Global Reach. Local Service. Email - cwelch@synergyonline.com Cell - 808 255 9431 Online - www.synergyonline.com USA | South Africa | United Kingdom | Asia Pacific
SharePoint 2010 End User Security - Standardization and Customization • Understanding security in the End User environment • Discussion and Demonstrations • All participation is welcome and appreciated
SharePoint 2010 End User Security - Standardization and Customization How do you make a meaningful security infrastructure? > Planning and understanding < So… Let’s talk a bit about security
What is security? • Trust • Trust in people • Trust in technology • Trust in business P&P • Trust in the institutional setting
Security is a management process • Best Practice • Keep it simple • Reduce • Reuse • Recycle
Basic Security Concepts • Plan the security environment • What – define security • Sites • Lists and libraries • Who – define roles • Separation of Duties • Access – define levels • Least Privilege
SharePoint Roles • Standard Security Roles • Farm Administrator • Site Collection Administrator • Service Application Administrator • Site Administrator • Users
Security 101 - Terms • Authorization vs. Authentication • Risk Management • $ or other measure • Central tenets of measuring secure systems • Confidentiality • Integrity • Availability • Non Repudiation • Others….
So What About SharePoint? • Demo Interlude • How does SharePoint do - • Confidentiality • Integrity • Availability • Non-Repudiation
Discussion Point • Where are the • Strengths in your SharePoint security • Weaknesses in your SharePoint security • What is the trust factor
Architecture Primer • SharePoint architecture Web Application Site Collection Sites Lists and Libraries
Web Application Security • Performed by a Farm Administrator • Security • Authentication • User Permissions • Policies • Anonymous • User • Permissions
Web Application Demo • Authentication Providers • User Permissions • Remove Manage Lists permission • Policies • Create Deny Delete Permission Policy • Apply as a User Policy
Site collection security • Site Collection Administrator • Has full control of all content in a site collection • Is bound by security policy settings at the Web Application level • Is managed at the site collection or farm Web Application level • Highly trusted position in user environment • Farm Administrator
Site Level Security • Uses three basic pieces of infrastructure • Security principle • Securable Object • Permission Level User or Group Site-List-Item Permission Level
Users and Groups • Maintained at the site collection • Users • Available from Authentication Provider • Stored in user information list • Groups • AD • SharePoint • Best Practice Discussion • Users vs. Groups
Some Limits to Consider • Supported Limits • Groups per users - 5000 • Users – 2 million per SC • Principles per group – 5000 • SharePoint Groups – 10,000 per SC • Security Scope – 5000 • Limits based on performance
Users and Group Demo • Users and Group • Review groups • Create a group and discuss settings • Suggestions Group • Add users • Settings overview • Groups page • Group
Securable Objects • Sites, lists and libraries, item • Security inherited by default • Inheritance can be removed • Sites can be created with unique permissions • Creates three groups by default • Permsetup.aspx
Securable Objects Demonstration • Review settings • Remove inheritance for a site • Remove inherited principles • Create a new security infrastructure
Permissions and Permission Levels • Used to grant access • Based upon granular permissions • 33 • Default set of permission levels • FDCRL • AMRV • Do not delete! • Used to create customized security settings
Permission Levels • Stored at the top level site • Inheritance can be broken, using PowerShell • Best practice is to create a new Permission Level by inheriting from an existing one
Demo of Permission Levels • Review permissions • Create a permission level by copying • Remove delete versions • Create a manage lists permission level • Demonstrate permission dependencies
Finally • Security • Standardize where possible • Customize where necessary • Plan • Document • Simplify