Система многофакторной аутентификации находится на критическом участке корпоративной инфраструктуры. Через нее проходят практически все сценарии доступа пользователей: подключение к VPN, вход в виртуальные рабочие столы, корпоративную почту, внутренние веб-приложения, облачные сервисы и административные панели. Если сервис аутентификации становится недоступным, сотрудники не могут начать работу независимо от того, насколько исправно функционируют остальные информационные системы.

Поэтому выбор между облачной и локальной моделью эксплуатации в первую очередь определяется не экономикой проекта, а требованиями к доступности, отказоустойчивости, безопасности и соответствию требованиям регуляторов.

За последние несколько лет мы реализовали обе модели. MULTIFACTOR используется как классическое on-premise решение внутри инфраструктуры заказчиков и одновременно существует как облачный сервис, который ежедневно обслуживает более миллиона пользователей. За это время стало очевидно, что вопрос «облако или коробка» уже не отражает реальную картину. Гораздо важнее понять, какие требования предъявляются к системе и каким образом должна быть построена ее архитектура.

Эта история началась не с продуктовой сессии, не с исследования рынка и даже не с запроса заказчиков. Отправной точкой стала встреча с коммерческой командой.

Коллеги из отдела продаж искали способ быстрее оценивать внешний периметр потенциальных заказчиков перед демонстрацией MULTISTATUS — сервиса геораспределённого мониторинга доступности веб-ресурсов.

В результате появился инструмент, который сначала помогал демонстрировать продукт заказчикам, а затем оказался полезен и для задач информационной безопасности. Рассказываем, как это произошло и как в этом помогла бот-ферма одного из разработчиков.

Всем привет! Я Дмитрий Милов, Python-разработчик компании МУЛЬТИФАКТОР в команде продукта MULTIDIRECTORY, мы разрабатываем собственную службу каталогов.

Как это обычно бывает в процессе развития продукта, код постепенно перестает помещаться в привычные рамки. Мы начали обсуждать, какое архитектурное решение лучше подходит нашей системе. Спор об определениях затянулся: у каждого были аргументы, почему одно решение лучше другого.

Почему продолжается путаница в концепциях, которые давно описаны и формализованы?

В проектах импортозамещения ИТ-продуктов почти всегда есть одна и та же проблема: нельзя просто взять и отключить уже существующее зарубежное решение. Особенно если речь идёт о службе каталогов и аутентификации. Так как у заказчиков имеется полнофункциональная среда на базе Active Directory, то полная замена в один шаг невозможна как технически, так и организационно.

Отсюда возникает задача: обеспечить плавную миграцию, при которой две системы продолжительное время работают параллельно.

Kerberos — один из тех протоколов, которые в инфраструктуре работают «тихо». Пользователь вошёл в систему один раз, и дальше всё открывается без лишних вопросов. За этим удобством стоит строгая модель доверия, построенная вокруг KDC и тикетов.

Но есть нюанс: классический Kerberos — это по сути однофакторная аутентификация. Если пароль скомпрометирован, вся цепочка доверия находится под угрозой.

В этой статье разберём, как можно усилить Kerberos с помощью второго фактора и как это реализовано в связке MULTIDIRECTORY и MULTIFACTOR.

В корпоративной инфраструктуре точек входа почти всегда больше, чем хотелось бы. Почта, VPN, внутренние порталы, системы разработки, облачные сервисы — у каждого ресурса свой механизм аутентификации, свои требования к паролю и, как следствие, своя зона риска.

Со временем это приводит к типичным проблемам: пользователи начинают повторно использовать пароли, записывать их в заметки, клеить стикеры с паролями на монитор или просто забывать. ИТ-поддержка тратит время на сбросы, а служба информационной безопасности получает дополнительные точки потенциальной компрометации.

На этом фоне технология Single Sign-On (SSO) из удобной опции превратилась в базовый элемент современной инфраструктуры доступа. Она позволяет централизовать аутентификацию и убрать избыточные проверки, не снижая (а при правильной реализации — повышая) уровень безопасности.

Разберёмся, как SSO устроен на уровне протоколов и архитектуры, и как эта технология реализована в системе для многофакторной аутентификации и контроля доступа MULTIFACTOR.

В инфраструктуре почти любой компании служба каталогов — центральный элемент аутентификации и управления доступами. Через неё происходит вход в систему, авторизация в корпоративных сервисах, проверка групп и ролей пользователей.

Пока инфраструктура состоит из одного домена и одного каталога, всё работает достаточно просто. Но в реальности часто возникает необходимость интеграции нескольких каталогов. Это может происходить при слиянии компаний, при построении гибридных инфраструктур или в процессе миграции на новую систему управления идентификацией.

В таких сценариях требуется механизм, позволяющий доменам доверять результатам аутентификации друг друга и обмениваться данными каталога. Для этого используются доверительные отношения между доменами.

