For a system with sensitive information stored in a PostgreSQL 9.5 database, in which data stored in a table that is deleted must be securely deleted (like
shred does to files), and where the system is persistent even though a particular data set won't be, I'm trying to figure out my options for securely deleting the underlying data files when a table is dropped.
As background, I'm not a DBA, but I am an experienced implementor in many languages, contexts, and databases. I've looked and haven't been able to find a way to ask PostgreSQL to do the equivalent of
shredding its underlying files before releasing them to the OS when a table is
DROPped. Is there a built-in way to ask PostgreSQL to do this? (I might just not have searched for the right thing - my apologies if I missed something and I'll gladly accept abuse along with links to relevant documentation)
A partial answer we're looking at is shredding the underlying data files for a given relation and its indexes manually before dropping the tables, but this isn't so elegant, and I'm not sure it is getting all the information from the tables that we need to delete.
We also are looking at strategies for shredding free space on our data disk - either running a utility to do that, or periodically replicating the data volume, swapping in the results of the copy, then shredding the entire volume that was the source so its "free" space is securely overwritten in the process.
Are we missing something? Are there other options we haven't found? If we have to clean up manually, are there other places we need to go to shred data than the relation files for a given table, and all its related indexes, in the database's folder? Any help or advice will be greatly appreciated.