Национальный стандарт РФ ГОСТ Р ИСО/ТС 22600-1-2009 "Информатизация здоровья. Управление полномочиями и контроль доступа. Часть 1. Общие сведения и управление политикой" (утв. приказом Федерального агентства по техническому регулированию и метрологии от 14 сентября 2009 г. N 410-ст)

Health informatics. Privilege management and access control.
Part 1. Overview and policy management

Дата введения - 1 июля 2010 г.

Введен впервые

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения".

Введение

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

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

Ситуация становится еще более сложной, когда для взаимодействия требуется пересечение периметров зон с разными политиками безопасности. Для преодоления различий между этими политиками необходимы взаимные соглашения о политиках между сторонами, обеспечивающими безопасность.

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

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

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

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

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

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

- переход от централизованных систем на базе больших компьютеров к распределенным системам на базе местных вычислительных ресурсов;

- все больше данных хранится в информационных системах, и тем ценнее они для пользователей;

- пациенты становятся более мобильными, и их медицинские данные требуются в разных местах пребывания.

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

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

Соглашение о политике должно также содержать описание выявленных различий в системах обеспечения информационной безопасности и согласованных мер по их преодолению. Например, в сервисе аутентификации права и обязанности одной стороны, запрашивающей доступ к информации другой стороны, должны обеспечиваться в соответствии с согласованной политикой, записанной в соглашении между сторонами. Для решения этой задачи необходимо обеспечить соответствующую группировку и классификацию как пользователей и поставщиков информации и информационных услуг, так и самой информации и предоставляемых услуг. Такая классификация может служить основой для реализации механизмов обработки требований доступа, категорирования информации и информационных услуг, а также механизмов описания политик контроля доступа и управления ими. Если все взаимодействующие стороны не видят каких-либо рисков, взаимодействие существующих систем и обмен информацией можно начинать сразу же после подписания соглашения о политике контроля доступа. Если риски настолько существенны, что их надо исключить до начала обмена информацией, то надо описать эти риски в соглашении о политике контроля доступа и добавить к нему перечень мероприятий по устранению рисков. Соглашение должно содержать график выполнения этих мероприятий и определять способ их финансирования.

Процесс документирования очень важен и служит основой для выработки соглашения о политике контроля доступа.

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

В стандарте ИСО/ТС 22600, состоящем из двух частей, содержатся ссылки на уже принятые стандарты информационной безопасности и архитектуры ее реализации, а также на спецификации, предложенные для здравоохранения такими организациями, как ИСО, CEN, ASTM, OMG, W3C и другими. В нем поддерживается применение подходящих стандартов либо предлагается их улучшение или модификация, либо обосновывается необходимость разработки новых стандартов.

В настоящем стандарте (ИСО/ТС 22600, часть 1 "Общие сведения и управление общей политикой") содержится описание сценариев и критичных характеристик трансграничного обмена информацией. В нем также приводятся примеры методов необходимого документирования, которые должны послужить основой соглашения о политике контроля доступа.

В ИСО/ТС 22600 часть 2 "Формальные модели" содержатся более детальные описания архитектуры и моделей полномочий и управления полномочиями, реализуемых для обеспечения защиты совместного доступа к информации, дополненные примерами шаблонов соглашений о политике контроля доступа.

Настоящий стандарт тесно связан с другими международными стандартами в этой предметной области, например ИСО/ТС 17090 и ИСО/ТС 21091. Он также связан с ведущейся разработкой проекта ИСО/ТС 21298.

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

Стандарт ИСО/ТС 22600 определяет сервисы управления полномочиями и контроля доступа, необходимые для распределенного доступа и обмена медицинской информацией между всеми заинтересованными пользователями, удаленными друг от друга и использующими разные средства защиты информации. В настоящем стандарте установлены принципы и определены сервисы, необходимые для управления полномочиями и контроля доступа. В нем определены необходимые понятия, базирующиеся на компонентах, и он предназначен для поддержки их технической реализации. Настоящий стандарт не определяет применение этих понятий в конкретных процессах оказания медицинской помощи.

1 Область применения

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

В настоящем стандарте определены методы управления авторизацией и контроля доступа к данным и/или функциям. Он обеспечивает согласование политик контроля доступа и основан на концептуальной модели, по которой для управления доступом к информации, осуществляемым различными прикладными программами (программными компонентами), могут использоваться локальные серверы авторизации и службы распределенного каталога и репозитория политик контроля доступа. Репозиторий политик предоставляет информацию о правилах доступа к разным прикладным функциям, основанным на использовании ролей и других атрибутов. Служба каталога обеспечивает идентификацию отдельных пользователей. Предоставление доступа должно осуществляться на основе:

