Deploying Privileged Account Security On Amazon Web Services PDF

Deploying Privileged Account
Security on Amazon Web Services
Version 10.1
Copyright © 1999-2017 CyberArk Software Ltd. All rights reserved.

This document contains information and ideas, which are proprietary to CyberArk
Software Ltd. No part of this publication may be reproduced, stored in a retrieval system,
or transmitted, in any form or by any means, electronic, mechanical, photocopying,
recording, scanning, or otherwise, without the prior written permission of CyberArk
Software Ltd.
PASAWS-10-1-0-1
2 Table of Contents
Table of Contents
Amazon Web Services 4

AWS Architecture for PAS Deployment 5
Key recommendations 6
Reference architecture 7
All-in-the-Cloud deployment 7
Hybrid deployment 9
Extending the On-Prem deployment to cloud resources 10
Cloud committed but retains an on-premises Vault 11
Resource account connectivity 12
VPC peering 12
Shared VPN (Transit) VPC 13
Direct VPN between components and resources 14
Security Overview 15
The Vault 15
Access the Vault 15
Vault keys in the cloud 15
Amazon KMS authorizations 16
Password delivery infrastructure 16
Bucket 16
Lambda function 16
Bucket policy 17
Password storage 17
Instance deployment 18
Instance profiles creation 18
Instance roles creation 19
Access Policies Creation 19
Instance creation 20
Stack deletion policy 20
General 21
System Requirements 22
Recommended AWS EC2 instance size specifications 22
Install Privileged Account Security Solution on AWS 25
Create the CyberArk Environment Automatically on AWS 26
OneClick Installation - Automatic Deployment by CloudFormation 28
CloudFormation architecture 28
License and public key files 29
Run the one-click installation 29
Deploy the CyberArk Environment Manually on AWS using AMIs 33
The Vault 33
Components 38
Deploy an Elastic Load Balancer over several Privileged Session Manager
instances 43
Create a classic load balancer 43
Privileged Account Security

Table of Contents 3
Configure the load balancer in PVWA as a new Privileged Session Manager

Server 44
Associate the load balancer with the relevant platforms in PVWA 45
Deploy an Elastic Load Balancer over several PVWA instances 46
Enable the PVWA to work in a load balancer environment 46
Create a classic load balancer 46
Change Server Keys 47
ChangeAwsKeys command 48
Limitations 50
General Limitations 50
Vault 50
Components 51
Disaster recovery configuration 51
Deploy only one instance of each component 51
CPM and PVWA 51
PSM 51
PSMP 52
Appendices 53
Prepare the AWS Environment Manually 54
Create a VPC for the Privileged Account Security Vault 54
Create a VPC for the PAS components 58
Configure peering between the VPCs 62
Region Names 64

4
Amazon Web Services
Deploy CyberArk's Privileged Account Security solution on Amazon Web Services

(AWS) with one click. This guide describes the architecture and best practices to
securely deploy CyberArk Privileged Account Security components on AWS, including
the Vault. In addition, we provide you the building blocks to custom build your own
process for deploying CyberArk on AWS.

Deploying Privileged Account Security on Amazon Web Services 5
AWS Architecture for PAS Deployment
This reference architecture establishes a set of recommendations and best practices

suited to an Amazon Web Services deployment. It was developed with the following
guiding principles:
Principle Description
Equitable Security While the nature of the cloud platform does not permit the application
to On-Premises of identical security controls to on-premises deployments, CyberArk
Deployment has sought to provide an equitable level of security for the cloud in
compliance with our Security Fundamentals for Privileged Account
Security and Digital Vault Security Standard.
Centralization of Enterprise cloud footprints can consist of tens, hundreds, or even

CyberArk thousands of AWS accounts and VPCs. We don't recommend
Privileged deploying Privileged Account Security to each of them as the cost
Account Security and complexity grows as each account or VPC is added. So we
focus on the interconnection between the CyberArk deployment and
your resource accounts.
Modular The approach to enterprise cloud architecture widely varies among

Architecture large enterprises, depending on the size of their cloud footprint and
type of workload. By loosely coupling the components of the
Privileged Account Security solution, the architecture can be
adapted to suit this approach. In addition, modularization supports
automation and reuse of specific parts of the solution in additional
regions, or to support high-risk use cases or other cloud providers.
Enable Recognizing that cloud workloads are often automated, our

Automation approach to centralize interconnection minimizes the steps
necessary to automate the deployment of Privileged Account
Security to newly provisioned accounts, VPCs, and instances.

6 Key recommendations
Key recommendations
The reference model for AWS has several key features that are important to
implementing the principles outlined above.
Recommendations Description
Deploy the Privileged More than just a unit for billing, an AWS account also acts as a
Account Security security perimeter. By isolating the deployment of CyberArk
solution within its Privileged Account Security in its own account, access to the
own AWS account instances and other resources supporting the CyberArk
deployment can be restricted. A dedicated account is the
foundation for securing the CyberArk deployment in AWS.
Protect internet- One key difference between the traditional on-premises

based connections to CyberArk deployment and a cloud-based deployment is the
Privileged Account reliance on the internet. While access from the internet should be
Security with a web- limited , it is important to add protection against internet-based
application firewall or threats.
unified threat
management device
Apply a restrictive Limiting the number users connecting to the CyberArk account,
identity and access and the privileges those users are granted protects the Privileged
management (IAM) Account Security deployment. Require Administrators
policy to the connecting with the CyberArk account to use two-factor
CyberArk account authentication, particularly before making changes to the
environment.
Use a different IP To avoid the possibility of address conflicts as the number of

address scheme from resource VPCs grows, it is recommended to use an IP address
your resource scheme outside of your resource allocation. For example, if your
accounts to protect resource VPCs use the 10.0.0.0/8 block, consider using the
against conflicts 192.168.0.0/16 block for CyberArk.

Reference architecture
There are two major Cloud deployments to consider when transitioning/adopting Cloud
strategies.
All-in-the-Cloud deployment, aimed at the Cloud First approach and moving all
existing applications to the cloud. CyberArk Privileged Account Security is one of
them, including the different components and the Vault.
Hybrid deployment, where the on-premise corporate data center is part of the
solution and where the Vault is installed.
Both designs, together with a description of architecture and best practices are described
below.
All-in-the-Cloud deployment
The following diagram represents the recommended architecture for deploying the entire
Privileged Account Security on AWS. For details on implementing, see Prepare the AWS
Environment Manually, page 54

8 Reference architecture
Ingress or The reference architecture contains transit VPCs. While not directly a
Transit VPC part of the CyberArk Privileged Account Security deployment, these
VPCs provide essential functions. The ‘ingress VPC’ is an often-shared
web-application firewall or a unified threat management infrastructure to
protect inbound access from the internet. The ‘transit VPC’ is a shared
VPC providing a common VPN infrastructure for inter-VPC connectivity.
The ingress and transit VPCs can be the same VPC.
Shared Core services, like Active Directory, RADIUS, logging, HSM, and many
Services VPC others, are often centralized into their own VPC(s) to provide a common
infrastructure across all applications. This reference architecture
presumes the existence of shared services VPCs rather than
infrastructure dedicated to CyberArk.
Privileged The Digital Vault VPC is an isolated network containing only the Digital
Account Vault instances. A primary and secondary Digital Vault server are placed
Security in separate availability zones within the same region to provide
Digital Vault redundancy.

VPC Should exposing the CyberArk Vault protocol over the internet be
required, network ingress is limited to the CyberArk Vault protocol from
the Components VPC and to the ingress VPC. . Network egress is
limited to shared services VPCs.
To improve security, create a separate AWS account for the Digital
Vault VPC. This establishes stronger isolation for the Digital Vault.
CyberArk also recommends requiring ‘Dedicated Tenancy’ for the Digital
Vault VPC. Dedicated tenancy allocates reserved physical host
infrastructure, enhancing the separation of your ‘keys to the kingdom’
from the processing of other workloads. However, this option increases
costs.
Privileged The administrative VPC provides an isolated Central Policy Manager

Account and Privileged Session Manager for administering the Digital Vault and
Security other CyberArk components. CyberArk administrators must establish a
Administrative VPN connected to this zone (with two-factor authentication). The
VPC administrative VPC is peered with other CyberArk VPCs and is the only
route for administrative access to the instances hosting CyberArk’s
components.
Hybrid deployment
The following diagrams represent the recommended architecture for deploying
Privileged Account Security on AWS to support hybrid connectivity. Each diagram is
targeted at two different corporate Cloud strategies.
The common denominator of the following three reference models is that the Vault is
installed on the corporate on-prem datacenter, and the rest or some of the components
are deployed on AWS.

10 Extending the On-Prem deployment to cloud resources
Extending the On-Prem deployment to cloud

