PAS ADMINISTRATION

Access Control

CyberArk Training
1
OBJECTIVES

In this session, we will:

• Describe how CyberArk implements Access Control

• Design a Safe Model

• Create a Safe Naming Convention

• Apply appropriate Access Control

2
OBJECT MODEL
We use the metaphor of a
bank when talking about the
Vault.
Encryption, Firewall, Audit,
Vault and Authentication
• First you authenticate
yourself to the bank teller.

• Then you use your key to

access your Safe Deposit
box. Safes Authorization
• Then you have access to
everything in the box.

Passwords Policy

3
BASIC ACCESS CONTROL CONCEPTS

• Access Control is applied on Safes.

• A user's access to a Safe usually
applies to all the objects inside that
safe.
• The PVWA makes the safe
structure largely invisible to the end
user, so don't over simplify for their
sake.

4
DEFINING A SAFE MODEL

Define how passwords should be stored in

OUR
Safes in order to implement a custom
GOAL
authorization 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 best defined during implementation
planning.

5
QUESTIONS TO ANSWER WHEN DEFINING SAFE MODEL

Who needs access to 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 better protected than others?

Should additional access limitations apply to (specific) objects?

Multiple Central Policy Managers, system load, regulations

6
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
• Compliance Requirements
• 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!

7
SAFE NAMING CONVENTION

• Safe names are limited to 28 characters

• For performance reasons, a maximum of 20,000 objects can be

stored in a safe.
• This includes versions of objects
• The recommended number of actual accounts or files stored
in a safe is 3,000-5,000

• Objects should be stored in Safes following the principle of

“least privilege”
• Avoid situations where providing a user access to a Safe
allows them to access accounts they don’t need to access
• For example: you may want to configure separate Safes for
Windows Desktop Accounts, Windows Local Administrators,
and Windows Domain Accounts

8
SAFE NAMING CONVENTION CREATION – STEP 1

• Define business designations that are important for your environment.

For example:
Line of business Geographical location
Compliance Data Center ID
Technology platform Account Type
Application association Environment, etc
• List them in order of importance
• Discuss and agree on the resulting layered structure
• Eliminate any layers that are redundant or not needed
This will be the basis for your Safe Naming Convention base.

9
SAFE NAMING CONVENTION CREATION – STEP 2

• List out as many examples of each designation as possible and define 2-4 letter translations for
each. For example:
• ORA for Oracle Database
• LADM for Local Administrative Account

• Create 7-10 examples of safe names to ensure the structure is sufficiently robust to account for any
future need

• Document the Safe Naming Convention

10
SAFE NAMING CONVENTION CREATION – EXAMPLE STEP 1

• Category 1 - Environment:
• Production (P), Development (D), Testing (T), Q/A (Q), etc

• Category 2 - Geographical Location or domain:

• Datacenter 1 (DC1), Datacenter 2 (DC2), California Datacenter (CA), etc

• Category 3 - Business Units / Access Groups / Applications:

• Security (SEC), Engineering (ENG), Support Desk (SUP), Network Routers (NWR), Network Switches
(NWS), etc

11
SAFE NAMING CONVENTION CREATION – EXAMPLE STEP 2

• Category 4 - Technology:
• Server (SVR), Workstation (WKS), Network Device (NET), Database (DB), Mainframe (MF), Domain
(DOM) etc

• Category 5 - Technology Subtype (flavor):

• Windows (WIN), UNIX (UNX), Linux (LNX), HP-UX (HP), Cisco (CSC), SQL Database (SQL), Oracle
Database (ORC)

• Category 6 - Account Type:

• Local Account (LA), Domain Account (DA), Local Service Account (LS), Domain Service Account (DS),
Root (RT), Enable Account (EN), SQL SA Account (SA)

12
SAFE NAMING CONVENTION CREATION – EXAMPLES

• P-BOS-SRV-WIN-LADM represents:
• Production (P) environment
• Boston data center (BOS)
• Servers (SRV)
• Windows (WIN)
• Local Administrative Accounts (LADM) for

• D-NYC-DB-ORA-LSVC-HR represents:
• Development environment (D)
• New York City data center (NYC)
• Database (DB)
• Oracle (ORA)
• Local Service Accounts (LSVC)
• HR application (HR)

13
SAMPLE SAFE DESIGN

14
FOUR DATA CENTERS

• Servers are hosted at four separate Data Centers

• Data Centers are managed by Site Support Teams

• Servers are Managed by Corporate IT in Boston.

SEATTLE MILWAUKEE

BOSTON

ORLANDO PORTLAND

15
SUPPORT RESPONSIBILITIES

• Corporate IT is responsible for • The site support team monitors servers and provides after
building and maintaining severs. hours support.

Corporate IT Site Support

Windows Unix SEA MKE MCO PDX

16
SARBANES-OXLEY

• A recent SOX audit found deficiencies in the

way Corporate IT and the Site Teams were
implementing Segregation of Duties.

• Access to SOX complaint servers must have

management approval in all cases.

17
DESIGN CRITERIA
Domain Windows SEA

• Platform teams need access to platform servers

MKE
regardless of location.

• Site support teams need access to site servers MCO

regardless of platform.
• Site support teams require management approval PDX

to access any server.

• Platform teams require management approval Linux SEA

to access SOX servers.

MKE

MCO

PDX

18
SAFE DESIGN

Vault

Platform Windows Unix

Location SEA MKE SEA MKE

SOX Compliance SOX Non-SOX SOX Non-SOX SOX Non-SOX SOX Non-SOX

Windows servers in Seattle subject to SOX

