Upper and lowercase letters, numbers, and special characters are what everyone thinks about when it comes to password policies. Length is usually a factor as well, but all too many places enforce a minimum 8 digit length which is pretty much useless. If your company uses a password manager like 1password, why not enforce the most secure passwords in IAM? (And if you don’t use password managers you should think about doing so)
If you are going to start requiring any useful amount of password length, go all the way since nobody is going to be remembering a 32 digit password anyway. My recommendation for an AWS IAM Password policy is: 128 characters, upper and lower case letters, numbers, and special characters.
Below I will go into more detail about expiration and reset. Instructions on how to change your AWS password policy can be found here.
Password Expiration, Reset, and Rotation
Your password policy should also include automatic rotation. Users should be able to change their own passwords, with their credentials expiring after 90 days. Password reuse prevention should also be enabled. As far as expired passwords requiring an admin to reset it, this would be personal preference with the tradeoffs of having an admin that needs to keep resetting passwords vs the ability to reset a seldomly used account with a long expired password. We would argue that unused AWS accounts should be deleted anyway before the 90 days is up.
Multi Factor Authentication
All users in your AWS Account should have MFA enabled. A hardware MFA device like a yubikey would be best, but if that’s not feasible have them use a virtual MFA device with 1password or an authenticator app on their phones with google authenticator for android or iOS.
Enforcing MFA in AWS isn’t as simple as changing a password policy on your account. There’s a step by step process described here about enforcing MFA logins for IAM:
CLI Key Rotation
AWS CLI access keys should be rotated often, 90 days according to AWS. Most keys give access that bypasses MFA and are stored as plain text in a well known location on your developers machines. Poorly and lazily implemented IAM roles and policies compound the danger of AWS keys getting into the wrong hands.
Forcing and automating AWS key rotation can be tricky, there’s a post about it here that you can look into, but it’s probably not something that needs to be done at a smaller scale.
One Key Per User
IAM users shouldn't have multiple keys, it makes it harder to deactivate and rotate them. Consider deactivating and deleting multiple CLI keys. The same goes for SSH keys, users shouldn't have multiple SSH public keys configured as it could mean multiple people have access to the account.
As a default, many employees are given AWS credentials when joining a company or team who may never use them. We recommend that any users not using their CLI or Console access in AWS should have it removed. Inactivate and delete keys that haven’t been used in 90 days, and revoke console access if they don’t use it.