Solved

Enabling Ransomware Protection on a MediaAgent for disk library

  • 9 November 2021
  • 4 replies
  • 268 views

Userlevel 2
Badge +8

Hi Community ,

 

Does Enabling Ransomware Protection on a windows MediaAgent CV feature make my disk library and backup copies immutable ? 

Do we also need WORM enabled primary or secondary copies even after enabling this CV native feature for full proof ransomware protection ? If yes , what is the use of ransomware protection feature ?

Regards, Mohit

icon

Best answer by Scott Moseman 9 November 2021, 22:25

View original

4 replies

Userlevel 7
Badge +23

Hi @Mohit Chordia , thanks for posting!

Let’s start by looking at what Ransomware Protection does vs what WORM does:

Ransomware Protection on the Media Agent:

  • When Ransomware protection is enabled on a MediaAgent, non Commvault processes (like a Ransomware running on the MediaAgent) will not be allowed to modify, delete or access the files on both the locally attached mount paths and the network mount paths. This includes OS level operations used to write/modify/delete data. Files can be copied from the mount path, but paste or copy operation to the mount path cannot be performed.

  • To ensure full protection of data on a network mount path, the network share should have restricted permissions with only a specific Commvault backup user with write, modify and delete permissions. Make sure that no other user, other than this specific backup user has write, modify or delete permissions on this network share, with possible exceptions to system and other important accounts like admin who may require these permissions to browse the mount path folder locally. It is highly recommended that the permissions to the network mount path be as restrictive as possible. In addition, ensure the following:

    • This Commvault backup user credentials is used to configure the Commvault disk library mount path.

    • Ransomware protection is enabled from all the MediaAgents accessing this share.

I highlighted the important part.  This prevents non-CV entities from access/edit the files on the Mount Paths.  Very handy feature.

Now, WORM is sort of similar sounding, but has a different purpose and function:

  • WORM Copy is an option that prevents the deletion of data that is not qualified for aging. The expiration date for the read-only is set to match the data retention time established in the storage policy copies. These archive files cannot be modified or deleted by any user or application until the specified retention date. Once the retention expires, the system deletes the archives as part of Data Aging.
  • WORM Copy also prevents deletion of clients, libraries, and mount paths.

So WORM is there to prevent accidental deletion before your retention period has been met.  It’s to protect you and your business from losing data you know you’ll require up to a certain date.

You’ll note that Ransomware Protection prevents deletion by non-CV entities, but has nothing to do with retention.  WORM prevents deletion before retention, but has nothing to do with ensuring only CV entities can access the data.

They both have their value and purpose, assuming your business needs require them.

Userlevel 4
Badge +7

Enabling Ransomware Protection and CV WORM are definitely steps towards securing your data, they do not constitute making the data immutable (unless you’re using HyperScale X).

As Mike notes, Ransomware Protection makes sure non-CV processes cannot access your data from any compromised MAs.  CV WORM makes sure no one accidently or maliciously deletes data before it has reached it’s configured retention from the CV GUI.  They compliment each other.

What’s missing from an immutability perspective is direct access.  If you’re using a NAS storage array, with the right credentials you could map to the \\nas\share from your laptop (or any computer) and delete the data directly.  This bypasses the CV stack, so the RP+WORM options cannot help.

To make the data immutable, we need RP+WORM enabled, plus one of these:

1)  Use Commvault HyperScale X storage.  These have storage which is local to the MAs and not presented externally to the network, so no horizontal access to the data.

2)  Enable “immutability” on your storage/cloud.  This is a more complex discussion, but note it will require periodic sealing of your DDBs and you’ll consume 3x your normal storage.

Thanks,
Scott
 

Userlevel 2
Badge +8

@Scott Moseman @Mike Struening 

Thanks for the reply.

What if we are using windows media agent with local storage , it can not be presented externally to the network.

Does enabling RP is enough in this case ? or should we consider enabling WORM which will increase our storage cost by 3x and also management overhead such as periodic sealing of DDBs.

 

Regards, Mohit

Userlevel 4
Badge +7

@Scott Moseman @Mike Struening 

What if we are using windows media agent with local storage , it can not be presented externally to the network.

Does enabling RP is enough in this case ? or should we consider enabling WORM which will increase our storage cost by 3x and also management overhead such as periodic sealing of DDBs.


If it cannot be externally presented, RP+WORM would make it immutable.  (Requires both.)

My concern would be whether the Windows MA is locked down well enough.  Unlike a storage array, there’s more opportunity for insecurities to be allowed on a Windows server.  e.g., Making sure no admins create a hidden share (\\server\d$) which gives horizontal access to its storage.

Thanks,
Scott

Reply