ACM.111 Separate your data and resources from your executable code
This is a continuation of my series of posts on Automating Cybersecurity Metrics.
The last post provided some suggestions pertaining to how CloudFormation could be improved.
This post explains how using CloudFormation can help you secure your AWS account.
Have you ever heard the phrase “separate your control plane from your data plane?” This is a concept often recommended as a security best practice for containers and Kubernetes (a topic I often get questions about from IANS customers.)
I imagine some developers got frustrated when they couldn’t take an action in CloudFormation. Instead of just describing what they want to deploy in a template they wanted to calculate or do something. Perhaps that is why custom resources and the ability to call Lambda functions got tacked onto CloudFormation.
But CloudFormation is not for “actions.” CloudFormation data. Metadata, to be more specific, that describes the state of your cloud infrastructure.
Have you ever been told to remove the configuration of your program from the application code itself and put it in a separate file? CloudFormation is a similar concept (kind of). We’re configuring resources. You separate the resource configuration from the code that executes the deployment.
The functionality that deploys a CloudFormation — the actions that you want to perform — should remain separate from the data itself for a clean design.
I realize that sometime this is hard to do. It requires additional thought when designing your deployment systems. I ran into some issues already in this series where I had to generate a template — but that was caused by CloudFormation limitations than an issue that could be fixed so I could keep my design nice and clean.
Here’s what you can do if you keep your configuration data separate from your executable code.
You can be sure that when someone is modifying code that takes action that they are not changing the CloudFormation templates or infrastructure configurations.On the other hand, when you are deploying infrastructure, you don’t need to allow someone to access or modify the code that handles deployments, like say turning off security checks embedded in the process.
Separate execution from data.
Deploying CloudFormation templates allows you to inspect the configuration of your resources because CloudFormation has a structure that can be validated and compared to what exists in your cloud account. Free-form code that can be written any which way might be hard to decipher to determine if you have a configuration problem.
By the way, if you are using Terraform it has this same characteristic of separating code from data depending on if you adhere to the principle. In general, you are defining resources and then use other commands to deploy the resources based on the defined configuration.
As an aside, sometimes people believe that by using Terraform they will write one set of code to deploy everywhere — but you are still going to have different code for different resources across cloud platforms. You will still want to understand the underlying cloud platforms to troubleshoot problems.
What Terraform helps with is to create a single deployment pipeline for resources across different cloud platforms so you can manage things in a consistent manner. If you’re using multiple platforms you may definitely want to consider it, but be aware you will still end up writing code for each platform in a lot of cases.
Here’s a perfect example of what I’m talking about:
How to build step by step a multi-cloud website running on AWS, Azure and Google Cloud, with…
I haven’t vetted that code I just quickly searched for an example to demonstrate the concept that I’m addressing.
Many articles have been written about how “infrastructure as code” can help you with cloud security. That’s something I cover in cloud security classes but not in this post. Here I’m specifically talking about using CloudFormation versus some other AWS deployment methods, and consideration for how you implement your deployments with it.
Just remember to keep your CloudFormation configuration data separate from your executable code or actions taken on and with that data.
Follow for updates.
Teri Radichel
If you liked this story please clap and follow:
Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research
© 2nd Sight Lab 2022
All the posts in this series:
Automating Cybersecurity Metrics (ACM)GitHub – tradichel/SecurityMetricsAutomation
____________________________________________
Author:
Cybersecurity for Executives in the Age of Cloud on Amazon
Need Cloud Security Training? 2nd Sight Lab Cloud Security Training
Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
How CloudFormation Helps Security was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
