Securing your AWS estate with tagging and your current identity solution, part 1

Identity access management (IAM) is one of the biggest challenges an organisation faces as it scales up from startup to enterprise.

As a fresh plucky startup, you didn’t pay much attention to identity and access. You only had a few users and had email addresses like john, lois or craig@company.com. You knew everyone on a first name basis, and everyone was trusted.

As the company becomes more successful, it grows. A second John is hired and suddenly you have to make modifications to the way you onboard users. Different styles of usernames and email addresses are introduced. And this new John really shouldn’t be able to access the financial results information, so you start introducing security groups, locking away data behind that up-until-now-ignored identity access management system.

Fast forward several more years. Your now large enterprise is constantly changing. An entire team is now running your identity and access; entire FTEs are spending their days onboarding new hires and offboarding the people moving on. New departments are being created or restructured which requires a lot of security group changes.

And now the company is moving into AWS, with entire departments foaming at the mouth to get their hands on those new shiny toys. How will your IAM team possibly manage these thousands of users and groups in this new environment quickly enough to satisfy the business needs but maintain the security they had years to organically build up?

Using AWS IAM Identity Center and Service Control Policies via AWS Organizations will allow you to manage your users and groups from your main identity provider in such a way that it will require minimal management on the AWS side.

Before going deep, hooking up all kinds of different services together, let’s begin with a bit of context to put all the different services and acronyms in their right place. If you’re familiar with the relevant AWS services, you can skip to part 2 of the blog series.

IAM policies 101

I often summarise access control in AWS with this statement: "Denied unless Allowed unless Denied."

What this means is that, by default, an entity within AWS has no rights to do anything unless these rights have been given AND, and this is the important part, they have not been explicitly denied.

So, written out fully, it’s Implicitly Denied until Explicitly Allowed until Explicitly Denied.

Within AWS what is allowed or denied to an entity is defined within Identity Access Management (IAM) policies. These policies are JSON formatted documents that define what a "principal" is allowed to do or, more importantly, not allowed to do within a certain context.

This principal is the initiator of the action and can be an IAM user or an application because within AWS, nothing and no-one is allowed to do anything without an IAM policy allowing it to do so.

Policies do not live in a vacuum. Policies are attached to things. These things differ depending on the policy.

If the policy is identity-based, they are ether assigned to IAM roles which in turn can be assumed by another AWS resource or IAM User or, the policy can be assigned to IAM users/groups directly.

If its resource based, the policy is attached directly to an AWS resource that will then be used to determine what rights the interacting principal has on this resource.

The components of these policies are as follows:

• Version: The policy language version so that AWS can correctly parse the data defined in the policy. Two exist, the older 2008-10-17 and the current 2012-10-17.
• Statement: Contains one or multiple policy statements.

Within the statement, policies are defined with the following.

Principal

Defines the principal (initiator of the action) that this policy statement applies to.

A principal, when defined must map against an IAM or STS user, group or role or an AWS Service. These can be as broad as an entire AWS account or as narrow as a single IAM user.

Examples:

• AWS Account: "Principal": {"AWS": "arn:aws:iam::045676890123:root"}
• AWS Service: "Principal": {"Service": "delivery.logs.amazonaws.com"}
• STS Assumed Role: "Principal": {"AWS": "arn:aws:sts::045676890123:assumed-role/{rolename}"}
• AWS Role: "Principal": {"AWS": "arn:aws:iam::045676890123:role/{rolename}"}
• If the policy is used in an identity-manner, it is not required to be defined because it is inferred by the principal the policy is attached too.

If the attached is used as a resource-based object however, it is required to define what principals are allowed to interact with the resource.

Effect

Does the policy either "Allow" or "Deny" the action defined in the policy.

Action

Define an action within AWS.

Actions are defined as “{service}:{action}” where part or the entirety can be replaced with a wildcard *. Examples are:

If not secured with either a Resource or a Condition statement, it will allow full access to every part of an AWS account or resource.

Actions can be defined as “Action” or “NotAction” creating a white or blacklist respectively. Combined with Effect:Deny, double-negative style allows can be created. We will zoom in on this later.

Resource

Define the AWS resource that the Action is limited to. This resource must be defined with an AWS ARN and one or more wildcards (*) can be used to broaden the scope of the resource(s) under the policy.

Examples are:

Condition

Conditions is an optional statement that can contain one or more sub-statements where further allowances or limitations can be made on top of Principal/Action and Resource.

Within conditions, logic checks can be performed. For example, comparing values from the calling principal to the targeted resource. Another often used condition is to check (and then block) for unencrypted traffic.

Full policies

Bringing all these together will create policies as these two examples.

This identity-based policy allows administrator rights to the entire AWS Account:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
] 
}

This resource-based policy allows all principals from the account 045676890123 to write into the bucket “access logs” as long as the connection is encrypted:

{
"Version": "2012-10-17",
"Statement": [
{
"Principal": {
"AWS": "arn:aws:iam::045676890123:root"
},
"Effect": "Allow",
"Action": "S3:PutObject",
"Resource": "arn:aws:s3:::accesslogs/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "true"
} 
}
} 
] 
}

Bringing it home

When a request is made within AWS all the policies attached to the identity requesting and the resources requested from are taken and combined into a single policy. Then, if at least one “Allow” to the resource and no “Deny” is found, access is given.

AWS Organizations

AWS Organizations (service name, further abbreviated to AWS Org) is designed to be used by organisations to centrally manage AWS accounts under their ownership more effectively.

