Why Self Service?
From working with the world’s leading organizations, we have learned that most mobilize a small team of people, often in security or operations, to provide machine identities to others who need them. These focused teams tend to support a much larger number of people who need identities for machines of all sorts. As a result, there is a pent-up demand for machine identities, which are needed faster than ever before and used more frequently to support applications in the cloud and in other modern architectures.
Removing that machine identity bottleneck represents a critical competitive edge for organizations that face a rapidly evolving marketplace. Giving the team members who need machine identities the ability to procure them via certificate self-service is critical for everyone's success. And that idea is not unique to organizations like Venafi that focus on optimizing machine identity management.
NIST SP1800-16 guidelines also describe a good certificate management platform being one that “provide[s] self-service access for certificate owners, so they are able to configure and operate the services for their areas without requiring significant interaction with the Certificate Services team.”
As much as many of us thrive on personal communications, there are some we would rather avoid, such as answering the same questions on repeat. For most PKI practitioners, questions about requesting, deploying, and renewing certificates fit into this category. If you're a PKI expert, you might feel like you're always helping a new person answer the same question that the last person you spoke with had. (And let’s face it, the same often applies to repeat customers.) If you are a machine owner, it might feel like you are relearning a skill every time you need to do something with an identity—such as a TLS certificate—on your machine.
To further complicate matters, infrastructure and ecosystem applications differ from team to team. Certificate requirements differ based on how and when a network device owner needs a certificate versus the certificate needs of a developer deploying applications with the Istio service mesh in a Kubernetes cluster will vary widely. Neither should be left to their own devices.
Without certificate self-service, machine owners may end up doing their own thing to obtain and deploy certificates. It may be an unfortunate truth that PKI is a poorly understood realm. Underlying this reality is the fact that the show must go on. In particular, expired certificates—that are the product of human error and a lack of oversight—can lead to costly yet avoidable downtime. When machine owners obtain certificates on their own, InfoSec often loses visibility and becomes blind to the risks introduced by unapproved CAs that produce certificates that may fail to adhere to policy. Similarly, machine owners might not track expiration dates or may move to a new role and therefore out of the loop, effectively orphaning certificates. Aside from the risk of an outage caused by expired certificates, there is also a risk of misuse. If certificates don't adhere to corporate policy, there's a greater chance they will become the target of malicious actors looking to gain unauthorized access to the organization’s sensitive data or spawn an outage.
What if you could eliminate certificate outages forever?
How does an effective self-service solution work?
As part of the Venafi Control Plane for Machine Identities, TLS Protect Cloud supports certificate self-service. Certificate self-service in TLS Protect Cloud has two main elements:
Capabilities that enable an administrator to create and enforce policies and tools for machine identity owners.
For example, a TLS Protect Cloud administrator can set up issuing templates so that when the network device owner or Istio developer needs a certificate, they can request one that meets the needs of their machine or application, while complying with corporate security standards.
Easy onboarding of machine identity owners and teams.
This capability allows machine owners to request and manage their own certificate self-service either directly through TLS Protect Cloud or through other enterprise software like an ITSM or programmatically through APIs or orchestration tools like Ansible, Kubernetes, Openstack, Terraform, HashiCorp Vault and others.
No matter how diverse your team might be in their workflows and preferences, they can all be held to consistent policies. Managing teams with TLS Protect Cloud is easy and assigning ownership of certificates to groups of users ensures that,even as your team evolves and changes, certificates are not lost in the shuffle. With full visibility of your certificate inventory, you can further ensure that nothing goes unaccounted for and give time back to your team to focus on more strategic initiatives.
There are many ways to enable self-service, whether through API, ITSM, or requesting and installing directly through Venafi’s UI. Third party certificates are also covered. Custom permissions can be put in place where and when appropriate.
We created this video to walk you through some of the highlights of how Venafi TLS Protect Cloud easily enables certificate self-service.
If you haven’t already begun your journey to certificate self-service, visit TLS Protect Cloud to sign up for a free trial. Otherwise, enjoy the new features!
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related Posts