Товары в корзине: 0 шт Оформить заказ
Стр. 1
 

45 страниц

517.00 ₽

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

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

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

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

Стандарты серии ГОСТ Р ИСО/МЭК 10031 предоставляют каркас для разработки стандартов протоколов распределенных учрежденческих приложений (РУП, distributed-office-application - DOA). Они применены для приложений, распределенных на значительных физических расстояниях, а также для “тесно связанных“учрежденческих систем

Показать даты введения Admin

Страница 1

ГОСТ Р ИСО/МЭК 10031-1-2000 ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

ТЕКСТОВЫЕ И УЧРЕЖДЕНЧЕСКИЕ СИСТЕМЫ.

МОДЕЛЬ ПРИЛОЖЕНИЙ РАСПРЕДЕЛЕННОГО УЧРЕЖДЕНИЯ

Часть 1 Общая модель

Издание официальное

БЗ 8-2000/259


ГОССТАНДАРТ РОССИИ Москва

Страница 2

ГОСТ Р ИСО/МЭК 10031-1-2000

Предисловие

1    РАЗРАБОТАН Государственным научно-исследовательским и конструкторско-технологическим институтом «ТЕСТ» Государственного комитета Российской Федерации по телекоммуникациям

ВНЕСЕН Государственным комитетом Российской Федерации по телекоммуникациям

2    ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 28 ноября 2000 г. № 317-ст

Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 10031-1—91 «Информационная технология. Текстовые и учрежденческие системы. Модель приложений распределенного учреждения. Часть I. Обшая модель*

3    ВВЕДЕН ВПЕРВЫЕ

<£) И ПК Издательство стандартов. 2001

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

Страница 3

ГОСТ Р ИСО/МЭК 10031-1-2000

Содержание

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

2    Нормативные ссылки............................................................................................................1

3    Определения............................................................. 2

4    Сокращения............................................................. 5

5    Модель................................................................. 5

6    Руководство по проектированию протоколов.................................... 9

Приложение А Ссылки, определения и сокращения для последующих справочных

приложений..................................................13

Приложение В Взаимосвязь с другими стандартами.................................14

Приложение С Требования...................................................15

Приложение D Основные понятия.............................................16

Приложение Е Рассмотрение идентификации.....................................26

Приложение F Концепции безопасности.........................................27

Приложение G Управление...................................................32

Приложение Н Категории и взаимосвязь приложений...............................32

Приложение J Модель объекта................................................37

Приложение К Стандартный набор операций.....................................39

Приложение L Библиография.................................................41

111

Страница 4

ГОСТ Р ИСО/МЭК 10031-1-2000 ГОСУДАРСТВЕННЫ Й СТАНДАРТ Р ОС С И Й С К О Й ФЕДЕ Р А Ц И И

Информационная технология

ТЕКСТОВЫЕ И УЧРЕЖДЕНЧЕСКИЕ СИСТЕМЫ.

МОДЕЛЬ ПРИЛОЖЕНИЙ РАСПРЕДЕЛЕННОГО УЧРЕЖДЕНИЯ

Часть 1

Общая модель

Information technology. Text and office systems. Distributed-officc-applications model.

Fart I. General model

Дата введения 2002—01—01

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

Стандарты серии ГОСТ Р ИСО/МЭК 10031 предоставляют каркас для разработки стандартов протоколов распределенных учрежденческих приложений (РУП. distributed-oflke-application -DOA). Они применимы для приложений, распределенных на значительных физических расстояниях. а также для «тесно связанных» учрежденческих систем.

Стандарты серии ГОСТ Р ИСО/МЭК 10031 описывают модель. Для того чтобы распределенные учрежденческие приложения были стандартизованы, они должны использовать принципы, установленные в этих стандартах.

Стандарты серии ГОСТ I’ ИСО/МЭК 10031 предоставляют руководства по проектированию протоколов, которые открывают доступ к различным приложениям и взаимодействию между приложениями. Протоколы для распределенных приложений находятся в пределах прикладного уровня ВОС и соответствуют прикладным операциям, определенным в стандартах серии ГОСТ Р ИСО/МЭК 9072.

В стандартах серии ГОСТ Р ИСО/МЭК 10031 подразумевается, что элементы системы, соответствующей какому-либо из них, могут быть реализованы на устройствах, постаачяемых разными продавцами и разными поставщиками услуг.

В стандартах серии ГОСТ Р ИСО/МЭК 10031 не определяется какой-либо интерфейс человек—машина, используемый с распределенными приложениями. Также в них не определяется интерфейс между программным обеспечением, непосредственно взаимодействующим с пользователем, и программным обеспечением конкретных приложений.

Содержание стандартов серии ГОСТ Р ИСО/МЭК 10031 разбито на две части.

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

а)    модель;

б)    руководства по проектированию протоколов.

В ИСО/МЭК 10031-2 |1| описана отличающая объект ссылка и соответствующие процедуры, которые могут быть использованы всеми РУП.

Требования соответствия настоящему стандарту не устанавливаются. В других стандартах серии ГОСТ I* ИСО/МЭК 1 (ЮЗI могут быть установлены требования соответствия для систем, реализующих процедуры этих стандартов.

2    Нормативные ссылки

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

ГОСТ 6.20.1-90 Электронный обмен данными в управлении, торговле и на транспорте (ЭДИФЛКГ). Синтаксические правила

ГОСТ 34.971-91 (ИСО 8822—88) Информационная технология. Взаимосвязь открытых систем. Определение услуг уровня представления с установлением соединения

Издание официальное

Страница 5

ГОСТ Р ИСО/МЭК 10031-1-2000

ГОСТ 34.981-91 (ИСО 8649—88) Информационная технология. Взаимосвязь открытых систем. Определение услуг сервисного элемента управления ассоциацией

ГОСТ 28906-91 (ИСО 7498-84, ИСО 7498-84, Доп. 1-84) Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель

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

ГОСТ Р ИСО/МЭК 7498-3—97 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 3. Присвоение имен и адресация

ГОСТ Р ИСО/МЭК 8824—93 Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии один (АСН.1)

ГОСТ Р ИСО/МЭК 9066-1—93 Системы обработки информации. Передача текста. Надежная передача. Часть I. Модель и определение услуг

ГОСТ Р ИСО/МЭК 9072-1—93 Системы обработки информации. Передача текста. Удаленные операции. Часть 1. Модель, нотация и определение услуг

ГОСТ Р ИСО/МЭК 9072-2—93 Системы обработки информации. Передача текста. Удаленные операции. Часть 2. Спецификация протокола

ГОСТ Р ИСО/МЭК 9594-1—98 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 1. Общее описание принципов, моделей и услуг

ГОСТ Р ИСО/МЭК 9594-3—98 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 3. Определение абстрактных услуг

ГОСТ Р ИСО/МЭК 10021-2—98 Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOT1S). Часть 2. Общая архитектура

ГОСТ Р ИСО/МЭК 10021-3—98 Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOTIS). Часть 3. Соглашения по определению абстрактных услуг

ГОСТ Р ИСО/МЭК 10021-5—96 Информационная технология. Передача текста. Системы обмена текстами, ориентированные на сообщения (MOT1S). Часть 5. Хранилище сообщений: определение абстрактных услуг

3 Определения

3.1    Определения базовой эталонной модели ВОС

В настоящем стандарте используют следующие термины, определенные в ГОСТ 28906:

а)    прикладной уровень;

б)    прикладная категория;

в)    элемент услуга прикладною уровня;

г)    уровень представления;

д)    соединение уровня представления;

е)    протокол;

ж)    определение услуга.

3.2    Определения безопасности базовой эталонной модели ВОС

В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 7498-2:

а)    аутентификация:

б)    авторизация;

г)    полномочия:

д)    политика безопасности.

3.3    Определения сервисного элемента управления ассоциацией (СЭУА, ACSE)

В настоящем стандарте используют следующие термины, определенные в ГОСТ 34.981:

а)    прикладной котгтекст:

б)    сервисный элемент управления ассоциацией (СЭУА).

3.4    Определение услуг уровня представления

В настоящем стандарте используют следующий термин, определенный в ГОСТ 34.971: абстрактный синтаксис.

3.5    Определения абстрактной синтаксической иотапии

В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК

8824:

a) ACH.I

Страница 6

ГОСТ Р ИСО/МЭК 10031-1-2000

б)    внешний тип;

в)    обобщенное время;

г)    макро;

д)    идентификатор объекта;

е)    время UTC.

3.6    Определение сервисного элемента надежной передачи (СЭНП. RTSE)

В настоящем стандарте используют следующий термин, определенный в ГОСТ Р ИСО/МЭК 9066-1:

сервисный элемент надежной передачи (СЭНП).

3.7    Определения сервисного элемента удаленных операций (СЭУО, ROSE)

В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 9072-1:

а)    аргумент;

б)    операция свяшвания;

в)    вызов;

г)    операция:

д)    выполнение:

е)    удаленные операции;

ж)    сервисный элемент удаленных операций (СЭУО);

з)    результат;

и)    операция развязывания.

3.8    Определения справочника

В настоящем стандарте используют следующие термины, определенные в стандартах серии ГОСТ Р ИСО/МЭК 9594:

а)    атрибут;

б)    макроатрибут;

в)    тин атрибута;

г)    значение атрибута:

д)    фильтр.

3.9    Определение EDI FACT

В настоящем стандарте используют следующий термин, определенный в ГОСТ 6.20.1:

EDI КАСТ.

3.10    Определения систем передачи текста, ориентированных на сообщения (MOTIS)

В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 10021-2:

а)    часть тела (сообщения);

б)    1Р-сообщение;

в)    сообщение.

3.11    Определения соглашения по определению абстрактных услуг

В настоящем стандарте используют следующие термины, определенные в ГОСТ I’ ИСО/МЭК 10021-3:

а)    абстрактная модель;

б)    абстрактные операции;

в)    абстрактные услуги;

г)    макро абстрактных услуг;

д)    асимметричный;

е)    порт:

ж)    очистка;

з)    симметричный.

