You don't want just anyone using your AWS resources. Even when you've got the right people onboard, you probably will need some control over which resources they can access and when they can do it. IAM will help you set the right permissions to better secure your systems. Here's a short overview of how it can do that.
A major pro of AWS we’ve briefly mentioned before is your ability to manage what resources your users can access. This control is accomplished with a free permission system called Identity Access Management (IAM).
Let’s just say that in most cases, your college student interns won’t need (and shouldn’t have) access to as many resources as your senior developer who’s been around for 10 years. IAM would allow you to restrict the interns from accessing all of the same resources the senior developers are using so none of them accidentally crashes a system.
In general, only the enabled users will have access to the necessary resources while everyone else will be denied access. Carefully selecting which employee is granted which privileges will help fortify your AWS security, since the wrong users accessing a resource can be disastrous. Even if you can trust them not to cause any trouble, there’s always the chance they may hurt something by accident.
Setting it up
Don’t worry about sharing any of your login info — each user will have their own credentials. Their accounts will be their own, but fall within your account, known as the “root account”. It’s highly recommended that the root account should never be shared with anyone since it has access to all AWS services your organization uses.
In fact, you shouldn’t even use it yourself, even just for administrative tasks. Make another account for yourself instead for extra security.
All accounts start with zero access to anything until you manually enable access to the services you’ll think they need. If you’ve got a large number of users, you’ll be able to put them into groups based on who will be receiving the same permissions. You can set quite a few conditions for access, such as what time of day the user or group can access the resource, what IP addresses they need to be using, or whether they’re using SSL. Note that not all users have be actual humans -- some can be created to generate an access key for an app that runs in your corporate network and needs AWS.
The permissions you grant can be “broad” or “specific”. Broad permissions refer to permissions to use an entire service, such as DynamoDB. Specific permissions refers to a part of a service, such as a certain S3 bucket. It’s recommended that you assign your users as few privileges as is necessary for their tasks. If you underestimate what they’ll need, you can always add more privileges.
Access management is controlled by the policies you create for each account. Policies, documents stored in JSON format, are attached to IAM identities (users, groups of users, or roles) or AWS resources, explicitly defining their permissions. The policies list who is authorized, which tasks are allowed, the conditions that need to be met, and the resources to which authorized tasks are performed. Policies are simple to use with only two variations: allow or deny. These permissions are evaluated by AWS whenever the user makes a request. Anything not allowed is denied by default.
Granting temporary access
Sometimes, some of your users are going to need resources you normally wouldn't grant them permission to access, such as when an unexpected project comes up. As-needed permissions can be taken care of by the creation of roles. With roles, you’d be controlling which operations can be performed by the entity, or AWS service, that assumes the role. Roles aren’t inherently tied to any users, rather you define which entity is allowed to assume the role.
Roles are also useful when you have a temporary employee or contractor onboard. Any credentials no longer necessary can and should be deleted. You’ll be able to generate credential reports every four hours which will tell you when a password was last used and when it’s time to change it.
Integration with other identity systems
If you have an existing identity system, such as Microsoft Active Directory, you can integrate it using standards-based federation technology so AWS can be administered without additional credentials. The ability to manage these federated users gives you a more centralized system so you aren’t switching back and forth.
IAM enables multi-factor authentication, which means your teammate's credentials aren't totally compromised when someone finds their notebook with all their passwords. After the user enters their username and password, they’ll have to enter an authentication code prompted by their AWS device. These devices include security keys, key fobs, or card displays provided by third-party suppliers. You can require multi-factor authentication for users to access certain resources.
We strongly recommend you set up AWS CloudTrail, which will send you logs of requests for access to services. This will make it easy for you to stay on track with API activity and stay compliant, keeping your IAM service reliable and available. You can also use CloudWatch, which will monitor your AWS resources and the applications that you run on AWS in real time.
Important note: IAM operates under the Shared Responsibility Model, which means you’re responsible for the security of your personal data you put into the cloud.
AWS IAM can help you enact more control over your organization while you’re physically out of the office and away from your teammates. Assigning the right policies to the right users with multi-factor authentication can seriously reduce the risk of a security breach, especially if you're working with someone who isn't the best at guarding their information. If you agree this feature of AWS is great for remote work and makes it more secure, contact us and we’ll help you get set up with AWS and guide you through IAM!