Deploying Archiver Appliance in a Security Focused Manner

[micoolpaul]

Hi,

I'm hoping someone else has come across this scenario and I'm missing something, otherwise it's a feature request I guess!

From what I can see, it's not possible to utilise a reserved IP address from AWS/Azure to allocate to the Archiver Appliance, meaning every time that the appliance gets created, it gets a new public IP (I've not spun one up for a few months but I believe the VM gets deleted when powered off, not just deallocated?). As the VBR server must communicate to the archiver appliance on TCP443 and TCP22, this combined with an ever changing public IP address means allowing the VBR server web access to anything on the internet, which isn't a security optimised design.

So, question one: Am I missing something that allows me to allocate a static IP address or reuse an IP address for the archiver appliance? So that the on-prem firewall isn't VBR -> WAN:ANY basically? My customer doesn't approve of this.

This is my current workaround assuming that question one doesn't have a good answer:

I'm aware that when working with Azure you can use ExpressRoute to communicate to the archiver appliance and as well to talk to object storage. My customer has separate WAN and ExpressRoute links with separate bandwidth amounts, due to ExpressRoute utilisation, we're backing up to Azure Storage capacity tier over the WAN. I've seen KB4373 (https://www.veeam.com/kb4373) has a registry key to utilise a private IP for the archiver appliance. Can I confirm that if I set that registry key, it won't attempt to override talking to object storage via a private IP too? As a workaround I'm thinking I deploy the archiver appliance for communication via the ExpressRoute, and use that as the 'control channel' to the appliance, whilst any data uploads to capacity tier utilise the WAN as normal? It wouldn't then necessitate that I add private endpoints to the Azure storage for the archiver appliance to use or anything?

Effectively as this is a large-scale production scenario I'm sceptical of breaking anything...


Hopefully this scenario has made sense, please let me know if anything is confusing and I'll do my best to elaborate.

[Mildur]

Hi Michael

(I've not spun one up for a few months but I believe the VM gets deleted when powered off, not just deallocated?)

Correct, we will delete the archiver appliance after the offload session.

ArchiveFreezingUsePrivateIpForAzureAppliance

I assume it only affects how Veeam connects to the archiver appliance, not Azure Storage itself. I will ask QA to confirm my assumption.

So, question one: Am I missing something that allows me to allocate a static IP address or reuse an IP address for the archiver appliance? So that the on-prem firewall isn't VBR -> WAN:ANY basically? My customer doesn't approve of this.

This is not possible today in the product. I also checked our registry database and couldn't find something which would help. I will discuss it with the team as a feature request. From a security perspective your request makes totally sense to me.

Best,
Fabian

[Mildur]

Hi Michael

The reg key <ArchiveFreezingUsePrivateIpForAzureAppliance> only affects communication with the archiver appliance.
Offload to the capacity tier will still be done over the public endpoint.

Best,
Fabian