3.12    Определения модели распределенных учрежденческих приложений (МРУИ)

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

3.12.1    исполнитель: л-сервер. который может присваивать отличающие объекты ссылки (ООС) объектам (которыми управляют по запросам от .v-клиентов) и осуществлять операции, обращающиеся к объектам по присвоенным им ООС.

3.12.2    соучастник: jr-сервер, который может осуществлять операции, объекты которых указываются ООС. обращаясь к исполнителю с этими ООС.

3.12.3    атрибуты управления: Атрибуты, связанные с объектом защиты, которые, при согласо-

3

Страница 7

ГОСТ Р ИСО/МЭК 10031-1-2000

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

3.12.4    пакет атрибутов управления: Совокупность атрибутов управления.

3.12.5    операция потребления: Операция, вызванная х-клиентом у соучастника, объекты которой указаны (ЮС.

3.12.6    объект данных: Объект, который представляет данные.

3.12.7    значение объекта данных: Значение, полученное из объекта данных в соответствии с набором правил или, при отсутствии таких правил, значение всего объекта.

3.12.8    прямой досту п к шачению: Доступ к объекту данных по значению, а не по ссылке.

3.12.9    прямая передача значения: Непосредственная передача значения объекта данных, а не передача ссылки.

3.12.10    отличающая объект ссылка (ООС): Однозначная ссылка на реальный объект в среде

РУП.

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

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

3.12.13    инициатор: х-клиент, который вызывает операции, запрашивающие у исполнителя ООС. а не значение объекта данных, и который вызывает у соучастника операции, объекты которых указываются полученными ООС.

3.12.14    объект учрежденческих данных: Объект, который представляет учрежденческу ю инфор-мацию.

3.12.15    учрежденческая информация: Данные, используемые в учреждении.

3.12.16    атрибуты привилегий: Атрибуты, связанные с субъектом защиты, которые, при согласовании с атрибутами контроля объекта зашиты, используются для предоставления доступа или отказа в доступе к этому объекту зашиты.

3.12.17    сертификат атрибутов привилегий: Сертификат, использующий атрибуты привилегий.

3.12.1К операция создания: Операция, вызванная х-клиентом у исполнителя, в которой запрашивается ООС, а не значение объекта данных.

3.12.19    квалифицированные атрибуты: Атрибуты, которые имеют квалификацию использования.

3.12.20    ссылочный доступ к объекту (СДО): Доступ к объектам с помощью ссылок.

3.12.21    операция СДО: Операция, вызванная соучастником у исполнителя.

3.12.22    атрибуты безопасности: Общий термин, охватывающий как атрибуты привилегий, так и атрибуты контроля. Использование атрибутов безопасности определяется политикой безопасности.

3.12.23    объект безопасности: Играющая пассивную роль категория, доступ к которой предоставляется или в доступе отказывается в соответствии с политикой авторизации.

3.12.24    субъект безопасности: Играющая активную роль категория, которой предоставляет доступ или отказывает в доступе к объекту безопасности в соответствии с политикой авторизации.

3.12.25    прикладной процесс пользователя: Прикладной процесс, который содержит УП-поль-зователя и одного или нескольких клиентов распределенных (учрежденческих) приложений (например, х-клиент, >'-клиент и т. п.).

3.12.26    д>: Родовое представление для конкретных имен приложений.

3.12.27    х-доступ: Определение функциональных возможностей х-приложения так, как они видны между х-клиентом и х-сервером.

3.12.2S абстрактная услуга .r-доступа: Абстрактная услуга между .v-клиентом и х-сервером.

3.12.29    протокол х-достуна: Протокол, используемый между х-клиентом и х-сервером.

3.12.30    х-приложение: Некоторого рода распределенное учрежденческое приложение, например приложение электронной почты или приложение хранения и поиска.

3.12.31    х-приклалная система: Совокупность х-клиентов и системы х-сервера. которые вместе обеспечивают х-пользователю функциональные возможности х-приложення.

3.12.32    х-клиент: Та часть х-приложения, которая является частью прикладного процесса, содержащей х-пользователь.

Страница 8

ГОСТ Р ИСО/МЭК 10031-1-2000

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

3.12.34    система л-серверов: Совокупность одного или нескольких х-серверов.

3.12.35    абстрактные услуги .t-системы: Абстрактные услуги между х-серверами.

3.12.36    протокол .t-системы: Протокол, используемый между л-серверами.

3.12.37    х-пользователь: Часть прикладного процесса, играющая роль, принятую при использовании .t-приложения.

4    Сокращения

13 настоящем стандарте использованы следующие сокращения:

АСН.1 — абстрактная синтаксическая нотация версии 1 ВОС - взаимосвязь открытых систем К У — качество услуги

МРУП — модель распределенного учрежденческого приложения

ООС — отличающая объект ссылка

РУН — распределенное учрежденческое приложение

САП — сертификат атрибутов привилегий

СДО — ссылочный доступ к объекту

СЭНП — сервисный элемент надежной передачи

СЭУА — сервисный элемент управления ассоциацией

СЭУО — сервисный элемент удаленных операций

EDIFACT — электронный обмен данными в управлении, коммерции и на транспорте (Electronic Daia Interchange For Administration, Commerce and Transport)

UTC — всемирное скоординированное время (Coordinated Universal Time)

5    Модель

Примечание — Информацию, служащую обоскованием концепции, использованной в данном разделе, см. в приложении D.

5.1    Абстрактная модель РУН

5.1.1    Абстрактная модель доступа

Распределенные учрежденческие приложения должны развиваться в соответствии с абстрактной моделью клиент—сервер, показанной на рисунке 1, используя соглашения по определению абстрактных услуг, приведенные в ГОСТ Р ИСО/МЭК 10021-3.

На рисунке 1 х-пользователь есть пользователь х-приложения, которое обеспечивается х-прикладной системой, .t-Пользователь взаимодействует с х-клиентом для использования услуг, предоставляемых A-приложением, л-Клиент получает доступ к д-серверу через л-доступ. Система х-серверов может быть разделенной и распределенной по нескольким х-сер-верам. Детали внутренней структуры системы А-сер-веров определены в 5.1.2.

Рисунок 1 — Абстрактная модель доступа распределенного учрежденческого приложения

Между A-клиентом и .t-сервером может быть определен один или несколько портов. Для каждого порта его тип должен быть асимметричным.

Примечание! — Услуга доступа, предоставляемые аетшетричными портами, находятся вне области применения настоящего стандарта.

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

Учрежденческая информация является данными, используемыми в учреждении, например:

а)    документы.

б)    сообщения.

в)    данные EDI FACT,

5

Страница 9

ГОСТ Р ИСО/МЭК 10031-1-2000

г)    атрибуты документов.

д)    время,

е)    информация, относящаяся к сообщениям,

ж)    информация о файлах документов.

з)    информация для печати документов (включая шрифты),

и)    управляющая информация для серверов.

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

Г1 р и м е ч а н и с 2 — Обмен информацией, отличной от учрежденческой, определен или будет определен в других стандартах.

5.1.2 Система л-серверов на рисунке I может быть уточнена для распределенной системы л-серверов путем определения абстрактных услуг между серверами, как предлагается в ГОСТ Р ИСО/МЭК 10021-3. На рисунке 2 показана детализация системы л-серверов.

Рисунок 2 — Детализация системы л-серверов 5.2 Реализация абстрактной модели РУП

На рисунке 2 л-клиент получает доступ к системе .v-серверов через абстрактную услугу х-доступа (а). В системе л-серверов доступу соответствует л-сервер. Для предоставления опрошенных л-клиентом услуг л-сервер может взаимодействовать с другими л-серверами через абстрактные услуги л-системы (s).

Система л-серверов может охватывать различные типы л-серверов.

Между л-серверами может быть определен один или несколько портов. Может использоваться порт любого типа.

5.2.1    Реализация абстрактной модели доступа

Для реализации абстрактной модели доступа должен использоваться СЭУО. определенный в стандартах серии ГОСТ Р ИСО/МЭК 9072. и его отображение в ВОС. Модель уровня приведена на рисунке 3. Дополнительную информацию об идентификации л-клиентов л-серверов см. в 6.4.4.

5.2.2    Реализация абстрактной модели для систем серверов

Нет ограничений на реализацию абстрактной модели для систем серверов. Примеры приведены в приложении D.

5.3 Ссылочный доступ к объекту

5.3.1 Классы доступа к данным

Доступ к значениям объектов данных концептуально вовлекает три стороны:

а)    инициатора, который запрашивает доступ;

б)    исполнителя, который хранит и создает значение объекта данных;

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

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

Когда инициатор размещен вместе с исполнителем или соучастником, доступ к данным осуществляется как часть запроса доступа. Это называется прямым доступом к значению.

В случаях, когда инициатор отделен как от соучастника, так и исполнителя либо физически, либо во времени, использование прямого доступа к значению может потребовать лве передачи данных (операции «чтения* и «записи»). Альтернативно, для более эффективного использования сетевых возможностей, инициатор может запросить accessee вернул, ссылку на объект данных, а не его фактическое значение. Затем эта ссылка может быть передана инициатором соучастнику, который может непосредственно взаимодействовать с исполнителем для доступа к значению объекта данных с единственной его передачей.

Аналогично, в языках программирования высокого уровня аргумент или результат передаются «■по значению», когда используется прямой доступ, и «по имени*, когда используется ссылочный доступ к данным.

6

Страница 10

ГОСТ Р ИСО/МЭК 10031-1-2000

ИЩЯЩ1

г^шщдим

ЗНЛМ1НТ

Приклад**

Зпмашш услуг Mnwn.


амцишущт

х-кпщит*


Прсттшж х-австугя


пртада*

я»*


СЭМ>

С9У0

| сангГ ~|

санГ

I I

СЭУА

Соадмимяхмм

грсууставленм


У1ШИ

