Introduction

From data storage, file sharing, remote access, to remote backup – cloud computing is a key factor in modern IT. More and more companies are moving from Dedicated server to Cloud server, and Amazon Web Services (AWS) remains a top choice for this solution.

However, improper security brings many risks for businesses. Many small and medium companies have “bitter fruit” when the Cloud system was attacked and received huge numbers in bills. During the pentest cloud process, many times, my colleagues and I found the access key indiscriminately on Github or S3 can be accessed and used publicly. That is the reason why I write this sharing. I will try to summarize the shortest, least flowers and branches so that we can together grasp the content.

Audit AWS – Higher Standard

1. Root account

• Register for an AWS root account using Company email
• Don’t use the root account for normal operation.
• Do not generate access keys for root account
• Only for people with experience working with AWS to manage their admin accounts (For many large companies, AWS Certified Security – Specialty is a required certification for admin account owners)

2. Developer account

• Define Developer Roles in Project (Administrator, Developer, Deployer, Read-only Supervisor ..)
• Create an IAM group with minimum privilege for each Developer Role.
• For each Developer, create an IAM user for that Developer in the IAM group
• Delete users, keys, and credentials when they’re done
• Give the IAM group only the bare minimum of privileges they can get to work with.
• It is recommended that with the exception of the Administrator Role, other roles are not allowed to access the IAM service.
• It is a good idea to create a group and assign users to that group, rather than setting permissions for each user.

3. No sharing

• Never share any keys or passwords with others.
• If someone (eg a customer) needs to have access to some particular service, create an IAM user for that person.
• If an application or IAM user is from another AWS or a user from your Active Directory needs access to some particular service, create an IAM role for that case.

4. Use MFA

• Enable MFA for all Console accounts

5. Restrict access using policy

• By default denies all access except a specific group of Resources and AWS Products
• Only allow access from specified IP range (corporate IP range or customer IP range)
• Allow access only from users using MFA (All non-MFA users for their account are denied by default)
• Only allow access to tagged resources (Resources must be specifically tagged, avoid confusion and be efficient in antiquity investigation)
• Only allow access for a limited time
• Only allows users to launch a specific instance type

6. IAM Password policty

Set password policy for all IAM users in your account

• At least 8 characters
• At least 1 uppercase letter, lower case letter, number and symbol
• Password expiration time is up to 30 days
• Do not use repeated passwords (at least 3 times in the past)

7. Track user action

• Turn on the AWS Config to record resource configurations
• Enable CloudTrail on all regions to track user actions

8. Create a billing alarm

• Use CloudWatch to set up billing alerts when your usage exceeds a specific threshold

(Using CloudWatch will probably cost a little bit of your money. But it will be very small with the amount of money you will lose if Hackers control your Cloud.)

9. Secure Logging and Monitoring Service

• Do not allow non-admin users to modify Monitoring Services (CloudWatch, CloudTrail, Config) – In the event of an intrusion, Hackers will try to disable these services to avoid traceability and export. shows security warning.
• Do not allow non-administrator users to modify the storage & output location (S3 buckets) for monitoring services.

10. Sandard AMI

• When launching a new Instance Machine, the default standard AMI provided by AWS must be used.
• Any other Image must be checked and approved by a security specialist (IT / TQA) prior to deployment in the Production environment.

(3rd party images are vulnerable to security flaws and it takes longer to fix security issues than standard AMIs)

12. Limit network access

• Restrict access to Instance by using Security Group and Network ACL to allow traffic only for certain ports and IP ranges

In specific cases, Security Group can be configured:

• Allows RDP (port 3389) to be sent from client’s IP range
• Allow SSH (port 22) to send in from client’s IP range
• Refuse all other inbound traffics (all other inbound traffics)

(Using 0.0.0.0/0 for “sensitive” services is always a headache in projects. There have been many times I’ve seen client rage related to this. Trust me. You won’t want to go through this ^^.!)

13.Use HTTPS and SSL / TLS

It is recommended to use HTTPS and TLS / SSL when connecting to cloud services (EC2, RDS, S3, DynamoDB …) over the Internet

It is an alternative to the method of transmitting plain text text information. Protect your information, do not steal or modify it. Most people are familiar with SSL / TLS certificates, which are being used by major websites and webmasters who are serious about protecting user transactions.

14.Encrypt RDS

• For important RDS database instance, you should enable RDS server side encryption (RDS server side encryption).

15.Backup RDS

• Use RDS snapshot or automated backup to back up important RDS databases

Talk

During the time I was still doing troubleshooting. Many times had to get up in the middle of the night to go and overcome the consequences caused by the project team. Once Hacker has obtained the highest authority and used 200 customer Instances for mining Coin. The amount of money AWS reported then was enough for the person who caused the consequences to have to sell the house to compensate. Looking at his pale face then, perhaps if he went back in time – he wouldn’t have dared to underestimate Security so much.