Since my time here, I have done numerous security audits for companies and have run into some of the same issues on each audit, so I felt it would be beneficial for the community to write a blog post detailing some basic AWS security principles.
A few basic AWS security principles are:
- Secure it when possible
- Evaluate risk vs. complexity
- Encrypt whenever possible
- Treat IAM as you would treat Active Directory permissions
Basic AWS Security Principles: Secure it When Possible
Almost every service within AWS has been built with security in mind. Let’s take S3 for a quick example: S3 allows you to write Bucket Policies to allow certain users from certain roles/groups to access a specific bucket. You can also force encryption in transit and at rest via bucket policies. Understanding bucket policies for S3 helps with ensuring your data is as secure as possible while stored in S3 and is a basic AWS security principle.
Another example is RDS: RDS has quite a few options for securing the data; specifically, enforcing the data to be encrypted at rest and not exposing the RDS instance to the internet. Exposing a database to the internet is a huge risk, and one that should be avoided at all costs. This gives attackers an attack vector directly into your customer data, whereas leaving it locked down and only accessible via the intranet forces attackers to make it through one layer of security, and then the next. Securing RDS could be be an entire blog post, so we won’t dig too much into that here.
Basic AWS Security Principles: Evaluate Risk vs. Complexity
It’s no secret that often times implementing security measures will increase complexity to the environment or for developers. Understanding the security features and the complexity they add to your environment will help ensure your relationship with your operational staff and developers doesn’t dwindle. Before you implement a new security feature, ask yourself the following questions to ensure it’s best for your environment:
- What impact will this have on my operational staff?
- What impact will this have on my developers?
- What risk does this mitigate and is there a hypothetical risk that will likely never occur?
- Can we implement log auditing to notify us if this ever occurs instead of complicating the environment?
Implementing new security measures just because they exist doesn’t mean it’s the best thing to do. Remember that your staff and colleagues still have to be able to work in a timely fashion.
Basic AWS Security Principle: Encrypt Whenever Possible, but Needed
Many AWS services allow you to encrypt the data at rest. Some even allow you to encrypt the data in transit. Encrypting all of your data isn’t a bad move; however, you could incur costs that you don’t necessarily need to incur. AWS Key Management Service (KMS) is a really cheap service, but if you have a larger application with millions of hits, it can definitely add to your bill. Encrypt the data whenever possible, but needed, and by needed, I mean encrypting anything with user information, customer information, proprietary software, architecture designs, etc. Some things you might not need to encrypt are a page that’s displaying stock ticker symbols, or road conditions to your office. So if it’s possible and needed, encrypt it.
Basic AWS Security Principle: Treat IAM as You Would Treat Active Directory Permissions
Not every user needs administrative rights on your AWS account. Actually, only a few people should have such permissions. With full administrator privileges, users (authorized or unauthorized) can modify logs and cover their tracks of malicious activity. These users can create additional users within IAM to spoof their activity. They can even change another user’s password and use their account for malicious activity.
Within Active Directory, not all users should have Domain Admin. Very few users should retain the Domain Admin privilege and the others should have well thought-out permissions for the environment. If your job doesn’t require you to be modifying the firewall ports on your servers, these jobs shouldn’t have access to modify the Windows Firewall. The same goes for IAM in AWS: if your user doesn’t need to open up ports in a Security Group, don’t give them permissions to do so. Understanding what your users are required to do within AWS and building IAM policies for their roles is vital. Associate the policy to a group, and associate the users to the group. This is crucial to maintain the security and integrity of your data.
Next Steps:
Contact us to learn more about how we can help your organization with the basic principles of AWS security. You can also read more of our latest security blog posts for tips and tricks from our subject matter experts.
