10 Things To Do In AWS Account Before You Use It

Lot of organizations started doing IT digitization using some or other cloud offerings. Everything in the cloud is available at your fingertips and is a couple of clicks away. This makes us more vulnerable to attack, if you do certain things without much understanding or not handled properly at the organization level. These things will go out of hand pretty soon, if not contained earlier. AWS offers a large set of services some are designed to get exposed over the internet, some work within your virtual private cloud. Not all the time your business use case is to have certain services/data available over the internet. Human error or untrained resources in a short amount of time can make your sensitive data exposed to the world. These mistakes could turn costly and by the time you realize irreversible damage is done. Proper precautions are the only safeguard mechanism. So I have tried to list down top 10 major things, you should be doing when you start using your AWS account for your organization.

Not these Roots 🙂
  1. AWS Root Account:- Least privileges access should be your principal when you are providing access to anyone. The root account is not meant for day to day activities related to infrastructure setup and it has admin privileges. Create IAM Users with different privileges with keeping purpose in mind.
MFA

2. Enabling MFA On All Accounts :- Enable Multifactor Authentication for all the accounts and users who have access to the AWS account. This could be implemented using your mobile phone, google authenticator, or any other MFA, authenticator.

Define Encryption Keys

3. Define Encryption Keys:- Think about your encryption mechanism about how you are going to encrypt the data in the cloud. It is a quite a big topic, which demands another article. Quickest and easiest way is to start using AWS KMS for the creation of AWS managed keys or CMK(Customer Managed Keys). Define multiple keys for your common storage devices like S3, EBS & EFS. This gives you coverage about the encryption of information at rest. Even if this storage is allocated to some other account they can not recover any data. Again AWS does make sure to erase everything when they allocate storage to other clients once your usage is over but this is extra protection.

Groups

4. Define IAM Groups : -You can use groups to specify permissions for a collection of users, which can make those permissions easier to manage for those users. Identify multiple possible groups in the organization and assign them privileges only to the resources on which they will be working on & start assigning those groups to the users who belong to the same group.

You know this 🙂

5.Enable Cross account CloudTrail :– Enable cross-account Cloudtrail destination,so that if someone has access to your AWS account who tries to do malicious activities, everything is recorded. At the same time, you want to make sure cloudtrail in the account is not deleted and you have all the forensic data for analysis with proper alerting through different account.

Subnet defining

6. VPC Setup:- Again this is a quite big topic and you can refer to my other article for it https://sachinkapale.blog/2019/12/29/awsvpc/. You should have already answers to the below questions, What will be your networking strategy? how many subnets do you need? What type of subnets you need, private or public? Internet gateway & NAT setup. You can refer to my earlier article to give you actual examples of each setup. You should have some level of alerting if someone is trying to modify your routing table entries or trying to make resources public.

VPC Security Group

7. VPC Default Security Groups :- Each VPC comes with a default security group and it is not at all recommended to use VPC security groups to any of your AWS services. This security group should not have any inbound and outbound rules.

NACL Rules

8. NACL Rules:– This should your first line of defense for any security attack & you should define those broader rules in NACL and further you should define much more granular rules in security groups. You should have a clear understanding of what is used for what purpose.

Alright, you got the point

9. Enable Guardrails:- Start putting some guard rails using SCP or AWS control tower. Define config rules, which makes sense, and define SNS topics on which you want to get alerted.

S3 & Dynamo Db through Gateway

10. S3 Buckets & Dynamo DB protections:- If you don’t want any communication to happen over the internet for S3 buckets & Dynamo DB, define VPC gateway endpoints. These endpoints make sure you are communicating over AWS backbone network for access to S3 buckets & Dynamo DB from your VPC.

Conclusion: AWS is ever-changing and you need to constantly keep on revisiting your standards but if you put proper guardrails you are covered from any attacks. Please comment and stay tuned for more topics on my discovery.

Categories AWS

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close