
Чем больше средств защиты вы покупаете, тем сложнее их администрировать: SSO для входа, MFA для подтверждения, IDM для управления правами, PAM для контроля доступа к сетевым ресурсам. Четыре продукта, четыре вендора, четыре консоли. И четыре техподдержки, с которыми приходится взаимодействовать. Интеграции съедают месяцы и могут «отваливаться» или терять данные, обновление одного компонента рушит связку с остальными, а безопасники вместо защиты инфраструктуры укрощают этот зоопарк.
Мы устали смотреть, как заказчики мучаются, и объединили все четыре класса решений в одну экосистему. Ниже — как устроен Magnus ID изнутри, примеры внедрения и конкретные цифры экономии.
Как родилась концепция Magnus ID
Прежде чем лезть под капот, синхронизируем терминологию. В «зоопарке» средств защиты корпоративных сетей давно прописались четыре класса решений. Обычно они живут в разных окнах браузера или клиентах, требуют разных лицензий и администрируются разными людьми:
Системы единых точек входа и аутентификации (SSO).
Системы многофакторной аутентификации (MFA).
Системы управления идентификацией и доступом (IDM).
Системы контроля привилегированных доступов для администраторов, разработчиков и т. д. (PAM).
Долгое время российские разработчики смотрели на этот сегмент с опаской: конкурировать с мировыми гигантами казалось безумием. Но после «великого исхода» иностранных вендоров рынок начал заполняться отечественными аналогами. Появились отличные MFA, неплохие PAM и целый ворох IDM-ов.
Сегодня основная проблема даже не в выборе конкретных решений, а в их интеграции.
Представьте, что вы собираете модель корабля, используя детали из разных наборов. Корпус от Lego, мачты из пластилина, паруса из оригами — и всё это нужно склеить синей изолентой.
Когда компания приобретает четыре разных решения, перед ней стоит похожая задача. Администраторы получают четыре счета на лицензии, четыре интерфейса управления и четыре службы техподдержки.
Когда несколько заказчиков пришли к нам с этой болью, мы задумались: почему бы не объединить эти инструменты? Идея лежала на поверхности, но гибридного продукта «всё в одном» на рынке не было. Так началась разработка Magnus ID.
Почему экосистема лучше, чем зоопарк
Уже на этапе идеи стали понятны преимущества такого подхода для бизнеса.
Готовая интеграция из коробки. ИБ-службе не нужно интегрировать четыре отдельных решения друг с другом. Компоненты по умолчанию используют общие объекты и предоставляют единый интерфейс.
Единый интерфейс. Даже один новый интерфейс управления часто воспринимается как приборная панель космолета. Если же внедряется сразу несколько систем, то впору хвататься за шаманский бубен. Ведь речь не только о кнопке «Запустить». Это еще и смежная логика управления доступом, аутентификации, выдачи и блокировки учетных записей и прочее. Всё это завязано на приложение, межсистемные интеграции (IDM-PAM, IDM-MFA, MFA-PAM), уведомления. Другое дело, когда у четырех систем один интерфейс, который для рядового пользователя и руководителя ИБ отличается только количеством доступных действий.
Единые обновления. Обновлять одно решение проще, чем четыре. Особенно когда автоматически обновляются все агенты, сервисы, поддерживаемые протоколы. И не нужно переживать, что новые версии сломают работающие интеграции или удалят важные данные.
Централизованная техподдержка. Это козырь любого продукта класса Enterprise. Пользователям нужна уверенность, что их не бросят. К тому же вместо взаимодействия с несколькими службами поддержки всё можно получить в режиме единого окна.
Что под капотом
Архитектурно Magnus ID — это сервер, который интегрируется с системами аутентификации и предоставляет API для клиентских приложений. Вся архитектура построена на микросервисах, напоминающих детали конструктора. Комбинируя их возможности, мы реализуем различные функции.
Программный комплекс Magnus ID разделен на несколько модулей.

