5.4.4 Данные отслеживания защиты

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

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

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

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

5.4.5 Процедура восстановления защиты

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

а) немедленные;

b) временные;

с) долгосрочные.

Например

Немедленные действия могут привести к немедленному прерыванию операций, подобному разъединению соединения.

Временные действия могут привести к временной неработоспособности какого-либо логического объекта.

Долгосрочные действия могут привести к занесению логического объекта в "черный список" или к изменению ключа.

5.4.5.2 Объектами стандартизации являются протоколы действий процедуры восстановления и административного управления восстановлением защиты (см. 8.3.3).

5.5 Иллюстрация взаимоотношений услуг и механизмов защиты

В таблице 1 перечислены механизмы, которые по отдельности или в сочетании с другими механизмами рассматриваются в качестве возможных в некоторых случаях для обеспечения каждой услуги. Эта таблица представляет собой обзор таких взаимоотношений и не является исчерпывающей. Услуги и механизмы, приведенные в этой таблице, описаны в 5.2 и 5.3. Более подробное описание взаимоотношений приведено в разделе 6.

Таблица 1 - Механизмы обеспечения услуг

МеханизмыУслуги	Шифрование	Цифровая подпись	Управление доступом	Целостность данных	Обмен аутентификацией	Заполнение трафика	Управление маршрутизацией	Нотаризация
Аутентификация равноправного логического объекта	Да	Да	*	*	Да	*	*	*
Аутентификация отправителя данных	Да	Да	*	*	*	*	*	*
Услуга управления доступом	*	*	Да	*	*	*	*	*
Конфиденциальность в режиме с установлением соединения	Да	*	*	*	*	*	Да	*
Конфиденциальность в режиме без установления соединения	Да	*	*	*	*	*	Да	*
Конфиденциальность выбранного поля	Да	*	*	*	*	*	*	*
Конфиденциальность потока трафика	Да	*	*	*	*	Да	Да	*
Целостность в режиме с установлением соединения с восстановлением	Да	*	*	Да	*	*	*	*
Целостность в режиме с установлением соединения без восстановления	Да	*	*	Да	*	*	*	*
Целостность выборочного поля в режиме с установлением соединения	Да	*	*	Да	*	*	*	*
Целостность в режиме без установления соединения	Да	Да	*	Да	*	*	Да	*
Целостность выборочного поля в режиме без установления соединения	Да	Да	*	Да	*	*	*	*
Безотказность отправителя	*	Да	*	Да	*	*	*	Да
Безотказность получателя	*	Да	*	Да	*	*	*	Да
ОбозначенияДа - механизм считается возможным для использования как в отдельности, так и в сочетании с другими механизмами;* - механизм считается невозможным для использования.

6 Взаимодействие услуг, механизмов и уровней

6.1 Принципы уровневой структуры защиты

6.1.1 Для определения распределения услуг защиты по уровням и последующего размещения по уровням механизмов защиты используются следующие принципы:

a) количество альтернативных способов предоставления услуги должно быть минимальным;

b) допускается построение систем защиты путем обеспечения услуг защиты на нескольких уровнях;

c) дополнительные функциональные возможности, необходимые для защиты, не обязательно должны дублировать существующие функции ВОС;

d) должно быть исключено нарушение независимости уровня;

e) объем доверительной функциональности должен быть минимальным;

f) в тех случаях, когда логический объект зависит от механизма защиты, обеспечиваемого каким-либо логическим объектом нижерасположенного уровня, любые промежуточные уровни должны быть построены таким образом, чтобы нарушение защиты было практически невозможным;

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

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

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

6.2 Модель привлечения, административного управления и использования защищенных (N)-услуг

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

6.2.1 Определение средств защиты для сеанса связи

6.2.1.1 Общие положения

В данном подразделе приведено описание привлечения средств защиты для сеансов обмена данными в режимах с установлением и без установления соединения. В случае сеансов обмена данными в режиме с установлением соединения, услуги защиты обычно запрашиваются/подтверждаются во время установления соединения. В случае привлечения услуги защиты в режиме без установления соединения защита запрашивается/подтверждается для каждого примитива БЛОК-ДАННЫХ запрос.

Для упрощения последующего описания термин "запрос услуги" будет в дальнейшем означать либо установления соединения, либо передачу примитива БЛОК-ДАННЫХ запрос. Привлечение защиты для выбранных данных может осуществляться путем запроса защиты выбранных полей. Например, эта процедура может быть выполнена путем установления нескольких соединений, каждому из которых может быть присвоен различный тип или уровень защиты.

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

6.2.1.2 Запросы услуги

При каждом запросе (N)-услуги (N+1)-логический объект может запросить необходимый тип желаемой защиты. Запрос (N)-услуги должен определить услугу защиты вместе с параметрами и любой дополнительной информацией, относящейся к защите (например, информацией о чувствительности и/или о метках защиты), для обеспечения заданного тина желаемой защиты.

Перед каждым сеансом обмена данными (N+1)-уровень должен обратиться к информационной базе административного управления защитой (ИБАУЗ) (см. 8.1). ИБАУЗ должна содержать информацию о требованиях, предъявляемых к защите административным управлением, относительно (N+1)-логического объекта. Доверительная функциональность необходима для усиления этих требований, предъявляемых к защите со стороны административного управления.

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

Если согласование выполняется в виде отдельной процедуры, результаты согласования (т.е. согласованный тип механизма защиты и параметры защиты, необходимые для обеспечения соответствующих услуг защиты) вводятся в ИБАУЗ (см. 8.1).

Если согласование выполняется как неотъемлемая часть обычной процедуры установления соединения, результаты согласования между (n)-логическими объектами будут временно сохранены в ИБАУЗ. Перед согласованием каждый (n)-логический объект должен иметь доступ к ИБАУЗ для получения информации, необходимой для согласования.

(N)-уровень должен отклонить запрос услуги, если он не подчиняется требованиям административного управления, которые записываются в ИБАУЗ для (N+1)-логического объекта.

(N)-уровень должен также дополнительно к запрашиваемым услугам защитьг привлекать любые услуги защиты, которые определены в ИБАУЗ как обязательные для достижения заданного тина желаемой защиты.

Если (N+1)-логический объект не определяет заданного типа желаемой защиты, (N)-уровень будет подчиняться стратегии защиты в соответствии с информацией, записанной в ИБАУЗ. Это может привести к обмену данными с использованием средств защиты по умолчанию, предусмотренных в рамках, определенных для (N+1)-логического объекта в ИБАУЗ.

6.2.2 Предоставление услуг защиты

После определения комбинации требований к защите со стороны административного управления и динамически выбранных требований, как описано в 6.2.1, (N+1)-yуровень будет пытаться обеспечить, как минимум, заданный тип желаемой защиты. Это может быть достигнуто одним или двумя следующими методами:

a) привлечение механизмов защиты непосредственно внутри (N)-уровня;