A Guide to: Accelerating Identity Security Maturity in the Cloud

Authored by:

Chad Lorenc

US-West Security Practice Manager Amazon Web Services

Mike LaRue

Sr. Consultant, Security Amazon Web Services

Tally Shae

Product Marketing Sonrai Security

This guide is inspired by the session, “Accelerating Identity Security Maturity in the Cloud,” delivered by Chad Lorenc, at the ACCESS: Identity, Access, and Permissions Summit 2023. You can find the original presentation on-demand here.

You must be ready to kick off your cloud identity security journey. Whether you’re asking yourself where to start, wanting to assess your identity security baseline, or looking to scale your maturity, you’re in the right place.

Below, we’ll cover the four phases of maturing a cloud identity security program, walking through what to consider at each phase, guiding security principles, and tips to ensure your identity program is business-objective focused.

Remember, cloud security is a journey, not a destination, but here’s a roadmap to get you started in the right direction.

Setting Your Cloud Identity Baseline

Business Objective: 

Enable secure cloud access to facilitate innovation without disruption.

Guiding Principle:

By default, ALL cloud access is privileged access.

Treat All Cloud Users as Privileged

Handling privileged access with extra care is not a unique identity concept. For the cloud, what is unique is who is considered to be privileged. In the cloud, all identities should be considered privileged. Since all identities in the cloud are considered privileged, we will borrow key capabilities from traditional Privileged Access Management (PAM) solutions.

Require Multi-factor Authentication (MFA): MFA provides an extra level of protection against threats to password security by requiring additional verification factors to prove identity.
Use Temporary Credentials: Temporary credentials leverage time-based tokens to access necessary resources or services. Unlike a password, a temporary credential is only valid for its defined lifetime, which limits exposure to unauthorized access to systems and resources.
Log All Access: Log all access in the cloud, whether it is through a console, command line interface (CLI), API, or any other programmatic method. Logging access in the cloud enables the ability to alert and respond to unauthorized access events, provides visibility into how your cloud environment operates, and facilitates ongoing permissions refinement.

Map Internal Identities to the Cloud

The preliminary step when setting up your cloud identity baseline, involves mapping your identities to the cloud. Building a clean and manageable model for your cloud identities will start you on your journey to building your identity model.

Centralize IAM: Managing user identities within an organization is streamlined when centralized. Centralization of identities drives consistent access and limits misconfigurations as identities are propagated. Centralizing identities requires defining an organizational structure for your cloud environment.
Define Your Roles: In an organization, different job functions have different access requirements within the cloud. You need to identify and define the different job functions that will operate in the cloud so that you can provide the right level of access. Operating in the cloud may introduce some new job functions to your organization, such as cloud operations, cloud engineer, or cloud security practitioner. These roles should be mapped in your internal directory.
Enable Single Sign-on: Enabling single sign-on within your cloud environment will allow your user community to leverage their identity to access resources across various identity boundaries (e.g., cross-account, cross-tenant) within your cloud environment.
Enable Federation: Federating identity with your existing identity platform allows you to utilize the same identity across different domains. Federation will prevent you from needing to recreate your identity program in the cloud and leverage your existing identity services and processes.
Map Roles to Policy: Once the job functions are mapped to roles in your internal directory, you can map these roles to identity policies in the cloud. Most cloud service providers have predefined policies already set up that align with common job functions in the cloud. Leveraging these predefined policies allows you to quickly align permissions to roles you defined. This means aligning developer roles to developer permissions, auditor roles to auditor permissions, and so on. This establishes a baseline system for identity management in the cloud and avoids giving groups of users broad sets of privilege.

Get a Comprehensive Cloud Identity Audit – Free

Uncover your cloud identity risks in 24 hours, with recommendations on next steps to immediately reduce your risk.

Request Your Audit

Recognize All Identities

It is important to understand the different identities that exist in the cloud. Each identity type will have unique characteristics that are addressed as part of your cloud identity baseline. In AWS the consumers of these identity types are referred to as Principals.

Cloud Users: Cloud users are the human users that access and administer the cloud. They are privileged access users who build infrastructure, spin up instances, deploy databases, and so on. Cloud user identities are often referred to as workforce identities. Access for cloud users is managed through cloud Identity and Access Management services which are often federated with your existing identity platform.
Application Users: Application users are human users that interact with applications and services. They access applications via front-end systems and services and do not have access outside of the application. Application users are also referred to as customer users.
Machine Identities: Machine identities are identities that interact resource to resource – there isn’t a human user tied to them. These are similar to service accounts in on-premises environments. Machine identities are leveraged by cloud resources and services when they need to take action within the cloud (e.g., a container resource accesses a storage resource). They are also leveraged by external integrations with the cloud (e.g., the CI/CD pipeline deploys infrastructure in the cloud). Machine identities significantly outnumber cloud user identities.
Account Owners: Every account has an account owner. This identity is the first point of contact behind the account. Account owners need to be clearly defined. In most organizations, the account owner should not be tied to a single individual, instead the account owner is tied to a shared contact mechanism like an email distribution list.
Root Users: The most important account, even more powerful than the privileged accounts like cloud users. They have an email and password sign-on to the cloud with complete access. The root user should be tightly controlled and protected. It should only be used in specific cases that only the root user can perform.

