ADSM-L

Re: [ADSM-L] Implementing Encryption

2013-04-05 09:33:04
Subject: Re: [ADSM-L] Implementing Encryption
From: Zoltan Forray <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 5 Apr 2013 09:30:36 -0400
Unfortunately, after discussing the choices with management, they decided
to choose LME vs AME.  So they want me to setup a Linux VM running  EKM
(onsite), as well as the EMK function on my offsite TSM server -
fun...fun....fun....  I know the 3494 config allows for a primary and
secondary EKM and assume the TS3500 allows for at least this minimum config.

At least they agree to wait until after the TS3500 is installed before
implementing.

Time to dig into the EKM docs for setting things up.  I saw in the 3494 LM
setup I need TCP/IP ports 3801 (default) opened. Not sure about the other
values like "Key Label Entry" and "Key Label"

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

> 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
>



--
*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