How can you tell if your AWS deployment is secure? Do you know HOW secure it is? Sure, you can use AWS Trusted Advisor to find out, or you may check out the comprehensive checklist that we have prepared for you below. See if you comply with these 100 AWS Security Best Practices.
Going through the list will help you evaluate the security of your AWS deployment. If you’re not following most of the below rules at the moment, it doesn’t necessarily mean that your deployment is insecure, however, you should think about making some improvements. So, grab your coffee, settle down, and enjoy our list!
- Protect your root account.
Create a strong password and keep it safe. Change your password regularly.
- Enable Multi-Factor Authentication (MFA) for the root account.
Make sure you configure Multi-Factor Authentication for your root user. This will add another layer of protection to your account.
- Ensure that privileged users are secure.
Use MFA for privileged user accounts.
- Apply the IAM password policy.
Enforce a password policy to ensure that users create strong passwords and rotate them regularly.
- Delete root access keys.
Root access keys provide full and unrestricted access to your AWS resources. You don’t want to use them, so it’s safer to get rid of them altogether.
- Rotate access keys.
Compromised keys can be used without your knowledge. You want to rotate access keys at least every 90 days.
- Check if you don’t keep your access keys in a code repository.
If you do, delete them and create new ones.
- Take control over your encryption keys.
To do that, use AWS Key Management Service (KMS).
- Create individual IAM users.
Create individual accounts for anyone who uses your resources. This will allow you to keep track of changes.
Create an individual account for yourself, as it is not secure to use the root account on a daily basis.
- Restrict administrative access to your account.
Only administrators should have full administrative rights to your account.
- Introduce groups of users.
Organize users with specific permissions into groups.
- Avoid granting permissions per user.
Grant permissions per group rather than per individual user. It makes permissions easier to manage.
- Grant permissions in an easy and secure manner.
Use AWS-defined policies whenever possible.
- Use IAM roles.
Enable roles for your AWS resources, and allow access only to the required resources.
- Ensure you have no expired or inactive accounts in IAM.
Generate and download a credential report to find and remove unused accounts.
- Double-check that you securely share your resources with other AWS accounts.
Use roles instead of sharing credentials.
- Follow the principle of least privilege.
Start with a minimum set of permissions and grant additional ones only when necessary.
- Provide extra security to IAM.
Configure policy conditions under which your IAM policies allow access to resources.
- Use Identity Federations.
Create an Identity Broker between your corporate users and AWS resources to manage authentication and authorization without having to recreate all users as AWS users.
- Ensure you have full visibility and traceability of your account activities.
Activate CloudTrail to record API calls made on your account.
- Make sure you can access the detailed historical configuration of your AWS resources.
To view all configuration records, use AWS Config.
- Check if you are protected from unauthorized access to logs.
Configure AWS IAM roles and Amazon S3 bucket policies to enforce read-only access to your logs.
- Add more security to your log files.
Protect S3 bucket where you store logs with MFA.
- Verify that you store logs for an organization-defined period of time.
Use AWS CloudTrail to configure the desired expiration period. Automate migration of old logs to Amazon Glacier.
- Protect your EC2 Key Pairs.
Download them and keep them in a safe place. You will not be able to access your EC2 instance without the Key Pair.
- Move your Key Pairs security to the higher level.
Generate Key Pairs on your own, and only import the public key of the Key Pairs to AWS.
- Check if you meet the corporate, contractual, and regulatory compliance requirements for data security by using dedicated HSM appliances.
Deploy CloudHSM EC2 instances to ensure secure key storage and cryptographic operations.
- Track requests for access to your S3 Bucket.
Enable S3 access logging and analyze the records regularly. This may become useful during security and access audits.
- Do not leave any S3 buckets with the open access permission.
Control access to the buckets with Bucket Policies or IAM roles.
- Limit the number of users who can access your data.
Use AWS permissions to manage access.
- Make sure you are able to retrieve and restore any version of any object stored in your S3 buckets.
Enable versioning for S3 buckets.
- Protect yourself against accidental or malicious deletion.
Use the MFA Delete feature.
- Provide maximum redundancy.
Keep you deployment in at least 2 Availability Zones to be covered by the SLA. To guarantee maximum protection, use more than 2 AZs and replicate data to different regions, if possible.
- Check if your Elastic Load Balancer uses secure protocols.
Enable an SSL or HTTPS listener. Ensure it doesn’t use a cipher or protocol that is termed as not recommended.
- Check if ELB security groups allow access only to the port configured on the load balancer.
Restrict access only to ports and protocols defined in the configuration of your load balancer listener.
- Verify that your environment supports network diagnostics.
Allow the ICMP protocol in your security groups and network access control lists to support network control such as path MTU discovery, or diagnostic tools like ping.
- Offload as much security responsibility as possible to AWS.
Use AWS managed services like Amazon RDS, Elastic Beanstalk or Elastic Map Reduce. They are patched and updated by Amazon, so you don’t have to worry about system updates.
- Define your “Golden Environment”.
Create an AWS CloudFormation script to capture your secure environment configuration, and use it repeatedly in your new projects to provide reliability.
- Audit your deployment in real-time.
Use services like AWS Config Rules, AWS Trusted Advisor or AWS Inspector to continuously monitor your deployment for compliance or vulnerabilities.
- Always have a backup for your S3 data.
Use the application layer technology to back up data from S3 to another AWS region or to on-premises backup systems.
- Use Server-side encryption to protect your data at rest.
Encrypt sensitive data stored in S3 buckets, EBS volumes, and RDS instances.
- Use extra protection for you critical data.
Leverage a Client-side encryption for data stored in AWS S3.
- Take care of your EBS volumes replication.
Replicate data at the application level and create backups.
- Check if you create EBS automated snapshots.
Schedule automated EBS Snapshots using CloudWatch Events.
- Allow authorized users only to access your snapshots.
Assign access permissions only to authorized users, roles, or groups.
- Protect Data at Rest on Amazon RDS.
Use the application layer or the platform layer protection with SQL cryptographic functions.
- Protect Data at Rest on Amazon Glacier.
Use Server-side or Client-side encryption.
- Protect Data at Rest on Amazon EMR.
Use Server-side, Client-side, or Application-level encryption.
- Protect Data in Transit.
Use IPSec/SSL/TLS where possible to encrypt data transited to or from your AWS deployment.
- Perform secure AWS Import/Export.
Use a PIN-code device or the TrueCrypt software to encrypt your data before shipping it to AWS.
- Protect your public cloud services.
Use SSH version 2 or SSL/TLS protected RDP. Issue a trusted X.509 certificate for Windows instances to avoid identity spoofing.
- Protect your AMIs.
Unless there’s a reason for your AMIs to be public, set them to private.
- Protect your RDS snapshots.
When you share RDS snapshots with others, make sure you don’t make them public.
- Harden your EC2 instances.
Protect your instances in the same way as you secure your on-premises systems.
- Manage malware risk.
Never use untrusted AMIs, software, or software depots.
- Ensure your EC2 instances are up to date.
Keep your systems patched and updated. Always use the latest AMIs.
- Make sure you do not send spam from your EC2 instances.
Disable any mail servers that can act as open relay.
- Protect your EC2 instances from spam, viruses, rootkits, etc.
Always use Antivirus/Antispam/Host-based IDS software.
- Never ignore abuse communication.
Always respond to abuse warnings, take action to stop the malicious activities, and prevent future re-occurrence.
- Check if you implemented only one primary function per EC2 instance.
Avoid applying different security levels on the same instance. Implement web servers, DB servers, DNS servers, etc., on separate instances.
- Disable all inessential services.
Enable only protocols, services, daemons, etc., that are indispensable for system operation.
- Customize AMIs that you run.
Always change vendor-supplied defaults.
- Check if connections to third-party AMIs you use are secure.
Generate your own Key Pairs, import them to your machine, and disable the password-based login.
- Double-check that no one can use your publicly shared AMI to log in to your systems.
Delete SSH-authorized keys. Remove any locally-stored credentials.
- Make sure you won’t expose historical data before you share AMI.
Delete shell history before creating your AMI.
- Ensure that no one will get your certificate with the private key from a shared AMI.
Remove your private key and certificate from the EBS volume before taking a snapshot.
- Use Public AMIs in a more secure manner.
Remove any pre-installed credentials, default usernames and passwords.
- Configure all services with security best practices in mind.
Always choose secure protocols/services over non-secure ones. For instance, always choose SSH over telnet.
- Define isolated network for each workload or organizational entity.
Create VPC with public and private subnets within.
- Transfer data between VPCs in a secure manner.
Configure VPC peering instead of transferring data through a public network.
- Provide an additional level of protection to your EC2 instances.
Always run your EC2 instances in a dedicated VPC.
- Decide if VPCs should be able to communicate with the Internet.
Create and attach Internet Gateways to the VPCs that should access the Internet.
- Check if your VPCs have subnets in different AZs.
To provide HA within VPC, always span them across multiple subnets in multiple AZs within a Region.
- Protect internal VPC subnets.
Decide whether a subnet should be reachable from the Internet by default. Is so, enable auto-assign of public IPv4 addresses for that subnet, if not, disable that feature.
- Make it impossible for your private subnets to directly access the Internet.
Use NAT instances or NAT gateways to access the Internet for patches or updates.
- Check if you can securely access resources in private subnets.
Use Bastion Hosts in the public subnet, which are allowed to connect to resources in private subnets.
- Ensure that you use RDP in a secure manner.
Do not expose all Windows instances to the world. Use one of them as EC2 management instance.
- Manage your route tables.
Create route tables only when needed and associate them with specific subnets.
- Check how many public subnets you have.
A good practice is to have only one public subnet with a route table providing the route to the Internet Gateway.
- Provide secure connectivity between AWS and your on-premises deployment.
Use IPSEC over Internet or Direct Connect links. AWS Direct Connect can be protected with IPSEC.
- Manage access to instances that have similar functions and/or security requirements.
For that purpose, use Security Groups.
- Check if your Security Groups allow unrestricted traffic to specific ports.
Make these rules as specific as possible. Avoid “0.0.0.0/0” and “All” keywords where possible.
- Define and follow standardized Security Group Naming conventions.
Use standardized names to improve operations and management, and to avoid transcription errors.
- Verify if you use any default Security Group.
Avoid using default Security Groups. Create dedicated ones and use them when creating resources like EC2 instances.
- Isolate subnets within VPC from one another.
Use Network Access Control Lists to allow or deny traffic before it reaches a security group.
- Check your Access Control Lists for inbound and outbound rules.
ACLs are stateless, so you need to allow traffic in both directions. Make sure that you authorize returning traffic for all inbound rules.
- Manage access in upper layers.
Provide access control in the application and/or services layer.
- Use additional, third-party, network protection.
Create a threat protection layer to leverage third-party security appliances like IPS/IDS, and force all traffic to pass through them.
- Never allow your applications to perform port scanning.
Port scanning is a violation of AWS Acceptable Use Policy.
- Obtain permission for vulnerability scans.
Whenever you need to perform a vulnerability scan to meet your compliance requirements, you need permission, and the scan can apply to your own instances only.
- Control how Amazon CloudFront or Application Load Balancer respond to web requests.
Detect and filter malicious web requests with AWS WAF.
- Check your WAF conditions.
A web request must match all conditions in the rule to be allowed or blocked. Specify a default action for requests not matching any rules.
- Protect your API from attacks.
Use API Gateway as a front end to your API applications, hiding them from the outside.
- Check if your Web Applications can sustain a DDoS attack.
Use AWS Shield integrated with AWS WAF. AWS Shield Advanced includes AWS WAF.
- Check if you require advanced DDoS protection.
To provide protection for your ELBs, CloudFront Distributions, and Route53 hosted zones, leverage AWS Shield Advanced.
- Check if you are protected against spikes in your AWS bills that could result from a DDoS attack.
Using AWS Shield Advanced can provide you with such protection.
- Make sure that your deployment can handle huge traffic load when needed.
Configure Auto-Scaling Groups for your EC2 instances and tune up thresholds to enable your environment to scale up when necessary.
- Verify the security of your RDS data base access.
Avoid connecting to the data base with the master user credentials. Create a dedicated account with limited access or use AWS IAM.
- Provide additional network control to your data base.
Run data bases within VPC in private subnets.
- Secure DB instances within VPC.
Use DB security groups.