- Service Delivery Program
- About Us
As the industry is moving towards DevSecOps culture, security and infrastructure deployment are not just the tasks of the security and operations teams. Today, developers are keen on including security and operations activities to understand what is best for their application.
This blog will discuss the aspects of security for an application and network for your Infrastructure and how AWS services can be implemented to achieve the goal.
TABLE OF CONTENT
|1. IAM (Identity and Access Management)
|2. Multi-Factor Authentication (MFA)
|3. Strategy for Using IAM in your Infrastructure
|4. AWS Shield
|5. AWS WAF
|6. Strategy to secure Application and Network of your Infrastructure
|8. About CloudThat
AWS IAM is a web service offered by AWS that helps us securely control AWS resources’ access. In addition, IAM is used to authenticate and authorize users to use resources. Here is a blog about 8 Best Practices of Identity and Access Management (IAM) for further reading.
When we create an AWS account for the first time, we will begin with an AWS account root user that has full access to all AWS services and resources present in the AWS account. This root user will be accessed by login with the email address and password that is used while creating the AWS account. It is recommended not to use the AWS root user for our daily tasks, even the administrative tasks. Instead, we adhere to the best practice of using a root user only to create our first IAM user.
IAM provides the following features:
AWS MFA provides an added layer of security on top of the AWS Credentials. With MFA enabled, users can log in to their AWS account using AWS Management Console. They need to provide their username and password, and an authentication code is generated by the AWS MFA device they have registered. These multiple factors for authentication increase our AWS account’s security and the AWS resources we have created. You can enable MFA for the AWS account and for an individual IAM user that you have created in the AWS account. MFA is not chargeable.
To provide the correct permissions to the users to access the required resources in your AWS infrastructure, we will be creating IAM groups based on the roles of the users like Admins, Developers, Testers, etc.
An IAM group is a collection of IAM users. IAM Groups let you specify permissions for multiple users, making it easier to manage the permissions for the users based on which group they belong to. For example, you can have a group of users called Admins and give that group Permissions that administrators require. All the users in that group will automatically be granted the permissions assigned to that group. However, suppose a new user needs to be added and needs administrator privileges. In that case, you can add that user to the Admins group, and the user will be assigned the appropriate permissions. Similarly, if a user’s role needs to be changed in your organization, instead of editing that user’s permissions, you can remove that user from the old IAM group and add that user to the new appropriate IAM group.
The permissions of the IAM groups and their users will be controlled by using IAM policies, which can be either AWS-managed policies or Customer managed policies. AWS-managed policies are policies created and owned by the AWS team, whereas we create and control customer-managed policies. Using IAM Policies, we can create permissions for IAM groups or IAM users, and based on the IAM policies, and they will get access to the AWS resources. For example, we can provide Development Server access to users who belong to the Development group and Test server access to users who belong to the Testing group.
We can have AWS CloudTrail to record and log all the API calls inside our AWS account. We can then use these logs or records to have auditing in a place where we can check if any suspicious activities have taken place in our account or not, and based on that; we can take actions on that activity. Whenever you create an AWS account, CloudTrail will get enabled by default, so we don’t need to take an overhead to enable it.
AWS Shield is a managed service that protects from Distributed Denial of Service (DDoS) attacks for applications running on AWS. It provides always-on detection and automatic inline mitigation that minimizes application downtime and latency, so there would be no need to engage the AWS Support to benefit from DDoS protection.
AWS Shield Standard helps to protect your application from the most common attacks occurring at network and transport layer DDoS attacks that target your website or applications.
AWS WAF is a web application firewall and helps protect your web application or APIs against the common web exploits and other bots that may affect availability, compromise security, or even consume excessive resources. AWS WAF gives you control over how the traffic reaches your application by enabling you to create a few security rules that control both traffic and block common attack patterns, like SQL injections or cross-site scripting.
After creating an AWS WAF web access control list (web ACL), create, or update web distribution to associate distributions with the web ACL. You can also associate as many CloudFront distributions as you want with the same web ACL or different web ACLs.
Image Source: aws.amazon.com
For Securing your Infrastructure Applications and Network, we can use security features provided by AWS like Security Groups, Network Access Control Lists (NACL), AWS WAF, AWS Shield.
In the above architecture, we can create a new VPC that will have private subnets where our application and database servers will be running. We can have our Elastic Load Balancer created inside the public subnet. Our application servers will be kept behind an auto-scaling group which will scale our application whenever there is a spike in traffic on the application server. Our Auto-Scaling group should be kept behind an Elastic Load Balancer and traffic coming from the internet will be distributed to the EC2 Instances using the Elastic Load Balancer.
We will use the security group to provide security to our EC2 Instances where our applications will be running. For example, we can only allow traffic or requests to our EC2 Instances from the AWS Elastic Load Balancer. No other internet traffic will be able to access our application. In this way, we can secure our applications running on the EC2 instances.
Image Source: aws.amazon.com
To secure our Database servers, we can use security groups that will act as a firewall for the Database. Here in this scenario, we can allow the traffic to our Database only from the EC2 Instance where our applications are running so that no other requests or traffic will reach our Database. Traffic to our Database can be managed using the Security Groups.
For Serving the requests coming from the internet, we can use Elastic Load Balancer, which is present in the public subnet and allowed to serve the traffic from the internet over port 443. Since ELB is a fully managed service of AWS, we don’t have to worry about its downtime or updates. By Using Security Groups, traffic to our Elastic Load Balancer can be managed.
For Subnet Level security, we can use Network Access Control List (NACL), which will help us to secure our network. Using NACL, we can manage the requests coming to our network. Furthermore, we can Allow/Deny incoming or outgoing traffic based on our requirements. Hence, using NACL we can secure our Subnets.
An added layer of security can be provided to our applications by using AWS Web Application Firewall (WAF). We can use AWS WAF to secure our applications from various cyber-attacks like SQL Injections or cross-site scripting. It uses conditions to target specific requests and trigger an action. It allows you to identify and block common request patterns and effectively avoid attacks. We can block a request using AWS WAF based on the length of its query string or request body. We can also restrict the traffic based on the geographic regions known as geo-blocking.
We can have AWS Shield Advance in place for an added layer of security for your network. AWS Shield Standard is by default enabled to many AWS services. We don’t need to enable it explicitly.
AWS WAF combined with AWS Shield serves as a comprehensive result for improving application security in the AWS environment. With cyberattacks, especially DDoS attacks only anticipated to increase, effective, quick discovery and response are crucial.
The two AWS solutions, AWS WAF and AWS Shield are available to registered Amazon clients at no additional charge. Also, both these products are highly scalable, allowing developers to develop your system without compromising on security dynamically.
Deploying AWS WAF and AWS Shield to your AWS environment is easy and will help you stay on top of your ever-increasing business security requirements.
Here at CloudThat are the official AWS (Amazon Web Services) Advanced Consulting Partner and Training partner and Microsoft Gold Partner, helping people develop knowledge on cloud and help their businesses aim for higher goals using best in industry cloud computing practices and expertise. We are on a mission to build a robust cloud computing ecosystem by disseminating knowledge on technological intricacies within the cloud space. Our blogs, webinars, case studies, and white papers enable all the stakeholders in the cloud computing sphere.
Feel free to drop a comment or any queries regarding AWS services, network security, infrastructure deployment, and we will get back to you quickly. To get started, go through our Expert Advisory page and Managed Services Package that is CloudThat’s offerings.
Our support doesn't end here. We have monthly newsletters, study guides, practice questions, and more to assist you in upgrading your cloud career. Subscribe to get them all!