ГОСТР ИСО 27789—2016
Обязательная функциональность. Формирование списка случаев доступа к медицинским картам через логин
врача’ пользователя; формирование / демонстрация списка неуспешных попыток доступа; и формирование сигна
лов тревоги в момент, когда фиксируется событие, не уполномоченное разрешительными документами.
- Любой случай использования (низкого/ высокого уровня) требует возможности ретроспективного анализа
аудита: «дайте мне данные, и я их проанализирую».
- Данный сценарий существует только для установления того, чтобы аудит мог быть «запрошен» по иденти
фикатору процесса (PID). а также по успешным’ неуспешным результатам события.
Проблемы:
- в реальном мире существует множество случаев автоматизированной предварительной подкачки и кэши
рования данных. В большинстве транзакций поставщик или имя субъекта получения медицинской помощи указаны не
в данных, а в информации связанного с ними приложения. Наглядный пример. Если человеку назначен прием, то его
данные предварительно демонстрируются на экране в смотровом кабинете. Сервис аудита должен быть в
состоянии сверять, кто был подключен к смотровому кабинету в то время, когда был назначен прием;
- неавториэсванные попытки получить доступ, как указано выше, соседом поставщика медицинских услуг,
должны либо отслеживаться приложением, либо проявляться как запросы от неожиданного источника:
- «сервис-наблюдатель» может иметь белый список смотровых кабинетов, которые могут предварительно
просматривать данные и отправлять уведомление, если запрос поступает от неожиданного источника и/или в на
рушение разрешительныхдокументов или документов по получению доступа. Определение того, когда и по какому
поводу сервис-наблюдатель оповещает, относится к вопросам местной политики.
А.4 Случай взломанного сервера
Недавно начал работать реестр состояния здоровья населения, и лицо, создавшее сервер, отказалось сме
нить пароль администратора. Некий хакер находит сервер и начинает использовать его. чтобы атаковать друтив
системы спамом от реестра состояния здоровья населения. Из-за необычно большого объема событий аудита
и случаев доступа уровня администратора с неизвестного IP-адреса должностному лицу, ответственному за
обеспе чение защиты отправляется сигнал, и это лицо сразу же проверяет журналы аудита и понимает, что
произошло, и может это прекратить. Дальнейший анализ журналов аудита обнаруживает некоторые
дополнительные уязвимо сти, которые не были видны при установке системы, и производится усиление защиты
для повышения защищен ности системы.
Это другой тип сервиса приложения, а также другой тип аудита.
Эти записи аудита будет создавать защитная система. Журналы маршрутизатора не характерны для
здравоохранения.
Обязательная функциональность. Необходимо «архитектурно» соответствовать тому, как профессиональ
ная IT-индустрия решает эту проблему.
Факт отправления сигнала тревоги также подлежит аудиту.
А.5 Случай уполномоченного пользователя, который злоупотребляет этими полномочиями
Некое лицо просит своего партнера устроиться на работу в качестве регистрирующего агента в новой ин
формационной Системе / Регистре поставщиков по лекарственным средствам и затем зарегистрировать это лицо и
других лиц как врачей с правами электронного назначения, чтобы они могли незаконно назначать лекарственные
средства.
Часто единственным способом раскрыть такой тип событий является естественная подозрительность или
случайный анализ журналов аудита.
Как можно своевременно на это реагировать? Может ли аудит и мониторинг помочь обнаружить необычные
случаи назначения подлежащих контролю лекарственных средств? (Резкий скачок в назначении морфина?) Наи
меньшее. чем может помочь система. — это немедленное предоставление доказательств несанкционированных
регистраций при обнаружении пользователя, злоупотребляющего полномочиями, а также список всех «врачей»,
зарегистрированных при использовании учетной записи пользователя, злоупотребляющего полномочиями.
Обязательная функциональность. Формировать список успешных событий регистрации пользователя.
Дополнительная функциональность. Делать перекрестные ссыпки между сервисом аудита и другими серви
сами для определения области нарушения.
Потенциальная функциональность для сервиса ID Mgmt. Сверять личность в регистре поставщиков с учет
ными данными поставщиков.
А.6 Случай неправильно направленных результатов исследований
Субьект получения медицинской помощи ждал свои результаты лабораторных исследований уже в течение
двух недель, когда врач сообщил ему, что при использовании новой информационной системы лаборатории ре
зультаты должны быть доступны менее чем через 48 часов. Когда субьект получения медицинской помощи звонит в
офис своего врача, обнаруживается, что в офисе имеется запись о заказе результатов из лаборатории, но не
сами результаты. Медсестра звонит в лабораторию и спрашивает, что случилось с результатами исследований.
Лаборатория проверяет свои журналы аудита и находит номер полученного заказа результатов из лаборатории,
а также результаты лабораторных испытаний, которые были отправлены в ответ. Лаборант проверяет, куда были
29