Migrating from On-Prem to Imprivata Cloud

By moving your VPAM solution to the Imprivata Cloud, Imprivata takes on the administrative burden of managing your appliance from your team. We do all the heavy lifting for you, including:

• Infrastructure management

• Ongoing appliance management

• Security and bug patches

• Monitoring

• Upgrades.

By transferring the infrastructure and appliance management to our team, you maintain the same product functionality, but eliminate the time and hard costs of managing the appliance in your own environment. This frees up additional internal time and resources.

While configuration may be slightly different (such as using a tunneled service for Active Directory (AD) integration in cloud), the functionality and end user experience are identical. There is an added benefit that a cloud deployment will get you to that point much faster and far more easily.

Our cloud deployments leverage the robust infrastructure and reliability of AWS. The built-in redundancy of AWS helps ensure uptime and eliminates the need for complex on-premises high availability deployments that are typically used to ensure infrastructure reliability.

We still offer disaster recovery (DR). This can be either with both servers available in our cloud or we can have your primary server hosted in our cloud environment (with a secondary backup to your on-premises server).

Server specifications for the cloud vary, but the benefit is Imprivata manages that after the migration. If we need to adjust to meet your specific use case needs, we will.

Imprivata coordinates and schedules upgrades with your team to avoid impact on users, but no resources are needed from your side to complete the upgrade. Imprivata manages the full upgrade process and validates connections post-upgrade.

In the unlikely event of an issue, Imprivata will be notified and will be able to connect to resolve that issue, with all access still tied back to a support ticket. However, this is not common, and the environment-level issues that are more likely in on-premises deployments are not a concern in cloud. Imprivata manages any SSL and encryption certificates including the initial configuration and any renewal or rotation. This is the same by default as in on-premises deployments.

Imprivata uses the global infrastructure of AWS, meaning we can deploy the server in the region best suited for your organization. This is typically the region closest to you to minimize latency.

However, we can place the production or failover instance in any region of your choosing, should there be a need to locate this elsewhere. We can accommodate most international deployments where an AWS region is available.

All servers are built to be accessible over the internet so remote users can reach them via their browserusing the server’s DNS. You will be provided a new DNS/URL that follows our cloud standardized guidelines. For example:

CUSTOMER.imprivatacloud.com

By default, AWS SES is deployed with east/west redundancy. Local SMTP servers are not possible with a hosted Imprivata Cloud customer because they are on segregated VPC networks, but publicly accessible customer-supplied SMTP can be supported if requested.

Each cloud deployment is on a standalone EC2 AWS instance. This means system resources are not shared between customers, which ensures both data security and performance reliability.

Standard audit retention is 365 days. You and Imprivata can hold conversations around modifications to the standard configuration in cloud if needed. Individual audit files can be downloaded from the product UI. If you wish to store audit in your own S3 (Amazon Simple Storage Service) for audit retention, that will be available as an option.

Imprivata Cloud uses AWS SES for mail relay.

Your end users won’t see a difference and your network team will only see a difference in where the data flows. Any Gateways or Gatekeepers you have deployed today will still be used and will instead connect to your cloud appliance, rather than one deployed locally in your Demilitarized Zone (DMZ) network.

Traffic remains encrypted and tunneled to keep it secure between endpoints, regardless of whether it goes through your DMZ or the cloud. Any local integrations needed such as your own security information and event management (SIEM) solution, AD integration, or your privileged access management (PAM) server can be configured to communicate through the encrypted tunnel that your Gateway establishes. That way, there is no need to expose internal resources directly to the cloud.

No authentication changes are needed. If you authenticate today through a single sign-on (SSO) provider or through local accounts, that will continue to function with no configuration changes needed. Any direct integration with AD or lightweight directory access protocol (LDAP) will need a quick update to ensure the tunneling service is utilized. This will use your existing Gateway and require no new deployments, taking only a few minutes to configure.

If you have an SSO provider that you’re currently not leveraging for user authentication, this is often a great time to migrate. Using your SSO provider helps ensure that your authenticating users are all undergoing the level of multi-factor authentication (MFA) or verification you already require for other applications. It also helps you keep all user authentication centralized. Switching from direct AD integration to SSO integration doesn’t have to impact users. We can configure those in tandem for you to test. You can then switch users over as you see fit. When moving to SSO, the user will simply be redirected to the SSO authentication they already are familiar with when they enter their username into the login field.

Migrations will take approximately one week, but time to production may vary based on resource availability. We will provide a new IP address, and both the on-premises server and our cloud server will need to meet the standard networking requirements for functionality.

Additionally, Secure Shell Protocol (SSH) bi-directional access between the servers helps facilitate the data transfer for migration preparation. Similar to upgrades, we anticipate a one-hour maintenance window to perform the migration.