Skip to main content

N2WS CPM

Visualize your N2WS Backup & Recovery (CPM) deployment in JupiterOne — the AWS accounts configured in CPM, backup policies and the schedules they use, the resources each policy protects, and resource control (power management) groups with the EC2 instances and RDS databases they start and stop — map CPM accounts and protected resources to the AWS accounts, instances, volumes, and databases ingested by the JupiterOne AWS integration, find AWS resources that no backup policy protects, and monitor changes through queries and alerts.

Installation​

This integration connects to your N2WS Backup & Recovery (CPM) server using the N2WS RESTful API and ingests the AWS accounts configured in CPM, backup policies, backup schedules, protected resources, and resource control (power management) groups with the resources they manage. The CPM server runs in your own AWS VPC and is usually reachable only from inside it, so the integration normally runs on a JupiterOne Collector that can reach the server's API over HTTPS (port 443 by default).

The integration authenticates with an API Authentication Key. It exchanges the key at POST /api/token/obtain/api_key/ for a one-hour access token, sends that token as an Authorization: Bearer header on every request, and obtains a new one automatically when it expires. The integration only issues read requests.

Configuration in N2WS​

Before you configure the integration in JupiterOne, prepare the following in the N2WS console:

  • The hostname or IP address of your CPM server. The JupiterOne Collector must be able to reach it over HTTPS.
  • A CPM user to own the API key. The key acts as that user: the integration only sees the accounts, policies, and resources that user can see, so a key created by a delegate of a managed user only returns that managed user's data. N2WS recommends a dedicated delegate user. If you create the delegate with all of its permission options cleared, it is a read-only user that can list information such as policies but cannot change configuration or run recoveries, which is all the integration needs.
  • An API Authentication Key for that user. Sign in to the console as the user, enable API access, and generate the key. The menu location differs between N2WS versions, so see A Beginner's Guide to N2W RESTful API for the steps. The key is only used to obtain access tokens.
  • If the server presents a self-signed or internal-CA TLS certificate, get the CA certificate in PEM format so the collector can verify the connection.

Once you have obtained the information above, proceed to JupiterOne to finalize the integration.

Configuration in JupiterOne​

To install the N2WS CPM integration in JupiterOne, navigate to the Integrations tab in JupiterOne and select N2WS CPM. Click New Instance to begin configuring your integration.

Creating an instance requires the following:

  • The Account Name used to identify the N2WS CPM account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.

  • Description to assist in identifying the integration instance, if desired.

  • Polling Interval that you feel is sufficient for your monitoring needs. You may leave this as DISABLED and manually execute the integration.

  • The CPM Host (required): the hostname or IP address of your CPM server, optionally with a :port, for example cpm.example.internal. Do not include a path. If you paste a URL such as https://cpm.example.internal/api/, the https:// prefix, trailing slash, and /api suffix are removed automatically.

  • The API Authentication Key (required) generated above.

  • Optionally, a CA Certificate to trust a self-signed or internal-CA certificate, or enable Disable TLS Verification to skip certificate validation (not recommended). Both are empty by default.

The integration validates the configuration by obtaining an access token and listing the AWS accounts in CPM, so the key's user must be able to list accounts.

Data Sources​

Each data source can be enabled or disabled on its own. All data sources are disabled by default, so enable the ones you want to ingest. The CPM server itself is always ingested as an n2ws_account entity.

Data SourceDescriptionEntities Created
Backup AccountsAWS accounts configured in N2WS CPMn2ws_backup_account
Backup PoliciesN2WS CPM backup and DR policiesn2ws_policy
Backup SchedulesN2WS CPM backup schedulesn2ws_schedule
Resource Control (Power Management)N2WS CPM resource control groups and the EC2 instances and RDS databases they power-managen2ws_resource_control_group, n2ws_power_managed_resource
Protected ResourcesAWS resources covered by an N2WS CPM backup policyn2ws_protected_resource

The relationships between data sources are built only when both sides are enabled:

  • Backup account to policy (HAS) requires Backup Accounts and Backup Policies.
  • Backup account to resource control group (HAS) requires Backup Accounts and Resource Control (Power Management).
  • Policy to schedule (USES) requires Backup Policies and Backup Schedules.
  • Policy to protected resource (PROTECTS) requires Backup Policies and Protected Resources.
  • Schedule to protected resource (HAS) requires Backup Schedules and Protected Resources.

CPM reports the policies and schedules covering a protected resource by name, so a protected resource is linked to a policy or schedule only when exactly one ingested policy or schedule has that name.

Relationships to AWS entities​

The integration links CPM data to the AWS entities ingested by the JupiterOne AWS integration through mapped relationships. It never creates AWS entities itself, so these relationships only appear for AWS accounts that the AWS integration also ingests.

SourceRelationshipAWS entityMatched on
n2ws_backup_accountISaws_accountAWS account number
n2ws_protected_resource (EC2 instance)PROTECTSaws_instanceInstance ID
n2ws_protected_resource (independent EBS volume)PROTECTSaws_ebs_volumeVolume ID
n2ws_protected_resource (RDS)PROTECTSaws_db_instanceDB instance identifier
n2ws_protected_resource (Aurora)PROTECTSaws_rds_clusterDB cluster identifier
n2ws_protected_resource (Redshift)PROTECTSaws_redshift_clusterCluster identifier
n2ws_power_managed_resource (EC2 instance)MANAGESaws_instanceInstance ID
n2ws_power_managed_resource (RDS database)MANAGESaws_db_instanceDB instance identifier

Only EC2 instances, independent EBS volumes, RDS instances, Aurora clusters, and Redshift clusters are linked to AWS entities. Other resource types that CPM can back up, such as EFS, DynamoDB, FSx, and DocumentDB, are not linked to AWS entities.

Because coverage is expressed as relationships to AWS entities, a query for unprotected resources is only meaningful for AWS accounts that the AWS integration ingests. For example, with the Protected Resources data source enabled, the following query lists EC2 instances that no CPM protected resource covers:

FIND aws_instance THAT !PROTECTS n2ws_protected_resource

With Backup Policies also enabled, the following query lists EC2 instances together with the CPM policy that protects them:

FIND n2ws_policy THAT PROTECTS n2ws_protected_resource THAT PROTECTS aws_instance

Click Create once all values are provided to finalize the integration.

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.

Additional resources​