(РЩЕШМИ

ишамшци

ии*


Ипитжшмя СЭНП фшртьлггмиа

Примечания

1    Данный рисунок является примером и не ограничивает реализации.

2    дг-клиент и л-сервер мот иметь но несколько прикладных категорий и наоборот.

3    Прикладная категория может предостаанять услуги серверам разных типов.

Рисунок 3 — Модель уровней для реализации доступа в абстрактной модели РУП

5.3.2 Функциональная модель для ссылочного доступа к объекту

5.3.2.1 Функциональная мемкль

Функциональная модель ссылочного доступа к объекту (СДО) применяется, когда инициатор, исполнитель и соучастник разделены либо в пространстве, либо во времени. Эта модель показана на рисунке 4. Например, инициатор, исполнитель и соучастник могут выполняться в трех разных системах, или система инициатора может работать там же, где позже будет работать исполнитель или соучастник.

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

Рисунок 4 — Модель ссылочного досгуиа к объектам

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

7

Страница 11

ГОСТ Р ИСО/МЭК 10031-1-2000

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

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

5.3.2.2    Операции создания

В некоторых операциях данных инициатор использует специфический для приложения протокол для выбора значения объекта данных (полного объекта данных, некоторого его подмножества или производного от объекта данных) у исполнителя. Операции этого класса называются «•операциями создания».

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

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

5.3.2.3    Операции потребления

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

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

5.3.2.4    Операции СДО

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

5.3.2.5    Функции, по<)разумеваемые поддержкой СДО

СДО требует, чтобы в исполнителя и соучастника были встроены дополнительные функциональные возможности:

а)    исполнитель должен быть способен предостаатять а ответ на операцию создания ООС, а не значение объекта данных;

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

в)    соучастник должен быть способен вызвать операцию доступа:

г)    исполнитель должен быть способен осуществить операцию доступа.

В специфических для приложений протоколах стандарты могут:

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

б)    либо налагать дополнительные ограничения на допустимость использования ООС.

в)    либо определять специальные элементы протокола для работы с операциями СДО-создания и СДО-потребления.

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

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

8

Страница 12

ГОСТ Р ИСО/МЭК 10031-1-2000

5.3.2.6    Качество услуги

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

а)    либо указывает на значение объекта данных, которое было в момент создания ООС.

б)    либо указывает па текущее значение объекта данных,

в)    либо становится неопределенным, если объект был обновлен.

Для обеспечения управления ссылками на динамически изменяющиеся объекты ООС может включать в себя индикацию качества услуги (КУ). КУ описывает ожидаемую или требуемую область для допустимости как ООС. так и значения соответствующих данных. Протоколы Jf-доступ а могут нуждаться в поддержке элементов протокола для обновления КУ.

5.3.2.7    Структура ООС

Подробности структуры ООС и связанные с ней процедуры определены в ИСО/МЭК 10031 -2 111.

6 Руководство по проектированию протоколов

6.1    Введение

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

6.2    Учрежденческая информация

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

Для обеспечения многообразия существующих и будущих концепций и типов учрежденческой информации абстрактный синтаксис и сематика объектов учрежденческих данных обычно могут быть прозрачными для протоколов распределенных учрежденческих приложений. В этом случае объект учрежденческих данных должен появляться как внешний тип АСН.1 в варианте «непосредственного указания* (т. е. без согласования правил кодирования уровня представления) в абсгракт-ном синтаксисе протоколов РУП. Значение «непосредственного указания идентификатора объекта» внешнего типа указывает как абстрактный синтаксис, так и кодирование объекта. Это значение должно использоваться в атрибутах, идентифицирующих тип объекта.

6.3    Модель объекта и удаленные операции

6.3.1    Использование удаленных операций

Удаленные операции, определенные в ГОСТ Р ИСО/МЭК 9072-1 и ГОСТ Р ИСО/МЭК 9072-2. обеспечивают нотацию и спецификацию протокола для операций связывания, развязывания и операций, вызванных в модели объекта операциями типа. В последующих подразделах приведено руководство по наименованию и стандартным установкам для операций.

Все протоколы доступа для распределенных учрежденческих приложений должны соответствовать удаленным операциям, установленным в ГОСТ Р ИСО/МЭК 9072-1 и ГОСТ I’ ИСО/МЭК 9072-2. Протоколы доступа должны использовать нотацию и концепции настоящего стандарта и должны допускать любое отображение, определенное в ГОСТ Р ИСО/МЭК 9072-1. раздел П. В приложении J дано краткое введение в эти концепции в контексте протокола доступа с учетом правил 6.4.

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

6.3.2    Использование метода абстрактных услуг для о предел е-н и я х-у слуги

Метод абстрактных услуг основан на ряде макросов АСНЛ, которые используются для описания функций и параметров услуг. Этот метод описания услуг тесно связан со способом формального описания удаленных операций. Метод гарантирует полную согласованность между определениями услуг и спецификациями протоколов. Он позволяет избежать дублирования работы и документации при импорте определений из услуг в формальные протоколы. При этом столь же легко можно импортировать определения из одного РУП в другое без их дублирования. Все последующие РУП должны использовать этот метод для документирования услуг.

Макросы абстрактных услуг определены в ГОСТ Р ИСО/МЭК 10021-3.

6.4    Прикладные правила

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

9

Страница 13

ГОСТ Р ИСО/МЭК 10031-1-2000

6.4.1    Конкуренция и разделение ресурсов

6.4.1.1    Конкуренция

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

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

а)    допускать несогласованные данные;

б)    иметь одну основную копию для каждого элемента данных и один конкретный сервер, ответственный за ее обновление:

в)    иметь одну последовательность распространения изменений на копии этого элемента данных и изменений связанных с ним элементов данных;

г)    минимизировать взаимосвязи между элементами данных на разных серверах:

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

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

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

6.4.1.2    Разделение ресурсов

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

Столкновение протоколов ограничивается тем. что в результате при взаимодействии сервер не будет способен какое-то время отвечать. Это может быть объявлено отказом в принятии взаимодействия, ответом, указывающим задержку, или отсроченным ответом. Категория, действующая как .v-пользователь, может быть обязана использовать перерыв (тайм-аут).

Если потребуется, то л-снстема может использоваться для управления ресурсами, совместно используемыми ее .v-серверами. Это должно быть отражено в протоколе .v-системы, но не должно влиять на протокол .v-доступа.

6.4.2    Прозрачность сети

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

6.4.3    Общее определение времени

Все протоколы в среде распределенных учрежденческих приложений должны выражать время, используя тип данных «GeneralizedTime*. определенный в ГОСТ Р ИСО/МЭК НН24.

Time:: = GeneralizedTime

Примечание — В стандартах серий ГОСТ Р ИСО/МЭК 9594 и ГОСТ Р ИСО/МЭК 10021 в настоящее время используется тип «UTCTime* вместо « GeneralizedTime». В этих стандартах планируется использование типа «GeneralizedTime». сохраняющего обратную совместимость.

6.4.4    Об шее определение идентификаторов

Все объекты, определенные в стандартах РУП. должны иметь по крайней мере одно глобально однозначное имя. Общее понимание имен и общее определение идентификаторов определены в ГОСТ Р ИСО/МЭК 749N-3. ГОСТ Р ИСО/МЭК Ш4 и ГОСТ Р ИСО/МЭК 9594-1. Подробнее см. приложение Е.

Данная модель придерживается кодирования АСН.1 имен, используемого приложениями, определенного в ГОСТ Р ИСО/МЭК 9594-1.

6.4.5    Использование атрибутов и фильтров

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

Понятие атрибута, нотация, обеспечивающая определения атрибутов, и абстрактный синтаксис атрибутов определены в ИСО/МЭК 9594-2 |2|. Подмножество определено в ГОСТ Р ИСО/МЭК

И)

Страница 14

ГОСТ Р ИСО/МЭК 10031-1-2000

10021-5. Стандарты распределенных учрежденческих приложений должны использовать атрибуты, когда это возможно, и должны ссылаться на ИСО/МЭК 9594-2 |2|.

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

Семантика и абстрактный синтаксис фильтров определены в ГОСТ Р ИСО/МЭК 9594-3, а подмножество - в ГОСТ Р ИСО/МЭК 10021-5. Стандарты для распределенных учрежденческих приложений должны использовать фильтры, когда это возможно, и должны ссылаться на ГОСТ Р ИСО/МЭК 9594-3.

Типы атрибутов, определенные для одного приложения, могут использоваться другим приложением. если определения и семантика одинаковы. В качестве инструмента для достижения этого используется идентификатор объекта, определенный в ГОСТ Р ИСО/МЭК 8X24.

Макрос для атрибутов определен в ИСО/МЭК 9594-2 |2|.

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

6.4.6    Ссылочный доступ к объекту

Значения объектов данных и ООС в протоколах доступа обычно могут появляться как внешние типы ЛСН.1.

6.4.7    Элементы прикладных услуг и прикладной контекст

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

6.5 Правила безопасности

6.5.1    Введение

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

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

Примечание— Подробнее о понятии безопасности см. приложение F.

6.5.2    Субъект безопасности

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

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

САП должен передаваться в примитиве BIND и применяться ко всем последующим операциям в ассоциации до тех пор. пока примитив UNBIND или ABORT ее не завершат. Каждая отдельная операция должна позволять клиенту передать другой САП; он будет дополнением для данной операции к САП из примитива BIND.

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

6.5.3    Объекты безопасности

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

11

Страница 15

ГОСТ Р ИСО/МЭК 10031-1-2000

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

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

6.5.4    Управление доступом

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

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

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

6.5.5    Ошибки безопасности

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

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

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

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

6.6 Стандартный набор операций

В данном подразделе приведен стандартный набор абстрактных операций.

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

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

Стандартный набор абстрактных операций РУП включает в себя следующие операции:

а)    перечислить (List):

б)    читать (Read);

в)    изменить (Modify);

г)    копировать (Сору);

д)    переместить (Move);

е)    искать (Search);

ж)    создать (Create);

и) удалить (Delete);

к) зарезервировать (Reserve);

л) отметить (Notify);

м) отказать (Abandon).

Пример этих операций приведен в приложении К.

12

Страница 16

ГОСТ Р ИСО/МЭК 10031-1-2000

