On Tue, Mar 14, 2017 at 12:32:10PM -0700, Russ Allbery wrote:
> "Henry B (Hank) Hotz, CISSP" <hbh...@oxy.edu> writes:
> > Shut down all daemons on the master.
> > hprop --decrypt --stdout | hpropd --stdin
> > Restart all daemons.
> You probably also want to shut down incremental propagation while you do
> this.  I think this should force a full resync when the slaves reconnect,
> but it would be a good idea to thoroughly test the replication behavior in
> a test realm before doing this in a production realm.  I forget how it
> deals with a complete database reload; I think it's supposed to do
> something sane, but that would be the component that I would worry about.

Good point, but actually restarting the daemons does not force a full
resync.  You have to remove the iprop log file (on the master and/or the
slaves -- either works) to force a full resync.

> Note that you will need to manually copy the new master key to the slaves
> before they'll be able to replicate.  Also don't forget to keep the old
> master key around for the length of your backup retention so that you
> don't invalidate your backups.

If you're not storing the master key on a different disk anyways, and
maybe even if you are, I would recommend just not encrypting the HDB at
all.  As with MIT, only the principals' keys are encrypted, which leaves
you subject to cut-n-paste attacks by, e.g., your backups operator.

You should separately encrypt the backups/dumps.

Even if we could put the master key in a hardware token, that would not
be sufficient to make the keys that much more secure.

The only case that KDB/HDB encryption gets you more security is where
it's easier to steal the disks than the whole system, and you either
store the master key on a disk that's inside the system or you type it
in when the daemons start.  With modern kit that's just not the case, so
you might as well not encrypt the KDB/HDB.  (MIT doesn't give you the
option; Heimdal does.)


Reply via email to