4 mins to read
Powerful identity and access management (IAM) models of public cloud providers like AWS, Microsoft Azure, and Google Cloud Platform, enable the deployment of applications and data with far greater protection than what is possible in traditional data centers. However, these IAM solutions are not without risk when used incorrectly, and the risk is very different (and sometimes much greater) than old-world enterprise IAM.
We’re going to explore the history of Identity Management and examine how it has evolved and improved over the years. With the advent of cloud, the nature of identity has experienced a significant evolution. Not only has the approach to identity changed but the way our organizations and teams approach identity needs to undergo a fundamental change.
Let’s begin our journey by defining what Identity and Access Management is and why it’s essential for anyone with an online presence – either personal, professional, or both. We’ll wrap it up with a discussion about current trends, including identity management in the public cloud, and offer suggestions on how to support the necessary changes to maximize data security and maintain ease.
The Importance of Identity
The concept of identity existed long before the invention of the computer and the need for online management. People received names and titles. A person’s name was their original identity. Someone might even have a title associated with their name as well.
Imagine, if you will, a young lady named Jane Cornswoddle, Duchess of the Hinterlands. The name, “Jane,” identifies her as a specific person, while Cornswoddle might establish her reputation based on family associations. The title, “Duchess,” might bestow on Jane certain rights and privileges within her geographic location.
In our modern world of technology, identity hasn’t changed all that much. We still have unique identifiers to establish who we are as users. We might also be assigned a group, such as engineers who report to Alice, the VP of Engineering. Finally, we can be assigned titles based on the rights and privileges we have. Where history had kings and queens, the modern enterprise has Super Users and System Admins.
Identity establishes who we are and what we’re allowed to do, and the systems used to manage and establish identity have evolved. Let’s look at some significant milestones.
Access-Control Lists
One of the earliest forms of digital identity management was ACLs or Access-Control Lists. Users authenticate themselves using a unique identifier, such as a username; and a security token, such as a password. The system evaluates the authenticated user against a table, which lists objects within a system, and specific access rights of users to those objects.
A specific file might have an access-control list entry which allows the user, “Alistair,” to read the file, and allows “Emily” to both read and write to the file. Many of the operating systems (Mac, Windows, Unix) we’ve used in the past have used ACLs to manage identities’ resource permissions.
In most cases, ACLs are used on a single system, requiring users to establish their identity on multiple systems if their roles require. A user would need to sign into their email account, into the time-tracking system, and into the corporate intranet. This approach has become increasingly unwieldy as the number of systems and applications has increased.
Single Sign-on and Federated Identity
The concept of using a single sign-on describes a system where a user’s identity is validated and managed in a single system. The single sign-on system is an identity service provider for other systems within an organization. Users enjoy the convenience of only having to validate their identity once. Centralizing the process of validation and management of identity simplifies a user’s digital interactions, as well as the administration of such systems by the organization itself.
In larger organizations, the concept of federated management allows a person’s identity to be shared and managed across multiple identity management systems.
The Complexities of Identity Management in the Cloud
As cloud-based platforms have gained popularity, cloud identity and access control management have become an integral part of the offerings on these platforms. Identity and access management or IAM cloud solutions are in place with all providers of cloud services. AWS, Azure, and Google Cloud all offer an integrated IAM solution.
IAM solutions aren’t just confined to human users of these systems either. Components of these platforms are also required to have an identity (we like to call them “non-people identities” or “pieces of compute”) that can be validated and used to determine the scope of resources they can access and the nature of those interactions. For an AWS AIM example, an application deployed in AWS might require EC2 instances and a DynamoDB table for it to function. Each EC2 instance is assigned a security group that allows it to establish its identity and to send and retrieve information from the DynamoDB table.
Managing the identities of both people and non-people entities present the additional problem of scale. As the digital footprint of your organization grows, the number of resources you might manage in the public cloud could grow exponentially into the tens of thousands, hundreds of thousands, and even millions. Many cloud entities can also be ephemeral, a fact which further complicates their configuration and management.
Managing a matrix of roles, resources, and permissions in a way that protects your online resources, and ensures the correct permissions for all entities presents a complex problem, that itself requires an advanced solution.
Zero-Trust and the Demise of Network Perimeters
Back when we housed our applications in private data centers, we could rely on the network perimeter to provide a layer of security. Unfortunately, much of this has evaporated with the move to cloud providers. Many recent data breaches have occurred because of incorrect configurations and assignment of roles that are too broad in the permissions they allow.
Zero trust model is a principle synonymous with cloud security. In a zero trust architecture, all entities are considered untrustworthy and must authenticate themselves before being granted access to resources. Best practices dictate the application of the principle of least privilege. Least privilege means that we grant an entity the least possible combination of permissions required to accomplish its tasks.
At the center of zero trust security framework is the IAM system. IAM systems use a variety of methods to establish the identity of a resource and then use roles to assign permissions. Implementing, maintaining, and monitoring IAM to ensure that the security principles of least privilege are applied while maintaining granular access to resources is central to the security of your cloud infrastructure.
Maintaining the integrity of your applications and data is of utmost importance to all IT security and cloud organizations. Fortunately, you don’t have to embark on this journey alone. Organizations, like Sonrai Security, have vast depths of experience in designing, managing, and protecting data for the largest enterprises in the world. Whether you’re hosting your applications in AWS, Azure, Google Cloud, or pursuing a multi-cloud strategy across multiple providers, Sonrai has the experience to help you design and manage a security strategy that works and is easier to maintain and scale.
See a demo today.
Read the latest news and insights
09.19.2022
Understand the difference between fact and fiction...
06.17.2020
In the wake of the largest data breach in CIA history,...
04.07.2020
April has certainly come in like a lion with two high...
