Making backups is, of course, always a good idea. If you store them offline or immutable, that’s even better 🙂 But as always, much more can be done to ensure you are as much protected as possible (or at least your backups are).
One of those things is to set up a backup resource domain with a one-way trust to your production domain where all the actual workloads live.
This way, you can make sure that only a small controlled amount of users have access to the actual backup domain and, by design, have access to your production domain.
Because there will only be a few users in the backup resource domain, you can really tighten the security on that part. That way, the attack factor can be as small as possible.
What would this look like?
Below I have made a small sketch of what this looks like from an infrastructure perspective and how the data flow would be travelling.
How to set it up?
So after the (simplified) design it is time to set it up. In this paragraph, I will try to show it step by step.
First step is ofcourse to have 2 domains in place. At the resource domain, go to “AD Domains and Trusts” and right-click the resource domain and select properties, select the “Trusts” tab and select “New Trust”.
Click Next and fill in the the production domain name (in my case veeamdemo.nl).
Select what kind of transistive trust it should be and select the one that is needed by your orginization. In my case I am choosing an “External Trust”, which makes it more secure by bounding it to the specific 2 domains in the trust (for a smaller attack footprint).
Select what kind of direction you want to use. In this case, because the “New Trust” wizard is initiated on the resource domain it will be a “One-way: incoming” trust.
In the next step you can tell it to create the trust on both domains (if you have appropriate credentials available for the domains, which I have).
After filling in the required credentials you will get the question to select the “Authentication Level”. In my case, I selected “Selective authentication” because I want to be totally in control of granting access to resources in the domain.
After this step, you will get an overview of the settings. Click next on this page.
After this the trust is created and can be verified (confirmed).
So after all these steps you should have a validated One-way trust between your two domains and making backups from a more secure perspective can begin.
Running a first backup job with the One-Way trust in place
Before we can start using VBR (which is located in the resource domain) to make backups of the production machines we will have to configure some settings in VBR.
First off, we will need to add a user’s credentials from the resource domain that you want to use for backing-up machines with AAIP in the production domain. In my case, I will be using my veeambackup\demo user.
For adding the vSphere infrastructure credentials need to be added too.
In my case I added the local administrator@vsphere.local account to see all the VM’s from the production domain (my advice is to use a specific local vSphere account instead of the administrator account 😉 and make sure your vSphere environment is not completely integrated and dependent on your production domain).
Now it is time to add a backup job to VBR. Start the new backup job wizard.
Select the destination for your backups and click next.
Now the most important step is the “Guest Processing” tab. Here you will have to select the right account to use for Application-Aware Processing. Here I have selected the “Guest OS credentials” based on my resource domain (veeambackup\demo).
Click the “Test Now” button to validate that you can access and communicate with the VM based on the resource domain credentials provided.
If all goes well, it should successfully finish the test. Go on with the wizard and complete the remaining steps.
Now it is time to run the actual backup.
As you can see, we can back up the machine with AAIP living in the production domain with a user from the resource domain.
So what else can we do to tighten security even more?
Well we can even use gMSA (Group Managed Service Accounts) so we can leave the password/user handling completely over by Active Directory (which will auto rotate and hand out passwords based on 240 bytes without us having to worry about it 🙂 ). I will discuss this in my next post.