resources
This model applies to clients who still operate predominantly on-premise, but are shifting
certain workloads to the cloud. Therefore, their user population is still primarily on an
enterprise network and can be routed through the VPN or Direct Connect connection to
access CyberArk components servicing cloud resources.

Cloud committed but retains an on-premises Vault
The above model applies to clients who are predominantly in the cloud or are “cloud first”
in their approach. Furthermore, the presumption is that user traffic is more internet-
oriented (e.g. VPN over internet or such).

12 Resource account connectivity
Resource account connectivity

Unlike most on-premises enterprise deployments, the cloud network is substantially
more segregated and frequently relies on over-the-internet routes for cross-VPC and,
particularly, cross-region communication. Establishing and securing that communication
is vital to the operations and security of the CyberArk Privileged Account Security
deployment, and several options exist to accomplish this.
VPC peering
Amazon Web Services provides a native method for enabling networking between two
VPCs called VPC Peering. VPC Peering is an appropriate method for enabling
communication between the CyberArk components VPC and resource VPCs. However,
VPC Peering is limited to VPCs within the same AWS region and each VPC has a
maximum number of peers, making VPC peering unsuitable for large or multi-region
deployments.

Shared VPN (Transit) VPC

To service a large number of resource VPCs or those in another AWS region, it is
necessary to deploy VPN infrastructure to enable this. Many enterprises are establishing
shared VPN infrastructure to centralize management, monitoring, and security of inter-
VPC communication. The CyberArk components VPC should be joined to the transit
VPC and allowed to communicate to each resource VPC over all ports and protocols as
required for password management and privileged sessions.
Note:
For this release, configuration recommendations and testing of this approach have not
been completed

14 Resource account connectivity
Direct VPN between components and resources

If a shared VPN infrastructure (Transit VPC) is not available, a direct VPN connection
between the CyberArk component VPC and each resource VPC can be established.
The VPN server infrastructure can be deployed on either the CyberArk component VPC
or the resource VPC side and connected to a virtual gateway attacked to the other VPC.
Note:
For this release, configuration recommendations and testing of this approach have not
been completed

Security Overview
This topic describes security measures implemented to deploy CyberArk components

automatically on AWS.
The Vault
Access the Vault

To manage the Vault, configure a security group to enable RDP access from your own
IP. We recommended accessing the Vault from an instance that resides on the Admin
VPC or from a dedicated instance on the same VPC.
It is not recommended to enable RDP access to the Vault from the internet, and it is
recommended that the Vault reside in a VPC that is isolated from the internet.
Note:
When configuring the Vault, do not use the AllowNonStandardFWAddress parameter in
DBParm.ini
Vault keys in the cloud

The CyberArk Vault's encryption mechanism is designed to ensure maximum security at
all times and to provide recovery capabilities, when needed. Two external keys are
associated with the Server.
The Server Key is required to start the Vault. When the Vault is stopped, the information
stored in the Vault is not accessible without that key. In AWS deployments, the Vault AMI
includes default keys that should be regenerated as part of the post install process.

16 Password delivery infrastructure
The server key is encrypted by an AES 256 bit KMS key in GCM authenticated
encryption mode, which also guarantees the server key integrity and authenticity in
addition to its confidentiality. It is generated on the bootstrap of the instance by using
random bytes from OpenSSL and random bytes from the Amazon KMS service to make
sure it's secure and unique for every customer.
The Vault uses a unique encryption context to further guarantee that only authorized
components will be able to perform encryption and decryption operations with the KMS
key.
Amazon KMS authorizations

The Vault uses the KMS to generate the server keys. The Vault (and DR) machine
should have the following KMS authorizations:
■ Create a KMS key
■ Encrypt with a key
■ Decrypt with a key
■ Generate random material from KMS
Password delivery infrastructure

The following resources are created to securely deliver passwords from the
CloudFormation UI to the Vault and component instances:
Bucket
The template creates a new bucket to securely store and transfer passwords to the
Vaults and components.
DeployBucket (Bucket) resource creates the bucket.
DeployBucket is the main assert during CloudFormation template runtime. It contains
password files during stack creation run time. By default, DeployBucket has a "private"
access control statement, which is the most restricted statement that can be used in
CloudFormation as a Bucket resource.
Lambda function
The template creates a lambda function to insert and delete passwords in a bucket.
StorePasswordLambda (Function) resource creates the function.
Lambda function role
The template creates a role that determines what the Lambda function can do when it
assumes this role.
LambdaDeployRole (Role) resources creates this role and defines the permissions of
the StorePasswordLambda function. It has one inline policy that grants the
StorePasswordLambda function permissions to write logs to CloudWatch. The
permissions include the following actions:

■ logs:CreateLogGroup
■ logs:CreateLogStream
■ logs:DescribeLogGroups
■ logs:DescribeLogStreams
■ logs:PutLogEvents
Bucket policy
DeployBucket is also protected by the DeployBucketPolicy with the following statements:
Deny all Put Object requests that do not use SSE encryption – the data in the bucket
must be encrypted using S3 Server Side Encryption mechanism.
Deny all requests that do not use secure transport.
Allow Put Object and Delete Object requests from LambdaDeployRole. The delete
permission allows the StorePasswordLambda function to delete password files in
case of roll back or deletion of the stack.
In addition, there are two roles that have limited access to the bucket:
VaultInstancesRole has an inline policy (VaultInsancesDeployBucketAccess) that
allows the role to Get and to Delete objects in the bucket.
ComponentInstanceRole has an inline policy
(ComponentInstancesDeployBucketAccess) that allows the role to Get and to Delete
only Vault Administrator password file objects in the bucket.
The purpose of the Get permission is to fetch passwords from the bucket. The purpose of
the Delete permissions is to delete the password files from the bucket at the end of
deployment. DeployBucketPolicy (BucketPolicy) resource creates this policy.
Password storage
Storage passwords entered through the UI in the bucket using the lambda function.
A vault requires three separate passwords. The following resources are responsible for
storing each password in the bucket:
StoreMasterPassword (CustomResource)
StoreAdminPassword (CustomResource)
StoreDRPassword (CustomResource)
These resources are implicitly linked to:
DeployBucket
StorePasswordLambda
LambdaDeployRole
DeployBucketPolicy
This ensures that resources are successfully deleted in the correct order.

18 Instance deployment
Instance deployment
The following resources are responsible to create the Vault and component instances
and their security context.
Instance profiles creation

Profiles required to connect the instances to their respective roles.
The following resources are responsible for each instance type:
VaultInstanceProfile (InstanceProfile)
This profile is for Vault and Vault DR instances and has the following inline policies:
Policy Description
VaultBootstrapKMSPolicy Grants instances permission to perform

KMS:CreateKey and KMS:GenerateRandom
actions. The permissions are needed to run
Vault and Vault DR bootstrap properly.
VaultInstancesKMSAccess Grants instances permission to perform

KMS:Encrypt and KMS:Decrypt actions. The
permissions are needed to run Vault and Vault
DR services.
VaultParametersBucketAccess Grants instances permission to Get Objects

from the Vault Parameters Bucket. The
permissions are needed to fetch pre-uploaded
License and Recovery Public Key files from the
bucket.Attention: This action must not be
denied by the Vault Parameters Bucket resource
policy.
VaultInsancesDeployBucketAccess Grants instances permission to Get and to

Delete objects from DeployBucket. These
permissions are needed to fetch passwords
from the bucket and to delete Master and DR
files after instances are deployed.
ComponentInstanceProfile (InstanceProfile)
This profile is for CPM, PVWA, PSM and PSM SSH Proxy instances and has only one inline
policy.
Policy Description
ComponentInstancesDeployBucketAccess Grants instances permission to Get and

to Delete the Administrator password
file object from DeployBucket. These
permissions are needed to fetch the

Policy Description
Vault Administrator password from the

bucket and to Delete the file after
instances are deployed.
Instance roles creation

The template creates roles to grant permissions to applications running on Amazon EC2
Instances.
The following resources are responsible for each instance type:
Role Instances
VaultInstanceRole For Vault and Vault DR

instances
ComponentInstanceRole For CPM, PVWA, PSM and

PSM SSH Proxy instances
Access Policies Creation

The template creates access policies that grant instances permission to KMS and S3
buckets.
Policy Description
VaultInstancesKMSPolicy Give permissions to encrypt

and decrypt using Amazon
KMS
VaultBootstrapKMSPolicy Give permissions to create

keys and get random bytes
InstancesS3VaultParametersBucketPolicy Give access to the bucket

the user provided to the Vault
and Vault DR instances
VaultInstancesS3DeployBucketPolicy Give access to the deploy

bucket for Vault and Vault
DR instances
ComponentsInstancesS3DeployBucketPolicy Give access to the deploy

bucket for the components
instances

