Professional Documents
Culture Documents
Deploying Privileged Account Security On Amazon Web Services PDF
Deploying Privileged Account Security On Amazon Web Services PDF
Version 10.1
Table of Contents
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.
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.
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.
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
Principle Description
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.
Principle Description
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.
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.
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.
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).
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.
Note:
For this release, configuration recommendations and testing of this approach have not
been completed
Note:
For this release, configuration recommendations and testing of this approach have not
been completed
Security Overview
The Vault
Note:
When configuring the Vault, do not use the AllowNonStandardFWAddress parameter in
DBParm.ini
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.
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.
Instance deployment
The following resources are responsible to create the Vault and component instances
and their security context.
VaultInstanceProfile (InstanceProfile)
This profile is for Vault and Vault DR instances and has the following inline policies:
Policy Description
ComponentInstanceProfile (InstanceProfile)
This profile is for CPM, PVWA, PSM and PSM SSH Proxy instances and has only one inline
policy.
Policy Description
Policy Description
Role Instances
Policy Description
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.
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.
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.
PVWA
CPM
PSM
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.
PSMP
Mid-range
Small implementation Mid-range implementation
implementation
(<100 concurrent (100-200 concurrent
(>200 concurrent
sessions) sessions)
sessions)
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.
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
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.
Users Access CIDR Allowed IPv4 address range for users access to
CyberArk components
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:
Parameter Description
3. Add a new route for each of the following Route Tables, using the command
below.
Components Private Route Table
■
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
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 Agreement
Key Pair
Vault Instance Name Enter a name for the Vault instance. Vault
CPM Instance Name Enter a name for the CPM instance. CPM
CPM instance Type Select the instance type of the CPM instance. c4.large
PVWA instance type Select the instance type of the PVWA t2.medium
instance.
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 SSH Proxy Select the instance type of the PSM m4.large
Instance Type SSH Proxy instance.
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:
Command guide
Parameter Description Action
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: -
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
Note:
AWS backup solutions are not supported.
Components
Property Value
Type https
Port 443
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.
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]>
Parameter Description
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:
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.
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.
Note:
To ensure security of the keys, it is recommended to follow AWS best
practices and store them in KMS.
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
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
Mandatory Yes
Default None
Command /KMSRegion
Mandatory No
Command /RecPrvPath
Mandatory No
Default Root\RecPrv.key
Command /RecPubPath
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 -
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
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.
PSMP
Currently, AD bridge is not supported in PSMP that is installed on AWS.
Appendices
In this section:
Prepare the AWS Environment Manually
Region Names
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
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
Rule
Protocol/Po Mandator
descriptio IP address Remarks
n rt y
subnets
7. Click Save
8. On the Outbound Rules tab, select Edit to add rules for outbound traffic:
9. Select Save.
Note:
Availability Zone should be in different zone from the one you chose in
the previous Vault Subnet
Protocol/Port
Role Source Mandatory Remarks
Protocol/Port
Role Source Mandatory Remarks
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
Protocol/Port
Role Destination Remarks
Protocol/Port
Role Destination Remarks
PSMP Secutity Group
9. Select Save.
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
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
Region Names
The Vault supports the following KMS services:
AWS Region Value
EU (Frankfurt) eu-central-1
EU (Ireland) eu-west-1
EU (London) eu-west-2