All about Cloud, mostly about Amazon Web Services (AWS)

Secure AWS Access using Bastion Accounts

 2018-05-13 /  912 words /  5 minutes

While the concept of a bastion host is generally well known, the concept of a bastion account is only mentioned in a few places. The idea of bastion accounts occurred to me while studying for the AWS Certified Security Specialist exam, but then I found a few others had also used the term. This post describes my initial thought and perhaps expands on the definitions of a bastion account as others have used it.

Bastion Hosts

For those who are unfamiliar with the concept of a bastion host, Wikipedia defines it as:

a special purpose computer on a network specifically designed and configured to withstand attacks. The computer generally hosts a single application, for example a proxy server, and all other services are removed or limited to reduce the threat to the computer. It is hardened in this manner primarily due to its location and purpose, which is either on the outside of a firewall or in a demilitarized zone (DMZ) and usually involves access from untrusted networks or computers.

This definition specifically calls out that bastion hosts are unique to network level security. The idea of bastion accounts does not in any way invalidate the notion of bastion hosts.

In the AWS environment, however, network security is just one part of the picture. Services like AWS Shield and Amazon CloudFront, Amazon Virtual Private Cloud (VPC) NAT gateways and network access control lists (NACLs) and Amazon Elastic Compute Cloud (EC2) security groups protect the network. In the AWS environment, we need to protect the management layer too. The management layer includes the AWS Management Console, the AWS Command Line Interface (CLI) and the AWS API. To protect the AWS management layer, services such as the AWS Identity and Access Management (IAM) use trust and access policies, roles and users, and multi-faction authentication.

Bastion Accounts

Bastion accounts do for the management layer what bastion hosts do for the network layer. Where a bastion host “is a special purpose computer on a network specifically designed and configured to withstand attacks,” a bastion account is a special purpose account on AWS specifically designed and configured to withstand attacks.

So, what types of attacks are we considering? Let’s take a look at a few ways to exploit AWS IAM. An easy and frequent method of exploitation is using bad password policies such as weak passwords, no password expiration, or too long of a password expiration interval. Another method of exploitation is using access keys and secret access keys to enable CLI or API access to AWS. Accidents or maliciousness lead to keys on github or other internet sites.

Federated Identity Limitations

Most large enterprises setup federated identity with AWS IAM. Some provide its users with AWS Security Token Service (STS) tokens that allows AWS Console, AWS CLI and AWS API access for as little as one hour. This method solves both those potential issues, so why do we need bastion accounts?

Account Login to the Master Account

Unforeseen circumstances! Network problems can arise with the federation systems. Administrators may lock themselves out or misconfigure the AWS IAM. These sample situations fall into a category of problems known as “break glass” or emergency scenarios.

These situations require an AWS IAM user with access to the account for reconfiguration and usually that user will require PowerUser levels of access, but we still need to solve the risks associated with AWS IAM users with long-standing access.

The bastion account is the account which has these AWS IAM users with long-standing access. Using the bastion account allows the users to have a password for AWS Console access (always with MFA!) and access keys and secret access keys for CLI and API access.

The bastion account is secure because:

First, it contains nothing. No default VPCs or Subnets, no S3 buckets and no EC2 instances. The only thing configured is CloudTrail which pushes logs to an audit account. Second, the policy assigned to the user only allows that user to AssumeRole to other accounts and get temporary security tokens.

Configuring Bastion Accounts

An example access policy for the bastion account user is:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
{
    "Version": "2012-10-17",
    "Statement":
    [
        {
            "Sid": "AssumeRole",
            "Effect": "Allow",
            "Action":
            [
                "sts:AssumeRole"
            ],
            "Resource": "*"
        },
        {
            "Sid": "GetSessionToken",
            "Effect": "Allow",
            "Action":
            [
                "sts:GetSessionToken"
            ],
            "Resource": "*"
        }
    ]
}

This is a classic defense-in-depth approach because only multiple failures lead to a vulnerability. Creation of resources is the first failure. Opening the access policy to allow access to the resources is the second failure.

Non-bastion accounts are configured with federated identity, which is the preferred mechanism for authentication because it integrates with on-premises systems. In fact, in regulated environments, the on-premises systems may have provided the necessary controls to meet local laws and it may be very difficult to replace them. The non-bastion accounts also include an AWS IAM role. The AWS IAM role has a trust policy that allows users in the bastion account to assume it. Assuming that the ID for the bastion account was 987654321012 then the trust policy for the role in the non-bastion account would be:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
{
    "Version": "2012-10-17",
    "Statement":
    {
        "Effect": "Allow",
        "Principal":
        {
            "AWS": "arn:aws:iam::987654321012:user/fred"
        },
        "Action": "sts:AssumeRole"
    }
}

This allows the IAM user “fred” from the bastion account (987654321012) to assume the role in the non-bastion account.


Tags:  AWS  AWS Console  AWS IAM  STS
Categories:  AWS  AWS IAM

See Also

 Top Ten Tags

AWS (43)   Kinesis (9)   Streams (8)   AWS Console (5)   Go (5)   Analytics (4)   Data (4)   database (4)   Amazon DynamoDB (3)   Amazon Elastic Compute Cloud (EC2) (3)  


All Tags (173)

Disclaimer

All data and information provided on this site is for informational purposes only. cloudninja.cloud makes no representations as to accuracy, completeness, currentness, suitability, or validity of any information on this site and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.

This is a personal weblog. The opinions expressed here represent my own and not those of my employer. My opinions may change over time.