ГОСТ Р ИСО/ТС 22600-1—2009
Общий репозиторий политик является формальным представлением соглашения о политике. Он
используетсяслужбойконтролядоступа вместес информациейо роляхотдельногосубъектадля приня
тия решения о предоставлении или отказе в доступе. Если все требования выполнены, пользователь
приложения из одной зоны безопасности получит полномочие на доступ и получение надлежащей
информации издругой зоны безопасности.
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).
5