AWS Startups Blog
AWS Migration Strategy for VirtualHealth’s Leading Healthcare SaaS Platform
Guest post by Michael Chatzopoulos, Vice President of Information Security & Infrastructure, VirtualHealth
VirtualHealth provides a SaaS platform to a number of the largest and most innovative healthcare organizations in the country that empowers care managers to optimally service patient needs. The platform hosts personal health information (PHI), meaning data security and integrity are paramount. Upon a thorough review of the data hosting landscape, we determined that AWS offered a compelling set of value propositions, including:
· Ability to quickly spin up a de-identified environment to troubleshoot issues without exposing PHI
· Uptime management in the event of a regional outage
· Comprehensive access management for both PHI and non-PHI environments
· Compliance with key HITRUST Certification requirements
We worked closely with our DevOps teams and AWS to develop a multi-account strategy within an AWS Control Tower (CT). In order to isolate, strictly control access, and protect PHI, we created wholly separate PHI and Non-PHI accounts and housed each type of account in a separate OU within the CT. The OU hosting PHI accounts were then configured with far more restrictive SCPs and user policies.
Harnessing the Infrastructure-as-Code model, we are able to deploy our platform instances based on the type of data intended for each environment. The deployments are automated and utilize multiple Availability Zones (AZs), Application Load Balancers (ALBs), and Autoscaling groups to ensure high availability. Cross-region replication supports regional outages, and the service control policies (SCPs) ensure our teams can fulfill their mission while remaining at least privilege.
Overview of solution
Our goal for this project was to migrate our applications to the AWS Cloud. The proposed solution was a lift and shift to start harnessing key services, including Amazon EC2 instances, Autoscaling Groups, ALBs, and Amazon Relational Database Service (Amazon RDS), while preparing to bring online AWS Lambda, Amazon Elastic Kubernetes Service (Amazon EKS), AWS Fargate, and AWS App Mesh to optimize intelligent automation of the available IaaS. We also identified strategic opportunities to streamline certain deployment processes, optimize business vs. non-business hours performance, and introduce more interlocked security and availability tools.
Solution Highlights
We put together a comprehensive project plan for the build, including:
· Control Tower design
· Application Infrastructure design and coding
· Data De-Identification
Control Tower Design and Implementation
To optimize data control, we opted to deploy an AWS CT. The CT offers a central logging location, provides requisite access controls and user roles, and ensures a repeatable process when deploying and managing accounts.
· In addition to the standard AWS accounts created as part of the CT, we built out capabilities relating to both shared and network services
Our OU design was predicated on our prime directive to ensure the protection of PHI, meaning the use of multiple OUs, including:
· Development OUs – used as a testing ground for engineering teams to test various solutions
· Non-PHI OUs – used by a designated subset of engineering teams with all data fully de-identified in accordance with HIPAA standards. The environments are deployed using the same infrastructure code but operate on a smaller scale given their limited resource needs.
· PHI OUs – used exclusively by vetted, authorized personnel. Access to these accounts is the most restrictive with SCPs that limit based on geography, user role, and other attributes.
Application Infrastructure and Coding
Infrastructure-as-Code is a requirement. No changes are made to OU accounts unless they are written and deployed as code, subject to rigorous security controls and testing. Our vending machine is made of a catalog of deployments based on client resource requirements. The Non-PHI accounts are size-adjusted appropriately to use fewer AZs and smaller EC2 instances, given their narrower use case.
Data De-Identification
Access to the PHI is always treated with the utmost security and care. We limit the number of users to those who need access only, with least privilege rules and comprehensive technical controls in place. Encryption in transit, encryption at rest (RDS and S3 Bucket encryption), and field-level encryption, are just some of the security features available in AWS to ensure data is secured at all points during processing.
To enable Non-PHI environments used for support and testing activities, we developed a comprehensive solution that includes the following:
1. Backups to an Amazon Simple Storage Service (Amazon S3) bucket
2. Designated servers to retrieve backups and de-identify the data based on Safe Harbor processes
3. Re-encryption of de-identified data using appropriate keys
Conclusion
We migrated to the cloud to meet our clients’ needs with regard to a more secure, resilient, and performant environment. Embracing the AWS Control Tower, with its built-in guardrails and automated provisioning has enabled our systems, software, and DevOps teams to focus their energies on value-added activities. The multi-account strategy that we have deployed offers a means to control, monitor, and manage access to both PHI and other types of confidential and sensitive data. Infrastructure-as-Code allows us to deploy the platform consistently, repeatably, and efficiently, increasing our teams’ productivity and reducing errors. We are continually improving and securing our environments and look forward to continuing to leveraging the latest in AWS technology to progress that mission.
About the Author
Michael Chatzopoulos is the VP of Information Security and Infrastructure at VirtualHealth. He has spearheaded highly complex IT projects for over 15 years and is passionate about applying new technologies to solve real-world challenges for both businesses and consumers. In his spare time, Michael is an avid alpine climber and dedicated father of two.