- аутентифицированной идентификации пользователя;

- правил доступа, относящихся к конкретному информационному объекту;

- правил относительно атрибутов авторизации, заданных менеджером авторизации для пользователя;

- функций конкретного приложения.

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

Настоящий стандарт поддерживает взаимодействие между несколькими менеджерами авторизации, которые могут действовать независимо от организационных и политических границ.

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

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

Настоящий стандарт не включает в себя детали, связанные с конкретными платформами и реализациями. В нем не определяются сервисы и протоколы защиты технической передачи данных, определенные в других стандартах, например в ENV 13608, а также методы аутентификации.

2 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

2.1 контроль доступа (access control): Средства обеспечения доступа к ресурсам системы обработки данных только авторизованным субъектам авторизованными способами [5].

2.2 отслеживаемость (accountability): Свойство, обеспечивающее однозначную привязку действий субъекта к конкретному субъекту [6].

2.3 сертификат атрибута (attribute certificate): Структура данных, заверенная цифровой подписью уполномоченного лица по сертификации, которая связывает некоторые значения атрибута с идентификацией его владельца.

2.4 аутентификация (authentication): Процесс достоверной идентификации субъектов информационной безопасности посредством надежной связи между идентификатором и его удостоверением.

Примечание - См. также аутентификацию источника данных и аутентификацию равноправного объекта.

2.5 уполномоченное лицо (authority): Субъект, ответственный за выдачу сертификатов.

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

2.6 авторизация (authorization): Процесс предоставления прав, включая предоставление прав на доступ.

2.7 доступность (availability): Свойство быть доступным и годным к использованию по запросу авторизованного субъекта [6].

2.8 уполномоченное лицо по сертификации; УС (certification authority; CA): Уполномоченное лицо, которому одна или несколько участвующих сторон доверили выпуск и присвоение сертификатов [7].

Примечания

1 Уполномоченное лицо по сертификации может факультативно создавать ключи для участвующих сторон.

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

2.9 конфиденциальность (confidentiality): Свойство, заключающееся в том, что информация не может быть доступной или раскрытой для неавторизованных лиц, объектов или процессов [6].

2.10 делегирование (delegation): Передача полномочия от его обладателя другому объекту.

2.11 идентификация (identification): Выполнение проверок, позволяющих системе обработки данных распознавать объекты.

2.12 ключ (key): Последовательность символов, управляющая операциями шифрования и дешифровки [6].

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

2.14 соглашение о политике (policy agreement): Письменное соглашение, в котором все участвующие стороны обязуются придерживаться определенного комплекса политик.

2.15 принципал (principal): Действующее лицо, способное реализовать определенные сценарии (пользователь, организация, система, устройство, прикладная программа, компонент, объект).

2.16 секретный ключ (private key): Ключ, используемый в асимметричном криптографическом алгоритме, обладание которым ограничено (обычно только одним субъектом) [9].

2.17 полномочие (privilege): Возможность, предоставленная объекту уполномоченным лицом в соответствии с атрибутом этого объекта.

2.18 открытый ключ (public key): Ключ, используемый в асимметричном криптографическом алгоритме, который может быть сделан общедоступным [9].

2.19 роль (role): Комплекс способностей и/или действий, связанный с задачей.

2.20 безопасность (security): Сочетание доступности, конфиденциальности, целостности и отслеживаемости [12].

2.21 политика безопасности (security policy): Утвержденный план или способ действий по обеспечению информационной безопасности,

2.22 сервис безопасности (security service): Сервис, предоставляемый уровнем взаимодействия открытых систем, обеспечивающий надлежащую степень безопасности систем или передачи данных [6].

2.23 надежная аутентификация (strong authentication): Аутентификация, осуществляемая посредством свидетельств, полученных с использованием криптографических средств.

2.24 цель (target): Ресурс, к которому субъект запрашивает доступ.

3 Цели и структура управления полномочиями и контроля доступа

3.1 Цели управления полномочиями и контроля доступа

Целями управления полномочиями и контроля доступа являются:

a) создание инструкций по совместному использованию информации, включая шаблон соглашения о политике, который задает и определяет структуру и содержание этого документа;

b) создание стандарта управления полномочиями и контроля доступа, который обусловливает безопасный обмен информацией между зонами безопасности. Для этого определен базовый процесс обмена информацией. Стандарт по управлению полномочиями и контролю доступа также определяет метод организации защищенного трансграничного процесса обмена информацией;

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

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

