Securing AWS Account with Identity and Access Management
Amazon web Services provides a sturdy set of controls on its own infrastructure, however, it is important to remember that you are responsible for the security of your own servers, not Amazon according to shared responsibility model.
As a part of the AWS shared responsibility security model, customers of AWS play a major role in securing their use of the service. Within the CSIS 20 critical Security Controls, critical control no.12 is that the controlled use of administrative privileges and also the responsibility for defense is directly on you because of the user of AWS.
Earlier to virtualization or cloud, the executive privileges were usually your accounts to the OS. However, currently, you’ve got a way an additional authoritative set of credentials to administer the access to the AWS console and APIs. Proper management of access to AWS is the first step.
Instead of AWS “root” Account and Use Identity and Access Management (IAM) to Enable Access.
You get your credentials (Username and password) when you signed up for AWS service. This account has root access to all of your AWS services. So keep these credentials safe and don't share this with anyone.
Now to enable IAM or Identity and Access Management go to the IAM section on the console to begin assigning Groups and Users.
Generally, you may want 2 sorts of users:
- People with a username and password to access the AWS console
- Programs using an Access Key Id and Secret Access Key to access the APIs
For the users you produce, you'll be given a special URL known as the IAM user sign-in link. Give this URL to the users you produce alongside their username and password. They won’t be ready to use the main sign-in link. The principle of least privilege is also essential for users you create to grant access to the AWS APIs. If you're developing an application that ships information from your datacenter to S3 you'll need to solely change S3 “Put” operations during a custom policy using the policy generator tool. That means if that key's compromised your damage is extremely limited. Creating specific users can assist you to control permissions for the folks and programs accessing AWS, and permit you to separately revoke access once required. For instance, if you provide an access key to the third party program or service, it's much easier to revoke it once it's a properly named user account.