Профилей

Необходимость такого согласования возникает, в частности, при

использовании стандартизованных API-интерфейсов, в том числе ин-

терфейсов приложений со средой их функционирования, интерфейсов

приложений со средствами защиты информации. При согласовании

функциональных профилей ППО возможны также уточнения профиля

среды ИС и профиля встраиваемых инструментальных средств созда-

ния, сопровождения и развития ППО.

Наиболее выпукло проблемы формирования функциональных

профилей можно показать на примере открытой распределенной ин-

формационной системы с архитектурой «клиент-сервер». Рассмотрим

общие подходы к построению профилей таких систем.

Профиль среды распределенной ИС должен определять ее архи-

тектуру в соответствии с выбранной моделью распределенной обра-

ботки данных, например, Distributed Computing Environment (DCE)

или Common Object Request Broker Architecture (CORBA).

В первом случае модель определяется стандартами консорциума

OSF, в частности, используется механизм удаленного вызова проце-

дур (Remote Procedure Call — RPC) с учетом стандартов «де-факто»,

которые специфицируют применяемые мониторы транзакций (напри-

мер, монитор транзакций Tuxedo).

Во втором случае модель определяется стандартами консорциу-

ма OMG, в частности спецификацией брокера объектных запросов

(Object Request Broker — ORB). Стандарты интерфейсов API прило-

жений со средой ИС должны быть определены по функциональным

областям профилей ИС. Декомпозиция структуры среды функциони-

рования ИС на составные части, выполняемая на стадии эскизного

проектирования, позволяет детализировать профиль среды ИС по

функциональным областям эталонной модели OSE/RM:

• графического пользовательского интерфейса (MOTIF консорци-

ума OSF или стандарт X Window IEEE);

• реляционных или объектно-ориентированных СУБД (например,

стандарт языка SQL-92 и спецификации доступа к разным базам

данных);

• операционных систем с учетом сетевых функций, выполняемых

на уровне операционной системы (например, набора стандартов

POSIX — ISO и IEEE);

• телекоммуникационной среды в части услуг и сервисов при-

кладного уровня: электронной почты (по рекомендациям ITU-T

Х.400, Х.500), доступа к удаленным базам данных RDA (по

стандарту ISO 9594-1.2), передачи файлов, доступа к файлам и

управления файлами (по стандарту ISO 10607 — 1, 2, 3, 4, 5, 6).

Профиль среды распределенной ИС должен включать в себя:

• стандарты протоколов транспортного уровня (по ISO/IEC OSI

или стандарт «де-факто» протокола TCP/IP);

• стандарты локальных сетей (например, стандарт Ethernet IEEE

802.3 или стандарт Fast Ethernet IEEE 802.3 u);

• стандарты средств сопряжения проектируемой ИС с сетями

передачи данных общего назначения (например, по рекоменда-

циям ITU-T: Х.25, Х.З, Х.29 и др.).

Профиль и выбор аппаратных платформ ИС связан с определе-

нием их параметров: вычислительной мощности серверов и рабочих

станций в соответствии с проектными решениями по разделению

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

аппаратных платформ; надежности. Функциональный профиль ИС со-

держит стандарты, определяющие параметры технических средств и

способы их измерения (например, стандартные тесты измерения

производительности).

Профиль защиты информации в ИС должен обеспечивать реа-

лизацию политики информационной безопасности, разрабатываемой в

соответствии с требуемой категорией безопасности и критериями без-

опасности, заданными в техническом задании на систему. Построение

профиля защиты информации в распределенных системах «клиент-

сервер» методически связано с точным определением компонентов

системы, ответственных за те или иные функции, сервисы и услуги, и

средств защиты информации, встроенных в эти компоненты. В обла-

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

• защита, реализуемая операционной системой;

• защита от несанкционированного доступа на уровне программ-

ного обеспечения промежуточного слоя;

• управление данными, реализуемое СУБД;

• защита программных средств, в том числе средства защиты от

вирусов;

• защита информации при обмене данными в распределенных си-

стемах, включая криптографические функции;

• администрирование средств безопасности.

Основополагающим документом в области защиты информации

в распределенных системах являются рекомендации Х.800, принятые

МККТТ (сейчас ITU-T) в 1991 г. Подмножество указанных рекомен-

даций должно составлять профиль защиты информации в ИС с учетом

распределения функций защиты информации по уровням концеп-

туальной модели ИС и взаимосвязи функций и применяемых механиз-

мов защиты информации. При использовании профиля защиты ин-

формации в ходе проектирования, разработки и сопровождения ИС

целесообразно учитывать методические рекомендации, изложенные в

интерпретации «Оранжевой книги» национального центра компью-

терной безопасности США для сетевых конфигураций. Профиль за-

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

средства обнаружения в применяемых аппаратных и программных

средствах недекларированных возможностей («закладок» и вирусов).

Профиль должен также содержать указания на методы и средства ре-

зервного копирования информации и восстановления информации

при отказах и сбоях аппаратуры системы.

Профиль инструментальных средств, встроенных в ИС, отоб-

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

провождения и развития конкретной ИС, описание которых должно

быть выполнено на стадии эскизного проектирования системы. Состав

встроенных инструментальных средств определяется на основании ре-

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

развития ИС. При этом должны быть учтены правила и порядок, ре-

гламентирующие внесение изменений в действующие системы. В об-

ласти профиля инструментальных средств, встроенных в ИС, должны

выполняться функции централизованного управления и администри-

рования, связанные:

• с контролем производительности и корректности функциониро-

вания системы в целом;

• преобразованием конфигурации ППО, тиражированием версий;

• управлением доступом пользователей к ресурсам системы и

конфигурацией ресурсов;

• перенастройкой приложений в связи с изменениями прикладных

