chapter 4 Flashcards
vault model
A. vault - encryption, firewall, audit, and authentication
1. safes - authorizations
a. passwords - policy
similar to bank operations:
A. authenticate to bank teller
1. use your key to access your safe deposit box
a. you then have access to everything
access control determines who can access information and from where
cyberark manages access control by storing privileged identities in (blank) only giving access to authorized users
safe
a user’s access to a safe usually applies to all the objects (passwords) inside that safe
(blank) is a container in the vault for data, primarily privileged accounts
it is the basis for managing access control to privileged accounts
can be created manually or programmatically (e.g. via the REST API)
safe
the vault and cyberark have safes for storing their data and files
safes are stored in the vault and can be viewed by (blank), (blank), and (blank)
vault file system
pvwa
privateark client
(blank) - to develop a system for how to store passwords in safes through an authorization mode that meets the needs to the organization
safe model
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
customer typically work with the implementation team to create the safe model during the implementation
what questions need answering when defining the safe model
who needs access to data stored in the vault - internal or external users
what is the security level of data stored in the vault - secret, information, productions, development, etc
who must not see a specific type of data - is there any type of data that needs to be available to some user but not to others
should addition access limitations apply to specific objects - multiple central policy managers, system load, regulations
safe naming constraints
safe names are limited to (blank) characters
double byte characters are not supported, Chinese, Korean, etc
28
what would you call a safe containing admin accounts on a Windows based Boston data center
Or a financial department test servers in a new york data center running linux
P-BOS-SRV-WIN-LAD-HR
T-NYC-SRV-LIN-FIN
for performance reasons, the number of objects stored in a safe should be limited to (blank)
this includes versions of passwords
the recommended number of accounts or files stored in a safe is between (blank) to (blank)
20,000
3000
5000
objects should be stored in safes following the principle of (blank)
least privilege - if a user does not need access to a password, they should not have access to the safe containing it
example: create separate safes for
1.
2.
3.
windows desktop accounts
windows local administrators
windows domain accounts
the (blank) makes safe structure largely invisible to end users, so don’t oversimplify
PVWA
The ACME corporation wants to onboard the following
accounts to CyberArk:
⎼ 50 Windows server local admin accounts
⎼ 10 Oracle sysadmin accounts
* 10 Windows servers host Oracle databases
(40 Windows servers do not host Oracle databases).
* The Windows team needs to have access to all
Windows Servers local admin accounts
* The Oracle team needs to have access to all local admin
accounts on Windows Servers hosting Oracle Database
and Oracle Database login accounts (sysadmin)
How many Safes would you create?
Which Safes will be accessed by which team?
3 safes:
50 windows server accounts:
WIN-SRV - safe
40 accounts for the windows team
WIN-SRV-ORA -safe
10 windows server accounts for the windows team
DB-ORA -safe
10 sysadmin accounts for the oracle team
permissions for safes are organized into 5 groups
1
2
3
4
5
access - these permissions enable members to access accounts in the safe
account management - these permissions enable members to perform account management tasks
safe management and monitoring - these permissions enable members to perform safe management tasks
workflow - these permissions enable members to control account workflows in the safe
advanced - the permissions enable members to perform folder related activities in the safe
permission - access
users who have (blank) permission can see the accounts in the safe
list accounts
permission - access
users who have (blank) and (blank) permissions can use the accounts in the safe to log on to a remote machine through a PSM connection
use accounts
list accounts
permission - access
users who have (blank) permission can view the account password and copy it
retrieve accounts
Permissions:
Account Management
account management permissions enable users to perform such tasks as
1
2
3
4
5
6
add accounts
edit accounts
initiate account management operations through the cpm
rename accounts
delete accounts
unlock accounts
Permissions:
Safe Management
users who have the manage safe permission can modify some of the safe properties
users who have the (blank) permission can add or remove users and groups both vault users and external LDAP to safes and specify their safe authorizations
manage safe members
Not all users have the right to add Safes only (blank) and (blank) have this permission
vault admins and safe managers
3 steps to safe creation using the wizard
1
2
3
define properties
select members
set permissions
Using the (blank)
parameter, you can limit the scope of a particular platform to only those Safes that match the regular expression pattern
* For example, Accounts
associated with the LIN SSH 30 Platform can only be stored in Safes that start with the string - “Lin-”
* This will help improve the performance of the CPM and simplify administrative tasks
AllowedSafes
- There are some differences in
the terminology used in the Private Ark Client and the PVWA - Private Ark Client
⎼ Owners List
⎼ Files - PVWA
⎼ Members List
⎼ Accounts
blank
