Два года OneIdP: построение системы нулевого доверия, выходящей за рамки идентификации.

опубликованный 16 июня 2026 by Шрирам Какарала in Из штаб-квартиры

Есть вопрос, который каждый IT-администратор в конце концов перестаёт задавать вслух, потому что смирился с тем, что на него нет однозначного ответа.

«Почему я знаю всё об этом устройстве, но почти ничего не знаю о том, кто сейчас сидит перед ним?»

Главный баннер, рекламирующий доступ по принципу «нулевого доверия», с заголовком «Для принципа нулевого доверия нужно больше, чем просто подтвержденная личность», а также логотипами One Identity и ScaleFusion слева и справа.

У вас есть информация о статусе обновлений, соответствии стандартам, инвентаризация приложений и местоположение. Вы можете удалить все это удаленно в 2 часа ночи со своего телефона. Но что насчет человека, входящего в систему в 9 утра? Это все равно в значительной степени соглашение, достигнутое на словах, и пароль, который, вероятно, кто-то использовал повторно с трех других учетных записей.

Именно из-за этого и существует OneIdP. И вот, спустя два года, честная история о том, что потребовалось для его устранения.

В каком мире на самом деле жили ИТ-команды?

Традиционный ответ уже давно устоялся: купить инструмент IAM, подключить его к UEM, а SSO настроить где-то посередине. 

Разные поставщики, разные панели управления и разные места, где ваша политика может незаметно противоречить сама себе в тот момент, когда возникает нестандартная ситуация.

Более глубокая проблема заключалась в том, что Scalefusion Общеизвестно, что корпоративные ИТ-среды строятся не на основе идеальных сценариев, а на основе исключений. К таким исключениям относятся, например, совместное использование устройств, удалённое оформление новых сотрудников, подрядчики, работающие на личных ноутбуках, и распределённые команды в пяти часовых поясах.

Это были не какие-то исключительные случаи, которые нужно было учитывать. Это были реальные условия эксплуатации.

Однако большинство стратегий доступа по-прежнему разрабатывались для мира, где все приходят в один и тот же офис, используя одно и то же управляемое устройство, каждый божий день. Поэтому аутентификация стала заменой всему. Аутентификация рассматривалась как решенная проблема. Проверить пароль, предоставить сессию. Готово.

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

Именно этот пробел мы и стремились закрыть.

Что мы выпустили в первый же день — и почему это было только начало.

При запуске OneIdP мы сделали осознанный выбор, который большинство продуктовых команд не делают. Мы выпустили основу, а не просто список функций.

Облачный каталог. Условный доступ через Keycard. Многофакторная аутентификация, интегрированная в ту же панель управления, которую ИТ-команды уже использовали ежедневно. Основа была намеренно прочной, прежде чем продукт стал многофункциональным. 

Ключ-карта Это позволяет ИТ-командам устанавливать реальные условия доступа — разрешенные местоположения, доверенные диапазоны IP-адресов, конкретные сети Wi-Fi и временные окна. Для команд, использующих общие пароли и вход в систему без контекста, даже первая версия представляла собой другой способ работы.

Твердая земля, до того, как мы начали строительство.

А потом произошло нечто, что показало нам, что фундамент действительно заработал. И уже через несколько месяцев клиенты не спрашивали, работает ли OneIdP. Они уже думали о том, что будет дальше. 

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

Это была карта, и мы следовали ей.

Два года подготовки к этой реальности.

Большинство инструментов управления идентификацией основаны на предположениях.

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

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

Мы опросили всех троих.

1. Для предоставления доступа достаточно указать свои личные данные.

Система единого входа (SSO), в том виде, в котором она всегда использовалась в отрасли, останавливается в момент проверки учетных данных. Пользователь подтверждает свою личность. Сессия разрешена.

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

Мы построили Расширенные политики доступа (XAP) задать именно этот вопрос.

Каждый вход в систему проверяется на соответствие полной картине. Сигналы о соответствии устройств требованиям в режиме реального времени от Veltar напрямую влияют на решение о доступе. Если что-то не соответствует требованиям, доступ прекращается до того, как что-либо будет открыто. Никакой ручной проверки. Никакого вмешательства администратора. Политика просто работает.

Затем мы рассмотрели другую сторону той же проблемы.

На устройстве, которое OneIdP уже знает и которому доверяет, повторный ввод пароля ничего не добавляет. Это лишь неудобство, которое незаметно сообщает человеку за экраном, что ИТ-отдел ему не доверяет. Расширенный единый вход (SSO) на управляемых устройствах полностью устраняет это. Статус соответствия устройства становится учетными данными. Взаимодействие становится незаметным — в самом лучшем смысле этого слова.

2. Вы начнете все заново с обретением собственной идентичности.

В каждом предложении типа «просто переключитесь на нашу платформу» есть один и тот же недостаток.

