Security Checklist for systems on Amazon Web Services

Security has always been a business concern when moving to the cloud, especially for businesses that store user data such as banking, finance, real estate, and insurance.

AWS Shared Responsibility Model

Security and compliance are a shared responsibility between AWS and its customers. This shared model can help reduce the operational burden on customers as AWS operates, manages, and controls components from the server operating system and virtualization layer to the physical security of the facilities. The department is operating the service.

The customers will be in charge of and manage the client operating system (including security updates and patches), other associated application software, and the configuration of the Security Groups and firewall provided by AWS.

shared responsibility model

The customer should carefully consider the services he/she chooses as the customer’s responsibility will vary with the service in use, the integration of those services into the customer’s IT environment as well as the law. and current regulations.

This nature of shared responsibility also provides flexibility and provides the ability to control customers to enable deployment.

Security in the Shared Responsibility Model

AWS’s Shared Responsibility Model makes it clear that certain aspects of AWS security are in the hands of the business, and businesses must be fully responsible for the security incidents that occur in the management of the business.

Security in the Shared Responsibility ModelCustomer’s ResponsibilitiesAWS’s Responsibilities
Preventing or detecting when an AWS account has been compromisedo 
Preventing or detecting a privileged or regular AWS user behaving in an insecure mannero 
Preventing sensitive data from being uploaded to or shared from applications in an inappropriate mannero 
Configuring AWS services (except AWS Managed Services) in a secure mannero 
Restricting access to AWS services or custom applications to only those users who require ito 
Updating guest operating systems and applying security patcheso 
Ensuring AWS and custom applications are being used in a manner compliant with internal and
external policies
oo
Ensuring network security (DoS, man-in-the-middle (MITM), port scanning)oo
Configuring AWS Managed Services in a secure manner o
Providing physical access control to hardware/software o
Providing environmental security assurance against things like mass power outages, earthquakes, floods, and other natural disasters o
Database patching o
Protecting against AWS zero-day exploits and other vulnerabilities o
Business continuity management (availability, incident response) o

To understand more on this model, please read more on the following link: https://aws.amazon.com/compliance/shared-responsibility-model/

AWS Security Checklist

This article has developed a checklist of best practices and highest priority, which businesses must follow to proactively stop threats. This checklist provides customer recommendations for Security Pillar matching in the AWS Well-Architected Framework.

aws security

Checklist of AWS Identity & Access Management (IAM)

Work ChecklistCheck
Avoid using the Access Keys of the root account in AWS as these allow full access to all resources 
Multi-Factor Authentication must be enabled for the root account to provide two-factor authentication 
Centralize identity with AWS Single Sign-On or 3rd party solution to avoid creating multiple IAM accounts arising frequently or using long-term (long-term) Access Keys 
Assign IAM user the necessary permissions to allow service logon or resource access through IAM Policies or IAM Roles if using cross-account 
Make sure the user account also has MFA authentication 
The IAM Access Keys must be renewed periodically 
Ensure a strong password policy for users and set up a 90-day lifecycle for passwords 
Assign permissions to users based on User Groups, rather than on individual users 
Granting minimal access while creating IAM Policies, these policies are required to take certain actions. 
Attach IAM Policies to Groups or Roles when creating 
Appropriate conditions should be used to limit refusal or authorization of action against resources 
Eliminate unnecessary IAM users who are inactive or inactive 
Use IAM Roles to grant access to applications on EC2 Instance 
Use multiple AWS accounts to separate data and resources on AWS, and enable the use of Service Control Policies to integrate guardrails in AWS Control Tower. AWS Control Tower makes it easy to set up and manage AWS multi-account environments 

Checklist of Amazon S3

Work ChecklistCheck
Ensure S3 buckets are not publicly accessible (publicly read or write) – users can enable ‘Amazon S3 block public access’ to prevent access from Public 
Use object-level or bucket-level permissions next to IAM Policies to grant access to resources. 
Enable MFA Delete to prevent accidental deletion of buckets 
Consider encryption of stored data, which can be done in two ways – server-side and client-side encryption 
Allows encryption of incoming and outgoing traffic through SSL endpoints 
Configure S3 lifecycle management (S3 lifecycle) through rule-based actions and use Bucket Versioning, to deal with random deletion 
Make sure S3 access logging is enabled 
Continuously inspect and monitor S3 buckets using Amazon CloudWatch metrics 

Checklist of Amazon EC2, Amazon VPC, and Amazon EBS

