Static IDs and passwords have been around for decades, and for all the talk about getting rid of them, big pockets remain. Sure, for human login to systems and applications, we’re making some headway with multi-factor authentication (MFA) usage growing in adoption. However, enrolling second factors for use in MFA itself requires user authentication—with an ID and password!
Governments and related high-security agencies are perhaps the only entities to up that game with in-person enrollment.
The reality is that MFA is for humans. It doesn’t work for headless activities—non-human interactions where applications and services access other applications and services.
IT Operations Management (ITOM) is a good example. Perhaps you consume ITOM services (for example, ServiceNow® Discovery) to provide the tools you need to manage your IT infrastructure. Many of these ITOM tools need privileged IDs and passwords to log into IT systems to do their jobs, such as asset discovery, orchestration, and vulnerability scanning apps.
Another example is DevOps, where applications and services need credentials to authenticate to other apps and services.
Cyber adversaries are aware of this and are increasing their efforts to target such systems. Just like DevOps, they too strive for speed, agility, and automation. They deploy autonomous bots to seek out and harvest privileged credentials, enabling the bots to masquerade as legitimate “users” to progress their attacks.
This blog focuses on the DevOps challenges inherent with the continual use of IDs, passwords, and service accounts for application and machine identity, authentication, and authorization, and an effective alternative. The main objective is to remove authentication and authorization friction for DevOps, which remains a considerable inhibitor for accepting IAM into their workday.
It seems obvious, but a best practice to minimize your exposure is to take static IDs and passwords out of the equation. Ideally, delete them, or if you can’t, store them in a password vault and strictly govern and control access.
This alone is a massive win by reducing your attack surface. Application code can call an API to retrieve passwords. Any bots trawling through files for credentials are simply out of luck. However, you still have to manage those passwords, rotate them, discourage them, and avoid sharing, and at the end of the day, they’re persistent and still weak.
If you’re tired of the security team pointing fingers at DevOps for exposing the organization to risk by relying on IDs and passwords, ephemeral tokens are a worthy consideration. Tokens, such as OAuth, have way more benefits:
Replacing passwords and even API keys with OAuth sounds perfectly nice, but there’s a reason why OAuth hasn’t seen stronger adoption. OAuth can be tricky for DevOps to implement, requiring yet another service account ID and secret for each application. And how does the application protect that secret?
With its OAuth provider and Delegated Machine Credentials (DMC) technologies, Delinea has cracked that nut. Let’s look at three main ways Delinea’s Privileged Access Service vault plus DMC helps.
Let’s first address those privileged credentials you can’t delete. You can protect and manage them inside the Delinea Privileged Access Service vault. In a perfect world, nobody should ever touch them. For emergencies, though, strictly control who can check them out and audit that activity. Further, enforce just-in-time access via workflow-based request and approval; time-box that access to prevent reuse; and, after use, rotate the passwords automatically, making them complicated and difficult to crack.
Vaults, in general, are not revolving doors allowing anyone or anything to access secrets, credentials, or tokens. Just like a user, your apps must also authenticate to the vault.
Traditionally, this has been a substantial manual undertaking. For each application, register an API account and password with the vault, configure roles and policies to constrain what they can access, create OAuth client code, and embed that client and a Secret in each application. Multiply that by the number of apps and services. With a new service account per application, your attack surface just exploded.
Then there’s the issue of how to store and protect that service account and password. In code? In a config file?
Alternatively, the Delinea Client establishes a trust relationship between the machine and the Delinea Platform, creates an OAuth Client in the vault, obtains a service account and an OAuth Secret (a DMC), and configures the OAuth Client with API scopes for the applications that run on the system. It does this automatically via a single enrollment command.
Your application can now ask the Delinea Client to log into the vault on its behalf (using DMC) and obtain a scoped bearer token granting access to specific vault API endpoints. The application can then make an HTTP request to the vault, with the bearer token in the Authorization header. Alternatively, it can issue commands to the Delinea CLI to do the same. The machine’s credential is never exposed to your application.
Either way, the developer doesn’t need to know how OAuth works – Delinea handles that complexity. No hard-coded secrets, passwords, or API keys in code or config files. Having a single service account per machine instead of per application dramatically reduces your attack surface.
To play nicely within your CI/CD pipeline, all of this can be automated – installing the Delinea Client, enrolling the machine, installing the Delinea CLI, configuring application OAuth scopes, creating the OAuth Client, etc.
DMC, coupled with ephemeral tokens, is a game-changer that avoids finger-pointing and risk exposure.
For more information, please check out the following blog articles:
ServiceNow® is a registered trademark of ServiceNow, Inc., in the United States and/or other countries. All other trademarks are property of their respective owners.