It has been well established that certain traditional IT security paradigms must be reimagined when approaching cloud native security. One component of a strong security posture takes on a particularly critical role in the cloud – identity. The concept of identity in the cloud can refer to many things, but for the purpose of this discussion, we’ll focus on two main entities: users and cloud resources.
Historically, defense-in-depth was mostly performed through network-layer controls. Advanced threat prevention tools are able to recognize the applications that traverse the network and determine whether or not they should be allowed. This type of security is still very much required in cloud native environments, but it’s no longer sufficient on its own.
Public cloud providers offer a rich portfolio of services, and the only way to govern and secure many of them is through identity and access management (IAM). In this blog we examine three specific challenges security teams face in regard to IAM, as well as guidance on remediation.
Identity and Access Management
IAM is a cloud service that controls the permissions and access for users and cloud resources. IAM policies are sets of permission policies that can be attached to either users or cloud resources to authorize what they access and what they can do with it.
The concept “identity is the new perimeter” goes as far back as the ancient times of 2012, when AWS first announced their IAM service. We’re now seeing a renewed focus on IAM due to the rise of abstracted cloud services and the recent wave of high-profile data breaches.
Services that don’t expose any underlying infrastructure rely heavily on IAM for security. For example, consider an application that follows this flow: a Simple Notification Service (SNS) topic triggers a Lambda function, which in turn puts an item in a DynamoDB table. In this type of application, there is no network to inspect, so identity and permissions become the most significant aspects of security.
As an example of the impact of a strict (or over-permissive) IAM profile, let’s consider the Lambda function. The function is only supposed to put items in the DynamoDB table. What happens if the function has full DynamoDB permissions? If the function is compromised for whatever reason, the DynamoDB table is immediately compromised as well, since the function could be leveraged to exfiltrate data.
If the IAM profile follows the “least-privilege” principle and only allows the function to put items in the table, the blast radius will be greatly reduced in the case of an incident. A hands-on example of this can be found in this CNCF webinar.
Managing a large number of privileged users with access to an ever-expanding set of services is challenging. Managing separate IAM roles and groups for these users and resources adds yet another layer of complexity. Cloud providers like AWS and Google Cloud help customers solve these problems with tools like the Google Cloud IAM recommender (currently in beta) and the AWS IAM access advisor. These tools attempt to analyze the services last accessed by users and resources, and help you find out which permissions might be over-privileged.
These tools indicate that cloud providers recognize these access challenges, which is definitely a step in the right direction. However, there are a few more challenges we need to consider.
Identity and Access Challenges
IAM and SSO
Most businesses today use some form of single sign-on (SSO), such as Okta, to manage the way users interact with cloud services. This is an effective way of centralizing access across a large number of users and services. While using SSO to log into public cloud accounts is definitely the best practice, the mapping between SSO users and IAM roles can become challenging, as users can have multiple roles that span several cloud accounts.
Effective permissions
Considering that users and services have more than one permission set attached to them, understanding the effective permissions of an entity becomes difficult.
“What can Mary access? Which actions can she perform on these services? If she accesses a virtual machine, does she inherit the IAM permissions of that resource? Is she part of a group that grants her additional permissions?” With layers upon layers of configurations and permission profiles, questions like these become difficult to answer.
Multi-cloud
According to RightScale, more than 84% of organizations use a multi-cloud strategy. Each provider has its own policies, tools and terminology. There is no common language that helps you understand relationships and permissions across cloud providers.
Getting IAM Security Right
IAM is only one, albeit crucial, aspect of cloud security. Businesses must look at IAM as a part of their overall security posture and add an integrated layer of security across their application lifecycle. We’d be remiss if we didn’t mention that this is where a Cloud Native Security Platform such as Prisma Cloud would come in handy.
Cloud providers deliver a great baseline for implementing a least-privileged approach to permissions. As cloud adoption scales in your organization, the challenges mentioned above and more will become apparent, and you might need to look at multi-cloud solutions to solve them. As a starting point:
- Don’t use root accounts - Always create individual IAM users with relevant permissions, and don’t give your root credentials to anyone.
- Adopt a role-per-group model - Assign policies to groups of users based on the specific things those users need to do. Don’t “stack” IAM roles by assigning roles to individual users and then adding them to groups. This will make it hard for you to understand their effective permissions.
- Grant least-privilege - Only grant the least amount of permissions needed for a job, just like we discussed with the Lambda function accessing DynamoDB. This will ensure that if a user or resource is compromised, the blast radius is reduced to the one or few things that entity was permitted to do. This is an ongoing task. As your application is constantly changing, you need to make sure that your permissions adapt accordingly.
- Leverage cloud provider tools - Managing many permission profiles at scale is challenging. Leverage the platforms you are already using to generate least-privilege permission sets and analyze your existing services. Remember that the cloud provider recommendation is to always manually review the generated profiles before implementing them.
Learn how Prisma Cloud handles all aspects of your cloud security.