Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
Identity and Access Management
Prof. dr. ir. André Mariën
There is a problem with IAM
• IAM projects are high-risk projects and at the same time critical improvement projects– High failure rates → management confidence ▼– IT business relationship ▼– Organizations that do not fail?
• Often: expected benefits have not materialized• What are the root causes of the difficulties?
– Lack the right tools?– Inherent complexity?– Incompetent people?
22018-2019 (C) A. Mariën
Business objectives
• Know you users– Manage their identities
• Ensure compliance– Accountability, data protection, duty segregation
• Prevent unauthorized access– Authenticated, Authorized, access control
• Affordable– Fit with business and IT reality
– Maintainable and mostly automated
32018-2019 (C) A. Mariën
Security lingo for objectives
• Ensure confidentiality– Confidentiality ≠ encryption– But access control is key for confidentiality
• Encryption, key management: support for access control
• Ensure accountability– Link between the physical world (people of flesh and blood) with technical world
(userID/password, certificate, token, claim, …): crucial relationship– Manage privileges, but also manage privilege management– Accurate and comprehensive reporting
• Ensure segregation of duties– Identifying duties with segregation constraints
• Dual control required– Submit – approve– Dubble keying
– Identity management must be enterprise wide:• link all logical instances to the actual, physical principal• Example: customer and employee at the same time
• Ensure least-privilege– Only privileges that are needed, but when needed– Organizational agility: acquiring and dropping privileges follows business changes immediately
42018-2019 (C) A. Mariën
Approach from risk management
• Prevent confidentiality breaches
– Privacy/GDPR
– business strategy, partner agreements
– Customer trust in keeping their data protected
• Evidence of transaction responsibility
– Who, what, when ,where
• Prevent fraud
• Limit impact of breaches
2018-2019 (C) A. Mariën 5
Your first decisions may put the whole program at risk
• Classify it as an IT project
– All will go well in the development and implementation phase
– Nothing but trouble near roll-out and production
• Decide on a company wide model, example: RBAC– Role based access control
• Scalability and manageability of the approach
– Proof-of-concept test succeed
– Roll-out and maintenance slowly turn into nightmare
• Pick a product, configure, do some role mining, done
– Great plan
– Try-outs seem to work
– Role mining produced on larger scale are less convincing
– No underpinning (semantics) of roles, so how to maintain?
62018-2019 (C) A. Mariën
Observations
• Identity space– multiple systems for managing identity information exist and are here to stay
• spread across the organization• different vendors• different purposes
– Fundamental to “identity” is it’s uniqueness, but many views coexist
• Business view– business must controlling access, but not all in the same way:
• based on functions, tasks, organizational structure, ...• Force one way: sure to meet resistance
– Business needs drive authorization and access control: the business need leads to authorizations and access granting
• Technology space– N+1 problem:
• Every application, service, package: +1 for account repositories• New & enhanced authorization and access control model(s)
– Ease of integration:• Some systems: immutable, really inert• others come and go, or are replace by new ones with a different vision
72018-2019 (C) A. Mariën
Mickey mouse model
• Divide and conquer: Four domains– Identity management– Business privilege management– Technical authentication and access control– Enterprise Privilege Management: the domain linking it all
together
• Core activities– Entity registration and correlation– Business privilege modeling and
model population– Access control solutions and provisioning– Privilege management and privilege use
8
IT
Identity Business
EPM
core
2018-2019 (C) A. Mariën
Four domains
• The three satellite domains must be able to evolve independently– Keep the center very stable
– Maintain interfaces as much as possible
– Absorb changes in the mapping on the borders (hinges)
• Minimize impact on other domains from– Changes in identity management solutions
– Business unit reorganization, model for privilege management changes
– Technology changes: new solutions, other provisioning, other repositories
9
EPM
interface
Variable
Stable
2018-2019 (C) A. Mariën
Identity management
• Approaches
– Registration authority, with local registration agents
– Correlation extensions in the various solutions
– “Master data management” approach
• Principle: Identity as root
– Identity-rooted data modeling
– Specific extensions
• Technical identities, and link with accountable identity
• Third party stub identities , and link with accountable identity
102018-2019 (C) A. Mariën
Business privilege management
• Rooted in business– The privileges of an actor are a consequence of the business context
• Business units have multiple privilege models– Organizational Roles, Organizational structure, Task based– Professional certification or authorizations– Unstructured subsets (for instance workload driven)
• High level differences between– Unit type: HR, finance, sales, IT– Business: bank, insurance, trading
• Primary schemes:– Direct: assign privileges to identities– Chain: example: Role to tasks to privileges
• Approach:– Map business model to a limited subset of concepts
• Example: functions, tasks, organizational units, accreditations
– Map this subset to privileges: pre-authorization step
112018-2019 (C) A. Mariën
Technical authentication and access control
• Account management– Accounts as a consequence of privilege assignments
• Authorization often hidden inside applications– Model per application, no model at all
• Technical privilege modeling– Permissions: abstract specific implementation– Example: Three distinctions to make: user, supervisor, manager; implementations
can vary:• Three classes of userIDs (Uxxx, Sxxx, Mxxx)• userID must be member of the right group• ACL contains userID
• Access control models– OASIS model provides solid base: policy (enforcement, decision, information,
administration) points: PDP, PEP, PIP, PAP– More details later
• Provisioning, SSO, federation, exceptions, credential management
122018-2019 (C) A. Mariën
13
The four-world model
SECURITY
TECHNICAL
CRM
HR
Contact
Marketing
Units
Functions
Accreditations
Contracts
Group Resource
Account
Projects
DelegationHierarchy
2018-2019 (C) A. Mariën
Process: business drives
• Processes and process design matter, a lot
• Move away from “request access”
– Access granting is based on business decisions• No need to ask for an account
• No need to check business reason for a request
– Revert thinking: business decision implies granting access• Not: ask for access as a separate process
• Changes in business imply granting the necessary access
• Task assignment, work unit assignment, … are business events at the basis of privilege changes
– Should lead to privilege changes
– Privilege changes should lead to account requests or removal
– No need to “request” new or delete old privilege
142018-2019 (C) A. Mariën
pilars
Identity
information
Real world
data
Registration
Accounts
Technical
world
Link with
identity
Credentials
Validation
data
ownership
Privileges
Business access
control
IT roles
IT access controls
Access policy
Actor, target
and context
dependent
layers
IAM conceptual design
ABB
IAM solution design
SBB
Access management
access management systems
Access control operation
access control infrastructure
Logg
ing
mo
nit
ori
ng
Generic structure of privilege management and usage
• 2 x 2 levels– Design
• Define the model– Example: RBAC, TBAC, group based, ACL
• Instantiate the model– Define roles, define tasks, define groups, define ACL controls
– Use• Populate the instance
– Assign accounts to roles, to groups, in ACLs
• Use the instance data– Access control decisions based on data
2018-2019 (C) A. Mariën 17
Privileges: two layers
• Two levels at least
– Privileges for primary services
– Privileges for privilege management
• Models for primary services
– Defined by business
– Use standard (RBAC) unless not suitable
• Model for privilege management
– Typically RBAC
2018-2019 (C) A. Mariën 18
Privilege to access control
• Two-step– Model for business level privilege management
– Technical infrastructure for access control
• Business view can be mapped on multiple technical realizations– Ex:
• business model: RO users and RW users
• Implementation:– Users must be member of the right group
– Two roles: RO and RW users; users gets right role
– User accounts with RW have account ending on rw (bad practice)
2018-2019 (C) A. Mariën 19
Cascading IAM
2018-2019 (C) A. Mariën 20
Systemapplication
PAP
PAP
user
Useradmin
Superadmin
App policy (ex.: RuBAC)
Admin policy (ex.: RBAC)
Super admin policy(ex.: 4-eyes, named accounts)
Software certificates
Hardware token
Hardware token + fingerprint
Automation
• Process: Three steps– Legitimate request for access?
• Implied by business decision.• Derive situation from business
data– Authorize access
• Principle-based authorization, not case-based.
• Modeling exercise: define privileges and mapping onto business attributes
– Enable access
• (Provisioning)• Update access control
repositories to allow access.• Update account repositories• Update access control component
database (PIP, PDP implementation)
• Business privilege assignment– Based on principles
• “All employees are authorized to access email”
• “Only personnel in HR has access to personnel records”
• “Only managers have access to evaluation reports”
– Based on business information sources• “is an employee”• “works in HR”• “is a manager”• “is a certified accountant”
• Automatic:– No approval delays for automated
privilege assignment– Privilege removal: as soon as business
context changes
• Responsibility:– Direct impact on operational rights– Change throttling/buffering
212018-2019 (C) A. Mariën
Additional complexity
• Constraints– Incompatible privileges cannot be combined– Important objective for business– Issues: where to check? When to check? Override?
• Contexts (mobile workforce, different commercial contexts)– Privileges assigned in context require context verification (acting for, from, …)
• Delegation (illness, holiday)– Delegation as normal business practice
• Not exceptional• Not via credential passing
• Transitions (function change, role change, in/out)– Transitions as normal business practice
• Start working, move to different unit, move to different function
– Change takes time• coexistence of two situations• Controlled move
• Parameterization– Opaque parameters for specific business information transfer to access control components– Context information
222018-2019 (C) A. Mariën
Access control
• Parameters for access control– Requesting entity
• Privileges
• Account
– Resource, target
• Target
• Action
• Parameters– Owner, restrictions
– Request
• Context: time, channel, location
• Actual access control: how? XACML model
232018-2019 (C) A. Mariën
XACML Data Flow Model
PEP
context
handler
8. request
context
PIP
4. attribute
query
9. response
context
1. policy
6. attribute
environment
resource
subjects
5b. envrionment
attributes
PAP
obligations
service11. obligations
PDP
access
requester2. access request
7. resource
3. request10. response
5c. resource
attributes
5a. subject
attributes
242018-2019 (C) A. Mariën
OASIS XACML based view
• Differentiation: location of the Access Control Enforcement Point (PEP), Decision Point (PDP), Administration Point (PAP) and Information Point (PIP):
– Provisioning Model (PAP[, PIP]):• privileges are translated into realm permissions and provisioned towards
the different realm masters.
• PDP, PEP: in the applications
– Privilege Information Retrieval Model (PAP,PIP):• PDP, PEP: in the applications
• But: PIP consulted to take decision
– Centralized Privilege Control (PAP,PDP[,PIP]):• PEP: in the applications
• PDP is externalized
• possibly PIP consulted to take decision
252018-2019 (C) A. Mariën
DAC & MAC (wikipedia)
• Discretionary Access Control (DAC)– the data owner determines who can access specific
resources– Example, a system administrator may create a
hierarchy of files to be accessed based on certain permissions.
• Mandatory Access Control (MAC)– users do not have much freedom to determine who
has access to their files.– Example, security clearance of users and classification
of data (as confidential, secret or top secret) are used as security labels to define the level of trust.
2018-2019 (C) A. Mariën 26
Some access control models
• Role-Based Access Control (RBAC)– RBAC allows access based on the job title. RBAC largely eliminates
discretion when providing access to objects. For example, a human resources specialist should not have permissions to create network accounts; this should be a role reserved for network administrators.
• Attribute-based Access Control (ABAC)– An access control paradigm whereby access rights are granted to users
through the use of policies which evaluate attributes (user attributes, resource attributes and environment conditions)
• Rule-Based Access Control (RuBAC)– RuBAC method is largely context based. Example of this would be only
allowing students to use the labs during a certain time of day.
• Tasked-based Access Control (ABAC)– An access control paradigm whereby access rights are granted to users
based on their assigned tasks
2018-2019 (C) A. Mariën 27