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
|