ПРИЛОЖЕНИЕ А (справочное)

С сылки, определения и сокращения для последующих справочных приложений АЛ Введение

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

А.2 Нормативные ссылки

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

ГОСТ Р 34.980.1-92 (ИСО 8571-1—88) Информационная технология. Взаимосвязь открытых систем. Передача, доступ и управление файлом. Часть I. Общее описание

ГОСГ Р ИСО/МЭК 7498-4—99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 4. Основы административного управления

ГОСТ Р ИСО 8613-1-99 Информационная технология. Текстовые и учрежденческие системы. Архитектур;! учрежденческих документов (ODA) и формат обмена. Часть 1. Введение и общие принципы

ГОСТ Р ИСО/МЭК 8879—99 Обработка информации. Текстовые и учрежденческие системы. Стандартный обобщенный язык разметки (SGML)

ГОСГ Р ИСО/МЭК 9545—98 Информационная технология. Взаимосвязь открытых систем. Структура прикладного уровня А.З Определения

А.3.1 Определения базовой эталонной модели ВОС

В последующих приложениях к настоящему стандарту используют следующий термин, определенный в ГОСТ 28906: прикладной процесс.

А.3.2 Определения безопасности базовой эталонной модели ВОС В последующих приложениях к настоящему стандарту используют Следующие термины, определенные в ГОСТ Р ИСО/МЭК 7498-2:

а)    управление доступом;

б)    список 'правления доступом:

в)    проверка;

г)    прослеживание проверки;

д)    информация аутентификации; с) средство:

ж) конфиденциальность; и) целостность данных; к) аутентнфнкания источника данных; л) цифровая подпись; м) шифрование: н) ключ;

о) управление ключами; п) отвержение.

А.3.3 Определения систем передачи текста, ориентированных на сообщения (MOTIS)

В последующих приложениях к настоящему стандарту используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 10021-2:

а)    передача сообщений;

б)    система передачи сообщений;

в)    хранилище сообщений;

г)    Р2;

д)    агент пользователя.

А.3.4 О п ре дел с н и я модели распределенных учрежденческих приложений

(МРУП)

В последующих приложениях к настоящему стандарту используют следующие определения:

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

А.3.4.2 контекст доступа: Контекст в терминах таких переменных, как положение, время дня. уровень безопасности установленных ассоциаций и т. п.. в котором осуществляется доступ к объектам безопасности.

А.3.4.3 криптографический ключ: См. ключ.

А.3.4.4 спецификация формата объекта данных: Тип данных в смысле АСН.1. который определен независимо от протоколов .г-доступа.

13

Страница 17

ГОСТ Р ИСО/МЭК 10031-1-2000

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

А.3.4.6 пользователь УП: Часть прикладного процесса, которая непосредственно взаимодействует с пользовагслем-человском и использует одно или несколько учрежденческих приложений в интересах лого пользовагсля-челонека.

А.3.4.7 администратор безопасности: Уполномоченный (лицо или группа лиц), ответственный за реализацию политики безопасности для области безопасности.

A.3.4.S область безопасности: Ограниченная группа объектов и субъектов безопасности, к которым применяется единая политика безопасности, осуществляемая единственным администратором безопасности.

А.3.4.1) средства безопасности: Процедуры, процессы, методы или их наборы, которые моделируют функции, относящиеся к безопасности.

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

А.3.4.11 пол, шва гель: Пользователь-человек или х-пользователь.

А.3.4.12 прикладной процесс пользователя: Прикладной процесс, который содержит пользователя УП и одного или нескольких клиентов распределенного (учрежденческого) приложения (например, х-клиент, >-клиент и т. п.).

А.3.4.13 х-, y-f z-, • .. : Родовые представления для конкрегных имен приложений.

А.3.4.14 интерфейс х-при.южеиия: Интерфейс к .v-приложению так. как он виден между х-иользовагслсм и х-клиентом.

А.3.4.15 определение х-услуги: Определение функциональных возможностей х-приложения так. как они видны между х-клиентахш и х-системой.

А.4 Сокращения

В последующих приложениях к настоящему стандарту использовано следующее сокращение:

СЭП — сервисный элемент приложения.

ПРИЛОЖЕНИЕ В (справочное)

Взаимосвязь с другими стандартами

В.1 Содержание

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

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

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

В.2 Использование друтих стандартов

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

В.З Согласованность с другими стандартами

Система обмена текстами, ориентированными на сообщения (MOTIS), и справочник ранее определили ряд вопросов, общих для распределенных учрежденческих приложений. По историческим причинах! в MOTIS имеются вопросы, не полностью встраивающиеся в настоящий стандарт.

Документы как обрабатываемая, печатаемая и пересылаемая информация являются основным видом учрежденческой информации. Хотя протоколы, которые будут разработаны по настоящей модели, не зависят от не пользовании конкретного кодирования документов, они должны быгь согласованы со стандартами по архитектуре учрежденческих (огкрытых) документов (ODA), стандартному обобщенному языку разметки (SGML), стандартному языку описания страниц (SPDL). языку семантики и спецификации стиля документа (DSSSL).

Удаленный доступ к базе данных (RDA) может использоваться как учрежденческая функция, и может быгь полезной какая-либо гармонизация с МРУП.

14

Страница 18

ГОСТ Р ИСО/МЭК 10031-1-2000

В.4 Сосуществование с другими стандартами

B.4.I Протокол виртуального терминала (VTP)

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

В.4.2 Протоколы передачи файлов

Передача, доступ и управление файлами (FTAM) непосредственно не касаются большинспза пользователей учрежденческих систем, которые работают в терминах документов и реляционно-подобною доступа к базе данных. Настоящий стандарт устанавливает руководство, которое не выполняется в рамках FTAM. Тем не менее приложения пользователей, в которых желательно использовать FTAM-подобные модели файлохра-нилнша и соответствующие функциональные возможности, должны быть способны использовать FTA.V1 наряду с учрежденческими приложениями.

ВАЗ Обработка транзакций (ГР), завершение, конкуренция и откатка (CCR)

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

В.4.4 Открытая распределенная обработка (ODP)

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

ПРИЛОЖЕНИЕ С (справочное)

Требования

С.1 Введение

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

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

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

С.1 Функциональные требования

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

а)    мсжперсональиые сообщения — для взаимодействия с лругими пользователями;

б)    групповое взаимодействие — для групп пользователей:

в)    преобразование — для обмена документами с разными синтаксисами или кодированиями;

г)    .запись и поиск документов — для упорядоченной записи и многоключевого поиска документов;

д)    ввод и вы вод документов — для распределенных учрежденческих систем с различными физическими устройствами, такими как сканеры, принтеры и пр.;

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

ж) аутентификация — для предотвращения несанкционированного доступа к различным приложениям;

и) локально доступное базовое время — для таких целей, как отметка времени файлов и сообщений в

сети;

к) прямой доступ — для удаленных серверов (например, видеотексту) и пользователей (например, через видеотекст):

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

м) передача данных между различными приложениями — для удаленных серверов.

15

Страница 19

ГОСТ Р ИСО/МЭК 10031-1-2000

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

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

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

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

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

С.З Требования проектирования

Проектирование протоколов должно обеспечивать:

а)    устойчивость —

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

б)    модульное проектирование:

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

2)    допускающее зребование высокой степени интеграции;

в)    общий стиль проекта протокола, включающий единообразное использование:

1)    поддерживающих приложений и возможностей.

2)    элементов услуг удаленных операций;

г)    безопасность — различные уровни, задаваемые пользователем;

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

В настоящем стандарте установлены принципы взаимодействия между различными приложениями.

ПРИЛОЖЕНИЕD (справочное)

Основные понятия

D.1 Введение

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

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

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

Узел сервера является устройством, которое управляет ресурсами, совместно используемыми несколькими пользователями.

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

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

16

Страница 20

ГОСТ Р ИСО/МЭК 10031-1-2000

D.2 Молсль клиснт-сервср

В данном подразделе описывается подход к объяснению распределения единственного х-приложения, приложения определенного вида.

D.2.1 Единственное нераспределенное приложение

В единственном нераспределенном х-приложении х-пользователь и х-прнложенне находятся в одном месте. В специальном случае, когда л-пользователь находится во взаимодействии с пользовагелем-человеком и с х-приложением в интересах этого пользователя-человека, де-пользователь называется УП-пользователь, а прикладной процесс — прикладным процессом пользователя (см. 0.3.1). ^-пользователь взаимодействует с ^-приложением через интерфейс л-приложения, который, обычно, является чей-либо собственностью и не является целью стандартизации (см. рисунок D.I).

Рисунок 0.1 — Нераспределенное учрежденческое приложение

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

0.2.2 Единственное распределенное приложение

Распределение л-приложения должно быть прозрачно для .v-пользователя, так что интерфейс х-ирнло-жения меняться не будет. A-клиент расположен в том же самом месте, что и д:-пользователь, ^-пользователь и дг-клиент вместе плодятся в одном и том же прикладном процессе.

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

А-клиент и х-сервер взаимодействуют' через сеть с помощью протокола ледоступа. Между х-клиентом и д-сервером может быть несколько независимых взаимодействий.

Новая ситуация отображена па рисунке D.2. где показано определение х-услуг рисунка 0.1, расширенное до квадрата, содержащею протокол х-доступа.

ПриюмаиоАгсхчюо

ГИПОИДНОЙ

прочих

Протшил

ШфЖф

ялагыомн

■ты

Интерфакс

Oipefloreum

KfWHMM

Рисунок D.2 — Распределенное учрежденческое приложение

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

D.2.3 Взаимодействие ВОС к л и с нт — с е р ве р

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

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

17

Страница 21

ГОСТ Р ИСО/МЭК 10031-1-2000

