Highlighted

restore security doubts

Hello folks.

My organization is under ISO auditing and I'm reviewing my procedures documents and I have a security issue here that  I'm not sure about:

Is BE Encryption key responsible for preventing to restore backup data on a different server than the original one?

If it is not, how can I prevent it from hapenning? For example, if I have my tapes stolen, how can I be sure that these files won't be accessed?

1 Solution

Accepted Solutions
Accepted Solution!

Re: restore security doubts

Encryption is never enabled as a default.  You have to enable it by creating encryption keys using passphrases.  This is done under Settings --> Network.

You then use these keys when you enable encryption in your jobs.  If you need to retore the tapes on another system or installation, you need to know the encryption passphrase.  Otherwise, they cannot be accessed.  If you loose the encryption keys, then even Veritas is unable to recover them for you and your tapes cannot be accessed.

View solution in original post

9 Replies

Re: restore security doubts

Encryption would prevent your tapes from being read without knowing the encryption key.

I am not sure if you can prevent it from being restored on a different server, but I am not sure you really want that.  In a disaster, you might be restoring on different/replacement servers.

Re: restore security doubts

I think it should have an ecryption method that could be exported or stored on a different file just like encryption key, so, in a case of disaster, I'd be able to restore those files.

you mentioned this encryption that prevents my tapes from being read without encryption key. How can I enable it? or is it enabled by default?

Accepted Solution!

Re: restore security doubts

Encryption is never enabled as a default.  You have to enable it by creating encryption keys using passphrases.  This is done under Settings --> Network.

You then use these keys when you enable encryption in your jobs.  If you need to retore the tapes on another system or installation, you need to know the encryption passphrase.  Otherwise, they cannot be accessed.  If you loose the encryption keys, then even Veritas is unable to recover them for you and your tapes cannot be accessed.

View solution in original post

Re: restore security doubts

Ok so assuming you have enabled encryption and then have a disaster on the BE server itself. If you then need to restore data afterwards you may need one or all of the following:

1) Details (documentaion) of the passphrases used to create the encryption keys (including dates/timeframes of use and jobs used with) - it is the reponsibility fo the backup admin to maintain these in a secure location (not with your backup storage media)

2) A regular up to date copy of the Backup Exec Database. This database, amongst other things, contains the encryption keys used by your jobs, again kept somewhere safe and not with your backup media.

3) For any given install a one-off export of the Databse Encyption Key (DEK) for the Backup Exec Database, again copied to somewhere safe, and do not rename this file as the orginal name is required to use it when recovering the BEDB. The DEK is responsible for the encrypted security information inside the BEDB so without it the copy of the BEDB (point 2) is useless. This should be kept somewhere safe but ideally NOT with the copy of the BEDB and not with your backup media.

In theory in the event of a disaster you could get away with either point 1 OR Point 2 combined with 3 , best practice though is maintain all 3 key factors.

 

As a side note, you of course also need to secure the media itself, the server and for efficiency in the event of a disater copies of your catalogs - although these points are not directly related to encryption

 

 

Re: restore security doubts

Colin, you've just raised more doubts about it. lol

1) If I use a passphrase to create my encrypt key under FIPS 140-2, I can't see any use for dates/timeframes of use, are we talking about the same feature? I'm being based on what pkh said.

2) I did only one BEDB copy, and that's because my environment never changed since then.

3) I'm not sure about what you meant here. DEK is that key that encrypt username and password used on backup jobs, isn't it? that's why I think we're misundertanding each other, lol.

I'm attaching, respectively, what I have configured and what I think that is what you mentioned, please, correct me if I'm wrong.

140-2.JPGbedbd.JPG

respectly, 
Sidney Morais

Re: restore security doubts

 

1) Ok so you have to maintain documentation on passphrases outside of Backup Exec. The reason you need Encryption key dates of use (and maybe jobs used by) as well as the passphrases  is if you decide to change your keys/passphrases after 6 months and then have a mixture of old and new backup sets, you need to know the dates you changed using them so that the correct key is known for the enrypted set you need to restore from. Similarly you might want to use different encryption keys for backing up different resources / servers / departmental data etc and would have to then know which jobs used which (of course if you only ever use one key you won't need this detail) - pkh is talking about these keys and not the DEK

2) The BEDB also contains your media inventory, media retention and protection, job configuration and job history information - while you could still get Backup Exec up and running without all of these, taking a regular copy will make things much easier in the event of a total DR of your BE server (OK not an encryption point but still important)

3) DEK is the term we use for the specific encryption key that protects the security data inside the BEDB - this security data is the logon account information and backup set encryption keys that you may be using with your backups - you need to protect and be aware of the DEK even if you do not encrypt your backups, if you encrypt your backups as well (using leys created by passphrases then these need documenting (as per point 1 above.) The screenshot you provided relates specifically to the DEK and not to the passphrases and keys used in your backups.

Re: restore security doubts

Hi Colin, thanks for replying.

Ok, I've thought about your considerations, but I can't see a connection between what you're saying and what pkh said.

I have enabled that FIPS 140-2 but it doesn't fit with what you're pointing to. I think that your mentioned encryption method is divergent of his.

can you please, show me a KB or screen shots about what you're saying?

thanks a lot for your recomendations, it will be strongly followed if I move forward on this.

Re: restore security doubts

As I am only trying to explain concepts I can't really give screenshots

Bascially there are 2 separate encryption mechanisms in Backup Exec

1) Encrypt the data you backup - this is what pkh is referring to and almost certainly applies to FIPS 140-2 requirements as well. This is NOT enabled by default and uses passphrases that create encryption keys - there is NO export function for these keys, all you can do is document the ones you use and/or backup the database that contains them.

2) Encrypt the security information in the configuration of Backup Exec (inside the database). The encryption key (known as the DEK) used for this does not have a passphrase and is automatically generated. It can be exported using the screens you posted. It has NOTHING to do with encrypting your data and I have no idea if FIPS 140-2 discusses requirements for this.

In the event of loss of the Backup Server (and assuming you do encrypt your backups)  then you need to take appropriate steps to ensure you have a way of recovering both types of encryption

 

Re: restore security doubts

Ooh, now I got it, it's pretty clear.

thanks a lot for your considerations Colin, I will be taking that as good practices approach on our encryption.