>>> *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. *
You are the second person to make such a comment when documentation I have
found says exactly the opposite. With AME, the TSM server managing the
robot acts as the EKM. The drive requests the key from the robot/ATL when
since it was told is using AME passed the request to the TSM server which
in turn generates the key and passes it back to the ATL/drive. From this
doc (yes I know it is old but a newer document sent to me says the same
thing):
http://tsm-symposium.oucs.ox.ac.uk/2007/papers/Christina%20Coutts%20-%20Tape%20Drive%20Encryption.pdf
on page 23, it states:
*TSM Application Managed Encryption (AME)*
TSM generates encrypts and stores the key in the DB with other meta data
- Provides interface to key services
- Associates correct key with file
On Tue, Apr 9, 2013 at 6:03 PM, Alex Paschal <apaschal5 AT frontier DOT com>
wrote:
> 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<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<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<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
|
