Customers are used to being able to use a lot of internet tools within their environment. They have a lot of security controls. We have got compliance, regulatory, audits, and all of these things that customers really wangle with. AWS Compliance program really just helps customers understand the different controls that are in place at AWS. If you’re having to comply with ISO, PCI, SOC-2, HIPAA, or Fredramp you can still inherit those same types of security controls and still operate in the cloud by choosing our Cloudnosys services. Let’s have a look at some of the best AWS cloud security practices to make

Security Groups

Security groups act as Virtual Firewall for your EC2 instances. The function of security groups is to block all the traffic except the protocols, ports, and ports, and sources that you define. When we use these different concepts, we can set up very robust security and many different layers to secure our AWS infrastructure sufficient in our use case.

In Security groups, we define rules which are inbound and outbound which means they are stateful which means when we define an inbound port, protocol, and source combinations, we are also going to define outbound rules which gives us very secure access control.

IAM MFA Audit

Identity and Access Management (IAM)

IAM stands for Identity and Access Management. IAM is a permission system that regulates access to Amazon Web Service resources. It helps us to define administrator and who can access what on an AWS account.

Secondly, IAM users allow you to assign broad or specific permissions to individual users or even groups of users. Broad permissions could include things like providing access to the entire AWS services such as DynamoDB. Specific permissions could include detailed access to a particular S3 bucket to perform read and write operations. Moreover, IAM provides a mechanism to monitor and audit access to specific resources by enabling AWS cloud trail.

IAM is best for those who are in big organizations with existing identity technologies because AWS IAM can easily integrate with other identity technologies such as Microsoft Active Directory.

Multi-Factor Authentication (MFA)

Users have access to our account and can possibly change configurations of deleted resources in our AWS account. So, we have to protect our root accounts and IAM users. Here comes another security layer on top of our passwords i.e. called Multi-Factor Authorisation.

What MFA really does is there is a password that we know, and there is a security device that we own. These two together have much greater security than just alone the password. 

Benefits of MFA:

The main benefit of using Multi-Factor Authorization is if a password is stolen or hacked, the account will still not be compromised because the hacker will also need to have your personal physical device that would be connected with the password. 

There are:

Virtual MFA Device:

Virtual MFA devices include a google authenticator, which can work on one phone at a time. It supports multiple root accounts and IAM users. 

Universal 2nd Factor (U2F) Security Key:

U2F Security Key is a physical device such as YubiKey. We can use physical devices because it’s very convenient to use. Physical keys support multiple root accounts and IAM users. It is a third-party device.

Hardware Key Fob MFA Device:

Hardware Key such as Gemalto. It also comes under physical device and is another option to be used and MFA. It is also a third-party device. 

ELB Access Log

ELB stands for Elastic Load Balancer. The load balancer is a server that will forward all the internet traffic to our instances of our applications downstream. We have EC2 instances and a load balancer before that. When the users connect, they do not connect directly to the EC2 instances. They will connect to the load balancer so we have user one connecting and the load balancer basically redirects that traffic to the EC2 instance. The instances come back with a response to the load balancer and the load balancer gives back the response to the user one.

Similarly, we can have user two that will connect us to another EC2 instance and user three will connect to another EC2 instance. It is called a load balancer because we can see user one, two, and three do not go to the same EC2 instances in the backend. Hence the load is being balanced.  

Access logging

Access logs are shared by Elastic Load Balancer and provide complete information regarding requests submitted to our load balancer. Individual log holds information like; the time in which request was received, the client’s IP address, latencies, request paths, and server responses. These access logs can be used to study traffic patterns and troubleshoot problems. 

ELB’s access logging is not a mandatory feature and it’s turned off by default. Once we turn on the access logging for or ELB, ELB stores the logs in the Amazon S3 bucket that we mention as compressed folders. 

Termination Protection

Termination protection is used to protect giants accidental termination in AWS console or CLI. So basically this is to protect employees against making mistakes.

ELB Listener Security Audit

A configuration named Secure Socket Layer (SSL) is used by Elastic Load Balancer to negotiate is called Security Policy. Security policy is negotiated between the client and the load balancer/ Security policy consists of protocols and ciphers. A secure connection and protocol are established by protocol between client and server to make sure all the data transferred between the client and our load balancer is private. 

Cipher is an algorithm that is used for encrypting to develop and code messages. It’s done by using encryption keys. Many different ciphers are used to encrypt data to be sent over the internet by protocols. 

Unused IAM Access Keys

AWS Lambda is a serverless architecture to identify old and unused IAM access keys in our account. It is an important security measure to identify old and unused keys and remove these vulnerabilities from our accounts.
Sometimes there are a lot of keys that we might not be able to remove manually, so it is very handy to have a lambda function that is triggered by cloud watch scheduled events which will scan our accounts for old user keys and then send an SNS email to our security operations team or to the end-user so they can rotate or delete their keys.

Root Account Access Key

When we initially set up an AWS account, we created a single identity that has full access to all of the services and resources. This account user is known as the AWS account root user. The best practice is to use the root user account just to create the first IAM user. 

We can create, rotate, disable, or delete the access keys for our Amazon Web Service account root user. One can have unrestricted access to all the resources in our AWS account if they have the login credentials of the root user account. 

When the access keys are created, key ID and secret access key are also created as a set. We should download the secret access key, else we will have to remove the old one and create a new key. We can make access keys for the root user with the help of the IAM console, AWS CLI, or AWS API. 

IAM Admin Roles Audit

How does IAM Works?

There are four key components in IAM. Users, groups, roles, and policies. 

Users: 

Users refer to specific individuals and using IAM we can grant each user login and password so they can access the AWS on their own, although they will have a limited set of permissions that we define. Users also have secret key access keys which are used as inputs when setting up clients in our application-level code.

Groups: 

Groups refer to a collection of users with a common theme. An example could be interned students and senior developers. Obviously, we want intern students to have a very different and limited set of permissions than a senior developer. 

Roles: 

Roles act as a collection of policies. For example, we can define a role that has both databases read and write permissions to a specific AWS DynamoDB table. Roles have a slight change and they are typically not directly tied to individual users and are meant to be assumed by anyone who needs it. For instance, we can use roles to allow users within a different AWS account to access one of our DynamoDB tables by making a role with the correct permissions and then allowing them the ability to use that role.

Policies:

Policies are the bread and butter of IAM. These things define the specific low-level permissions for access to AWS resources. There are two variations to these; either allow or deny, so we can allow or deny permissions to resources.

Using the IT resources of the organization, an IAM procedure should be created to initiate, alter, track, record, and terminate the specific IDs associated with each account.

Some of the major roles of IAM administrations are following:

• Monitor Manage passwords
• Audit and reconcile
• Administer policies
• Strategize
• Manage systems

CloudTrail

CloudTrail is a service whose primary function is to record and track all the AWS API requests made. These API calls can be programmatic requests initiated from a user using an SDK, ADA best command-line interface from within the AWS management console, or even from a request made by another ADA rear service. CloudTrail supports over 60 AWS services and features. It is also very effective for security analysis.

CloudTrail captures the API requests as an event and records these events within a log file which is then stored on S3. Each API call represents a new event within the log file. CloudTrail also records associates and other identifying metadata with all the events. For example, the identity of the caller, the timestamp of when the request was initiated, and the source IP address. CloudTrail log files can be used to deliver to CloudWatch logs for metric monitoring and alerting via SNS.

Our controls and our compliance programs are something that we are continuing to grow every single year. You can pull a compliance audit report through our Cloudnosys compliance services to check if you are compliant.