Between misconfigurations, tangled permissions and sketchy ghost servers, cloud computing security risks are a bunch of moving targets. Throw in the shared responsibility model (no, your provider won’t handle everything for you) and eye-watering prices for security features, and you’ve got yourself a real challenge if you’re in charge of cybersecurity for your organization.
While you’re probably handling some common Cloud security risks already, there might be issues lurking beyond what’s popping up in your Slack and Teams channels. Let’s walk through the top risks associated with cloud computing and ensure they don’t keep you up at night.
Your Coffee Machine might turn on you
If you’ve spent any time in traditional data centers, you know the drill: lock down your network, set up your VPNs, and configure your firewalls. The thing is, this fortress mentality isn’t just outdated; it’s downright dangerous. Just ask Capital One about their 2019 breach in which 100 million customer records were exposed due to misconfigured identity access management (IAM).
If you’re going to establish dominance over these sorts of Cloud computing security issues, you gotta know the rules of the game: in this cyber world, identity is your perimeter, and it’s a more complex beast than you think.
Here’s what makes cloud IAM interesting (and by that I mean “terrifying”): every single resource has an identity. Your applications, functions, and APIs all need to authenticate and authorize against each other. Heck, even your smart coffee maker needs access to send notifications once your cup is ready.
We see it all the time: the “temporary” admin access from that 3:00am incident that’s still active, a Jenkins account with unnecessary full permissions, and those orphaned roles nobody dares to touch because what if it breaks something? All of these are ticking time bombs waiting to blow up into your next security incident.
Be Stingy with Permissions
The solution starts with embracing the least privilege principle. Begin with zero permissions and work your way up based on actual needs, not convenience. Here’s how:
Use tools like AWS IAM Access Analyzer to understand who’s sharing what and with whom, and Azure PIM to answer the “How did they get admin” question. Don’t just run these checks during audits—make them a part of your everyday routine.
For new resources, start with zero permissions. Let your app fail in dev, then add permissions one IAM statement at a time.
Yes, it’s tedious.
Yes, your developers will complain.
No, it’s non-negotiable.
Finally, automate admin access and cleanup. If an engineer needs production access, let them open a ticket that grants them access that auto-revokes after two to four hours. You can do this fairly easily through AWS IAM Identity Center. And while you’re at it, write scripts that hunt down unused roles and stale access keys, setting up alerts for anything unused after 30 days.
Remember: in the Cloud, IAM is your entire security foundation. Get this wrong, and nothing else matters. Get it right, and you might have more interesting problems to worry about.
How Microsoft Landed in Hot Water
Your Cloud environment might look right in isolation, but as soon as you start layering features, integrations, and network rules, things can easily spiral out of control.
The ChaosDB vulnerability in Azure Cosmos DB is the perfect example of this. Microsoft introduced Jupyter notebooks into Cosmos DB to make it easier for developers to interact with their databases. A thoughtful feature, for sure, but behind the scenes, enabling it created a shared environment that allowed attackers to harvest all the primary keys and log into customer accounts.
The Cosmos DB incident taught us that even small, seemingly unrelated features can affect data security. To stay ahead of this, audit access to your storage resources frequently. Set expiration dates on SAS tokens and other temporary credentials. Finally, make sure you rotate encryption keys regularly.
Look Out for Misconfigurations
Kubernetes, API Gateways and other managed cloud services are like high-performing sports cars: incredible when configured correctly, but a disaster when mishandled.
Misconfigurations in this case aren’t just about exposing your console to the internet (though that’s still an issue, as Tesla learned). In Kubernetes, for example, your service mesh configuration might be encrypting traffic between services through mTLS, but what about the certificate validation? Teams sometimes accidentally disable this during testing, leaving their inter-service communication wide open to man-in-the-middle attacks.
Boarding a Flight with a Fake ID
API Gateways come with their own challenges, too. While everyone focuses on web application firewall (WAF) settings, the real risks of cloud computing often come with those custom pieces of code filtering out bad traffic.
Think carefully about the way you’re configuring these custom authorizers. If you’re not careful, your Lambda authorizers might end up with bugs that let malicious requests through. It’s like a poorly-engineered airport ID scanner. If its verification logic has a flaw, it will check for the presence of a hologram but not whether it reflects light the right way. Similarly, your custom authorizer might only check if a token exists but not whether it’s valid or expired.
Be Wary of Tools that Know Too Much
Tools that need excessive data access to their job are especially attractive to attackers. You might be so concerned with direct attacks that you forget about the risk of legitimate features being used in unintended ways.
Jenkins breaches have repeatedly shown us how dangerous over-collection can be. In multiple documented cases, attackers accessed build logs containing hard-coded credentials, API tokens, and cloud access keys. The service was doing its job (logging build information) but it was also inadvertently creating troves of sensitive data.
To mitigate sloppy credential management, configure secret detection in your pipelines. Tools like TruffleHog or GitLeaks scan your source code to spot exposed credentials before they end up in your logs. You can take this a step further and mask the credentials and block them from ever showing up in the first place.
The Unusual Way of Monitoring Security
Want to hear something crazy? Your AWS bill might spot an attack before your security tools do! Say you noticed your machine learning training costs suddenly spike in a dev account that shouldn’t be running anything heavy. Your fancy security tool might have missed attackers hijacking your GPU instances to mine crypto—but your AWS bill caught it instantly.
The fact is, you can catch attacks faster through cost anomalies than traditional security monitoring. Keeping an eye on your Cloud costs isn’t just good FinOps practice: it can mean the difference between a high-five from your CISO… or a very tense meeting!
Here’s what else you can do:
- Set up cost anomaly detection. Every observability tool has one.
- Use EventBridge to auto-quarantine resources when you spot weird spending patterns
- Tag every single resource. It’s boring, true, but it means the difference between “Huh, that’s odd” and “Sh*t, shut it down, now!”
There’s a saying in journalism: follow the money (and you’ll find the truth). The same is true with Cloud security.
A Spooky Liability
One threat cloud cost tools are unlikely to catch is ghost servers. These are not only hard to spot, but still very much active and dangerous.
Ghost servers still maintain network access, valid credentials, and active connections. These servers often run outdated, unpatched versions of software while retaining privileged access to your production environment. Imagine an old Jenkins server, forgotten during a migration, still holding valid AWS credentials and access to your repository.
Once compromised, ghost servers provide stable, long-term access to your environment. It’s a nightmare as the attackers are able to move laterally through the infrastructure using valid credentials. Or worse, misuse sensitive resources while looking legit.
Up to 30% of servers in any data center are ghost servers, signaling a vast attack surface we need to patch up. Clear ownership, regular infrastructure audits, and continuous monitoring are key to mitigating this cloud security risk.
DDoS Attacks: Just Because You’re Paranoid, Doesn’t Mean They’re Not Out to Get You
Your network is like a post office. Usually, it handles the daily flow of mail just fine. Then, out of nowhere, every person in town decides to mail a brick, and they all show up at the same time, demanding immediate service.
That’s basically what a DDoS attack does: overwhelms a service with malicious requests, rendering it absolutely useless. But modern DDoS techniques go beyond just volume-based attacks.
Protocol attacks, for example, target the actual mechanics of network communication. SYN floods fall into this category and are the equivalent of someone ringing your doorbell but running away before you can answer, leaving your system waiting for connections that never complete.
But the nastiest of all are Application layer (Layer 7) attacks. These are the clever ones. They mimic legitimate user behavior so that your defenses can’t tell them apart from real traffic. You end up burning through resources and amassing costs while genuine users get stuck with slow responses and failures.
Mitigating Recurrent Attacks
Okay, so your server is getting hammered by these relentless attacks. Your services are crashing under increased load and it feels like things are spiralling. Don’t let it get to you though, because there are ways of regaining control.
First off, Cloudflare offers a commanding level of protection against DDoS attacks. Tools like AWS Shield, Akamai, and Azure DDoS Protection are similar set-and-forget solutions that can save you a lot of headaches. In fact, the latter mitigated one of the largest DDoS attacks ever recorded, when Microsoft faced an attack from 10,000 sources across multiple countries. The DDoS Protection from Azure nullified the assault without service disruption.
If you’re not keen on Cloudflare and its counterparts, you can get your hands dirty with other methods. Start with rate-limiting. You need to cut down on the amount of requests any single IP can throw at you in a set period of time. Tools like Apache’s mod_ratelimit or Nginx’s limit_req. allow you to set this up right at the web server level. And while you’re at it, use GeoIP filtering to weed out the junk coming from specific regions.
Next, automation is going to be your best friend here. Fail2Ban is a great option to dynamically block IPs bombarding your servers with failed requests or scanning for non-existent files. The beauty of Fail2Ban is that you can customize its filters to match the weird traffic patterns you’re seeing. If the attackers keep switching IPs, CrowdSec might be an even better fit since it taps into a global network to block malicious activity before it even reaches you.
Finally, don’t forget to set up solid monitoring—and don’t cheap out on logging; you want to see what’s happening in real-time and spot cloud computing security threats early. Tools like Graylog or ELK can help you make sense of the chaos. Once you’ve got these measures in place, your server will be much more resilient to whatever gets thrown at it.
The 20-year old Tactic that still Works in 2024
“It is possible to commit no mistakes and still lose. That is not a weakness; that is life.”
—Captain Jean-Luc Picard, USS Enterprise
That’s the brutal truth about cloud security in 2024. You can do everything we’ve talked about in this article and still have everything fall apart because people do human things.
Phishing and Human-Centric Attacks: Your Biggest Security Nightmare
While you’re stressing over proper configurations and multiple layers of encryption, Steve from marketing uses 'Password123' as his password. And Linda, an IT admin, hasn’t checked logs in months because “nothing ever happens anyway.” Even worse, that convincing “urgent password reset” email might be all it takes to compromise your entire cloud infrastructure.
Modern phishing attempts have evolved beyond the obvious scams (no, a prince is not trying to give you money). Today’s attackers scrape LinkedIn and other public sources to craft highly targeted messages, referencing real project names, mimicking your CEO’s writing style, and timing attacks around known company events.
Even more worrying is the rise of generative AI, with attackers using language models to compose personalized, grammatically correct emails at scale, making traditional red flags like poor grammar or generic greetings obsolete. These communications look frighteningly real.
Your team members, though well-meaning, are likely to be the weakest link in your security chain. They don’t really think about the security risks of cloud computing as they go about their already complex jobs—and let’s face it: traditional security training is putting people to sleep!
What we all need is a cultural shift in how people perceive and approach security. The key here is creating an environment where people are celebrated when someone spots a phishing attempt instead of mocking them when they fall for one. Run regular phishing simulations, but don’t turn them into ‘gotcha’ moments. Your team members are just trying to do their job, and making security work for—and not against—them will solve more problems than an annual awareness session ever could.
Final Thoughts
We’ve covered some serious ground in this article trying to answer the burning question: what are the risks of cloud computing? From common misconfigurations to DDoS attacks happening at an unprecedented scale, big news stories show us just how much damage can occur when these risks become actual threats to your data and operations.
Remember, cloud computing risks are a bunch of moving targets, and as we’ve seen, it doesn’t take much for small oversights to snowball into serious breaches.
To those of you who’ve stuck around this far, nice work! You’re now better equipped to tackle cloud security risks before they turn into attack vectors. And hey, you’ve got some fresh material for next year’s CloudFest networking parties. Nothing says “Cloud professional” quite like discussing ghost servers over beers at Europa-Park. Better yet, subscribe to the CloudFest newsletter (you’ll see the link on the left) and you’ll also get a free ticket to the upcoming edition of the world’s #1 internet infrastructure festival.
CloudFest is calling you
March 17-20, 2025