20 Stack deletion policy
Instance creation
Deployment of AMIs and the execution of the post-installation processes:
1. VaultMachine (Instance) resource creates the Vault instance.
2. VaultDRMachine (Instance) resource creates the Vault DR instance.
3. CPMMachine (Instance) resource creates the CPM instance.
4. PVWAMachine (Instance) resource creates the PVWA Instance.
5. PSMMachine (Instance) resource creates the PSM instance.
6. PSMPMachine (Instance) resource creates the PSM SSH Proxy instance.
Stack deletion policy

The CloudFormation template was built in accordance with Amazon's best practices, yet
it requires the customer to follow up on the deployment process by deleting the stack
after it is deployed. This action will delete all unnecessary resources from the cloud.
The deletion policy of the following resources is "Retain" and resources will not be
deleted during stack roll back or deletion:
Instances: ■ Vault instance

■ Vault DR instance
■ CPM instance
■ PVWA instance
■ PSM instance
■ PSMP instance
Instance profiles: ■ Vault instance profile

■ Components instance profile
Roles ■ Vault instance role

■ Components instance role
Policies ■ VaultInstancesKMSAccess policy of the Vault instance role
Note:
In the POC template all resources are deleted during stack roll back or deletion

General
Use the following considerations to provide the best security for the Privileged Account
Security deployment:
Use a dedicated CyberArk account for which the only user is the Vault administrator.
Make sure that CyberArk component instances cannot communicate with any other
IP addresses, except those of Vault instances, until after the CloudFormation stack is
deleted.

22 Recommended AWS EC2 instance size specifications
System Requirements
The following tables summarize the recommended AWS EC2 instance size and software
specifications for servers that are required when implementing CyberArk’s Privileged
Account Security (PAS) solution. These specifications are based on the entry level
industry standard for small-mid range servers. For other implementation sizes,
requirements should be customized according to customer needs.
Recommended AWS EC2 instance size

specifications
The following table lists the recommended specifications for standalone Vault servers,
standalone DR Vault servers, PVWA, and CPM instances.
Vault servers and standalone DR Vault servers
Small Medium Large Very large

(<1,000 (1,000-20,000 (20,000 – 100,000 (more than 100,000
managed managed managed managed
passwords) passwords) passwords) passwords)
■ m4.large ■ m4.xlarge ■ m4.2xlarge ■ m4.4xlarge

■ 250GB storage ■ 500GB storage

PVWA

