It seems like a straw man to argue that leakage isn't the same as a compromise. Leakage of credentials sure has led to quite a few compromises.
No.
As per my post above, they "led to compromise" because lazy syadmins have been too inept to RTFM and make full use of IAM.
I mean, I could post my IAM credentials right here. I've even been lazy and haven't rotated them for 5 years (yes I've already slapped myself on the wrist !).
But they'll be naff all use to you because:
- My credentials are deactivated when I'm not using them.
- The STS policies they are linked to are IP-restricted
- The Role policies they are linked to are also IP-restricted
- The Role policies have minimal necessary privilege
- The Role policies can only be invoked be an assumed role
- The Roles have externalID attribute set using a UUID as value
And that's just a simple example. You can go much more layered and granular than that.
Its not rocket science, its not difficult, its just a case of the old PPPPPP (Prior Planning Prevents P* Poor Performance).
Companies generally totter along until about 50 engineers / 100 employees before hiring a single security-focused engineer. When those first few security engineers come on board, you can bet they'll have a backlog of at least several months' if not a couple years' worth of research and remediation before they get anywhere near taming the company's IAM setup. The vast majority of companies are small and probably aren't where they need to be in terms of IAM practices.
AWS adoption has become a lot more mainstream among companies. 10 years ago it was almost a secret weapon for forward-thinking (and VC-money-burning) companies that let them out-scale competitors. Unfortunately their defaults, documentation, guard rails, etc are still set up for those bleeding-edge, hyper-competent, top-0.01% companies.
If an engineer doesn't understand how to write secure software then they will continue to write un-secure software and there will be leaks and compromises. You're just externalizing risk and costs to your customers.
A public/leaked set of IAM credentials, using reasonable AWS access policies, should be considered more secure than a private set of credentials that just has unrestricted access to everything.
Indeed I'm not.
To spell it out, what I'm saying is....
People should be working on the assumption that their IAM credentials WILL be leaked and work back from there.
That leak may be accidental on Github, it may be via a hack, you might have accidentally pasted it into an email, it doesn't matter, the mechanism of leak is irrelevant.
Blast radius / Attack surface / Layered security ... whatever your choice of words, that's what you need to do and that's what AWS IAM gives you the tools to do.
As I've previously said, its really not that much effort to add the extra layers of security (e.g. you can start with easy stuff, low-hanging fruit like IP/Time constraints and then move onto more advanced stuff later).
Infact I'd argue the detractors here who have been busy downvoting me and arguing against me could have put a lot of extra security on their IAM credentials in the same timeframe. ;-)
This sounds rather interesting, mind elaborating how its done? How would they activate when you use them, but not if anyone else does?
You can quite easily monitor cloudtrail for malicious activity and use cloudwatch to notify you when someone uses your credentials from, say, an unknown IP, outside of working hours, etc.
Do you mean using roles (which aren’t credentials) or temporary credentials (which can’t be revoked)?
Or do you use other credentials to disable them (and how do you disable those)?
I’m not an AWS expert by any stretch, so genuinely interested as I wasn’t aware of any other mechanism you could be using.
Not saying they're impossible, but they are definitely difficult to figure out!
> No.
> As per my post above, they "led to compromise" because lazy syadmins have been too inept to RTFM and make full use of IAM.
You're contradicting yourself: "No, it hasn't led to compromises" but "they led to compromise because ..."
It's possible that (as you argue) AWS IAM provides strong security controls and, simultaneously, a lot of people use it in a way where credential leak _does_ represent compromise. My going-in expectation is that both of these are true. But this post isn't about whether AWS IAM is any good. Nor does the post talk about solutions -- I don't see a call to action to buy Datadog (aside from the banner in the footer that doesn't look connected to the post). So your criticism of "this is a non-problem -- everybody's just using it wrong" sounds pretty lame.
I don't follow your argument.
Perhaps let me try with simpler example.
I'll tell you my credit card PIN number is 7341.
Following your line of argument, you'll stand there screaming until you're blue in the face: "that's a secret credential leak, your card is compromised".
To which I say: "well, my card is in my wallet, and my wallet is in my pocket, so watcha' gonna' do with that PIN number chum ?"
So its the same with AWS.
I could tell you one of my access keys is AKIA3CWKZKKGZLHN and its secret access key is QOF0yG/lvqqAcklAHCDzPKRtk9D5oPnY.
But watcha gonna do with it ? Try logging in ? To what ? And even if you knew which AWS service, even with just low-hanging fruit security layers of IP range restrictions and time-gating you still won't get anywhere. Once we start adding extra layers such as roles and STS on top, then frankly you're more likely to win the jackpot on the lotto twice in a row.
If its not usable, its not compromise.
Maybe we came to this with different assumptions? My going-in assumption is that most people have not set up those extra layers that you're talking about. For them, a credential compromise is tantamount to an account compromise. Thus, a post like this is relevant to raise awareness of credential compromise (and sure, maybe a missed opportunity to talk about those other layers one could add).
Is your going-in assumption that most people _are_ using those extra layers and so the post is pointless because it _erroneously_ implies that a lot of folks might be more exposed than they think? That's not what I thought you were saying. I thought you were saying: "if a credential leak compromises your account, then you're doing it wrong". That might be true, but if there are lots of people doing it wrong, then it doesn't matter.
(I don't like your PIN example because in real life, the initial conditions set by the bank are that you know your PIN and you have your card. You have to go out of your way to expose both. By contrast, with the AWS credentials, you have to have taken the extra steps you mention to establish the extra layers that you're talking about (IP range restrictions, time gating, etc.))