The Amazon Web Services (AWS) in terms of security follow a shared responsibility model. So, the security ‘of’ the cloud is on the shoulders of AWS, whereas you and your organization’s development team have to look after the security “in” the cloud. Hence, the protection of the infrastructure of the cloud, including hardware, software, and networking falls under the territory of AWS. All the other security objectives, including access to your AWS resources and the security of your application, is your responsibility. The following is an overview of four of the most common AWS security features you’ll need to keep your cloud secure.
1. S3 Security
S3 stands for Amazon’s Simple Storage Service, which is responsible for providing data storage with a high level of availability & durability. Just like all AWS services, the S3 by default denies access from most sources. Only the bucket and object owners (the AWS account owner) have read/write access by default. Hence, it becomes important to lock your S3 buckets so that no unauthorized users are able to view, upload, or delete your files. Contrary to other services, there are several ways of adding permissions to S3, like:
- Firstly, by giving IAM roles to your hand-picked users within your AWS account. They can be used to specify what the users are allowed to do, and how many of them have access to it?
- Usage of Bucket Policies to lock down a single bucket. There is an option of adding permissions to either the individual users or the entire AWS accounts. Bucket policies can be helpful if some files in your application are public and some are private.
- Use of Access Control Lists (ACL) to gain access for AWS accounts & not the individual users. These become very helpful when your company is in possession of & uses several AWS accounts or if any other organization needs access to your files.
2. Identity Access Management (IAM)
The IAM is a free-of-cost element of the AWS that allows you to control & manage- ‘what users have access to what services and resources. By default, access to resources is generally denied, so you will have to grant users permissions in IAM. Permissions are incredibly comminuted and allow you to specify the particular file or resources that a user can access, what the things are that they can do with the file and the work conditions that have to be present for the permissions to get activated – like, using a specific IP address to access AWS. Here are some best practices you should consider with IAM:
- Granting few privileges- Granting the users only the permissions they need to perform the tasks, and nothing more. This is very beneficial, as you can always grant more permissions, but you cannot obtain the databases that were deleted or removed because you made everyone an admin.
- Creation of groups- A group can be defined as a lump or collection of users that allows you to specify the various permissions for the concerned users. Because of this, tracking who has what permissions becomes very easy, plus you can add permissions to several users at once. For example, a group called Mismo AWS could be given full control over the AWS, while the other group, i.e., AWS Developers, in this case, may only be given access to Lambda and S3.
- Enable multi-factor authentication, or MFA, for all users. MFA means that, for a user to sign in, they will have to enter the passcode followed by an additional code that is sent to them through a secondary device, like a smartphone. This is very useful as, even if a user’s password is compromised, their account will not be accessible.
Your applications are not directly affected by CloudTrail, but it is essentially a tool used for tracking the activity of the users, compliance demonstration, and executing the security analysis. The review activity can also be searched through the logs created by CloudTrail. Overall, it is present by default, so you can view the logs as long as you have an AWS account. CloudTrail is very useful in determining whether your security configuration is sufficient or not? You can view the following from CloudTrail logs:
- The various updates to AWS services.
- The IP address source of the API calls.
- Which account created, deleted, or even modified the different AWS resources.
You can monitor and protect your organization’s digital assets with the built-in features of AWS. You have the power to determine which security features to employ and who has access to them. Your data gets stored securely on the cloud, & your organization’s unique security requirements are still your control.
4. Security Groups
Elastic Cloud Compute also called EC2, instances are the actual servers on which the applications are run. Each server operates from a Virtual Private Cloud (VPC), a virtual network that you have control over. These VPCs have. There are many security groups in VPCs, which may or may not allow the entry of traffic.
In these security groups, you get to choose the traffic that can enter both in and out of your VPC. Security groups, however, are stateful, so if you allowed ‘in’ a request, its response is allowed ‘out’. By default, traffic is denied, so everything gets rejected if it is not specifically allowed ‘in’. It is quite common for all the traffic to be allowed for Outbound traffic (because you are the one who is sending it), but it is important to cut down on the type of inbound traffic that you allow. You can also specify the types of requests (like HTTP, SSH, etc.), the port range, & the source of traffic through these security groups.