Telegram давно стал для нас основным каналом общения с клиентами. Это быстро, привычно и не требует создания отдельных порталов, заполнения логинов-паролей и форм. Клиенты пишут нам так же легко, как друзьям, а инженеры отвечают скринами, логами и командами из терминала.

Но у этого удобства есть обратная сторона. Когда чатов становится не десятки, а сотни и тысячи, начинает побеждать хаос. В какой-то момент мы поняли: либо мы научим Telegram жить по правилам SLA, либо сами перестанем в эти правила укладываться.

В статье расскажем, как мы поддерживаем пилотных и VIP-клиентов прямо в Telegram — без классического Service Desk, но с измеримым и контролируемым SLA.

Если вы не хотите использовать мессенджер MAX для входа на «Госуслуги», альтернативой  может стать стандарт TOTP: генерация одноразовых кодов на устройстве пользователя. В этой статье разберём, как подключить двухфакторную аутентификацию на портале и настроить совместимое приложение-генератор кодов.

2025 год стал для компании МУЛЬТИФАКТОР временем комплексных изменений. Вместо точечных доработок мы сосредоточились на развитии продуктовой системы в целом: полностью переработали логику аутентификации и запустили новый облачный сервис для внешнего мониторинга доступности.

В этой статье мы собрали ключевые обновления продуктов МУЛЬТИФАКТОР за год.

За 2025 год служба каталогов MULTIDIRECTORY прошла значительный путь развития: было внедрено много новых и полезных функций для удобства пользователей, улучшилась производительность, а функционал продукта расширился.

Собрали все самые важные фичи этого года в одном материале.

Push-уведомления давно перестали быть просто всплывающими окошками. Если раньше пуши были просто способом сообщить о событии, то теперь это существенная часть системы безопасности и бизнес-логики компаний в целом. В условиях роста задержек доставки компании перестраивают инфраструктуру уведомлений, переходя на отечественные решения. Как рынок адаптируется к изменениям и как решения компании МУЛЬТИФАКТОР помогают обеспечить надежность доставки, рассказываем в нашей статье.

В корпоративных сетях RADIUS — один из самых распространённых протоколов аутентификации доступа к VPN, Wi-Fi, сетевому оборудованию и терминальным серверам. Но интеграция с 2FA и каталогами пользователей до сих пор часто остаётся самодельной для каждого отдельного админа: костыли, скрипты, нестандартизированные схемы.

Поэтому в MULTIFACTOR мы переработали собственный Radius Adapter и недавно выпустили версию V2 — с кросс-платформенностью, поддержкой нескольких LDAP-источников и переработанной логикой второго фактора. В этом разборе рассказываем, как всё работает и что изменилось в обновлении.

Когда на RDP или VPN одновременно приходит несколько тысяч запросов авторизации, 2FA перестает быть просто удобным способом безопасного входа. Это становится чисто инженерной задачей: как выдержать нагрузку, не потерять запросы на авторизацию и не превратить безопасность в точку отказа.

Мы в МУЛЬТИФАКТОР несколько лет решаем именно этот вопрос — строим систему двухфакторной аутентификации, которая работает в больших и маленьких корпоративных сетях, поддерживает все основные протоколы и при этом не зависит от зарубежных сервисов. В этой статье расскажем о том, как устроена система MULTIFACTOR: архитектура, взаимодействие компонентов и инженерные решения, которые позволяют системе быть стабильной при любой нагрузке.

Привет, Хабр!

Меня зовут Дмитрий Макаров, я руководитель продукта MULTIDIRECTORY — российской службы каталогов с ядром собственной разработки.

После ухода Microsoft с российского рынка многие инженеры и администраторы столкнулись с вопросом: чем заменить Active Directory? При этом ещё нужно сохранить совместимость и привычные инструменты, обеспечить надежность и безопасность. Samba и FreeIPA казались логичным выбором, но на практике часто оказывались либо сильно устаревшими, либо слишком сложными для использования.

Мы решили начать с нуля и создать службу каталогов, которая сочетала бы знакомый функционал AD с современным стеком, гибкой архитектурой и возможностью интеграции в гибридные инфраструктуры. Так началась история MULTIDIRECTORY (MD).

Когда все чеки зеленые, а клиентские чаты полыхают — это говорит о том, что где-то команда DevOps свернула не туда.

Рассказываем историю о том, как мы устали от лавины алертов и собрали свой инструмент распределенного внешнего мониторинга. В статье делимся «внутрянкой», как все устроено и тем, какие грабли словили при развертывании системы.

За последние несколько лет ситуация с кибербезопасностью в России изменилась радикально. Многократно выросли масштабы атак, их сложность и последствия. Геополитическая напряженность превратила страну в одну из наиболее привлекательных мишеней: по информации TAdviser, доля заказных кибератак на российские компании в 2023 году составляла около 10%, а в 2024 году она выросла более чем в 4 раза. Компании сталкиваются уже не с отдельными фишинговыми рассылками, а с многоуровневыми, тщательно подготовленными кампаниями хакерских группировок, работа над которыми может занимать месяцы.