Из разряда "как попытаться выдать недостаток за достоинство". Искренне надеюсь, что ваши специалисты на самом деле не думают, что мультимастер структура AD - это потому, что ребята не знали, как "логично" сделать.
Multimaster‑структура AD — это историческая особенность архитектуры. Она была разработана в 2000 году под специфические задачи: работу с непостоянными каналами связи (спутниковые линии, филиалы с ограниченной связью) с так называемыми окнами доступности. Отсюда и функционал репликации по расписанию в течение суток, который кажется избыточным в современных реалиях.
В современном мире, при стабильных постоянных каналах связи, схема master → multireplica полностью покрывает все сценарии: аутентификация, авторизация. Никакой особой логики здесь нет — просто исторический дизайн учитывал условия и ограничения того времени.
Геораспределенную систему или систему работающую под большой нагрузкой в с таким подходом точно не построите, впрочем у вас питон, поэтому тут про нагрузки и говорить не приходится.
Геораспределённый кластер на PostgreSQL прекрасно строится с помощью Patroni со схемой master–replica. Для удалённых филиалов можно использовать реплику в режиме read-only для аутентификации и авторизации, а master — для операций записи. Даже при обрыве связи с master филиал остаётся полностью работоспособен в локальных сценариях.
Что касается нагрузок и Python — здесь важно понимать масштаб. Даже у крупнейших компаний в России количество активных пользователей не превышает сотен тысяч. Например, если взять инфраструктуру компании с численностью порядка 400 000 пользователей, — такая нагрузка без проблем обслуживается Python-сервисами при правильной архитектуре. Python давно используется в высоконагруженных системах — от брокеров сообщений до крупных web-сервисов. Его легко масштабировать горизонтально: микросервисная архитектура, асинхронные фреймворки, балансировка через Nginx/Traefik, worker-пулы для фоновых задач и т.п.
LMDB действительно снимает ограничение по размеру базы, но не решает главные проблемы Samba — архитектурные.
Проект исторически создавался как реализация протоколов Windows NT в Linux-среде. Со временем в него “дописывали” поддержку AD, Kerberos и LDAP, но эти компоненты остались слабо связанными и разношерстными по архитектуре. Репликация и обработка политик реализованы в однопоточном режиме, а кэширование и индексация данных крайне ограничены. На десятках тысяч объектов наблюдаются задержки репликации и рост времени отклика LDAP. Это подтверждается тестами крупных организаций и интеграторов.
Интересно, а какие санкционные риски у .net и Go по сравнению с Python?
Санкционные риски напрямую зависят не только от языка, а от экосистемы и юрисдикции. .NET — продукт Microsoft, целиком под контролем американской корпорации. Даже при наличии .NET Core с открытым исходным кодом, зависимость от инфраструктуры (NuGet, tooling, Visual Studio, лицензии) остаётся высокой. Go — развивается под управлением Google, что тоже создаёт риски.
Python — полностью открытый, развивается международным сообществом под управлением Python Software Foundation, зарегистрированной как некоммерческая организация. В нём нет корпоративного вендора, способного одномоментно ограничить использование или распространение.
DDoS и отказоустойчивость Для защиты от DDoS и вредоносного трафика мы используем оператора NGENIX с ротацией IP-адресов каждые 30 минут и фильтрацией запросов. Список всех актуальных сетевых префиксов можно проверить на странице. Также в нашем случае все вычислительные мощности и сетевая инфраструктура, необходимые для работы системы, размещены в трех дата-центрах – DataLine, Selectel и LinxCloud. Дата-центры сертифицированы на Tier III / Tier IV (Uptime Institute), с резервированием всех инженерных систем.
Почему нет бэкапа фактора Отсутствие резервного копирования это наше осознанное решение. Хранение секретных ключей где-то вне устройства разрушает саму идею второго фактора. Смысл MFA в том, чтобы объединить независимые типы факторов: то, что вы знаете (пароль), то, что у вас есть (устройство или приложение-аутентификатор), и то, что вы есть (биометрия).
Чтобы украсть учётную запись нужно как минимум знать пароль и иметь физический доступ к Вашему телефону. При появлении бэкапа атака становится проще. Можно защитить бэкап паролем, но тогда возникает цикличность. Чтобы восстановить доступ к аккаунту, защищенному паролем, нужен другой пароль, который пользователь может установить ненадежный или забыть. Если бэкап зашифрован, то появляется проблема управления ключом шифрования: его где-то нужно хранить, а значит, снова возникает потенциальная уязвимость.
Сравнение с сохранениями игр здесь интересно, но не совсем корректно. Данные игр это Ваши личные прогрессии и настройки. Их ценность субъективна. А секретные ключи это цифровые аналоги ключей от квартиры или сейфа. Их копирование и хранение на устройствах, не находящихся под Вашим полным контролем, по сути небезопасно. Потеря устройства решается безопасным пересозданием фактора, риска компрометации ключей не возникает.
Почему корпоративная MFA, а не Free2FA Свободные локальные решения хороши для личного использования, но в корпоративной среде у них есть ограничения. Когда сотрудники используют разные аутентификаторы по своему выбору, невозможно централизованно применять политики безопасности, оперативно отозвать доступ при увольнении или проводить аудит инцидентов. “Бесплатность” таких решений тоже иллюзорна. Они не всегда являются отечественными, у них зачастую меньший функционал, их все равно нужно поддерживать, защищать от DDoS, обновлять и мониторить, что в итоге обходится дороже готового сервиса с этими функциями “из коробки”. Ну и еще корпоративные MFA-системы специально проектируются для защиты критически важных ресурсов. Они устойчивы к фишингу, поддерживают строгие протоколы и создаются специально под требования бизнеса и регуляторов.
Multimaster‑структура AD — это историческая особенность архитектуры. Она была разработана в 2000 году под специфические задачи: работу с непостоянными каналами связи (спутниковые линии, филиалы с ограниченной связью) с так называемыми окнами доступности.
Отсюда и функционал репликации по расписанию в течение суток, который кажется избыточным в современных реалиях.
В современном мире, при стабильных постоянных каналах связи, схема master → multireplica полностью покрывает все сценарии: аутентификация, авторизация. Никакой особой логики здесь нет — просто исторический дизайн учитывал условия и ограничения того времени.
Геораспределённый кластер на PostgreSQL прекрасно строится с помощью Patroni со схемой master–replica.
Для удалённых филиалов можно использовать реплику в режиме read-only для аутентификации и авторизации, а master — для операций записи. Даже при обрыве связи с master филиал остаётся полностью работоспособен в локальных сценариях.
Что касается нагрузок и Python — здесь важно понимать масштаб.
Даже у крупнейших компаний в России количество активных пользователей не превышает сотен тысяч. Например, если взять инфраструктуру компании с численностью порядка 400 000 пользователей, — такая нагрузка без проблем обслуживается Python-сервисами при правильной архитектуре.
Python давно используется в высоконагруженных системах — от брокеров сообщений до крупных web-сервисов. Его легко масштабировать горизонтально: микросервисная архитектура, асинхронные фреймворки, балансировка через Nginx/Traefik, worker-пулы для фоновых задач и т.п.
LMDB действительно снимает ограничение по размеру базы, но не решает главные проблемы Samba — архитектурные.
Проект исторически создавался как реализация протоколов Windows NT в Linux-среде. Со временем в него “дописывали” поддержку AD, Kerberos и LDAP, но эти компоненты остались слабо связанными и разношерстными по архитектуре.
Репликация и обработка политик реализованы в однопоточном режиме, а кэширование и индексация данных крайне ограничены. На десятках тысяч объектов наблюдаются задержки репликации и рост времени отклика LDAP. Это подтверждается тестами крупных организаций и интеграторов.
Санкционные риски напрямую зависят не только от языка, а от экосистемы и юрисдикции. .NET — продукт Microsoft, целиком под контролем американской корпорации. Даже при наличии .NET Core с открытым исходным кодом, зависимость от инфраструктуры (NuGet, tooling, Visual Studio, лицензии) остаётся высокой.
Go — развивается под управлением Google, что тоже создаёт риски.
Python — полностью открытый, развивается международным сообществом под управлением Python Software Foundation, зарегистрированной как некоммерческая организация. В нём нет корпоративного вендора, способного одномоментно ограничить использование или распространение.
Здравствуйте, спасибо за подробный комментарий!
DDoS и отказоустойчивость
Для защиты от DDoS и вредоносного трафика мы используем оператора NGENIX с ротацией IP-адресов каждые 30 минут и фильтрацией запросов. Список всех актуальных сетевых префиксов можно проверить на странице. Также в нашем случае все вычислительные мощности и сетевая инфраструктура, необходимые для работы системы, размещены в трех дата-центрах – DataLine, Selectel и LinxCloud. Дата-центры сертифицированы на Tier III / Tier IV (Uptime Institute), с резервированием всех инженерных систем.
Почему нет бэкапа фактора
Отсутствие резервного копирования это наше осознанное решение. Хранение секретных ключей где-то вне устройства разрушает саму идею второго фактора. Смысл MFA в том, чтобы объединить независимые типы факторов: то, что вы знаете (пароль), то, что у вас есть (устройство или приложение-аутентификатор), и то, что вы есть (биометрия).
Чтобы украсть учётную запись нужно как минимум знать пароль и иметь физический доступ к Вашему телефону. При появлении бэкапа атака становится проще. Можно защитить бэкап паролем, но тогда возникает цикличность. Чтобы восстановить доступ к аккаунту, защищенному паролем, нужен другой пароль, который пользователь может установить ненадежный или забыть. Если бэкап зашифрован, то появляется проблема управления ключом шифрования: его где-то нужно хранить, а значит, снова возникает потенциальная уязвимость.
Сравнение с сохранениями игр здесь интересно, но не совсем корректно. Данные игр это Ваши личные прогрессии и настройки. Их ценность субъективна. А секретные ключи это цифровые аналоги ключей от квартиры или сейфа. Их копирование и хранение на устройствах, не находящихся под Вашим полным контролем, по сути небезопасно. Потеря устройства решается безопасным пересозданием фактора, риска компрометации ключей не возникает.
Почему корпоративная MFA, а не Free2FA
Свободные локальные решения хороши для личного использования, но в корпоративной среде у них есть ограничения. Когда сотрудники используют разные аутентификаторы по своему выбору, невозможно централизованно применять политики безопасности, оперативно отозвать доступ при увольнении или проводить аудит инцидентов. “Бесплатность” таких решений тоже иллюзорна. Они не всегда являются отечественными, у них зачастую меньший функционал, их все равно нужно поддерживать, защищать от DDoS, обновлять и мониторить, что в итоге обходится дороже готового сервиса с этими функциями “из коробки”. Ну и еще корпоративные MFA-системы специально проектируются для защиты критически важных ресурсов. Они устойчивы к фишингу, поддерживают строгие протоколы и создаются специально под требования бизнеса и регуляторов.