chapter 4 Flashcards
(22 cards)
basic access control concepts
access control determines who can access information and from where
cyberark manages access control by storing privileged identities in (objects) only giving access to authorized users
safe
a user’s access to a safe usually applies to all the objects (passwords) inside that safe
(object) 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 - aka windows explorer d:\privateark\safes\data
pvwa - standard web interface
privateark client
defining a safe model- to develop a system for how to store passwords in safes through an authorization mode that meets the needs to 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
customer typically work with the implementation team to create the safe model during the implementation
(none)
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, production, 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 additional access limitations apply to specific objects - multiple central policy managers, system load, regulations
(none)
safe naming constraints
safe names are limited to (number) 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 (number)
this includes versions of passwords
the recommended number of accounts or files stored in a safe is between 3000 to 5000
20,000
objects should be stored in safes following the principle of (blank privilege)
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
windows desktop accounts
windows local administrators
windows domain accounts
the (system) makes safe structure largely invisible to end users, so don’t oversimplify for their sake
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
granular safe permissions
permissions for safes are organized into 5 groups
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
(none)
permission - access
users who have the (blank blank) permission can see the accounts in the safe
list accounts
permission - access
users who have the (blank) account permission and the (blank) account 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 the (blank) accounts permission can view the account password and copy it
retrieve accounts
Permissions:
Account Management
account management permissions enable users to perform such tasks as
add accounts
edit accounts
initiate account management operations through the cpm
rename accounts
delete accounts
unlock accounts
(none)
Permissions:
Safe Management
users who have the manage safe permission can modify some of the safe properties
users who have the (blank blank 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 blank) and (blank blank) have this permission
vault admins and safe managers
3 steps to safe creation using the wizard
define properties
select members
set permissions
(none)
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
