>>> *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 <apasch...@frontier.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.prat...@icfi.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@VM.MARIST.EDU] On Behalf Of >>> Zoltan Forray >>> Sent: Thursday, April 04, 2013 9:41 AM >>> To: ADSM-L@VM.MARIST.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 >>> zfor...@vcu.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 >> zfor...@vcu.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 zfor...@vcu.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
