Your services, data, and infrastructure have left the building. Identities, both human and non-human, now enjoy all kinds of access to your resources and suddenly, the private, contained neighborhood we once knew well became a crowded city filled with clouds, services, users, and APIs—a hidden world of cloud permissions that exists right under our noses, an unknown world that never stops changing.
The three major cloud infrastructure environments: Amazon AWS, Google Cloud, and Microsoft Azure, offer a reach and complex Identity and Access model, mainly introducing a broad interpretation of the concept of “identity” to include machines and other computes such as “applications” and even individual functions. The teleporting of the existing entitlement model into the cloud creates a huge challenge for IT security and operations teams. It is primarily a problem of scale and complexity that cannot be resolved by human labor.
I-Robot
One of the interesting concepts of the cloud entitlement model is non-human identities. In the “old world,” when an application or a machine running application code needed access to resources, the app or machine would most often be given the credentials of an administrator. This poor practice resulted in administrator credentials being stored on many machines granting excessive privileges. However, there was a simple answer to the question “who has administrative privileges?”—everyone with access to these machines/applications.
In a cloud-first world, a machine and an application carry their own identity in the entitlement system and should be granted their own access privileges (either directly or through roles they could assume). The machine (or application) is identified by the underlying infrastructure at the time of instantiation and granted an “authenticator” token to be used with available APIs to claim privileges.
This modus operandi fits well into the theory of full accountability and the least-privileged access model. However, this carries with it a penalty for the operators in practice. First and foremost, this shift created a sudden increase in the number of managed identities. In particular, the number of application and machine identities can be disproportionate to the number of human identities. A security group that used to manage entitlements for a few dozens of IT employees can find itself very quickly with hundreds and thousands of machine and application identities (e.g. in a microservices environment).
The implications of inappropriate or excessive privileges granted to an application or machine identity usually become apparent after it is too late—someone with some access to the machine or the application code (e.g. an individual with login credentials to the machine or a programmer with permission to add code pieces into the application) is able to take advantage (or abuse) of the full set of privileges of that machine or the application. Thus, an incident that may seem like a small issue—account compromise of an employee with what seems like a small set of privileges—quickly turns into a large-scale mega-breach. Moreover, it turns out that entitlement review for these identities is much more challenging than with human identities. In the latter case, you can at least approach the individuals in question and inquire about their needs and access requirements. Good luck doing that with a machine or an application that went through several revisions by multiple owners/programmers over the course of two years.
The hidden world of cloud entitlements
The world of cloud entitlement is filled up with strange new concepts. Every service and sub-service comes with its own list of object types, jargon, and semantics. Keeping track of the meaning and implications of each individual entitlement is becoming ever so difficult. To make things worse, model and naming are substantially (and probably deliberately) different.
Let’s talk storage, for example. In Amazon AWS, there are multiple storage services: S3, Glacier, RDS, and DynamoDB, to name a few, not to mention those EBS volumes. They each have individual sets of privileges to be granted with different implications. Even within the individual service, it is extremely difficult to get your hands around the true access policy. A quick look into S3 reveals a complex model involving bucket policies attached to the buckets themselves. Moreover, these IAM policies may reference S3 objects but are not part of the buckets themselves and, of course, Bucket and Object ACLs that are sub-resources within the bucket. Just when you got your head straight around all this, you realize that Amazon Athena can be used for SQL access to S3 data and that you now need to dive into a whole new world of Athena privileges. Confusion and mishaps are not restricted to the S3 domain. Identities entitled to creating, cloning, mounting, and unmounting EBS volumes may have the ability to access data as well as take over machines. Understanding which identities are becoming overprivileged in this elastic world of storage volumes is therefore becoming a complex intellectual task.
Some of the confusion can also stem from trying to view cloud entitlements with the eyes of on-premise ones. For example, some reviews of S3 bucket access policies revealed that administrators tend to grant listing permissions and even write permissions on buckets to the “Authenticated Users” group. Their intent is to limit access to such resources to “Enterprise Users”—the literal translation of the term authenticated users to on-premise language. However, the end result is of course buckets being accessible to any AWS user in any account.
Perfect is the enemy of good
All cloud vendors took a very fine-grained and highly expressive approach to establishing access privileges in their environment. Identities in each environment can be referenced individually or as groups—which in turn might not be disjoint/disconnected. Identities can also be indirectly referenced through roles that they assume. Privileges can be expressed as predefined sets of privileges (e.g. “collaborator”) on the one hand and as individual granular permissions on specific objects on the other hand. Some services include simple UI for basic entitlement configuration. At the same time, however, almost every object, every service, and every identity (or group thereof) can be decorated with a set of policies written in a very expressive language to include wildcards on almost any identifier of identity, object, and operation. Some environments (e.g. Amazon AWS) encourage the use of tags and conditions in such policies, which further add complexity to the model. This is a nightmare for an individual to truly understand the set of identities entitled to access some resource in a specific manner. Security professionals in cloud environments have a very hard time understanding the risks and threats posed by a breached identity or compiling the set of identities that represent a threat to a set of resources.
Whose line is it anyway?
As though things are not complex enough—due to the technical issues described in previous sections—organizational evolution steps in to make them worse. In the “on-premised land” resources (computes and data stores) were provisioned centrally by IT people, who would (usually) follow some central security policy (dictated by the IT Security team) when defining access controls and entitlements. In the kingdom of Cloud Computing the DevOps paradigm rules meaning “every programmer gets to be king.” While somewhat exaggerated, the previous statement is not a total misrepresentation of reality.
In the DevOps world, individual application owners (and programmers) are responsible for the provisioning of objects and computes and are expected to take responsibility for applying some reasonable (centrally dictated) security policy to them. The elastic and evolving nature of the environment means that most often than not, a central policy related to the new objects/computes being provisioned does not exist (as security people were probably not involved beforehand in designing the new environment being provisioned). Even if such a policy existed, it still would need to be distributed to all groups who might be able to provision objects and computes. Of course, even if the people responsible for the provisioning of objects and computes received such a policy, they would still need to be versed enough in all the intricacies of implementing entitlements (as mentioned in the previous sections) in order to make this work.
When security teams are attempting to review entitlements of such an environment, they again face the challenge of not only collecting all the bits and pieces of the model, but also the difficulty of compiling the rationale for it by collecting information from a distributed network of individuals (who provisioned parts of the environment) who at this point in time are all but happy to spend time reviewing their past decisions.
The law of large numbers
While “the law of large numbers” actually discusses probabilities, it should have been used to state that human beings have a hard time processing large amounts of data. Not only that we are slow in collecting, assembling, and processing specific types of data (e.g. entitlement information across multiple sources) when faced with many instances of such issues we quickly fail to see the forest for the trees.
In today’s IT environments, and in particular cloud environments, the sheer number of all objects, identities and operations cannot be handled manually. This is true for the moment of granting some privilege as well as the aftermath of trying to review the effective access capabilities of an individual or the set of threats to some object. When the cross-product of identities, objects, and actions in a mid-size environment is well in the high millions range, it is no wonder that people who try to implement a proper entitlement policy make mistakes. Similarly, a security team trying to review enterprise entitlement posture manually will not effectively discover mistakes, risks, and policy violations in the cloud environment.
Zscaler CIEM uncovers your hidden world of cloud permissions, providing absolute permission control. It runs continuously & automatically across all cloud platforms, services, and identities, and uncovers all hidden permissions, showing you at every moment exactly who can access what. Now, you can find misconfigurations as they happen, remediate them, and stop permission risks from causing disaster—because life in the cloud doesn’t have to mean head in the clouds.
To learn more about Zscaler CIEM or to schedule a demo please connect with us directly.
