CyberArk University
Access Control
1
Objectives
▪ Understand How CyberArk implements Access Control to Passwords
▪ Design a Safe Model to implement Access Control
2
Safe Design
4
Basic Access Control Concepts
▪ Access to passwords are controlled through Safe
Authorizations
▪ Only Users that are authorized for a specific Safe
(i.e. Safe Members) can access safe data
▪ If a User has “retrieve permissions” in a Safe, all
objects inside the can be accessed by this user
5
Defining a Safe Model
How should Password Objects be split and
stored in several safes in order to implement a
custom authorization and access model that
fits the organization?
▪ Generally, there is no common, generic “Safe
Model” that fits all CyberArk implementations!
▪ Defining a Safe Model is an individual,
implementation specific process during
implementation planning.
6
Questions to Answer When Defining Safe Model
▪ Who needs access to which data stored in the Vault?
￭ Internal (e.g. Employees) or External Users (e.g. Partners, Contractors, etc.)
▪ What is the security level of data stored in the Vault?
￭ Secret, Informational, Production, Development, Test, etc.
▪ Who must not see a specific type of data?
￭ Is there any type of data that needs to be especially protected in front of
others?
▪ Should additional access limitations apply to
(specific) objects?
￭ Multiple Central Policy Managers, system load, regulations
7
Example Criteria for Deriving a Safe Model
▪ Organizational Structure of the Enterprise
￭ e.g. Each Organization Unit has a set of dedicated safes, like OPS team Web Servers
or Database team, etc.
▪ Functional Structure
￭ e.g. group Passwords of a certain platform type in a safe, like Windows, Linux,
Oracle, etc.
￭ e.g. group types of passwords like all passwords of local administrator accounts of
Windows Workstations on place them in one safe
▪ Geographic Structure of the Enterprise
￭ e.g. Group Data in Safes based on the geographic locations of the users access this
data
▪ Security Level or Classification of Data
￭ e.g. group Passwords in Safes based on Security Classification
▪ Some other, individual criteria for separating password objects
▪ A Combination of several aspects and criteria mentioned above
￭ Note: These are examples! Start understanding the local requirements and business
processes first!
8
Safe Design
(sample)
11
Customer Example Requirements
▪ “EPV will manage the Accounts for Windows Systems, Unix
Servers and Oracle Databases.”
▪ “Password objects of a specific platform may be used by team
members only.”
▪ “EPV will be used by Windows, Unix and Oracle Teams”.
▪ “The Windows Team has a second team of external
Administrators that takes care of Windows Workstations only.”
▪ “Workstation Admins may not have access to Server passwords,
but Server Admins should have access to Workstation
passwords.”
▪ “Oracle Administrators need Access to Servers (Windows and
Unix) hosting Oracle Databases.”
12
A Sample Solution Approach
▪ Define sets that need Access, i.e. identify Users
and Groups of Users that need to be handled:
￭ Windows Server Admins
￭ Windows Workstation Admins
￭ Unix Administrators
￭ Oracle Administrators
▪ Split set of all Accounts in major sub sets:
￭ Windows
￭ Unix
￭ Oracle
▪ Start splitting Passwords Sets and start defining
sub sets to meet requirements.
13
Defining Users, Groups and Sets of Passwords
Windows
Server
Admins Windows Accounts
Windows
Workstation
Admins
Unix Accounts
Unix Admins
Oracle
Admins
Oracle Accounts
14
Drilling Down – Safe Model
￭ “Password objects of a specific platform must be used by team
members only”
15
Basic Safe Model
“Password objects of a specific
platform must be used by team
members only.”
Windows Accounts Unix Accounts Oracle Accounts
Windows Accounts Unix Accounts Oracle Accounts
16
Drilling Down – Safe Model
￭ “Password objects of a specific platform must be used by team members
only”
￭ “Workstation Admins may not have access to Server passwords, but
Server Admins should have access to Workstation passwords”
17
Basic Safe Model – Split Windows Accounts
“Workstation Admins may not have
access to Server passwords, but Server
Admins should have access to
Workstation passwords”
Windows Accounts Unix Accounts Oracle Accounts
WindowsWorkstations
Windows Accounts Unix Accounts Oracle Accounts
Windows Servers
18
Drilling Down – Safe Model
￭ “Password objects of a specific platform must be used by team members
only”
￭ “Workstation Admins may not have access to Server passwords, but
Server Admins should have access to Workstation passwords”
￭ “Oracle Administrators need Access to Servers (Windows and Unix)
hosting Oracle Databases”
19
Basic Safe Model – Servers Running Oracle
“Oracle Administrators need Access to
Servers (Windows and Unix) hosting
Oracle Databases.”
Windows Accounts Unix Accounts Oracle Accounts
WindowsWorkstations
Windows Accounts Unix Accounts Oracle Accounts
Unix Servers
Windows Servers Running Oracle
Windows Servers
Running Oracle 20
Drilling Down – Safe Model
￭ “Password objects of a specific platform must be used by team members
only .”
￭ “Workstation Admins may not have access to Server passwords, but
Server Admins should have access to Workstation passwords”
￭ “Oracle Administrators need Access to Servers (Windows and Unix)
hosting Oracle Databases”
￭ Grant the users access to Safes
21
Basic Safe Model – Provide safe Permissions
Windows Accounts
WindowsWorkstations
Windows Accounts
Windows Workstation
Admins
Windows Servers
Windows Servers
Running Oracle Windows Server
Admins
Oracle Accounts
Unix Accounts
Oracle Accounts
Unix Servers
Running Oracle
Oracle Admins
Unix Accounts
22
Unix Admins
Safe Naming Conventions
(sample)
23
Safe Naming Convention
▪ The safe naming convention should reflect access control requirements.
▪ Make it logical and easy to understand.
▪ In this example we have three levels of hierarchy.
1. At the highest level the safes are labeled by platform (Win, Unix and Ora).
2. Second level denotes function.
3. Third level indicates application type.
Level 1 Level 2 Level 3 Safe Name
Win WKS Win-WKS
Win SRV Win-SRV
Win SRV ORA Win-SRV-ORA
Unix SRV Unix-SRV
Unix SRV ORA Unix-SRV-ORA
Ora DBs Ora-DBs
24
Safe Naming Convention
▪ The safe naming convention should reflect access control requirements.
▪ Make it logical and easy to understand.
▪ In this example we have three levels of hierarchy.
1. At the highest level the safes are labeled by platform (Win, Unix and Ora).
2. Second level denotes function.
3. Third level indicates application type.
Level 1 Level 2 Level 3 Safe Name
Win WKS Win-WKS
Win SRV Win-SRV
Win SRV ORA Win-SRV-ORA
Unix SRV Unix-SRV
Unix SRV ORA Unix-SRV-ORA
Ora DBs Ora-DBs
25
Basic Safe Model – Provide safe Permissions
Note: Safe names are
Windows Accounts
limited to 28 characters.
Win-WKS
Windows Accounts
Windows Workstation
Admins
Win-SRV
Win-SRV-ORA
Windows Server
Admins
Oracle Accounts
Unix Accounts
Ora-DBs
Unix-SRV-ORA
Oracle Admins
Unix-SRV
26
Unix Admin
Safe Level Permissions
(sample)
27
Safe Level Permissions
• Only the Unix team members should see and use Unix accounts
• Only the Windows team members should see and use Windows accounts
• Manager authorization is required in order to retrieve accounts
• Managers can view the audit log of users activity but they can’t retrieve passwords
themselves
Unix Administrators Windows Administrators
Michael (manager)
Karen (manager)
Toby
Jim
Dwight
Pam
• How many safes do we need to create?
• How many groups do we need to create?
28
Safe Level Permissions
• Only the Unix team members should see and use Unix accounts
• Only the Windows team members should see and use Windows accounts
• Manager authorization is required in order to retrieve accounts
• Managers can view the audit log of users activity but they can’t retrieve passwords
themselves
Unix Administrators Windows Administrators
Michael (manager)
Karen (manager)
Toby
Jim
Dwight
Pam
• How many safes do we need to create? 2
• How many groups do we need to create? 4
29
Safe Level Permissions – Unix Team
Users Group permissions Safe
Toby, Dwight Unix_Admins Use Accounts,
Retrieve Accounts, Unix Servers
List Accounts
Michael Unix_Admins_Mgr List Accounts,
View Audit log,
Authorize Unix Servers
password requests
30
Safe Level Permissions – Windows Team
Users Group permissions Safe
Jim, Pam Windows_Admins Use Accounts,
Retrieve
Accounts, List Win Servers
Accounts
Karen Windows_Admins_ List Accounts,
Mgr View Audit log,
Authorize Win Servers
password
requests
31