В соответствии с моделью ВОС, дг-клиент и .v-сервер рассматриваются как часть прикладных процессов и имеют связанные с ними прикладные категории. Прикладные категории являются частью прикладного уровня эталонной модели ВОС и содержат множество элементов прикладных услуг. Элементы прикладных услуг обеспечиваю!' функции взаимосвязи, в соответствии с определением услуг, для дг-клиента и х-сервера и реализуют протокол х-доступа. При этом элемент прикладной услуга может использовать услуги, предоставляемые другими элементами прикладных услуг в той же самой прикладной категории, и услуга, прсдосгаачяе-мые уровнем представления эталонной модели ВОС.

На рисунке D.3 содержимое изображенного пунктиром прямоугольника показывает более детальную модель взаимосвязи ВОС между д-клиентом и л-сервером.

*млхшстк

ИнпффЛс if rfnintnmm


Ожидали и»

W7


Приимдно*

»«■


Протают

тугт


31


сап сэп


СЭЛ


Г^шп

ММ

Щ1МЯЯ

щмя

|сэл||сэп||сэп|


^заввнь | HHH1HHWH

I идотмудони

I


Смдочммдом ЦИЦ 111ИШН1


Рисунок D.3 — Распределенное учрежденческое приложение с взаимосвязью ВОС

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

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

Дополнительные подробности взаимосвязи клиент/сервер описаны в D.4.

D.2.4 Объектная модель распределенного учрежденческого приложения

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

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

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

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

Ничего не значит то. что объекты другого типа используются в контексте распределенных учрежденческих приложений. Последние являются объектами данных (например, типы .тайных АСН. 1. содержание записей, форматы личных документов и пр.). Абстрактный синтаксис этих объектов данных независимо определяется протоколами .v-доступа и протоколами л-сисгемы.

D.3 Функциональная модель

D.3.1 Несколько приложений в интегрированной системе

Интегрированная учрежденческая система образована набором учрежденческих приложений (например, передачи сообщений, записи и поиска документа, печати). Интеграция учрежденческих приложений осуществляется У П-пользователем. У П-пользователь взаимодействуете пользователем-человском и. в интересах этого пользователя-человека, — с набором учрежденческих приложений. Взаимодействия между УП-пользователем и дг-ссрвером осуществляются через дг-клиенга. Взаимодействие между клиентами осуществляется через УП-пользователя. Эго показано на рисунке D.4.

18

Страница 22

ItoBWOiipOUNft

I    I

Огрвмашм    Оулйш—

ГОСТ Р ИСО/МЭК 10031-1-2000


Wf    yw

Рисунок D.4 — Несколько нераспределенных учрежденческих приложений

D.3.2 Несколько распределенных учрежденческих приложений У П - под ьзовател ь и клиеты находятся в одном прикладном процессе, который называется прикладным процессом пользователи (см. рисунок D.5). Несколько прикладных процессов пользователей могут сосушесг-воиать в одном узле пользователя, но в настоящем стандарте они рассматриваются по отдельности.

Пршжпи    Протопал

IhWOiyM    Г*»)»

Рисунок D.5 — Несколько распределенных учрежденческих приложений

Для некоторых приложений (например, справочник, хранилище сообщений) представление каждого УГ1 -пользователя, получившего доступ к серверу, называется агентом пользователя. Этот агент пользователя включает в себя клиентов и У П-пользователя.

D.3.3 Организация серверов

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

Л'-систсма может состоять из:

а)    единственного .v-сервера;

б)    нескольких не взаимодействующих между собой х-серверов;

в)    нескольких взаимодействующих между собой х-серверов.

Взаимодействие между .v-клиентом и х-сервером управляется протоколом х-доступа (см. рисунок 0.6). Эти протоколы являются предметом стандартизации конкретного х-приложения и не рассматриваются подробно в настоящем стандарте.

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

19

Страница 23

al) — протокол х-доступа;

п2) — протокол *-доступ а (факультативен);

»|    —    протокол    х-с и с тс мы (если требуется).

Рисунок D.6 — ^-система

ГОСТ Р ИСО/МЭК 10031-1-2000


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

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

D.3.4 Кооперация между серверами

D.3.4.1 Сервер как пользователь другого сервера

В некоторых случаях одна система (х-систсма) будет пользоваться другой системой (у-систсмой). Такая ситуация моделируется описанием х-сервера. нуждающегося в использовании .г-системы, в роли ^пользователя у-прмложения. Тогда v-клиент существует с прикладным процессом, содержащим х-сервср (см. рисунок D.7).

Рисунок D.7 — Сервер как пользователь другого сервера

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

D.3.4.2 Ссылочный доступ к объекту

Для некоторых типов объектов данных (см. D.2.4) х-сервср действует как источник, а у-сервер — как сток значений данных (например, сервер хранилища сообщений может быть источником, а сервер печати — стоком печатных документов). Вообще говоря, один и тот же сервер может действовать и как источник, и как сток данных (например, сервер записи и поиска документов, сервер хранилища сообщений).

Если х- и у-клиент расположены в одном и том же месте в пределах одного прикладного процесса, а значение объекта должно быть передано от х-сервера к у-серверу, то может оказаться неэффективным передавать это значение объекта через протока! х-досгупа от х-сервера к х-клиенту, а затем — через протокол у-доступа от у-клиента к у-серверу (см. рисунок D.8). В этом случае более эффективно передавать в протоколах доступа только ссылку на значение объекта. Само указанное значение объекта передается непосредственно от источника (х-сервера) к стоку (у-серверу).

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

20

Страница 24

ГОСТ Р ИСО/МЭК 10031-1-2000

Рисунок D.8 — Ссылочный доступ к объектам

D.4 Коммуникационная модель к.шеи г — сервер

В данном подразделе специфицированы некоторые дополнительные подробности коммуникации между дг-клиентом и .v-сервером на основе модели, введенной в D.2.3 и на рисунке D.3.

На рисунках D.9—D.12 показаны различные примеры конфигурации, которые требуют различных наборов сервисных элементов прикладного уровня (СЭП). Сервисный элемент управления ассоциацией (СЭУА) требуется в каждом наборе СЭП. Более того, в каждом наборе требуется сервисный элемент удаленных операций (СЭУО). Сервисный элемент надежной передачи (СЭНГ1) является факультативным. Какие дополнительные СЭП обязательны для данного набора, зависит:

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

б)    от того, свя зан ли набор с клиентом или с сервером;

в)    от того, реализует ли набор протокол доступа или протокол системы.

Спецификации формата объекта данных представляет собой основу кооперации между л:-пользователем и х-сервером или между УП-иодьзователями.

Смрфиу ||ЦМЧИ oMwaww


Сащми ццюшлна


МШЫ9-


Опдорчыи*

xitnf


хлптт


Прштдта

Я*—*


Пругадтя

МтгОСм!

СЭПы<1)


Пртпмоп у-доступа


Ургшт»

И АЙЛМДОШМ


СЭПы(1) — этот набор сервисных элементов приложения вы пап н нет функции, требуемые х-клиентом для связи с х-сервером с использованием иротоката л-доступа.

СЭГ1ы(2) — этот набор сервисных элементов приложения выполняет функции, требуемые .v-сервером для связи с х-клиентом с использованием протокола .v-доступа.

Рисунок D.9 — Взаимодействие ВОС между х-клиентом и х-ссрвером

21

Страница 25

ГОСТ Р ИСО/МЭК 10031-1-2000

елмшмдкяфадшта

uC>»ii ячш

■ггель

\

хчовмнт

кяряу

СЭПы(1) — этот набор сервисных элементов приложения виполнисг функиии. требуемые д:-клиентом для связи с .v-сервером с использованием протокола х-доступа.

СЭПы(2) — этот набор сервисных элементов приложения выполняет функции, требуемые д-сервером для связи с дг-клиентом с использованием протокола д:-доступ а.

СЭПы(З) — этот набор сервисных элементов приложения выполняет функции, требуемые д-сервером для связи с другим д-сервером с использованием протокола .т-системы.

1)    Протокол х-доступа.

2)    Протоксч д-системы.

П р и м с ч а и и с — Прикладные категории, содержащие СЭПы(2) и СЭПы(З), мот быть объединены в одну прикладную категорию, поддерживающую два прикладных контекста.

Рисунок 0.10 — Взаимодействие ВОС между .v-клиентом и .v-сервером и между двумя д-серверами

СЭПы(З) — этот набор сервисных элементов приложения выполняет функиии. требуемые д-сервером для связи с другим .v-сервером с использованием протокола д-системы.

Рисунок D.1I — Взаимодействие ВОС между лс-клиентом и совместно с ним расположенным .v-сервером и

другим д-сервером

22

Страница 26

ГОСТ Р ИСО/МЭК 10031-1-2000

Спцифноря фцмшв овыгадмш

ИЬйМйп

'|П llflllfl— ■!»

9НМ0ИР

нлмнт

хчоттп

Прмпдои

шторм

м

Прагдоая

ншчм

1)

Пршмдни

шпор*

сэг*<1)

сэсыд

СЭПи{1)

пни»мин домни 1Тияти


смдимнмдеяня


ршпи

Hfippmypm*


СЭПы(1) — этот набор сервисных элементов приложения выполняет функции, требуемые х-клиентом для связи с jr-сервером с использованием протокола .v-доступа.

СЭПы(2) — этот набор сервисных элементов приложении выполняет функции, требуемые .v-сервером для связи с .г-клиентом с использованием протокола д-доступа.

1) Протокап л-доступа.

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

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

Рисунок D.12 — Взаимодействие ВОС между двумя х-клиентамн и .v-сервером и между двумя пользователями

D.S Функциональные категории

D.5.I Производящие и поддерживающие приложения и возможности

В настоящем стандарте проводится различие между производящими и поддерживающими приложениями и между производящей и поддерживающей ролями приложения.

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

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

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

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

D.5.2 Операционная поддержка

Общая операционная поддержка, которую могут получать производящие приложения, включает в себя, например:

а)    базовое время.

б)    аутентификацию и атрибуты возможностей,

в)    некоторые функции справочника (например, отображение имен в адреса).

Этот список неполон. В приложении Н приведено более подробное рассмотрение данного вопроса.

23

Страница 27

ГОСТ Р ИСО/МЭК 10031-1-2000

D.5.3 А л м к н и с т р а г и в н о с управление

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