Machine identities significantly outnumber human users. These identities require a whole new approach and set of tools to secure because they behave differently than human users. Their usage is programmatic and predictable, but also ephemeral and short-lived. They can easily become overprivileged and can pose significant danger if not properly secured.

Building Your Identity Defenses

Business Objective:

Enhance security while enabling rapid resource provisioning for faster development.

Guiding Principle:

Create layers that enable and protect the business.

Identity provides connectivity in the cloud. This is similar to how a network firewall works within an on-premises environment. You could pull a network firewall configuration and see the flow and communications patterns between apps and data – that is how identity and access works in the cloud. In the cloud, identity controls communication between applications, resources, and data. In this phase you create the layers that protect your business.

Creating Fences, Gates, and Guardrails

Permissions work in a hierarchical-like structure in the cloud. Some identity policies take precedence over others. As you increase the maturity of your identity model you will begin adding granularity to what resources principals may access and what actions they can take on a given resource. There are multiple levels in the identity model where you can facilitate permission refinement. These levels work together to define the final set of entitlements a principal receives. These levels need to be considered with building your identity model:

Guardrails: Guardrails are identity controls that define broad access capability within an entire organization. These are common controls that impact all principals within an organization and set your baseline policy. These guardrails may be designed to ensure compliance to a regulatory standard or enforce data residency. They may also be used to set operational and security standards for your organization regarding which regions may be used within your organization, what services can be used, and what specific actions are forbidden. A guardrail may be a Service Control Policy (SCP) in AWS that blocks a principal from granting S3FullAccess to an S3 bucket, or a GCP IAM Deny policy that prevents making resources public.

Fences: Fences or permission boundaries set limits on permissions a user or role may have within an account. These are implemented through managed policies that define the maximum permissions a principal can have granted via an identity-based policy; For example, enforcing that a specific user can only manage specific services like S3 or CloudWatch.

Gates: Gates articulate the specific conditions that must be met to enforce an identity policy. Conditions could be based on time of day, a principal’s location, specific resource definitions, etc. For example, you may want to allow a front-end developer to only access resources that are tagged as “web”. A conditional policy like this would limit access to only “web” resources and prevent the developer from accessing resources that did not contain that tag.

Securing High Risk Identities

Understanding, identifying, and securing your highest risk identities is a critical component of maturing your identity security. The highest risk identities are those with the greatest privilege (i.e. power and potential for damage if misused).

Root User: The root user is the primary administrator of an account. It is the most powerful identity available holding all available permissions. Extra care needs to be taken when managing the root user identity.
- Lock away root users and use them as infrequently as possible.
- Ensure MFA is enabled and never create access keys associated with the root user (Note: blocking the creation of access keys for root is a common guardrail.)
- Build a break glass user for emergency access needs. The break glass user is associated with a role that can support the root user, and not the root user itself.
- Monitor and alert for the use of the root user so that you may quickly take action if unauthorized.
Service Accounts: Service accounts are the machine identities that provide access to resources and services to non-human principals.
- Use roles for machine identities and avoid the use of access keys. Roles provide temporary access to services and resources. An access key is a long-lived credential. Anyone with access to a resource with a key is also able to use that key to extend their access. For example, if an EC2 instance uses an access key to access other resources, an adversary with access to that EC2 could acquire the key and abuse the privilege associated with the key, moving laterally or escalating privileges for further damage.
- Leverage a secrets manager as opposed to hardcoding any passwords or authentication forms into applications.
- If you must use access keys or embed secrets in code, rotate them frequently to reduce how long the credential is valid. If possible, automate key and secrets rotation.
Administrators: Administrators have broad levels of privilege that allow them to create new identities, provision new access, build infrastructure, and even delete your cloud. It is critical to ensure attackers cannot access them.
- Identities with admin level privilege should be treated with the utmost care and audited frequently to certify that they should have that level of sensitive privilege.
- Ensure there are no pathways allowing unauthorized identities to inherit admin-level privilege by role-chaining or toxic combinations of permissions culminating together.

Automation Pipeline

As you mature your identity security model you can begin to ‘Shift Left’ by addressing identity earlier in the deployment process. Shifting left occurs when cloud identities are created and managed via automation pipelines. This is only possible once your foundations are built and you know identities can be created automatically, but in a secure fashion (think back to those guardrails, fences, and gates).

