Veritas CloudPoint Administrator's Guide
- Getting started with CloudPoint
- Section I. Installing and configuring CloudPoint
- Preparing for installation
- About the deployment approach
- Deciding where to run CloudPoint
- Meeting system requirements
- CloudPoint host sizing recommendations
- Creating an instance or preparing the physical host to install CloudPoint
- Installing Docker
- Creating and mounting a volume to store CloudPoint data
- Verifying that specific ports are open on the instance or physical host
- Deploying CloudPoint
- Deploying CloudPoint in the AWS cloud
- Using plug-ins to discover assets
- Configuring off-host plug-ins
- AWS plug-in configuration notes
- Google Cloud Platform plug-in configuration notes
- Microsoft Azure plug-in configuration notes
- Dell EMC Unity array plug-in configuration notes
- Pure Storage FlashArray plug-in configuration notes
- HPE RMC plug-in configuration notes
- NetApp plug-in configuration notes
- Configuring an off-host plug-in
- About CloudPoint plug-ins and assets discovery
- Configuring the on-host agents and plug-ins
- About agents
- Oracle plug-in configuration notes
- MongoDB plug-in configuration notes
- Microsoft SQL plug-in configuration notes
- About the installation and configuration process
- Preparing to install the Linux-based on-host agent
- Preparing to install the Windows-based on-host agent
- Downloading and installing the on-host agent
- Configuring the Linux-based on-host agent
- Configuring the Windows-based on-host agent
- Configuring the on-host plug-in
- Configuring VSS to store shadow copies on the originating drive
- Protecting assets with CloudPoint's agentless feature
- Preparing for installation
- Section II. Configuring users
- Section III. Protecting and managing data
- User interface basics
- Indexing and classifying your assets
- Protecting your assets with policies
- Tag-based asset protection
- Replicating snapshots for added protection
- About snapshot replication
- About cross-account snapshot replication in the AWS cloud
- Requirements for replicating snapshots
- Cross-account snapshot replication support matrix
- Cross-account snapshot replication limitations
- Configuring replication rules
- Editing a replication rule
- Deleting a replication rule
- Managing your assets
- Creating a snapshot manually
- Displaying asset snapshots
- Replicating a snapshot manually
- About snapshot restore
- About single file restore (granular restore)
- Single file restore requirements and limitations
- Restoring a snapshot
- Additional steps required after a SQL Server snapshot restore
- Additional steps required after an Oracle snapshot restore
- Additional steps required after a MongoDB snapshot restore
- Additional steps required after restoring an AWS RDS database instance
- Restoring individual files within a snapshot
- Deleting a snapshot
- Monitoring activities with notifications and the job log
- Protection and disaster recovery
- Section IV. Maintaining CloudPoint
- CloudPoint logging
- Troubleshooting CloudPoint
- Restarting CloudPoint
- Docker may fail to start due to a lack of space
- CloudPoint installation fails if rootfs is not mounted in a shared mode
- Some CloudPoint features do not appear in the user interface
- Off-host plug-in deletion does not automatically remove file system and application assets
- Disk-level snapshot restore fails if the original disk is detached from the instance
- Snapshot restore for encrypted AWS assets may fail
- Error while adding users to CloudPoint
- CloudPoint fails to revert restored snapshots if indexing, classification, or restore operations fail
- SQL snapshot or restore and SFR operations fail if the Windows instance loses connectivity with the CloudPoint host
- Troubleshooting CloudPoint logging
- Working with your CloudPoint license
- Upgrading CloudPoint
- Uninstalling CloudPoint
- Section V. Reference
About CloudPoint integration with AWS KMS
CloudPoint uses the AWS account credentials (Secret Key and Access Key pair) to connect to the AWS cloud, discover all the assets, and perform operations on those assets. The AWS account details are stored in the CloudPoint configuration in an encrypted format. CloudPoint uses the 256-bit Advanced Encryption Standard (AES) specification to encrypt and decrypt all the configuration information. The encryption keys, also referred to as the coordinator keys, are stored internally in the CloudPoint MongoDB database. This encryption mechanism is used as a default for all CloudPoint deployments, whether on-premise or in the cloud.
Starting with CloudPoint 2.2 release, CloudPoint also provides support for AWS Key Management Service (KMS) for deployments in the cloud. AWS KMS is a managed service that allows you to create and manage encryption keys that are used to encrypt your data. With AWS KMS integration, you can now utilize the AWS KMS service to encrypt and decrypt the CloudPoint configuration information rather than storing the encryption keys internally in the CloudPoint database.
Refer to the AWS documentation for more details on KMS:
https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
When you configure CloudPoint to use KMS, CloudPoint sends a request to KMS to generate a data key that is used to encrypt and decrypt all configuration information such as CloudPoint plug-in configuration, agentless configuration, and application configuration data. KMS provides an encryption key in two forms--a cryptic cipher form and a plain text form. CloudPoint uses the plain text form of the key to encrypt the configuration and then stores the cipher form of the key in the CloudPoint database. The plain text form of the key is completely discarded after the encryption is completed.
To decrypt the configuration information, CloudPoint sends a request to KMS to decrypt the cipher form of the key that resides in the CloudPoint database. KMS decrypts the cipher key and generates the actual key that CloudPoint then uses to decrypt the configuration information. The cipher form of the key that resides in the database can be decrypted only by KMS.
How you configure CloudPoint to use AWS KMS depends on how you deploy CloudPoint in the cloud:
If you deploy CloudPoint manually using the Docker image on an EC2 instance, then you can configure AWS KMS using CloudPoint APIs.
This is a manual procedure that must be performed after successfully installing and configuring CloudPoint on the EC2 instance.
If you deploy CloudPoint using the CloudFormation Template (CFT), then there are no additional steps required.
You specify the AWS KMS Customer Master Keys (CMK) as one of the parameters in the template form. AWS KMS is automatically configured on the CloudPoint instance when you launch the CloudFormation stack.
If you are upgrading from an older release of CloudPoint that did not support KMS, then the default encryption mechanism that was used earlier continues to work as is even after a successful upgrade. However, if you wish to use AWS KMS post upgrade, you can configure AWS KMS using CloudPoint APIs.
Note:
Once you configure KMS, you cannot disable it or go back to using the default encryption method, in the same CloudPoint deployment.
The following conditions are applicable to CloudPoint integration with AWS KMS:
CloudPoint supports AWS KMS customer managed Customer Master Keys (CMK) only. AWS owned CMK and AWS managed CMK keys are not supported.
AWS KMS integration is available for CloudPoint deployments in AWS cloud only. This is not supported for on-premise deployments as well as deployments in other cloud environments.
You must not delete the Customer Master Keys (CMK) that are used for KMS configuration in CloudPoint. If the keys are lost, your CloudPoint configuration may be irrecoverable and you may have to redeploy your entire CloudPoint environment.