Three most common security mistakes in the cloud
Having worked with hundreds of cloud-based application architectures, we’ve seen a lot of applications where security has been a key design principle. Unfortunately, we’ve also seen more than a few where security seems to have been forgotten completely.
Based on our experience, here are the three most common security mistakes in the cloud:
1. Poor secrets management
The most common, and sadly the most critical issue we see is poor (or missing!) secrets management. Almost every application in the cloud has secrets: typically these are database credentials, API keys for external services, or deployment keys for a cloud platform - things that, if exposed, could lead to a major data breach.
Some organisations still store secrets as part of the source code - that’s a big no-no, since any breach of the source code would lead to a catastrophic security breach of all related systems. Since a copy of the source code tends to be saved locally to all developer workstations, it’s a disaster waiting to happen.
For better secrets management, consider using security profiles instead of API keys where possible, and utilise tools such as AWS Secrets Manager.
2. Overly permissive user accounts and security policies
The second most common security mistake is not aligning with the Principle of Least Privilege. According to this principle, all users and components using service accounts should only have access to what they need in normal operations, and nothing more.
Following this principle minimises the damage if access to an account should be compromised, typically via a phishing attack or due to poor secrets management (see above!).
As a first step, review your list of administrative users and remove / downgrade anyone who doesn’t need administrative access. In AWS, use the IAM Access Analyzer to limit security policies to the set of required permissions only.
3. Lack of firewalls and network-level security
While it’s true that you shouldn’t attempt to build data centres in the cloud, many proven network design principles still stand: things that shouldn’t be public must not be accessible via the public Internet.
It sounds obvious, but it’s still a pattern we see very often: database endpoints are reachable via the internet, or application servers that are behind a load balancer or Web Application Firewall are reachable directly if you know their public IP address (and we do).
To fix this, ensure you are using private and public subnets correctly, and utilise firewalls (or Security Groups) to limit access to your private components such as databases. Seek help to review your current setup where appropriate.
