How to Use AWS Service Catalog for Code Deployments: Part 2 of the Automating HIPAA Compliance Series

In my previous blog post, I discussed the idea of using the cloud to protect the cloud and improving healthcare IT by applying DevSecOps methods. In Part 2 today, I will show an architecture composed of AWS services that gives healthcare security administrators necessary controls, allows healthcare developers to interact with the system using familiar tools (such as Git), and leverages AWS managed services without the need for advanced coding or complex configuration.

Along the way, I hope to dispel the myth that healthcare security administrators lose control in a DevSecOps environment, and show that healthcare developers can still rely on their administrators without having their development cycles affected adversely.

Architecture overview

The following architecture diagram shows what I will build in this post. The centerpiece of this system is AWS Service Catalog, which is an AWS service that provides a single location where healthcare organizations can centrally manage catalogs of IT services. With AWS Service Catalog, healthcare security administrators can control which IT services and versions are available, limit the configuration of the available services to what is covered under the AWS Business Associate Agreement (BAA), and delegate permissions access by developer or role.

Before diving into the details of how to set up the individual elements of this architecture, I will walk you through the previous diagram and provide a basic overview of how the AWS services fit together to help you manage the lifecycle of your healthcare environment:

1. Starting at the top left of the diagram, the healthcare security administrator defines an AWS Service Catalog product using AWS CloudFormation templates. In this blog post, I will use the example product of a “healthcare web server,” which is simply an Apache web server with a few options enabled that serve as starting points for meeting the customer requirements outlined in the AWS BAA.
2. After the healthcare security administrator defines the healthcare web server, they publish it for healthcare developers in the AWS Service Catalog.
3. As shown on the right side of the diagram, the healthcare developer continues to develop applications under Git source control and use AWS CodeCommit to fully manage the private Git repository.
4. When the developer is ready to push code from Git to their healthcare infrastructure, they can use AWS Service Catalog to find and launch the product they need as a CloudFormation stack.
5. The stack automatically provisions the Git repository specified by the developer.
6. AWS Code Commit contains the source code pushed by the healthcare developers. In the design of this architecture with AWS Service Catalog at the center, healthcare developers can release their source code without needing to have access to any of the underlying resources or going through security administrators.
7. Access to the stack and its underlying resources (such as the web server itself) is recorded and tracked through AWS CloudTrail, and the data is stored in Amazon S3.
8. The healthcare security administrator configures, monitors, and alerts on the health of the stack, its changes, and its access with AWS CloudWatch.
9. As the stack is being changed, change events are recorded and tracked through AWS Config.
10. CloudWatch initiates alarms based on rules you design, which can be used to indicate that something may be out of compliance.
11. CloudTrail monitors all API calls made against the AWS environment.
12. The administrator is notified by CloudWatch when something changes that could cause the system to be noncompliant.

Now that I have reviewed the overall healthcare architecture diagram, I will jump into the details of how to implement this architecture. I will start with the tasks that would typically be performed by our healthcare security administrators.

Creating the architecture: Healthcare security administrators

Enable CloudTrail and AWS Config

From the Management Tool section of the AWS console, the administrator should choose AWS CloudTrail, click Get Started Now, name the S3 bucket in which to store the logs, and then click Turn On. When turned on, API-level logging is enabled for the entire region. It is a best practice to turn on logging in all regions, even if your organization does not plan to use all regions available. As a healthcare security administrator, you want the ability to review all activity and API calls, in the event a region is being used when it should not be. In fact, you may even want to trigger alarms if API calls show up in unexpected regions.

Next, choose AWS Config from the AWS Management Console, and follow the on-screen instructions to set up the service. You can follow these steps if you have questions as you walk though the setup. You will know this task is complete when you see on the right side of the screen that Recording is on.

Set up the healthcare developer accounts

Create a healthcare developer IAM group with the policy AWSCodeCommitPowerUser (as shown in the following screenshot). This policy gives your developers the ability to perform most tasks with the source control service, but it does not give them the ability to delete projects. In addition, add the ServiceCatalogEndUserAccess policy. Specify the products the team has access to in AWS Service Catalog itself. This policy gives the members of the group the ability to use the service as end users.

Set up a healthcare web server in AWS Service Catalog

At the time of this post’s publication, AWS CodeCommit is available only in the US East (N. Virginia) region, so make sure you follow the following steps in the US East (N. Virginia) region so that your AWS Service Catalog product can communicate directly with AWS CodeCommit:

1. Under Management Tools in the AWS Management Console, click Service Catalog.
2. Click Get Started, and then pick a name for your portfolio of products and specify an owner’s name.
3. Click Upload new product in your portfolio, specify a product name such as Healthcare Web Server, and then complete the rest of the required fields.
4. Click through until you see the Version details page. This page is where you can specify the CloudFormation template that defines the infrastructure you wish to make available to your HealthcareDeveloper group. For this example, you can Specify an S3 URL location for an Amazon CloudFormation template by using this CloudFormation template.