Основные модули
Magnus ID: Core — ядро и консоль управления. Обеспечивает взаимодействие между модулями и внешними решениями с помощью брокера очередей, кэширования данных и т. д. На него, как на фундамент, наслаиваются все остальные компоненты. Вместе с ядром поставляется сервис аутентификации с поддержкой OIDC (OpenID Connect).
Magnus ID Access. Access отвечает за управление доступами пользователей в целевых ресурсах: контроль учетных записей и изменений в них, оперативные блокировки. Словом, модуль обеспечивает функции Identity Management.
Magnus ID: Control (в настоящее время находится в разработке). Это PAM-решение для обеспечения контроля сессий администраторов при подключении к RDP, SSH, VNC или базам данных.
Magnus ID: Auth является сервером многофакторной аутентификации, который обеспечивает защиту корпоративных систем. Агенты и сервисы модуля Magnus ID: Auth отвечают за многофакторную аутентификацию:
WinLogon обеспечивают второй фактор в современных системах Microsoft Windows;
RADIUS-proxy помогает реализовать второй фактор аутентификации для корпоративной сети, например, при подключении сотрудников к VPN;
также у RADIUS-Proxy имеется режим RADIUS Server с проверкой аутентификации в подключенных LDAP-каталогах/Active Directory-доменах;
LDAP Proxy предоставляет второй фактор для доменной аутентификации через Active Directory;
для Linux-систем мы поддерживаем встроенные возможности работы с многофакторной аутентификацией на базе RADIUS (это pam_* библиотеки);
для Mac OS систем также поддерживается двухфакторная аутентификация через RADIUS.
Приложение «Magnus ID-цифровой пропуск». Классическое приложение для синхронизации и работы с TOTP-кодами. Приложение бесплатное, совсем как FreeOTP, Яндекс.Ключ, Google Authenticator и т. д. При этом в Magnus ID реализовано шифрование TOTP-секретов с длиной ключа до 512 бит. А при использовании в связке с комплексом Magnus ID в приложении включается функция PUSH-уведомлений для удобного подтверждения личности (второго фактора) сотрудником. Ведь проще нажать «Да, это я», чем вводить шестизначные коды.

Приложение доступно для смартфонов на Android в Google Play и для iPhone в App Store.
Основной стек
Теперь кратко пробежимся по технологиям, которые мы применяли. Весь код написан на Java — этот язык лучше всего подходит для бизнес-приложений, так что мы убежденные джависты. В Magnus ID используются Spring Boot и Spring Framework, брокеры сообщений Kafka и RabbitMQ, JOOQ и другие библиотеки для работы с СУБД, а также JNDI для управления именами и атрибутами объектов в каталогах. При работе с низкоуровневыми библиотеками и системами применяются C#, C++.
Такой стек хорошо ложится на микросервисы, контейнеризацию, современные кэши и NoSQL-базы. Это дает высокую производительность на единицу мощности и понятный мониторинг нагрузок.
Приведу пример из практики. Недавно мы тестировали фичу, которая сильно нагружает систему и требует высокой скорости взаимодействия с пользователями. Попытались положить сервис — но он не упал и продолжал работать, хотя и замедлился.
При этом комплекс был развернут на машине с одним процессором, гигабайтом оперативки и 5 ГБ хранилища на всё, включая логи. Среднестатистический смартфон в сравнении с этим покажется суперкомпьютером.
Кейсы применения Magnus ID: Auth (модуль многофакторной аутентификации)
Чтобы не быть голословными, рассмотрим конкретный пример внедрения нашей экосистемы. Детали проекта защищены NDA, так что обойдемся без названий и имен.
Реальный кейс: крупный холдинг
Компания владеет популярными новостными и развлекательными ресурсами. Краеугольными камнями стала необходимость управления доступами, защита от векторов атак с учетными данными (TA0006 MITRE) и контроль сессий подрядчиков, имеющих доступ в корпоративную сеть.
Защита от атак через цепочки поставок
Такие атаки — настоящий бич последних пяти лет. Обычный сценарий: подрядчику дали доступ в систему, а злоумышленники «угнали» у него учетную запись, выполнили горизонтальное перемещение и докопались до ценных данных компании. От таких схем не спасают даже «неприступные» цифровые цитадели с десятью периметрами защиты.
Двухфакторная аутентификация в Magnus ID стала дополнительным барьером внутри инфраструктуры. Даже если злоумышленник завладеет учеткой, на его пути встанет 2FA с вопросом «Это точно вы?». По интеграции в SIEM отправляется информация о неудачных попытках входа, таймаутах при вводе подтверждений 2FA. Если у подрядчика украли учетку, он увидит в приложении уведомления о попытках входа от своего имени и нажмет «Нет, это не я». Такой сигнал моментально улетает в SIEM как warning.
Аутентификация первого фактора собственными средствами
Это специфическая доработка под нужды заказчика. В Magnus ID есть функция проксирования запросов сетевой аутентификации (RADIUS Proxy). Но мы с заказчиком решили пойти дальше: система не отправляет запросы в имеющийся Radius (например, Microsoft NPS), а сама проверяет учетные данные пользователя — в службах каталогов. Фактически Magnus ID выполняет задачи RADIUS-сервера. Да, это усложнило логику приложения и модель безопасности. Зато компания сократила свой «зверинец» СЗИ (средств защиты информации) на одно специализированное решение.
Модуль RADIUS в отличие от других решений может спокойно работать с длинными значениями служб каталогов (с этим ограничением сталкиваются многие другие вендоры). К тому же к моменту выхода этого материала — с огромной долей вероятности будет реализована проверка еще и доменной аутентификации непосредственно со шлюзов, VPN и при необходимости — с сетевых устройств. Но это точно уже не про системы класса MFA, а уже какой-то приевшийся зеро-траст. Почти как файрволы с приставкой Next Generation.
Покрытие Windows-систем (начиная с Windows 8.1 и до версий Н22)
Такая задача решается с помощью Windows Logon-агента. Агент работает с нативными средствами Windows, но в отличие от многих не имеет открытого исходного кода. Ведь любой «низкий» уровень программирования может указать потенциальному злоумышленнику с нейронками способ получить доступ к системе.