3.2 Структура управления полномочиями и контроля доступа

3.2.1 Элементы структуры

Структура модели процесса обмена данными между зонами безопасности состоит из элементов, перечисленных ниже. В настоящем стандарте понятие структуры раскрывается в широком смысле.

Структура состоит из следующих элементов:

- зона;

- политика;

- роли;

- каталог;

- аутентификация;

- процесс.

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

3.2.2 Зона

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

Зона может состоять из субзон (которые будут наследовать и могут специализировать политики родительской зоны). Наименьшей зоной может быть отдельное рабочее место или конкретный компонент информационной системы. Зоны могут объединяться в суперзоны связыванием отдельных зон и формированием общей зоны большего масштаба для обмена информацией и взаимодействия.

3.2.3 Политика

3.2.3.1 Политика контроля доступа

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

Для описания политик могут использоваться такие средства, как шаблоны или формальные модели политик. Модель политики описана в подразделе 4.4 ИСО/ТС 22600-2. Что касается требований по безопасности, то особый интерес представляет политика информационной безопасности. Политика информационной безопасности рассматривается в подразделе 4.1 ИСО/ТС 22600-2.

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

При межзональном взаимодействии необходимо определить общий набор политик, применяемых ко всем взаимодействующим зонам. Данный набор должен быть определен на основе анализа релевантных политик, специфичных для каждой из взаимодействующих зон. Такие общие политики вырабатываются (согласуются) в процессе, называемом "наведением мостов". Уже согласованные политики должны быть документированы и подписаны всеми уполномоченными лицами, отвечающими за обеспечение безопасности в своих зонах. В идеале весь этот процесс должен проводиться с использованием представлений и согласований в электронной форме, чтобы обеспечить взаимодействие в реальном времени в рамках (заранее согласованной) соответствующей и регламентированной структуры. Согласование и верификация политик в этом случае будут иметь место при каждом взаимодействии служб обеспечения безопасности.

Соглашение о политике представлено в разделе 6 и формально промоделировано с использованием структурных схем и шаблонов в части 2 ИСО/ТС 22600. Процесс выработки соглашения по информационному обмену должен предшествовать процессу реального обмена информацией. Ниже описан сценарий процесса выработки соглашения, которое будет служить основой для процесса реального обмена информацией, описанного в 3.2.7.

3.2.3.2 Процесс выработки соглашения

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

После принятия решения о том, какой информацией можно обмениваться, надо провести анализ уровня защиты в обеих системах и определить уровень, удовлетворяющий обе стороны. Для этого надо составить список всех требований с обеих сторон и для их оценки составить форму, подобную приведенной в приложении А.

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

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

В соглашении должны быть указаны средства обеспечения управления и функционирования общего каталога и сервисы репозитория политик.

3.2.4 Роли

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

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

Обобщенная концепция ролей описана в 4.4 и в приложении А ИСО/ТС 22600-2, а также будет рассмотрена в разрабатываемом стандарте ИСО/ТС 21298.

3.2.5 Репозиторий политик

Репозиторий политик содержит набор правил контроля доступа и набор ролей, к которым они применяются. Для обеспечения межзонального контроля доступа эти правила и механизм отображения ролей следует хранить в общем репозитории политик.

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

3.2.6 Каталог

Служба каталога предоставляет информацию о субъектах. Спецификация каталога должна соответствовать требованиям, изложенным в [14].

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

3.2.7 Аутентификация

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

Основы аутентификации определены в [8] и [9]. Процедура аутентификации основана на использовании инфраструктуры открытых ключей. Основы инфраструктуры открытых ключей определены в [10]. Сертификат аутентификации соответствует спецификации X.509V3.

3.2.8 Процесс

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

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

Сценарием примера является ситуация, когда специалисту из зоны безопасности 1 нужна информация о своем пациенте, хранящаяся в зоне 2, где данный пациент проходил лечение ранее.

В определенных обстоятельствах одному приложению необходимо передать информацию другому приложению и/или получить информацию от него. Эта необходимость определяется пользователями данных приложений. Пользовательский доступ контролируется каждой зоной безопасности, но он может быть также предоставлен по запросу пользователя из другой зоны безопасности. Внешний запрос на доступ удовлетворяется после его успешной проверки на соответствие согласованным правилам, хранящимся в репозитории политик. Все такие правила должны быть указаны в соглашении о политике.

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

Модель процесса представлена на рисунке 1.

Процесс осуществляется в следующей последовательности:

1) Новый сотрудник получает свою роль, определенную и назначенную руководителем подразделения, в котором он собирается работать, в соответствии с изложенным в 3.2.4.

