Notes from SPC14: SharePoint Data Security and Compliance

Wednesday March 5, 2014 9:00-10:15am

Speaker: Liam Cleary

ITPro Session 

Authentication vs Authorization

• Authentication = verification of claim
• Authorization = verification of permission
• Authentication precedes authorization
• Exception to the rule
• Anonymous access can leave comments on blog site
• Anonymous users are already authorized but not authenticated 

• SharePoint does not perform authentication (domain authenticates you), but it does authorization 

Authorization

• SharePoint does this after Authentication
• Is user member of group?
• Is user account added to ACL of object?
• Does user have required attribute?
• SharePoint only understands what it is told
• Ex. Just because user logged in at? Does not authorize 

• SharePoint out of the box is secure!
• By default it will deny you access 

• Best approach to authorization
• Active directory groups
• Roles from membership and role provider
• Claims associated to user… can move away from groups

Authentication

• First web page request is always anonymous 

• Classic authorization approach
• Active directory users and groups
• Users added to AD groups, AD groups added to SharePoint site groups
• Single Sign On
• Web applications set to the same authentication
• Sites added to intranet zone with auto login enabled
• People Picker = full name resolution control
• Specific configuration: none
• Custom component: none 

 

Custom Role Provider

• Classic .NET approach
• Support local & remote authentication store
• Web services, remote database calls
• Single sign on  = custom solution
• People picker - name resolution control
• Specific configuration = yes, web.config 

SAML Approach

• Single Sign On, sites set to require authentication
• People picker = claim provider needed, otherwise use the default provider with its issues
• Specific configuration = no (need to use powershell to configure trusted provider and SSL certs)
• Custom components = yes, welcome control, login control, etc. 

Windows Azure Authentication Process

• Request web page (anonymous)
• Send to Azure ACS provider picker
• Redirect to provider login page
• Send credentials to provider
• User authenticated, redirect to Azure ACS
• Request SAML security token wrapped from provider
• Validate credentials with STS
• Send a SAML security token
• Create SharePoint security token and send page 

Claims Fundamentals

• Identity - info about a person or object (ad, google, windows live, facebook, etc.)
• Claim - attributes of the identity(user ID, email, age, etc.)
• Token - binary of identity, claims and signature
• Relying Party - users token, SharePoint 

• Ex. Driver's license has an Identity, Issuer, Claims 

Claims Augmentation

• Ability to intercept the incoming claims and transform to different outgoing claims
• Add additional attributes before output is generated
• Why?
• Retrieve user attributes from line of business apps
• Types of augmentation
• Federation gateway: claim mapping transformation
• SharePoint: claim mapping transformation
• Custom claim provider: append claim attributes

 

OAuth

• Definition - enabled users to approve an application without sharing credentials
• Used only for access token that are then used to retrieve date from SharePoint
• Not used for sign-in tokens
• Use of tokens
• Specific site, resource or for a defined duration
• User does not reveal credentials or their data 

App Model

Authentication

• App Model
• Used to authorize app requests - facebook type
• SharePoint Store based using Windows Azure ACS
• Windows Azure ACS or User defined permission
• App Permissions
• Based on "trust" - user must select that they trust it
• Request trust levels as part of the app
• App Types
• Cloud, SharePoint or Provider Hosted 

Authorization

• Permissions
• User permissions
• App and user permissions
• App permission
• Types
• Server 2 Server - 2 legged approach
• High trust - SSL certificate (inherent trust for anything using that certificate)
• Azure ACS - 3 legged approach
• Man in Middle Attack
• Fiddler is great for this 

Protecting Content

• Location based - URL path classification
• Taxonomy Classification - only show data based on tagged taxonomy
• Permission based - security groups, roles
• Claim attribute based - user has "X" associated with them
• Request Management Service - specific blocking based on parameter 

• Rights Management - client based, compliments baseline security
• File and Drive - bit locker and EFS, protection storage location only
• SQL encryption - content database specific, no restoring of databases without private key 

Protecting Infrastructure - Edge/Perimeter

• Stop just publishing "Windows Login"
• Utilize firewall technology
• UAG
• Similar firewall technology
• Multi-factor authentication
• Certificate services
• Azure multi-factor services

Protecting Infrastructure: Database

• Block the standard SQL server ports - makes it a little more difficult for someone to realize they're talking to a SQL box
• Listen on a nonstandard port
• Implement Windows Firewall Policies
• Utilize group policies - implement least privileges 

Protecting Infrastructure: General

• Implement firewall layers between server layers
• Run 'best practice security analyzer"
• Close unused ports (80, 443, UDP 1434, TCP 1433, 25
• File and printer sharing services
• Lots more ports to protect, depending on where communication is needed between servers 

Who are you protecting against?

• Staff, vendors, partners, anonymous users or the kid next door
• Insider threats
• Protection is only as good as what you implement
• Log traffic - review firewall and server logs, authentication traffic is logged extensively
• Implement alerting mechanism for breaches