Remove Standing Passwords with AAPM
For as long as it’s been possible, IT has been using and deploying scripts with secrets embedded within them. As DevOps practices have expanded thanks to Agile methodology, this approach has been amplified as a means to facilitate the fast, efficient, and flexible development process demanded by modern business. This easy access of secrets has a downside, however, exposing them not just to DevOps applications but to anyone with a way in, culminating with the integration of DevSecOps – secure DevOps – which pushed back against this approach by rethinking the use and security of secrets.
Many organizations today have secrets saved on the disk, made available to any program that can access the filesystem. The development of worms, intrusion, and, more recently, malware has proven that secrets should not be left lying around. The consequences can be devastating.
Analysts recommend that secrets should be stored in a vault where they can be secured and audited. This vault should be hidden to reduce the network’s attack surface.
But these security measures raise new issues. What about agility? What about legacy applications that have passwords in scripts or in configuration files?
The Application-to-Application Password Management way
Securing access to secrets doesn’t need to sacrifice agility. At WALLIX, we offer a unique Application to Application Password Management (AAPM) solution that secures access to secrets. But where security is truly taken to another level is that we base security not only on an initial seal that secures the capacity to provide secrets from a vault, but also on the integrity of the password-consuming application and the user or group launching the application based on the policy.
This approach allows us to make a three-factor authentication:
- The host is identified and authorized from vault credentials,
- The application is verified based on a complex hash mechanism
- The caller, either a user or a user from a group, is identified
Once established, these parameters of trust enable simplified security, preventing unattended modification and use of credentials. As long as these three factors remain true, there’s no need to log in each time to retrieve the most recent password.
The Forgotten Problem
A classic case of security risk in DevOps is that of an application that requires a password in a configuration file, such as the backend database password. It must be provided upon starting the process which will then connect to the database. Additionally, whenever the password changes, it may require a restart of one or several services.
A common example is WordPress, a popular content management system (CMS) that requires a web server, such as Apache, and a database, let’s say MySQL for web publishing.
If the MySQL database password changes, through the service account policy, the database is reloaded. But at the same time, the Apache needs to be restarted so WordPress will reload its configuration file holding the database password.
Platforms like CMS and other tools require continuous support in order to keep up with constant evolutions. And these code modifications must be managed seamlessly, to avoid disrupting productivity with constant changes.
At WALLIX, we have taken the approach of intercepting the call to the configuration file and replacing tags with the password value on the fly when the program reads the file. Thus, the password is never visible on the filesystem.
The PasswordFS feature, part of the WALLIX AAPM solution, can intercept the reading of the configuration file, get it from the AAPM layer, and inject the password freshly grabbed from the Vault where it has been securely stored so that WordPress can start seamlessly and connect to its database.
How is it done? Simply replace the password in the file with a placeholder. It’s as simple as that.
Through our unique approach to application-to-application password management, even in agile and rapid DevOps processes, passwords are never saved on the filesystem. Security and agility are saved.