Note: I have provided this CloudFormation template as a basic starting point and example of how you can leverage tools to support healthcare needs in a DevSecOps environment. You should customize this template for your own environment.

Now that you have created both your portfolio and your product, confirm that the product name now appears under the Products heading on the portfolio page. From this same portfolio page, give two sets of permissions:

1. Under Add users, groups and roles access, the first set of permissions gives permissions to the group that needs to be able to launch the product you just created. In this example, you can select the HealthcareDeveloper group you created previously, as shown in the following image.
   
2. The second set of permissions is defined under Constraint type. You can find this under the Constraints heading on the portfolio page. These are the permissions you give to AWS Service Catalog to build your product. You need to determine the proper permissions based on the template you build. As an example, you could choose the Launch constraint type (as shown in the following image), which will rely on an IAM role you create in the IAM console.

The IAM role will not only need to contain the permissions to perform all the tasks of the CloudFormation template used in the product, but it will also need to be able to assume the role of the AWS Service Catalog.

If you do not currently have an AWS Service Catalog role set up, you can create this role by returning to the IAM console and following these steps:

1. Sign in to the AWS Management Console and open the IAM console.
2. Click Roles.
3. Click Create New Role.
4. Type a role name and click Next Step.
5. Under AWS Service Roles next to AWS Service Catalog, click Select.
6. On the Attach Policy page, click Next Step.
7. To create the role, click Create Role.

A launch role defines which actions our CloudFormation template can perform in AWS Directory Service. To attach a policy to the new launch role:

1. Click the role that you created to view its details page.
2. Click the Permissions tab, and expand the Inline Policies section. Click Click here.
3. Click Custom Policy, and then click Select.
4. Enter a name for the policy, and then paste the following code into the Policy Document editor.

{"Version":"2012-10-17",
"Statement":[        
{
"Effect":"Allow",
"Action":[
    "catalog-user:*",
    "cloudformation:CreateStack",
    "cloudformation:DeleteStack",
    "cloudformation:DescribeStackEvents",
    "cloudformation:DescribeStacks",
    "cloudformation:GetTemplateSummary",
    "cloudformation:SetStackPolicy",
    "cloudformation:ValidateTemplate",
    "cloudformation:UpdateStack",
    "s3:GetObject"
    ],
    "Resource":"*"      
}] }

5. Add a line to the policy for each additional service that the product uses. For example, to add permissions for Amazon Relational Database Service (Amazon RDS), type a comma at the end of the last line in the “Action” list, and then add the following line.

"rds:*"

6. Click Apply Policy.

See Applying Launch Constraints for more information about how to apply the correct privileges to the CloudFormation templates that underlie AWS Directory Services.

Congratulations! You have set up a DevSecOps infrastructure that utilizes AWS Service Catalog for automated deployments of healthcare web servers.

Using the architecture: Healthcare developers

Now that you have configured the DevSecOps infrastructure, the development team can take advantage of automated deployments while knowing that their underlying infrastructure has been set up in a controlled environment by their healthcare security administrator. The following steps demonstrate how a healthcare developer might interact with this architecture.

Step 1: Set up your first CodeCommit repository

Before you try to run any of the commands associated with CodeCommit, first verify that you have the correct version of the AWS CLI by running the following command.

aws codecommit help

If the output is documentation, you have a CLI version that contains CodeCommit. If your CLI version does not include CodeCommit, download the latest version of the CLI. Also be sure that you install Git.

When you are ready to start a new project, create a new CodeCommit repository by running the following command from the CLI.

aws codecommit create-repository --repository-name DevSecOpsExampleRepo --repository-description "My DevSecOps example repository"

The response will be similar to the following.

{

    "repositoryMetadata": {

        "repositoryName": "DevSecOpsExampleRepo",

        "cloneUrlSsh": "ssh://git-codecommit.us-east-1.amazonaws.com/v1/repos/DevSecOpsExampleRepo",

        "lastModifiedDate": 1449967097.005,

        "repositoryDescription": "My DevSecOps example repository",

        "cloneUrlHttp": "https://git-codecommit.us-east-1.amazonaws.com/v1/repos/DevSecOpsExampleRepo",

        "creationDate": 1449967097.005,

        "repositoryId": "xxxx-ee53-465e-a7ac-xxxx",

        "Arn": "arn:aws:codecommit:us-east-1:xxxx:DevSecOpsExampleRepo",

        "accountId": "xxxxxx"

    }

}

Step 2: Connect to your CodeCommit repository

