Here ya go. Buy the BIG bottle of aspirin. http://www.redbooks.ibm.com/abstracts/sg247907.html?Open
And just as a follow up: When you use TSM-managed encryption, it IS hardware based. Either TSM or TKLM, the encryption is done outboard by the drive itself. The difference is who handles the encryption keys/certificates, TSM or the TKLM. And the question of what TSM tapes can be encrypted as a result. W -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: Thursday, April 04, 2013 1:42 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Implementing Encryption I apologize, when I said EKM, I meant TKLM, which is the current product replacement for the old EKM. The only paint-by-number is a redbook for TKLM. Actually there are a couple, and you'll need aspirin. I'll look up the numbers and get back to you. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan Forray Sent: Thursday, April 04, 2013 12:35 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Implementing Encryption Wanda, As always, thanks for the detailed explanation. However, it brings up lots of questions. >>> With externally-managed encryption, the keys are managed by the EKM. Since this would be hardware-based and encrypts everything, this is the way we would go. >>> You set the encryption mode on the library to library-managed. The >>> EKM has to be run on a server. It is a pay-for product. Huh? I downloaded EKM from the IBM FTP sight. It is Java based and nobody ever said anything about paying for it? As I understand it, in this scenario with our 3494 (soon to be replace with a TS3500/3584), the "EKM server" has to talk to the tape library to get the keys from it (DRIVEE=ALLOW). When Googling, one doc/comment we saw the person simply installed it on the TSM server. My question, since I am running 7-servers, do I need multiple instance - one per TSM server or just one and it gets everything from the 3494? I am confused...... >>> High learning curve. Lots of testing required to make sure you can recover. Agreed. We are still digging through the docs on just installing and implementing EKM and who connects to who and where...... >>> You have to be careful about protecting the EKM; you have to recover the EKM at a DR site before you can read your tapes. (If you have a hot site, better to share the keys between the libraries.) More like a "lukewarm sight" - I have an offsite vault/TSM server where the tapes are stored and daily each production TSM server does a DB backup to the offsite TSM server. >>> But with the EKM, your security group can control the key >>> management, certificate changing, etc. And then DB backup tapes, EXPORT, and BACKUPSET tapes can be encrypted. This totally throws me off - I really need a "paint by numbers" diagram on how all the pieces connect - I have never dealt with encryption..... On Thu, Apr 4, 2013 at 12:10 PM, Prather, Wanda <wanda.prat...@icfi.com>wrote: > With externally-managed encryption, the keys are managed by the EKM. > TSM doesn't' know it's happening. > You set the encryption mode on the library to library-managed. > The EKM has to be run on a server. It is a pay-for product. > But the cost of the software is trivial compared to the implementation > cost. > High learning curve. Lots of testing required to make sure you can > recover. > > You have to be careful about protecting the EKM; you have to recover > the EKM at a DR site before you can read your tapes. > (If you have a hot site, better to share the keys between the > libraries.) It is possible (not likely, but possible) to get yourself > in a DR situation where NOBODY, including IBM, can read those encrypted tapes. > Test, test, CYA, test. > But with the EKM, your security group can control the key management, > certificate changing, etc. > And then DB backup tapes, EXPORT, and BACKUPSET tapes can be encrypted. > -- *Zoltan Forray* TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
