Moving to the cloud means a lot more than just moving your servers and applications to the cloud; it’s also about the data – and data always has a target on it.
A lot of IT departments are finding that it’s easier to meet the “five nines” (99.999%) of uptime and availability by going outside their organization and letting AWS, Microsoft, or Google handle the infrastructure and personnel needed to meet those requirements. Plus, if your applications need configuration information or a place to store data, then you will be using cloud-based storage.
This is especially true if your data is in containers, on cloud-managed operating systems, or even in server-less applications (like AWS Lambda functions or Azure functions).
Change Management in the Cloud
This also means that you’ve moved the problem of tracking changes to important files from on-premises to the cloud. Ah, but you’re thinking – AWS, Azure, etc., tracks changes for me in cloud trails or logs, and that is true. However, that’s not the same as having a before-and-after view of the changes, an easy-to-report-on audit trail, a way to check those changes against a change ticket, and a means of comparing changes to configurations against a hardening standard.
Are your cloud teams creating change tickets for important changes to configurations/information in the cloud? If not, why not? Who or what is keeping track of whether changes are authorized and what may put you at risk?
Have you ever tried to determine authorized versus unexpected or unauthorized changes in a log stream? It’s not easy, and it’s also why change tracking using a baseline is used for operating systems, databases, network devices, etc. Creating a baseline that files are currently set to (or a known “good state”), as well as a mechanism to track deviation from that known good state, is just as important for files kept in cloud storage as it is for your on-premises files.
When the files in cloud storage are configuration files for your cloud-based applications, those should have both change tracking and hardening guidelines monitoring them. For instance, AWS has a lot of configuration settings for securing your S3 buckets beyond just whether they are public or not. There are plenty of questions to consider:
- Do you have encryption turned on?
- What about cross-region replication? (Should those even be turned on?)
- Are you using S3 object locking? How is it configured on newly created buckets?
- Should versioning be turned on?
All configuration settings have security and cost implications. Knowing what they’re set to and if they’re in compliance with your corporate standard across your AWS accounts (or the equivalent in Azure) is important from both a security and cost perspective.