функций ИС;

• настройкой пользовательских интерфейсов (генерацией экран-

ных форм и отчетов);

• ведением баз данных системы;

• восстановлением работоспособности системы после сбоев и ава-

рий.

Дополнительные ресурсы, необходимые для функционирования

встроенных инструментальных средств (минимальный и рекомендуе-

мый объем оперативной памяти, размеры требуемого пространства на

дисковых накопителях и т.д.), учитываются в разделе проекта, относя-

щемся к среде ИС. Выбор инструментальных средств, встроенных в

ИС, производится в соответствии с требованиями профиля среды ИС.

Ссылки на соответствующие стандарты, входящие в профиль среды,

должны быть указаны и в профиле инструментальных средств,

встроенных в ИС. В этом профиле также предусмотрены ссылки на

требования к средствам тестирования, которые необходимы для про-

цессов сопровождения и развития системы. К встроенным в ИС сред-

ствам тестирования относятся средства функционального контроля

приложений, проверки интерфейсов, системного тестирования и диа-

гностирования серверов (клиентов) при максимальной нагрузке.

Поясним сказанное ранее на конкретном примере. Нужно по-

строить профили основных функциональных компонент корпоратив-

ной ИТ компании, которая хотела бы обеспечить переносимость раз-

рабатываемых ею SQL-приложений (как серверной, так и клиентских

частей), написанных с использованием языков С++ и SQL. Сетевая

инфраструктура данной организации основана на использовании ло-

кальной сети FDDI (рис. 2.15).

Для обеспечения целей открытости корпоративная технология

должна строиться из программных и аппаратных систем, поведение

которых на своих интерфейсах соответствует стандартам. В частно-

сти, в данном случае задача состоит в том, чтобы построить два OSE-

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

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

Рис. 2.15. Пример корпоративной информационной технологии

Обозначим для определенности профиль клиентской стороны

системы (Client Side of System) как <PC>. Он будет включать в себя

спецификации как минимум двух классов интерфейсов, а именно ин-

терфейса API, определяющего взаимодействие клиентской системы с

прикладной программой (Application Program), а также коммуникаци-

онного интерфейса, определяющего состав протоколов сетевого взаи-

модействия между клиентскими и серверными системами.

Коммуникационный интерфейс можно формировать, начиная с

мощного протокола прикладного уровня RDA (ISO 9579), используе-

мого, в частности, для реализации распределенных SQL-приложений

с архитектурой «клиент-сервер» над стеком протоколов модели

RM OSI. Для большей гибкости решения разобьем стек протоколов

модели RM OSI на две группы протоколов: протоколы верхних трех

уровней, которые обозначим OSI Stack (7-5), и протоколы транспорт-

ной системы, обеспечивающие транспортные услуги OSI в режиме с

соединением.

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

ванных профилей, то можно обнаружить, что уже существует про-

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

ных по транспортному протоколу OSI через локальную сеть FDDI.

Данный профиль имеет наименование <ТС54>. Он включает в себя

ссылки на стандарт транспортного протокола OSI, стандарт протокола

сетевого уровня (Х.25) вместе с дополнениями, адаптирующими этот

протокол для использования в локальных сетях, а также ссылки на

стандарты протоколов нижних уровней, определяющих функциониро-

вание сети FDDI. Профиль <ТС54> является типичным примером

OSI-профиля, так как устанавливает только функции сетевого взаимо-

действия, определенные стандартными протоколами, разработанными

в соответствии с моделью RM OSI.

Таким образом, описание коммуникационного интерфейса в

профиле <РС> будет содержать ссылки на следующие спецификации:

стандарт протокола DRA, стандарты протоколов верхних уровней мо-

дели RM OSI (OSI Stack (7-5)), профиль <ТС54>.

В состав спецификаций API необходимо включить стандарты

языков <С++>и <SQL> (Std «С++» и Std «SQL» соответственно), а

также интерфейс RDA, реализующий сервис протокола RDA для кли-

ентских систем. Следовательно, описание интерфейса API в профиле

<РС> содержит ссылки на следующие спецификации: Std «С++»,

Std «SQL», интерфейс RDA-клиента.

В профиль <РС> могут входить спецификации и других классов

интерфейсов, например графического пользовательского интерфейса.

Тогда в профиль <РС> пришлось бы включать такие ссылки, если бы

одним из исходных требований к разрабатываемой системе было тре-

бование обеспечения легкости перевода пользователей с одной

компьютерной платформы на другую.

Профиль серверной части (Server Side of System) обозначим как

<PS>. Он будет содержать идентичный с профилем <РС> коммуника-

ционный интерфейс (иначе клиентские и серверные системы не смог-

ли бы взаимодействовать). Интерфейс API профиля <PS> будет почти

идентичным соответствующему интерфейсу профиля <РС>, за исклю-

чением некоторых различий в программных интерфейсах для сервиса

RDA в клиентской и сервисных системах.

Если в исходной постановке задачи имеется требование обеспе-

чения переносимости хранимых данных, то в профиль <PS> следова-

ло бы ввести ссылки на стандарты, определяющие форматы представ-

ления данных в долговременной памяти. Такие стандарты относятся к

классу интерфейсов, называемых информационными.

В соответствии с введенными определениями, построенные в

примере профили <РС> и <PS> относятся к OSE-профилям. С целью

наглядного представления случаев применения и функциональности

профилей используются специальные схемы (сценарии), на которых,

как правило, определяются основные функциональные компоненты

описываемой данным профилем технологии, их взаимосвязи, интер-

фейсы, распределение основных функций в системе и пр. Для профи-

лей <РС> и <PS> таким сценарием может служить схема, показанная

на рис. 2.16.

Рис. 2.16. Пример схемы (сценария) для наглядного представления случаев при-