Enabling tape encryption

JensD

ADSM.ORG Senior Member
Joined
Aug 2, 2005
Messages
82
Reaction score
3
Points
0
Location
Denmark
Website
Visit site
PREDATAR Control23

Hi

I've been looking at setting up data-at-rest encryption all over, and I've come to our backups in TSM (v7.1.6.0) on Linux, and I need some advice or pointers to the right parts of the documentation that have been unable to locate myself.

For everything on disk (random STGPs for incoming data, on-disk STGPs for main storage and later copy to on-tape copy STGPs), I'm going to migrate the individual LVM PVs for all LVs to new LUKS/dm-crypt'ed PVs, so everything should be transparent to TSM.


For all data tape volumes, what are the caveats for just updating my LTO4 library deviceclass to DRIVEEncryption=ON and have TSM manage the keys - will TSM just begin to write encrypted data the next time any STGP data is written?

I cannot find any mention of how I ensure that all existing tapes are repopulated with encrypted data, but I would need that to happen as well - hopefully without having to resort to setting ACCESS=DESTROYDD for all tape volumes to force TSM to rewrite data from the on-disk STGPs, but what are my options here?

Furthermore, I can see that I need to secure a copy of the master encryption key somehow.
In TSM v7.1.8 there was an optimization/improvement mention here: https://www.ibm.com/support/knowledgecenter/en/SSGSG7_7.1.8/srv.common/r_techchg_srv_ekey_718.html, but as I'm currently running v7.1.6, does that mean that I have to back up dsmserv.pwd myself, or can I just run DB backups with options PROTECTKeys=YES and PASSword=<some password> and then just keep the chosen password safe?

I also take it, that when I eventually come around to upgrading to later versions of TSM I either have to secure copies of cert.kdb, dsmkeydb.kdb, cert.sth and dsmkeydb.sth (mentioned in the like above) or just use PROTECTKeys=YES and PASSword=<some password> as with v7.1.6?
 
PREDATAR Control23

Hi

I've been looking at setting up data-at-rest encryption all over, and I've come to our backups in TSM (v7.1.6.0) on Linux, and I need some advice or pointers to the right parts of the documentation that have been unable to locate myself.

For everything on disk (random STGPs for incoming data, on-disk STGPs for main storage and later copy to on-tape copy STGPs), I'm going to migrate the individual LVM PVs for all LVs to new LUKS/dm-crypt'ed PVs, so everything should be transparent to TSM.


For all data tape volumes, what are the caveats for just updating my LTO4 library deviceclass to DRIVEEncryption=ON and have TSM manage the keys - will TSM just begin to write encrypted data the next time any STGP data is written?

I cannot find any mention of how I ensure that all existing tapes are repopulated with encrypted data, but I would need that to happen as well - hopefully without having to resort to setting ACCESS=DESTROYDD for all tape volumes to force TSM to rewrite data from the on-disk STGPs, but what are my options here?

Furthermore, I can see that I need to secure a copy of the master encryption key somehow.
In TSM v7.1.8 there was an optimization/improvement mention here: https://www.ibm.com/support/knowledgecenter/en/SSGSG7_7.1.8/srv.common/r_techchg_srv_ekey_718.html, but as I'm currently running v7.1.6, does that mean that I have to back up dsmserv.pwd myself, or can I just run DB backups with options PROTECTKeys=YES and PASSword=<some password> and then just keep the chosen password safe?

I also take it, that when I eventually come around to upgrading to later versions of TSM I either have to secure copies of cert.kdb, dsmkeydb.kdb, cert.sth and dsmkeydb.sth (mentioned in the like above) or just use PROTECTKeys=YES and PASSword=<some password> as with v7.1.6?

Hopefully you managed to find a way around this but if not, you'll need to do the drive encryption in the device class like you say. Once that is done you should notice when you do a 'q vol <vol name> f=d' that the volume now has a key manager.
To encrypt the older volumes, you'll need to run a move data against each of the unencrypted volumes.

The keys article which you're looking at is if you're utilising client encryption. Turning it on for the drive will mean that the keys will be managed by TSM and will be stored in the internal database. Meaning that the TSM database backup, if done to tape, will not be encrypted, so I would recommend that you back up the database to disk or NAS elsewhere in your environment through a file device class
 
PREDATAR Control23

Hopefully you managed to find a way around this but if not, you'll need to do the drive encryption in the device class like you say. Once that is done you should notice when you do a 'q vol <vol name> f=d' that the volume now has a key manager.
To encrypt the older volumes, you'll need to run a move data against each of the unencrypted volumes.

The keys article which you're looking at is if you're utilising client encryption. Turning it on for the drive will mean that the keys will be managed by TSM and will be stored in the internal database. Meaning that the TSM database backup, if done to tape, will not be encrypted, so I would recommend that you back up the database to disk or NAS elsewhere in your environment through a file device class

Hi, thanks for replying

No, I have not started encrypting the tapes - yet - but it's nice to know that it should "just work" by setting DRIVEEncryption=ON and issuing a few(!) "move data" commands.


Where do you see that the article I linked to related to client encryption?
As far as I can see the link describes a new feature in TSM server v7.1.8 that mentions that the master password will me migrated from dsmserv.pwd to cert.kdb, dsmkeydb.kdb, cert.sth and dsmkeydb.sth and that a master encryption key is automatically generated if it didn't exist before the upgrade.

I'm doing backups of TSMs DB onto tape (using the same deviceclass as the STGP volumes that will be encrypted) as well as onto disk using a FILE deviceclass, but I need to be absolutely sure that the copy written to either FILE or tape can still be accessed if I have dsmserv.pwd (when running TSM < v7.1.8) or cert.kdb, dsmkeydb.kdb, cert.sth and dsmkeydb.sth (when running TSM >= v7.1.8) and the password used to protect the DB backup - kind of what is required in a DR situation, where I have to bootstrap TSM.
 
Top