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