I am currently evaluating solutions to make deployment and configuration of my on premise software more secure. I am mostly concerned about spring boot java backend applications and the content of the application.properties. While I was watching videos and reading articles / tutorials regarding Vault I had the following question.
Does Vault prevent intruders with access to the app deployment server via SSH from gaining information about database credentials if I store them in Vault? I am wondering because if I use Vault, db username and password would be stored in it. But I still have to provide some sort of token so the application is able to receive its configurations / credentials from the Vault server don`t I?
If I have to store the vault access token in the application.properties file than could the intruder no just take said token and extract the database credentials from Vault via HTTP requests? For the application to be able to access its data inside Vault, the Vault has to be unsealed so the intruder wont even need the 3 tokens to unseal it first doesnt he?
It is completely possible that I missunderstood something so please if you notice anything feel free to correct me. I am also thankful for any advice regarding best practices on how to use Vault in order to store credentials for backend services securely to prevent compromise of the database if the application server gets compromised.
You are correct. If an intruder can access the Vault credentials such that it can imitate the application it would be able to access any secrets from Vault that the application itself is able to access. General security practices can be used to minimise the likelihood of such issues - such as ensuring the application runs at its own user, and any configuration files, etc. are only accessible by the application.
If an intruder is able to compromise a privileged account (e.g. root) many of those security controls could be bypassed. At that level of privilege it is usually also possible to inspect the application’s memory, which could also allow direct access to secrets without needing to connect to Vault.
Reactive mechanisms should ideally be used in concert with other security controls, to record audit records on Vault and other servers, with the ability to automatically flag unusual patterns of behaviour. For example if a server starts sending requests to Vault at a much higher rate to normal that could indicate a compromise.
All secrets are managed the same way, with controls around where they can be used, and records around when they are used.
The ability to use “dynamic” credentials, to allow short lived & granular access to things like databases - where traditionally you’d have been sharing broad logins across multiple applications.
Ability to do things differently with things like encryption as a service
While no system can prevent certain classes of attack - for example if you are able to make a call to Vault from the same location it would have legitimately come from, using the same credentials (because say you stole them from the real application) there is no way to determine the difference between you and the legitimate application - it can give you more abilities to detect issues as well as mitigate them.
For example if you detect that a certain token is encountering lots of permission denied errors, using a token that should be for one of your key apps, that could indicate a compromise - a person could be trying to download lots of secrets (and failing) that the real app would never try to access at all (as it had no need to). You could then investigate further and remove that attacker.
With regards to break in resolution take the case of a database credential being compromised. With the model of static broad ranging database secrets you are in a very difficult place. Revoking the secret would cause many apps to stop working, possibly for some time as you worked to update them all with the new secret. Instead using Vault with dynamic database secrets you could revoke access from the specific compromised application without impacting other users, while also making it easier to have much tighter permissions too.