14 min to readCloud ServicesApplication Services

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

Nick de Wijer
Nick de WijerPrincipal AWS Platform Architect
An aerial view of a snowy road with cars driving on it.

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.

Identity and resource based IAM policies

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:

Action Definition
s3:PutObject Allows for the writing of an object into S3.
kms:* Allows every action within the Key Management Service (KMS)
* Allows everything.

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:

Action Definition
arn:aws:s3:::accesslogs/* Defines all objects within an S3 bucket called "accesslogs"
arn:aws:kms:eu-west-1:045676890123:key/87132241-9a03-4c89-a723-af0b43aea2bc7 Defines a specific KMS key within account 045676890123 in AWS Region eu-west-1
* Defines all resources

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.

IAM merging and analysing resource and identity-based policies

If, however, a "Deny" is found, the request will be denied, even though an "Allow" for that same request exists.

IAM denying policy due to deny statement found analysing combined policies

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.

Example AWS Org OU structure

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
Visual representation of AWS Org policies' influence in an OU structure

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.

IAM Policy evaluation flow

Where before, only Resource and Identity based policies (and permission boundaries but I am leaving these out right now for the sake of simplicity) were at work determining if a request for access was to be allowed or denied. With the introduction of SCPs, they will also weigh in if a request will be allowed or denied.

A deny at the SCP level will deny the entire request

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.

Visual representation of the interaction between Users/Groups, Permissionsets and AWS Accounts

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.

Simplified overview user access via AWS IAM Identity Center

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:

User attribute in IAM Identity Center Maps to this attribute in your Microsoft AD directory
AD_GUID ${dir:guid}
email ${dir:windowsUpn}
familyName ${dir:lastname}
givenName ${dir:firstname}
middleName ${dir:initials}
name ${dir:displayname}
preferredUsername ${dir:displayname}
subject ${dir:windowsUpn}

Read more

These attributes are the ones minimally required to perform successful logins into AWS. What ABAC allows for is to sync more attributes from AAD into Identity Center. Examples of these are department and cost centre, or office location and function title.

By passing these attributes into AWS and linking them in ABAC, direct references to these can be made by Identity Provider.

Example view of Attribute-based Access control

These attributes, as the name of the service implies, can then be used to help dictate access for users within AWS.

Now, let’s bring all these components together and use them in tandem to provide easy, secure, and flexible access into AWS. Read part 2 of this blog.

A green field with a river running through it.

Explore our cloud services

Optimise your path to the cloud with SoftwareOne.

Explore our cloud services

Optimise your path to the cloud with SoftwareOne.

Author

Nick de Wijer

Nick de Wijer
Principal AWS Platform Architect