Work ChecklistCheck
Ensure data and disk (disk volume) in EBS is encrypted with AES-256 
Restrict access to instances from restricted IP ranges using Security Groups 
Limits the scope of ports opened on EC2 Security Groups, to prevent attacks through vulnerabilities 
Use IAM policies with restrictions for IAM users, roles that are allowed to change or modify the original AMI (Amazon Machine Images) 
Make sure Elastic Load Balancers have a valid Security Group associated with it and enable access logging 
Monitor and optimize default Security Groups, as they allow unlimited access for inbound and outbound traffic 
Use AWS Firewall Manager to automatically apply the rules of Security Groups and AWS WAF 
Ensure limited access to SSH, FTP, SMTP, MySQL, PostgreSQL, MongoDB, MSSQL, CIFS…, limit access to fixed IPs if possible. 
Use IAM Roles to grant access to EC2, instead of Access Keys for temporary requests 
If you are using the IAM user Access Keys for permanent permissions, make sure not to embed these keys directly in the code. 
Create different keys for different applications, rotate Access Keys, use MFA validation, and deactivate unused Key pairs 
Enable and enable VPC flow logs to record incoming and outgoing traffic in VPC for better tracking and early diagnosis of potential problems 
Delete unused Virtual Private Gateway and VPC Internet Gateway 
Make sure that no VPC endpoints are exposed to the public, by checking the key value in the policy. 
Make sure there are no Network ACLs that allow unrestricted access or exit 

Checklist of AWS CloudTrail

Work ChecklistCheck
Make sure CloudTrail has Multi-region feature enabled 
You should log into a centralized S3 bucket and use access logging and restrict access to the CloudTrail S3 bucket. 
Make sure both CloudTrail and CloudTrail logging have Multi-Region logging enabled 
Ensure CloudTrail log file integrity authentication is enabled 
Ensure CloudTrail logs are encrypted 
Use in conjunction with Amazon CloudWatch for binding metrics, with Amazon GuardDuty for continuous monitoring and AWS Security Hub for a holistic view of security on AWS 

Checklist of Amazon CloudFront, AWS WAF, and AWS Shield

Work ChecklistCheck
Uses Amazon CloudFront, AWS WAF, and AWS Shield to provide DDoS attack protection at Layer 3 (Network), Layer 4 (Transport), and Layer 7 (Application) 
Use “Signed-URLs” for content that needs to be authorized, see also: Using signed URLs – Amazon CloudFront 
Use secure CloudFront SSL versions 

Checklist of Amazon RDS

Work ChecklistCheck
Make sure the RDS Security Groups do not allow unrestricted access 
Ensure encryption of RDS instances and snapshots, using AES-256 level encryption 
Protects data when transmitting to RDS over SSL endpoints 
Monitoring RDS control with AWS Key Management Service (KMS) and Customer Managed Keys 
Configure AWS Secrets Manager to automatically rotate secrets (a set of information, usernames, and passwords, and connection details used to access a secured service) to Amazon RDS 
Ensure RDS database instances and snapshots are not publicly accessible 
Enable automatic minor upgrade for RDS 

Checklist of Amazon Redshift

Work ChecklistCheck
Enable require_ssl parameter in all Redshift clusters to minimize the risk of data encryption in transit for the Redshift and connect SQL Client to the enterprise cluster 
Enables Redshift Cluster encryption 
Enable the require_ssl parameter for the RedShift Cluster 
Make sure Redshift user activity logging is enabled 
Ensure Redshift encryption with KMS Customer Managed Keys 
We recommend that enterprises launch Redshift clusters in the VPC for better control 
Make sure that the Redshift clusters are not publicly accessible 

Checklist of AWS Systems Manager

Work ChecklistCheck
Use AWS Systems Manager Patch Manager to automate the process of patching systems and code, including OS, application and code dependencies 
Use the AWS Systems Manager Automation runbook or use Command to access the database or system indirectly 

Checklist of Monitoring and Alerts

Work ChecklistCheck
Enable AWS Config to monitor historical data of resources, and use the Config Managed Rules to automatically alert or immediately alert unwanted changes 
Alerts on the creation of both logs and events from AWS CloudTrail, to Amazon GuardDuty and application logs, help identify high-priority alerted events to investigate security incidents. 

Source

Security Checklist for systems on Amazon Web Services | VTI CLOUD

Read more: Blog Archives | Cloud Space Technology Solutions

Menu