Прочие функции административного управления выглядят как отдельные приложения, а для польэова-теля-человека — как производящие приложения. Это. в частности, справедливо дли анализа и предста&ления информации административного управлении.

Административное управление может сгать предметом последующей стандартизации.

D.5.4 Руководства для приложений

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

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

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

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

D.6 Типы взаимодействии между приложениями

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

Эти типы взаимодействий будут использоваться в последующих подразделах настоящего приложения.

Взаимодействия между .v-пользователе xi и производящим .v-приложением описаны выше и здесь не повторяются.

Взаимодействия между, например, д-полыовагелем и поддерживающим приложением могут происходить в связи с взаимодействием между У П-пользователем и производящим приложением. Это показано на рисунке D.13 как взаимодействие типа 1 между УП-подыователем и (поддерживающим)^-приложением. Информация.

1)    Взаимодействие типа I между УП-пользователем или сервером, действующим в роли .v-полыователн, и .v-сервером, которое приводит к тому, что информация, полученная от у-сервера, используется во взаимодействии с дг-ириложением.

2)    Взаимодейст вие типа 2 между .v- и у-ссрвером. использующее у-клиента и протокол у-доступа.

3)    Взаимодействие типа 3 между двумя серверами, действующими но инструкциям, переданным УП-пользователсм или категорией, играющей роль х- и .г-пользователя (с использованием протоколов х- и

доступа). При передаче информации от л-ссрвера ку-серверу используется СДО-протокол.

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

Рисунок D.13 — Типы взаимодействий

Страница 28

ГОСТ Р НСО/МЭК 10031-1-2000

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

Взаимодействие между двумя серверами (любой из которых может быть производящим или поддерживающим) показано на рисунке D. 13 как взаимодействие типа 2. Л'-сервср использует совместно с .v-клиентом протокол у-доступа для доступа к у-серверу.

Ряд скоординированных взаимодействий существует при ссылочном доступе к объекту. При этом пользователь или категория, действующая как х- и у-пользователь, используя протоколы д:- и у-доступа, даст указания л- и у-серверу об осуществлении передачи шк}юрмаиии. На рисунке D.J3 это показано как взаимодействие типа 3. Таким образом, это взаимодействие содержит два скоординированных щага. Первое действие, внутреннее для пользователя. — скоординировать установку для ссылочного доступа к объекту с дг-и у-сервером. второе — запрос самого доступа.

D.7 Пример взаимодействий приложений

На рисунке D.14 приведен пример взаимодействий между У П-пол ьзоватслем и приложениями, выпш-няюшими производящие и поддерживающие функции.

[а] - мшппктям ян з

р*|-    1;    f*]“—    кшимтиг

Рисунок D.14 — Взаимодействия между УП-пользоватслем хранилища сообщений

и другими приложениями

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

a)    Сервер хранилища сообщений обращается к серверу аутентификации и атрибутов безопасности (взаимодействие типа 2).

b)    УП-пользователь обращается к серверу хранилища сообщений для идентификации сообщения в качестве объекта, который должен быть предоставлен позже.

c)    УП-пользоватсль обращается к справочнику для получения адреса сервера записи и поиска документов, способного записать сообщение (взаимодействие типа I).

d)    У П-пользователь обращается к серверу записи и поиска документов для выбора структуры, в которой сообщение должно быть записано в файл, и идентифицирует это сообщение ссылкой, полученной в результате взаимодействия Ь).

с) Сервер записи и поиска документов получает сообщение от сервера хранилища сообщений через СДО-иротокол (взаимодействие типа 3).

25

Страница 29

ГОСТ Р ИСО/МЭК 10031-1-2000

ПРИЛОЖЕНИЕ Е (Справочное)

Рассмотрение идентификации

Е.1 Общие требования

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

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

Некоторые системные категории, которые должны иметь отличающие имена, перечислены ниже:

-    пользователь-человек;

-    группа пользователей-людей;

-    узел (пользователя и сервера);

-    сервер;

-    объект данных.

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

-    сервера записи и поиска, который содержит конкретную группу файлов;

-    сервера, содержащего хранилище сообщений для конкретного пользователя;

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

-    серверов печати, которые могут предоставить высококачественную печать и широкую каретку.

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

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

-    связывание атрибут—множество имен — эта возможность даст список имен категорий (объектов), имеющих данный атрибут или атрибуты. Одним из примеров являются «желтые страницы» справочника, которые могут использоваться, например, для нахождения имен всех удаленных серверов печати, имеющих высококачественную печать и широкую каретку;

-    альтернативные имена — различные имена дли одной и той же категории (объекта) полезны тем, что предоставляют пользователям больше гибкости при доступе к различным категориям среды распределенного учрежденческого приложения. Для того чтобы обеспечить различное написание для одного и того же объекта, может оказаться удобным использование альтернативных имен (например. MUN1CH/MUNCHEN). Аналогично. в межорганизационном окружении внешне сервер может указываться но имени, отличающемся от его имени, используемом внутри организации, для того чтобы скрыть какие-либо организационные детали.

£.2 Типы имен

E.2.I Обзор

Стандарты для распределенных учрежденческих приложений требуют наименования и адресации ятя следующей информации:

а)    имена и адреса, требуемые для управления прикладными ассоциациями;

б)    имена, требуемые для идентификации пользователей-людей и .г-пользователей;

в)    имена, требуемые для объектов данных.

Е.2.2 Имена и адреса для управления прикладными ассоциациями

В ГОСТ Р ИСО/МЭК 7498-3 установлены принципы для наименования и адресации. Имена и адреса, требуемые .тля управления прикладными ассоциациями, определены в ГОСТ 34.981.

Е.2.3 Имена для пользователей

В контексте MOTIS пользователи идентифицируются O/R-именами. O/R-имя факультативно включает в себя отличающее имя.

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

O/R-имсна определены в ГОСТ Р ИСО/МЭК 10021-2, отличающие имена — в ИСО/МЭК l)594-2 |2j.

26

Страница 30

ГОСТ Р ИСО/МЭК 10031-1-2000

Е.2.4 Имена объектов

Если информация об объекте хранится в справочнике (например, хранилище документов), то этот объект идентифицирован отличающим именем (см. ИСО/МЭК 9594-2 (2|).

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

Для других объектов, требующих однозначной идентификации (см. Е.З), используются идентификаторы объектов АСН.1.

Е.З Регистрация идентификаторов

Ряду типов обьектов должны быть присвоены стандартные идентификаторы либо в соответствующем стандарте, либо уполномоченным по регистрации. Несколько примеров приведено ниже. Идентификаторы являются идентификаторами объектов, определенными в ГОСТ Р ИСО/МЭК 8824.

Е.3.1 Прикладной контекст

Сервисный элемент управления ассоциацией (ГОСТ 34.981) требует идентификации прикладных контекстов.

Е.З.2 Типы содержимого сообщения

Типы содержимого сообщения, определенные в MOTIS. идентифицируют различные типы содержимого, которое может передаваться по протоколу Р1. Тип содержимого является примером спецификации формата объекта данных (см. рисунок D.9). Подробнее см. ГОСТ Р ИСО/МЭК 10021-2.

Е.3.3 Типы частей тела сообщения

Типы частей тела сообщения идентифицируют различные типы формата/кодирования, которые могут быть найдены как часть сообщения пользователя (см. ГОСТ Р ИСО/МЭК 10021-1). Эти типы частей тела сообщения также являются спецификациями формата объекта данных.

Некоторые типы частей тела сообщения определены в ГОСТ Р ИСО/МЭК 10021-7. Другие типы могут быть определены в соответствующих стандартах или уполномоченными по регистрации.

Е.3.4 Типы объектов ООС

Типы объектов ООС определены в ИСО/МЭК 10031-2 (I|.

E.3.S Типы атрибутов

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

ПРИЛОЖЕНИЕ F (справочное)

Концепции безопасности

F.1 Введение

Настоящее приложение является общим руководством.

F.1.1 Определение «безопасности»

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

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

Таким образом, безопасность относится не только к угрозам организации, но и обеспечивает целостность работы.

F. 1.2 Область действия безопасности

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

F.1.3 Политика безопасности

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

27

Страница 31

ГОСТ Р ИСО/МЭК 10031-1-2000

мерами в политике безопасности. Ответственность за реал man и к» полишкп безопасности и за управление ее зффективностью воаяагается на администратора по безопасности.

Ниже приводится примеры вопросов безопасности, которые относятся к политике безопасности. Какие именно меры применяются как часть данной поли-гаки безопасности, зависит от среды организации:

а)    целостность информации, содержащейся и/или обрабатывающейся в системе;

б)    конфиденциальность (избранной) информации, содержащейся и/иди обрабатывающейся в системе;

в)    целостность услуг и функций, обеспечиваемых системой;

г)    конфиденциальность услуг и функций, обеспечиваемых системой;

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

е)    способы аутентификации отдельных пользователей и трупп пользователей в соответствии с определенными правилами;

ж)    управтение доступом к серверам, функциям и информации, доступное в системе;

и) управление потоком информации внутри и между системами.

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

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

F.2 Требования безопасности для распределенных учрежденческих приложений

F.2.I Общие требования безопасности

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

F.2.1.1 Защита доступа

F.2.I.I.I Общие положения

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

F.2.1.1.2 Аутентификация

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

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

F.2.1.1.3 Авторизация доступа

Узлы в среде распределенного учрежденческого приложения могут требовать использования авторизации доступа для зашиты конфиденциальности и целостности объектов безопасности и целостности узла сервер;!. Методы аихоризаини могут использовать различные способы, такие как списки упра&тсния доступом, возможности и другие атрибуты безопасности, но отдельности или в комбинации.

Пользователям должен предоставляться доступ к д-серверам и к объектам безопасности на лг-серверах на основе атрибутов привилегий в соответствии с политикой безопасности вовлеченной(ых) области(ей) безопас-ности.

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

F.2.1.2 Защита информации данных

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

Зашита данных охватывает как конфиденциальность (охрану секретов), так и целостность (защиту от изменений).

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

