restore security doubts

Question

Hello folks.My organization is under ISO auditing and I'm reviewing my procedures documents and I have a security issue here that&nbsp; 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?

pkh · Accepted Answer

Encryption is never enabled as a default.&nbsp; You have to enable it by creating encryption keys using passphrases.&nbsp; This is done under Settings --&gt; Network.
You then use these keys when you enable encryption in your jobs.&nbsp; If you need to retore the tapes on another system or installation, you need to know the encryption passphrase.&nbsp; Otherwise, they cannot be accessed.&nbsp; If you loose the encryption keys, then even Veritas is unable to recover them for you and your tapes cannot be accessed.

colin_weaver · Answer

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.
&nbsp;
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
&nbsp;
&nbsp;

larry_fine · Answer

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.

smorais · Answer

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?

smorais · Answer

Colin, you've just raised more doubts about it. lol1) 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.respectly,&nbsp;Sidney Morais

colin_weaver · Answer

&nbsp;
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&nbsp; 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.

Forum Discussion

restore security doubts

9 Replies

Related Content

Doubt about NITA x Version Netbackup

Doubt About Backup Catalog

CVE-2023-38545/6 security vulnerability.

modify security permission

BMR restore.

Recent Discussions

Backup Exec Job got canceled

BackupExec for Oracle 23ai?

Add Oracle DB in Backup Exec

Veritas Backup Exec version upgrade & migrate to another new Server

Veritas Backup Exec 23 - Slow Backup after Windows server 2019 upgrade