Understanding Identity & Access Management Fundamentals and implementing best practice
Overview
Identity and Access Management (IAM) is just one of those things you have to do, but it’s worth getting it right from the start, and not just because the price of getting it wrong could be a disaster. Assigning users access to applications is not rocket science until you have 100s of users accessing dozens of services, and then it really pays to implement a best practice approach.
There are obvious benefits to best practice, and not just because it mitigates risk and enforces compliance, but also because it delivers a better user experience and it can be automated delivering significant efficiencies when deploying new users and managing access.
This will entail creating Group Policies, using RBAC, implementing PoLP, using AWS Organisations, deploying AWS SSO, connecting to ADs and using SAML to federate your SSO.
WOW! That’s a lot of acronyms. In this blog we’ll unpack these concepts and explain why you might want to adopt some of these approaches.
Start at the Beginning - AWS Identity and Access Management (IAM)
At the organisational level, you typically have too many users to simply assign access to users on a case by case basis. Best practice is to use the principle of Role Based Access Control (RBAC). Here you manage Roles, which are given permission to control operations. This allows services (as well as real people) to assume the Roles and perform operations.
Another best practice which drives security (and compliance) is to implement the Principle of Least Privilege (PoLP). This means giving any user access to only those resources they need to perform their authorised activities.
AWS IAM’s supports RBAC and provides features which allow very fine grain control, assisting you to implement PoLP.
IAM also enables you to add specific conditions, such as time-of-day access, configure Multi-Factor Authentication (MFA) or leverage an existing identity Management Solution such as Microsoft Active Directory using Federation.
Managing IAM at Scale - AWS Organizations
AWS Organizations is an additional AWS service that allows you to consolidate multiple accounts and manage them centrally. AWS Organizations service is provided free of charge, and offers many benefits including:
Centralised management across all AWS accounts.
The ability to create Organisational Units (OU) which allows accounts to be grouped for ease of management.
Hierarchical grouping of accounts for budgetary, security, or compliance purposes.
Consolidated billing of all included accounts.
Use Service Control Policies (SCP) to restrict access to AWS Services and resources by users and roles.
Integrates with, and supports AWS IAM across the organisation.
AWS Organizations is also a prerequisite for AWS Single Sign On.
Single Sign On
Single Sign On is not just nirvana for the user; but because it is tightly integrated with AWS Organisations, it streamlines the administration of IAM for IT admins.
AWS Single Sign-On is a cloud-based single sign-on (SSO) service that makes it easy to:
Centrally manage SSO access and user permissions across all your AWS accounts in AWS Organizations to your cloud applications and services.
Manage access and permissions to commonly used third-party software as a service (SaaS) applications, and other applications that support Security Assertion Markup Language (SAML) 2.0.
AWS SSO also records all sign-in activity in AWS CloudTrail giving you the visibility to monitor and audit SSO activity in one place. A very useful resource in the context of demonstrating compliance.
AWS SSO includes a user portal where your end-users can find and access all their assigned AWS accounts, cloud applications, and custom applications in one place.
Using an Existing Directory
In most cases, if you are managing users at scale, you will already be using an Active Directory (AD). If you are using Microsoft AD, AWS Managed Microsoft AD, enables your directory-aware workloads and AWS resources to use managed Active Directory (AD) in AWS.
AWS Managed Microsoft AD is built on actual Microsoft AD and does not require you to synchronise or replicate data from your existing Active Directory to the cloud. So you can use the familiar Microsoft AD administration tools and take advantage of the built-in AD features, such as Group Policy and single sign-on.
Using AWS Managed Microsoft AD, you can easily join Amazon EC2 and Amazon RDS for SQL Server instances to the domain, and use AWS End User Computing (EUC) services, such as Amazon WorkSpaces, with AD users and groups.
Users can use their Corporate Credentials to access all the cloud services they are authorised to access - all through their user portal.
Federation using SAML
If you have another Identity Provider (IdP), such as Okta or Azure Active Directory, you can use Security Assertion Markup Language (SAML) to authenticate identities and provide federated Single Sign On.
AWS SSO provides support for the System for Cross-Domain Identity Management (SCIM) standard which allows you to keep users and group policies from Azure AD, synchronised into AWS SSO, again allowing users to access all their cloud based services and applications using their corporate credentials.
SAML can also be used to provide SSO to other services and applications that support SAML such as Salesforce, Microsoft 365 and Concur.
Next Steps
If you would like to discuss any of these concepts in relation to your organisation, or need help with implementing any of them, PolarSeven is just a phone call away. We would be happy to give you a free consultation to discuss any of your security issues.
If you are managing Users at Scale within a Multi-Account Structure you might be interested in reading about AWS Control Tower which allows you to customise and automate your own security baselines.