Compliance is boring, as developers we don't actively think about security loopholes in our infrastructure, just a few standard practices and that's it. However, AWS provides us with the tools that can help improve the observability of our infra and protect us from security issues down the line.
AWS S3 Security
Observe who is accessing the S3 buckets
You can enable server access logs for your s3 buckets and view detailed records of requests that are made to the bucket. The logs can be loaded in Athena to identify malicious access to buckets. Ideally you should have one server access logs bucket in each region with logs added based on bucket name prefix paths.
Observe S3 configuration changes
You should be able to log all configuration changes to your S3 buckets, this is useful to detect malicious modifications to your bucket configurations. This is easily possible with AWS CloudTrail. AWS CloudTrail will log all API access to your buckets in CloudWatch. You can add a metric filter with alarm on CloudWatch to send you a notification if any malicious S3 configuration change activity is detected.
Block public access to buckets if possible
If you are serving public data via cloudfront, you can block all public access to S3 buckets and add a bucket policy to only allow cloudfront to access your buckets. This is an additional security measure, although not necessary if you are serving non-sensitive data.
Enforce HTTPS access on buckets
It's a good practice to disable HTTP access to buckets, to do this you just need to add a policy (aws:SecureTransport) to your bucket that disables insecure access
Cloudfront
Enable WAF on CloudFront distributions
WAF protects your distribution from bots and common web exploits by blocking such requests. This feature is just one click away on your CloudFront dashboard. Be careful as it blocks genuine requests too, hence you can enable it in monitor mode to start off with and add custom rules later on.
CloudFront Standard Logs
This is similar to S3 server access logs, detailed information about requests to you distribution are logged in a separate S3 bucket.
IAM
Cloudwatch alarm for sign in / authorization failures
If you have enabled management events in CloudTrail. Authorization failures will also be logged in the associated CloudWatch group. All you need to do is add a metric filter with alarm that filters out console signin failures and authorization failures.
Rotate IAM user passwords
AWS recommends to regularly rotate the passwords of all IAM users. This is possible by adding a password policy from the AWS console.
At least one user with support role
AWS provides the ability to manage incidents with AWS Support through a managed policy called arn:aws:iam::aws:policy/AWSSupportAccess.This allows an IAM user to interact with the AWS Support Center where users can talk to AWS agents to resolve issues. It is recommended that at least one IAM user is assigned this role.
Enable IAM access analyzer
It is an AWS security feature that regularly scans your IAM policies for misconfigurations, over-privileges and possible security risks. It is recommended to enable it in all active regions.
VPC
VPC flow logs
Flow logs capture information about incoming / outgoing / restricted traffic without any impact on network performance. They are helpful in diagnosing overly restrictive security group rules. It is recommended to enabled flog logs on all subnets in your VPC
Observe VPC configuration changes
VPC configuration changes should be logged to CloudTrail and a log metric filter with associated alarm should be configured in CloudWatch so that all changes to VPC configurations are logged.
Lambda
Code Signing
This feature ensures only code from trusted sources runs in your lambda functions. For this you'll have to first create an AWS signer profile and AWS signing config using another service called is AWS signer.
CloudWatch Lambda Insights
Lambda functions runtime performance metrics (eg: CPU, memory, disk usage etc) can be monitored by enabling enhanced monitoring form the lambda function console. This will allow you to monitor unusual behaviour of your lambda functions.
EBS
Volumes and Snapshots should be encrypted
It is recommended that all EBS snapshots and volumes in use are encrypted using an AWS KMS customer managed key. For existing volumes, a snapshot can be taken, then they can be encrypted and restored. Also you have an option in the console to enable encryption by default when new volumes are created next time.
KMS
Customer managed keys must be rotated regularly
Rotation of AWS managed keys is handled by AWS, for Customer managed keys, they can be configured to rotate after after a fixed interval from the AWS console.
Monitory KMS configuration changes
Just like services mentioned previously, metric filters can be added to cloudtrail logs on CloudWatch that filter API calls like (ScheduleKeyDeletion , DisableKey ) and an alarm should be associated with them
EC2
Ensure IMDSv1 is not in use
The instance metadata service on EC2 instances provides an api to access meta information about EC2 instances, however this also an exploitation target for attackers. You need to ensure that the EC2 instances are using IMDSv2 and not IMDSv1, read more here
A lot of the above mentioned security features come with a cost, so you have to be cautious of the impact of such features on the AWS cloud bill.
Hopefully, you learned something new !!
Top comments (0)