There’s a scene in the original “Matrix” movie when Neo is sitting in the grimy kitchen with the rest of the crew and eating gray, runny slop. No matter what new version of gray slop they eat, they always seem to think that it tastes like chicken.
When confronted with something new, it’s a natural human trait to relate it back to something we already know. I’ve had friends who have grown up exclusively with Western cuisine try tofu and described it as tasting like chicken. If you were to ask my grandmother, who was born and raised in China, what tofu tasted like, she would probably give you a quizzical look and simply state that tofu tastes like tofu.
The problem with this tendency to compare something new to something we’re familiar with (like chicken) is that it can cause us to make a lot of false assumptions – for instance, you might assume tofu is animal-based rather than plant-based.
When we think about cloud Identity Security, we have to work hard to put aside our natural human tendency to instantly equate it with something we already know, or we could end up working off of those false assumptions. In the case of Identity Security, security teams may at first consider cloud to “taste like” the on-premises infrastructure that they’re used to. But cloud infrastructure is entirely different (think back to plant-based tofu versus animal-based chicken), and we must think about the cloud for what it is versus try to fit it in a box from our previous experience in order to design proper security controls. Otherwise, those false assumptions could lead to flawed security architectures and increase the risk of potential cyberattacks.
So let’s take a look at what cloud security is, instead of trying to relate it back to what has been done for on-premises infrastructure. Along the way, we’ll consider the two types of identities – human and non-human – since they each have vastly different access requirements.
The Great Identities Divide: Humans and Non-humans
Human identities (employees, vendors and maybe even customers) are relatively stable and well-known. Human scalability is limited; after all, there’s a limit to how fast a person can type or click. However, human access use cases vary greatly by role and circumstance. For instance, under normal circumstances, a developer may not be allowed access into a production environment, but if there’s an outage, the access level may be elevated to “read all/write all” to allow them to quickly traverse the entire environment to diagnose and resolve the issue. Human individuals can also assume different access roles for various reasons – an individual covering for a teammate out on paternity leave or transferring to another department or receiving a promotion.
Non-human identities (services, microservices or machine identities) are in many ways the polar opposite. Service containers and virtual machines (VMs) are highly dynamic and ephemeral through autoscaling. Service scalability can vary from thousands to extremes of millions of transactions per second. However, non-human service behaviors and access are highly programmatic and predictable. Services never have to cover for another service that has a family emergency, and, during an outage, the human’s task is to diagnose why some service or set of services isn’t behaving exactly like it’s supposed to.
These and many other differences drive us to think about securing the identity of human and non-human access very differently.
Human Cloud Access Considerations
The bottom box of the image below shows the three layers of a cloud environment that are within the control of an organization. The top box depicts SaaS applications in someone else’s cloud that are outside the organization’s control.
- IN the cloud depicts all the native services that are provided by the cloud service providers (CSPs). Each of the three major CSPs now have hundreds of services and provide granular native controls to each of those services. However, users have standing (always-on) access and entitlements, which creates exposure to a range of security issues. Companies with multi-cloud environments have compounded issues as they are managing access in multiple CSPs.
- ON the cloud depicts workloads that organizations build and deploy on top of the CSP’s cloud. All CSPs preach a shared security model which puts the onus of securing workloads ON the cloud on the organization. These workloads could be wholly contained as a single service running in a container or an entire legacy application in a VM. These workloads take advantage of one of the core values of the cloud: elastic compute, which auto-scales fleets of instances up and down based on demand. However, this creates a problem for anyone who wants to peek inside a VM at any given moment to diagnose an issue because it’s impossible to laboriously register every ephemeral VM that comes and goes with a fixed access control list.
- IN the VM ON the cloud describes a possible third layer that could range from a light Java app to a heavyweight legacy independent software vendor (ISV) application. Each of these workloads, of course, has its own security model.
Lastly, every organization uses SaaS applications, whether it be a business application or a technical application. The SaaS vendors each have their own security access method outside the control of the organization. However, the organization still has the need to monitor the activities of the admin for those SaaS apps in case of malicious activity.
Non-human Cloud Access Considerations
Non-human identities, on the other hand, typically use secrets to communicate to each other and to access critical resources. Secrets are credentials like passwords, API keys, SSH keys and the like. There are two sides of the coin when it comes to managing secrets in the cloud for non-human access.
On one side, organizations have to manage the secret itself. This means managing the myriad types of secrets (token, public/private keys, certificates and more) as well as industry or internal rules such as rotation intervals in order to stay in compliance. However, doing this in the cloud in a consistent manner becomes complicated in a multi-cloud environment and with the reality of open-source vaults.
On the other side of the coin, organizations must control access to the secrets, since these secrets are used by each target system to govern how each of the disparate systems talk to one another. A mishmash of control points spread out across each system is clearly inefficient and cumbersome. It’s obvious that a central hub to control access to the secrets is the most logical solution.
Secure Access to the Layers of the Cloud
Securing access to the cloud is challenging. As you build cloud security controls, make sure you don’t fall into the trap of equating it to on-premises infrastructure; remember, tofu tastes like tofu. Instead, consider a robust cloud Identity Security program that accounts for all of these layers of infrastructure independent of an on-premises mental model. A holistic pragmatic approach to improve cloud security will help both digital-native businesses and enterprises lifting and shifting legacy workloads secure access to the cloud for humans and non-humans.
To learn more about how you can take a phased approach to build a pragmatic cloud Identity Security program, check out my next piece, “Why Cloud Identity Security Seems So Hard.”
Charles Chu is the general manager of Cloud Security at CyberArk.
