Aspiring engineer gets bombarded with AWS charges while in a group study!

In the aspiring engineer community, there are many horror stories of "I suddenly got millions of won in charges on my AWS account that I was using to study." This kind of charge bombardment is usually caused by a malicious user taking over. In this post, we will show you how to protect your AWS account from malicious users.

Here is how to protect your AWS account from malicious users.

1. Cloud security starts with protecting the root account

When you first sign up for AWS, the root account is the first account you access. The saying goes, "With great power comes great responsibility." How much power does the root account have?

• You can create, modify, and delete any resource that exists in AWS. You can create hundreds of virtual machines and charge a price bomb, or delete a DB that was being used for a service.
• You can give or take away authorization to other users.
• You can unsubscribe.

That is a lot of power. Let's talk about how to use a little power and take a little responsibility.

a. Password management

a. Password management

Password management is the most basic security measure. Because they are more vulnerable to breaches than other authentication methods, you should manage them to ensure that they are as follows.

• Use long, randomly generated passwords to make them less predictable.
• Store your passwords on a secure medium so that no one can see them. Never write them down on a post-it note and stick them to your monitor.
• Ensure that only a few people know the password for the root account, and rotate it periodically to prevent reuse by note-taking or memorization.

b. Enable multi-factor authentication (MFA)

Multi-factor authentication is an authentication method that uses additional verification methods in addition to your username and password. When you enable MFA in AWS, you must enter an accurate one-time password (OTP) in addition to your existing username and password to use your account. An OTP is a one-time password that is regenerated every 30 seconds. Let's take a look at the advantages over using a password alone.

Common passwords are vulnerable to hackers because of the following factors

• Because many people use the same password across multiple sites, a hack into just one insecure service can have the effect of compromising multiple accounts.
• Many people do not change their passwords regularly, so once a password is compromised, it can be used for a long time. If your password is used at work, it could be used by someone who leaves the company if you do not change it.
• You may be a victim of a dictionary attack, where common words are substituted for your password.

Using OTPs together can make up for a lot of the weaknesses in passwords.

• Each service uses a separate OTP, so you cannot recycle one from another service.
• They are automatically replaced every 30 seconds, so even if a hacker manages to steal your OTP, it will soon be useless.
• They are randomly generated, making dictionary attacks pointless.

c. Access key not issued

The username and password are used to access the AWS web console, but when you want to use the CLI or SDK, the access key and secret key take over the role of username and password, respectively. Therefore, if these two keys are stolen, it has almost the same effect as if you gave up your username and password. Fortunately, the Access key is not generated unless you request it, so it is safe to not create it at all.

d. Enable login notifications

You can set up notifications to occur whenever someone logs in to the root account so that you can react quickly. To implement a notification, you can write a lambda that sends an email or message whenever a login is recorded in AWS Cloud Watch. The AWS official blog has a great article on how to do this, which I will link below.

Monitor and Notify on AWS Account Root User Activity

We recommend that you avoid using the root account whenever possible.

Once you have implemented the basic protections described above, you should strictly limit access to the root account. Most of the root account's privileges can be transferred to other users through IAM, which we will discuss later. Unless you absolutely need the root account, such as to change payment settings, do not use it at all.

2. Controlling access with IAM

IAM stands for Identity and Access Management, and it is a service that controls users or resources to use only the authorization that is appropriate for their identity. Employees in a company need different authorizations depending on their organization and position, or identity. For example, a DB administrator needs DB modification authorizations, but does not need operational authorizations on a Kubernetes cluster. A Kubernetes engineer, on the other hand, does not need any DB-related authorizations. With IAM, you can grant each user only the authorizations they need. In other words, even if a Kubernetes engineer's account is compromised, your DB will not be attacked.

An IAM policy is a predetermined list of what kinds of authorizations you want to grant. For example, let's say you have a policy that says, "You can view the status of your development Kubernetes cluster." Only development clusters have this authorization, not production. You only have this authorization on the development cluster, not the production cluster, and you can only view it, not modify or delete it. That is what a policy is.

IAM's identities can be broadly categorized into 'User' and 'Role', but let's leave roles for later and start with users. A user is an account that can log in to AWS. They log in with a username and password, or an Access key and Secret key, to perform operational tasks. The basis of IAM operation is to associate an identity with a policy, i.e., the identity "developer Hong Gil-dong's account" with the policy "Allow viewing of Kubernetes clusters for development".

a. Enable multifactor authentication (MFA) for IAM users

IAM user accounts can also have multifactor authentication enabled, just like the root account. It makes the login process a bit more cumbersome, but it is much more secure.

b. Manage access keys

I mentioned earlier that you should never issue access keys for the root account, and it is unreasonable to completely restrict IAM users from doing so. However, if you must issue access keys, it is a good idea to delete them as soon as you are done. As I mentioned earlier, the ripple effect of a valid access key and secret key pair being compromised is almost identical to having the entire account compromised. Using them for as little time as possible is a way to reduce the risk of compromise.

In particular, you should never post your Access and Secret keys in public places like Github. Many hackers still run crawlers that look for unintentionally published access keys. The moment you publish your keys on Github, your account becomes public property for hackers.

C. Grant the least amount of authorization

When faced with errors due to unauthorized authoriazations in production, it can be very tempting to set your IAM policy to a wildcard (*) and grant all authorizations. This is the equivalent of creating another root account, and should never be done. Even if it is frustrating, you should find and grant the minimum authoriazations needed to get the job done.

d. Use IAM roles whenever possible

IAM roles are an authentication method that issues access keys and secret keys to users or resources with the right authorizations that are only valid for a certain amount of time. Like OTPs, they are more secure because they expire after a certain amount of time, even if they are compromised.

IAM roles can also be granted to users, but this is limited because they must use the access key as part of the authentication process to eventually be granted the role. IAM roles really come into their own when they are assigned to resources. For example, suppose you need to download a file from s3 to deploy a service to an ec2 virtual machine. By granting ec2 the download authorization from s3, you can download the file without having to enter or save an access key. This is great for automation through scripts because it eliminates the process of entering keys.

Avoid cloud cost bombardment by establishing security policies

Cloud security incidents can be financially devastating. While you may be able to get a refund if the breach was clearly caused by a malicious user, the process can be complicated and there is no guarantee you will get 100% relief. It is best to protect your account by establishing a security policy in advance.