а) зашита данных при хранении (даже на переносимых носителях);

2S

Страница 32

ГОСТ Р ИСО/МЭК 10031-1-2000

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

Зашита относится к предотвращению утечки существенной информации, а также к предотвращению «загрязнения* достоверной >пн|юрмаиии недостоверной.

Независимо от физической зашиты конфиденциальность может потребовать использования шифрования. а целостность — использования цифровой подписи.

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

F.2.I.3 Защита использования ресурсов

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

F.2.1.4 Подсчет использования ресурсов

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

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

F.2.2 Требования управления безопасностью

F.2.2.I Общие положения

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

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

F.2.2.2 вопросы упрощения безопасностью

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

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

Выявление основывается на проверке безопасности операций системы.

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

Проверка имеет три составляющих:

а)    проверка отслеживания создания и сбора;

б)    проверка отслеживания анализа;

в)    проверка отслеживания архивирования.

Последнее относится и к вопросам администрирования.

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

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

Администрирование имеет два аспекта, относящиеся к жизни системы:

а)    сбор информации от системы:

б)    создание информации для системы.

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

F.3 Модель бе«опасности систем F.3.1 Обзор

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

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

29

Страница 33

ГОСТ Р ИСО/МЭК 10031-1-2000

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

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

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

Имеются два фундамен тально различных уровня, к которым должны относится требования безопасности распределенной системы:

а)    не зависящий от приложения уровень — для управления доступом к объектам безопасности распределенной системы, таким как прикладные процессы пользователя и сервера, рабочие Станции, коммуникационные ресурсы и пр.;

б)    зависящий от приложения уровень — для управления доступом к конкретным объектам безопасности в приложении (таким, как документы).

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

F.3.2 Средства безопасности

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

F.3.2.1 Средство представления iio.ibsoeame.in

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

а)    передачу сведений для аутентификации:

б)    начало выбора сервера:

в)    приостановку неактивных пользователей.

F.3.2.2 Средство аутентификации

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

F.3.2.3 Средство атрибутов безопасности

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

F.3.2.4 Средство авторизации

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

F.3.2.5 Средство управления ассоциацией

Это средство обеспечивает*.

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

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

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

30

Страница 34

ГОСТ Р ИСО/МЭК 10031-1-2000

F.3.2.6 Средство состояния безопасности

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

F.3.2.7 Средство проверки безопасности

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

F.3.2.8 Средство восстановления безопасности

Это средсгво действует по информации о событии от средства проверки безопасности в соответствии с правилами, установленными администратором безопасности.

Г.3.2.9 Межобластное средство

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

F.3.2.I0 Средство поддержки шифрования

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

а)    конфиденциальность данных;

б)    конфиденциальность коммуникаций;

в)    целостность коммуникации:

г)    аутентификация источника данных;

д)    неотрииание источника;

е)    неотрииание получателя.

F.3.3 Поддерживающие безопасность приложения

В настоящем стандарте идентифицированы следующие три поддерживающие безопасность приложении:

а)    приложение аутентификации и атрибутов безопасности; оно объединяет средства аутентификации и атрибутов безопасности;

б)    межобластное приложение; оно является межобластным средством:

в)    приложение проверки безопасности; оно является средством проверки безопасности.

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

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

F.3.4 Заместитель (proxy)

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

а)    д-сервер работает в соответствии со своими собственными интересами:

б)    л-сервер работает в интересах другого субъекта безопасности (например, пользователя-человека).

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

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

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

F.4 Права доступа для распределенных учрежденческих приложений

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

В таблице F.1 показан пример взаимосвязи между стандартным набором абстрактных операций и одним из возможных наборов прав доступа.

Табл и ца F.I — Права доступа и допустимые операции

Права доступа

ВЛА

ЧИУ

ЧИ

ч

Перечислить

X

X

X

X

Читать

X

X

X

X

Изменить

X

X

X

31

Страница 35

ГОСТ Р ИСО/МЭК 10031-1-2000

Окончание таблицы F. I

Операции

Праи доступа

ВЛА

ЧИУ

ЧИ

ч

Копировать

X

X

X

X

Переместить

X

X

Искать

X

X

X

X

Создать

X

Удалить

X

X

Зарезервировать

X

X

X

Отметить

Отказаться

X

X

X

X

Знак «х» означает, что соответствующая операция допустима при соответствующих правах доступа.

Примечание— Использованы следующие четыре уровня прав доступа:

ВЛА — владелец;

ЧИУ — читать—изменять—удалять;

ЧИ — читать—изменять;

Ч — только читать.

ПРИЛОЖЕНИЕG (справочное)

Управление

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

Управление обеспечивается рядом средств, каждое из которых поддерживает один из вопросов требуемого управления. Эта средства включают в себя:

а)    управление неисправностями;

б)    управление подсчетом;

в)    управление конфигурацией и наименованием;

г)    управление выполнением;

д)    управление безопасностью.

Обшис вопросы управления в ВОС рассмотрены в ГОСТ Р ИСО/МЭК 7498-4.

ПРИЛОЖЕНИЕ Н (справочное)

Категории и взаимосвязь приложений

11.1 Введение

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

32

Страница 36

ГОСТ Р ИСО/МЭК 10031-1-2000

Примечание — Далее в настоящем приложении термины «поддерживающее* и «производящее» будут использоваться для описания роли, которую некоторое приложение играет в рассматриваемое время в описываемой активности. В данном приложении не подразумевается, что приложение является внутренне поддерживающим или производящим.

11.2 Работа поддерживающих приложений и средств

Н.2.1 Средство базового времени

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

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

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

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

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

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

Н.2.2 Поддерживающие безопасность приложения

Н.2.2.1 Введение

В настоящем подразделе описаны поддерживающие безопасность приложения, которые вместе обеспечивают:

-    не зависящий от приложения уровень безопасности управления доступом к таким объектам безопасности распределенной системы, как клиенты, серверы, рабочие станции, коммуникационные ресурсы:

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

Илснгифииированы и описаны в последующих пунктах следующие поддерживающие безопасность приложения:

-    приложение аутентификации и атрибутов безопасности (Н.2.2.2):

-    межобластное приложение (Н.2.2.3);

-    приложение проверки безопасности (Н.2.2.4).

Эти приложения безопасности не несут ответственности за:

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

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

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

Эти приложения безопасности не зависят от учрежденческих приложений, которые они поддерживают и обслуживают.

Н.2.2.2 Приложение аутентификации и атрибутов безопасности

Это приложение предназначено для аутентификации и работы с атрибутами безопасности ттользовате-ля-человека и объектами безопасност и уровня приложения, например .v-серверами.

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

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

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

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

33

Страница 37

ГОСТ Р ИСО/МЭК 10031-1-2000

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

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

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

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

И.2.2.3 Межобластное приложение

Пользователи-люди и/или компоненты распределенной системы могут находиться в разных областях безопасности. Эго влияет на вопросы безопасности при взаимодействии между ними. Например, объекты безопасности, свободно доступные людям-пользователям в одной области безопасности, могут быт ь доступны только нескольким людям-пользователям вне этой области.

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

Выбор обьектов безопасности, которые должны быть недоступны для других областей безопасности, может быть различным в зависимости от взаимосвязей между областями безопасности. Этот выбор не является просто иерархическим. При взаимосвязи между двумя областями безопасности конкретное множество объектов безопасности может быть доступно некоторым пользователям из одной области безопасности и не доступно для всех пользователей из других областей, в то время как другие объекты безопасности, недоступные из рассматриваемой области, могут быть доступными для некоторых пользователей из других областей безопасности. Другими словами, одна область безопасности может «доверять» другой области доступ к ограниченному множеству объектов безопасности. Это множество зависит от взаимосвязей между областями безопасности объектов и субъектов безопасности.

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

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

Межобластное приложение отображает интерпретацию:

а)    идентичности субъектов безопасности (пользователей-людей и пользователей),

б)    идентичности объектов безопасности и

в)    атрибутов безопасности

одной области безопасности в интерпретацию другой области.

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

Н.2.2.4 Приложение проверки безопасности

Проел ежи вас мостъ проверки является существенным требованием для любого эффективного мониторинга безопасности.

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

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

Н.2.3 Приложение справочника

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

Когда это возможно, распределенные учрежденческие приложения должны использовать приложение справочника, определенное в стандартах серии ГОСТ Р ИСО/МЭК 9594. например для следующих функций:

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

34

Страница 38

ГОСТ Р ИСО/МЭК 10031-1-2000

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

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

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

Н.2.4 Ссылочный доступ к объекту

Некоторые учрежденческие приложения действуют как источники или стоки объектов, например файлов, документов или частей сообщений Р2.

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

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

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

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

Когда серверам различных приложений требуется некоторое взаимодействие, отличное от простой передачи данных, они используют протоколы доступа, как описано в D.3.3.2. D.6 и D.7.

Н .2.5 Взаимодействия между поддерживающими приложениями

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

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

Примечание — Стрелки и содержимое прямоугольников соответствуют следующей взаимосвязи клиент—сервер:


I Н~ЕЕР


Рисунок H.I — Взаимодействия между поддерживающими приложениями


35

Страница 39

ГОСТ Р ИСО/МЭК 10031-1-2000

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

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

11.3 Поддержка производящих приложений

Н.3.1 Введение

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

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

Упоминаемые ниже типы взаимодействий описаны в D.6.

П.3.2 Поддержка приложения передачи сообщений

П.3.2.1 Описание при.южения передачи сообщений

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

Приложение передачи сообщений определено в ГОСТ Р ИС'О/МЭК 10021-3.

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

П.3.2.2 Работа пршожения передачи сообщений

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

Следующие взаимодействия могут быть вовлечены в типичное использование приложения передачи сообщений:

а)    пользователь приложения передачи сообщений обращается к базовому времени;

б)    пользователь приложения передачи сообщений обращается к приложению справочника для получения адреса представления сервера передачи сообщений (взаимодействие типа 1);

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

г)    пользователь приложения передачи сообщений представляет сообщение на сервер передачи сообщений;

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

