In our previous article on CloudFormation security, we discussed several basic cloud security best practices for securing your CloudFormation templates. We covered access control, secrets management, enabling logging, and scanning CloudFormation templates for misconfigurations.
In this article, we’ll explore some more advanced cloud best practices that you can bake into your CloudFormation processes to further secure your AWS environment.
Fine-tuning access with custom policies
A fundamental tenet of cloud security best practices is the principle of least privilege. Where access is required, you want to ensure that you grant just enough access to accomplish the required task—and no more. In our earlier post, we talked about using a service role so that CloudFormation templates can create and modify infrastructure. This approach allows engineers to provision resources through CloudFormation without extending that power to each engineer’s identity and role.
In the previous article, we also talked about using a service role to limit creation and modification of resources to the CloudFormation service. You can further improve your organization’s cloud security by limiting access to only those resources that are owned by a team or specific group of users. One way to do this is by controlling access through roles that reference tags associated with the resources. You can do this by adding a Condition to your IAM policy that checks the values of tags on the resources. Some examples of tags you might use to limit access could be related to team, department, or environment.
As roles become more specific for each team or function, the number of roles you need to maintain increases. Fortunately, AWS CloudFormation templates provide tools like the AWS IAM Access Analyzer to help you find roles with excessive access or incorrectly configured access policies. You might also benefit from using a third-party open-source tool, such as AirIAM, to scan IAM activity, eliminate unnecessary roles, and create new roles with more appropriate levels of access. Just as CloudFormation improves your ability to manage your infrastructure through code, using CloudFormation templates to create and maintain your IAM roles can provide many of the same benefits. With CloudFormation, you’ll be augmenting your infrastructure-as-code with IAM-as code.
Protecting your deployment pipeline and environment
In addition to using IAM policies to protect what your CloudFormation templates are able to do, let’s look at some other features you can use to improve the safety and stability of your stacks and resources. This process begins as soon as your DevOps engineers start creating your CloudFormation templates. You should implement tools in the development environment that can validate the templates, identify potential vulnerabilities, and recommend best practices.
Once the templates are complete and committed to the source code repository, additional checks can be automated to analyze the templates and ensure that the template isn’t creating resources that contain misconfigurations. These checks should include validation that:
- S3 buckets are secure
- publicly accessible instances don’t have internet access
- resources are assigned the minimum permissions needed to accomplish their responsibilities
You should not allow developers to manually intervene and adjust resources manually or out of band. The result of manual changes to resources is known as cloud infrastructure drift. Drift creates differences from the original configuration that may be problematic. We’ll cover drift detection in its own section below.
Setting up guardrails
As your organization matures and implements more automation in its deployment processes, CloudFormation templates will become a crucial component of your version control system (VCS) and continuous integration (CI) pipelines. In addition to ensuring that these tools have the right amount of access, you also want to put guardrails in place.
Guardrails are cloud security advanced best practices that work like rules that you can set up using AWS Control Tower. Control Tower provides the tools to manage the security of your AWS accounts. Guardrail rules can be preventative and detective in nature, allowing you to specify prohibited activities. They can also notify you about actions that are not enabled or actions that violate the rules.
Managing compliance
In today’s complicated cloud environments of IaC, microservices, and containers, misconfigurations are a given. Establishing a secure foundation using the top cloud security advanced best practices already described will reduce mistakes and vulnerabilities, but monitoring your infrastructure to ensure compliance is still critical.
Ideally, you want to detect problems as early as possible in the development process to reduce the time to resolve the problem and eliminate context switching for your developers. To help eliminate context switching, validation tools are included in the CLI and can be integrated into many of the most popular development environments.
Once the CloudFormation templates are checked into source control, you can use tools like Checkov to monitor your CloudFormation and other infrastructure as code (IaC) to validate their security and compliance with best practices. Ideally, you want to select a tool that regularly scans your templates to detect problems and either alerts you of those problems or, better yet, applies automated fixes to correct the issues as they occur.
Monitoring and mitigating cloud drift
Finally, we need to talk about cloud infrastructure drift. Drift occurs when changes to cloud resources are made outside of the IaC blocks that defined them. It often happens when one team (e.g., a security team) doesn’t have access or knowledge to fix a cloud misconfiguration at the IaC layer, so they end up making the change directly in the cloud console. Although drift doesn’t present a direct security risk, it does create inconsistencies between CloudFormation templates and running AWS resources.
Manually implemented changes also bypass many of the security checks that you may have implemented. AWS CloudFormation includes a drift detection tool, and access to the tool only requires read-only permission. After executing the Detect Drift function, you’re presented with a comparison of the original configuration and the new configuration. Because some changes may be legitimate, you can review all the changes and, if required, create a changeset on the CloudFormation stack to bring the stackback in line with the original configuration.
···
Building in security from the start—from application development to deployments and monitoring—is essential to maintaining a safe and secure AWS environment. CloudFormation allows us to automate much of that security policy enforcement, but also adds complexity. As your environment grows, new AWS services are released, and new security considerations crop up, you’ll want to exercise constant vigilance by learning more about potential threats as well as the tools that can protect your processes and your digital property.
To see how Bridgecrew can help keep your CloudFormation templates secure and compliant, get started with a free Bridgecrew account and connect a repo.
