ADSM-L

Re: [ADSM-L] Implementing Encryption

2013-04-04 18:55:01
Subject: Re: [ADSM-L] Implementing Encryption
From: "Prather, Wanda" <Wanda.Prather AT ICFI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 4 Apr 2013 22:53:08 +0000
Correct. 
Anything that has to be readable without accessing a live TSM DB, can't be 
encrypted with TSM, ergo backupsets, exports, DB backups.

And I don't know of any other reason not to choose TSM/App managed encryption.
It's transparent, easy, free, and I've never run into any problems with it.

The tape internal label isn't encrypted, so there isn't even a problem if you 
have encrypted tapes in one pool and they go back to scratch and get used later 
in an un-encrypted pool.
Set it and forget it.  (But don't forget you have to turn on encryption in the 
TS3500 library partition first.)

W

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Zoltan Forray
Sent: Thursday, April 04, 2013 2:08 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Implementing Encryption

Thanks.

Other than the factor that certain tapes/processes are not encrypted (from the 
book when setting DRIVEE=ON - *Other types of volumes-for example, backup sets, 
export volumes, and database backup volumes-will not be
encrypted.*)

is there any reason not to choose "Application Managed Encryption"?  As I think 
I understand it, with AME/TSM managing the keys, they are stored on the DB 
backup tape, thus the reason to not encrypt it?  Correct?

On Thu, Apr 4, 2013 at 1:55 PM, Prather, Wanda <Wanda.Prather AT icfi DOT 
com>wrote:

> 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 AT VM.MARIST DOT EDU] On Behalf 
> Of Prather, Wanda
> Sent: Thursday, April 04, 2013 1:42 PM
> To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On Behalf 
> Of Zoltan Forray
> Sent: Thursday, April 04, 2013 12:35 PM
> To: ADSM-L AT VM.MARIST DOT 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.Prather AT icfi DOT 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
> zforray AT vcu DOT 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
>



--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT 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