Infrastructure as Code (IaC): IaC refers to the process of building cloud infrastructure with code through automation as opposed to manually. As one of the components of your Infrastructure as Code, include Identity as Code as well. As you deploy your cloud infrastructure, define and deploy your roles and permissions in code. This will ensure consistent deployment of identity functionality. It will also provide an audit trail for changes to identity configurations.
Pipeline Roles: CI/CD pipelines used to deploy IaC often require elevated privileges. Since pipeline integration with your cloud leverages a machine identity (service account) you will need to define the roles that will be used for deployment. Take care to ensure those roles are limited to the permissions required to deploy your IaC. For example, if your pipeline only deploys network infrastructure into an environment, limit its role to only networking permissions. This would ensure that your network pipeline cannot be misused to deploy unauthorized resources or enable unauthorized services.

Tuning Your Identity Access

Business Objective: 

Enable a robust least privilege access control framework that streamlines operations, simplifies compliance, minimizes human error and disruption, and enhances security processes, all while facilitating seamless scalability.:

Guiding Principle:

Nobody wants to buy least privilege for least privilege’s sake.

Drive Down Risk

As you continue on your identity journey and move toward higher levels of maturity, we transition from the build phase to fine-tuning the access and privileges assigned to your principals. This tuning will help you drive down risk, however it must align with your business objectives.

Identify Risk: Establish what risk you’re trying to address and what is important to your business. For example, if your business is subject to regulatory requirements, you may need to address the risk of non-compliance. If your business has 100% uptime requirements, you may need to address human error. It is likely you will need to manage multiple risks to address your business requirements. It will be necessary to understand the priority of those requirements to help you prioritize which risks to address and the best way to address them.
Understand Impact: Knowing where your critical data resides and the impact of that data to your business is important. You need to identify your highest risk data and work backwards to your business objective. As you move toward least privilege, start building it out at your highest impact data.
Quick Wins: Start where there is the greatest impact. Some low-hanging fruit to tackle first is unused identities in your environment. Simply auditing these identities and removing unnecessary ones can trickle down and clear up other risks like privilege escalation or lateral movement.
Measure Often: Create measurable benchmarks to determine success and use as a framework for stakeholder communications. You should measure and communicate your progress and alignment to the benchmarks as well as the business impact.

Move Towards Least Privilege

Least privilege is a well-known and trusted security principle; however, it is difficult, time consuming, and expensive. Least privilege alone is not a concept to sell to your stakeholders. Focus on rooting least privilege in a business objective. Working towards least privilege is not worth aimlessly working on unless there is a clear outcome to the business that you can communicate a measurable impact on.

Refine Permissions: Earlier, we referenced managed cloud policies. These were a great starting point, but now it’s time to customize identity policies so they fit your unique business needs. These policies can enforce any internal standards or unique needs for your business objectives.
Use Automation: Use automated tools to get a clear understanding of what permissions are needed by a principal. It’s challenging to figure out which resources and services are being accessed, and by whom, just by manually reviewing logs and piecing together communication trails. Automated tools can quickly track and identify what actions are required in a given set of permissions allowing you to revoke unnecessary permissions.
Simplify: Look for opportunities to simplify. For example, when you get moving on processes like automatically creating compute, using tagging methodologies can be helpful. You can tag identities by attributes so their privilege is provisioned according to their attributes. This is referred to as Attribute-Based Access Control (ABAC).

Identify Risks with Automated Tools

Cloud environments change frequently. The velocity of changes in the cloud impacts identity and your overall security posture. Tooling is needed to identify issues within your environment. For identity, what tool you use is less important than being able to identify risks, measure identity health, and track progress remediating those risks. Some common risks to look out for:

Inherited Admins: Inherited admins are identities with admin-level privileges where the privilege was not explicitly assigned to them. In the cloud, the complexity of permissions can lead to identities inheriting privileges through other roles, trust relationships, conditions, etc. This means there can be identities with admin privilege that your teams don’t see.
Unused Identities: The proliferation of cloud identities and automated provisioning of privilege can make it hard to maintain proper governance. Typical enterprises have many identities that are dormant, forgotten about, and unused. These entities are unseen to your teams, but can still be manipulated by attackers. They come about easily, but can be just as easily solved with proper monitoring and maintenance.
Overprivileged Identities: It is very easy to assign broad permissions during the development process for greater ease of use and less operational obstacles. Additionally, as previously mentioned, it is very easy for identities to inherit privileges your teams never intended for them to have. The more privilege, the more damage an identity can cause if exploited.
Role-chaining: Role chaining is where an attacker leverages one role to assume another role, which then grants access to an additional role, and so on. This can lead to a dangerous accumulation of permissions that can lead to cloud hijackings, ransoms, or business disruption.
Cross-account Access: Cross-account access occurs when an identity can move from their original account to another via their permissions. This can be difficult to identify because manual efforts and some tools cannot track this risk. This is a common risk and in many cases a role gains the ability unintentionally. Meaning, your teams never intended to allow this, but the identity inherits the ability. This might mean a piece of compute in a testing account somehow finding their way to a production account.

