Cloud Tech First Floor Recommendations

I hate to say it, but I’m an old, curmudgeonly guy that’s been in the industry more than 20 years. And after a while, things just start to wear on you. In fact, there was a point in my career that I swore if I had to counsel just one more company on the importance of having strong passwords and password policies, I would jump out a window. And yet here I am, still dealing with these issues many, many years later. Thank goodness, my recommendations were always delivered on the first floor.

Now we’re a dozen or so years into cloud technologies, and we're finding ourselves starting to get into that same pattern – repeating the same recommendations ad nauseam, just with a slightly different twist. User, credential and access management top the list of recommendations we make to our clients, and ultimately this is what makes up the bulk of “security misconfigurations” that top our list of cloud issues in our annual Penetration Risk Report. So, to that end, I’ve been inspired to put together a quick and dirty list of best practices for cloud user access management – specifically for AWS, as it’s what I know best – to share here. These have been gathered from a variety of sources across the internet, including from AWS documentation, so this shouldn’t be surprising to many, and hopefully will be a good refresher.

AWS Cheat Sheet

1. Don’t use the root account for anything. Just like in a traditional server/enterprise environment, using the account that has the keys to the kingdom is asking for trouble. Instead, create Individual IAM users to which you can grant access. Truth be told, you’ll have to use the root account for billing, but the point is to avoid it as much as possible.
2. Grant access with IAM roles. IAM roles are a gateway to a world of security benefits. Delegation of access, cross-account access, and the potential elimination of credential sharing are just the start.
3. Automatically rotate your keys. Accounts can be configured to automatically rotate IAM credentials and keys. Implement this to avoid stale accounts.
4. Least privilege. :* is very, very bad. For us old curmudgeonly guys, * policies are the “any:any” of IAM. It’s easier to add privileges through additional policies than removing them from existing policies. And speaking of policies…
5. Manage user accounts with groups; manage permissions with policies. The easiest way to manage is by groups. It’s logical, and it’s not a departure from traditional user management, but use policies to manage access permissions. Policies have versioning, and this can be incredibly useful when working out access issues.
6. Enable Cloudtrail. Get visibility into activity – without it, you’re ultimately flying blind.
7. Enable Multi-Factor Authentication (MFA). At a minimum, enable MFA on privileged accounts. What’s a privileged account? I’d recommend starting with anything that has permissions to manage IAM accounts.
8. Configure a strong password policy. The tired message that this blog started with, but this time with a twist – to “un-configure” credentials that aren’t needed. Got a console-only user? Delete the API key if there is one. An application-only (API, CLI, or SDK) user? Delete the password. And to help you manage this, use the Credential Report to audit credential usage and delete those that aren’t used. Finally, ensure you configure an access key rotation policy as well – this doesn’t happen by default.

None of these break new ground, but I hope that repeating this here on the blog helps shore up the next 20 years of repetition of IAM best practices.