Follow me on Twitter @AntonioMaio2

Wednesday, March 5, 2014

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 

  • 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

  • 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
  • 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

  • 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 

  • 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

No comments:

Post a Comment