Vault 101 – Simple Questions, Simple Answers

We all suffer from terminology/lingo/jargon overload when discussing something new and multi-faceted, especially in the information security space. I am all too often guilty of venturing far too easily into the verbose depths…… In this instance however, I’m going to try and consciously keep this introductory post as high level as possible and to stick to the fundamentals. For sure I will likely miss something along the way, but we can fill in the blanks over time.

Brevity is beautiful….

To that end, this post will concentrate on providing simple concise answers to the following questions.

1. What do we need in order to create an operational Vault?
2. How do we close and lock the door in the ‘vault’?
3. How do we move data into the vault, and use that data to re-instantiate critical applications?

This implies, we will not discuss some very key concepts such as the following.

• Are we sure the Data hasn’t changed during the process of placing the ‘Data’ into the Vault? (Immutability)
• Tools and processes to guarantee immutability?
• Who moved the Data and were they permitted to do so, what happened? (AAA, RBAC, IAM)
• How fast and efficiently we moved the ‘Data’ to make sure the ‘Vault’ door isn’t open for too long (Deduplication, Throughput)
• Where is the ‘Source’ and where is the ‘Vault’? (Cloud, On-Premise, Remote, Local). How many vaults do we have?

Of course, in the real world these are absolutely paramount and top of mind when discussing technical and architectural capability. Rest assured we will revisit these topics in detail along with where everything fits within the NIST and COBIT frameworks in later posts.

What do we need in order create an operational ‘Vault’?

Let’s start with a pretty common real-world example. A customer running mixed workloads on a VMware infrastructure. Of course, they have a Dell VxRail cluster deployed!

In the spirit of keeping this as simple as possible, the following represents the logical setup flow:

1. We need some mechanism to backup our Virtual Machines (VM’s) that are deployed on the vSphere cluster. We have a couple of choices; in this instance we will leverage Dell PowerProtect Data Manager. We have others such as Avamar and Networker, that we will explore in a later post, but PPDM is a great fit for protecting VMware based workloads.
2. PowerProtect Data Manager (PPDM) does the backup orchestration, but it needs to store the data somewhere. This is where Dell PowerProtect Data Domain enters the fray. This platform comes in all shapes and sizes, but again for this VMware use case, the virtual edition, Dell PowerProtect DD Virtual Edition (DDVE) is a good option
3. We need to get the Data into the ‘Vault’. We do this by pairing the Production DDVE with a DDVE that physically sits on a server in the Vault. The vault could of course be anywhere, in the next aisle, in the cloud. At this point, there is no need to get into too much detail around how they are connected, other than to say there is a ‘network’ that connects them. What we do with this network is a key component of the vaulting process. More on that in a while.
4. Once we pair the DDVE appliances across the network, we create an MTree replication pair using the DDOS software. We’ll see this in action in a future post. The replication software copies the data from the source DDVE appliance to the Vault DDVE appliance. Power Protect Cyber Recovery will leverage these MTree pairs to initiate replication between the production side and the Vault.
5. We will deploy another PowerProtect Data Manager in the vault, this will be available on the vault network but left in an unconfigured state. It will be added as an ‘application asset’ to the Cyber Recovery appliance. Power Protect Cyber Recovery will leverage an automated workflow to configure the vault PPDM when a data recovery workflow is initiated.
6. Once we have the basic infrastructure setup as above, then we deploy the PowerProtect Cyber Recovery software in the vault. We will deploy this on the VxRail appliance. During setup, the Cyber Recovery appliance is allocated storage ‘Assets’, a mandatory asset is the DDVE

So, there you go, a fully functional Cyber Recovery Vault leveraging software only. Of course, when we talk about scale and performance, then the benefits of the physical Data Domain appliances will begin to resonate more. But for now, we have an answer to the first question.

Of course, the answer to the second question we posed is key…….

How do we close the vault and lock the door?

This part is fairly straightforward as the Cyber Recovery software automates the process. Once the storage asset is added to Cyber Recovery and a replication policy is enabled then the vault will automatically lock. Don’t worry we will examine what the replication policy looks like and how we add a storage asset in a future post.

Of course, I still didn’t answer the question. In short, the process is fairly straightforward. As mentioned earlier, I skipped over the importance of ‘network’ connectivity between the ‘Production’ side DDVE and the ‘Vault Side’ DDVE above.

Remembering that the Cyber Recovery software now controls the Vault side DDVE appliance (asset) then:

1. When a Policy action (such as SYNC) is initiated by Cyber Recovery, then the software administratively opens the replication interface on the DDVE appliance. This allows the Data Domain software to perform the MTree replication between the Production Side and Vault.
2. When the Policy action is complete, then the Cyber Recovery software closes the vault by administratively shutting down the replication interface on the vault side DDVE appliance.
3. The default state is admin down. or locked.

This is in essence the logic behind the ‘Operational Airgap’. Again, we will dig into this in more depth in a future post, but for now I’m going to move on to the third question. Brevity is beautiful!

How do we use a copy of the ‘Data’ in the vault if required to re-instantiate a business function and/or application?

The cyber recovery software is a policy driven UI which includes:

• Policy creation wizards allowing for point in time and scheduled execution of tasks replication and copy tasks.
• Recovery assistance with the ability to easily recover data to the recovery host(s). e.g., VxRail cluster in our example.
• Automated recovery capability for products such as Networker, Avamar and PowerProtect Data Manager. For example, using point-in-time (PIT) copies to rehydrate PPDM data in the Cyber Recovery Vault.

We have skipped over this last question to an extent, but I think it is deserving of its own post. For example, we will cover in depth how we leverage PPDM in the Vault to re-hydrate an application or set of VM’s

Up next

Hopefully you will find this useful. Clearly the subject is much more extensive, broader and deeper than what we have described thus far. The intent though was to start off with a practical example of how we can make the subject ‘real’. How does this work at a very basic architectural level using a common real-world example? Keeping it brief(ish) and keeping it simple…. we will add much more detail as we go.

Stay tuned for my next post in the series, which will cover how we stand up the Production side

DISCLAIMER
The views expressed on this site are strictly my own and do not necessarily reflect the opinions or views of Dell Technologies. Please always check official documentation to verify technical information.

#IWORK4DELL