Securely manage your users remotely with AWS IAM
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 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.
With IAM, you can determine who can carry out important tasks like who can launch an EC2 instance. 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.
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, which is 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.
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 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 people, 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. Even if you underestimate what they’ll need, you can always add more privileges.
When users will need to access resources outside of the norm, you can create temporary credentials. This can be done by creating 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 it’s you who defines which entity is allowed to assume the role. 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.
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.
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 to add an extra layer of security for all users you create. 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. 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 greatly reduce the risk of a security breach. 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.