Re: What the . . . ?
Ah yes, the unfeasible academic dream of PKI data backups.
Take a relatively trivial relational database with 500,000 records of individuals in it.
Each record identifies an individual therefore we must have a system that manages 500,000 encryption keys. Each key must be related to a single specific individual and wholly identifiable to this individual and no other, therefore these keys are now also considered personally identifiable data. These keys must also be backed up because, if these keys are lost, any backups using these keys may as well be random noise in a data file. These key database backups must be retained, kept offline and managed just like mainstream data. Choosing to delete a key means that this key must be deleted from the live dataset and every single backup made of it. Effectively, we now have 500,000 individual backups to manage, which also require a database to manage these backups... which must also be backed up, because losing this will lose the database that manages the keys which means the core backups are worthless. This kind of scheme is possible, within ridiculous margins of possible course, but most snake-oil salesmen conveniently forget this side of it. In essense, all that's happened is that the pain point has been moved.
That's the key management side of it. We also have to deal with the data itself. There are a couple of broad options here:
1) Every single row of data relating to an individual is encrypted in the database, with the key being recorded in the separate key database (backed up separately, see above). Needless to say database performance at this point is something that happens to other people, as no useful indexes are possible and therefore the data may as well not be in a database. This includes searches therefore we have a database relating to 500,000 individuals which to many intents is unsearchable. This means no corporate statistics nor "big data" nor anything like this. Basic business processes will also be glacial against this database. This is usually the option touted as "data at rest".
2) The database is operated normally, but never, ever backed up. Ever. At all. Instead we have a nightly (or whatever) export of the database which converts the relational structure into a file or set of files for every discrete individual in the database where all data relating to each individual is exported into an export structure and encrypted using the key in the key database. This also requires that a re-import process exists which is thoroughly and regularly tested, particularly with version management of the using application and database structures taken into account. This is the closest that a key system can get to encrypting "data at rest" but it does not work around the issue of key management, it's just moving the issue from one place to another. The advantage of this technique is that ancillary files, such as documents, can also be thrown into the same key encrypted repository as long as the export process is smart enough.
A further problem with this is where data relates to more than one individual. For example, Project X references Individual A and Individual B, which key should be used to encrypt this data? A solution would be to have an additional encryption key used for wherever Individual A and Individual B are associated in the same data. Our key database has now become suddenly much more complicated and harder to backup in itself. Removing all keys relating to Individual B should not remove any shared records relating to Individual A as well. While deleting the reference Individual B out of the database would remove the reference it would not remove the data therefore this is not compliant with data protection removal. Deleting all references to Individual B regardless of whether or not any other individuals are associated with the data is not compliant with data protection management because this also mandates the correct management of data. Management policies can be created to help manage this kind of complication.
The point here is that in the real world things rapidly much more complicated than academic dreams of PKI backups or snake oil salesmen will ever admit. In any organisation of any appreciable size there are usually multiple databases and applications, each of which must be managed separately but in the same way. There is no perfect solution.
Biting the hand that feeds IT
