Oh, sorry, rest of the question.  It's easy to convert from AME to LME -
create new library partition, new devclass, set up for LME. Rename some
stgpools and recreate them using the new devclass so you don't have to
modify your daily maintenance scripts or copygroups. Then attrition,
reclamation, or move data scripts.  Pretty much the same way you'd
handle any other media refresh.

I don't think there's anything else you need to do.  With AME, the robot
doesn't talk to TSM for the keys - it's done strictly at the tape drive
level.  TSM requests a tape mount, the robot moves the tape to the
drive, the drive mounts and sends the volser to TSM, TSM looks up the
data key in the db, sends the data key to the drive, the drive uses the
data key to encrypt.  It's described pretty well in the IBM System
Storage Open Systems Tape Encryption Solutions redbook.
http://www.redbooks.ibm.com/abstracts/sg247907.html

On 4/9/2013 9:39 AM, Zoltan Forray wrote:

Well folks, this project keeps changing.  Originally figured we would use
EKM/TKLM but then discussions bought it back to, why not just AME/TSM
handle the encryption - do we need to encrypt the DB?

So, while we are pending a response from the security/auditor folks about
AME being sufficient, the question arose asking "what if we implement AME
and then the power-that-be say it isn't good enough and they want the DB
encrypted as well, forcing us to move to LME"? How much of a pain-in-the..
would that be?  What is the impact?

On the subject of implementing AME, besides saying UPDATE DEVCLASS ..
  DRIVEE=ON and then going to the encryption controls of the 3494/TS3500 and
selecting "Encryption Method - Application Managed" and making sure all the
TS1130 drives have encryption turned - what else do I need to do?  How does
the robot know to talk to TSM for the keys?

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

Zoltan, BTDTGTTS.

You first decide if you want to use TSM-managed or externally-managed
(EKM) encryption.

With TSM encryption, it really is just as simple as creating a devclass
and creating storage pools pointing to that devclass.
(Plus you have to set the encryption mode on the logical library to
application-managed.)

TSM creates its own keys, stores them in the TSM DB, passes the keys to
the drives and tells the drives to encrypt the tapes.
The encryption is still done outboard by the hardware.
Has the wonderful advantage of being simple, free, and unbreakable.
Your hands never touch the keys, it's totally transparent to everybody.
  You can't hurt it.
No implications for DR.  No reason not to use it.
TSM development doesn't get enough credit for making this easy and free.

OTOH, TSM-managed encryption will not encrypt DB backup tapes, or EXPORT
tapes, nor BACKUPSET tapes.

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.

So if you have a requirement for encrypting backupsets, you need the EKM.
   DEVCLASS change does not apply, as TSM knows nothing about the encryption.

If all you have is a requirement that BACKUP DATA on your storage pool
tapes (which isn't included in a DB backup tape) gets encrypted so that if
a tape falls off a truck there is no exposure to PII, choose TSM encryption
and just turn it on.

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 9:41 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Implementing Encryption

I know this sounds strange, but we need to implement encryption on our
TS1130 tapes.

Never having done this, I need some help/suggestions/war-stories/etc on
how to basically turn encryption on.  Is there a quick-and-dirty book on
the subject?

I understand the first thing would be to change the devclass for the tape
drives to "encryption=yes" for ALL of my servers (currently, 2 of 7 are
library managers).

Then I saw something about EKM to manage the keys.  Is this also
implemented on all TSM servers?

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