Monitoring Your Identity Access

Business Objective:

Enable instant provisioning for users and environments to maximize efficiency and minimize risk while expediting the delivery of products, features, and services to market.

Guiding Principle: 

"You do not know, what you do not know."

The concept of entropy in physics can be extended to Identity. “IAM Entropy” is the concept that over time, your identity implementation will gradually decline into disorder. This is due to the proliferation of identities by Infrastructure as Code (IaC) for resources, services, and microservices. Permissions are accumulating daily. To maintain your identity baseline and maintain order in your identity model, visibility is crucial. Whether natively within your cloud service provider or leveraging a third-party tool, proper monitoring of identity permission usage and resource or data access is needed. Once you’ve reached your secure baseline, monitoring is how you stay there by catching changes that introduce new risk.

Pipelines

Scan Your Code: Security code scanning is important to identify vulnerabilities in code. Since identity is core to your cloud security posture, scanning code for identity issues is valuable. Scanning is a preventative control that helps you find and remediate issues before they are implemented. Commercial and open source tools are available.
Block the Build: You can set up your CI/CD pipelines to stop deployment if vulnerabilities are found. This will ensure vulnerabilities are not introduced to the environment. A secondary benefit to ‘blocking the build’ is it encourages developers to produce tighter code so their deployments are not stopped.

Detect

Leverage Honeytokens: A honeytoken is ‘bait’ data that is created to entice bad actors. If access or manipulation to one is detected, you know there is a malicious threat.
Track Changes: Install a change management process for changes to identities or roles. Knowing when changes occur and having an audit trail is helpful when addressing identity issues.
Anomaly Detection: Detect anomalous permissions and access activity. Use tools to catch unusual usage of permissions or unusual access to assets.
Monitor Root: Root keys or root users should never be used, so if you detect activity, this should be escalated to an incident.

Monitor & Maintain

Identity Hygiene: Maintaining your identity model and ensuring your environment stays clean helps maintain your security posture. As part of your monitoring activity make sure action is taken to address issues that are found. Regular cleanup is likely needed as your environment changes over time.
Remove Unused Identities and Roles. These are identities and roles that were implemented but never used. This is a common situation as applications and services change over time.
Remove Dormant Identities and Roles. These are identities and roles that were once used but have not been used over a set period of time. The definition of the time between usage is dependent on the use case for that role. Depending on your business, this could be 30, 60, or 90 days. Before deleting a dormant role, you will need to investigate to ensure removal does not impact your business. Regular reporting of stale identities and roles shared with your development community can help with these investigations.
Remediate Overly Permissive Roles. When a role is found to be overly permissive, whether through its own permissions, cross-account access, or role assumption capabilities, investigate the issue and work to remediate the issue.
Remove Unused Permissions in Roles. This is similar to removing unused roles but in this case the role is used, but certain permissions within the role are not being used. This activity is necessary to drive towards least privilege.

Respond

Auto-remediation: Leverage automation in your remediation workflows. In response to anomalous change detection, seek out automated remediation efforts like bots to detach policies or forcefully end sessions.
Establish Red and Blue Teaming: consider bringing in third-parties to intentionally breach your perimeter or exploit identity and access misconfigurations to help point out your gaps. Equally, have your incident response team available to respond or build out plans for remediating discovered concerns.
IR Playbooks: Establish a playbook for incident response and documentation around what tools and solutions your teams have for enforcing access controls in the cloud.

Building a robust cloud identity and access program can feel daunting when viewed as a whole. Instead, we can break it up into maturity phases. Your build phase includes steps 1-2, setting a baseline and building your defenses. Step 3 means fine-tuning your identity privilege and access. Finally, step 4 means monitoring everything to keep your security up-to-par.

Sonrai’s Cloud Identity Diagnostic is a free and non-intrusive analysis of all your cloud identity risks. The report details what your greatest concerns are, where they are, how they compare to peers in your industry, and finally, how to fix them. The insight comes in an easy-to-share report with actionable items to remediate and strategic guidance to help build your IAM program.

This is a great starting point for your cloud identity journey or a compelling justification for budget on your next identity project.

Learn More About the Opportunity Here

Sonrai Security Releases Industry-First Risk Insights Engine 👉

Interactive Product Tour

Interactive Product Tour

A Guide to: Accelerating Identity Security Maturity in the Cloud