Предполагается, что ИТ-команды откажутся от многолетней настройки каталогов, интеграции с поставщиками идентификации и политик доступа и начнут все заново в новом инструменте. Для команды, управляющей 800 устройствами на двух континентах, это непростая задача.

Федерация Идентификаций была создана именно для этой цели.

OneIdP выступает в качестве уровня политик доступа поверх уже существующей инфраструктуры. Entra, Google Workspace, Okta, PingOne или локальные установки Active Directory, созданные до прихода нынешней ИТ-команды, — всё это остаётся на месте. 

Мы пошли еще дальше, СКИМ Входящие и исходящие соединения. При приеме на работу доступ предоставляется автоматически. При изменении роли доступ адаптируется. При увольнении учетные записи удаляются без создания заявки в службу поддержки или пропуска каких-либо ручных действий. Информация о численности персонала во всех подключенных приложениях остается актуальной.

3. Всегда найдётся кто-то, кто будет этим управлять.

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

Пароли локального администратора Это хороший пример проблемы, которая незаметно работает на заднем плане, пока не перестанет работать. Идентичные учетные данные на сотнях машин, неизменные в течение нескольких месяцев, потому что их ручная смена — это задача, на которую ни у кого нет времени. LAPS автоматизировал этот процесс. Смена происходит по расписанию. Каждые учетные данные проходят аудит. Риск исчезает, не требуя от кого-либо каких-либо действий.

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

Единый вход на основе устройств решил проблему совместного использования устройств, которая оставалась нерешенной с момента запуска. Любой зарегистрированный пользователь на управляемом компьютере получает доступ к своему приложению. Перерегистрация между сменами не требуется. Доступ сохраняется за пользователем. Устройство остается готовым для следующего пользователя.

Функция SSO Access Logs автоматически предоставляла каждому руководителю службы информационной безопасности (CISO) запрошенный им журнал аудита во время первой проверки безопасности — без необходимости его создания в электронных таблицах.

Три предположения. Три обдуманных решения строить по-другому.

Но решения, принимаемые на бумаге, и решения, принимаемые в процессе производства, — это две совершенно разные вещи.

Вот как всё на самом деле развернулось.

Честно говоря, хронология событий такова.

Полезно понимать, как всё это разворачивалось — не как план развития продукта, а как серия ответных действий на то, что мы узнавали:

Июнь 24-го

Запуск OneIDP

Справочник, единый вход, ключ-карта.

1 квартал 24 г.

Интеграция с поставщиками идентификационных данных

GWS, Entra, Okta, PingOne, локальная служба Active Directory и т. д.

3 квартал 24 г.

Пользовательский портал и федерация идентификации

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

2 квартал 25 г.

SCIM v2.0 — Масштабирование ресурсов

Пользователи синхронизируются. Уволившиеся сотрудники автоматически лишаются доступа.

3 квартал 25 г.

Расширенные политики доступа (XAP)

Предоставляйте доступ к единому входу (SSO) на основе соответствия устройства требованиям, местоположения, IP-адреса и наличия приложения.

4 квартал 25 г.

Единая интеграция на основе устройств + LAPS

Предоставление совместимым управляемым устройствам возможности доступа к приложениям независимо от того, кто вошел в систему.

1 квартал 26 г.

Назначение SSO на основе групп пользователей

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

2 квартал 26 г.

пароли

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

Как на самом деле выглядит OneIDP сегодня

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

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

Этот переход от основы к полноценной платформе — именно то, к чему мы и стремились.

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

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

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

Именно этим балансом мы больше всего гордимся.

Что будет

Два года работы в команде ИТ-специалистов учат полезному: проблема всегда масштабнее той, которую вы только что решили.

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

Сфера применения принципов нулевого доверия в управлении доступом постоянно расширяется, и мы намерены расширяться вместе с ней.

Шрирам Какарала
Шрирам Какарала
Шрирам занимается разработкой мобильных приложений более 10 лет. Его опыт включает работу над решением BYOD, специальной ОС Android для предприятий и многоканальными клиентами чата для потребителей. У него был опыт работы как со стартапами на ранних стадиях, так и с застрявшими компаниями среднего размера и многонациональными корпорациями, находящимися на грани застоя. На личном уровне он считает, что хороший сэндвич – это все, что нужно миру!

Больше из блога

Конференция Apple WWDC 2026: Восхождение ОС, которая...

Всемирная конференция разработчиков Apple 2026 открылась в Apple Park, и три темы постоянно звучали на протяжении всей презентации: производительность, дочерние приложения...

Примеры использования IAM: Решение проблем идентификации и доступа в...

Управление идентификацией и доступом (IAM) превратилось из функции бэкэнд-ИТ в ключевую бизнес-стратегию. В контексте SaaS...

SSO против MFA: объяснение ключевых различий

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