How-to: Secure your AWS Setup - A Quick Checklist of Do’s & Don’ts🧾
--
Background
AWS comes with a ton of freedom and opportunities to build cool stuff.
But we all know, with great freedom comes great responsibility.
AWS offers a wide array of flexibility in terms of what security configuarations one can set up. From an organizational perspective, these settings, or lack thereof, are bound to have a huge impact on a company.
With the rise in data breaches occurring across the tech landscape, it is important that as each company embarks on their migration to the Cloud, they keep security as a top-most priority in their mind.
After all, AWS is almost like an apartment (development platform) that you as a company (tenant) will be renting. You will be placing your data (Customer information, SPI, NPI, Internal APIs, and Client-facing applications (your most valued assets) in the Cloud.
Would you want to leave your apartment front door with a weak, brittle lock, while your $1200 MacBook Pro, Designer Watch collection, and a bunch of other valuables are sitting in there? NO? Then keep reading. 🙂
1) General Best Practices
- ☑️ Involve information security throughout your development process rather than at certain points
- ☑️ The amount of discrete security groups should be minimized
- ☑️ Periodically rotate SSH keys
- ☑️ Use a standard naming/tagging convention for all resources
- ☑️ Implement a strict password policy
- ☑️ Purge unused SSH Public Keys
2) How to set up Accounts
- ☑️ Use Multifactor Authentication for the “root” account
- ☑️ Regular use of root user accounts should be limited and even avoided
- ☑️ Access keys must not be used with root accounts
- ☑️ Least privileged access must be granted as much as possible for application users
3) How IAM Settings should work
- ☑️ Always set Multifactor Authentication for IAM users
- ☑️ Allow IAM users for multi-mode access
- ☑️ Link IAM policies to Groups or Roles
- ☑️ Regularly rotate IAM access keys, and standardize the selected number of days
- ☑️ Grant access to resources using IAM roles
- ☑️ Keep the number of IAM groups low
- ☑️ Disable access for inactive IAM users
- ☑️ Remove inactive IAM access keys
4) How to use Logging Services
- ☑️ Enable CloudTrail logging across all Amazon Web Services your organization uses
- ☑️ Allow CloudTrail multi-region logging
- ☑️ Permit access logging for Elastic Load Balancer Service (ELB)
- ☑️ Allow Redshift audit logging
- ☑️ Set CloudTrail log file validation
- ☑️ Allow Virtual Private Cloud (VPC) flow logging
- ☑️ Permit access logging for CloudTrail S3 buckets
- ☑️ Combine CloudTrail logging with CloudWatch events
- ☑️ Encrypt the CloudTrail log files at rest
5) Applying Development Best Practices
- ☑️ Use Multifactor Authentication (MFA) to delete CloudTrail buckets
- ☑️ Expired SSL/TLS certificates must never be used
- ☑️ Always use HTTPS for CloudFront distributions
- ☑️ Your Elastic Block Store (EBS) database should be encrypted
- ☑️ Restrict access to well-known ports such as CIFS, FTP, ICMP, SMTP, SSH, Remote desktop Disallow unrestricted ingress access on different ports Also to resources like: AMIs (Amazon Machine Images), EC2 Security Groups, Redshift clusters, RDS Instances, and in general all outbound calls
- ☑️ Permit the require_ssl parameter in all your Redshift clusters
6) Data Security Best Practices
- ☑️ Always encrypt sensitive data like personally identifiable information (PII) or protected health information (PHI)
- ☑️ Properly encrypt Amazon’s Relational Database Service (RDS)
Want to learn more about 🛡️Secure Coding 🔒 & Engineering?
Check out my series linked below! 🙂
