Agenda

• Definitions
• Safe design
• Platform design

cyberark.com
1 Definitions

cyberark.com
Onboarded accounts are stored
in a Safe with safe Authorizations
defining who has access Encryption, Firewall, Audit,
accounts and what level of Vault
access they have. and Authentication
• Connect
• View Password
• Account Approvers (Authorize access to
Passwords)
• Account Users (Request access to
Passwords)
Safes Authorization
Accounts are associated with
Platforms who determine which
policies will apply:
• Password rotation frequency.
• Dual control password access approval
• Exclusive Access Accounts Policy (Platforms)
• One-Time Password

cyberark.com
2 Safe Design

cyberark.com
 To develop a system for how to store passwords
OUR
in Safes through an authorization model that
GOAL
meets the needs of the organization

There is no generic “Safe model” that fits all

CyberArk implementations

Defining a Safe model is an individual,

implementation-specific process best defined during
the planning stages

cyberark.com
 Objects should be stored in Safes following
the principle of “least privilege”

Avoid situations providing a user access to a Safe

which allows them to access accounts not related
to their job responsibilities

If a user does not NEED access to a

password, they should not have access to the
Safe containing it

Consider separate Safes for:

– Windows Desktop Accounts

Least Privilege –
–
Windows Local Administrators
Windows Domain Accounts

Copyright © 2021 CyberArk Software Ltd. All rights reserved. cyberark.com

Safes are ACLs Design Considerations
• Accounts are stored in exactly one safe exactly once • CPMs are assigned at the safe level
• Users (and apps) can be members of any number of • Number of safe discussion very similar to RBAC vs
safes DAC/MAC
• Permissions for members on objects within are • Granularity is operationally burdensome, but any
assigned at the safe level. Access to a safe grants alternative is compromising on security
access to all the accounts within • Distinction between personal safe (for personal admin
accounts such as admin- or a.) and everything else

Provisioning Access Optional

• Direct provisioning for personal safes • Create an Internal user named something like Safe
Admin that can be used to create/manage safes
• AD groups for non-personal safes
• Consumes a license; however, if maxed out, can get
• Minimum two “roles”: user and admin
license extended by 1 for free 9

cyberark.com
• WHO will have access to WHAT and HOW? Accounts
• WHO: End User (User) Onboarded into a
Safe
• Via Safe Membership
• WHAT: Target Account (Account)
• Via Onboarding of Accounts
Safe
• HOW: Access Controls
Authorisation
• Via Safe Permissions
Safe
Access Control List

• Representation of:
• Example deployment safes Safe Member
(User or Group,
• Membership of those safes (users/groups) e.g. AD group)
• Naming convention for safes Assigned Safe
Authorizations /
Permissions
11

cyberark.com
 • Safe names are limited to 28 characters
• Objects should be stored in Safes following the principle of “least privilege”
• Example: Configure separate Safes for Windows Desktop Accounts,
Windows Local Administrators, and Windows Domain Accounts

13

Copyright © 2021 CyberArk Software Ltd. All rights reserved. cyberark.com

 • Plan naming conventions that allow flexibility for growth
• Safe design does not have to be final

• A good safe design is when you can easily identify what this safe is storing
• Use a readable naming convention

• Start from the most generic property to the most detailed one

• Plan for separate PSM recording Safes and access

• Regularly review Safe permissions and access

• Recommended maximum number of accounts per Safe: < 5,000

• Document and share the safe design

• Set AllowedSafes parameter up within each Platform Policy: Link
14

Copyright © 2021 CyberArk Software Ltd. All rights reserved. cyberark.com

 CATEGORY CATEGORY CATEGORY
1 2 3

Environment Geographical Location Business Units / Access

or Domain Groups / Applications
• Production (P) • Datacenter 1 (DC1) • Security (SEC)
• Development (D) • Datacenter 2 (DC2) • Engineering (ENG)
• Testing (T) • Provider/Region (AZEU) • Support Desk (SUP)
• Q/A (Q) • Network Routers (NWR)
• Network Switches (NWS)
17

Copyright © 2021 CyberArk Software Ltd. All rights reserved. cyberark.com

 CATEGORY CATEGORY CATEGORY
4 5 6

Technology Technology Subtype Account Type

(flavor)
• Server (SVR) • Windows (WIN) • Local Account (LA)
• Workstation (WKS) • UNIX (UNX) • Domain Account (DA)
• Network Device (NET) • Linux (LNX) • Local Service Account (LS)
• Database (DB) • HP-UX (HP) • Domain Service Account (DS)
• Mainframe (MF) • Cisco (CSC) • Root (RT)
• Domain (DOM) • SQL Database (SQL) • Enable Account (EN)
• Oracle Database (ORC) • SQL SA Account (SA) 18

Copyright © 2021 CyberArk Software Ltd. All rights reserved. cyberark.com

 • Used for Personal Privileged Accounts provisioned to an individual
• Personal Privileged Accounts should be placed a safe that is only owned by the individual
• Assuming the same CPM can manage all the secrets contained within, all accounts
associated with this individual, regardless of their domain or platform, can be stored within this
safe
• Example:
PPA-JSmith represents:
► Personal Safe (PPA)
► Unique identifier for User (e.g. SAM
AccountName or UPN)

19

Copyright © 2021 CyberArk Software Ltd. All rights reserved. cyberark.com

Safe Naming Convention Creation – Examples

P-BOS-SRV-WIN-LA represents: D-NYC-DB-ORA-LS-HR represents:

► Production (P) environment ► Development environment (D)

► Boston data center (BOS) ► New York City data center (NYC)
► Servers (SRV) ► Database (DB)
► Windows (WIN) ► Oracle (ORA)
► Local Accounts (LA) ► Local Service Accounts (LS)
► HR application (HR)

cyberark.com
 23

cyberark.com
• CyberArk Web Portal
• Per-safe tasks
• Link: Access Control

• REST APIs
• Per-safe or bulk tasks Safes Authorization
• Link: Developers – Safes

• See the CyberArk GitHub for

some premade tools

cyberark.com
Key Takeaways

Safes need to have a naming

convention

Safes are where access is

restricted

Permissions can be granular

Copyright © 2021 CyberArk Software Ltd. All rights reserved. cyberark.com

3 Platform Design

26

cyberark.com
• Platforms are the settings that apply to the associated accounts onboarded
• Platform naming conventions should include details conducive to assigning new
accounts to that platform

• Each account is assigned to a single platform and can be stored in only one safe

• Exceptions to Master Policy are made at the platform level

• PSM(s) are assigned at the platform level

• Only 1 PSM or PSM Load balancer can be specified

27

cyberark.com
• Platform name can contain maximum 100 characters
• A dedicated PSM recording Safe doesn’t require a dedicated Platform Policy: Link
• Regularly review Platform Policy configuration
• Set the standards for Application based Platforms
• Use FromHour/ToHour carefully
• Limit the number of Platforms to no more than 800: Link.
• Environments that have over 800 Platforms could lead to issues: Link

28

cyberark.com
• Each CPM will monitor each active platform
and the accounts associated with them
• By default, several out of the box platforms
are active
• Ensure that only platforms with accounts
assigned to them are active
• Make all templates and platforms without
accounts assigned inactive (grayed out)

29

cyberark.com
Thanks ! Questions ?

31

cyberark.com