AWS Fundamentals: Addressing Security Risk

Protection :

1.Compute resource :

AWS will be responsible for protecting the hypervisor and EC2 instance isolation. To secure your EC2 instances, there are several best practices that we recommend.

1. restrict access at the network and the OS layer.
2. you can leverage security groups as the primary mechanism for controlling network access to EC2 network interfaces.
3. you can use network ACLs as a secondary control for denying a specific subnet of traffic, all providing high-level subnet guardrails.
4. on the instance itself, you should only install necessary packages for your operating system and applications.
5. it is also recommended that the SSH key be used to log in to the EC2 instances need to be secured, and providing interactive access to EC2 instances should follow the least privileges model.
6. controlling the API access coming from EC2 instances is important. When your applications run on EC2 instances need to access our AWS services, you should use IAM roles to grant permissions for the instance to make API calls.
7. using IAM roles eliminates the need to distribute and rotate long-term credentials on EC2 instances.
8. we recommend to regularly scan and install missing patches for your instances. This is where AWS Systems Manager can help you to automate processes around patching Windows and Linux EC2 instances.
9. apply security monitoring and auditing for EC2 resources and your accounts.
   1. This will include enabling AWS CloudTrail, to capture API calls, which will enable AWS Config to audit and track changes made to your EC2 resources.
   2. Now, if you choose to run your application in Docker containers, there are several container management and orchestration services available. You’ll maintain control over the container environment, the operating system, and the underlying EC2 instance when using Amazon ECS and EKS. However, you have control over the container environment.
   3. ECS, EKS, and Fargate let you use IAM roles to control requests from the application running on containers to other AWS services.

1. For more information on securing EC2 instances please see: https://aws.amazon.com/answers/security/aws-securing-ec2-instances/
2. This white paper provides an overview of security when using Lambda: https://d1.awsstatic.com/whitepapers/Overview-AWS-Lambda-Security.pdf
3. More details on Amazon ECS can be found at: https://aws.amazon.com/ecs/features/

2.AWS Lambda :

AWS Lambda automatically runs your code without requiring you to provision or manage servers. You just write the code and upload it to Lambda. AWS will manage the underlying infrastructure and foundation services, the operating system, and the application platform for Lambda. You are responsible for the security of your code, the storage and accessibility of sensitive data, and IAM to the Lambda service and within your function.

Each Lambda function runs in one or more dedicated execution environments that are used for the lifetime of the function, and then it will be destroyed. So, you can use CloudWatch and CloudTrail to monitor and audit your Lambda functions, and you can also track configuration changes to allow the function using AWS Config.

3.Protecting the Endpoints :

Elastic Load Balancing works with Amazon Virtual Private Cloud (VPC) to provide robust security features, including integrated certificate management, user-authentication, and SSL/TLS decryption. Together, they give you the flexibility to centrally manage TLS settings and offload CPU intensive workloads from your applications.  For more information on ELB, see https://aws.amazon.com/elasticloadbalancing/ 

There are a few different types with the two notable ones being the Application Load Balancer, or ALB, and Network Load Balancer, or NLB. The ALB operates on the individual request level, or Layer 7, and the Network Load Balancer operates on the connection level, or Layer 4.

In our example, we’re using the NLB, and we’re load balancing traffic across our fleet, using a round-robin algorithm, which rotates traffic in order between the instances. Our fleet hosts a website, and since we want to secure it by default, we require that the traffic is always transported over HTTPS. HTTPS, and it means that requests will be encrypted and decrypted. In order to achieve this on our EC2 instances, we route the encrypted traffic through the NLB and then terminate them on the instances themselves. Requests will then be decrypted on the instances, and the application can proceed further.

Additional information about TLS termination for Network Load balancers is available in this AWS Blog posting: https://aws.amazon.com/blogs/aws/new-tls-termination-for-network-load-balancers/

Improvised Solution :

By using the NLB, we can terminate our HTTPS traffic on the load balancer itself, which will free your EC2 servers from the compute-intensive work of encrypting and decrypting all of your traffic. You also get some added benefits, like simplified management, access logs, and improved compliance.

