We all know that a gap remains between what companies want to get out of DevOps and the day-to-day realities of working on an IT team.
The concept of self-service infrastructure is very popular in the DevOps world. Teams want the ability to launch a cloud server or an entire test/dev environment on their own without having to wait. But what’s the reality of governing a self-service infrastructure system? How do you ensure that the correct guardrails are in place and that HIPAA auditors don’t find a bunch of non-compliant resources launched by a rogue developer?
All the major cloud platforms have offered solutions to this problem. In this post, we’re going to outline how simple it is to automate the delivery of secure, HIPAA compliant AWS resources with AWS Service Catalog.
Operating in the public cloud removes many of the traditional barriers to provisioning new resources. Theoretically, you could give your entire IT team administrative access to your cloud platform, and you’ve got “self-service.”
Unfortunately, many companies do this. But you can’t afford to if you need to be HIPAA compliant.
Ideally, you’d give each engineer or developer exactly the resources they need — but pre-configured with your desired security controls. That’s exactly what tools like AWS Service Catalog provide.
If you create an AWS Service Catalog, here’s what the finished product might look like:
AWS Service Catalog is a very simple technology, providing your IT team with a catalog of multiple products and allowing engineers to launch products with a single click. You can also integrate AWS Service Catalog with ServiceNow so users can request AWS services and resources through the platform.
Who has the power to launch a product through AWS Service Catalog? That is dictated by policies in Identity and Access Management (IAM). You can determine which engineers have access to launch which stacks or develop custom stacks for different teams. You can share Service Catalog products across multiple AWS accounts.
Each item in AWS Service Catalog is an AWS CloudFormation template. Whether you use AWS or another platform, your catalog will be made up of templates. An infrastructure template is a very simple concept: You tell the cloud platform what you want the environment to look like (in JSON), and the platform takes care of performing the manual actions of provisioning those services.
In other words, your administrators create the templates, and your end users launch live infrastructure based on the template, on demand.
A template can describe a single instance or a complex, multi-tier architecture. It can even incorporate 3rd party services and can be used to launch container clusters. Anything you can build in the console, you can templatize in CloudFormation. If your team builds instances from machine images or bootstraps instances with configuration management, you can kick off the bootstrapping process in CloudFormation.
Even if you’re not doing self-service, CloudFormation should always be the foundation of any build you do in AWS. Rather than launching resources in the AWS console, you should write CloudFormation templates. Ideally, it should also be the default way that you update a stack by rewriting and then relaunching the environment rather than making a change on individual resources. (This philosophy is often called immutable infrastructure.) Mature organizations usually nest CloudFormation templates, either by function or team, so that you have these modular pieces of your stack to assemble into a complete architecture.
Hand-coding JSON is not a pleasant experience, but it’s not complicated. You can get a head start with prebuilt templates. Once you complete your CloudFormation templates, uploading to Service Catalog is as simple as giving the product a name and assigning access.
Need more flexibility in your templates? Check out new tools like Sparkleformation or StackMaster which can be used to further abstract and control the stacks created. Other tools such as Terraform take a different approach by accessing the API directly and not using CloudFormation. Terraform is a wonderful solution for companies managing environments outside of, or in addition to, AWS. But having tools that generate CloudFormation as a base allow you to move between AWS-centric solutions as needed, while keeping the underlying work intact.
Imagine a world where you know that every system in your environment is built from an approved, HIPAA-compliant template. That at a moment’s notice, you could check a single template to learn the security configurations of multiple environments — even across accounts. That’s the power of maintaining a catalog of templates.
Ideally, you’re not just using these templates to build out an environment once. Rather than manually changing your environment, your engineers will change the template and relaunch the entire stack. That means your template is always a true reflection of the configuration of your live systems. Security professionals love this and your HIPAA auditors will too.
Using a catalog of templates also has obvious benefits for your security engineers’ workloads. Once they approve a template or it is audited for HIPAA compliance, it can be reused multiple times without having the security team review every AWS resource or environment. At Logicworks, we have a catalog containing hundreds of templates that have passed HIPAA and HITRUST audits. Whenever we build something new, we always rely on a firm foundation of previously-audited templates.
Of course, giving anyone self-service access always comes with risks. This is where smart access controls become crucial. You can also use a tool like AWS Config Rules to set rules, such as requiring encryption on any object uploaded to S3 with a specific tag.
We recently worked with NextGate, the #1 EMPI platform, to SaaS-ify their applications on AWS. It had taken them 2-3 months to onboard a customer because of complex on-premises software installations, but they now onboard a customer in less than a day on AWS.
The secret to these faster onboarding times? AWS Service Catalog.
We helped them write an AWS CloudFormation template that built out an AWS environment with NextGate software pre-installed and put that template as a product in AWS Service Catalog. The initial process of designing this “ideal” template took time. NextGate needed to maintain HIPAA compliance and is planning to get HITRUST certified so everything was built to the highest standards. The template, built out VPCs, Bastions, databases, EC2 instances, etc., kicked off the instance bootstrapping process and pulled the most recent version of their software. Other tools for access, logging, and monitoring were automatically set up.
The AWS environments for each of their customers is nearly identical, so NextGate only has to launch the product through Service Catalog, make a few customizations, and the environment is ready for their customer. They now have dozens of customers running in separate AWS environments, each launched by a Service Catalog product.
The benefits of this system for compliance are clear. Since every environment is built from the same template, NextGate can be confident that all of their environments are built to HITRUST standards. This reduces their audit scope; auditors only have to assess one core set of services to understand the configuration of each system. They also put scanners in place to alert them if configurations deviate from the ideal state.
As you can imagine, this confidence around compliance is also attractive to NextGate’s end customers, hospitals, and other healthcare organizations that also must meet HIPAA standards.
Most highly-regulated companies think that self-service is dangerous, imagining a “wild west” where developers can launch their own servers and mistakenly expose sensitive data. But tools like AWS Service Catalog, controlled and integrated with the right access configurations, can actually improve standardization across your cloud environments and promote stronger security practices.
Time invested up front developing and maintaining templates will serve you well in the long term, especially if you build out new cloud resources frequently. We encourage everyone to check out, and start experimenting with, these tools. Trust us, your IT team will be much better governed and less stressed as a result.
Logicworks helps healthcare companies design, manage, and optimize AWS environments for HIPAA and HITRUST compliance. We are an AWS Premier Partner, HITRUST CSF certified, and have worked with hundreds of healthcare companies on AWS. To learn more, contact us at www.logicworks.com.