Securing TSM DB Backups when using TSM to manage encryption keys

willidh

Active Newcomer
Joined
Nov 16, 2004
Messages
6
Reaction score
0
Points
0
PREDATAR Control23

Hi All

We are designing a TSM implementation where the tape library will be TS3500 with LTO5 drives. There will be several TSM servers and we want to keep them separate securely.
We have been discussing the tape encryption key management methods: TKLM and using the TSM DB.

We'd prefer to use the TSM DB but have hit the issue of the TSB DB backups not being encrypted.

Ejecting the TSM DB backups and putting them somewhere really safe seems counter-intuitive. And just keeping them in the library won't work either.

One idea that was suggested was not to backup the TSM DB to tape but to backup to disk. Has anyone done this securely? If so, what did you do?

And are there any other ideas on how to secure TSM DB backups so that the crown jewels aren't easily accessible?

Cheers

Danny
 
PREDATAR Control23

I would answer your question with a question:

What do you think will happen if someone got hold of your TSM DB backup WITHOUT getting hold of your backup tapes?

Sure they could restore it but that is all that they can do without THE REAL BACKUP TAPES. All that is inside the TSM DB tapes is meta-data - pointers to where the files are located; no real data exist in those tapes.

As to your question about backing up to disk, sure you can do this. You could do SAN to SAN replication for offsite safe keeping. However, just be aware that you will need to keep quite a number of copies and this translates to disk space.

For my two cents, I am just fine storing to tape and moving the tape to offsite for safekeeping plus maintaining two copies, or three if you are really paranoid
 
PREDATAR Control23

And here's my 2 cents: if security is that big of an issue, encryption should belong to the security team, not the backup team. Get a proper key encryption infrastructure in place.
 
PREDATAR Control23

We do not encrypt our TSM DB. We store a single copy offsite on tape, disk, or VTL depending on the storage attached to the instance doing the backup.

Our sites are connected via private fibre so our tapes never leave our data center or the library for that matter. Therefore I see no reason to encrypt the TSM DB.

That being said.... data that requires encrytion gets it at the application layer. Example: SQL LiteSpeed DB dump files are encrypted on disk and backed up encrypted to TSM. TSM should not be responsible for the securing of business data.
 
PREDATAR Control23

Thanks for all your replies.

moon-buddy - good point about the TSM DB - it is certainly of no use on its own.
DanGiles - the security people are involved - we are trying to balance a variety of requirements (see below)
Jeff_Jeske - do you use drive encryption or just at the application layer?

So - a little more about what we're designing:

There will be several TSM servers using the tape library. The library will be split into logical libraries. The idea is that each logical library will be for a separate organisation Within an organisation there may be departments that want additional separation - if so then they will get their own TSM server.

The reason why we have selected TSM to manage the encryption keys is so that we can guarantee that one TSM server can not restore another TSM server's data. I appreciate that this is unlikely - the TSM servers will be on separate VLANs - apart from a shared management VLAN. If we were using TKLM then each TSM server would need a dedicated logical library - and that's quite an inefficient use of tape drives.

So what we need to demonstrate is that one TSM server can't restore another TSM server's tapes. The first part of a restore would be to restore the TSM DB backup. Therefore we'd like the TSM DB backup to be more secure if possible.

It could be that what I'm asking for is bonkers. If so then I'd be glad to understand your thinking. There could be a totally different approach that is far more workable.

Danny
 
PREDATAR Control23

Danny,

We only use application layer encryption.

What seems odd here is TSM ownership seems to be distributed to different groups within the organization. Its almost as if you are a library provided for 7 different companies.

Most companies have a DR team responsible for the entire organization as one big happy family. Only TSM admins would have access to all of the data.
 
PREDATAR Control23

Hi Jeff_Jeske

TSM ownership will be most definitely centralised. However the systems being backed-up are distributed. For various reasons we need to ensure the data is securely separated when it's backed-up. And part of this is about demonstrating the separation to people who don't understand TSM.

Danny
 
PREDATAR Control23

Hi

My 2 cents....

"There will be several TSM servers using the tape library. The library will be split into logical libraries. The idea is that each logical library will be for a separate organisation Within an organisation there may be departments that want additional separation - if so then they will get their own TSM server."

This just seems to be overcomplicating things. Can you not just use seperate policy domains for each organisation. If they then want further seperation that can be done by mgmtclasses and collocation groups.

Out of interest how much data are you looking at managing here?

Cheers
 
PREDATAR Control23

Hi ilovetsm

Yes it does sound complicated - and we will certainly be using policy domains etc. to provide separation within TSM.

Each TSM server could be managing 100TB of data to be backed-up (i.e. lots more in the storage pool once you account for # versions)

Danny
 
PREDATAR Control23

Danny,

I'm having a hard time wrapping my head around the actual request. Is it that your customers don't want their data to share library media? I find it odd that they would be ok with sharing a physical library and possibly a TSM server and having the same admins manage it all but then be concerned about the media. I bet you could solve this entire situation by calling a meeting, sitting down with the customer and explaining to them how it works.

Sometimes we need to explain to them what they really need and gently guide them away from what they think they need.

To me it sounds like this your architecture shouldn't be any different than anyone elses. A couple TSM server backing up all nodes to a shared library. Turning on encryption is an option but there is no reason to have a special key for each organization. I do think you could use a collocation group to separate the business function on the back end but it doens't really provide any value.
 
PREDATAR Control23

Hi Jeff

Sorry I'm not being as clear as I could be.
The organisations are fine sharing a library but want to ensure their data is kept separate - for good reason. Hence the separate keys for tape encryption and network separation for the TSM servers.

They are entirely open to us proposing the right solution. At the moment it looks like what we have proposed is as good as it'll get. Unless anyone has any other ideas?

Danny
 
PREDATAR Control23

I can't envision a need to do that type of separation but so be it.

When using TSM as the key manager it will not encrypt DB, export or backupset volumes. Thus simple-ish type suggestions using tape is out. The only way you can get to a point where you can use tape encryption of the DBB is if each group had their own physical library and their own external key manager.

That leaves you with putting your DBB to a file devclass.

With the data on disk you can then encrypt the files using SW or HW appliance and replicate to an off-site location. You will need to track individual encryption keys somehow and have them readily at hand in the event of a DR. I would assume each group will insist on a different key.

If you don't have a way to replicate the DBB off-site then you are vulnerable to disaster.

This of course ignores the fact that the same group of people will be managing all of the servers and would likely have the skills required to circumvent any additional precautions.

An easier approach could be to totally ignore the DB encryption question and simply send off all of the DBB tapes using a different vendor and transport to a different vault location. The DBB tapes alone are worthless to anyone and the encrypted tapes without the DBB are also useless.

Any attempts at theft or collusion would require a much more complicated caper worthy of Hollywood.
 
PREDATAR Control23

What is the reason their data must be separate from everyone else's?

They don't use a separate LAN, SAN, or WAN do they?

Most companies have pensions, claims, financials, privacy act data, and everythign else all going to the same place.
 
PREDATAR Control23

rmazzon

Thanks for your thoughts.
It looks like ejecting the DBB and taking it off-site to a location separate to the backup data is the simplest and lowest risk option.

Jeff_Jeske

There is good reason for the separation. In the old world each would have had their own backup & recovery solution. We are trying to introduce some central services to reduce costs. Each environment will have a separate SAN, LAN and WAN. We will install a dedicated Backup LAN and Backup SAN. Systems that require LAN-free backup will therefore be connected to two SANs - data and backup.
 
Top