Skip to content
ELI5: What is 'drif...
 
Notifications
Clear all

ELI5: What is 'drift' in cloud security and why should I care?

3 Posts
3 Users
0 Reactions
1 Views
(@chloeh)
Trusted Member
Joined: 1 week ago
Posts: 45
Topic starter   [#20770]

Hey folks, I usually hang out in the sales tools forums, but our team's been moving more infrastructure to the cloud. I keep hearing security folks talk about "drift" and it's got me curious.

Can someone break down what "drift" actually means in plain terms? Like, if I set up a secure cloud server on Monday, what happens by Friday that makes it "drift"? And why is it such a big deal for security? Trying to connect the dots to my world of keeping customer data safe.



   
Quote
(@davidm78)
Estimable Member
Joined: 6 days ago
Posts: 64
 

Think of it like your server's security settings have a mind of their own and start wandering away from where you set them.

You build that secure server on Monday. By Friday, someone might have logged in to install a new tool and accidentally opened a network port they shouldn't have. Or an automated update might change a permissions policy. The server's actual, live state has "drifted" from the secure blueprint you started with. It's no longer what you approved.

That's why it's a big deal for customer data. You might have a perfect, audited setup on day one, but drift creates invisible gaps over time. You can't protect data in a system that's quietly changing without your knowledge. It's why teams use tools to constantly check live resources against their intended "source of truth" configs.


Data doesn't lie, but dashboards sometimes do.


   
ReplyQuote
(@cloud_cost_breaker)
Estimable Member
Joined: 2 months ago
Posts: 131
 

You've nailed the root cause - changes made after the fact. The connection to customer data is spot on, but there's a hidden operational cost angle too.

That invisible gap doesn't just create risk, it creates technical debt. You start paying for and managing a system that no one fully understands because its configuration is undocumented. If you ever need to rebuild it for recovery or scaling, you'll likely rebuild Monday's version, not Friday's drifted version, which can cause new failures.

Tools that check against a source of truth are essential, but that source must be *enforced*, not just referenced. This is where Infrastructure as Code pays off - your definition file *is* the state, and any manual drift can be automatically reverted.


Less spend, more headroom.


   
ReplyQuote