Cloud native development and multicloud infrastructures has led to proliferation and decentralization of secrets. If left to their own devices, these secrets can sprawl over time, leading to data breaches and privacy concerns.
A DISPARATE SET OF TOOLS
DevOps teams uses multiple tools for different phases of the development process. Centralized system that can integrate with all these tools and systems is a rarity. Cloudnative secrets management tools are limited to the specific cloud provider and fail under a multi-cloud scenario.
DEVOPS BLIND SPOTS
Most enterprises are unaware of where their secrets are located, access level or whether the secrets have been changed. This lack of understanding of the functioning of the DevOps pipeline often increases the risk of an internal data breach.
Fortanix provides a single centralized platform to securely store, control and manage secrets outside the source code in a FIPS 140-2 level 3 certified HSM. With flexible deployment modes and scalable architecture, Fortanix secret management works across environments, on-premises, natively in the cloud, hybrid and multicloud. Integrates with any DevOps environment with Rest APIs.
Secrets — typically sensitive credentials or encryption keys — have proved increasingly dangerous in DevSecOps environments, although the challenge is hardly new. Developers have always routinely hardcoded passwords and other types of credentials in scripts and programs. More-enlightened organizations might move the credential to a configuration file or a metadata service — helping somewhat, but still typically leaving the credential in plaintext in a location readily accessible to malicious users.
How the solution works?
Fortanix Data Security Manager provides a very simple and intuitive GUI for all users, regardless of their role. Secrets “belong” to Groups. Each secret stored in Data Security Manager is associated with its creator and is stored in a specific Group. Only the user(s) associated with that group have access to the secret, according to their role/privileges, which may be further controlled by means of a quorum approval policy. It is easy to inspect (through the GUI or REST API) who is the creator of a secret and which other users are in the Group (and their roles). Additional users can be added to the Group (thereby gaining access to the secrets therein) at any time. Groups in Data Security Manager can be mapped to external AD groups via an external role mapping feature that further allows applying AD group based RBAC.