Do you wonder if your AWS cloud workloads are deployed according to security best practices? If so, you’re not alone. We are often hired to review whether a deployment to AWS followed best practices. And while we’re happy to provide our assessment of a completed deployment, we encourage our customers to make sure their deployment is done right from the start. As you likely know, automation, when implemented correctly, is probably our most important tool to ensure consistently secure deployments to AWS.
Here is a simple example of how using automation in the AWS platform helped one of our customers ensure compliance with a strict internal security policy.
The client is an international insurance provider using AWS to run actuarial batch jobs. The client’s analytics application suite was built by a third-party software development partner. We were engaged in deploying the applications according to AWS’ best practices, and according to the client’s list of specific requirements for OS hardening, network and application configuration.
Meeting these strict guidelines is a great use case for ‘infrastructure-as-code’ using the CloudFormation service.
With CloudFormation, you’re able to create templates that contain the commands to create infrastructure along with the related services for security and monitoring. Additionally, for this project, we used the CloudFormation templates to document to the client’s compliance team that the deployment followed the required best practices.
By leveraging CloudFormation we were able to organize the project around auditable deployment templates.
We started with an AWS CloudFormation template that captures Softchoice and AWS best practices for configuring the account, locking down access, and turning on optional audit services such as CloudTrail and Config. Next, we used a CloudFormation template to create an EC2 instance (an AWS virtual server) with Windows Server OS and then extended it to implement OS hardening to meet the client’s requirements.
The completed templates became the foundation from which we could produce a golden Amazon Machine Image (AMI) representing an instance with the hardened OS.
Next, for each application in the application suite, we created CloudFormation templates to stand up an EC2 instance based on the golden AMI, install the application, and then customize the configuration. For example, each application required slightly different configuration of the AWS Security Groups so that each instance would be configured with fewest possible open ports. Finally, the templates captured each application instance as an AMI.
As the project progressed the team could run the templates, test the resulting infrastructure, make modifications to the templates and then blow away the infrastructure and be ready to try again with the improved template.
The team could make reference to the CloudFormation templates to document how requirements were addressed. Deficiencies could be addressed, and progress documented, through the revision history captured in the source repository where the templates were stored.
For this client, the automation stopped with CloudFormation. For other clients we have implemented Continuous Deployment pipelines to manage the infrastructure deployments as new versions of the application are released.
These deployments often manage configuration through a Configuration Management platform such as Chef and Ansible rather than configurations captured in an AMI.
You can read more about how automation of infrastructure fits into your overall adoption of AWS cloud in the white paper: AWS cloud in the AWS Cloud Adoption Framework – Operations Perspective. How are you improving security by automating your cloud? Leave a comment below.