Netbackup 5240 appliance Encryption

[Lev5240]

Hello VOX community,

I am new to VOX community... Hopefully I can find an answer for what I am looking for. My questions in reagards to Netbackup 5240 Appliance Encryption.

We have bought Netbackup 5240 Appliance (Netbackup 8.1) and now in the process to migrate our existing hosts/clients from Netbackup 7.6 to the new appliance. Few of our clients have Client side Encryption backups taken. I was told that with the new appliance and new netbackup 8.1 version all backups automatically encrypted. Not really sure how this works. In  netbackup 7.6 version with client side encryption we used to create a KEYFILE on the client side and update the POLICY for the host and check the ENCRYPT option in the ATTRIBUTES tab.

Plus after you take an encrypted backup in 7.6 you could see if the backup file is in fact encrypted by running: /usr/openv/netbackup/bin/tar -tvf client1.domain_137458487345_C1_F1_137458487345.img     and look for    .Encryption_CIPHER.0

Not really sure how it works in 5240 appliance with MSDP.  Are all backups automatically encrypted? do you need to create any keyfiles? do you need to check ENCRYPT option in the POLICY under ATTRIBUTES tab.

What steps need to be taken to have a CLIENT side encryption in the new netbackup 8.1.

Thank you so much for reading this.

Really appriceaite your help.

[Systems_Team]

Hi Lev5240,

I don't believe 8.1 encrypts all backups by default. It looks like encryption hasn't changed much.  Here is the link to the NetBackup 8.1 Security and Encryption Guide: https://www.veritas.com/support/en_US/doc/21733320-127424841-0/index

What I think you're talking about is that all 8.1 servers and clients now have encrypted communications between them, using TLS.  The Master server basically operates as Certificate Authority for this.  If you have earlier clients that do no support this, then you can enable insecure comms so that the 8.1 Master can talk to them.  Here is the link to the Read Me First document for Secure Communications in 8.1: https://www.veritas.com/content/support/en_US/doc/127918107-127918110-1

A fairly major change so worth running through that first 

Hope this helps,

Steve

[andrew_mcc1]

You will need to be careful here. Client Encryption will defeat deduplication, when using MSDP the normal recommendation would be to use MSDP native encryption plus tape drive encryption (SCSI T10 based Key Management Service) if also using tape-out.

Also note MSDP Encryption is documented in the NetBackup Deduplication Guide, not the Security and Encryption Guide.

Andrew

[Lev5240]

Steve,

Thank you for your reply. Since 5240 appliance with Netbackup 8.1all comunication is encrypted using the TLS protocol between the master and client server. How can you actually PROVE that you have taken an encrypted backup.

With earlier versions of client encrypted backups you could run below command and look for Encryption_Cipher.0  as in example below.

/opt/encrypted_backups # tar -tf <client>_1200321967_C1_F1.1200321967.img
10742623350 10741770322 //
10742672662 10742672662 //tmp/
10742672663 10742672663 /.EnCrYpTiOn_CiPhEr.0
10742671626 10742671610 //tmp/testfile

How can this be proven with client encrypted backups on 5240 appliance.

Thank you.

[RB-Infinitely]

Hi,

What you're referring to in NetBackup 8.1 is the communications channel being encrypted with TLS. The actual data is not encrypted.

For encryption of the MSDP, refer to this note

https://www.veritas.com/content/support/en_US/doc/25074086-127355784-0/v95643059-127355784

[Marianne]

@Lev5240

Please read through @andrew_mcc1's post again.

You should NOT use Client Encryption in the policy with MSDP.

Please read up in NetBackup Deduplication Guide   about these topics:
Use MSDP compression and encryption
About MSDP encryption
MSDP compression and encryption settings matrix
Configuring encryption for MSDP backups
Configuring encryption for MSDP optimized duplication and replication
MSDP encryption behavior and compatibilities

You will see this in one of these sections:

Note: Do not enable backup encryption by selecting the Encryption option on the Attributes
tab of the Policy dialog box. If you do, NetBackup encrypts the data before it reaches the
plug-in that deduplicates it. Consequently, deduplication rates are very low. Also, NetBackup
does not use the Deduplication Multi-Threaded Agent if policy-based encryption is configured.

[Lev5240]

Marianne,

Thank you for your reply. I went through the topics you have mentioned but I still couldn't not find any information about below questions.  Since 5240 appliance with Netbackup 8.1 all comunication is encrypted using the TLS protocol between the master and client server. How can you actually PROVE that you have taken an encrypted backup. With earlier versions of client encrypted backups you could run below command on master server and look for Encryption_Cipher.0  as in example below.

/opt/encrypted_backups # tar -tf <client>_1200321967_C1_F1.1200321967.img
10742623350 10741770322 //
10742672662 10742672662 //tmp/
10742672663 10742672663 /.EnCrYpTiOn_CiPhEr.0
10742671626 10742671610 //tmp/testfile

 
How can this be proven with client encrypted backups on 5240 appliance.  We have an AUDITING department who would require us to show them proof that we actually taken CLIENT ENCRYPTED backups with screen shots. In older versions of Netbackup (7.6) I would give them above screen shot.

My other question... how can you see if your backups are actually being DEDUPLICATED in MSDP? In my old netbackup set up I used to see where the backup files would go (through command line), see their size, expire them manually. With 5240 appliance seems like you can't get access to the backup files through command line.

Thank you for your answers.

[Marianne]

Seems a similar question was asked over here: https://vox.veritas.com/t5/NetBackup/client-side-encryption-over-deduplication/td-p/604985

From the answers, it looks like NBU does not capture this info in the catalog and that the only way to confirm is by running a test backup, capture the packets (using something like WireShark) and look into the packets.

So, if entries in pd.conf and contentrouter.cfg does not satisfy the auditors, then give them the network 'sniffer' option.