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
|
