When to think about Security in AWS?

One of the first things you should do when building for AWS is start thinking about Security. You have to be on your toes right from the beginning. In the arena of Cloud, security cannot be an after thought. Consequences of failing to consider security from ground up is huge.

Starting with AWS Account

Do not jump to AWS site and start creating an AWS Account yourself. Find out who is the right authority to own AWS Account.

• Ask your Partner to setup the AWS Account. You can provide help to the partner and guide them through the process.
• If we are to own the entire environment for any reason then reach out to IT Support and get the IT Admin to setup the AWS Account.
• On creation of AWS Account it gets a Root User Account. This Root account has full access to all of the AWS Resources. This account is accessed by the email address used to create the AWS Account.
• Day to day administration should NOT be done using this Root Account.
• You or the Team do NOT need credentials of this root Account. This should strictly belong to Partner or IT Admin.

When setting up an AWS Account

There are many things to consider and undertake when setting up an AWS Account. Here is a list of things you should ask or guide Partner/IT Admin to do when setting up a new AWS Account.

• Use complicated password - mix of upper and lower case, special characters, and numbers.
• Enable Multi Factor Authentication on the Root Account
• Delete Root Access Keys, these are used to access AWS resources programatically
• Create an Administrator Group - 'administrator'
• Assign 'AdministratorAccess' policy to this group, this gives same access as the root user.
• Create an Administrator User - 'admin'
• Assign access type AWS Management Console
• Assign to 'administrator' group created above
• Require Password Reset on Login
• Get the account login url and accountId. Account Id is required to be specified when you want to login into any account.
• Now use this new user - 'admin' to login into the AWS Management Console.

AWS IAM Setup

Once an AWS Account has been setup and an 'admin' user is in place, the Lead Developer can start to setup the environment in AWS. First thing that Lead Developer needs to do is login using the 'admin' user, change password and start creating AWS IAM Groups and separate IAM User for each team member requiring access to AWS.

IAM Groups

Start with AWS IAM Groups. Group is used to manage access to a group of users. You would assign a set of access policies to a Group and then assign some users to the Group. All the users in a Group will have the same access as defined by the policies assigned to the Group. This makes administration of users and their access easy.

IAM Policies

AWS IAM Policy is a json document. It is an entity that provides permissions to a resource. It can be used to allow or deny access to a resource. Avoid making use of policies with broad and sweeping access but operate from least privilege principle.

Broad policy - Do NOT use

{
    "Version": "2021-01-01", 
    "Statement": [
        {
            "Effect": "Allow", 
            "Action": "*", 
            "Resource": "*",
        }
    ]
}

Grannular policy - Recommmended

{
    "Version": "2021-01-01", 
    "Statement": [
        {
            "Effect": "Allow", 
            "Action": ["s3:GetObject", "s3:ListBucket", "s3:GetBucketLocation"], 
            "Resource": "arn:aws:s3:::projectX",
        }
    ]
}

IAM Roles

IAM Role is also an IAM Identity that has specific permission. It is like an IAM User but differs in that IAM Roles are meant to be assumable by whosoever needing them. So for example an EC2 instance can assume and take on a IAM Role to perform some task, similarly even a user can take on an IAM Role to perform some task. See below illustration.

Recommendations

• You can setup these three groups - administrator (Setup above), developers and testers.
• Create and Assign IAM policies to these groups according to the level of access you want each type of IAM Group to have.
• Create individual users in AWS IAM User for each of the team member requiring access to the AWS Resources.
• Attach appropriate tags to each user as you create them.
• Enable programmatic access only if those users need to access AWS Resources programmatically.
• Require Password Reset on Login for each user
• Enable MFA for each user.
• Only Lead and DevOps engineer should be part of administrator group.
• Never share same User credentials among the team members, not even the programmatic access keys.
• Never embed your Secret ID and Secret Key for accessing any of the AWS Resources from your Web App or API or Lambda.
• Create an IAM Role for allowing access to AWS Services like S3 or DynamoDB or SQS and Attach these IAM Role to EC2 Instance or Lambda functions that need to access them.
• Consult with Partners and enable AuditTrails for all resources (including AWS Global Resources)