AWS 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 recommend 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.

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.

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:

AWS System Manager (SSM) Parameter Store

The template creates a new parameter, in the Parameter Store, to securely store and transfer passwords only to the Vaults and components.

SSM policy

The SSM parameter is protected by the SSM Policy with the following statements:

• Allow Put Object and Delete Object requests from LambdaDeployRole. The delete permission allows the StorePasswordLambda function to delete password files when there is a roll back or deletion of the stack.
• Built-in SSM functionality denies all requests that do not use a secure transport.

In addition, there are two roles that have limited access to the SSM parameter:

• VaultInstancesRole has an inline policy (InstancesSSMPolicy) that allows the role to Get the SSM parameter.

• ComponentInstanceRole has an inline policy (InstancesSSMPolicy) that allows the role to Get the SSM parameter.

Lambda function

The template creates a lambda function to insert and delete passwords in the Parameter Store.

StorePasswordLambda (Function) resource creates the function. Creates all resources that are necessary for the deployment process (for example, passwords used for deploying the components).

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

Password storage

Storage passwords are entered through the UI in the parameter store using the lambda function.

A vault requires three separate passwords. The following resources are responsible for storing each password in the parameter store:

• StoreMasterPassword (CustomResource)

• StoreAdminPassword (CustomResource)

• StoreDRPassword (CustomResource)

These resources are implicitly linked to:

• StorePasswordLambda

• LambdaDeployRole

• SSM

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.

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.
InstancesSSMPolicy	Grants instances permission to get parameters from SSM. These permissions are needed to fetch passwords from the parameter store.

ComponentInstanceProfile (InstanceProfile)

This profile is for CPM, PVWA, PSM and PSM for SSH instances and has only one inline policy.

Policy	Description
InstancesSSMPolicy	Grants instances permission to Get parameters from SSM . These permissions are needed to fetch passwords from the parameter store

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 for SSH instances

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 PSMinstance.

6.

PSMPMachine (Instance) resource creates the PSM for SSH 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 ■ PSM for SSH instance
Instance profiles:	■ Vault instance profile ■ Components instance profile
Roles	■ Vault instance role ■ Components instance role
Policies	■ VaultInstancesKMSAccess policy of the Vault instance role

 

In the AIO templates, all resources are deleted during stack roll back or deletion.

Privileged Session Manager

PSM does not require or use AWS IAM role and user data information.

If you need to attach an AWS IAM role or use the userdata's AWS mechanism to transfer sensitive information from the PSM machine for your functionality, you must use AWS recommended security controls to protect access to the machine.

When you connect to a target using a web connection component that connects through a browser, any user can use that browser to retrieve the metadata as well as userdata information.

For more information about security best practices for using the metadata and userdata, refer to the AWS Security Best Practices at https://aws.amazon.com/whitepapers/aws-security-best-practices/.

General

Use the following considerations to provide the best security for the Privileged Access 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.