19
SAFE NAMING CONVENTION
Safes
• Flatten the hierarchy but preserve all the Platform Site SOX Safe Name
information in it. Win SEA NS Win-SEA-NS
• Level 1 – Platform Win SEA SOX Win-SEA-SOX
• Level 2 – Site Win MKE NS Win-MKE-NS
• Level 3 – SOX Compliance Win MKE SOX Win-MKE-SOX
Win MCO NS Win-MCO-NS
• Use a short code for each level. Win MCO SOX Win-MCO-SOX

• Concatenate the codes to create the safe Win PDX NS Win-PDX-NS

Win PDX SOX Win-PDX-SOX
name.
NIX SEA NS NIX-SEA-NS
NIX SEA SOX NIX-SEA-SOX
NIX MKE NS NIX-MKE-NS
Remember: NIX MKE SOX NIX-MKE-SOX
Safe names are limited to 28 characters. NIX MCO NS NIX-MCO-NS
NIX MCO SOX NIX-MCO-SOX
NIX PDX NS NIX-PDX-NS
NIX PDX SOX NIX-PDX-SOX
20
SITE SUPPORT PERMISSIONS

Grant access to Safes with a matching Site Code

Safes
Platform Site SOX Safe Name
Win MKE NS Win-MKE-NS
Win MKE SOX Win-MKE-SOX
NIX MKE NS NIX-MKE-NS
NIX MKE SOX NIX-MKE-SOX

21
CORPORATE IT PERMISSIONS
Grant access to Safes with matching Platform Code
Different Permissions for SOX and Non-SOX safes.

Safes
Platform Site SOX Safe Name
Win SEA NS Win-SEA-NS
Win MKE NS Win-MKE-NS
Win MCO NS Win-MCO-NS
Win PDX NS Win-PDX-NS

Safes
Platform Site SOX Safe Name
Win SEA SOX Win-SEA-SOX
Win MKE SOX Win-MKE-SOX
Win MCO SOX Win-MCO-SOX
Win PDX SOX Win-PDX-SOX
22
MANAGER PERMISSIONS

Grant Access to Approve on all safes with matching Platform Code.

Safes

Platform Site SOX Safe Name

Win SEA SOX Win-SEA-SOX
Win MKE SOX Win-MKE-SOX
Win MCO SOX Win-MCO-SOX
Win PDX SOX Win-PDX-SOX

23
ROLE BASED ACCESS CONTROL AND SEPARATION OF DUTIES

Safes Access
Platform Site SOX Safe Name Corporate IT Site Support Managers
Win SEA NS Win-SEA-NS g_Win-SEA-NS-IT g_Win-SEA-NS-SUP g_Win-SEA-NS-MGR
Win SEA SOX Win-SEA-SOX g_Win-SEA-SOX-IT g_Win-SEA-SOX-SUP g_Win-SEA-SOX-MGR
Win MKE NS Win-MKE-NS g_Win-MKE-NS-IT g_Win-MKE-NS-SUP g_Win-MKE-NS-MGR
Win MKE SOX Win-MKE-SOX g_Win-MKE-SOX-IT g_Win-MKE-SOX-SUP g_Win-MKE-SOX-MGR
Win MCO NS Win-MCO-NS g_Win-MCO-NS-IT g_Win-MCO-NS-SUP g_Win-MCO-NS-MGR
Win MCO SOX Win-MCO-SOX g_Win-MCO-SOX-IT g_Win-MCO-SOX-SUP g_Win-MCO-SOX-MGR
Win PDX NS Win-PDX-NS g_Win-PDX-NS-IT g_Win-PDX-NS-SUP g_Win-PDX-NS-MGR
Win PDX SOX Win-PDX-SOX g_Win-PDX-SOX-IT g_Win-PDX-SOX-SUP g_Win-PDX-SOX-MGR
NIX SEA NS NIX-SEA-NS g_NIX-SEA-NS-IT g_NIX-SEA-NS-SUP g_NIX-SEA-NS-MGR
NIX SEA SOX NIX-SEA-SOX g_NIX-SEA-SOX-IT g_NIX-SEA-SOX-SUP g_NIX-SEA-SOX-MGR
NIX MKE NS NIX-MKE-NS g_NIX-MKE-NS-IT g_NIX-MKE-NS-SUP g_NIX-MKE-NS-MGR
NIX MKE SOX NIX-MKE-SOX g_NIX-MKE-SOX-IT g_NIX-MKE-SOX-SUP g_NIX-MKE-SOX-MGR
NIX MCO NS NIX-MCO-NS g_NIX-MCO-NS-IT g_NIX-MCO-NS-SUP g_NIX-MCO-NS-MGR
NIX MCO SOX NIX-MCO-SOX g_NIX-MCO-SOX-IT g_NIX-MCO-SOX-SUP g_NIX-MCO-SOX-MGR
NIX PDX NS NIX-PDX-NS g_NIX-PDX-NS-IT g_NIX-PDX-NS-SUP g_NIX-PDX-NS-MGR
NIX PDX SOX NIX-PDX-SOX g_NIX-PDX-SOX-IT g_NIX-PDX-SOX-SUP g_NIX-PDX-SOX-MGR

24
SUMMARY

25
SUMMARY

In this session we covered:

• Understanding how CyberArk implements Access Control

• Designing a Safe Model
• Creating a Safe Naming Convention
• Applying appropriate Access Control

26
ADDITIONAL RESOURCES

Videos

• CyberArk RestAPI: From Start to Finish

• CyberArk, Sailpoint, and OKTA Integration*
• *Note: This Video was not produced by CyberArk.

27
THANK YOU

CyberArk Training
28