Quantify Cyber Risk Now

header ads

AWS Best Security Practices 2018 | Lucideus Research

In the coming years, Cloud Computing is the domain in which every organization will be focusing on as we have to move our infrastructure to the cloud because to maintain it on premises it is quite difficult for us to handle security, monitoring, logging, failover, autoscaling, backups of the applications.

So everyone will be opting for Cloud Servicing Platforms such as AWS(Amazon Web Services), Google Cloud Platform, Microsoft Azure etc.But to apply the cloud computing techniques with best practice and in a secure way is a difficult task.

So here we will be listing down some of the best practices in AWS Cloud Platform through which we can completely secure our infrastructure from outside attacks.

1. Infrastructure / EC2 Instance level : 

3.Using AWS Secret Key and Access Key Id in a secure and protected environment:

Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3)

4.1.2 For Client-Side encryption we have the following techniques : 1.1 We can setup up password authentication for pems and ppks for the instance level access in AWS and we should maintain user level pems/ppks for instance access which means that one ppk/pem should not be there for accessing the server whereas every user should have its own ppk/pems in order to access the instance.

1.2 We should not directly access the different instances through pems/ppk but there should be bastion or jump box server through which we should route the ssh connections to other servers.

1.3 We should configure proper routing mechanism in our Security Groups which provide routing configurations to the instances with their respective ports that is we should be aware of our organization and client locations Ip address and should enable the traffic from those ip only and not for the wildcard entries i.e , ::/0

1.4 We should setup VPN so that our traffic in transit is encrypted while accessing our infrastructure and through this we will not be using public IP’s anymore for accessing the resources and in turn we will be using private IP’s which are even more secure as private IP’s are restricted to the internal infrastructure and not to the outer world. 

1.5 We should define our infrastructure with public and private subnets because they help our applications to get segregated in public and private facing applications and moreover we can choose how to route traffic from these subnets to the internet with the help of Gateways.So if we want our private applications to be secured from outside world then we should make the route table of that subnet not associated to internet gateway and in turn, we should associate it with NAT gateway because it will help us to route traffic from private subnet to the internet and not vice versa.

2.Accessing Management Console of AWS :

2.1 We should enable MFA (Multi-Factor Authentication) for accessing the management console because it enables an extra level of security for the login as we know login passwords can be hacked.MFA adds extra security because it requires users to type a unique authentication code from an approved authentication device or SMS text message when they access AWS websites or services.

2.2 MFA consists of 2 types : 
2.2.1 Security Token Based: This type of MFA requires you to assign an MFA device (hardware or virtual) to the IAM user or the AWS account root user. A virtual device is a software application running on a phone or other mobile device that emulates a physical device. Either way, the device generates a six-digit numeric code based upon a time-synchronized one-time password algorithm. The user must type a valid code from the device on a second webpage during sign-in.

              2.2.2 SMS text message-based : This type of MFA requires you to configure the IAM user with the phone number of the user's SMS-compatible mobile device. When the user signs in, AWS sends a six-digit numeric code by SMS text message to the user's mobile device. The user is required to type that code on a second webpage during sign-in. Note that SMS-based MFA is available only for IAM users. You cannot use this type of MFA with the AWS account root user.

2.3 We should not log in through root account to the management console because we would not be able to track the actions of who did something malicious in the account and would not be able to catch him because many people are accessing the console through the same root credentials and to avoid this we should use the IAM(Identity Access Management) of AWS which create users ,groups and roles and assign the privileges on the basis of their requirements.This will block the unnecessary resources provided to the user which he doesn’t need it.

2.4 By enabling Cloud trail service of AWS, we can track users login date and time, the actions which he performed in the account and every event which he created in the management console.Moreover, through cloud trail, we can track the application level security, for example, the web services requests which are being made on to the servers and from where they are coming.We can enable WAF(Web application firewall) to filter the traffic based on the request destinations and apply a regular expression to filter for the data being sent in the request which can harm our servers.Moreover, we can block SQL injections and cross-site scripting with WAF enabled in our system.

3.1 We should use AWS STS(Security Token Service) for accessing the AWS services through secret and access key id.Through this, we will not be using the permanent credentials provided by the AWS and in turn, we will be using temporary credentials which will be valid for a specific period of time and when its TTL expires, again we have to request the temporary credentials for a specific period of time and use them.Due to this if anyone access the credentials somehow then these will be deleted by the AWS after that TTL.So it's more secure than using the permanent Secret and Access key Id provided by the AWS.

3.2 We can also use PreSigned URL for accessing the services of AWS.For example if we want to access S3 Bucket Object then we can generate pre signed urls which are valid for a certain duration and are not valid if their TTL expires.

3.3 We should store these credentials in the encrypted format with a well-known encryption algorithm that is AES256 etc. so that it cannot be decrypted to a plain text format and visible by others.

4. Protecting data using Encryption
4.1 We should protect data at the client, in transit and at rest.So AWS provides all the 3 features of encrypting the data in a secure way that no one is able to fetch the packets of traffic and decrypt it.
4.1.1 For server-side encryption we have following techniques : 

Using AWS Managed Customer Master Key (CMK)
Using Client Side Master Key

4.1.3 For in transit encryption we have use the Route53 generated SSL certificate which take care of the network traffic in transit.


Post a comment


  1. Hey..nice information thanks for providing for more updates on AWS AWS Online Training