AWS offers many tools to help secure your account. However, because many of these measures aren't active by default, you must take direct actions to enable the guardrails. In this guide we will highlight some of the best practices to consider when securing your account and its resources.

No security discussion is complete without mentioning the Shared Responsibility Model. Cloud providers are only responsible for some parts and customers are responsible for others. This is very important to understand for everyone who is using the AWS account directly or indirectly.

Every technical organization broadly has following roles and entities. In some cases there are different people/team assigned for each role or may be same user/team is overseeing multiple roles:

• Administrator
• Billing
• Application Developers
• Network administrators
• Database administrators
• System administrators
• Support users

AWS Identity and Access Management (IAM) is the key service to specify who or what can access services and resources in AWS. Through IAM one can centrally manage fine-grained permissions, and analyze access to refine permissions across AWS account.

Let's look at some of the important steps one can take to protect the AWS account.

Multi-Factor Authentication on Root Account

MFA or 2FA has become standard for securing your digital accounts. You will see that the 2FA enforcement has become general practice among major social or utility applications like Google, Facebook, Instagram, etc. These services are easy targets for malicious entities to hijack user accounts and misuse them for financial gains. Same is the case with AWS, bad actors are always on lookout for vulnerable accounts for misuse.

Multi-Factor Authentication (MFA) is an AWS IAM feature that adds an extra layer of protection on top of your username and password. With MFA enabled, when a user signs in to an AWS Management Console, it prompts them to enter their username and password (the first factor—what they know), as well as to enter an authentication code from their AWS MFA device (the second factor—what they have).

https://aws.amazon.com/what-is/mfa/

Root User vs Non-Root User

When you first create an AWS account, you begin with a default set of credentials with complete access to all AWS resources in your account. This user is called the AWS root user. With all the power comes great responsibility, it's strongly recommended that you don't access the AWS account root user unless you have a task that requires root user credentials. For all other activities, please create role-specific user identities.

Instead of accessing the root user, create an administrative user for everyday tasks. IAM Users are a preferred way to create role specific identities. When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as least-privilege permissions.

Let's take couple of example policies:

This example shows how you might create an identity-based policy that allows full EC2 access within a specific Region.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "ec2:*",
            "Resource": "*",
            "Effect": "Allow",
            "Condition": {
                "StringEquals": {
                    "ec2:Region": "us-east-1"
                }
            }
        }
    ]
}

This example shows how you might create an identity-based policy that allows an administrator to enable and disable the Asia Pacific (Mumbai) Region (ap-south-1).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnableDisableMumbai",
            "Effect": "Allow",
            "Action": [
                "account:EnableRegion",
                "account:DisableRegion"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {"account:TargetRegion": "ap-south-1"}
            }
        },
        {
            "Sid": "ViewConsole",
            "Effect": "Allow",
            "Action": [
                "account:ListRegions"
            ],
            "Resource": "*"
        }
    ]
}

Please do keep in mind if the target identity requires AWS Console access or AWS Programmatic Access. Password is required for Console Access and Access Keys are required for Programmatic access. We recommend that you decide while creating the identity if you want that user to access the Management Console or not.

AWS Single Account vs AWS Organization

We have seen many new account users just keep one AWS account and run all of their workloads in that single account. For simple use cases and small team, having just one account makes sense, but if you have large/multiple teams working on multiple applications, managing them under a single account can become security and governance nightmare.

• For a single, standalone AWS account, create Administrator users for resource management
• For multiple teams or projects, create multiple AWS accounts managed through AWS Organizations.

The additional advantage of using AWS Organization is to further restrict the service-level access in the account through Service Control Policies (SCP). SCPs offer central control over the maximum available permissions for all accounts in your organization. An SCP defines a guardrail, or sets limits, on the actions that the account's administrator can delegate to the IAM users and roles in those accounts.

For example, if one of the accounts under Organization is subject to run a Serverless application, then the SCP can be defined to Deny Access to create EC2 instances. Another example would be to allow specific accounts to only use certain AWS regions.

AWS Identity Center Single Sign-On (SSO)

IAM Users are considered to be long-term users. Either with password or with Access Keys they can continue access AWS resources. This is manageable for single account, but with practice of account-level isolation in multi-team, multi-project or evan multi-environment, there is an additional overhead of Policy replication across accounts and extra steps for Cross-account access.

AWS released an improved approach to centralize the Identities and Access management across multiple accounts with AWS IAM Identity Center. With IAM Identity Center, you can create or connect users and centrally manage their access across all their AWS accounts and applications. You can use multi-account permissions to assign your users access to AWS accounts. You can use application assignments to assign your users access to AWS managed and customer managed applications.

You can create and manage user identities in IAM Identity Center’s identity store, or easily connect to your existing identity source, including Microsoft Active Directory, Okta, Ping Identity, JumpCloud, and Microsoft Entra ID (formerly Azure AD).

IAM Identity Center allows you to select user attributes, such as cost center, title, or locale, from your identity source, and then use them for attribute-based access control (ABAC) in AWS.

Configure Billing Alerts

Everything happens in your AWS account has some sort of financial cost attached to that. As an organization, you should always be in-sync with your Cloud spending.

With AWS Budgets, you can configure budgets to track your costs and usage, and respond quickly to alerts received from email or SNS notifications if you exceed your threshold.

AWS Budgets gives you access to a number of filtering dimensions (i.e., AWS Service, Availability Zone, and Member Account), and allows you to create budgets that are tracked on a monthly, quarterly, or yearly basis. This is the simplest way to keep track of your spending without tracking each resources.

Training and Upskilling

With cloud adoption growing and creating jobs at a staggering rate, there’s no realistic way to create net new cloud professionals at the rate they’re needed. But that doesn’t mean that businesses can’t get access to the skills required to make the most of cloud tech, or help other organizations achieve their digital goals.

Addressing the tech skills gap by training existing employees is a solution that’s available to every business. It makes sense: in any situation where resources are in limited supply, you work with what you already have. And with a wide range of roles and high-quality training available to tech professionals, you might be surprised how effective reskilling and upskilling employees into cloud tech roles can be.