Why machine identities matter (and how to use them)
The migration of everything to the cloud and corresponding rise of cyberattacks, ransomware, identity theft and digital fraud make clear that secure access to computer systems is essential. When we talk about secure access, we tend to think about humans getting access to applications and infrastructure resources. But the real security blind spot is the computing infrastructure, i.e., the machines themselves.
The rise of the machines
The modern digital economy relies on a massive network of data centers with reportedly 100 million servers operating worldwide. These 100 million physical servers might represent nearly a billion virtual servers, each an entry point for hackers and state-sponsored bad actors. Additionally, depending on which analyst you listen to, the number of connected devices shows no signs of slowing down – the installed base for the internet of things (IoT) was reportedly around 35 billion by the end of 2021, with 127 new devices hooking up to the internet every second. That is an incredible amount of machine-to-machine communication, even more so when you factor in the 24/7 demands of the connected society.
At the same time, denial of service (DoS) attacks and most hacking attempts are also automated. Human hackers write software exploits, but they rely on large fleets of compromised computers to deploy them.
In the dangerous world of cloud computing the machines are hacking into machines.
For these reasons alone, it is not hyperbole to say that machine identities and secure access has become a priority for both IT leaders and decision makers alike. In the 18 months since machine identity management made its debut on the Gartner 2020 IAM Hype Cycle, the trust that we need to have in the machines that we rely on for seamless communication and access has become a critical part of business optimization.
Machine-to-machine access technology is lagging behind
The fundamental reason for the increase of successful hacking attempts is explained by the fact that machine-to-machine access technology is not as advanced as its human-to-machine counterpart.
It is well accepted that reliance on perimeter network security, shared accounts, or static credentials such as passwords, are anti-patterns. Instead of relying on shared accounts, modern human-to-machine access is now performed using human identities via SSO. Instead of relying on network perimeter, a zero-trust approach is preferred.
These innovations have not yet made their way into the world of machine-to-machine communication. Machines continue to rely on the static credentials – an equivalent of a password called the API key. Machines often rely on perimeter security as well, with microservices connecting to databases without encryption, authentication, authorization, or audit.
There is an emerging consensus that password-based authentication and authorization for humans is woefully inadequate to secure our critical digital infrastructure.
As a result, organizations are increasingly implementing “passwordless” solutions for their employees that rely on integration with SSO providers and leverage popular, secure, and widely available hardware-based solutions like Apple Touch ID and Face ID for access.
However, while they both outnumber humans and have the capacity to create more widespread damage due to scale and automation, machines are still frequently using outdated security methods like passwords to gain access to critical systems.
These methods include but are not limited to:
- Use of static credentials, such as API keys (“passwords for machines”)
- Reliance on shared credentials when the same key is used by different services
- Reliance on perimeter security, when only the network boundary is protected.
Towards a unified notion of identity for humans and machines
If passwords are insufficient to protect applications and infrastructure resources for humans, we need to acknowledge that they are even worse for machines. But what should we replace them with? Without fingertips or a face, Touch ID and Face ID are non-starters.
I believe the answer is short-lived, cryptographically secure certificates. Every machine and every microservice running on it must receive a certificate and use it to communicate with others.
A certificate is superior to other forms of authentication and authorization in multiple ways.
First, it contains metadata about the identity of its owner. This allows production machines to assume a different identity from the staging or testing fleet. A certificate allows for highly granular access, so the “blast radius” from a compromised microservice will be limited only to resources accessible to that microservice. Certificates also expire automatically, so the loss of a certificate will limit the exposure even further.
Certificates are not new. They adhere to the open standard called X.509 and are already widely used to protect you when you visit sites like this one. The little lock in the address bar of your browser is the result of a Certificate Authority confirming that the website is encrypting traffic and has a valid SSL/TLS certificate. The certificate prevents a phony website from impersonating a legit one. Let’s Encrypt is the most popular way to generate these certificates for websites and is currently used by over 260 million websites worldwide.
We need to adopt certificates for all forms of machine-to-machine communications. Like Let’s Encrypt, this system should be open-source so anyone can use it regardless of ability to pay. It should be trivial to request, distribute, and renew certificates that uniquely identify a machine.
If all machines have an identity, organizations can manage access to infrastructure with one passwordless system that treats people and machines the same way. This simplicity is not only more secure since complexity is the most common cause of insecurity, but it also dramatically simplifies implementation. For example, companies already have rules that prevent an intern from being able to access root on a production server. Now, they can have a rule that dictates that a CI/CD bot should not be able to login to a production database. Both users can be authenticated with the same technique (short-lived certificates), authorized using the same catalog of roles, and audited with the same logging and monitoring solutions.
Making the world a safer place
The joy of being a human is increasingly mediated by machines. Maybe you are singing happy birthday via Zoom to a distant relative, or opening a college savings account for a grandchild. None of this is possible without a vast fleet of servers spread across the world. We all deserve to know that the machines making up this network have an identity, and that their identity is used to explicitly authorize and audit their actions. By moving machine identity out of the shadows, the world will be a safer place.