2) Новый сотрудник регистрируется в системе авторизации соответствующей зоны безопасности с ограничениями и авторизацией, присущими назначенной ему роли. Это подразумевает, что сотрудник аутентифицируется в соответствии с изложенным в 3.2.7.

3) Пользователи из двух зон безопасности, которые удовлетворяют правилам, определенным в соглашении о политике, могут быть найдены через службу общего каталога. Каталог доступен из любого приложения в зонах безопасности, на которые распространяется соглашение о политике. См. 3.2.6.

4) Когда сотрудник, принадлежащий к зоне безопасности 1, начинает использовать приложение 1 в информационной системе 1 зоны безопасности 1, первым, что должно сделать данное приложение, является проверка его авторизации в службе контроля доступа 1 (см. рисунок 1).

Рисунок 1 - Модель процесса

5) Сотруднику предоставляется доступ к приложению 1 в зоне безопасности 1. Правила внутризонального и межзонального информационного взаимодействия описаны в подразделе 4.1 ИСО/ТС 22600-2.

6) Сотрудник, использующий приложение 1, создает запрос на получение информации от приложения 2 из зоны безопасности 2. Запрос содержит идентификацию и роль запрашивающего, а также ссылку на соответствующее правило в общем репозитории политик.

7) В этой ситуации обе системы обратятся к репозиторию политик, чтобы проверить, выполняются ли требования к обмену информацией. Поэтому необходимо, чтобы для зон 1 и 2 была согласована политика для данного типа обмена информацией, и чтобы в репозитории политик имелись правила для проверки допустимости данного обмена. Если все эти условия выполнены, то процесс продолжается с шага 8. В противном случае приложение 1 должно уведомить пользователя, что его запрос отклонен.

8) Приложение 1 посылает запрос на получение информации приложению 2 из зоны безопасности 2.

9) Результат запроса посылается приложению 1, в котором сотрудник может его прочитать и сохранить вместе с другой информацией о данном пациенте.

10) Все транзакции, имевшие место в приложении 1, приложении 2, службе каталога и репозитории политик, а также все взаимодействия между двумя зонами должны регистрироваться. Стандартные процедуры мониторинга журнала регистрации должны быть определены в соглашении о политике.

4 Соглашение о политике

4.1 Обзор

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

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

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

Функции описаны в 4.2-4.22.

4.2 Идентификация

Соглашение о политике должно определять методы идентификации, используемые в зонах безопасности, включая идентификацию лиц (пациентов, медицинских специалистов, других работников здравоохранения и т.д.), организаций, систем, устройств, приложений, компонентов и т.д. При использовании разных систем идентификации каждая из них должна быть определена. Также должны быть определены механизмы связывания, отображения и преобразования. В данном контексте необходимо рассмотреть и задать использование уникального идентификатора пациента, а также главного регистра пациентов, связанного с пространством имен, и служб идентификации пациентов.

4.3 Информированное согласие пациента

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

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

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

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

4.5 Идентификация информации

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

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

4.6 Локализация информации

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

4.7 Целостность данных

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

4.8 Безопасность

С большой вероятностью каждая зона будет иметь свои собственные правила безопасности. Конечно, было бы идеально, если бы все участвующие зоны могли перейти к единой модели безопасности. Это является основной целью, и стандарты информационной безопасности, принятые Европейским комитетом по стандартизации и ИСО, должны служить главными инструментами ее достижения.

Если такой переход невозможен, то в соглашении должно быть определено, какой уровень защищенности в одной зоне соответствует какому уровню защищенности в другой зоне. Также должны быть разработаны полномочия пользователей для разных уровней защищенности в обеих зонах.

Примечание - Аспекты информационной безопасности рассматриваются в ИСО/ТС 22600-2.

4.9 Авторизация

В соглашении о политике должны быть определены процессы авторизации как внутренний, в пределах зоны безопасности, так и внешний, относящийся к другим зонам безопасности. Более подробно авторизация рассмотрена в разделе 4 ИСО/ТС 22600-2.

4.10 Структура ролей

Роли определяются для каждой зоны. В политиках определяются права и обязанности для одной или нескольких ролей в конкретных контекстах. Назначение ролей является очень важной частью при разработке окончательного стандарта по согласованию политик. Модель ролей представлена в подразделах 4.6-4.9 ИСО/ТС 22600-2.

4.11 Права аттестации

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

4.12 Делегирование прав

