Hello Community and good day,

bringing the conversation here as well to further discuss on this topic. First of all, apologies for the long thread but I wanted to provide as much context as possible.

I totally agree that using physical boxes exclusively as VHRs and putting the VBR server role alone somewhere else (as long as backup data is physically separated from the VBR server itself) should be the way to go from now on.

Looking at our install base, we still have some customers using physical Windows boxes hosting both the primary backup repository and the VBR server role at the same time. To be completely honest, in a scenario where backup data is not physically separated from the VBR server itself I see little point to enabling two-factor authentication for Veeam Backup and Replication users without applying some hardening on these boxes, such as preventing some users from logging onto the operating system.

Although the first goal should be to put the VBR server role alone, physically separate backup data from it and implement end to end immutability for all the backup copies, realistically it will take time to transition all existing install base to this scenario (to the perfect scenario, if you will).

Sticking with the mantra from Sami Laiho "In Security, don’t let perfect be the enemy of good", I believe it is possible to increase the security of the VBR server itself with minimal effort by creating separate, Veeam Console-specific users protected with MFA without admin rights of the VBR server itself for logging in and operating the v12 Console.

The plan I have in my mind in order to accomplish this task is to end up with:

VBR server itself
==================================================
1) Remote Desktop Service disabled
2) Not part of the production domain
==================================================

VBR server Default local Administrator account
==================================================
1) Not used for daily operations and intended as a Break Glass Account with a and unique password stored safely
2) Depending on the level of paranoia, it can be disabled in favor of a Break Glass Account whose username is automatically generated, with a complex and unique password stored safely and MFA (like Cisco Duo) at the OS level
3) Regarding the User Rights Assignments at the Windows OS level, I believe "Deny access to this computer from the network", "Deny log on as a batch job", "Deny log on as a service" and "Deny log on through Remote Desktop Services" can all be disabled using the Local Group Policy Editor, thus allowing log on directly at the device's console only
==================================================

VBR server local account(s) with administrator rights used for periodic operations on the VBR server itself, such as performing upgrades of Veeam Backup & Replication
==================================================
1) Username(s) for such account(s) can be automatically generated, with a complex and unique password and MFA (like Cisco Duo) at the OS level depending on the level of paranoia
2) Regarding the User Rights Assignments at the Windows OS level, I believe we can apply the same security policy settings listed above for the VBR server Default local Administrator account/Break Glass Account
==================================================

VBR server local account(s) without administrator rights used for daily Veeam Console-specific operations depending on the role assigned to them
==================================================
1) Username(s) for such account(s) can be automatically generated, with a complex and unique password and MFA at the Veeam Console level
2) Regarding the User Rights Assignments at the Windows OS level, I believe "Deny log on as a batch job", "Deny log on as a service", "Deny log on locally" and "Deny log on through Remote Desktop Services" can all be disabled using the Local Group Policy Editor, while I am unsure whether the "Deny access to this computer from the network" can be safely disabled as it is required to allow proper logon through the Veeam console from a remote computer
==================================================

Any suggestions and thoughts will be greatly appreciated.

Kind Regards,

Massimiliano