Inclusive WP KMS
A key management system for WordPress built for Inclusive Digital: a plugin that encrypts personal data, and a Laravel service on separate infrastructure that holds the keys.
Built at Inclusive Digital as something to reuse across their clients: a way of holding personal data in WordPress without holding it in the clear. Two applications, a plugin and a key service, deliberately on two different machines.
The thing being defended against
WordPress is the most attacked application on the web, and the usual shape of a bad day is not somebody reading your code: it is a database dump. Backups end up somewhere they should not, a plugin has a hole, credentials leak. The attacker walks away with a copy of the tables.
That is the event this is built for. Not a determined adversary picking a specific target, but the ordinary case where a copy of the database ends up somewhere it should not be. If the personal data in that copy is readable, it is a breach. If it is ciphertext and the keys were never on that machine, it is a file of noise.
A plugin and a service, on purpose
The WordPress half is a plugin, because that is where the data is entered, read and displayed. It encrypts personal data before it ever reaches the database, so what WordPress stores is already unreadable.
The other half is the key management service, a Laravel application on a different server. It holds the decryption keys and hands them out. WordPress never stores a key it could be robbed of, which is the entire point: the machine facing the public and the machine holding the keys are not the same machine.
The two stacks are not an accident either. The service has no business being a WordPress plugin. It is not a website, it guards keys, and the less it has in common with the exposed machine, the better it does that job: fewer plugins, fewer themes, fewer reasons for anybody to be there at all.
What it costs
Encrypted columns stop being columns you can work with. You cannot sort on them, you cannot search them with a LIKE, and a report that groups by one of them has to be built some other way. This is the real trade of encrypting at rest inside an application, and it is worth saying out loud rather than discovering it the first time somebody asks for a list ordered by surname.
So it is not applied to everything, only to what is worth the loss: the personal data of real people, on sites where that list existing in the clear is the problem.
Where it ran
It went into production on the site of the Brewers' Company, a City of London livery company chartered in 1438, whose membership is exactly the kind of list that is worth this much trouble.