Единый вход в закрытом контуре: один каталог для порталов, 1С и языковой модели
Доступ выдаётся и отзывается в одном месте, а язык модели видит только те документы, на которые у человека есть права
Проверяется: матрица ролей и тест отзыва доступа
ГоссекторРаботаем по NDA
В закрытом контуре работают портал, 1С, почта, система заявок и, в перспективе, частная языковая модель. У каждого сервиса свои учётные записи. Сотрудника принимают, увольняют и переводят, а права в каждой системе меняют вручную и не одновременно. Служба безопасности просит журнал входов, которого нет в одном месте.
Что съедает срок и бюджет на самом деле
Задача выглядит как настройка входа, но ломается на данных и людях. Ниже, где именно.
Каталога пользователей нет или их два
часть людей заведена в одном каталоге, часть в другом, часть только в прикладных системах. Пока нет источника истины, единый вход переносит беспорядок, а не убирает его.
Не все сервисы умеют внешний вход
старая 1С, самописные кабинеты и внутренние утилиты работают на собственных паролях. Для каждого нужен способ подключения: стандартный протокол, прокси перед сервисом или временная привязка.
Роли берутся из групп, а группы живут своей жизнью
вместо матрицы «кто и что может» в каталоге десятки исторических групп. При подключении ИИ-ассистента вскрывается, что права на документы определяются тремя разными способами.
Отзыв доступа проверяют только после инцидента
учётная запись уволенного исчезает из каталога, но остаётся рабочая сессия или локальный пароль в прикладной системе.
Ограничение, которое определяет решение
В закрытом контуре нельзя использовать внешние сервисы входа, поэтому каталог, сервер аутентификации и журнал живут на ваших серверах. Выбор между открытым решением и отечественным программным продуктом из реестра определяют требования вашего заказчика или регулятора. Сертификацию средств защиты и аттестацию мы не проводим: лицензии ФСТЭК у нас нет.
Как проверить, что работа сделана
Приёмка держится на проверке, а не на документах. Матрица ролей: по каждой должности записано, к чему она имеет доступ, и вы сами выбираете несколько человек и сверяете запись с тем, что они видят.
Отзыв доступа: тестового сотрудника «увольняем» в каталоге, и в течение согласованного времени он теряет вход во все подключённые сервисы, а сессии закрываются.
Журнал: каждый вход и отказ попадает в одно место, откуда его можно выгрузить службе безопасности. Для языковой модели отдельно проверяется, что чужой документ не попадает в ответ.
О чём спросить любого подрядчика
- Откуда будут браться роли: из групп каталога или из матрицы, которую ведёт заказчик. Ответ «из существующих групп» без разбора групп настораживает.
- Как подрядчик подключает сервисы, которые не умеют внешний вход, и что делает с локальными паролями.
- Как проверяется отзыв доступа и с каким допустимым запаздыванием.
- Где хранится журнал входов, кто его читает и как быстро он выгружается.
- Что будет с входом, если сервер аутентификации недоступен, и есть ли режим для аварии.
Как мы идём по этапам
На каждом этапе назван результат, который остаётся у заказчика. Остановиться можно после любого.
- Инвентаризация учётных записейСобираем каталоги, прикладные системы и способы входа в каждой. Результат: реестр сервисов и источников пользователей.
- Матрица ролейВместе с вашими специалистами записываем, какая должность к чему имеет доступ. Результат: таблица, которую можно проверить.
- Сервер аутентификацииПоднимаем его в контуре, подключаем каталог, настраиваем журнал. Результат: рабочий стенд с тестовыми пользователями.
- Подключение сервисов по очередиНачинаем с тех, что умеют стандартные протоколы, затем сервисы с прокси. Результат: список подключённых и список исключений с причинами.
- Проверка и передачаОтзыв доступа, сверка ролей, проверка выдачи документов языковой моделью. Передаём настройки и инструкцию вашим администраторам.
Как это обычно устроено внутри
Типовая схема: каталог пользователей хранит людей и группы, сервер аутентификации выдаёт сервисам подтверждение входа по стандартным протоколам (OpenID Connect, SAML, Kerberos или LDAP), роли передаются в виде групп или утверждений. Перед сервисами без поддержки внешнего входа ставится прокси, который проверяет сессию. Для частной языковой модели роль и группа пользователя передаются в слой поиска, и фильтр прав применяется до того, как фрагмент документа попадает в контекст.
- Keycloak
- FreeIPA
- LDAP
- Kerberos
- OpenID Connect
- SAML
- Обратный прокси
Похожая задача у вас?
Разберём её на созвоне за 40 минут: назовём объём работ, ограничения контура и по каким числам вы будете принимать результат. Если задача не наша — скажем прямо.