К слову, одна из ключевых особенностей комплекса и его функций — отсутствие скрытых учетных записей, разного рода кодов и паролей «на всякий случай». В последующих статьях мы приоткроем завесу работы комплекса в режиме катастрофоустойчивости, включая отсутствие штатного режима bypass (прим. — пропуск без ввода второго фактора).
Контроль LDAP proxy и доменной аутентификации
Система позволяет отследить, кто аутентифицируется на «давно понятном механизме». Ведь механизм, который доверяет токенам длиной в 90 дней, могут считать надежным только IT-специалисты, и то редко.
Покрытие вторым фактором множества систем организации
Другой важный компонент — это агент AD FS. Зная специфику данного решения и его протоколов, можно попасть в широкий пул систем предприятия. Почему бы не покрыть и эту часть корпоративной инфраструктуры вторым фактором, который точно остановит злоумышленников еще на этапе подбора ключей и токена?
А теперь представьте, какой объем работ пришлось бы выполнить при интеграции отдельных MFA, IDM, PAM, чтобы создать объекты и общую логику системы. Прибавьте сюда стоимость сопровождения обновлений, которые на IDM измеряются миллионами и миллионами.
Благодаря Magnus ID всех этих расходов и сложностей удается избежать, поскольку каждый модуль заведомо работает в тесной связи с другими еще до выхода проекта в релиз.
Избежание потерь и рисков в связи с утечками данных
Теперь вспомним один нашумевший случай с крупным российским туроператором, у которого, к сожалению, не было Magnus ID, и порассуждаем, как наша экосистема помогла бы избежать нежелательных последствий для бизнеса.
Итак, учетную запись сотрудника взломали, и персональные данные тысяч клиентов утекли. Злоумышленники зашли в сеть под взломанной учеткой, провели горизонтальное перемещение, оставили агентов С2 и спустя месяц выкачали информацию из баз. Слили имена, контакты, паспортные данные, сведения о родственниках, истории поездок. Всплыли даже пикантные подробности из жизни знаменитостей. Турфирма понесла огромные материальные и репутационные потери, плюс уголовное преследование.
А теперь представим, что в компании использовалась наша система. Сотрудника взломали или он сам передал учетку. При попытке зайти в корпоративную почту запрашивается второй фактор. Если сотрудник сам ввел 2FA, значит, он почти наверняка причастен.
Допустим, сотрудник пошел на хитрость и заявил о краже телефона. В таких ситуациях второй фактор сразу сбрасывается. Злоумышленник не сможет его ввести после проникновения в сеть. Три неудачные попытки — и оповещение улетает безопасникам. Система бьет тревогу, учетка экстренно блокируется. Атака отбита, «крот» выведен на чистую воду, данные клиентов в безопасности.
Вместо заключения
Мы не придумали новых аббревиатур — SSO, MFA, IDM и PAM существуют давно. Но почему-то эти инструменты до сих пор живут в разных консолях, требуют отдельных лицензий и плохо стыкуются друг с другом. Magnus ID — это решение, которое позволяет построить защиту в режиме одного окна и сократить расходы.
Впереди релиз модуля PAM, модуля IDM, новые интеграции. Но первые внедрения показали, что подход 3-в-1 — рабочий.
BigD
Keycloak?
full_moon Автор
Нет, не Keycloak и не его форк. Собственная разработка на Java 21/Spring Boot. Из основного стека также используются JOOQ, Kafka, Redis и другие компоненты, о которых написано в статье.
Пересечение есть только на уровне задач аутентификации и SSO, поэтому аналогия понятна. Но архитектурно и технологически Magnus ID не связан с Keycloak.
BigD
Но, кстати, еще комментарий
это небезопасно абсолютно. MS, например, давно отказался от этого - пуш приходит, но в нем надо ввести код
BigD
Какие гарантии дадите клиенту в подтверждение безопасности решения?