When you create an AWS account from scratch, you also create an omnipotent “root” account. AWS recommends against using it for everyday tasks and encourages you to create an IAM user. By default, IAM users don’t have credentials or access; it’s up to you to configure them. The complexity of AWS IAM authentication and access control can make it tough to design a good usability and security tradeoff for the regular AWS “human” user.
One design patten to consider is
sudo. Sudo is a Unix feature that lets users impersonate another user of the system, by default the superuser account, but if you consider the
sudo pattern as “re-establish trust before I elevate privileges”, it’s commonly used outside of operating systems.
You will see a
sudo-like pattern for accessing the Google Administrator Console:
And on Github when you edit security settings:
What makes this design useful is that the friction of authentication ceremonies and permission negotiation are aligned with the risk of trust decisions. I think it’s also becoming more familiar to developers, and because familiarity is usability, it should be easier to roll out then tactical access restrictions that can be hard to intuit.
The setup described below puts sensitive functionality behind a
sudo-like prompt for MFA for web and API access, and offers some protection from malware designed to steal AWS API credentials.
When you create IAM users, AWS recommends you consider the concept of least privilege — and the first step is to “determine what users need to do”. AWS has many services, each with dozens of different actions, and each account has a potentially large number of different resources. Like configuring a file system for least privilege, it can be difficult to know a priori what user needs which kind of access to particular resources.
Let’s assume, for now, read access by an adversary is less bad than write access, which may make sense if your primary concern is credential theft and someone spinning up a bunch…