4.API Gateway :

API Gateway, where API stands for application programming interface. It’s a fully managed service, which allows you to create, publish, maintain, monitor, and secure APIs at any scale. By using API Gateway, you can expose certain application logic via REST or even WebSockets.

In essence, you’re only allowing access to needed parts of your application, and therefore, you’re not opening, say, your backend for the whole world. This notion of protecting your backend, and other critical systems, such as your database, is a best practice for any architecture, and we highly recommend it when designing your next workload.

Q. How do we make sure only authorized users can use it?

You can add optional authorization processing, such as AWS Signature Version 4, or SigV4, even Lambda authorizers. SigV4 works via AWS credentials. These being your access and secret keys, which authorize access by signing those requests to your service. When you create your API Gateway service call structure, you essentially generate a custom SDK for your service, and this custom SDK will handle the signing for your requests. If you don’t want to use permanent credentials, you can even use Amazon Cognito to retrieve temporary, role-based ones, so you can make calls to your API. The other option for securing your API Gateway is via custom Lambda authorizers, which are actually AWS Lambda functions. And as a reminder, Lambda functions are the serverless compute offering on AWS, and allow you to write your code as reasonable functions, in a language of your choice.

This means that if a Lambda authorizes is configured, API Gateway calls the Lambda function with the incoming authorization token, and depending on the strategy you implemented, it will return IAM policies, which are used to authorize the request. If the policy returned by the authorizer is valid, API Gateway will then cache the policy associated with the incoming token for up to 1 hour. And, that’s how you can secure your API Gateway.

5.AWS Shield :

AWS Shield is a managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS. AWS Shield provides always-on detection and automatic inline mitigations that minimize application downtime and latency, so there is no need to engage AWS Support to benefit from DDoS protection. There are two tiers of AWS Shield – Standard and Advanced.

6.AWS WAF :

AWS WAF is a web application firewall that helps protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources. AWS WAF gives you control over which traffic to allow or block to your web applications by defining customizable web security rules.Also, AWS WAF includes a full-featured API that you can use to automate the creation, deployment, and maintenance of web security rules. 

Secrets Manager :

These database credentials can be defined as a type of secret. They need to be carefully stored and handled. Other secret types can be password, third-party API key, and even arbitrary text. Handling of these secrets can be an important task in any infrastructure that requires secure handling and protection from unauthorized access. . You also want to rotate your secret frequently to avoid things like stale credentials from being used against you. And keep in mind that your secret will need to be encrypted at rest and in transit. A best practice is never to log the secret in system logs or application logs.

AWS Secrets Manager is an AWS service that makes it easier for you to manage secrets. In short, it gives you the ability to have a centralized storage for the secrets and provide direct access to only the necessary components. So, the way that Secrets Manager works is,

1. an admin creates or retrieves the secret. In this example, the secrets are database credentials.
2. the admin then stores the credentials in Secrets Manager and limits access to only the necessary users. Here, the user is a custom application running locally.
3. the application makes a call to Secrets Manager using its credentials that it has from the associated IAM role.
4. because the admin allowed for the application to have access, the application is then allowed to retrieve the credentials
5. Once the credentials are retrieved, they are stored in a non-persistent way, and then the credentials can be used to access the database, as we see with step number five.

well architected framework :

It’s composed of five pillars to ensure a consistent approach to reviewing of architectures and designing for scaling over time,

1. It’s cost optimization,
2. operational excellence,
3. reliability,
4. performance efficiency,
5. security.

You can now access it via the AWS console, create a workload, and run it against your AWS account to generate a report showing areas that should be addressed. It’s similar to the traffic light system with AWS Inspector, with green being, everything is okay .Orange being, there is room for improvement and red being, there is a critical error that must be taken care of .

previous blog in the series :https://programmerprodigy.code.blog/2020/05/31/aws-fundamentals-awscloud/

next blog in the series :https://programmerprodigy.code.blog/2020/06/05/aws-fundamentals-migrating-to-the-cloud/