с) сервер передачи сообщений обращается к базовому времени для создания временной метки для каждого сообщения:

ж) сервер передачи сообщений обращается к приложению справочника для раскрытия «получателей», которые являются списками рассылки (взаимодействие типа 2);

и) сервер передачи сообщений обращается к приложению справочника для получения адресов представления всех серверов хранения сообщений получателей (взаимодействие типа 2).

П.3.3 Поддержка хранилища сообщений

Н.3.3.1 Описание доступа к хратиищу сообщений

Приложение хранения сообщений тесно связано с приложением передачи сообщений. Приложение передачи сообщений фактически опускает сообщение в «почтовый ящик», связанный с пользователем, а приложение хранения сообщений позволяет этому пользователю получить письмо. Приложение хранения сообщений определено в ГОСТ Р ИСО/МЭК 10021-5.

П.3.3.2 Работа при.южения хранения сообщений

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

Следующие взаимодействия могут быть вовлечены в типичное использование приложения хранения сообщений:

а)    агент пользователя (см. ГОСТ Р ИСО/МЭК 10021-2) обращается к базовому времени;

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

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

г)    агент пользователя запрашивает сообщения из хранилища сообщений:

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

с) хранилище сообщений использует средство авторизации для проверки допустимости доступа;

ж) хранилище сообщений возвращает пользователю сообщение.

36

Страница 40

ГОСТ Р ИСО/МЭК 10031-1-2000

Н.3.4 Поддержка приложения записи и поиска документов

Н .3.4.1 Описание приложения записи и поиска документов

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

Приложение записи и поиска документов также обеспечивает управление доступом к хранению документов.

Н.3.4.2 Работа пргиожения записи и поиска документов

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

Следующие взаимодействия могут быть вовлечены в использование (в данном примере — для поиска) приложения записи и поиска документов:

а)    пользователь приложения записи и поиска документов обращается к базовому времени;

б)    пользователь приложения записи и поиска документов обращается к приложению справочника дли получения адреса представления требуемого ему сервера записи и поиска документов (взаимодействие типа 1);

в)    пользователь приложении записи и поиска документов обращается к приложению аутентификации и атрибутов безопасности для получения атрибутов безопасности для доступа к серверу записи и поиска документов (взаимодействие типа 1):

г)    пользователь приложения записи и поиска документов запрашивает документ от сервера записи и поиска документов:

д)    сервер записи и поиска документов может обратиться к приложению аутентификации и атрибутов безопасности для аутентификации пользователя приложения записи и поиска документов (взаимодействие типа 2);

е)    приложение записи и поиска документа возвращает документ пользователю данного приложения.

Н.3.5 Поддержка приложения печати документов

П.3.5.1 Описание приложения печати документов

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

П.3.5.2 Работа при.южения печати документов

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

Следующие взаимодействия могут быть вовлечены в использование (в данном примере—для печати документа) приложении печати документов:

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

б)    пользователь приложения печати документов обращается к приложению справочника для получения адреса представления требуемого ему сервера печати (взаимодействие типа 1):

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

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

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

с) сервер печати помешает документ в очередь для печати:

ж)    приложение печати документов извещает пользователя о завершении запроса.

ПРИЛОЖЕНИИ J (справочное)

Модель объекта

J.1 Введение

Как клиент, так и сервер рассматриваются как содержащие объекты.

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

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

37

Страница 41

ГОСТ Р ИСО/МЭК 10031-1-2000

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

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

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

б)    с конкретным множеством экземпляров объектов д-сервера и, факультативно, д>клиента.

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

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

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

J.2 Взаимосвязь между дг-сервсром н экземплярами объектов

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

На рисунке J.1 показаны три различных ситуации отношений экземпляров дг-объектов и .v-серверов:

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

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

л) Протокол х-дасIупa: s.) Протокол х-системы м.ш х-клиент н протокол л-лоступа Рисунок J.1 — Сервер и экземпляры объектов

38

Страница 42

ГОСТ Р ИСО/МЭК 10031-1-2000

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

С точки зрения х-клиента, между этими тремя ситуациями ист различия. А'-клиент просто задаст типы операций относительно х-сервера, с которым он взаимодействует, используя протокол х-доступа. Не обязательно все три рассмотренных варианта должны поддерживаться каждым распределенным учрежденческим приложением.

ПРИЛОЖЕНИЕ К. (справочное)

Стандартный набор операций

К.1 Введение

В данном приложении подробнее рассмотрен пример стандартного набора абстрактных операций РУП. введенный в 6.6.

Набор абстрактных операций содержит следующие операции:

а)    перечислить;

б)    читать:

в)    изменить;

г)    копировать;

д)    переместить; с) искать:

ж) создать; и) удалить; к) зарезервировать: л) отмстить: м) отказаться.

К.2 Описание операций

Примечания

1    «Идентификатор объекта* является именем объекта или ООС. В случае операции потребления или операции доступа используется ООС.

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

К.2.1 Перечислить

Операция «перечислить» используется для получения списка компонентов в заданном объекте. Аргумент операции «перечислить* может содержать следующие компоненты:

а)    идентификатор объекта;

б)    селектор;

в)    запрошенные атрибуты;

г)    индикация запроса (запрашивается значение обьскга или ООС).

Результат операции «перечислить» может содержать компонент: значение списка или ООС списка.

К.2.2 Читать

Операция «читать» используется для получения значения или ООС и атрибутов заданного(ых) объек-та(ов).

Аргумент операции «читать» может содержать следующие компоненты:

а)    идентификатор обьскта;

б)    селектор;

в)    запрошенные атрибуты;

г)    индикация запроса (запрашивается значение обьскга или ООС).

Результат операции «читать» может содержать компонент; значение или ООС объекта, который должен быть прочитан.

К.2.3 Изменить

Операция «изменить* используется для изменения значения и/или атрибутов заданного объекта. Аргумент операции «изменить» может содержать следующие компоненты:

39

Страница 43

ГОСТ Р ИСО/МЭК 10031-1-2000

а)    идентификатор объекта;

б)    изменения (удаление, замену или добавление).

Результат операции «изменить- может не содержать никаких компонентов.

К.2.4 Копировать

Операции «копировать» используется для копирования объекта.

Аргумент операции «копировать» может содержать следующие компоненты:

а)    идентификатор объекта;

б)    селектор;

в)    запрошенные атрибуты;

г)    идентификатор объекта назначения.

Результат операции «копировать» может не содержать никаких компонентов.

К.2.5 Переместить

Операция «переместить* используется для перемещении объекта.

Аргумент операции «переместить» может содержать следующие компоненты:

а)    идентификатор объекта;

б)    селектор;

в» запрошенные атрибуты; г) идентификатор объекта назначения.

Результат операции «переместить» может не содержать никаких компонентов.

К.2.6 Искать

Операция «искать» используется для идентификации объектов, которые соответствуют заданным условиям. и помещения результата в заданном обьекте назначения.

Аргумент операции «искать» может содержать следующие компоненты:

а)    идентификатор объекта;

б)    селектор;

в)    запрошенные атрибуты;

г)    идентификатор объекта назначения;

д)    индикация запроса (запрашивается значение обьскга или ООС).

Результат операции «искать» может* содержать компонент: идентификатор объекта назначения.

К.2.7 Создать

Операции «создать» используется для создания объекта. Факультативно может быть допустимо присвоение значения и атрибутов.

Аргумент операции «создать» может содержать следующие компоненты:

а)    идентификатор объекта;

б)    поддерживаемые атрибуты;

в)    значение объекта и/или атрибутов;

г)    индикация запроса (запрашивается значение обьскга или ООС).

Результат операции «создать» может содержать компонент; идентификатор объекта.

К.2.8 Удалить

Операция «удалить» используется для удаления обьскга.

Аргумент операции «удалить» может содержать следующие компоненты:

а)    идентификатор обьскта;

б)    селектор.

Результат операции «удалить* может не содержать никаких компонентов.

К.2.9 Зарезервировать

Операция «-зарезервировать» используется для «фиксации» обьскга для предотвращения его изменения или удаления другими пользователями.

Аргумент операции «зарезервировать» может содержать следующие компоненты:

а)    идентификатор обьскта;

б)    запрошенное действие (зарезервировать или освободить).

Результат операции «зарезервировать» может не содержать никаких компонентов.

К.2.10 От XI с г и ть

Операция «отметить» используется для задания информации о статусе изменений заданного объекта. Аргумент операции «отметить» может содержать компонент: идентификатор объекта.

Результат операции «отметить» может не содержать никаких компонентов.

К.2.II Отказаться

Операция «отказаться» используется для отказа от выполнения ранее запрошенной задачи (например, «найти*).

Аргумент операции «отказаться» определяет данную задачу.

Результат операции «отказаться* может не содержать никаких компонентов.

Страница 44

ГОСТ Р ИСО/МЭК 10031-1-2000

ПРИЛОЖЕНИЕ L (справочное)

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

|1| ИС'О/МЭК 10031-2—91 Информационная технология. Текстовые и учрежденческие системы. Часть 2. Модель приложений распределенного учреждения

|2| ИСО/МЭК 9594-2—95 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 2. Модели

41

Страница 45

ГОСТ Р ИСО/МЭК 10031-1-2000

УДК 681.324:006.354    ОКС    35.100.70    Г1Х5    ОКСТУ    4002

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

Редакюр В. II. Огурцов Технический редактор В.II. Прусаками Коррекюр B.C. Черпах Компьютерная верстка В.II. Грисаенко

Над. лиц. N: 02354 от 14.07.2000. Сдано в набор 19.12.2000. Подписано в печать 29.01.2001. Уел. печ. л. 5.12.

Уч.-изд. л. 4.S0.    Тираж 3IKI экз.    С    174.    Зак.    105.

И ПК Издательство стандартов. 107076. Москва. Колодезный пер.. 14.

Набрано и Издательстве на ПЭВМ Филиал ИПК Издательство стандартов — тип. "Московский печатник". 103062. Москва. Лялин пер.. 6

Плр N 0S0I02