Developers can connect to a repository in a variety of ways, but for this example, I will use the cloneUrlHttp URL that is highlighted in red in the preceding code. The CLI keys will perform authentication.

To configure authentication against CodeCommit, first run the following Git configuration commands.

git config --global credential.helper '!aws --profile default codecommit credential-helper $@'

git config --global credential.UseHttpPath true

Note: If you are an OS X user and are experiencing issues with Git asking for passwords after running these commands, see Setup Steps for HTTPS Connections to AWS CodeCommit Repositories on Linux, OS X, or Unix.

Step 3: Push code to CodeCommit

If you currenlty use Git, the process of pushing code to CodeCommit should be familiar to you. If you are not familiar with Git, see this tutorial to get started. However, all the Git commands needed to follow along with the remainder of this post can simply be copied and pasted from the code snippets that follow.

curl https://s3.amazonaws.com/awsiammedia/public/sample/hipaa-compliance/aws-service-catalog/code-deployments/index.html > index.html

From within the directory, run the following commands, replacing the URL that is highlighted in red with the cloneUrlHttp you created in Step 2.

git init
git add .

git commit –m ‘first CodeCommit’
git remote add origin https://git-codecommit.us-east-1.amazonaws.com/v1/repos/DevSecOpsExampleRepo
git push -u origin master

Review this push by using the CodeCommit console. You will see a page similar to what is shown in the following image, which displays a single-file Git repository that contains an index.html file.

Step 4: Using AWS Service Catalog to release code

As a healthcare developer, sign in to the AWS Management Console, and choose Service Catalog. You will see only the end-user view of the console, which will contain the list of products that have been set up for you by the healthcare security administrator. The following image shows the products available from a developer’s point of view.

Select the Healthcare Web Server check box. Click Launch Product and name the stack something meaningful to you.

As shown in the following image, you are now prompted for Healthcare Web Server parameters as requested via the CloudFormation template, which was used by the healthcare security administrator.

Each of these parameters is explained in the following list:

• FriendlyName – The name with which you tag your server.
• CodeCommitRepo – The cloneUrlHttp field for the Git repository that you would like to release on the web server.
• Environment – A choice between PROD and TEST. TEST will create a security group with several secure ports open, including SSH, from within an AWS CIDR block range. Choosing PROD will create a security group with HTTPS that is only accessible from the public Internet. (Exposing production web servers directly to the public Internet is not a best practice and is shown for example purposes only).
• PHI – Choose if you need to actually store protected health information (PHI) on the server. Choosing YES will create an encrypted EBS volume and attach it to the web server.
• WebDirectory – This is the name of your website. For example, DNS-NAME/WebDirectory.
• InstanceType – This is the Amazon EC2 instance type on which the code will be deployed. The available instances are restricted to the list of EC2 instances that support EBS encryption.
• InstanceOwnerEmail – The e-mail address of the developer setting up this server. This field will be used to tag the instance and will give the security administrator the ability to generate alerts and metrics based on this tag.
• KeyName – The SSH key used to log in to the instance.

After you have populated the fields and launched the stack, after a few minutes you should be able to review the output, as illustrated in the following image.

Click the Value (link) for CompliantWebsiteURL, and you will be taken to the website that you just created.

Important note: Most browsers will display an error for the certificate that was used in this server’s configuration. The certificate used in this example is a self-signed dummy certificate I created to share publicly on this blog. It should never be used in an actual healthcare application. However, the techniques used to deploy that certificate can be used in your environment with your own certificates.

After you acknowledge this one-time exception by clicking Continue and verify that your connection is not actually private, you will be taken to the website deployed from your Git repository.

You have now successfully deployed your code to a healthcare website without direct intervention from the security team, but with the assurance that a security administrator has properly set up your web server to meet the correct compliance requirements.

Reviewing architecture deployments: Healthcare security administrators

Even though the web server and code were deployed entirely by the healthcare developer, the healthcare security administrator can still have complete oversight into their environment.

The developer does not have the ability to use the EC2 console, but the security administrator can review the server that was just created, who created it, and for what purposes it will be used. For example, the following screenshot shows that this server instance was created for the production environment and will not store PHI.

Along with the EC2 instance, other items such as ubiquitous and centralized logging using Amazon CloudWatch were set up as well, which you can see an example of in the following image.

Additionally, AWS Config is now recording the state of our healthcare web server, as shown in the following image.

Conclusion

This blog post has shown an introductory DevSecOps architecture that “uses the cloud to protect the cloud.” I hope I have dispelled the myth that security administrators lose control in a DevSecOps environment, and have shown healthcare developers that they can still rely on their security administrators without slowing down their development cycles.

In my next post, I will dig deeper into the CloudFormation template that was used in this blog post and provide best practices for healthcare customers who wish to automate their compliance controls in CloudFormation templates.

– Chris