True, those pages don't mention a tape library. In this document on the
TS3500 Tape Library:
http://publib.boulder.ibm.com/infocenter/ts3500tl/v1r0/index.jsp?topic=%2Fcom.ibm.storage.ts3500.doc%2Fipg_3584_managing_encrypt.html
It says:
Planning for application-managed encryption
This topic explains application-managed encryption (AME).
This method is best where operating environments run an application already
capable of generating and managing encryption policies and keys, such as
Tivoli® Storage Manager (TSM). Policies specifying when encryption is to be
used are defined through the application interface. The policies and keys
pass through the data path between the application layer and the encrypting
tape drives. Encryption is the result of interaction between the
application and the encryption-enabled tape drive, and does not require any
changes to the system and library layers. Because the application manages
the encryption keys, data volumes written and encrypted using the
application-managed encryption method can only be read by the same software
application that wrote them.
A key manager *is not required by, or used by, application-managed tape
encryption*.
On Wed, Apr 10, 2013 at 2:04 PM, Alex Paschal <apaschal5 AT frontier DOT
com>wrote:
> That's odd. On page 23 it didn't mention anything about a robot being
> in the AME workflow. Might it be on another page?
>
> In the Redbook, AME is on pages 34-37. There is no mention of the
> library itself being in the data key workflow.
>
> I don't know what to tell you about the conflict. All I can do is to
> give you my citations. Please let us know if you find some way to
> answer the question.
>
> On 4/10/2013 7:23 AM, Zoltan Forray wrote:
>
>> *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<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>
>>> <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>
>>>>> <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>
>>>> <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
|
