If you’ve considered hosting your website on the cloud or a platform like Amazon Web Services (AWS), there are certain aspects one must be aware about.
AWS runs on a ‘shared responsibility’ model, meaning that you are still responsible to some degree for the safety of your website (such as securing your code and user data), while AWS is in charge of the security of the hardware and data centers.
Another important aspect of AWS is the lack of automatic security, which implies that users need to remain on the top of updated security measures and ideally maintain a checklist. Many big online stores or businesses consider to go for an Amazon Web Service Infrastructure Security Audit to avoid any panic situations.
Protect your AWS
When moving the infrastructure to the cloud, there are multiple sections of the data that must be kept concealed from the public eye, because of the risk of hackers. The physical data center only offers a modicum of protection, so here are two ways to ensure this protection – console access and programmatic access.
- Console Access
Securing the root account password is a foolproof way to protect your AWS account, therefore;
- Make it strong and complex – no personal details or ‘1234’
- Use efficient tools like password managers to remember your passwords for you so that you’re not discouraged from using complex ones and they aren’t compromised
- Use an administrative group to add all users individually to the group
- Make use of multi-factor authentication for added security barriers
- Don’t give out the password for any random reason and make sure that you don’t use it for regular administrative tasks
- Programmatic access
Here, the access key and secret key provided as part of your AWS account usually provides programmatic access to the AWS API. You can also use the Secure Token Service (STS).
- If it is mandatory for you to use keys, assign them separately to individual users without linking it to the root account
- Rotate keys on a regular basis
- Protect your PEM files used for SSH access with passwords into EC2 instances
- Don’t use a code repository for storing access or secret keys
- Use STS for programmatic access
- The role delegation feature present in IAM allows one to give access for particular resources
- Finally, if it is possible to do away with them, delete your access and secret keys for the account if they exist. This is because if an attacker manages to get a hold of these, they will be able to gain complete access to the AWS environment.
Use Encryption
The strength of your encryption determines how safe the entire cloud infrastructure is.
- The AWS Key Management
There are already options under the AWS system, especially since a good portion of the control is for their taking. Otherwise, you can also use features like ‘Vault’ or ‘StrongKey’. The point is, wherever possible, make encryption the main aspect you focus on, given the number of features already provided freely by AWS itself. You can use S3 buckets, RDS and Aurora databases, and EC2 EBS volumes.
- Remember to use HTTPS
This is particularly important if you’re using CloudFront, since you’ll need the certificates for setting up the HTTPS connection. After configuring the databases to accept secure connections, you can use the AWS Certificate Manager to create the required certification.
- Check infrastructure frequently
Given the high number of logging options, the most desirable ones that should be configured accordingly are S3 access logging, billing logs, VPC Flow logs, and CloudTrail logs. You can also refer to the Centralized Logging Implementation Guide for further instructions on monitoring the infrastructure.
AWS Identity and Access Management (IAM)
This service allows you to limit access to resources, utilizing the principle of least privilege and allowing you to establish the foundation of protected cloud infrastructure. Some other tips on handling IAM include;
- Give controlled access to resources for users and EC2 instances, focusing only on the minimum permissions required to do their respective jobs and nothing more. You can use AWS managed policies for providing these permissions – these are predefined and completely set by AWS. These can be used for commonly occurring situations, making it easier to implement barriers for access than creating something from scratch.
- Provide permissions through an IAM group or on a role level, instead of providing at the level of individual IAM users. Once you create the groups, you can provide permissions on the basis of administrators, developers, etc.
- Use individual IAM users as administrators, with only minimal access for their jobs. Also, make sure that the root user account is not used for basic functions and delete all unwanted root account access keys.
- Applications running on the same EC2 instance have the same privileges, so be careful to not mix any applications which require different levels of permissions on the same server.
Finally, there are some miscellaneous options that allow AWS to audit your resources for you (‘Trusted Advisor’) or customizable templates to audit these configurations yourself (‘AWS Config’).
A professional AWS Pentesting could be a great way too for regular security checks that will ensure that your current infra & any new updates that you pushing is free from vulnerabilities that can lead to hack.