В повседневной работе нередко возникает потребность в делегировании прав. Для управления этим процессом делегирование прав должно быть определено в соглашении, так как крайне трудно точно знать, кто наделен какими правами внутри своей зоны безопасности и в других зонах. Делегирование должно быть хорошо структурированным, чтобы его можно было отслеживать. Модель делегирования рассматривается в подразделе 4.8 ИСО/ТС 22600-2.

4.13 Срок действия

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

4.14 Аутентификация пользователей и ролей

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

4.15 Доступ

Обстоятельства, при которых разрешается доступ к информации в другой зоне безопасности, описаны в подразделе 4.7 ИСО/ТС 22600-2.

Правила для прав доступа должны быть согласованы и установлены в соглашении.

4.16 Срок действия соглашения

В соглашении должен быть установлен срок его действия. Соглашение должно также содержать пункт, определяющий процедуру прекращения действия соглашения как по окончании срока его действия, так и досрочно. Должны быть определены законные основания для расторжения соглашения. В соглашении также должны быть определены штрафные санкции в случае его досрочного расторжения.

4.17 Этические принципы

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

4.18 Защищенный регистрационный журнал

Как было указано выше, все транзакции должны регистрироваться в журнале. В соглашении должно быть указано, как это будет делаться и с какой степенью детализации. Регистрация транзакций является ключевым фактором доверия пациентов к системе.

Чтобы гарантировать высокое качество ведения регистрационного журнала, необходимо использовать метки времени. Все информационные транзакции должны иметь метку времени. Это может потребовать существенного перепрограммирования более старых систем и, следовательно, может оказаться невозможным по экономическим причинам. В этом случае стороны, подписывающие соглашение, должны решить, что можно сделать в существующих обстоятельствах и какие меры должны быть приняты для исправления ситуации. План реализации этих мер является частью соглашения.

4.19 Аудиторская проверка

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

4.20 Анализ рисков

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

4.21 Непрерывность и управление чрезвычайными ситуациями

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

4.22 Развитие информационных систем

Для обеспечения не только текущего, но и будущего обмена данными между информационными системами все стороны должны принять на себя в соглашении о политике обязательство развивать свои информационные системы в соответствии с настоящим стандартом и другими принятыми стандартами.

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

В соглашении о политике должны быть определены все функции обмена информацией.

5 Документация

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

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

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

Любое различие в ответах на вопросы "как есть сейчас?" и "как должно быть?" является фактором риска для информационной безопасности. Должен быть проведен анализ того, какие риски могут вытекать из выявленных различий. Необходимо задокументировать эти риски и описать меры по их устранению.

Пример шаблона стандартной документации приведен в приложении А.

Библиография

[1] Blobel, В. and Roger-France, F., A Systematic Approach for Analysis and Design of Secure Health Information Systems, International Journal of Medical Informatics, 62 (3), pp. 51-78,2001

[2] Blobel, В., Analysis, Design and Implementation of Secure and Interoperable Distributed Health Information Systems, Series "Studies in Health Technology and Informatics" 89, IOS Press, Amsterdam, 2002

[3] Damianou, N., Dulay, N., Lupu, E. and Sloman, M., Ponder: A Language for Specifying Security and Management Policies for Distributed Systems, The Language Specification, Version 2.3. Imperial College Research Report DoC 2000/1. 20 October, 2000

[4] Ferraiolo, D.F., Sandhu, R., Gavrila, S., Kuhn, DR. and Chandramouli, R., Proposed NIST Standard for Role-Based Access Control, ACM Transactions on Information and System Security, 4 No. 3, August 2001, pp. 224-274

[5] ISO/IEC 2382-8:1998, Information technology - Vocabulary - Part 8: Security

[6] ГОСТ Р ИСО 7498-2-99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 2. Архитектура защиты информации

[7] ISO/IEC 9594-8:2001, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks - Part 8

[8] ISO/IEC 9798-3:1998, Information technology - Security techniques - Entity authentication - Part 3: Mechanisms using digital signature techniques

[9] ISO/IEC 10181-1:1996, Information technology - Open Systems Interconnection - Security frameworks for open systems: Overview

[10] ISO/TS 17090-1:2002, Health informatics - Public key infrastructure - Part 1: Framework and overview

[11] ENV 13729:2000, Health informatics - Secure user identification - Strong authentication using microprocessor cards

[12] ENV 13608-1:2000, Health informatics - Security for healthcare communication - Part 1: Concepts and terminology

[13] ENV 13606-3:2000, Health informatics - Electronic healthcare record communication - Part 3: Distribution rules

[14] ISO/TS 21091, Health informatics - Directory services for security, communications and identification of professionals and patient

[15] ISO/TS 21298, Health informatics - Functional and structural roles