Can't figure out how to protect Vault hack

Background

Very very new to Vault and the concepts behind it - but trying to figure out how best to protect Vault from being hacked by someone gaining physical access to a client utilising Vault.

Scenario

Client app sitting on host on client’s network contacting public facing Vault
IP of client’s public IP could change
IP could be spoofed by bad actor

Confusion!

If the client app uses either token or even TLS certs to authorise against Vault, someone with physical access can get hold of the token or cert files and then use them from somewhere else (CIDR restrictions not really useful due to spoofing and/or client public IP changing outside of our control).

Solution?

Is there a solution to this? I.E. someway that you can protect against physical access to the client?

1 Like

Hi @dcgsteve, welcome to the community. I’d recommend checking out the security model in our docs for some detailed discussion on this topic.

I think what you’re getting at is closely related to “secure introduction”, and the level of protection you require will depend on your threat model. Vault has a fairly wide selection of auth methods, and some of them allow single-use secrets such as AppRole, and Vault Enterprise has support for MFA, but in general I think physical access to the client is quite a difficult scenario to defend against because auth methods rely on possessing some initial secret material that they can exchange with Vault to prove their identity. If an attacker has that same secret material, then they can spoof the real client.

Finally, it’s worth mentioning an incomplete set of defence in depth layers you may also want to consider:

  • Restrictive ACL policies to limit blast radius of breaches
  • Dynamic secrets where possible to limit duration of breaches
  • Audit logging to enable alerting and retrospective action
1 Like

Thanks for info @tomhjp - am working slowly through docs :slight_smile:

The slight difficulty is that the app is in theory processing requests every few seconds, possibly more often - so I need to weigh security against performance (as the Vault is remote). Fun fun!

Ok - managed to confirm that if someone manages to get on to the physical machine with privileged access then we are no longer responsible for the outcome … although obviously we will try and obscure information as much as possible :slight_smile:

Many companies rely on keys/codes for security. This practice is expensive; prone to cyberattacks; hard to maintain: It’s a big hassle for the users.​

This year alone $2B US is spent on the abuse of mismanagement of pass phrases as well as public and private key. – We are going a different direction here.​

We focus on, on-demand keyless end-to-end encryption for timeless security by reducing the steps needed for the keycode systems.​

This accelerates business velocity and best user experience.​ ​

Our flagship LokDon ECSMID V1.0.0 + SDK could be found In your favorite marketplaces including the cloud:​

LokDon ECSMID V 1.0.0 SDK​ AWS Marketplace Link​

LokDon ECSMID V 1.0.0 SDK​ Docker hub Link​ ​ ​

Quick start guide​ AWS image​ LokDon ECSMID V 1.0.0

Quick start guide​ Docker images​ LokDon ECSMID V 1.0.0

With our proprietary solution Harshicorp could build:

  1. Wallets that do not expose key(pub/priv) except for when needed.

  2. Wallets that dont move, store, reuse and manage seed phrases.

There many other use cases.