Temporary Privileges is an example of security theater. It does not change the attack surface in a threat model because the model is not temporal. Has anyone ever shown a practical evidence that the attacker will face a problem waiting for the elevated permissions to support this idea?
And if you still really want to do that, you don't need AWS roles as a separate concept for this. You can just use temporary membership in groups.
AWS IAM model is overcomplicated compared to GCP/Azure.
It becomes clear when you try to migrate the project with multiple envs (projects in GCP aka accounts in AWS) with cross-env accesses.
It's not just theater, it can be the difference between someone finding an unlocked laptop that needs to refresh their access before doing more actions or just having 100% unfettered access. This is only one attack vector that gets safer by temporary tokens with short expiries, and for the dev under normal work conditions just means every few hours (or whatever TTL) you need to place your finger on your fingerprint reader for 1 second.
I think you’re talking about something different. AWS session tokens let you use your SSO to request session tokens that have a short expiry. So you can do API/console actions but if an attacker takes the creds, they expire. It also lets you generate session tokens that only have the subset of your allowed perms that you need for that workflow.
Yea. Like, I’m 100% on board with the idea that AWS IAM is full of footguns, is overcomplicated, and is hard to get right (I assume other cloud platforms are similar, but my expertise is largely specific to AWS).
But also it’s a complex and very important problem space.
> Temporary Privileges is an example of a security theater. It does not change the attack surface in a threat model because it's not temporal. Has anyone ever shown a practical evidence to support this idea?
I agree. I think the benefit of this is quite low. If someone takes over your machine, things are lost anyways. If they take over your machine but for some reason cannot access your password manager (or so) or your 2fa to increase priviledges, you at least gain some time before the attack happens since the attacker has to wait - but it's not a major win.
The only case where this really helps is if the attacker gains only temporary access to you (maybe a temporary vulnerability in the browser) but can't "persist" it. In that case, you can reduce the blast radius.
Are you aware that you can associate an EC2 instance profile on a temporary basis with a role? And attach and detach them via api or on a schedule? Because if you do that, and you hack the machine (Linux, Windows or Mac not relevant...), but you don't have the role with the privileges you need, you are going nowhere.
Yeah, so that means the attacker has to wait for the next schedule. As I said, that's an advantage but I wouldn't classify it as a major win.
It's different if you use a different machine for the priviledged account. Then an attacker has to take over that second machine too. IMHO this is a mucher better concept, but also increases friction significantly.
It also helps in large companies where lots of people may have needed the higher permissions over the years - if you do temporary permissions then someone currently/soon having those permissions needs to be hacked, as opposed to hacking any one of the many people who needed those permissions a few years ago and still have them because they weren't temporary and got forgotten about.
I think this is a different case though. The point of those "temporary priviledges" is not so that someone only can use them sometimes, it's that they only do use them sometimes.
What you say (that people should only have the permissions that they need) is orthogonal to that.
Why do you assert that all threat models have no temporal component?
A realistic attack that compromises a low privilege session may not be able to leverage that into higher privileges. Therefore, limiting the use of high privilege to a smaller window of time definitely reduces the attack surface.
And if you still really want to do that, you don't need AWS roles as a separate concept for this. You can just use temporary membership in groups.
AWS IAM model is overcomplicated compared to GCP/Azure. It becomes clear when you try to migrate the project with multiple envs (projects in GCP aka accounts in AWS) with cross-env accesses.