🔑 Healthcare IT · SSO · RBAC · MFA

SSO и ролевая модель

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

SSO + RBAC - это связка единого входа через корпоративные и государственные IdP (OAuth2/OIDC, SAML, LDAP) с ролевой моделью доступа на детальных разрешениях по ресурсам и действиям, многофакторной аутентификацией для административных ролей, делегированием с автоматическим отзывом и управлением сессиями. Кто, куда, при каких условиях, под каким контролем - без жёстко прописанных ответов на эти вопросы платформа превращается в «общую папку», что несовместимо с врачебной тайной и регуляторными требованиями.

🧭 Контекст

Почему SSO и RBAC - фундамент медицинской платформы

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

Идентичность снаружи

Платформа ассоциации не хранит пароли членов - это лишняя поверхность атаки и неудобство. Идентичность приходит из корпоративного IdP клиники или госпортала, платформа доверяет токену.

Роли отражают устав

Структура ассоциации (президиум, секции, комиссии, региональные отделения, редколлегии) переносится в роли платформы. Не «всем админам всё», а «председатель этической комиссии видит только дисциплинарные дела».

Минимум привилегий по умолчанию

Новый член получает только базовую роль. Дополнительные роли - только по решению уставных органов и на ограниченный срок. Истечение срока - права отзываются автоматически.

⚠️ Боль

Что ломается без SSO и RBAC

🐾

Зоопарк паролей

У каждого члена ассоциации 5+ систем: МИС, корпоративная почта, госпортал, платформа ассоциации, образовательный портал. Без SSO он использует один пароль везде - утечка из любой системы открывает доступ ко всем.

🚪

Уволенный остался с доступом

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

👁️

Админ видит всё

Без ролевой модели один технический администратор имеет полный доступ ко всем модулям: финансы, peer review, голосования, аккредитации. И риск утечки, и риск злоупотребления.

🤝

Делегирование руками

Председатель в отпуске - заместитель работает под чужой учёткой с её паролем. В аудит-логах действия числятся за председателем. Если что-то пойдёт не так - разобраться невозможно.

⚙️ Подход

Архитектура SSO + RBAC

Архитектура - это три SSO-протокола под все распространённые IdP, маппинг атрибутов IdP в роли платформы, детальные разрешения на ресурсы и действия, MFA по ролям и операциям, управление сессиями и делегирование с полным аудитом.

1. Поддержка протоколов

OAuth2/OIDC, SAML 2.0, LDAP - три протокола покрывают все распространённые корпоративные и государственные IdP. Платформа выступает как service provider, доверяя identity providers из заданного списка.

2. Маппинг IdP в роль

После аутентификации в IdP платформа берёт атрибуты из токена (организация, должность, специализация) и сопоставляет с реестром членов. Базовая роль присваивается автоматически, дополнительные - по решениям уставных органов.

3. Детальные разрешения

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

4. Многофакторная аутентификация

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

5. Управление сессиями

Сессии с ограниченным сроком, автоматическое продление при активности, принудительный выход при изменении роли, единый logout через IdP. Член ассоциации видит список активных сессий и может прервать любую.

6. Делегирование с аудитом

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

📊 Доказательство в production

Как это работает на десятках тысяч учётных записей

Во флагманском кейсе SLAtech модуль SSO + RBAC обслуживает 40+ тысяч учётных записей с дифференцированными ролями через три SSO-протокола - OIDC, SAML, LDAP - с поддержкой корпоративных и государственных IdP, обязательным MFA для административных ролей и делегированием с автоматическим отзывом.

40K+

Учётных записей с дифференцированными ролями

3 протокола

OIDC + SAML + LDAP

19 лет

Непрерывной эксплуатации модуля без переписывания

Открыть раздел кейсов

❓ Частые вопросы

Частые вопросы о SSO и RBAC

Зачем медассоциации SSO?

Член ассоциации работает в клинике (корпоративная учётка), госмедсистеме (учётка регулятора) и в платформе ассоциации. Отдельный пароль - это неудобство и угроза безопасности. SSO позволяет логиниться через корпоративную или госпорталовскую учётку - платформа доверяет IdP, не хранит свои пароли. Снижает риски утечки, упрощает onboarding и offboarding.

Какие SSO-протоколы поддерживаются?

OAuth2/OpenID Connect для современных IdP (Azure AD, Okta, Keycloak, государственные порталы), SAML 2.0 для классических корпоративных IdP, LDAP для интеграции с внутренними AD клиник. При необходимости - собственная учётная запись для членов, у которых нет корпоративной идентичности. Список разрешённых IdP контролируется администратором ассоциации.

Что такое RBAC и как он устроен?

RBAC - модель, где доступ определяется ролями пользователя, а не индивидуальными разрешениями. Роли в платформе ассоциации: член ассоциации, редактор журнала, председатель секции, координатор аккредитации, администратор взносов, главный администратор (полный доступ с обязательным MFA). Каждой роли соответствует набор разрешений на конкретные ресурсы.

Может ли один пользователь иметь несколько ролей?

Да, это типичный случай. Член ассоциации, одновременно председатель секции и редактор журнала - имеет три роли с пересекающимися правами. В интерфейсе доступны функции всех ролей, но каждое действие выполняется в контексте конкретной роли - это важно для аудита (см. Защита данных).

Как обеспечивается многофакторная аутентификация?

Уровень MFA настраивается по ролям и операциям. Для базовых функций члена MFA не обязателен (если корпоративный IdP уже его обеспечивает). Для административных ролей - обязателен: TOTP или push. Для критических операций (массовое удаление, инициирование выборов) - повторное MFA-подтверждение в активной сессии. Новое устройство - обязательный MFA независимо от роли.

Как реализовано делегирование полномочий?

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

🔗 Связанные направления

Что соприкасается с SSO и RBAC

🔒

Защита персональных данных

RBAC как технический фундамент защиты - каждая роль видит только свой срез чувствительных данных с логированием каждого обращения.

Подробнее

🗳️

Электронные выборы

SSO - точка входа избирателя в кабинет голосования с проверкой права голоса по реестру членов.

Подробнее

🩺

Регистрация и верификация

SSO определяет, как новый член ассоциации заводится - через корпоративную учётку, госпортал или внутренний пароль.

Подробнее

Нужны SSO + RBAC для вашей медорганизации?

Разберём ваш ландшафт identity providers и архитектуру ролевой модели под структуру вашей ассоциации - на десятках тысяч учётных записей с дифференцированными ролями.

Обсудить проект Обзор медицинских IT-платформ