Права доступа и роли (RBAC) в клинике

Зачем клинике роли и наименьшие привилегии

Через одну и ту же систему частной клиники каждый день проходят десятки людей: врачи, медсёстры, регистратура, биллинг, администратор, а иногда и внешние подрядчики. Все они так или иначе касаются данных пациентов, но не всем нужно видеть одно и то же. Когда у каждого пользователя есть полный доступ ко всему, любая человеческая ошибка или скомпрометированный аккаунт превращаются в инцидент масштаба всей системы. Отраслевой ответ на это — RBAC (Role-Based Access Control), управление доступом на основе ролей.

Идея проста: вместо того чтобы привязывать права к каждому человеку по отдельности, вы определяете роли, привязываете каждое право к роли и назначаете каждому сотруднику подходящую роль. Новый сотрудник получает роль — и сразу же имеет ровно нужный доступ, не больше и не меньше. Дополняющий принцип — least-privilege, принцип наименьших привилегий: каждая роль получает минимум, необходимый для работы, и ничего сверх этого. Вместе эти два принципа сокращают поверхность атаки, упрощают аудит и облегчают соответствие ожиданиям приватности вокруг медицинских данных.

Базовые роли в клинике

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

• Врач / специалист — читает и пишет клиническую карту, открывает визиты, выписывает рецепты, заказывает анализы.
• Медсестра — фиксирует витальные показатели, готовит визит, ведёт препараты и прививки, обычно в более узком клиническом объёме, чем врач.
• Регистратура — управляет записями, демографией и коммуникацией, без глубокого клинического содержания.
• Биллинг / финансы — работает со счетами, требованиями, платежами и балансами, и нуждается только в обосновывающем диагнозе, а не в полной клинической карте.
• Администратор — настраивает систему, роли и права, но не обязательно вносит текущее клиническое содержание.
• Внешний пользователь — консультант, аудитор или поставщик с ограниченным и временным доступом.

Что такое матрица прав

Матрица прав — это двумерная таблица: в строках роли, в столбцах объекты доступа (типы данных и действия), а в каждой ячейке уровень права — нет доступа, только чтение, чтение и запись или управление. Матрица превращает расплывчатый вопрос («кто и к чему может прикоснуться?») в явный документ, который можно проверять, сопровождать и объяснять. Это же и контракт, по которому оценивается любой нестандартный запрос на доступ.

Пример матрицы

Объект / Роль	Врач	Медсестра	Регистратура	Биллинг	Админ	Внешний
Записи (торы)	Чтение/Запись	Чтение/Запись	Чтение/Запись	Чтение	Настройка	Ограниченно
Карта пациента	Полный	Клинически, узко	Только демография	Ограниченно	Нет	Ограниченно
Визиты и формы	Запись	Частичная запись	Нет	Чтение для кодирования	Нет	Ограниченное чтение
Рецепты	Запись	Чтение	Нет	Нет	Нет	Нет
Финансы	Чтение	Нет	Чтение	Полный	Чтение	Нет
Админ и права	Нет	Нет	Нет	Нет	Полный	Нет

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

Права на уровне формы и поля

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

Журнал аудита и как ловить аномалии

Хорошая матрица определяет, что разрешено; журнал аудита (audit log) фиксирует, что произошло на самом деле. Каждый просмотр, редактирование, экспорт или печать чувствительной информации записываются: кто, когда, к какой записи и какое действие. Ценность журнала зависит от его целостности — если его можно тихо отредактировать, он бессмыслен. Поэтому строки обычно защищают от ретроспективного изменения.

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

Break-glass — аварийный доступ как понятие

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

Уход сотрудника или смена роли

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

Чек-лист настройки прав

• Опишите все реальные роли, включая внешние и временные.
• Определите для каждой роли минимально необходимое право (least-privilege).
• Постройте явную матрицу прав и задокументируйте её.
• Точечно закройте чувствительные формы и поля на уровне роли.
• Убедитесь, что журнал аудита активен и защищён от подмены.
• Согласуйте с поставщиком процедуру аварийного (break-glass) доступа.
• Определите чёткий процесс ухода и смены роли с немедленным отзывом доступа.
• Запланируйте периодический пересмотр прав и журнала аудита.

Что подтверждено в CareOS

Модуль администрирования CareOS включает матрицу прав из 65 объектов доступа по 6 ролям, наряду с 492 настройками конфигурации по доменам и дизайнером форм, не требующим разработки (F-M10). Права не заканчиваются на уровне модуля: их можно задавать на уровне отдельной формы внутри визита (F-M3). Журнал аудита ведётся с подписью целостности на каждой строке (F-M10), а запись лечения включает полный лог доступа к записи — кто смотрел и когда (F-M8). CareOS спроектирована с учётом требований приватности медицинских данных в Израиле, но не претендует ни на какой стандарт или сертификацию.

Заключение

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

Хотите увидеть, как матрица прав выглядит на практике? Запишитесь на демонстрацию CareOS — вместе разберём роли, права на уровне формы и журнал аудита для вашей клиники.

Назад в блог