Единый вход в корпоративный портал и интранет: что выбрать и сколько занимает

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

Дальше разговор уходит в аббревиатуры: AD, LDAP, SAML, Keycloak. Заказчик в нём обычно молчит, хотя решение принимает он. Разберём по-человечески: что эти способы означают для интранета, корпоративного портала и клиентского кабинета, что сотрудник увидит на экране входа, что увидит служба безопасности и сколько времени вариант добавит к проекту. Настраивать вам не придётся, выбирать — придётся.

Слова «единый вход» скрывают четыре вопроса, а обсуждают их как один. Где лежит список людей — кто считается сотрудником компании. Кто проверяет пароль — сам портал или система, которая и так проверяет его каждое утро при включении компьютера. Откуда внутри портала берутся роли и права. И что происходит в день увольнения.

Протокол — только второй вопрос, самый технический и самый безобидный. Третий и четвёртый важнее, но их обычно не задают: все спорят про SAML, а потом выясняется, что права в портале живут отдельно от каталога и уволенный менеджер ещё две недели видит список клиентов. Единый вход — не «вход одной кнопкой», а договорённость о том, какая система считается источником правды о людях. Всё остальное — следствие.

Отдельный пароль портала. Человек получает письмо с приглашением и придумывает пароль. Экран входа свой, логотип ваш. Для сотрудника это лишняя сущность, для администратора — лишняя обязанность, для службы безопасности — лишний список, который надо сверять с кадровым. Нормально для пилота, плохо как постоянное решение.

Вход по корпоративной учётной записи через каталог. Экран входа остаётся порталовским, но логин и пароль те же, что от компьютера. Портал не хранит пароль — он спрашивает у каталога, тот ли это человек и в каких он группах. Active Directory и есть такой каталог, он стоит почти в каждой компании со своей ИТ-службой; LDAP — способ к нему обратиться. Сотрудник заметит только то, что пароль стал один. Служба безопасности заметит больше: пароль всё-таки проходит через портал, и это обсуждается отдельно.

Перенаправление на корпоративную страницу входа. Самый заметный для сотрудника вариант: он нажимает «Войти», его перебрасывает на знакомый корпоративный экран — часто тот же, что у почты, — и возвращает внутрь портала. Если он уже входил сегодня в другую систему, портал откроется без вопросов. За этим стоят SAML или OpenID Connect: одна схема старше и привычнее крупным компаниям, вторая новее и удобнее мобильным приложениям. Пароль до портала не доходит ни разу, а второй фактор работает как в остальных корпоративных системах.

Отдельный сервер входа. Keycloak — не протокол, а программа, которая сама становится такой страницей входа: она подключается к каталогу, а порталы и кабинеты подключаются к ней. Сотрудник видит то же перенаправление, так что покупаете вы не удобство, а порядок подключения следующих систем. Ответ на вопрос «когда он нужен» простой: на одной системе — никогда, на двух — спорно, с третьей начинает окупаться. Подключение к отдельному серверу входа занимает дни против недели-полутора на каждую прямую настройку, и экономия идёт не только на сроке: права и роли описываются один раз, а не заново в каждой системе, и при увольнении вы отключаете человека в одном месте, а не в трёх. Если портал у вас один и второго не планируется, этот вариант — лишняя точка отказа.

Безопасники смотрят на три вещи. Где хранится пароль и кто его видел. Остаётся ли след — можно ли через полгода выгрузить, кому и когда выдали доступ. И как быстро доступ снимается.

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

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

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

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

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

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

Отдельный разговор — когда в систему заходят не только сотрудники. Клиенты, агенты, дилеры в корпоративном каталоге не числятся, и заводить их туда не нужно: каталог рассчитан на штат, а не на рынок. Для внешних делается свой контур входа: регистрация с подтверждением почты или телефона, самостоятельное восстановление доступа, при чувствительных данных второй фактор. Сотрудники входят через корпоративный механизм. Два входа в одну систему — архитектура, а не костыль.

Пример системы, где внешние и внутренние пользователи работают в одном продукте, — наш кабинет агента для медицинской группы EMC. Кейс подтверждает два модуля: для медицинских агентов из разных регионов и стран и для сотрудников EMC, где заявки распределяются с учётом загруженности и области экспертизы. Разграничение прав описано в кейсе так: каждый видит только то, что нужно для его работы. Раньше запросы жили в почте, звонках и мессенджерах; после запуска время от поступления запроса до медицинского заключения сократилось на 60%. Способ входа в кейсе не описан, поэтому конструкцию с двумя контурами мы приводим как типовую, а не как решение EMC.

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

Решение «у нас будут внешние пользователи» принимается до проектирования: оно задаёт модель данных — у пользователя появляется принадлежность к организации, у каждого объекта — владелец. На старте это почти ничего не добавляет к срокам: разговор на проектировании и пара дней на то, чтобы права считались от организации, а не только от роли.

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

Поэтому вопрос «кто будет входить, кроме сотрудников» стоит в опроснике выше: ответ меняет не способ входа, а устройство системы.

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

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

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

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

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

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

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

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

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

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

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