It allows for grouping AWS accounts in a hierarchical method using one or multiple levels of organizational units (OU) based on the requirements of the organisation.

These OUs will house one or more AWS accounts and can have several types of policies attached to either the OU or accounts directly to allow management on a high or granular level. The available policy types are.

• Backup policy – Ensure consistency in how AWS Backup plans are implemented
• Tag policies – Standardise tags on all supported resources
• Service control policies (SCP) – Control IAM permissions within the AWS account
• AI services opt-out policies – Control what AI Services can store and what content within an account it can use to do its job

When a policy is applied to an OU, the policy will affect all child OUs and AWS accounts within those OUs as seen in the image above.

Service control policies (SCP)

Service control policies (SCP) introduce an extra level of securing AWS accounts by granting or denying access to resources.

We’ve spoken about IAM policies – how they are constructed and how identity and resource-based policies grant or deny access for a request.

What is important to know at this stage is that that an extra step is introduced when AWS Org is enabled.

Tagging policies

The last component I want to highlight within AWS Organizations is tagging policies. These policies can enforce the way resources can be tagged.

They however do not enforce a specific tag being used.

{
"tags": {
"department": {
"tag_key": {
"@@assign": "Department"
},
"tag_value": {
"@@assign": [
"finance",
"sales",
"security"
]
},
"enforced_for": {
"@@assign": [
"ec2:instance",
"kms:*"
]
}
}
}
}

As an example, this policy defines that if the tag "department" is used, it must have one of the three values defined in "tag_value". Furthermore, this enforcement is then only done on ec2:instance and all kms resources.

It’s important to fully understand the goal of tagging policies. They are designed to be used for compliance reasons. Using the Management console or the AWS CLI, you can generate a report of non-compliant resources to allow for correction later.

Also, not all resources can be tagged. "ec2:*" for instance is not supported and specific resources must be defined. A complete list can be found here.

Enabling AWS Org will also enable other services and enable centralised management functionally of existing services. A sample of services which are important to AWS Org or relevant to this document are the following:

Centralised billing – free

Enabling AWS Org instantly turns the account that created it into the master billing account (MBA), also known as the Root account. What this means is any account in the AWS Org, including itself, reports its AWS service usage to the MBA from where a single billing dashboard will be available, and a single bill will be generated and paid out to AWS. The consolidated billing dashboard is free to use and a great way to analyse costs across the accounts in the AWS Org by service, account or any tagging enabled for billing purposes.

AWS IAM Identity Center (successor to AWS SSO) – free

This service has recently been renamed from AWS Single Sign-On (SSO), which is why the name right now is a mouth full as both are being used in this transition phase. Identity Center enables the organization to centrally manage and control the AWS Management Console and API access for Users and Groups across all AWS Accounts within the Organization. This is done by using either the built-in Users and Groups functionality of IAM-IC or by connecting to a third-party Identity provider (IdP) like Okta or AzureAD.

We will go in further detail in the next chapter.

Enterprise support – Paid

Standard AWS accounts have three tiers of support:

• Basic: Allows only for account, billing, and business support cases.
• Developer: Opens the capability of logging technical support cases.
• Business: Adds P1 and P2 urgency to support cases and give quicker support.

With an Organisation, a fourth tier opens; Enterprise support. (Which itself split up in two tiers: Enterprise On-Ramp and Enterprise.)

The first three tiers of support were set on an account level. Enterprise support is set at the organizational level and allows for every single account to have the highest grade of support available.

AWS IAM Identity Center

AWS IAM Identity Center (successor to AWS SSO) is the single sign-on solution for AWS accounts joined together within an AWS Org. Identity Center gives a centralised location to manage users and groups, their access to AWS accounts within the organization, and what rights they have within those accounts using Permission sets. By default, the root account of the AWS Org is the administrator of Identity Center but this can be delegated to, for instance, a dedicated IAM or Security account. This will prevent too many users accessing the, arguably, most important account within the AWS Org.

A permission set is a structure that contains one or more of the following IAM policies:

• AWS managed policies
• Customer managed policies
• Inline policy, so defined directly inside the permission set
• Optionally, a permissions boundary

When a Permission set is provisioned in a member account, an IAM role is created with policies that correspond to the specific rights defined within the permission set, e.g., an attached policy or an inline policy. These IAM roles (and policies) are protected entities that cannot be modified from the member account.

When a user logs in via Identity Center, they can then assume the IAM role in the member account to work within this account within the boundaries defined in the IAM role.

The power of AWS IAM Identity Center lies in its capability of integrating with Security Assertion Markup Language (SAML) 2.0 compliant Identity providers (IdP). Most organisations already use an identity provider to manage their users with providers like Okta, Active Directory Federation Services (ADFS), or Ping, among others.

Going one step further, by using System for Cross-Domain Identity Management (SCIM), users and groups can be synchronised automatically from the SAML IdP into IAM-IC.

The result of this allows organisations to set up a single sign-on environment where users can access AWS with the same credentials they use for their workstation, email, or other work environments. Often without having to even fill in their credentials again.

Attribute based access control

Identity Center also introduces a feature that is not enabled by default and slightly hidden away but allows organisations to manage user access in an entirely new way by basing access on enterprise specific parameters, which is called Attribute-based access control (ABAC).

In a simple Azure AD SAML & SCIM setup, only these user attributes are synchronised:

Read more