🔒 Healthcare IT · 152-ФЗ · GDPR · Аудит доступа

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

Архитектура защиты персональных данных в платформе медассоциации - на стыке 152-ФЗ, GDPR и врачебной тайны, часть медицинской IT-платформы.

Защита персональных данных - это связка процессов и архитектурных решений: классификация чувствительных данных с минимизацией состава, уровневое шифрование, ролевое разграничение доступа, логируемый аудит обращений, версионируемое управление согласиями, реализация права на забвение с прозрачным отчётом субъекту и процедуры реагирования на инциденты - в соответствии с 152-ФЗ, GDPR и врачебной тайной.

🧭 Контекст

Почему защита данных в медассоциации - это отдельная категория

Данные о здоровье - отдельная категория с повышенной защитой и в 152-ФЗ, и в GDPR. Платформа ассоциации работает на стыке: персональные данные специалистов плюс псевдонимизированные ссылки на клинические случаи. Регулятор приходит с проверкой чаще, чем в обычные ИТ-системы, а доверие членов к ассоциации - это фундамент, который нельзя пересобрать после утечки.

Медицинская специфика

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

Регулятор смотрит

Медицинская организация и профессиональная ассоциация - приоритетные объекты проверок надзорных органов. Архитектура должна быть готова к проверке Роскомнадзора, прокуратуры, аудитора по информационной безопасности.

Доверие как актив

Защита данных десятков тысяч специалистов - не формальное соответствие, а сохранение фундамента доверия членов к организации. Это требует проектного подхода, а не «галочки в проверке».

⚠️ Точки риска

Что ломается в медицинских платформах

👁️

Один админ - всё видит

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

🔓

Шифрование «на бумаге»

TLS на канале есть, но в БД пароли в открытом виде, банковские реквизиты - plain text, ключи лежат рядом с данными. Атака на сервер сразу выливает всё - шифрование оказывается фиктивным.

📝

Согласия - формальность

При регистрации галочка «согласен с обработкой ПДн», состав целей - общими словами на 20 строк. При проверке регулятор требует увидеть, на что конкретно согласился субъект - этого показать невозможно.

🗑️

Удалили только частично

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

⚙️ Подход

Архитектура защиты данных

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

1. Классификация и минимизация

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

2. Шифрование уровневое

TLS на канале, шифрование БД на диске, отдельные зашифрованные хранилища для самых чувствительных категорий (паспорта, банковские реквизиты, сканы документов) с независимыми ключами. Ключи в системе управления с ротацией и аудитом использования.

3. Ролевая модель

RBAC с детальными правами (см. SSO и ролевая модель): администратор взносов, редактор журнала, председатель этической комиссии, координатор аккредитации - каждая роль видит только свой срез данных, попытка выйти за рамки отказывается и логируется.

4. Аудит доступа

Каждое обращение к чувствительным данным логируется с timestamp, идентификатором оператора, объёмом выгрузки. Логи защищены отдельно - администратор данных не может удалить записи об обращениях. Член ассоциации видит, кто заходил в его профиль.

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

При регистрации согласия собираются по конкретным целям с галочками, текст согласия версионируется. Когда меняется состав обработки - субъект получает уведомление и подтверждает новую версию. Журнал согласий показывает, на что и когда субъект соглашался.

6. Право на забвение

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

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

Как это работает на десятках тысяч субъектов

Во флагманском кейсе SLAtech модуль защиты данных обслуживает 40+ тысяч записей субъектов на стыке двух регуляторных контуров - 152-ФЗ и GDPR - с уровневым шифрованием, ролевой моделью доступа, аудитом обращений и версионируемыми согласиями.

40K+

Записей субъектов под защитой

152-ФЗ + GDPR

Двойной контур соответствия

19 лет

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

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

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

Частые вопросы о защите персональных данных

Какие данные обрабатывает платформа медассоциации?

Персональные данные специалистов (ФИО, образование, лицензии, контакты, банковские реквизиты), данные клинической активности (счётчики операций, peer review случаев, аккредитационные результаты - частично псевдонимизированно), финансовые данные по членским взносам, голосования (отдельная криптографическая схема, см. Электронные выборы). Прямых клинических данных пациентов платформа обычно не хранит - это домен МИС клиник.

Как обеспечивается соответствие 152-ФЗ?

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

Как реализован принцип разграничения доступа?

Доступ построен на ролевой модели (см. SSO и ролевая модель): каждая роль видит только тот срез данных, который нужен для её функции. Администратор взносов видит платежи, но не peer review. Редактор журнала видит рукописи, но не банковские реквизиты. Каждое обращение к чувствительным данным логируется.

Что хранится в зашифрованном виде?

TLS на канале (все endpoint). На уровне хранения шифрование по чувствительности: банковские реквизиты, паспортные данные, скан-копии документов - отдельные зашифрованные хранилища с ограниченным набором ключей. Голосования - криптографическая схема с разделением каналов авторизации и бюллетеней. Резервные копии - отдельным ключом. Ключи в системе управления с ротацией.

Как пользователь реализует право на забвение?

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

Как реагирует платформа на инцидент с данными?

Мониторинг аномалий доступа: массовая выгрузка, обращения вне рабочих часов, попытки выйти за пределы роли - триггерят уведомление и временную блокировку учётной записи. Процедура: фиксация в журнале, расследование, оценка масштаба, уведомление субъектов и регулятора в установленные сроки (для 152-ФЗ - 24 часа в случае утечки), меры по устранению причины.

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

Что соприкасается с защитой данных

🔑

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

Технический фундамент разграничения доступа к чувствительным данным - кто, куда, при каких условиях, под каким контролем.

Подробнее

🏛️

Интеграция с госреестрами

Защищённый обмен данными с государственными системами - отдельный слой защиты с взаимной аутентификацией сервисов.

Подробнее

🗳️

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

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

Подробнее

Нужна архитектура защиты данных для вашей медорганизации?

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

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