(<1,000 (1,000-20,000 (20,000 – 100,000 (more than 100,000
■ t2.medium ■ t2.large ■ t2.xlarge ■ t2.2xlarge

■ 80GB ■ 80GB storage ■ 80GB storage ■ 80GB storage
storage
CPM

(<1,000 (1,000-20,000 (20,000 – 100,000 (more than 100,000
■ m4.large ■ m4.xlarge ■ m4.2xlarge ■ m4.4xlarge

■ 80GB ■ 80GB storage ■ 80GB storage ■ 80GB storage
storage
PSM
Small Mid-Range Large

(1-5 concurrent (6-30 concurrent (31-60 concurrent
RDP/SSH sessions) RDP/SSH sessions) RDP/SSH sessions)
■ C4.2xlarge ■ C4.4xlarge ■ C4.8xlarge

■ 80GB storage ■ 80GB storage ■ 80GB storage
Note:
■ Do not exceed 60 concurrent sessions per PSM server.
■ Concurrent session ranges are based on RDP and SSH connections performance
measurements.
■ Running resource-intensive applications like Toad, vSphere Client, etc. on the
PSM server will result in lower concurrency.
■ Ranges of concurrent sessions assume that the PSM is running on a dedicated
server.
■ Ranges of concurrent sessions are based on performance measurements while
video recording user’s activities in HD resolution (one screen). Note that video
recording resolution is affected by the desktop resolution of the client machine from
which the connection was made. This means that performing connections from
client machines with more than one HD screen, or with a higher resolution screen,
will result in lower concurrency.

24 Recommended AWS EC2 instance size specifications
PSMP
Mid-range
Small implementation Mid-range implementation
implementation
(<100 concurrent (100-200 concurrent
(>200 concurrent
sessions) sessions)
sessions)
m4.large m4.xlarge m4.2xlarge
Note:
■ In large scale implementations, it is recommended to deploy the CPM ,PVWA and
PSM on different instances.
■ For more information about other supported versions and requirements, refer to
Privileged Account Security System Requirements.
■ For specific system requirements of the different Central Policy Manager plug-ins,
refer to the Privileged Account Security Implementation Guide.

Install Privileged Account Security Solution

on AWS
This section describes how to install the Privileged Account Security solution on AWS in
the following ways:
■ Automatic - This method leverages AWS CloudFormation functionality.
■ Manual - This method uses CyberArk AMIs, but still differs from the standard
Privileged Account Security installation.
In this section:
Create the CyberArk Environment Automatically on AWS
OneClick Installation - Automatic Deployment by CloudFormation
Deploy the CyberArk Environment Manually on AWS using AMIs
Deploy an Elastic Load Balancer over several Privileged Session Manager
instances
Deploy an Elastic Load Balancer over several PVWA instances
Change Server Keys

26 Create the CyberArk Environment Automatically on AWS
Create the CyberArk Environment Automatically on

AWS
You can create the CyberArk environment automatically on AWS using a preprepared
template. Run the template using either the CloudFormation UI or a Command Line
Interface (CLI).
The template creates the following components:
■ Two VPCs for the CyberArk Vault and components.
■ Two private subnets across different availability zones in each VPC.
■ A public subnet in each VPC for a NAT Gateway service. The NAT Gateway is
required to enable CyberArk instances to connect to AWS services such as KMS,
CloudFormation and S3.
■ Security Groups for each CyberArk component.
After you upload the template, specify the following parameters:
Name Description Default
CyberArk Network Configuration
Vault VPC CIDR IPv4 address range for the Vault VPC. 10.0.0.0/16
Vault NAT Gateway IPv4 address range for the Vault NAT Gateway 10.0.0.0/28
Subnet CIDR subnet.
Note: The NAT Gateway is required for the
Vault to connect to the AWS KMS
service.
Vault Main Subnet IPv4 address range for the main Vault subnet. 10.0.1.0/28
CIDR
Vault DR Subnet IPv4 address range for the Vault DR subnet. 10.0.2.0/28
CIDR
Components VPC IPv4 address range for the components VPC. 10.10.0.0/16
CIDR
Components NAT IPv4 address range for the components NAT 10.10.0.0/28
Gateway Subnet Gateway subnet.
CIDR
Note:
The NAT Gateway is required for
the components to connect to the
AWS CloudFormation and S3
services
Components Main IPv4 address range for the first private 10.10.1.0/26
Subnet CIDR components subnet.
Components IPv4 address range for the second private 10.10.2.0/26

Secondary Subnet Components subnet.

CIDR
Users Access Management
Users Access CIDR Allowed IPv4 address range for users access to
CyberArk components
Administrative Allowed IPv4 address range for Remote

Access CIDR Desktop administrative access to CyberArk
instances
For details about manually creating the CyberArk environment, see Deploy the CyberArk
Environment Manually on AWS using AMIs, page 33.
After creating the CyberArk environment automatically on AWS, do the
following:
1. Create a VPC peering between the CyberArk Components VPC and the
Transit VPC ID, using the following command:
aws ec2 create-vpc-peering-connection --vpc-id

<ComponentsVPC> --peer-vpc-id <TransitVPC> --
peer-owner-id <AWSAccountID>
The following table explains the parameters that must be replaced:
Parameter Description
ComponentsVPC The VPC ID of the components
TransitVPC TheTransit VPC ID of the components
AWSAccountID The ID of the account where the Transit VPC resides
2. Accept the VPC peering from the peered VPC account:
aws ec2 accept-vpc-peering-connection --vpc-

peering-connection-id <PeeringID>
The following table explains the parameters that must be replaced:

PeeringID The VPC ID of the Transit VPC
3. Add a new route for each of the following Route Tables, using the command
below.
Components Private Route Table
■
Transit VPC Route Table.

■

28 OneClick Installation - Automatic Deployment by CloudFormation
aws ec2 create-route --route-table-id

<RouteTableID> --destination-cidr-block
<VPCCidrBlock> --vpc-peering-connection-id
<PeeringID>
For example, using the following examples of IDs and blocks, you would run
the two commands below.
■ Components Private Route Table ID - rtb-d80a75b0
■ Transit VPC Route Table ID - rtb-0306796b
■ Components VPC Cidr Block – 10.10.0.0/16
■ Transit VPC Cidr Block – 30.30.0.0/16
■ VPC Peering ID - pcx-1a2b3c4d
aws ec2 create-route --route-table-id rtb-

d80a75b0 --destination-cidr-block 30.30.0.0/16 --
vpc-peering-connection-id pcx-1a2b3c4d
aws ec2 create-route --route-table-id rtb-
0306796b --destination-cidr-block 10.10.0.0/16 --
vpc-peering-connection-id pcx-1a2b3c4d
OneClick Installation - Automatic Deployment by

CloudFormation
This section describes how to automatically deploy Privileged Account Security on
Amazon Web Services using OneClick Installation.
OneClick installation automatically deploys one instance of each component. Additional
installations must be done manually, as described in Deploy the CyberArk Environment
Manually on AWS using AMIs, page 33. For more information, refer to Limitations, page
50.
CloudFormation architecture
CyberArk offers three CloudFormation templates :
The basic template consists of the following instances which are deployed in this order:
■ Vault
■ Vault DR
■ Central Policy Manager
■ Password Vault Web Access
■ Privileged Session Manager
The POC template consists of the following instances:
■ Vault

■ Components all- in- one (Central Policy Manager, Password Vault Web Access and
Privileged Session Manager)
A third template consists of the following instance:
■ PSM SSH Proxy
License and public key files

Before running the template, create a dedicated bucket with the following files:
License
Public Key
Task Link
Create a bucket using CLI Create a bucket
Move items to a bucket using CLI Move a bucket item
Run the one-click installation

The one-click installation will be provided to you by a CyberArk representative.
You can run the template either using the CloudFormation UI or a Command Line
Interface (CLI).
After you upload the template, specify the following parameters:
General parameters
Description Default Values
License Agreement
I have read and agree to the Terms Decline Accept/Decline

and Conditions.
The EULA will be provided with the
CloudFormation template.
Key Pair
Select an existing Key Pair from Select an existing Key

your AWS account. Pair from your AWS
account.
Vault Parameters Bucket Name
Enter the name of the bucket VaultParameters

containing the license and public
key.
License - Full Path in Bucket
Enter the path of the license file license.xml

within the bucket.
Public key - Full Path in Bucket

Description Default Values
Enter the path of the public key file recpub.key

within the bucket.
Vault and Vault DR configuration (DR parameters in the extended template

only)
Vault Instance Name Enter a name for the Vault instance. Vault
Vault Master Enter a password for the Vault Master user.

Password
Vault Admin Enter a password for the Vault Administrator

Password user.
Vault and Vault DR Select the instance type of the Vault

instance type instance.
Vault and Instance Assign Security Groups to the Vault m4.large

Security Groups instance.
Select the Vault Security Group from your
AWS account.
Vault Instance Subnet Select the Subnet Id where the Vault

Id instance will reside.
Select the Vault Instance Subnet Id from
your AWS account.
Vault DR Instance Assign Security groups to the Vault DR

Select the Vault DR Instance Security
Groups from your AWS account.
Vault Instance Subnet Select the Subnet Id where the Vault DR

Id instance will reside.
Select the Vault Instance Subnet Id from
your AWS account.
DR password Enter a password for the Vault DR user.

Components configuration (For the POC template)

Components Enter a name for the PAS Components Components

Instance Name instance.
Components Select the instance type of the PAS m4.large

instance type Components instance.
Component Instance Assign Security Groups to the PAS

Security Groups Components instance.
Select the Component Instance Security
Groups from your AWS account.
Component Instance Select the Subnet Id where the PAS

Subnet Id Components instance will reside.
Select the Component Instance Subnet
Id from your AWS account.
CPM configuration (For the extended template)

CPM Instance Name Enter a name for the CPM instance. CPM
CPM instance Type Select the instance type of the CPM instance. c4.large
CPM Instance Assign Security groups to the CPM instance.

Security Groups
Select the CPM Instance Security Group from
your AWS account.
CPM Instance Select the Subnet Id where the CPM instance

Subnet Id will reside.
Select the CPM Instance Subnet Id from your
AWS account.
PVWA configuration (For the extended template)

PVWA Instance Enter a name for the PVWA instance. PVWA

Name
PVWA instance type Select the instance type of the PVWA t2.medium
instance.
PVWA Instance Assign Security groups to the PVWA

Select the PVWA Instance Security Group
from your AWS account.
PVWA Instance Select the Subnet Id where the PvWA

Subnet Id instance will reside.
Select the PVWA Instance Subnet Id from
your AWS account.

PSM configuration (For the extended template)

PSM Instance Name Enter a name for the PSM instance. PSM
PSM Instance Type Select the instance type of the PSM c4.2xlarge
instance.
PSM Instance Assign Security groups to the PSM

Select the PSM Instance Security Group
from your AWS account.
PSM Instance Select the Subnet ID where the PSM

Subnet Id instance will reside.
PSM SSH Proxy configuration (For the second extended template)

PSM SSH Proxy Enter a name for the PSM SSH Proxy CyberArk

Instance Name instance. PSM SSH
Proxy
PSM SSH Proxy Select the instance type of the PSM m4.large
Instance Type SSH Proxy instance.
PSM SSH Proxy Assign Security groups to the PSM

Instance Security SSH Proxy instance.
Groups
Select the PSM SSH Proxy Security
Group from your AWS account.
PSM SSH Proxy Select the Subnet ID where the PSM

Instance Subnet Id SSH Proxy instance will reside.

Deploy the CyberArk Environment Manually on AWS

using AMIs
You can deploy Privileged Account Security on AWS manually using the provided AMIs.
For each component, a tool is provided to finalize the installation and activate the
component. Each tool works in two modes, one that gets all the required parameters
from the user and a second that gets some of the parameters from the user and others
from AWS resources.
The order of deployment is:
1. The Vault, page 33
2. Components, page 38
a. Central Policy Manager
b. Password Vault Web Access
c. Privileged Session Manager
d. Privileged Session Manager SSH Proxy
The Vault
Before you launch

Pre-launch steps
1. Upload the customer license to the Vault instances for post installation
configuration.
2. Prepare the CyberArk Vault keys:
■Upload the Public recovery key from the Operator CD to the Vault
instances for post installation configuration.
■Place the Master CD in a safe physical location for use in an
emergency.
3. Create an IAM role for the KMS with following authorizations:
■ kms:CreateKey
■ kms:GenerateRandom
■ kms:Encrypt
■ kms:Decrypt
Launch the Vault-DR AMI

Use the AWS console to launch the Vault-DR AMI:
1. From the AWS Console Home > EC2 > Images > AMIs, select the Vault
AMI shared by CyberArk. Click Launch.
2. Choose the instance type according to the system requirements described in

34 Deploy the CyberArk Environment Manually on AWS using AMIs
Recommended AWS EC2 instance size specifications, page 22

3. In the Configure Instance Details step:
a. Select the dedicate VPC for the Vault. The creation of this VPC was
described in Prepare the AWS Environment Manually, page 54
b. Select the the IAM role you created using the KMS service.
4. In the Configure Security Group step, select the dedicate security group
you created for the Vault.
PostInstall utility
Run CAVaultManager to complete the installation
1. Connect to the Vault instance as an administrator and run the
CAVaultManager utility.
2. After running the PostInstall utility, restart the “PrivateArk Database” service.
Example command:
CAVaultManager PostInstall /AdminPass udK5_d(E /MasterPass

AS789df& /RecPub c:\RecPub.key /IsPrimaryOrDR Primary/DR
/PrimaryVaultIP 1.1.1.1 /DRPassword mNu8U$d2
/EnableFailOver /LicensePath C:\License.xml /AcceptEULA yes
Command guide
Parameter Description Action
AdminPass Administrator Sets the Administrator password

password
Valid values: Valid
password
Default value: -
MasterPass Master password Sets the Master password

Valid values: Valid
password
Default value: -
RecPub Path to the public Copy the public recovery key to the
recovery key new Server directory
Valid values: Valid
path
Default value: -
IsPrimaryOrDR The role of the The vault services are started for the
machine. Either specified role of the machine.
primary or disaster
recover.

Valid values:
"Primary"/"DR". This
is not case sensitive.
Default value: -
PrimaryVaultIP The IP of the Primary Update the Vault.ini of the DR

vault. component, found in the
PADR\vault.ini. with the primary Vault
Valid values: Valid
IP.
IP. When set to
Primary, this value
can be "1.1.1.1"
Default value: -
DRPassword DR's user password Set the DR password if relevant and

create a new credfile for the DR User.
Valid values: Valid
password
Default value: -
EnableFailOver Enable automatic fail Update the EnableFailOver parameter

over on the DR site in the padr.ini.
Valid values:
Yes/No
This is not case
sensitive
Default value: Yes
LicensePath Path to the license Your license file will be saved in the
file Server directory
Valid values: Valid
path
Default value: -
AcceptEULA Accept the End user Set this parameter to Yes to accept
license agreement the EULA terms. If this parameter is
set to No, the utility stops before any
Valid values:
changes are made.
Yes/No
This is not case
sensitive
Default value: No
KMSRegion The name of the Sets the name of the KMS region in
KMS region from DBParm.ini. When the Vault needs to
which the vault will use KMS, it will use the KMS defined
consume services. in this parameter.
Valid values: Valid Set the identical value in the
region name. For KMSRegion parameter in DBParm.ini
details, see Region in the Vault and all associated DR

Names, page 64. Vaults.

Default value:
us-east-1
(N. Virginia)
Post-install back-end actions

The following actions are performed on the back-end when you run the PostInstall
command:
Generate the server key
During the post installation process, we generate server keys as described in the
Security Overview, page 15. We store these files in the System Safe in the Primary
Vault:
■ Server.key - The KMS-encrypted server key
■ KMSKeyUUID - The key to decrypt the server key using KMS services.
The PACLI command transfers these sensitive files to the DR Vault. After the process
completes, the relevant data (keys, PACLI script) is deleted from the Vault System Safe.
Update the database and the dbparm.ini with new server key
After generating the server, the utility updates the database and external files with the
new server key and deletes the old public recovery key. The utility updates the dbparm.ini
with the new path for the server key and the public recovery key. In addition, the utility
updates the KMSKeyUUID value.
Configure remote control agent

If you choose to use the Remote Control Agent for monitoring the Vault by sending
SNMP traps, do the following.
Configure remote control agent
1. Open c:\Program Files (x86)\PrivateArk\Server > PARagent.ini.
2. In the RemoteStationIPAddress section, write the station IP that runs the
PARClient commands.
3. In the UserCredentialsPath section, write the name and path of the
PARAgent Password file that is created in step 5 in this procedure. For
example, PARAgentPass.pass.
4. As administrator, run the command PARagent.exe setpassword
<password file name> from a command line in c:\Program Files
(x86)\PrivateArk\Server directory.
5. Restart the PrivateArk Remote Control Agent service.

Configure the Event Notification Engine (ENE)

If you choose to use the Event Notification Engine service (ENE), refer to the Privileged
Account Security Installation Guide.
Install the CyberArk backup solution

If you choose to use the CyberArk backup solution, refer to the Privileged Account
Security Installation Guide.
Note:
AWS backup solutions are not supported.

Components
Launch a new component

Do the following to launch a Privileged Account Security Component in an AWS cloud
environment. To launch a PSMP server in the cloud, see Launch a PSMP AMI, page 41.
Launch a component in AWS cloud
1. From the Amazon EC2 console, launch a new EC2 instance using the PAS
Components AMI.
Configure the instance parameters according to the recommended system and
security specification. For details, see System Requirements, page 22
andSecurity Overview, page 15.
2. After the instance is launched, connect to it using a Remote Desktop session
as an Administrator user.
3. Once connected, run the Components Registration tool:
a. Open a command prompt as administrator.
b. Navigate to C:\CyberArk\Components Registration
c. Register the component instance with a Vault using one of the
following methods:
■ Authenticate with an AWS S3 Object
RegisterComponent.exe <1> /accepteula <2>

/vaultip <3> /vaultport <4> /vaultuser <5>
/bucketname <7>/objectKey <8>
■ Authenticate with a password, execute the following command:
RegisterComponent.exe <1> /accepteula <2>

/vaultip <3> /vaultport <4> /vaultuser <5>
/vaultpassword <6>
Placeholder Parameter Description Value
<1> <Component Enter the component ■ CPM

name> name ■ PSM
■ PVWA
<2> accepteula Accept the end user Yes/No

License agreement
<3> vaultip IP address or hostname IP address

of the vault server or
hostname

Placeholder Parameter Description Value
<4> vaultport Vault’s configured Port

communication port. number
Default Vault port: 1858
<5> vaultuser Vault user performing String

the installation.
Note: We recommend
using the Vault
administrator
user to install
Privileged
Session
Manager as this
user has the
appropriate
Vault
authorizations.
and is created in
the appropriate
location in the
Vault hierarchy.
<6> vaultpassword Vault user password String
<7> bucketname AWS bucket name String
<8> objectKey AWS s3 Object key String
4. After the component registration is complete, verify that the component

service is running:
a. From the Start menu, select Settings > Control Panel.
b. From Control Panel, select Administrative Tools,> Services to
open the Services window.
c. Verify that the Cyber-Ark <Component> service is running. If not,
start the service.
5. Complete additional tasks for specific components:
PVWA
The AMI is deployed with a default machine name and a self-signed
certificate in the IIS with binding to the PVWA.
a. Change the host name.
b. Create a self-signed certificate or upload a certificate and create a
new binding in the IIS:
From IIS Manager> Sites > Default Web Site, right-click on
Bindings, then click Add:

Property Value
Type https
IP address All Unassigned
Port 443
SSL certificate The certificate you just created
PSM
If the the client devices are outside of the Virtual Private Cloud (VPC) where
Privilege Session Manager is running, change the private address of the
Privileged Session Manager server to the public IP address:
a. From EC2 Management Console > Running Instances, select
the Privileged Session Manager instance. Note the IPv4 Public IP
address in the Description tab.
b. Log in to PVWA as an administrative user.
c. Go to Administration > Component Settings, click Options.
d. Select Privileged Session Management > Configured PSM
Servers > [ID of the PSM server] > Connection Details. Select
Server.
e. In the Properties pane, set the value of the Address property to the
public IP address from step a.
f. Select Apply to apply the configuration change.
Launch multiple Privileged Session Manager instances

The Enterprise Password Vault can work with multiple instances of the PSM that access
the same Vault. This enables you to work with the following scenarios:
■ Load balancing implementations using an Elastic Load Balancer.
■ Access to managed devices that are located in different networks. A PSM server can
be installed in each network segment to communicate with the remote machines
using native protocols and without the need to open the enterprise firewall.
Add more than one Privileged Session Manager instance:
1. Open the PrivateArk client and log on to your Vault server.
2. Add the Vault user who will perform installation to the PSMMaster group.
Verify that this user is not an owner PSMUnmanagedSessionAccounts
Safe. After you have finished installation, remove the user from the
PSMMaster group.
3. To launch another PSM instance, see Launch a new component, page 38
4. To configure the PSM servers in a load balanced environment, see Deploy
an Elastic Load Balancer over several Privileged Session Manager
instances, page 43
5. For other implementations, associate the PSM with a relevant platform in
PVWA

a. In PVWA, select Administration > System Configuration >

Platform Management to display a list of supported target account
platforms.
b. Select the platform to configure for the PSM. Click Edit.
c. Expand UI & Workflows > Privileged Session Management. The
Privileged Session Manager parameters for this platform are
displayed with their default values.
d. In the Properties list, specify the following property:
e. ID – The unique ID of the PSM. This ID is taken from the list of
Privileged Session Manager Servers configured in Options.
f. Click Apply to save the new configurations..
Optional PSM post-installation tasks

The following are optional post installations procedures.
Enable users to connect to a target system directly from their desktop using an RDP
Client Application
Enable maintenance users to logon remotely to the PSM server
Enable users to print PSM Sessions
Allow CPM management for PSMConnect and PSMAdminConnect users
Configure implementations with Multiple PVWAs
For details, see Following PSM Installation in the Privileged Session Manager
Installation Guide.
Setup PSM for Databases and Virtualization
For details, see (Optional) Setting up PSM for Databases and Virtualization in
the Privileged Account Security Installation Guide.
Launch a PSMP AMI

Launch a PSMP server in the AWS cloud environment.
1. From the Amazon EC2 console, launch a new EC2 instance using the
PSMP AMI.
Configure the instance parameters according to the recommended system
and security specification.
For details, see System Requirements, page 22 andSecurity Overview,
page 15.
2. Connect to the PSMP machine using an ec2-user. Enter the following
commands:
a. sudo su
b. cd /tmp/PSMPInstall/
c. chmod 700 register_and_activation.sh

d. /opt/CARKpsmp/bin/createcredfile
/tmp/PSMPInstall/user.cred
e. chmod 400 /tmp/PSMPInstall/user.cred
f. ./register_and_activation.sh
/tmp/PSMPInstall/user.cred <Vault IP>,<Vault DR>
<Instance ID> <AcceptEULA [Y/N]>
Vault IP IP address or hostname of the vault server
Vault DR IP address or hostname of the vault disaster

recovery server
Instance ID A unique identifier of the server where the PSMP is

installed.
AcceptEULA Accept the end user License agreement [Yes/No]
3. Verify that user.cred file has been deleted.

Deploy an Elastic Load Balancer over several

Privileged Session Manager instances
This topic describes how to deploy an elastic load balancer over several Privileged
Session Manager instances:
Create a classic load balancer

Create a classic load balancer:
1. Open the Amazon EC2 console.
2. From the navigation bar, select a region for your load balancer. Be sure to
select the same region that you selected for your Privileged Session
Manager instances.
3. From the EC2 Dashboard pane > LOAD BALANCING, select Load
Balancers. Click Create Load Balancer.
4. Select Classic Load Balance. Click Continue.
5. Define the load balancer:
a. In the Basic Configuration section:
Name: Enter a name for your load balancer
Create LB Inside. Select the VPC where your Privileged
Session Manager instances are running.
b. If the load balancer is internal, meaning the clients are in the same
VPC as the load balancer, check Create an internal load balancer
option. This makes the load balancer inaccessible from the internet.
Leave this option unchecked if you want the load balancer to route
requests from clients over the internet.
c. Click Listener Configuration. Create a single listener with the
following details:
Load Balancer Protocol: TCP
Load Balancer Port: 3389
Instance Protocol: TCP
Instance Port: 3389
d. Click Select Subnets, then select all the subnets, that have
Privileged Session Manager instances, you want to route traffic to
from the load balancer.
6. Click Assign Security Groups, then select the security groups based on
the recommended security specifications. For details, see AWS Architecture
for PAS Deployment, page 5
7. Click Configure Security Settings. Click Next.

44 Deploy an Elastic Load Balancer over several Privileged Session Manager instances
Note:
To configure secured RDP connections, refer to the Securing RDP
Connections with SSL section in the Privileged Account Security Implementation
Guide
8. Click Configure Health Check. Set the health check settings, as shown in
the following example:
9. Click Add EC2 Instances. Select the Privileged Session Manager

instances you want the load balancer to route traffic to.
10. Click Add Tags section, create tags to help identify the load balancer. This
step is optional.
11. Click Review. Verify the load balancer configuration. You can edit
configuration settings before you create the load balancer.
12. Click Createto create the load balancer with the current configuration.
Configure the load balancer in PVWA as a new Privileged

Session Manager Server
Configure the load balancer as a new PSM server
1. From EC2 management console dashboard > LOAD BALANCING, click
Load Balancers. This opens the load balancers list.
2. From the load balancers list, select the load balancer you created. Note the
value of the DNS name in the Description tab .
3. Log in to PVWA as an administrative user.
4. Select Administration > System Configuration > Options.
5. Expand Privileged Session Management .> Configured Privileged
Session Manager Servers.
6. Copy and paste from an existing Privileged Session Manager server .

Note:
It is important to copy an existing Privileged Session Manager server and
modify it to retain the PSMProtocolVersion property for both the load
balancer the configured servers. Do not use the Add PSMServer option.
7. Click the new entry. In Properties pane, edit the following properties:
■ ID – A unique ID for the load balancer in the configuration.
■ Name – The name of the load balancer.
8. Expand Connection Details. Select Server.
9. In the Properties pane, set the Address property to the DNS name from
step 2.
10. Click Apply to save the new configuration.
Associate the load balancer with the relevant platforms in

PVWA
Associate the load balancer with platforms
1. In PVWA, select Administration > System Configuration > Platform
Management to display a list of supported target account platforms.
2. Select the platform to configure for the load balancer. Click Edit.
3. Expand UI & Workflows > Privileged Session Management. The
Privileged Session Manager parameters for this platform are displayed with
their default values.
4. In the Properties list, specify the following property:
■ ID – The unique ID of the load balancer. This ID is taken from the list
of Privileged Session Manager Servers configured in Options.
5. Click Apply to save the new configurations.

46 Deploy an Elastic Load Balancer over several PVWA instances
Deploy an Elastic Load Balancer over several PVWA

instances
This topic describes how to deploy an elastic load balancer over several Password Vault
Web Access instances:
Enable the PVWA to work in a load balancer environment

Enable PVWA in load balancer environment
1. In the PVWA PVConfiguration.xml configuration file, set the following
values:
UseRelativePath=Yes
LoadBalancerFullPath=<The full path of the Load balancer, according to
the record that was defined in Route 53>
Note:
In the path, specify either http:// or https:// as a prefix
2. Provide a simple html page for the load balancer health check functionality
and save it in the IIS root folder of the PVWA instance.

1. Use AWS best practices to create an Elastic Load Balancer that fits a web
application.
2. Configure a sticky session for the classic load balancer.

Change Server Keys

The ChangeServerKeys utility is used to change the main keys of the Vault server, and
re-encrypt Vault data and metadata that were encrypted with the old keys. You can use
new keys that support a different algorithm, and change the encryption algorithm used to
encrypt the Safes. The activities carried out by the utility are written to a log file, and
stored in the same folder as the utility.
Note:
To ensure security of the keys, it is recommended to follow AWS best
practices and store them in KMS.
To change the server keys

1. On the Vault server, upload the following keys to the VaultInternal Safe:
Key Description
The previous The PrivateKey that was paired with the PublicKey that has
PrivateKey been used to encrypt files until now.
The new The new PublicKey that will be used to encrypt files from
PublicKey now on.
2. Replicate the previous PrivateKey and the new PublicKey to other machines
in your environment, such as DR machines.
3. On the DR machine(s), make sure that the DR replicated the keys:
a. Restart the DR service to initiate a replication.
b. Make sure that the keys were replicated. Check the padr.log, and
make sure that the keys are in the correct folder on the file system.
4. Stop the DR service.
On the Primary Vault server:
5. Stop the PrivateArk Server service.
6. Run the ChangeAwsKeys.command, as described in ChangeAwsKeys
command, page 48.
7. Start the PrivateArk Server service.
On the Disaster Recovery server:
8. Copy the following files from the Primary Vault to the DR Vault:
%KEYS%\KMS\server.key
%KEYS%\KMS\newUUID.txt
Caution:
Make sure you don’t delete the old server.key as DBParm.ini

48 Change Server Keys
must point to it. The ChangeAwsKeys command will replace

these files safely.
9. Run the ChangeAwsKeys command, as described in ChangeAwsKeys

command, page 48.
10. Start the DR service.
On both the Primary Vault server and the Disaster Recovery server:
11. After the ChangeAwsKeys command has finished successfully, we
recommend that you delete the keys from the VaultInternal Safe.
Note:
If the ChangeAwsKeys utility process fails, we strongly recommended that you
delete the new KMS key that was created as it is not relevant.
If the ChangeAwsKeys utility process succeeds, you can decide whether to keep
or delete the old KMS key. You might need it in the future to recover old files that
were encrypted before you changed the server keys.
Whenever you delete the KMS key, make sure you are not mistakenly deleting
the KMS key which is used at the moment.
ChangeAwsKeys command
The ChangeAwsKeys command has the following options.
Note:
If a mandatory option is not specified, the default value will be used.
Command /IsPrimaryorDR
Description Whether the site role is Primary or DR.
Mandatory Yes
Default None
Command /KMSRegion
Description The name of the region in which to store the KMS Key.
Mandatory No
Default The region where the previous key is stored.
Command /RecPrvPath
Description The path in the Safe of the recovery private key.
Mandatory No
Default Root\RecPrv.key
Command /RecPubPath

Description The path in the Safe of the recovery public key.
Mandatory No
Default Root\RecPub.key
Command /ServerKeyPath
Description The path of the server key that is generated by the master.
This is only relevant for the DR Vault. However, it must be specified when
changing keys on the Primary Vault, even though it will be ignored.
Mandatory Yes
Default -
Command /UuidPath
Description The path of the CSK_UUID.txt file that is generated by the master.
This is only relevant for the DR Vault. However, it must be specified when
changing keys on the Primary Vault, even though it will be ignored.
Mandatory Yes
Default -

50 General Limitations
Limitations
General Limitations
■ Configure all Vaults that share the same architecture to access the same KMS,
regardless of its region. In DBParm.ini on the Primary Vault and all DR Vault, set the
KMSRegion parameter to the same value. For details about the regions, see Region
Names, page 64.
■ Currently, HSM is not supported.
Vault
■ High Availability for the Vault is not supported.
■ The DR module, deployed on the primary Vault instance as a fail-back scenario, is
not configured with a separate DR user. A manual procedure is required:
a. From the Private Ark Client, create a new DR user. The user type is defined in
your license for the fail-back scenario.
b. Add the user to the DR users group.
c. Create a Cred File for the new user. For details see AppendixA: Creating
Credential Files in the Privileged Account Security Installation Guide.
■ You can deploy one DR instance. Multiple DR instances are not supported.
■ This version does not support changing the server keys after they have been
generated as part of the initial configuration process.

Components
Disaster recovery configuration

To use the DR Vault, you will need to manually add the DR address to the Vaut.ini file of
each component.
Deploy only one instance of each component

When using CloudFormation you can only automatically deploy one instance of each
PAS component.
Deploying additional components, requires manual steps. For details on deploying
multiple PSM instances, see Launch multiple Privileged Session Manager instances,
page 40. To deploy multiple instances of CPM and PVWA, refer to the Privileged
Account Security Installation Guide.
CPM and PVWA

When working with AMIs in version 9.9.5, the CPM, Scanner & Task Scheduler services,
and the PVWA Task Scheduler service are run by the SYSTEM user, which is not in line
with CyberArk's hardening best practices.
To finalize hardening for CyberArk components, do the following :
Components that include CPM
1. Set a complex password for the cpmsrv user.
2. Open Microsoft Services, and modify the CPM and the Scanner services to run
with the cpmsrv user, instead of the SYSTEM account. Provide the password
that you set in the previous step.
3. Restart the CPM and Scanner services.
Components that include PVWA
1. Set a complex password for the schedtasksrv user
2. Open Microsoft Services, and modify the Task Scheduler service to run with the
schedtasksrv user, instead of the SYSTEM account. Provide the password that
you set in the previous step.
3. Restart the Task Scheduler service.
PSM
The Components AMI does not come with the RemoteApp feature installed.
The hardening policy used for the PSM does not support the PSM to be a member of a
Domain.

52 PSMP
PSMP
Currently, AD bridge is not supported in PSMP that is installed on AWS.

53
Appendices
In this section:
Prepare the AWS Environment Manually
Region Names

Prepare the AWS Environment Manually

The following section describes the process for manually creating the architecture
discussed in the AWS Architecture for PAS Deployment, page 5 section. This
environment can be created automatically according to the procedure described in
Create the CyberArk Environment Automatically on AWS, page 26.
Create a VPC for the Privileged Account Security Vault

This section describes how to configure a virtual private cloud (VPC) with a public subnet
and private subnets. The instances in the public subnet can send outbound traffic directly
to the Internet, whereas the Vault instances in the private subnets cannot. Instead, the
Vault instances in the private subnets can access the Internet by using a network address
translation (NAT) gateway that resides in the public subnet. The Vault servers can
connect to the Internet to access the AWS KMS service using the NAT gateway, but the
Internet cannot establish connections to the Vault servers.
Create the VPC
1. Open the Amazon VPC console
2. From the navigation pane, select Your VPCs > Create VPC.
3. Enter a Name tag for the Vault VPC.
4. Enter an IPV4 CIDR block. For example, 10.0.0.0/16 allocates 65536 IP
addresses for your instances.
5. Select Yes, Create.
Create the main Vault subnet
1. From the navigation pane, select Subnets > Create Subnet.
2. Enter a Name tag for the private Subnet where the Vault main instance will
reside, select the Vault VPC and select an Availability Zone.
addresses within this Subnet.
Create the Vault DR subnet
2. Enter a Name tag for the private Subnet where the Vault DR instance will
reside.
Note:
Select the Vault VPC and select an Availability Zone. The Availability
Zone should be a different zone from the one from you selected for the
main Vault Subnet

55 Prepare the AWS Environment Manually

Create and configure the NAT gateway

Create the public subnet for the NAT gateway:
2. Enter a Name tag for the public Subnet where the NAT Gateway will
reside. Select the Vault VPC and select an Availability Zone.
3. Enter an IPV4 CIDR block. Ror example, 10.0.3.0/24 allocates 256 IP
Attach an internet gateway to the Vault VPC
1. In the navigation pane, Select Internet Gateways > Create Internet
Gateway.
2. Optionally, in the Create Internet Gateway dialog box, you can name your
Internet gateway. Select Yes, Create.
3. Select the Internet gateway that you just created and select Attach to VPC.
4. In the Attach to VPC dialog box, select your VPC from the list.
5. Select Yes, Attach.,
Create the NAT gateway
1. In the navigation pane, select NAT Gateways > Create NAT Gateway.
2. In the Create NAT Gateway dialog box,
a. Specify the subnet to create the NAT gateway.
b. Select an Elastic IP address to associate with the NAT gateway.
c. Select Create a NAT Gateway.
The created NAT gateway displays in the console. After its status changes to
Available it is ready for you to use.
Modify the routing tables for the private subnets
After you complete this procedure, there are two Route Tables, one for the public
Subnet and one for the Vault private Subnets.
1. From the navigation pane, select >Route Tables > < the main Route
Table for the Vault VPC. This Route Table is for the private subnets.
2. Select the details pane to display the details for the Route Table.
3. On the Routes tab, choose Edit and add the following route:
Destination Target
0.0.0.0/0 nat-gateway-id

4. Select Save.
5. On the Subnet Associations tab, select Edit. Select the private subnets.
6. Select Save.
Create a new route table for the public subnet
1. Choose Create Route Table.
2. Optionally, in the Create Route Table dialog box, name your Route Table.
Select the Vault VPC .
3. Select Yes, Create..
4. Select the Route Table that you just created.
5. On the Routes tab, choose Edit and add the following route:
Destination Target
0.0.0.0/0 internet-gateway-id
6. Select Save.
7. On the Subnet Associations tab, choose Edit and select the public subnet.
8. Click Save.
When you created the NAT instance, it used the default Security Group for the
VPC. Associate the NAT instance with a dedicated Security Group instead.
Create the Security Group for the Vault instances
1. Open the Amazon VPC console.
2. From the navigation pane, select Security Groups > Create Security
Group.
3. Specify Vault-SG as the name of the security group, and enter a description.
For VPC, select the ID of the Vault VPC.
4. Click Yes, Create.
5. Select the Vault-SG security group that you created. The details pane
displays the details for the security group, and the tabs for editing the
inbound and outbound rules.
6. On the Inbound Rules tab, select Edit to add rules for inbound traffic:
Rule
Protocol/Po Mandator
descriptio IP address Remarks
n rt y
Vault TCP/1858 ■ Vault Yes Allows

Protocol subnets communicati
on between
Vaults
■
Vault TCP/1858 Yes Allows
Componen
Protocol communicati
t subnets
on from
■ Admin CyberArk
subnets components
■ Web to the Vault

Rule
Protocol/Po Mandator
descriptio IP address Remarks
n rt y
subnets
ICMPv4 ICMPv4 ■ Vault Yes Allows the

subnets DR
components
to monitor the
Primary Vault
Remote TCP/3389 ■ Vault Yes Allows the

Desktop UDP/3389 Manageme Vault
nt Instance administrator
■ Admin to connect to
subnets the Vault with
RDP through
the Vault
management
instance
Remote TCP/9022 Remote Control No Must be

Control Client IP opened if the
Agent Remote
Control
Agent is
configured on
the Vault
7. Click Save
8. On the Outbound Rules tab, select Edit to add rules for outbound traffic:
Rule Protocol/Port IP address

description
Mandatory Remarks
Vault TCP/1858 ■ Vault Yes Allows

Protocol subnets communication
between Vaults
ICMPv4 ICMPv4 ■ Vault Yes Allows the DR

subnets components to
monitor the
Primary Vault
HTTPS HTTPS/443 0.0.0.0/0 Yes Allows

outbound communication
from CyberArk
instances to
AWS services
Syslog TCP/514 Syslog Server No Must only be

outbound IP opened if Syslog
(TCP) is integrated
with the Vault (in
TCP mode)
Syslog UDP/514 Syslog Server No Must only be

outbound IP opened if Syslog
(UDP) is integrated
with the Vault (in
UDP mode)

Rule Protocol/Port IP address

description
Mandatory Remarks
LDAPS TCP/636 LDAP Server No Must be opened

outbound IP if the Vault is
integrated with
an LDAP server
(port=636)
RADIUS TCP/1812 RADIUS No Must be opened

outbound Server IP if the Vault is
integrated with a
RADIUS server
SMTP TCP/25 SMTP server No Must be opened

outbound IP if the ENE
service is
configured to
send mails from
the Vault
SMTP UDP/162 SNMP server No Must be opened

outbound IP if the Remote
Control Agent is
configured to
send SNMP
traps from the
Vault
9. Select Save.
Create a VPC for the PAS components

This section describes the configuration for a virtual private cloud (VPC) with private
subnets for the PAS components. To use the “One-click Installation”, provide a
connection from this VPC to the AWS managed services We recommend creating a
NAT Gateway that resides in a public subnet. This is similar to the Vault VPC
configuration.
Create the components VPC
1. Open the Amazon VPC console
2. From the navigation pane, select Your VPCs > Create VPC.
3. Enter a Name tag for the Components VPC.
4. Enter an IPV4 CIDR block. Ffor example, 10.10.0.0/16 allocates 65536 IP
addresses for your instances.
Create the first components subnet
2. Enter a Name tag for the private Subnet where the PAS Components
instances will reside. Select the Components VPC and select an
Availability Zone.


Create the second components subnet:
2. Provide a Name tag for the private Subnet where the PAS Components
instances will reside, choose the Components VPC and choose an
Availability Zone.
Note:
Availability Zone should be in different zone from the one you chose in
the previous Vault Subnet
3. Enter an IPV4 CIDR block For example, 10.10.2.0/24 allocates 256 IP

Create and configure the NAT gateway

For details, see Create and configure the NAT gateway, page 55.
Create Security Groups for the components instances
1. Open the Amazon VPC console .
2. From the navigation pane, select Security Groups > Create Security
Group.
3. Specify the name of the security group, and enter a description. For VPC,
select the ID of the Components VPC.
5. Select the security group that you created. The details pane displays the
details for the security group, and tabs for editing the inbound and outbound
rules.
6. On the Inbound Rules tab, select Edit to add rules for inbound traffic:
PVWA Security Group
Role Protocol/Port Source Mandatory Remarks
Security Group Name: PVWA-SG
Web interface TCP/443 PVWA Yes Access to PAS users
PSM Security Group
Protocol/Port
Role Source Mandatory Remarks
Security Group Name: PSM-SG
Incoming TCP/3389 All client Yes RDP

connections machines session
from

Protocol/Port
Role Source Mandatory Remarks
client
machines
PSMP Security Group
Role Protocol/Port Source Mandatory Remarks
Security Group Name: PSMP-SG
Incoming TCP/SSH All client Yes SSH

connections machines session
from
client
machines
7. Click Save
8. On the Outbound Rules tab, select Edit to add rules for outbound traffic:
Note:
It is mandatory to set all the following rules
CPM Security Group
Role Protocol/Port Destination Remarks
Security Group Name: CPM-SG
Vault TCP/1858 Vault

communication
Managed White list of the All managed Manage

targets minimum targets passwords on
required set of target devices
protocols
HTTPS HTTPS/443 0.0.0.0/0 Allows

from CyberArk
instances to AWS
services
PVWA Security Group
Protocol/Port
Role Destination Remarks
Security Group Name: PVWA-SG

communication

Protocol/Port
Role Destination Remarks
outbound communication from

CyberArk instances
to AWS services
PSM Security Group
Security Group Name: PSM-SG

communication
Managed White list of the All managed Enable

targets minimum targets connections to
required set of target devices
protocols

from CyberArk
instances to AWS
services
PSMP Secutity Group
Security Group Name: PSMP-SG

communication
Managed SSH/22 All managed Enable connections

targets targets to target devices

outbound communication from
CyberArk instances
to AWS services
9. Select Save.

Configure peering between the VPCs

To connect between the Vault instances and the Components, we configure peering
between these VPCs. A VPC peering connection is a networking connection between
two VPCs that enables you to route traffic between them using private IPv4 addresses or
IPv6 addresses. Instances in either VPC can communicate with each other as if they are
within the same network.
Create a VPC peering connection in your account:
1. Open the Amazon VPC console .
2. From the navigation pane, select Peering Connections > Create VPC
Peering Connection.
3. In the Peering Connections dialog box, configure the following
Name tag: Optionally, you can name your VPC peering connection.
Doing so creates a tag with a key of Name and a value that you specify.
Local VPC to peer: Select the Components VPC in your account you
want to create the VPC peering connection.
Select a VPC to peer with: Ensure My account is selected. Select the
Vault VPC from VPC. Only VPCs in the current region are displayed.
4. Select Create VPC Peering Connection.
Note:
Ensure that your VPCs do not have overlapping IPv4 CIDR blocks. If they
do, the status of the VPC peering connection is set to failed
5. In the confirmation dialog box, select OK.

6. Select the VPC peering connection that you created. Select Actions >
Accept Request.
7. In the confirmation dialog, Select Yes, Accept.
8. In the second confirmation dialog, select Modify my route tables now to
directly go to the route tables page, or select Close to do this later.

Update the routing tables for a VPC peering connection

To send traffic from your instance to an instance in a peer VPC using private IPv4
addresses, add a route to the route table associated with the subnet in which the instance
resides. This route points to the CIDR block, or portion of the CIDR block, of the other
VPC in the VPC peering connection.
In this configuration, you should edit the Routing Tables of both the Vault private
Subnets and the Components private Subnets.
Update routing tables
1. In the navigation pane, choose Route Tables.
2. Select the route table associated with the private Components Subnets.
Note:
If you do not have a route table associated with that subnet, select the
main route table for the VPC, as the subnet then uses this route table by
defaul
3. Select Routes > Edit > Add Route.

4. For Destination, enter the IPv4 address range to direct network traffic in the
VPC peering connection. You can specify the entire IPv4 CIDR block of the
Vault VPC, a specific range, or an individual IPv4 address, such as the IP
addresses of the Vault instances with which to communicate. For example, if
the CIDR block of the Vault VPC is 10.0.0.0/16, you can specify a portion
10.0.0.0/28, or a specific IP address 10.0.0.7/32.
5. Select the VPC peering connection from Target. Click Save.
6. Select the route table associated with the private Vault Subnets.
7. Select Routes > Edit > Add Route.
8. For Destination, enter the IPv4 address range to direct network traffic in the
VPC peering connection. You can specify the entire IPv4 CIDR block of the
Components VPC, a specific range, or an individual IPv4 address, such as
the IP addresses of the Components instances with which to communicate.
For example, if the CIDR block of the Components VPC is 10.10.0.0/16, you
can specify a portion 10.10.0.0/28, or a specific IP address 10.10.0.50/32.
9. Select the VPC peering connection from Target. Click Save.

Region Names
The Vault supports the following KMS services:
AWS Region Value
US East (Ohio) us-east-2
US East (N. Virginia) us-east-1
US West (N. California) us-west-1
US West (Oregon) us-west-2
Asia Pacific (Mumbai) ap-south-1
Asia Pacific (Seoul) ap-northeast-2
Asia Pacific (Singapore) ap-southeast-1
Asia Pacific (Sydney) ap-southeast-2
Asia Pacific (Tokyo) ap-northeast-1
EU (Frankfurt) eu-central-1
EU (Ireland) eu-west-1
EU (London) eu-west-2

Deploying Privileged Account Security On Amazon Web Services PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Deploying Privileged Account Security On Amazon Web Services PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Deploying Privileged Account

Security on Amazon Web Services

Copyright © 1999-2017 CyberArk Software Ltd. All rights reserved.

Amazon Web Services 4

Privileged Account Security

Configure the load balancer in PVWA as a new Privileged Session Manager

Privileged Account Security

Amazon Web Services

Deploy CyberArk's Privileged Account Security solution on Amazon Web Services

Privileged Account Security

AWS Architecture for PAS Deployment

This reference architecture establishes a set of recommendations and best practices

Centralization of Enterprise cloud footprints can consist of tens, hundreds, or even

Modular The approach to enterprise cloud architecture widely varies among

Enable Recognizing that cloud workloads are often automated, our

Privileged Account Security

Protect internet- One key difference between the traditional on-premises

Use a different IP To avoid the possibility of address conflicts as the number of

Privileged Account Security

Privileged Account Security

Privileged Account Security

Privileged The administrative VPC provides an isolated Central Policy Manager

Privileged Account Security

Extending the On-Prem deployment to cloud

Privileged Account Security

Cloud committed but retains an on-premises Vault

Privileged Account Security

Resource account connectivity

Privileged Account Security

Shared VPN (Transit) VPC

Privileged Account Security

Direct VPN between components and resources

Privileged Account Security

This topic describes security measures implemented to deploy CyberArk components

Access the Vault

Vault keys in the cloud

Privileged Account Security

Amazon KMS authorizations

Password delivery infrastructure

Privileged Account Security

Privileged Account Security

Instance profiles creation

VaultBootstrapKMSPolicy Grants instances permission to perform

VaultInstancesKMSAccess Grants instances permission to perform

VaultParametersBucketAccess Grants instances permission to Get Objects

VaultInsancesDeployBucketAccess Grants instances permission to Get and to

ComponentInstancesDeployBucketAccess Grants instances permission to Get and

Privileged Account Security

Vault Administrator password from the

Instance roles creation

VaultInstanceRole For Vault and Vault DR

ComponentInstanceRole For CPM, PVWA, PSM and

Access Policies Creation

VaultInstancesKMSPolicy Give permissions to encrypt

VaultBootstrapKMSPolicy Give permissions to create

InstancesS3VaultParametersBucketPolicy Give access to the bucket

VaultInstancesS3DeployBucketPolicy Give access to the deploy

ComponentsInstancesS3DeployBucketPolicy Give access to the deploy

Privileged Account Security

Stack deletion policy

Instances: ■ Vault instance

Instance profiles: ■ Vault instance profile

Roles ■ Vault instance role