Безопасность и защита информации¶
[ТЗ] Требования определяются приказом ОАЦ № 66 от 20.02.2020 (меры реализации Указа Президента РБ № 449 от 09.12.2019). Средства защиты информации — только подтверждённые по приказу ОАЦ № 77 от 12.03.2020.
Срок [ТЗ]: УЗ должно внедрить систему защиты информации к 40-й неделе 2025 года в рамках подключения к ЦИСЗ.
Юрисдикция
Применяется законодательство Республики Беларусь. Российское законодательство о персональных данных (152-ФЗ) к проекту не относится и в требованиях не используется. Защита персональных данных в РБ регулируется Законом от 07.05.2021 № 99-З «О защите персональных данных» — [ПР], в паспорте прямо не назван, но применим к обработке ПДн пациентов.
Разделение ответственности¶
Не всё из перечня ОАЦ реализуется кодом. Смешение проектных и эксплуатационных мер — типичная причина того, что часть требований не реализует никто.
flowchart TB
subgraph DEV["Закладывается в разработку<br/>(нельзя добавить потом)"]
D1["Журнал событий ИБ<br/>хранение ≥ 1 года"]
D2["ЭЦП электронных документов"]
D3["Блокировка сессии<br/>по бездействию"]
D4["Синхронизация<br/>временных меток"]
D5["Шифрование ПДн<br/>при хранении"]
D6["Разграничение доступа<br/>RBAC"]
D7["Аудит доступа к ПДн"]
end
subgraph OPS["Обеспечивается службой ИБ УЗ"]
O1["Межсетевое экранирование"]
O2["Обнаружение вторжений"]
O3["Антивирусная защита"]
O4["Физический доступ"]
O5["Сегментирование сети"]
O6["Резервное копирование"]
O7["Ежегодные проверки"]
end
subgraph BOTH["Совместно"]
B1["Управление учётными записями"]
B2["Ротация секретов"]
B3["Перечень разрешённого ПО"]
B4["Контроль внешних подключений"]
endЗадачи левой колонки вынесены в эпик E11 со стартом в этапе 1 — попытка добавить их после разработки означает переписывание.
Персональные данные¶
Что относится к ПДн в системе¶
| Данные | Где | Режим |
|---|---|---|
| ФИО, личный номер, полис, адрес, телефон | patients |
Шифрование на уровне приложения (AES-GCM), доступ по RBAC, каждое чтение → audit_log |
| Данные о состоянии здоровья | vital_observations, triage_assessments, monitor_observations |
Врачебная тайна; доступ по роли, привязка к ПДн только через patient_id |
| Диагнозы, анамнез | transport_notifications |
То же |
| Учётные данные персонала | users |
Хеш пароля, отпечаток сертификата |
Минимизация¶
[ПР] Три механизма снижают объём обрабатываемых ПДн:
- Анонимная очередь (FR-T-15). До оформления
appeals.patient_id IS NULL— система хранит только параметры оценки состояния, без паспортной части. Это не обходной путь, а прямое операционное требование, совпавшее с принципом минимизации. - Браслет не содержит ПДн. В штрих-код кодируется внутренний идентификатор обращения, а не ФИО или личный номер — браслет виден посторонним.
- Разделение потоков в ЦИСЗ. Координаты карет, логи запросов, вызовы из палат и сырые Bundle в ЦИСЗ не передаются — см. «Интеграцию с ЦИСЗ».
Обезличивание¶
[ТЗ] Этап 1 включает определение методов обезличивания персональных данных.
[ПР] Предлагаемый подход для аналитики и выгрузок:
| Метод | Применение |
|---|---|
| Исключение прямых идентификаторов | Выгрузки для КПЭ и статистики не содержат patient_id, ФИО, личного номера |
| Замена на суррогатный ключ | Для анализа маршрута пациента — стабильный псевдоним в пределах выгрузки |
| Огрубление | Возраст → возрастная группа; точный адрес → район; точное время → интервал |
| Подавление малых групп | Значения, встречающиеся реже порога, не выводятся (защита от реидентификации) |
Огрубление времени — неочевидно, но необходимо
Точное время доставки в сочетании с районом вызова может однозначно идентифицировать пациента даже без ФИО: в небольшом городе в конкретную минуту в конкретный район ехала одна бригада. Для выгрузок вне контура УЗ время округляется.
Шифрование¶
| Что | Как |
|---|---|
| Передача между вендором и 3H | TLS 1.2+, mTLS с клиентским сертификатом |
| Передача внутри контура | TLS между сервисами; полевая шина RS-485 — изолированный сегмент |
| ПДн при хранении | AES-GCM на уровне приложения; ключи — во внешнем секрет-хранилище |
| Резервные копии | Шифрование бэкапов; отдельный ключ |
| Поиск по зашифрованному | Детерминированный HMAC (personal_no_hash) — индексируемый, не раскрывает значение |
[ТЗ] Требования ОАЦ разделяют средства линейного шифрования (конфиденциальность при передаче по сетям общего пользования) и предварительного шифрования (конфиденциальность при хранении). Реализованы оба.
ЭЦП¶
[ТЗ] Обеспечение подлинности и контроля целостности электронных документов; подтверждение действий врачей.
Подписываются: результат сортировки, обращение в приёмный покой, факт передачи пациента, отказ от медпомощи, выписка из приёмного отделения, утверждение версии правил сортировки. Подробнее — в «Интеграции с ЦИСЗ».
Структура подписываемых документов фиксируется до реализации
Подпись охватывает содержимое. Изменение состава полей после внедрения ломает проверку ранее выданных подписей. Состав подписываемых объектов должен быть зафиксирован на стадии проектирования.
Идентификация, аутентификация, доступ¶
[ТЗ] Требования ОАЦ: разграничение доступа, полномочное управление учётными записями, контроль правил генерации и смены паролей, защита обратной связи при вводе, блокировка по бездействию.
Роли¶
| Роль | Доступ |
|---|---|
operator |
Пульт, журнал запросов мест, ручная передача в МИС |
triage_nurse |
Сортировка, пересортировка, печать талонов, приём пациента |
registrar |
Очередь, оформление, выбытие |
ward_nurse |
Вызовы поста, размещение на койках |
doctor |
Вызовы врача, сводки пациентов |
icu_doctor |
Панель реанимации, оповещения, протокол |
admin |
Провайдеры, устройства, правила, отчётность |
security |
Журналы аудита и событий ИБ — только чтение |
integration |
Сервисная учётная запись вендора; только эндпоинты приёма |
security не имеет доступа к ПДн, admin не имеет доступа к журналам
Разделение полномочий: администратор системы не должен иметь возможности незаметно изменить журнал своих действий, а администратор безопасности не нуждается в доступе к медицинским данным пациентов. Совмещение ролей в одном пользователе допускается только явным решением и само протоколируется.
Сессии¶
| Параметр | Значение |
|---|---|
| Блокировка по бездействию | [ТЗ] Обязательна; [?] конкретное время — настройка УЗ, ориентир 15 мин |
| Блокировка по запросу пользователя | Обязательна |
| Терминал самообращения | Работает без сессии; доступ только к созданию обращения |
| Терминалы палат | Аутентификация по NFC-карте персонала |
| Повторная аутентификация | Требуется для действий с ЭЦП |
Блокировка по бездействию против реальности приёмного отделения
Требование обязательно, но короткий таймаут на АРМ сортировки в разгар массового поступления приведёт к тому, что персонал найдёт способ его обойти — вплоть до заклеенной клавиши. Настройка должна различаться по типам рабочих мест: короткая для АРМ с доступом к ПДн, более длинная для экранов, не показывающих персональные данные (табло, панель реанимации). Табло очереди ПДн не отображает вовсе — только коды талонов.
Журналирование¶
Три журнала с разным назначением и сроком хранения:
| Журнал | Что фиксирует | Срок хранения | Кто читает |
|---|---|---|---|
security_events |
События ИБ: вход, отказ доступа, нарушение прав, изменение учётных записей | ≥ 12 мес [ТЗ] | security |
audit_log |
Действия с ПДн и клинически значимые: чтение карточки, сортировка, передача в МИС, выписка | ≥ 12 мес [ПР] | security |
integration_log |
Обмен с вендорами: запросы, коды ответов, длительность, ошибки | 3–6 мес [ПР] | admin |
[ТЗ] Требование ОАЦ: обеспечение централизованного сбора и хранения информации о событиях ИБ в течение установленного срока, но не менее одного года; определение способа и периодичности мониторинга уполномоченными пользователями.
Партиции журналов ИБ нельзя отцеплять по общему регламенту
ambulance_locations можно чистить агрессивно, security_events — нельзя раньше года. Единая политика ретеншна для всех партиционированных таблиц приведёт к нарушению требования ОАЦ. Политики задаются по таблицам — см. «Ретеншн».
Защита интеграционного периметра¶
flowchart LR
V["Сервер вендора СМП"] -->|"1 · mTLS"| NG["nginx"]
NG -->|"2 · IP allowlist"| NG2["проверка"]
NG2 -->|"3 · подпись тела"| GW["fhir-gateway"]
GW -->|"4 · ограничение частоты"| GW2["обработка"]
GW2 -->|"5 · валидация FHIR"| GW3["приём"]
GW3 -->|"6 · идемпотентность"| DB[("БД")]| Уровень | Мера |
|---|---|
| 1 | Взаимная TLS-аутентификация; сертификат вендора в provider_credentials |
| 2 | Список разрешённых адресов на провайдера |
| 3 | Проверка подписи тела (HMAC/JWS), если вендор поддерживает |
| 4 | Ограничение частоты на сервисную учётную запись; защита от всплеска |
| 5 | Валидация FHIR R4 до бизнес-логики |
| 6 | Уникальность (provider_id, message_uid) — защита от повторов |
[ТЗ] Требование ОАЦ: определение перечня внешних подключений к ИС и порядка такого подключения; обеспечение контроля за внешними подключениями. Реализуется через providers + provider_endpoints как явный, аудируемый реестр.
Секреты¶
| Правило |
|---|
| Ключи, сертификаты, пароли БД — во внешнем секрет-хранилище, не в БД и не в репозитории |
В БД хранится только secret_ref — ссылка |
Ротация с фиксацией rotated_at; срок действия в valid_from/valid_to |
| Компрометация дампа БД не даёт доступа к внешним системам |
Резервное копирование¶
[ТЗ] Требования ОАЦ: определение состава информации, подлежащей резервированию; резервирование информации и конфигурационных файлов сетевого оборудования; защита резервных копий от НСД.
[ПР]
| Что | Периодичность | Хранение |
|---|---|---|
| БД (полный) | Ежесуточно | 30 сут |
| БД (WAL, непрерывно) | Потоково | 7 сут, PITR |
| Конфигурации сервисов и провайдеров | При изменении | Бессрочно, версионируется |
| Правила сортировки | Версионируются в БД | Бессрочно |
| Секреты | По регламенту хранилища | — |
Восстановление должно регулярно проверяться: непроверенный бэкап не является бэкапом. Целевые RTO/RPO — в «Нефункциональных требованиях».
Соответствие требованиям ОАЦ № 66¶
Сводная проверка групп требований паспорта:
| Группа | Где закрывается |
|---|---|
| Аудит безопасности | security_events, audit_log, ретеншн ≥ 12 мес, роль security |
| Защита данных | Шифрование ПДн, защита бэкапов, регламент съёмных носителей (УЗ) |
| Идентификация и аутентификация | RBAC, управление учётными записями, политика паролей, блокировка по бездействию |
| Защита системы защиты | Смена атрибутов по умолчанию, обновление, физический доступ (УЗ), NTP |
| Криптографическая защита | TLS/mTLS, AES-GCM, ЭЦП, контроль целостности |
| Виртуальная инфраструктура | Применимо при виртуализации; резервирование ВМ (УЗ) |
| Иные | Перечень разрешённого ПО, контроль состава ИС, сегментирование, антивирус, межсетевой экран, СОВ, контроль внешних подключений, ежегодные проверки — преимущественно УЗ |
Отнесение к КВОИ ещё не выполнено
[ТЗ] Этап 1 включает «изучение вопроса отнесения создаваемой информационной системы к критически важному объекту информатизации» по приказу ОАЦ № 66. От результата зависит объём применимых требований. До получения ответа проектирование ведётся по более строгому варианту — снизить требования дешевле, чем добавить их после аттестации. См. R-5.