Phyllis Buono

Я пришел к следующему решению.

1. Использовать ACL модель безопасности. Каждый объект в системе имеет связанный с ним набор разрешений (permissions). Разрешения определяют, кто и какие действия могут выполнять над объектом.
   
2. Микросервисы отвечают за авторизацию на уровне сущности и фильтрацию объектов в ответах на основе разрешений этих объектов.
   
3. Служба централизованного контроля доступа (Access Control Service) отвечает за создание, обновление и удаление разрешений для всех объектов в системе. База данных Access Control Service является основным хранилищем разрешений объектов.
   
4. Разрешения, хранящиеся в базах данных микросервисов, которые синхронизируются с базой данных Access Control Service с использованием event-carried state transfer. Каждый раз, когда изменяются разрешения, событие отправляется брокеру сообщений (message broker). Микросервисы могут подписываться на эти события для синхронизации разрешений.
   
5. API Gateway может использоваться как дополнительный уровень защиты. API Gateway может напрямую обращаться к Access Control Service (RPC) для проверки разрешений объектов ответа или загрузки недавно отозванных разрешений.
   

Данный подход имеет следующие особенности:

1. Требуется возможность уникальной идентификации каждого объекта в системе (например, UUID).
   
2. Синхронизация разрешений в микросервисах eventual consistent. В случае разделения сети (partition) между брокером сообщений и микросервисом, разрешения не будут синхронизироваться. Это может быть проблемой в случае с отзывом разрешений. Решение этой проблемы - отдельная тема.
   

Разве ПО UniFi не имеет дистрибутива под Windows? Мне кажется, что имеет.
Виртуализация сама по себе не является никакой ресурсоемкой задачей, так что советчиков с их "поставь 32 гига озу" можете не слушать. Следуя таким советам даже полной корзины топовых блейдов будет мало, в то время как мой хиленький макбук вполне сносно справляется с тремя виртуальными Windows Server, запущенными одновременно.
Правильно сделать следующим образом: считаете, сколько максимально потребуется ОЗУ гостевым системам + накидываете сверху 20% (если будете использовать Hyper-V -- добавляйте не менее 2 ГБ).
Подобными рекомендациями вендора ПО зачастую можно пренебречь: если серверу хватает производительности для приложения, самому приложению нет разницы, физический он или виртуальный.
Кроме одного НО!
Все платформы виртуализации до сих пор имеют некоторые проблемы с перенаправлением физических устройств в виртуальные машины, особенно если железо экзотическое. Грубо говоря, даже ESXi вряд ли поможет мне внутри виртуальной машины посмотреть кабельное ТВ с помощью платы 15-летней давности. Я не знаю, как устроен этот ваш программно-аппаратный комплекс, но подозреваю, что специфические контроллеры и/или интерфейсы он все же задействует. Уточните у разработчиков этой АРМ "Орион", будет ли ваш комплекс работать внутри виртуальной машины.