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

Запечников С.В. Стандартизация информационных технологии в аспекте защиты информации в открытых системах. - М.: МИФИ, 2000. - 135 с. Книжная серия журнала «Безопасность информационных технологий» В работе рассматривается состояние и развитие стандартизации современных информационных технологий, связанных преимущественно с понятиями распределённой обработки данных и открытых систем. На основе анализа основных международных и национальных стандартов раскрываются основные элементы концепции открытых систем, рассматриваются необходимые условия совместимости систем обработки данных и свойства открытых информационных систем. Проводится аналитический обзор важнейших стандартов, моделей и направлений развития открытых распределённых вычислений, а также кратко рассматриваются отличительные особенности подходов ведущих мировых фирм - лидеров на рынке информационных технологий. Отдельная глава посвящена стандартам и архитектурным моделям защиты информации в открытых системах. Предназначено для студентов факультетов «Б» и «К» МИФИ, для руководства и администраторов центров защиты информации и для слушателей курсов повышения квалификации сотрудников банковской сферы. СОДЕРЖАНИЕ Введение 1. Основные элементы технологии открытых систем 1.1. Среда информационных технологий 1.2. Концепция открытых систем 1.3. Роль стандартов в технологии открытых систем. Основные группы стандартов и организации по стандартизации 2. Переносимость и способность к взаимодействию 2.1. Основные аспекты совместимости систем 2.2. Переносимость 2.3. Способность к взаимодействию 3. Основные модели открытых систем и их развитие 3.1. Классификация моделей 3.2. Базовые стандартные модели 3.2.1. Модель ISO OSI 3.2.2. Модель POSIX OSE 3.3. Модели сред открытых систем 3.4. Модели распределённых систем 3.5. Обобщённые модели открытых распределённых вычислений 3.5.1. Модель RM-ODP 3.5.2. Модель TOGAF 3.5.3. Модель IT DialTone 3.6. Подходы ведущих фирм-производителей к организации распределённых сред 4. Стандарты и модели защиты информации в открытых системах 4.1. Защита информации в модели ISO OSI. Стандарты ISO 4.2. Защита информации в модели POSIX OSE 4.3. Модели защиты информации в документах The Open Group Заключение. Роль стандартизации в развитии информационных технологий

ВВЕДЕНИЕ Интенсивное развитие современных технологий обработки данных привело к появлению и развитию сложного комплекса научно-технических дисциплин, получившего название "информационные технологии". Под этим термином обычно понимают совокупность научных методов, инженерных, технических приёмов и технологических решений, связанных с процессом обработки информации при помощи электронного оборудования (компьютеров, коммуникационных устройств, сетей связи, носителей данных), системного и прикладного программного обеспечения. Создание и функционирование любой технологии компьютерной обработки данных подчиняется совокупности требований потребителя информации, а также техническим требованиям и возможностям. К первой группе относятся требования той предметной области, для которой предназначена технология, требования бизнеса, экономические условия и пр. Среди технических условий особое значение имеют быстро расширяющиеся возможности компьютерного хранения и обработки информации, коммуникационные возможности, требования со стороны приложений, условия разработки и эксплуатации программного обеспечения и пр., а также обеспечение совместной обработки данных различными компьютерными системами. Информационные технологии за несколько десятилетий прошли ряд этапов, характеризующихся сменой концепций, принципов и взглядов на их назначение, функции, методы построения. Современный этап развития информационных технологий отмечен следующими важными обстоятельствами: • переходом от централизованной к полностью распределённой модели обработки данных; • значительным расширением сфер применения информационных технологий при одновременной универсализации функций, выполняемых вычислительными системами; • потребностью сохранения существующих технологических решений при развёртывании новых систем обработки данных и обеспечения совместимости между ними в различных аспектах; • высокой сложностью не только электронной техники и системного программного обеспечения, но и самой логической организации (структуры, отдельных компонент и взаимосвязей между ними) систем обработки данных и приложений. Создание и эксплуатация сложных систем обработки данных требует определённой научно-методической основы. В качестве такой основы на сегодняшний день выступает система международных стандартов и других координирующих документов, созданных специализированными международными организациями. В данной работе основное внимание уделяется анализу современных логических моделей организации, методов и инструментов описания сложных систем компьютерной обработки данных. Рассматриваемые методы и модели исторически развивались в русле двух основных течений. Во-первых, ведущие фирмы-производители оборудования, программного обеспечения и поставщики решений для систем обработки данных, ощущая неуклонное усложнение структуры таких систем, сами стремились сформулировать стратегические направления развития информационных технологий и следовать им в своей деятельности. Во-вторых, эта работа осуществлялась в рамках международных органов стандартизации, промышленных групп и консорциумов, различных международных объединений и союзов. Причём, как правило, деятельность международных организаций строится с учётом и на основании уже накопленного ведущими фирмами научного потенциала и созданных ими технологических решений. Документы международных организаций оформляют, обобщают и "приводят к общему знаменателю" мнения большей части заинтересованных фирм и промышленных групп. На сегодняшний день основным "законодательством" в сфере информационных технологий является именно совокупность документов и стандартов международных организаций. В силу высокой сложности современных информационных технологий общепринятой мировой практикой является обращение к этим документам и использование их в качестве базы для развития и совершенствования любых новых технологий. Более того, в настоящее время стандарты играют роль не только

нормативных или рекомендательных документов, но и в совокупности задают своеобразную "философию" современных информационных технологий. Стандарты, являясь результатом коллективной работы большого числа участников процесса стандартизации, предоставляют чёткую научную основу для рассмотрения различных аспектов информационных технологий, которую не всегда представляется возможным выявить на основе изучения и анализа материалов отдельных фирм, документации к программным продуктам и публикаций в печати. Пристальное внимание к документам международных организаций и промышленных консорциумов представляется необходимым и по следующим причинам: Они определяют довольно обширную систему понятий и терминов в области информационных технологий, принятую в результате соглашений, достигнутых между большим числом участников организаций. • Хотя совокупность документов различных организаций и не образует между собой единой системы, но большинство из них прямо или косвенно имеет связь с документами других организаций либо является их развитием, расширением, уточнением. Это создаёт предпосылки для формирования единого, обобщённого теоретического взгляда на информационные технологий. • Большинство из рассматриваемых стандартов имеют равный статус как у нас в стране, так и за рубежом, так как Россия является членом многих международных органов стандартизации. Международные стандарты могут служить основой для разработки национальных стандартов. • Данные стандарты и модели являются основой для более детального рассмотрения (также на основе существующих стандартов и документов) практически всех основных направлений современных информационных технологий: телекоммуникационных технологий, операционных систем, систем управления базами данных, языков программирования, управления системами обработки данных, проблем безопасности информационных технологий и многих других направлений. • Рассматриваемые стандарты и модели предоставляют базу для развития сложных информационных технологий, таких как технология Internet, создание инфраструктуры для электронного бизнеса и др. • Анализ существующих стандартов и моделей позволяет выявить нерешённые проблемы и определить направления дальнейшего научного поиска. В данной работе предпринимается попытка анализа состояния и развития стандартизации информационных технологий на современном этапе, связанных преимущественно с понятиями технологий открытых систем и распределённых вычислительных сред. Работа не ставит целью подробное изложение стандартов и моделей информационных технологий. Здесь рассмотрены главные вопросы, которые позволяют ориентироваться в большом числе документов, выбирать необходимые для решения более конкретных задач. За 1990-е гг. состояние международной стандартизации информационных технологий существенно изменилось. Количество стандартов многократно возросло, а их качественный состав принципиально изменился, появились систематизированные собрания стандартов. К сожалению, отечественные издания по этой тематике довольно малочисленны [2,3,6,7], а столь значительные изменения пока практически не нашли отражения в отечественной литературе. Данная работа пытается восполнить этот пробел: в ней на основе зарубежных публикаций и материалов рассматривается состояние стандартизации на 1999 — 2000 г. В главе 1 рассматриваются основные элементы технологии открытых информационных систем: основные понятия, характеристика технологии открытых систем, обсуждается объективная необходимость стандартизации в рамках понятия открытой системы, основные группы стандартов и организаций по стандартизации. Глава 2 посвящена более детальному рассмотрению основных качеств, которыми характеризуются открытые системы: переносимости и способности к взаимодействию. В главе 3 обсуждаются основные модели информационных технологий с позиций открытых систем в их эволюционном развитии, приведшем к понятию открытых распределённых вычислительных сред и созданию обобщённых моделей систем распределённой обработки данных. Кратко затрагиваются подходы ведущих фирм-производителей и поставщиков решений в

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

Глава 1. ОСНОВНЫЕ ЭЛЕМЕНТЫ ТЕХНОЛОГИИ ОТКРЫТЫХ СИСТЕМ 1.1. Среда информационных технологий Практически любая крупная современная организация (предприятие, учреждение) независимо от профиля своей деятельности в той или иной мере осуществляет обработку информации, необходимой для функционирования этой организации, т.е. нуждается в информационном обеспечении своей деятельности. Под информационным обеспечением деятельности предприятия, учреждения или другой организации понимается создание, организация и обеспечение функционирования такой системы сбора, хранения, обработки и выдачи информации, которая обеспечивала бы предоставление всем подразделениям и должностным лицам организации всей необходимой им информации в требуемое время, требуемого качества и при соблюдении всех устанавливаемых правил обращения с информацией. В связи со всё возрастающим объёмом информации, подлежащей обработке, в большинстве случаев информационное обеспечение деятельности предприятия осуществляется при помощи компьютерной информационной системы. Под (компьютерной) информационной системой понимается сложная система, включающая всю совокупность аппаратного, системного и прикладного программного обеспечения и методов их организации, которая обеспечивает информационную деятельность предприятия. Этот термин используется, когда компьютерная система рассматривается с точки зрения пользователя, потребителя предоставляемых ею услуг и возможностей. Словами "система обработки данных" ("система обработки информации") чаще всего обозначается сложная система, включающая технические средства преобразования, хранения и передачи информации (аппаратное и системное программное обеспечение) и методы их организации, которая обеспечивает поддержку приложений пользователей. Под приложениями понимаются компьютерные программы, предназначенные для выполнения специфических задач пользователей. Термин "система обработки данных", как правило, используется, когда компьютерная система рассматривается "изнутри", с точки зрения конструктора, проектировщика, программиста. Иными словами, под системой обработки данных понимается та техническая основа, на которой строится информационная система. Чтобы различать отдельные средства вычислительной техники, входящие в сложную систему обработки данных, будем называть их вычислительными системами. Таким образом, информационная система предназначена для решения каких-либо конкретных прикладных задач предприятия или организации, т.е. обеспечивает поддержку информационной деятельности пользователей, а система обработки данных предоставляет ей средства для решения этих задач, т.е. поддерживает приложения. Часто используется также термин "среда" (среда информационных технологий, распределённая вычислительная среда, среда приложения, телекоммуникационная среда и т.п.) — это конкретное воплощение информационной системы или её части, например, приложений, коммуникационной сети, в отдельно взятой вычислительной системе, на данном конкретном предприятии, в регионе и т.д., со всей совокупностью присущих ей качеств, особенностей, образуемых всеми используемыми методами и средствами обработки данных, и условий, в которых протекает процесс обработки информации. Рассмотрим характеристики типичной информационной системы достаточно крупной организации. Важнейшими из них являются следующие: • Разнородность (гетерогенность). Сложность и специфичность задач, решаемых информационной системой организации, обширность и сложность структуры системы приводят к наличию в ней большого количества аппаратных и программных средств от различных производителей и поставщиков. Они, вероятно, не предназначены изначально к совместной работе друг с другом. Несовместимость аппаратного и программного обеспечения обусловлена в основном причинами "исторического" характера. Так, известно, что развитие систем обработки данных происходило несколькими самостоятельными путями: • централизованные технологии, мэйнфреймы (mainframe) — многопользовательские многозадачные вычислительные системы высокой производительности с очень развитым набо-

ром возможностей по обработке информации, пользовательскими сервисами и возможностями управления системой (например, система IBM S/390); • UNIX-системы — попытка достижения независимости приложений от аппаратного обеспечения вычислительной платформы; • RISC-технологии (reduced instructions set computer) — попытка приблизить производительность, достигнутую мэйнфрейм-технологиями, на системах более низкого уровня (POWER, RS/6000); • системы среднего уровня (midrange systems) — попытка оптимизировать структуру вычислительной системы к требованиям сред приложений с не очень высокими требованиями, например, для среднего бизнеса, промышленных предприятий (VAX, AS/400); • персональные системы — попытка перенести традиционные технологии обработки данных, ориентированные на бизнес, в повседневную практику индивидуальных пользователей (Intel 80х86, Motorola 600х0, Alpha); • суперкомпьютеры - многопроцессорные вычислительные комплексы очень высокой производительности, обладающие параллелизмом аппаратной архитектуры и требующие специального программного обеспечения, предназначенные, как правило, для решения специальных классов задач с очень интенсивными вычислениями (IBM SP1 и SP2, CRAY, NEC, Fujitsu, Hitachi, «Эльбрус» и др.). Каждый из этих путей связан в историческом аспекте с теми или иными классами системного программного обеспечения. Для каждой из систем создан большой набор прикладных программ. Эволюция систем обработки данных привела к тому, что потребитель может выбирать изделия из большого числа типов процессоров, архитектур, системного программного обеспечения. Системы обработки данных имеют тенденцию ассоциироваться с определёнными конфигурационными решениями, т. е. способами, которыми приложения строят своё взаимодействие с терминалами, рабочими станциями и системными сервисами. Выделяются следующие категории конфигурационных сред: • среды непрограммируемых терминалов (NPT); • среды локальных сетей (LAN); • среды глобальных сетей (WAN); • одно- или многоуровневые серверные среды; • другие взаимосвязанные системы, в том числе среды со связью "точка — точка". Следует обратить внимание, что эти категории скорее представляют режимы работы приложений, чем определённые физические конфигурации оборудования. Одна и та же аппаратура может, например, функционировать как непрограммируемый терминал для одного приложения и предоставить среду локальной сети для другого приложения. Даже если организация обладает однородной средой, она вполне может столкнуться с гетерогенностью при объединении своей информационной системы с другими организациями, при выходе во "внешний мир". Гетерогенность может принимать различные формы: большое разнообразие техники, используемой на рабочих местах пользователей: рабочие станции, терминалы, персональные системы, мобильные пользователи и др.; • различные аппаратные архитектуры и платформы; • множество операционных систем; • множество коммуникационных сетей и протоколов; • многочисленные версии одного и того же аппаратного и программного обеспечения; • множество поколений одних и тех же приложении. Причины гетерогенности в среде информационных технологий многообразны. Они могут быть следующими: • Экономические, финансовые или иные условия деятельности организации диктуют необходимость сохранения инвестиций, уже вложенных в свою информационную систему. • Со снижением стоимости вычислительных систем появилась возможность приоб-

ретать новые элементы системы обработки данных без учёта существующих решений. • Слияние или поглощение одной организацией другой может привести к появлению в одной организации разнородной среды. • С изменением нужд организации и развитием новых технологий оказывается, что ни одна фирма-производитель не может удовлетворить всех потребностей организации при сохранении приемлемой стоимости системы. • В ряде случаев фирмы-производители патентуют, намеренно не разглашают или сильно ограничивают информацию о деталях устройства своего программного и аппаратного обеспечения. Это делает практически однозначным выбор той или иной вычислительной платформы. • Не существует стандартов, препятствующих объединению разнородных сред в одно целое или делающих невозможным адаптацию систем различных фирмпроизводителей для совместной работы друг с другом. Несовместимость Внутри каждой из разнородных сред технологические решения создавались только основываясь на архитектуре, структуре и функциональных возможностях этих сред. Перемещение прикладных программ между различными системами и адаптация пользователей к работе на различных системах могут быть затруднены, так как при объединении разнородных сред в создающейся сложной среде модули будут использовать различные аппаратные, программные и коммуникационные компоненты. Большое количество систем Учитывая общую тенденцию непрерывного снижения стоимости, улучшения функциональности и упрощения использования аппаратного обеспечения, количество используемых вычислительных систем постоянно возрастает. Иногда это вызывает многократное увеличение количества вычислительных систем в организации. Более того, количество вычислительных систем, участвующих в обработке данных при решении той или иной задачи может быть вообще не определено или заранее неизвестно, например, если информационная система построена на основе глобальной сети. Недостаток глобальной инфраструктуры Превращение совокупности разнородных сред во взаимосвязанную систему требует создания согласованной, управляемой инфраструктуры для обеспечения эффективной работы всей сложной среды в целом. Перечисленные качества сложных сред ослабляют полезность, эффективность, работоспособность системы обработки данных. Это может выразиться в следующих проблемах: • трудности разделения информации между различными системами вследствие различных форматов представления и методов организации данных, различных операционных систем и прикладного программного обеспечения, различных протоколов, не позволяющих осуществить соединение между системами; • трудности разделения ресурсов между различными системами вследствие несовместимости методов подключения устройств, коммуникационных интерфейсов и т.п.; • неспособности перенести с системы на систему приложения, созданные пользователем, и адаптироваться самому пользователю к работе в различных средах; • неспособности управлять системой из одной точки, расширять (масштабировать) систему, обнаруживать источники сбоев и неполадок и устранять их; • высокой стоимости обучения персонала вследствие использования в различных системах разных методов управления системой, пользовательских интерфейсов, процедур инсталляции программного обеспечения и других функций; • трудности в обеспечении общего комплекса мер по защите информации, так как системы обеспечивают различные уровни защищённости и непохожие механизмы для отслеживания целостности системы. Решение практически всех перечисленных проблем может быть сведено к выполнению двух требований:

•

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

1.2. Концепция открытых систем Термин "открытые системы" подразумевает сложный, постоянно растущий набор требований к информационным системам. Эти требования тесно связаны с тенденциями построения распределённых вычислительных сред на гетерогенной основе, что будет подробно рассмотрено далее. Две основные группы требований к открытым системам состоят в следующем: 1) идеальное решение для пользователей открытой системы — технология, которая позволяет любому приложению осуществлять доступ и разделять свои собственные локальные данные и любой тип данных, размещённый на удалённой гетерогенной системе, поддерживая одинаковый уровень производительности; 2) пользователи должны иметь возможность осуществлять свободный выбор наилучших для них решений для всех компонент открытой системы, которые наиболее полно отвечают их требованиям, без ограничения в существующих аппаратном, программном обеспечении и архитектурах систем. В идеале открытые системы должны предоставлять открытые решения задач в любой области обработки данных, т.е. обеспечивать возможность потребителю выбирать из множества источников любые доступные средства, наиболее полно удовлетворяющие его запросы и позволяющие ему максимально эффективно решать стоящие перед ним задачи. Так, операционные системы должны обеспечивать одни и те же интерфейсы к системным сервисам независимо от класса систем (от мэйнфреймов до персональных компьютеров) и независимо от архитектуры системы (от единичного процессора CISC-архитектуры до многопроцессорных систем из RISС-процессоров). Приложения должны быть способны прозрачно осуществлять доступ к данным, вычислительным мощностям, утилитам пользователя и другим ресурсам, например, принтерам, дисковым массивам и др. Обслуживающий персонал и пользователи не должны замечать отличий в интерфейсах, наборе сервисов и инструментах на платформах различных фирм-производителей, или эти отличия должны быть минимальными. Таким образом, при выполнении перечисленных идеальных условий организации смогут легко конструировать свою систему обработки данных (и на основе неё - свою информационную систему) из стандартных компонентов. Однако, такая задача трудно реализуема на практике. Технологии и стандарты могут перекрывать друг друга по выполняемым функциям. Некоторые стандарты и рекомендации могут быть очень сложными для их полной практической реализации. Новые технологии постоянно совершенствуются, и трудно предсказать, какая из них окажется удачной. Наконец, существующие системы также должны быть приспособлены к архитектуре открытых системы. Хотя открытые системы не являются решением всех проблем, эта идея хорошо разработана во многих областях, например, в телекоммуникациях. Она может предоставить основу для использования гетерогенности и других специфических особенностей вычислительных систем для получения максимального эффекта от построенной на их основе информационной системы. На сегодняшний день открытые системы являются единственным общепризнанным способом решения обозначенных проблем. Вместе с тем, концепция открытых систем является динамичной, пока ещё не вполне законченной, но быстро развивающейся и открытой для всех заинтересованных сторон областью информационных технологий.

Существует несколько определений понятия "открытая система" (или "среда открытых систем"). Наиболее известными и широко принятыми являются следующие четыре определения, данные Международным институтом инженеров по электронике и электротехнике (IEEE), Всемирной независимой организацией по открытым системам Х/Ореn, международным консорциумом OSF и Международным телекоммуникационным союзом ITU. По определению IEEE, средой открытых систем называется "исчерпывающий и консистентный [т.е. последовательный, внутренне согласованный и взаимосвязанный] набор международных стандартов по информационным технологиям и функциональных профилей стандартов, который специфицирует интерфейсы, сервисы и поддерживаемые форматы для достижения способности к взаимодействию и переносимости приложений, данных и пользователей". По определению Х/Ореn, открытые системы — это "среда программного обеспечения, сконструированная и реализованная в соответствии со стандартами, которые являются независимыми от поставщиков и общедоступными". По определению OSF, открытой системой называется "среда, использующая стандартный набор интерфейсов для программирования, коммуникаций, управления системой и пользовательских интерфейсов, использующих способность к взаимодействию, переносимость и сохранение инвестиций". В определении ITU и ISO "среда взаимодействия открытых систем" - это "абстрактное представление набора концепций, элементов, функций, сервисов, протоколов и т.д., определённых в эталонной модели OSI, и производных от них специфических стандартов, которые, будучи применены, позволяют осуществлять связь между открытыми системами". Несмотря на отсутствие единства в определениях среди различных организаций можно, однако, выделить те свойства открытых систем, которые отражены во всех определениях и, следовательно, являются бесспорными: • понятие "открытая система" относится преимущественно к программному обеспечению; • основная цель открытых систем состоит в обеспечении: а) способности к взаимодействию между гетерогенными системами; б) переносимости приложений, пользователей и данных между гетерогенными системами; • понятие «открытая система» может применяться и по отношению к отдельно взятой вычислительной системе, и к системе обработке данных в целом, и к построенной на её основе информационной системе, если они согласуются с концепцией открытости; • стандарты играют ключевую роль в открытых системах. Последнее свойство является особенно важным, так как на него прямо указывают все определения. Информационная система не может рассматриваться как открытая до тех пор, пока она не реализует функции, которые согласуются со стандартами, имеющими отношение к соответствующей области. Учитывая центральное место стандартов в концепции открытых систем, важно рассмотреть более подробно, что представляют собой стандарты, как и кем они создаются.

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

рассмотрения объекта стандартизации: терминологию, нормативные модели, формальное описание процедур обращения с объектом, спецификации, структуру объекта и т.п. Стандартизация позволяет избежать несогласованного, субъективного, неполного или одностороннего взгляда на объект стандартизации. Стандарты позволяют замаскировать неоднородность объектов стандартизации, предоставляя такую модель, которая помогает избежать различий в представлении, описании и реализации этого объекта. В отсутствии такой модели каждый разработчик был бы вынужден создавать свою собственную. Таким образом, стандарт уменьшает потенциальную разнородность объекта стандартизации. Как будет видно далее, многие стандарты являются именно абстрактными моделями различных аспектов обработки данных, например, общеизвестная модель ISO OSI. Стандарты специфицируют общую форму, к которой должны "сходиться" разнородные системы для того, чтобы выполнять совместную работу или обеспечивать основу для переносимости между ними. Если две системы поддерживают стандарт в дополнение к их собственным формам, тогда любая пара систем сможет быть совместимой друг с другом. Таким образом, стандарт облегчает управление гетерогенностью. Разработчик информационных технологий заинтересован в том, чтобы его продукты и системы соответствовали стандартам. Это путь к широкому признанию его продукции и росту числа потребителей. Соответствия стандартам можно достичь двумя способами: либо добиваться принятия своей технологии в качестве стандарта, либо как можно быстрее интегрировать в свои продукты технологию, претендующую быть стандартом. Вследствие того, что любая организация по стандартизации проводит широкое и всестороннее обсуждение документов, прежде чем они становятся стандартами, как правило, стандартом становится объективно наилучшее по большинству критериев решение (спецификация, модель и т.д.). Другой важный аспект стандартизации — в том, что любые изменения в стандартах или новые стандарты почти всегда (но не всегда) принимают во внимание созданную ранее базу стандартов в этой области. Организации по стандартизации не заинтересованы в отчуждении уже существующего "сообщества" пользователей стандартизованной технологии, а в ряде случаев они прямо участвуют в выработке стандартов. Наконец, важно провести различие между стандартами и реализующими их технологиями. Стандарты описывает абстрактные сущности, определённые только на бумаге: модели, спецификации, описания интерфейсов и протоколов, схемы, форматы данных и т.п. Описанные в нём объекты с определённой функциональностью должны быть затем реализованы, используя определённую технологию: программно или аппаратно. Разрабатываемые и выпускаемые тем или иным производителем в соответствии со стандартами продукт или система, как правило, имеют значительно больше функций, чем те, которые описаны в стандарте. Стандарт обеспечивает лишь наименьший "общий знаменатель" для продуктов определённого типа. Различают два типа стандартов: стандарты де-юре и стандарты де-факто. Стандарты де-юре утверждены организациями по стандартизации и имеют юридически оформленный статус официальных документов. Стандарты де-факто могут являться результатом признания большим количеством производителей и потребителей удачного научного или технологического решения или быстро набирающей силу, обладающей большими потенциальными возможностями в будущем, технологией. Они не имеют никакого официального статуса и могут быть описаны в произвольной форме. Станет или нет какая-либо технология стандартом де-факто — определяет только рынок. Стандарты де-факто могут быть в конце концов приняты как стандарты де-юре, и наоборот (по крайней мере теоретически), стандарты де-юре должны в итоге становиться стандартами де-факто, будучи приняты рынком. Рассмотрим более подробно эти две категории стандартов. Стандарты де-юре характеризуются следующими особенностями: • Формальные процедуры тщательного согласования и утверждения этих стандартов приводят к тому, что их разработка занимает весьма длительное время, как правило, много лет. Стандарты не успевают за быстрым развитием информационных технологий, и нередко принимаются уже по факту их широкого

распространения. • Стандарты, как правило, являются сложными и могут включать несколько различных подходов к решению одной задачи, поэтому они предоставляют производителям и потребителям широкий спектр возможностей реализации (в том числе необязательных). • Продукты появляются позже, чем стандарты (за исключением случаев, когда утверждён стандарт де-факто). • Стандарты открыты для всех разработчиков и производителей на равных условиях. • Организации по стандартизации обеспечивают процесс совершенствования стандартов, который позволяет всем заинтересованным сторонам подавать свои предложения для рассмотрения. • Эти стандарты определяют долговременные направления развития, независимые от конкретных продуктов и решений. Стандарты де-факто отмечены следующими особенностями: • Реализации этих стандартов доступны уже сейчас, возможно, даже от многих поставщиков: нет необходимости ждать их окончательного согласования и утверждения. • Существует опыт применения этих стандартов, хорошо известны их сильные и слабые стороны. • Стандарты де-факто могут использовать произвольный, удобный для этих стандартов, набор существующих технологических решений, не обязательно состоящий из стандартов де-юре. • Истинная "открытость" этих стандартов всегда может быть подвергнута сомнению. Для многих стандартов де-факто технология, реализующая стандарт, либо предшествует, либо становится доступной одновременно со спецификациями. Станет ли спецификация общепризнанной — зависит либо от успеха исходной технологии, либо от степени согласия других производителей со спецификацией. Часто можно видеть несколько конкурирующих технологий и (или) спецификаций одновременно. В этом случае бывает трудно предсказать, какая из них завоюет успех на рынке. Тогда, чтобы добиваться стандартизации своих продуктов, производители могут объединяться в различный организации: консорциумы, альянсы, фонды и т.п. Из-за множества стандартов и большого количества необязательных или альтернативных возможностей реализации, предусмотренных во многих стандартах де-юре, некоторые заинтересованные организации разрабатывают так называемые профили стандартов. В профилях точно отмечается, какие стандарты и какой выбор возможностей из этих стандартов они желают реализовать в информационных системах. Профили обычно специфицируют, где это возможно, подмножества стандартов де-юре, а оставшиеся "свободные места", для которых не существует стандартов де-юре, заполняют стандартами де-факто. Профили, как и стандарты, играют важную роль в открытых системах. Число стандартов и областей, которые они покрывают, очень велико и продолжает расти. Всё труднее становится конструировать открытые решения, которые могут свободно взаимодействовать друг с другом или могут быть получены из других открытых решений. Это противоречит самой концепции открытых систем. Профили предназначены для снижения потенциальной возможности несовместимого использования продуктов, соответствующих стандартам. Кроме того, они помогают идентифицировать "пробелы", которые существуют в стандартизации информационных технологий. Профили могут создаваться самими организациями по стандартизации, организациями пользователей, правительственными органами. Так, правительственные профили возникли в результате возрастания потребностей упростить и облегчить процесс применения информационных технологий в правительственных структурах путём определения общего набора требований и исключения независимого изучения пользователями огромного множества сложных, объёмных стандартов. Правительственные профили могут комбинировать международные и национальные стандарты той страны, для которой они создаются. Тем самым обеспечивается стабильность деятельности прави-

тельственных учреждений. Цель этих профилей — добиться взаимодействия средств различных поставщиков на рабочих местах правительства. Профили явились началом развития более сложных форм структурной логической организации стандартов: архитектур, нормативных моделей и др. Поэтому, учитывая нынешнее развитие стандартизации, конкретные профили целесообразно рассматривать в рамках более высокоуровневых логических моделей (см. п. 3.2.1, 3.2.2). Различается три типа организаций, разрабатывающих стандарты: • Национальные и международные организации по стандартизации. К этой категории относятся, например, ISO, IEC, ITU, IEEE (международные), Госстандарт РФ, ANSI, NIST (США) и др. Эти организации являются единственным источником стандартов де-юре, тогда как остальные два типа организаций производят только стандарты де-факто. • Консорциумы и альянсы фирм-производителей. К этой категории относятся OSF, Unix International, Power-Open и др. Они способствуют созданию стандартов де-факто, распространяя спецификации и технологии на множество производителей. Однако, поддержка технологий таким образом может быть недостаточной, если она не соответствует требованиям организаций пользователей. • Организации пользователей. Они определяют стандарты де-факто либо посредством спецификации профилей, либо выявляя их на рынке информационных технологий. Первый способ используют большие пользователи, такие как правительственные организации или ассоциации пользователей. Второй способ предполагает исследование преимуществ и недостатков каждого продукта, его распространённости у пользователей. Принятие или непринятие рынком той или иной технологии (продукта, решения) есть окончательный показатель стандарта дефакто. Если они не соответствуют тому, что требует пользователь, он не будет покупать их. Охарактеризуем некоторые из наиболее важных и влиятельных организаций, вовлечённых в процесс разработки стандартов по информационным технологиям. • Международная организация по стандартизации (ISO — International Organization for Standardization). ISO — международная неправительственная организация. Как записано в её Уставе, она "осуществляет разработку международных стандартов и координирует деятельность в области стандартизации с целью содействия взаимному сотрудничеству в важных областях человеческой деятельности: интеллектуальной, научной, технологической и экономической". Сейчас в состав ISO входят около 130 государств. Каждое государство участвует в работе ISO через свой национальный орган стандартизации. Государства могут быть членами, членами-корреспондентами или членами-подписчиками ISO. Каждое государство-член ISO возглавляет один или несколько технических комитетов или подкомитетов. Официальными языками ISO являются английский, русский и французский. СССР был одним из учредителей ISO в 1946 г. Сфера ответственности ISO за разработку стандартов охватывает все области техники, за исключением электроники и электротехники (это — прерогатива IEC). Структурно ISO состоит из Технических комитетов (ТС), которые делятся на Подкомитеты (SC). Для обеспечения работы по подготовке стандартов внутри подкомитетов образуются Рабочие группы (WG). Группы, работающие над решением конкретной задачи, называются TF (Task Force). Каждый разрабатываемый стандарт проходит последовательно несколько стадий: • NWI — New Work Item; • WD — Working Draft; • CD — Committee Draft; • DIS — Draft International Standard; • IS — International Standard. Согласованный проект принимается в качестве стандарта, если за него проголосовало не менее 75% государствчленов ISO.

• Международная электротехническая комиссия (IEC — International Electrotechnical Commission) — специализированная международная организация, которая разрабатывает стандарты, связанные с электроникой, электротехникой и информационными технологиями. IEC — одна из первых международных организаций, начавших процесс разработки международных стандартов. Образована в 1906 г. В настоящий момент она дополняет деятельность ISO в области информационных технологий. IEC совместно с ISO сформировала Объединённый технический комитет JTC1 (Joint Technical Committee) для координации разработки стандартов по информационным технологиям.

• Международный телекоммуникационный союз (ITU — International Telecommunications Union). ITU — одна из первых международных организаций. Союз был основан в 1865 г., до 1947 г. носил название Телеграфного союза. Сейчас входит в систему органов ООН. Объединяет около 160 стран. В структуру ITU входят Международный консультативный комитет по радиосвязи (ITU-R, до 1993 г. — CCIR) и Международный консультативный комитет по телефонии и телеграфии (ITU-T, до 1993 г. — CCITT). Название последнего было

заменено на ITU/TSS (Telecommunications Standard Sector), но более известным остаётся предыдущее. Стандарты ITU официально называются "рекомендациями". Они принимаются на сессиях ITU, которые проходят один раз в четыре года. Разработка стандартов, таким образом, занимает весьма длительное время.

ITU занимается стандартизацией открытых телекоммуникационных сервисов. ITU-T выпускает 25 серий рекомендаций (обозначаемых буквами латинского алфавита от А до Z), каждая из которых насчитывает до нескольких десятков или сотен рекомендаций. Наиболее известны серии, посвящённые стандартизации взаимодействия открытых систем, сетям ISDN и др. Многие рекомендации ITU были приняты в качестве стандартов ISO. • Международный институт инженеров по электронике и электротехнике (IEEE — The Institute of Electrical and Electronics Engineers). IEEE был основан в 1884 г. В настоящее время активно участвует в разработке стандартов для компьютерной промышленности. IEEE работает в тесном сотрудничестве с другими международными организациями, в частности ISO, так что между стандартами IEEE и эквивалентными стандартами ISO практически не вносится никаких изменений.

IEEE разрабатывает три типа спецификаций: • стандарты — спецификации с предписательными требованиями; • рекомендованные практики — спецификации действий, процедур и практик, рекомендуемые IEEE; • руководства — описывают спектр альтернативных возможностей без рекомендации определённого подхода. Два наиболее известных стандарта IEEE: стандарты серии 802 по локальным вычислительным сетям и стандарты POSIX. • Internet Architecture Board (IAB) — неофициальная организация, создающая систему стандартов для среды Internet. IAB основана в 1992 г. Состоит из двух подразделений: IETF (Internet Engineering Task Force), которая ответственна за разработку краткосрочных инженерных документов, и IRTF (Internet Research Task Force), которая занимается долгосрочными исследованиями. IAB ведёт работу в девяти функциональных областях: приложения, сервисы Internet, управление сетями, операционные требования, интеграция с OSI, маршрутизация, безопасность, транспортные сервисы, сервисы пользователя.

Наиболее известными документами этой организации является серия так называемых RFC (Request for Comments). RFC различны по своему статусу: некоторые из них являются утверждёнными стандартами для среды Internet, другие рекомендованы к использованию, но не являются обязательными, третьи вообще служат справочными материалами. Значительная часть из них является стандартами де-факто. RFC создавались с целью определения минимально необходимого набора спецификаций для обеспечения нормальной работы глобальной информационной среды. Сегодня этот "минимум" включает уже более двух с половиной тысяч стандартов. • The Open Group (TOG) — образована в 1993 г. в результате слияния консорциума OSF и организации Х/Ореn как международная некоммерческая организация с целью содействия развитию технологий открытых систем и открытых распределённых сред. The Open Group занимает особое положение: можно утверждать, что она находится между первой (официальные органы) и второй (неофициальные) категориями организаций. Она одобряет стандарты де-юре, согласует и разрабатывает стандарты де-факто, и её документы имеют большое влияние на промышленность. Однако, в отличие от промышленных групп и консорциумов, она не внедряет отдельные продукты, технологии или решения фирм-производителей. Многие свои проекты TOG ведёт совместно с официальными организациями по стандартизации, прежде всего ISO. • Open Software Foundation (OSF) — некоммерческий международный консорциум, в 1993 г. вошедший в состав The Open Group. Это научно-производственная организация, цель которой — создание спецификаций для программного обеспечения открытых систем с целью поддержки различных производителей. Широко известны разработки OSF, которые объединяют лучшие достижения промышленности: набор спецификаций и исходных кодов для UNIXподобных операционных систем OSF/1, графический интерфейс OSF/Motif, набор сервисов для поддержки распределённых приложений OSF/DCE, набор сервисов для управления системами OSF/DME, модель и спецификация интерфейсов для разработки переносимых приложений в среде открытых систем OSF AES. • Х/Ореn — всемирная некоммерческая независимая организация по открытым систе-

мам, основанная в 1984 г. и вошедшая в состав The Open Group в 1993г. Главными разработками этой организации являются спецификации САЕ (Common Application Environment) — модель и стандартный набор интерфейсов программирования, опубликованные в документах XPG. САЕ основана преимущественно на стандартах де-юре (в т.ч. POSIX) и включает стандарты де-факто и промышленные стандарты производителей. • Unix International (UI). В настоящее время эта организация ликвидирована, но во многом благодаря ей понятие "открытые системы" ассоциируется с операционными системами UNIX и протоколами TCP/IP. Кроме перечисленных, большое влияние на технологии открытых систем оказывают также следующие организации: • OMG — Object Management Group; • NMF — Network Management Forum; • W3C— World Wide Web Consortium; и другие. Ссылки и замечания к гл. 1: п. 1.1: В настоящее время многие понятия, связанные с распределённой обработкой данных, не получили ещё однозначного, единообразного толкования. Определения одних и тех же терминов различаются даже в международных стандартах. Определения системы обработки данных, (компьютерной) информационной системы, вычислительной системы сформулированы автором на основе обобщения документов [11,14,17,22,24], определение среды — на основе [11,17]. Эти определения не претендуют на полноту и научную строгость: они введены только в контексте данной работы. Так, информационная система может пониматься более широко: например, в [Расторгуев С.П. Информационная война как целенаправленное информационное воздействие информационных систем. //Информационное общество. — 1997. — №1. — С. 64] под информационной системой понимается "система, осуществляющая получение входных данных; обработку этих данных и/или изменение собственного внутреннего состояния (внутренних связей/отношений); выдачу результата либо изменение своего внешнего состояния (внешних связей/отношений)". Определение информационного обеспечения деятельности предприятия заимствовано из [В.А. Герасименко, А.А. Малюк. Основы защиты информации. —М.,1997. — с. 14,16]. В ряде случаев адекватный перевод англоязычных терминов и определений на русский язык затруднителен. Как правило, если перевод является спорным или неочевидным, здесь и далее в данной работе рядом приводится их оригинальное написание на английском языке. Хорошим источником стандартизованных ITU-T (и частично ISO) определений является база данных по определениям и аббревиатурам в области телекоммуникаций SANCHO (ITU-T Sector Abbreviations and definitions for a telecommunication tHesaurus Oriented database), доступ к которой возможен в сети Internet no адресу: http: //www7 . itu. int/sancho. Этот и следующий параграфы придерживаются в основном плана изложения, принятого в учебном руководстве [20, ch.2], и частично используют материал его пп. 2.3 — 2.9, 2.27 — 2.28. Хорошей, но несколько устаревшей, обзорной работой по технологиям распределённой обработки данных является также [22]: характеристика путей эволюции систем обработки данных, конфигурационных сред составлена по материалам этой книги. п. 1.2: Определения открытых систем и среды открытых систем приводятся по следующим источникам: IEEE — [20,21], OSF uX/Open — [20], определение ISO сформулировано в стандарте [12] и эквивалентном ему стандарте ITU-T X.200. В глоссарии к модели TOGAF (версия 5, янв. 2000г.) [24] организации The Open Group определение открытых систем (рекомендованное вместо определений OSF и Х/Ореn) сформулировано следующим образом (приводится исходный текст на английском языке): "Open system — a system that implements sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered applications software: (a) to be ported with minimal changes across a wide range of systems, (b) to intemperate with other applications on local and remote systems, and (c) to interact with users in a style that facilitates user portability." "Open systems environment (OSE) — the comprehensive set of interfaces, services, and supporting formats, plus user aspects for interoperability or for portability of applications, data, or people, as specified by information technology standards and profiles. " n.1.3: Информация о международных и национальных органах стандартизации, порядке их работы и целях деятельности, разрабатываемых стандартах получена, в основном, с соответствующих Web-страниц сети Internet: ISO (International Organization for Standardization) — http://www.iso.ch/, дополнительно использовалось [21, App. А.З], The Open Group — http: //www. opengroup. org, IEEE— http://www.

ieee.org/,

ITU— http://www.itu.ch/, IAB — http: / /www. ietf. org, OMG— http://www.omg.org/, Госстандарт РФ— http://www.gost.ru/, http://www.interstandard.gost.ru/ (каталог российских и международных стандартов), NIST (Национальный институт стандартов и технологий США) — http: //www. nist. gov . В России на начало 2000 г. насчитывается 161 государственный стандарт по классу "Информационная технология". Несмотря на это количество и состав государственных стандартов РФ по информационным технологиям всё ещё значительно уступает международным стандартам ISO/IEC. Перечни и краткие аннотации стандартов могут быть также получены по следующим адресам: стандарты ISO и ISO/IEC — http://www.iso.ch/cate/cat.html, рекомендации ITU — http://www.itu.int/publications/index.html.

Глава 2. ПЕРЕНОСИМОСТЬ И СПОСОБНОСТЬ К ВЗАИМОДЕЙСТВИЮ 2.1. Основные аспекты совместимости систем Как было отмечено в главе 1, основными требованиями к совместимости вычислительных систем в сложной среде является переносимость и способность к взаимодействию. Рассмотрим подробнее смысл этих требований, различие между ними, методы их реализации в среде открытых систем. Для этой цели нам потребуется функциональная модель информационной системы, которая в дальнейшем будет использоваться для размещения в ней и более подробного рассмотрения стандартов и технологий открытых систем. Переносимость означает возможность перемещать между вычислительными системами приложения, данные и пользователей. Концепция переносимости применяется к разделённым, не связанным между собой системам, т.е. когда мы хотим взять один из этих объектов (приложение, данные, пользователя) из одной системы в другую, мы говорим о переносимости. Переносимость имеет три составляющие. Переносимость приложений означает возможность исполнения прикладных программ пользователя на платформе, отличной от той, для которой она была создана изначально. Само понятие переносимости не подразумевает никакого конкретного способа достижения этого качества открытых систем, хотя, как будет видно далее, переносимость приложений, например, может быть достигнута либо на уровне исходных текстов приложений на языках программирования, либо на уровне исполняемых кодов. В первом случае исходный текст перекомпилируется на каждой новой платформе, во втором — программа компилируется один раз и может исполняться на любой платформе из обозначенного множества. Но ни в том, ни в другом случае это никак не влияет на пользователя, так как он всегда приобретает уже готовый объектный код. Переносимость данных означает возможность доступа приложений к одним и тем же данным на различных платформах (считая их не связанными между собой!), т.е. приложения должны иметь единые механизмы манипулирования данными: создание, удаление, поиск, копирование и др. Наконец, переносимость пользователей означает, что пользователям и обслуживающему персоналу не потребуются дополнительные затраты на обучение, привыкание и накопление опыта работы на различных вычислительных системах, входящих в открытую среду. Они всюду будут работать с системой через единый интерфейс, обладать одинаковым набором сервисов, иметь равные возможности управления системой, равные права доступа к ресурсам и т.д. Способность к взаимодействию означает способность разнородных вычислительных систем выполнять некоторую работу вместе. Необходимым условием совместной работы двух или более систем является их взаимосвязанность. Они должны иметь физическое соединение между собой, которое позволит обмениваться данными. Но простого соединения вычислительных систем в сеть недостаточно для обеспечения возможности обмена данными. Наличие различных типов сетей: множества технологий передачи данных, множества производителей, множества коммуникационных протоколов — делает необходимым решение следующей задачи. Любая вычислительная система должна быть доступна из любой точки в пределах всей сложной сети. Когда мы хотим иметь возможность использовать ресурсы другой системы с имеющейся у нас системы, мы говорим о способности к взаимодействию. Однако, сама по себе возможность обмена данными через вычислительную сеть ещё не обеспечивает способности систем к взаимодействию. Им необходимо достичь общего понимания работы, которую они выполняют, а именно, все системы должны единообразно воспринимать порядок и значение сообщений, которыми они обмениваются, а также ту работу, которую каждая из систем должна выполнять индивидуально в ответ на получаемые сообщения. В общем случае эта задача решается при помощи коммуникационного интерфейса (см. п. 2.3). Итак, способность к взаимодействию позволяет вычислительным системам совместно выполнять некоторую работу. В зависимости от характера работы, это качество может быть представлено в системах в различной степени: от способности простой передачи файлов до способности их работать как полностью распределённая система с прозрачным хранением и обработкой данных. Переносимость и способность к взаимодействию не являются взаимно исключающими понятиями. Открытые системы предоставляют пользователям обе эти возможности, хотя не все

пользователи и не всегда могут ощущать их одновременно. Заметим, что, например, определение IEEE среды открытых систем можно расчленить на две составляющие в соответствии с понятиями совместимости и способности к взаимодействию. С одной стороны, открытая система подразумевает "исчерпывающий и консистентный набор международных стандартов по информационным технологиям .... который специфицирует интерфейсы, сервисы и поддерживаемые форматы для достижения ... переносимости приложений, данных и пользователей", а с другой стороны — "исчерпывающий и консистентный набор международных стандартов ... , который специфицирует интерфейсы, сервисы и поддерживаемые форматы для достижения способности к взаимодействию ...". В настоящее время существует очень большое количество стандартов в области открытых систем. Они определяют различные элементы технологии открытых систем: эталонные модели, сервисы, интерфейсы, форматы, протоколы, руководства и рекомендованные методики. Эти стандарты могут различаться по сложности, по широте охватываемых проблем и относиться к любому аспекту информационных технологий. Чтобы распознать и позиционировать различные стандарты, связанные с переносимостью и способностью к взаимодействию, будем использовать простую модель информационной системы, показанную на рис. 1. За основу в ней берётся модель POSIX OSE, описанная в документе IEEE PI 003.0 "Guide to the POSIX Open Systems Environment", которая подвергается дальнейшей декомпозиции по методике, используемой в документах фирмы IBM. Выбор модели POSIX OSE объясняется тем, что она является наиболее простой и наиболее общей. Она взята за основу в большинстве других, более сложных моделей. Эта модель не является определяющей по отношению к рассматриваемым далее стандартам, она — лишь средство классификации стандартов. Методика фирмы IBM была выбрана вследствие того, что она представляется наиболее удобным, объективным и независимым от продуктов конкретных фирм методом описания информационных систем, не нуждающимся в то же время в привлечении сложных структур и понятий. Главное её преимущество заключается в том, что она позволяет легко классифицировать стандарты двумя способами: • во-первых, как интерфейсы программирования (форматы) или протоколы; • во-вторых, как относящиеся либо к переносимости, либо к способности к взаимодействию. Основными элементами модели являются блоки и интерфейсы между ними: 1. Прикладное программное обеспечение (AS — Application Software) — представляет программное обеспечение, специфичное для конкретных задач пользователей. 2. Платформа приложений (АР — Application Platform) — представляет все остальные элементы системы обработки данных, за исключением прикладного ПО: аппаратуру, операционную систему и другие компоненты и подсистемы системного ПО. Приложения запрашивают ресурсы от платформы посредством вызова сервисов через интерфейс — интерфейс прикладного программирования (API — Application Programming Interface). Ресурсы, находящиеся вне платформы, запрашивают сервисы через другой интерфейс — интерфейс внешней среды (EEI — External Environment Interface). Внутренняя структура АР в модели POSIX OSE намеренно не рассматривается вследствие того, что различные разработчики и производители могут иметь различный взгляд на "наполнение" платформы, а модель должна обеспечить единый, предельно общий взгляд. 3. Внешняя среда (ЕЕ — External Environment) — представляет все объекты вне системы, с которыми она взаимодействует каким-либо образом: людей, коммуникационные средства, сменные носители данных и средства ввода/вывода. Интерфейс между АР и ЕЕ включает в себя форматы данных, коммуникационные протоколы, человекомашинный интерфейс и др.

Рис. 1. Базовая модель информационной системы

Для удобства дальнейшего рассмотрения необходимо более подробно охарактеризовать все три основные составляющие модели. • Внешняя среда. Внешняя среда состоит из трёх типов объектов: пользователей, внешних объектов данных, коммуникационных средств (хотя разбиение внешней среды именно таким образом в некотором роде произвольно). Внешние объекты данных включают все устройства ввода/вывода и сменные носители данных: гибкие диски, дисковые массивы, принтеры, устройства ввода с перфокарт и т.п. Коммуникационные средства включают каналы связи, локальные, глобальные сети и соответствующее коммуникационное оборудование. АР осуществляет доступ к этим объектам через EEI. Этот интерфейс принимает форму протоколов, форматов и потоков данных и включает такие аспекты как формат данных, формат экрана, поведение объектов на экране, протоколы обмена данными и т.д. • Платформа приложений. АР включает аппаратное, системное программное обеспечение и различные программные подсистемы, например, такие как СУБД, менеджеры транзакций, графическую подсистему. Следовательно, структура типичной платформы обычно является сложной. Многие модели рассматривают внутреннюю структуру платформу (см. гл. 3). Здесь мы не будем пользоваться фиксированной внутренней структурой, так как среди документов различных организаций и фирм не существует единого мнения по этому вопросу. Для обсуждения того, как технологии и стандарты АР используются для удовлетворения требований приложений и внешней среды, удобно выделить в АР четыре класса сервисов (рис.2).

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

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

Указанные классы сервисов обеспечивают связь между сервисами АР и внешней средой, с которой АР взаимодействует. Три класса сервисов: сервисы человекомашинного взаимодействия, сервисы данных и сетевые сервисы —~ связаны с соответствующими классами объектов внешней среды. Четвёртый набор сервисов — внутренние сервисы платформы — позволяет прикладному ПО AS использовать эти сервисы, полагаясь только на ту платформу, на которой эти приложения исполняются. Следует заметить, что взаимосвязь между классами сервисов АР и классами объектов ЕЕ не является однозначной, поэтому на рис. 2 показана единая связь между АР и ЕЕ. Такое разбиение обеспечивает удобство классификации стандартов. Поскольку АР ответственна за целостность и консистентность сервисов, которые она обеспечивает, эти сервисы должны быть доступны и контролируемы через определённый интерфейс. Использование интерфейсов делает зависимые от реализации характеристики платформы прозрачными для прикладного ПО и внешних объектов. Каждый компонент будет иметь свой собственный набор интерфейсов прикладного программирования (API), через которые приложения могут воспользоваться его сервисами. Существование API в форме стандартов, поддерживаемых многими платформами, делает возможной переносимость приложений.

Рис. 4. Распределённая система

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

мени. • Прикладное ПО. В общем случае на платформе может исполняться одновременно множество приложений, и каждое приложение может пользоваться при своём исполнении множеством API для доступа к различным сервисам платформы. Перечисленные три элемента базовой модели достаточны для рассмотрения свойства переносимости. Для рассмотрения способности к взаимодействию и концепции распределённых систем модель необходимо расширить. Способность к взаимодействию подразумевает наличие двух или более вычислительных систем и коммуникационных средств между ними. Модель взаимодействующих систем показана на рис. 3. Приложения из одной системы могут запрашивать сервисы удалённой платформы, используя сетевые сервисы, доступные на своей собственной платформе. Например, они могут осуществлять доступ к внутренним или внешним ресурсам на удалённой платформе, взаимодействовать с удалённым приложением или общаться с пользователем удалённой системы. Необходимое условие для этого — на удалённой платформе должен поддерживаться тот же самый интерфейс сетевого сервиса, т.е. сетевые протоколы и форматы сообщений. Как уже отмечалось выше, для взаимодействия системы должны не только обмениваться данными, но и одинаково "понимать" выполняемую работу. Для этого необходимы дополнительные протоколы и форматы, зависящие от характера выполняемой работы. Заметим, что в данном случае приложение "осведомлено" о расположении партнёра (сервиса или другого приложения), так как, если он находится на удалённой системе, приложение пользуется сетевым сервисом своей АР. Способность к взаимодействию между системами достигается через коммуникационные средства внешней среды. Каким образом может быть обеспечена переносимость конкретных программных продуктов? Известны четыре подхода к решению этой проблемы: • спецификация открытых программных интерфейсов для неограниченного использования разработчиками ПО; • создание программных продуктов, которые могут работать на нескольких программных и аппаратных платформах; • применение стандартных интерфейсов в программных продуктах (SQL, OSF/DCE, POSIX 1003 и пр.) в дополнение к их собственным интерфейсам; • совмещение двух последних подходов. Перечисленные методы в основном применимы и для обеспечения способности к взаимодействию между программными модулями. Кроме того, способность к взаимодействию чаще всего подразумевает уровневую структуру программного обеспечения — тогда, кроме того, появляется выбор возможностей реализации этого свойства. Например, если требуется взаимодействие удалённого приложения с СУБД, возможны следующие альтернативы: взаимодействие на коммуникационном уровне (непосредственная передача данных приложением через низкоуровневый коммуникационный интерфейс), взаимодействие на уровне менеджера транзакций (последовательное выполнение транзакций) или взаимодействие на уровне СУБД (отработка запроса, написанного на языке манипулирования данными, например, SQL). Один из лучших известных подходов к многоуровневой организации ПО в открытых системах — стандартизованный набор интерфейсов для распределённых вычислений модели OSF DCE (см. п.3.4). Часто по многим причинам невозможно составить исходный текст приложения на языке программирования так, чтобы оно было полностью переносимо в исходных кодах. Действительно, приложение будет исполняться быстрее (иногда значительно), если его код оптимизирован для архитектуры конкретной платформы. Кроме того, нельзя исключить ситуации, что приложению требуется некоторый специфический сервис, для которого не существует стандарта, но который предоставляется некоторой платформой. В этих условиях приложения необходимо конструировать так, чтобы максимально локализовать платформно-зависимые участки кода и структурировать всё приложение таким образом, чтобы эти участки встречались в минимальном количестве модулей. Это обязательно должно быть отражено в документации разработчика. Только такой подход обеспечивает обозримость приложения и сравнительную простоту его адаптации к конкретной платформе.

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

венное представление качеств открытых систем: она позволяет множеству систем, разделённых в пространстве, сообща использовать ресурсы. Пусть теперь модули, которые реализуют определённый сервис внутри одной платформы, могут использовать сетевые сервисы для доступа к удалённой платформе, если это требуется для удовлетворения запроса сервиса от приложения. Наглядным примером такой ситуации может быть доступ к файлам в локальной сети. Если файла, запрашиваемого пользователем или приложением на рабочей станции ЛВС, не оказалось на локальном диске, запрос перенаправляется на файловый сервер. Если при взаимодействии используется специальный протокол файлового сервиса, пользователь (приложение) осуществляет доступ к файлу через тот же самый интерфейс, который используется для локально расположенных файлов. Таким образом локальная платформа скрывает тот факт, что некоторые файлы расположены на удалённой вычислительной системе, и обеспечивает пользователю прозрачность файловой системы. Расширение этого примера на все категории сервисов, предоставляемые АР приложениям, приводит к концепции распределённой вычислительной системы. Схематическая модель распределённой системы показана на рис. 4. В ранее обсуждавшемся случае взаимодействующих систем две платформы рассматриваются как разделённые объекты, соединённые коммуникационными связями. В случае распределённой вычислительной системы они уже рассматриваются как единая, унифицированная платформа. Это различие имеет значение только с точки зрения приложений. Технически система в обоих случаях может быть одинакова, а формирование распределённой вычислительной системы обеспечивается только системным программным обеспечением. Распределённая вычислительная система может существовать как в однородной, так и в разнородной (гетерогенной), сложной среде информационных технологий. Концепция открытых систем направлена на обеспечение совместимости вычислительных систем: переносимости и способности к взаимодействию — в гетерогенной среде. (Часто также говорят о среде открытых систем.) Расширение этой концепции, направленное на организацию распределённой вычислительной системы в гетерогенной среде, приводит к понятию распределённых вычислительных сред (или просто распределённых сред, или сред распределённых систем). Естественно потребовать, чтобы распределённая вычислительная среда обладала рядом дополнительных свойств помимо переносимости и способности к взаимодействию, которые обеспечивали бы формирование образа единой системы для любого пользователя и любого приложения (рис. 5). Среди таких свойств чаще всего отмечают: • доступность — означает, что пользователи видят распределённую систему как единое, связанное вычислительное средство с единой точкой входа, единственной процедурой входа в систему (logon), с ресурсами, доступными через согласованную и универсальную схему именования ресурсов, независимую от местоположения и метода доступа; • прозрачность — означает, что сервисы системы предоставляют хорошо определённые, простые, функциональные интерфейсы, независимые от деталей реализации; пользователи и их приложения не видят общей сложности и неоднородности распределённой системы; напротив, они видят её как продолжение, расширение своей собственной системы; • масштабируем ость — подразумевает, что система может приспосабливаться к выбору различных конфигураций аппаратного обеспечения от сравнительно простого и дешёвого до сложного с развитыми возможностями, надёжного и высокопроизводительного; система допускает развитие и расширение с ростом требований или расширением задач потребителя; • управляемость — включает степень приспособленности системы для планирования, координации её работы, оперативного управления, поддержки разнородного оборудования, конфигурирования, мониторинга системы, обработки ошибок и исключительных ситуаций и т.д.; в сложных системах включает также степень автоматизации управления, возможность самостоятельного выполнения системой некоторых функций управления, возможность управления системой из одной точки и пр.; • безопасность — включает комплекс вопросов, связанных с обеспечением конфиденциальности, целостности данных, аутентичности пользователей и данных, контроля доступа к ресурсам, аудита, администрирования всех этих функций и пр.;

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

Рис. 5. Формирование образа единой распределённой системы

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

2.2. Переносимость Как было установлено в п. 2.1, понятие переносимости обычно рассматривается в трёх аспектах: переносимость приложений, данных и пользователей. Приложения получают доступ к сервисам и ресурсам АР через API. Использование API гарантирует, что платформа может поддерживать единообразный и контролируемый доступ к сервисам для всех приложений, которые потребуют этого. АР также обеспечивает сервисы и для внешней среды (ЕЕ). И наоборот, если того требует запрос, платформа может осуществлять доступ к ресурсам ЕЕ через соответствующие интерфейсы. ЕЕ рассматривается как состоящая из трёх типов объектов: пользователей, внешних объектов данных и коммуникационных средств. Переносимость приложений реализуется посредством обеспечения сервисов и (или) их API на многих АР. Переносимость данных достигается путём поддержки платформой приложений форматов и протоколов обмена данными между системами. Наконец, переносимость пользователей обеспечивается АР за счёт сервисов, инструментов (например, средств администрирования, средств разработки приложений) и интерфейсов, общих на нескольких платформах. Для более детального рассмотрения стандартов и компонентов интерфейса между приложением и АР было бы естественным разбить API на фрагменты, соответствующие основным классам сервисов, предоставляемых АР: • API сервисов человекомашинного взаимодействия; • API сервисов данных; • API сетевых сервисов; • API внутренних сервисов платформы. Первые три из них естественным образом соответствуют трём классам объектов внеш-

ней среды. Последний — API внутренних сервисов платформы приложений — позволяет приложениям осуществлять доступ к сервисам, которые АР поддерживает, используя только свои собственные, внутренние ресурсы. Сразу оговоримся, что API сетевых сервисов не рассматриваются в данном разделе, так как к свойству переносимости они непосредственного отношения не имеют: в контексте переносимости системы считаются не связанными между собой. Заметим, что, как и связь между классами сервисов АР и классами объектов ЕЕ, так и взаимосвязь между классами API и классами объектов ЕЕ не является однозначной. Например, если приложение запрашивает файл, который, как оказывается, хранится на удалённой системе, сервисы данных, доступные через API сервисов данных, будут обеспечивать доступ к этому файлу прозрачно для приложения. Но этот сервис, в свою очередь, воспользуется сетевым сервисом, доступным через API сетевого сервиса, для передачи данных через коммуникационные средства. Итак, API делают возможным переносимость приложений за счёт стандартизации интерфейсов между AS и АР. Переносимость пользователей и данных достигается за счёт стандартизации форматов и протоколов, используемых между АР и ЕЕ (см. рис. 1,2). Для пользователей эти форматы и протоколы принимают вид, например, форматов экрана, поведения объектов на экране, стиля общения с пользователем и т.п. Для данных — это форматы данных, в которых они записываются на одной платформе, хранятся на носителе и считываются на другой платформе. Рассмотрим теперь подробнее с точки зрения переносимости приложений, пользователей и данных все классы сервисов АР и соответствующих им API (за исключением сетевого сервиса и API сетевого сервиса). Все виды сервисов удобно рассматривать по единому плану: • предоставляемые услуги и выполняемые функции; • API сервиса; • стандарты по данному виду сервиса. 1. Внутренние сервисы платформы предоставляются приложениям платформой, используя только свои собственные, внутренние ресурсы платформы. Эти сервисы, в отличие от других классов сервисов, никогда не предоставляются внешней среде. В данную категорию входят следующие два типа сервисов. • Системные сервисы — это те сервисы, которые обычно обеспечиваются ядром операционной системы и связанными с ней низкоуровневыми подсистемами, такими как драйверы устройств. В эту группу входят сервисы управления процессами и ресурсами, обработки ошибок и исключительных ситуаций, межпроцессного взаимодействия и др. Для обеспечения переносимости требуются стандарты на спецификации API тех сервисов, которые будет обеспечивать операционная система для приложений. API системных сервисов — это механизм, через который приложения запрашивают ресурсы платформы: память, файловую систему, устройства ввода/вывода. Все эти сервисы обычно обеспечиваются ядром операционной системы и низкоуровневыми драйверами логических устройств. В распределённой системе эти сервисы могут обеспечиваться для приложения как локальной, так и удалённой по отношению к приложению системой. Но приложения не должны знать расположение сервиса: является ли он локальным или удалённым. Приложение воспринимает распределённую систему как единую платформу. В группе системных сервисов можно выделить следующие сервисы: • сервисы управления процессами и нитями; • сервисы управления памятью; • межпроцессные коммуникации (interprocess communications - IPC); • сервисы управления событиями, ошибками и исключительными ситуациями; • сервисы управления временем; • сервисы логического именования ресурсов; • сервисы управления устройствами; • сервисы управления файловыми системами; • сервисы конфигурирования системы. Часть из этих сервисов обеспечивается операционной системой "автоматически", независимо от воли разработчика приложения и независимо от приложения. Это сервисы, обеспе-

чивающие базовую функциональность, целостность и устойчивость работы системы, например, предотвращение возможности перекрытия приложений в оперативной памяти. Они, в том числе, обеспечивают многопользовательские и многозадачные возможности операционной системы. Другая часть сервисов выполняется по вызову от приложений через API, например, открытие файла, чтение, запись данных в файл и др. Стандарты по API системных сервисов. Наиболее важным стандартом по системным сервисам для открытых систем является документ IEEE POSIX (Portable Operating System Interface for Computer Environment). Системные сервисы описаны в части 1003.1-1990 этого стандарта (утверждена в качестве международного стандарта ISO/IEC 9945-1:1990). Эта часть специфицирует вызовы к операционной системе со стороны приложений и требуемую функциональность при выполнении этих вызовов, номера ошибок, типы данных и пр. Стандарт в значительной степени основывается на реализациях UNIX System V и BSD операционных систем UNIX. Однако это не означает, что другие, не UNIX-подобные операционные системы не могут достичь совместимости с POSIX. Они могут обеспечивать POSIX-совместимые сервисы и API в дополнение к существующим в них собственным, как это сделано, например, в OS/400, OpenEdition/MVS, Open VMS. Х/Ореn разработала спецификацию для API системных сервисов, основываясь на стандарте POSIX, которая получила название XSH и является частью стандарта XPG4. • Сервисы языков программирования. Прикладные программы должны быть составлены на одном или нескольких языках программирования. Кроме того, требуется некоторый механизм, с помощью которого язык программирования мог бы запрашивать системные сервисы. Для обеспечения этих сервисов требуется спецификация самого языка программирования, API языкового сервиса и механизма вызовов, которые запрашивают системные сервисы. API сервисов языков программирования. Языки программирования — это средства, с помощью которых разработчик описывает требуемые функции приложений. Чтобы обеспечить переносимость приложений, языки программирования должны быть однородны во всех системах, т.е. должна существовать спецификация языка программирования. Спецификация может задаваться в различных формах: от описания компилятора до формальных методов. Поскольку на практике язык программирования всегда реализуется посредством трансляторов, задать API сервисов языков программирования можно путём создания стандартов на трансляторы. Существует большое количество языков программирования. Выбор конкретных языков для разработки приложений зависит от большого числа факторов. Однако для достижения переносимости желательно, независимо от языка, использовать всегда только стандартизованные подмножества языков и избегать таких функций языка, которые являются зависимыми от конкретной платформы. Стандарты по сервисом языков программирования. Основной международной организацией, занимающейся стандартизацией языков программирования, является ISO. Существуют стандарты или проекты стандартов на следующие языки программирования: Ada, APL, BASIC, С, C++, COBOL, FORTRAN, Modula-2, MUMPS, Pascal, PL/I. 2. Сервисы данных — сервисы, связанные преимущественно с доступом, манипуляцией и обменом данными. Для достижения переносимости приложения должны иметь: 1) единообразный метод доступа к механизмам управления данными; 2) способ управления отдельными транзакциями над этими данными. • Сервисы файловой системы обеспечивают базовые сервисы для хранения, доступа и манипулирования файлами, организованными в виде потока байтов или в виде записей. Стандарты на API файловых сервисов обычно являются составной частью стандартов на функциональность операционных систем (например, POSIX). • Сервисы баз данных. Приложения могут управлять своими собственными данными. Но часто для упрощения разработки приложений, для улучшения возможности разделения данных между ними и для создания возможности поддержки множественных, сложных типов данных приложения могут использовать базы данных (БД). БД обычно используются в совокупности с системами управления базами данных (СУБД). СУБД характеризуются применяемой в них моделью структуризации данных. Наиболее важными из них являются реляционная, иерархическая, объектно-ориентированная, сетевая, семантическая. СУБД должны обеспечивать

возможности для создания, удаления, доступа и манипулирования данными при условии сохранения целостности и безопасности. Обычно выделяют следующие категории сервисов данных: • сервисы доступа к данным; • сервисы управления данными; • сервисы обеспечения целостности данных; • сервисы манипулирования данными; • дополнительные сервисы (создания форм, отчётов, контроля доступа, словари и пр.). API, реализующий эти функции, должен обеспечивать возможность доступа к сервисам как со стороны прикладных программ, так и из внешней среды, включая возможность доступа и обмена данными с другими, удалёнными СУБД. Основными и доминирующими стандартами в отношении сервисов БД являются стандарты ISO 10032:1993 — Reference Model for Data Management (Нормативная модель управления данными) и ISO 9075, определяющий SQL (Structured Query Language) — непроцедурный язык манипулирования данными для реляционных СУБД. Расширенная версия SQL определена в спецификации X/Open XPG4. Существует много других версий языка SQL. Среди интерфейсов, позволяющих обеспечить доступ к СУБД из внешней среды (в частности, из других СУБД) выделяется четыре спецификации: • Remote Database Access (RDA) — стандарт ISO/IEC 9579, поддерживаемый X/Open; • Distributed Relational Database Architecture (DRDA) — разработка фирмы IBM; • Open Database Connectivity (ODBC) — разработка фирмы Microsoft, имеющая сильную поддержку в промышленности; • Integrated Database API — совместная разработка фирм Borland, Novell, WordPerfect. • Сервисы обработки транзакций позволяют вычислительным системам выполнять операции с данными, требующие высокой степени целостности. Транзакция — это логическая единица работы, которая должна быть либо выполнена целиком, либо не выполнена вообще. Она может включать в себя несколько или множество действий, которые рассматриваются как выполнение одной логической задачи. Основными и наиболее полными стандартами по обработке транзакций являются: • ISO 10026 — OSI Distributed Transaction Processing (OSI-TP). Этот стандарт определяет модель, сервисы и коммуникационные протоколы для распределённой среды обработки транзакций. Основными элементами в модели обработки транзакций являются прикладные программы, менеджеры ресурсов, к которым осуществляется доступ, и менеджер транзакций, обеспечивающий основные качества транзакций: неделимость, целостность, блокирование ресурсов, неизменяемость состояния ресурсов. • X/Open Transaction Processing Group (XTP). В него входят: нормативная модель обработки транзакций (X/Open DTP), ТХ — спецификация API между прикладными программами и менеджером транзакций, ХА — спецификация интерфейса между менеджером транзакций и менеджерами ресурсов (предоставляет менеджеру транзакций возможность структуризации работы менеджеров ресурсов внутри транзакции). • Сервисы печати предназначены для упрощения печати данных на различных типах носителей и просмотра их пользователем перед печатью. Эта группа включают следующие сервисы: • способность описывать требуемые выходные данные и параметры печати; • поддержка очередей и множества устройств печати; • способность специфицировать характеристики задания на печать; • управление заданиями; • управление очередями; • управление шрифтами; • контроль доступа к устройствам печати; • поддержка учётной информации и пр. API для сервисов печати должен включать поддержку указанных сервисов для приложений и ряда специальных сервисов для администрирования подсистемы печати: конфигурирование подсистемы, управление доступом к учётной информации и пр. Среди стандартов по сервисам печати следует выделить ISO 10175 — Document Printing

Application (DPA) и ISO 10180 — Standard Page Description Language (SDPL), основанный на языке PostScript, а также IEEE PI 003.7 — администрирование печати. • Сервисы обмена данными поддерживают способность перемещать данные между системами через внешнюю среду путём записи их на распознаваемый обеими системами носитель в формате, дающем возможность обеим системам одинаково интерпретировать данные. Различают два аспекта рассматриваемой проблемы: преобразование кодировки символов из одного машинного представления в другое и распознавание полученной информации приложениями. Наиболее значительными являются следующие стандарты по форматам обмена данными: • ISO 9735 — EDIFACT (Electronic Data Interchange for Administration, Commerce and Transportation) — набор стандартов, определяющих формат и структуру документов, используемых в делопроизводстве и электронном документообороте. • ISO 8613 — ODA/ODIF (Open Document Architecture / Open Document Interchange Format) — набор стандартов по структуризации и прозрачному для пользователей обмену сложными составными документами, включающими несколько типов информации: текст, рисунки, геометрическую графику. • ISO 8879 — SGML (Standard Generalized Markup Language) — язык представления структуры, содержания и формата документа. 3. Сервисы человекомашинного взаимодействия — важная группа сервисов, обеспечивающих возможность общения человека с компьютером и форму организации работы пользователя. • Сервисы командного интерфейса могут принимать различные формы: от простой интерпретации введённых пользователем команд до развитого командного языка, который могут использовать прикладные программы. Эти сервисы требуют обеспечить API для приложений и интерфейс для внешней среды. По этой причине открытый командный интерфейс должен предоставлять по крайней мере следующие возможности: • команды для манипулирования файлами, их содержимым и доступа к ним; • команды для манипулирования директориями и доступа к ним; • диспетчеризация команд; • пакетный режим обработки команд; • доступ к информации о среде пользователя; • примитивы языков программирования для написания простых программ на командном языке. Основной стандарт в этой области — ISO/IEC 9945-2 (основан на IEEE Р1003.2). • Сервисы текстового пользовательского интерфейса предоставляют простые средства общения пользователя с вычислительной системой при помощи ввода и отображения текстовых данных. Исторически это первая форма организации пользовательского интерфейса. Сейчас она в значительной степени вытеснена графическими интерфейсами. • Сервисы графического пользовательского интерфейса (GUI — Graphical User Interface) обеспечивают для приложений возможность создавать и манипулировать визуальными объектами на экранах компьютеров. Пользователи должны иметь единый, легко понятный им стиль общения с вычислительной системой через такой интерфейс. На сегодняшний день GUI является общепринятой формой организации пользовательского интерфейса. АР должна иметь два интерфейса с сервисами GUI: • API сервиса визуальных объектов (часто также называется "оконный интерфейс") позволяет приложениям использовать сервисы GUI; • EEI обеспечивает форматы и протоколы обмена данными между сервисами GUI множества систем и формирование единообразной рабочей среды для пользователей различных систем. Среди стандартов на открытые сервисы GUI важное значение имеют протоколы XWindows — это стандарты де-факто, специфицированные и реализованные консорциумом Х/Ореn. Интерфейсы, основанные на этом стандарте, преобладают среди UNIX-подобных платформ. На персональных системах стандартами де-факто являются API операционных систем Microsoft Windows и MacOS. • Сервисы графики поддерживают работу приложений с графическими объектами —

растровую и векторную графику. Они имеют большое значение для многих типов приложений и очень развитый набор функций. API сервисов графики должен обеспечивать интерфейс для доступа приложений к этим сервисам. EEI должен поддерживать форматы и протоколы, необходимые для управления устройствами, отображения графической информации на удалённых устройствах и обмена графическими данными между системами. Ситуация со стандартизацией сервисов графики характеризуется наличием очень большого количества стандартов, важное место среди которых занимают стандарты ISO. • Сервисы разработки приложений — это сервисы, которые связаны с обеспечением жизненного цикла прикладного ПО, и, в особенности, этапа его разработки. Переносимость понимается здесь в двух аспектах. Первый — создание переносимого прикладного ПО. Второй — обеспечение переносимости в самом процессе создания ПО, когда, например, различные модули могут создаваться на различных платформах, а компиляция, отладка, тестирование, документирование — на других платформах. Весьма перспективным направлением развития сервисов разработки приложений является создание систем автоматизации проектирования программного обеспечения — CASE (Computer Aided Software Engineering). Соответствующие стандарты в основном находятся в стадии разработки; среди уже существующих можно отметить стандарты POSIX. 4. Межкатегориальные сервисы. Рассмотренные сервисы АР допускают довольно чёткую, хотя и не единственно возможную, классификацию. Следующая группа сервисов — так называемые межкатегориальные сервисы. Они принципиально отличается от указанных выше: • Межкатегориальные сервисы имеют определённое влияние на все остальные сервисы, которые предоставляются АР. Каждый сервисный компонент должен быть сконструирован с учётом этих межкатегориальных сервисов. • Все остальные сервисы предоставляют свои компоненты для того, чтобы межкатегориальные сервисы могли эффективно выполнять свои функции. • Сервисы поддержки национальных особенностей. Данные сервисы подразумевают учёт особенностей национальных языков, форматов представления числовых величин, дат, времени и т.п. в различных странах. Они не имеют значительного влияния на структурную организацию системы, поэтому в некоторых моделях они опущены. Две других категории сервисов, напротив, очень важны для функционирования системы; с ними связано большое число стандартов. • Сервисы защиты. Их целью является защита техническими средствами информации, обрабатываемой в распределённой системе. Сервисы защиты должны быть предусмотрены с самого начала жизненного цикла системы.. Они должны быть взаимоувязаны со всеми функциями и сервисами, которые предоставляет АР. В силу большого различия в целях, функциях, размере, сложности, а также разнородности программного и аппаратного обеспечения систем обработки данных невозможно выработать единого критерия, когда систему следует считать безопасной. Каждая система требует формулировки политики безопасности (security policy) для того, чтобы определить, какой уровень защищённости и какие правила разграничения доступа требуются для информации, обрабатываемой в этой системе. Для осуществления на практике этой политики могут быть применены механизмы, которые гарантируют желаемый уровень безопасности. Совокупность всех аппаратных и программных компонентов, с помощью которых в системе "проводится в жизнь" установленная политика безопасности, носит название комплекса средств защиты (согласно определению Гостехкомиссии; в оригинале - ТСВ — trusted computer base). Кроме того, должны существовать некоторые способы оценивания того, насколько хорошо эти механизмы реализуют заданную политику безопасности. Мы будем рассматривать только те механизмы, которые могут быть реализованы, измерены и оценены с точки зрения АР, исключая физические, организационные, юридические и пр. средства защиты. Для обеспечения механизмов, реализующих политику безопасности и оценку их эффективности, в системе требуется наличие нескольких сервисов: • сервисы аутентификации; • механизмы контроля доступа; • сервисы верификации (т.е. проверки целостности и полноты ресурсов системы);

• сервисы шифрования; • сервисы аудита; • средства установления доверия к каналам передачи и узлам обработки данных. Наиболее важными стандартами, относящимися к сервису защиты в контексте проблемы обеспечения переносимости, т.е. не затрагивая взаимосвязь систем, являются: • Стандарт IEEE P1003.6 — специфицирует функциональные требования и стандарты интерфейса системы для механизмов защиты, аудита и контроля состояния системы. Он включает следующие интерфейсы: • интерфейсы аудита; • интерфейсы привилегий доступа к объектам; • интерфейсы дискретционного контроля доступа; • интерфейсы мандатного контроля доступа. • ISO/IEC 15408 — Information technology — Security techniques -Evaluation criteria for IT security (Критерии оценки защищённости продуктов и систем информационных технологий). Стандарт описывает модель процесса проведения оценки защищённости продуктов и систем, даёт классификацию функциональных требований к механизмам защиты, специфицирует критерии, по которым производится соотнесение функций защиты, реализованных в системе, тому или иному уровню гарантий защищённости. Стандарт состоит из трёх частей: часть 1: Введение и общая модель; часть 2: Функциональные требования по защите; часть 3: Требования гарантий защищённости. • Сервисы административного управления системой. При стандартизации сервисов административного управления (management) открытыми системами в основном исходят из предположения о том, что управление производится в распределённой среде. Поэтому, рассматривая свойство переносимости, можно только перечислить требования, которым должна удовлетворять одна, отдельно взятая вычислительная система: • управляемость конфигурации процессоров; • инсталляция и управление программным обеспечением; • корректный запуск и останов системы; • лицензирование программного обеспечения; • управляемость и конфигурирование вычислительной сети; • управление организацией хранения данных на дисках; • диспетчеризация заданий; • администрирование пользователей; • учётность пользователей и ресурсов; • управление защитой; • управление производительностью системы; • управление ёмкостью носителей данных; • сервисы резервного копирования и восстановления; • управление нештатными ситуациями; • управление системой печати и пр. Этот перечень показывает, что при создании сервисов управления системой требуется учитывать, что они должны взаимодействовать практически со всеми остальными сервисами, ресурсами и объектами АР.

2.3. Способность к взаимодействию Конечная цель взаимодействия систем — обеспечение прозрачного доступа к любым ресурсам, несмотря на возможную неоднородность распределённой среды. Способность к взаимодействию необходима для поддержки широкого спектра функций систем и прикладных программ: от сравнительно простых до полнофункциональных сред, объединяющих информационные системы крупных предприятий. Примерами могут служить следующие функции: • электронная почта; • передача файлов из одной системы в другую; • доступ к приложениям на удалённой системе;

• разделение файлов между несколькими системами; • разделяемые базы данных; • сложные приложения, использующие ресурсы на различных системах, целостность которых гарантируется системой управления распределёнными транзакциями. Какая бы из этих или иных функций ни использовалась в системе, способность к взаимодействию обеспечивает более эффективное использование и уменьшает дублирование ресурсов, предоставляет новые пути разработки и распространения прикладного ПО в системе. Переносимость и способность к взаимодействию скрывают от пользователя различия между системами и стандартизируют способ их восприятия пользователями, приложениями или другими системами. Важно отметить, однако, что по существу цель сокрытия различий состоит не в полной их ликвидации или выравнивании, а наоборот, в использовании уникальных возможностей и характеристик каждой индивидуальной системы. Пользователю только представляется образ единой системы. Способность к взаимодействию обеспечивает несколько дополнительных преимуществ по сравнению с переносимостью: • Она позволяет объединять существующие системы с новыми, сохраняя преемственность и инвестиции, уже вложенные в информационную систему. • Она позволяет разрабатывать распределённые приложения. Это означает, что каждая из функций приложения может быть выполнена именно на той платформе, которая наилучшим образом подходит для этого. • За счёт прозрачного разделения ресурсов среды она создаёт такие условия для пользователя, что все ресурсы системы кажутся ему доступными локально. Как уже отмечалось ранее, способность к взаимодействия достигается посредством: • соединения системы коммуникационными средствами, которые позволяют осуществлять передачу данных между системами; • введения в систему набора дополнительных сервисов, которые используют коммуникационный сервис вычислительной сети. Действительно, когда системы имеют средства связи между собой: коммуникационные средства внешней среды, сетевые сервисы платформы приложений — они таким образом обеспечены средствами обмена сообщениями. Сетевые сервисы не являются специфичными для какого-либо приложения или типа приложений, работающих в системе. Это общецелевые сервисы, такие как адресация, маршрутизация сообщений, обеспечение надёжной их доставки и пр. Кроме того, для удовлетворения требований различных приложений необходим набор дополнительных сервисов. Но для того, чтобы выполнять функции, которые ожидают от приложений конечные пользователи, приложения должны "уметь" идентифицировать и распознавать среди всех передаваемых сообщений информацию, относящуюся к тому или иному приложению. К примеру, при передаче файла сообщения должны содержать имя файла, его атрибуты и данные, содержащиеся в файле. При выполнении распределённой транзакции менеджеры транзакции будут обмениваться управляющей информацией о начале и конце транзакции, а также об операциях, произведённых над данными каждым из них. Очевидно, для того, чтобы системы могли взаимодействовать на уровне приложений, необходима стандартизация таких сообщений, т.е. описание форматов и протоколов, которые определяют синтаксис сообщений и правила осуществления обмена. Таким образом приходим к необходимости описания "комплекта", набора протоколов различных уровней (как видно из предыдущих рассуждений — по крайней мере двух). Под протоколом принято понимать точно определённую последовательность действий, с помощью которой два или более логических объектов одного уровня совместно решают некоторую общую задачу. Иными словами, протоколы определяют логику взаимодействия удалённых логических объектов одного уровня.

Подобные многоуровневые наборы протоколов часто называют "стеками протоколов". Основной принцип описания таких протоколов — информация, имеющая значение для протокола определённого уровня, переносится протоколом нижележащего уровня безотносительно к содержанию этой информации. Вернёмся к модели информационной системы, введённой в п. 2.1. При рассмотрении переносимости обсуждались два типа интерфейсов АР: API и EEI с пользователями и внешними

объектами данных. С точки зрения способности систем к взаимодействию имеет значение другой компонент — EEI между АР и коммуникационными средствами внешней среды. Коммуникационные средства позволяют одной данной системе рассматривать все другие системы как часть внешней среды (рис. 6). Чтобы добиться способности к взаимодействию, необходимо стандартизировать форматы и протоколы обмена сообщениями через EEI, используя коммуникационные средства внешней среды. Часть EEI, которая управляет такими сообщениями, носит название коммуникационного интерфейса. Он включает в себя сетевые протоколы и высокоуровневые прикладные протоколы, необходимые для поддержки распределённых сервисов. Коммуникационный интерфейс — это единственный интерфейс, где две (вероятно, различные) системы непосредственно контактируют друг с другом. Он позволяет платформам приложений осуществлять взаимный доступ к ресурсам и предоставлять сервис друг другу, используя сетевые и соответствующие прикладные протоколы. Способность к взаимодействию обращается к таким функциональным возможностям, которые не затрагивает переносимость. Так, она организует доступ к тем сервисам АР, к которым пользователь или приложение не имеют прямого доступа через API. При этом не имеет значения, как именно реализуется внутри той или иной системы конкретный вид сервиса. Он вполне может использовать внутренние особенности и преимущества организации системы.

Рис. 6. Базовая модель взаимодействующих систем

Заметим, что для достижения способности к взаимодействию нет необходимости стандартизировать API — только соответствующие форматы и протоколы. Также для этого не нужны стандарты на те сервисы, которые являются внутренними для АР, и те части EEI, которые взаимодействуют с внешними объектами данных и пользователями. Однако из этого правила есть исключение: стандартизация API сетевых сервисов способствует обеспечению взаимодействия на более высоком уровне. Тогда появляется возможность ввести в состав платформы приложения, работающие с сетевыми сервисами, а их услугами уже могут пользоваться остальные приложения. Установив необходимость многоуровневой организации взаимодействия открытых систем, рассмотрим более подробно основные преимущества такого подхода: • Многоуровневая организация есть частный случай модульности — это позволяет легче понимать структуру системы. • Протоколы различных уровней в стеке и виды передаваемой ими информации в основе своей независимы друг от друга. Несмотря на то, что каждый уровень выполняет свою работу по указанию вышестоящего уровня, способ выполнения запроса не имеет значения для сделавшего запрос. • Уровневые сервисы всегда включают некоторый сервис по транспортировке данных, который предоставляется верхним уровням. Это означает, что, хотя каждому объекту некоторого уровня кажется, что он взаимодействует с объектом того же уровня, на самом деле перемещение данных по всем уровням, кроме самого нижнего, происходит "вертикально". И только нижний уровень действительно пере-

мещает данные "горизонтально". Отметим теперь основные принципы многоуровневого взаимодействия: • Взаимодействие по принципу сервисов и протоколов. Каждый уровень взаимодействия предоставляет сервисы уровню, расположенному над ним, и сам, в свою очередь, пользуется сервисами уровня, расположенного под ним. Сервис определённого уровня доставляется посредством протокола этого уровня. Уровень, запросивший сервис, не видит протокол нижнего уровня. Таким образом, протоколы образуют каскад сервисов, предоставляемых с верхнего уровня до нижнего. • Мультиплексирование. Множество объектов верхнего уровня могут параллельно использовать сервис нижнего уровня. Множество сервисов различного качества и различной функциональности могут предоставляться на каждом уровне по соглашению между партнёрами. • Свобода выбора протокола. Каждый уровень может выбирать свой собственный протокол независимо от других уровней. Кроме того, чёткое разделение функций между уровнями допускает дальнейшую декомпозицию уровня на подуровни, вставку протоколов "поверх" и "внизу" уровня, • Качество сервиса. Каждый отдельный уровень может предлагать альтернативные возможности реализации сервиса, гарантированно определяющие некоторые его свойства или параметры, например, скорость, надёжность соединения. • Адресация. Любая форма коммуникации требует какой-либо подходящей формы адресации. На каждом уровне формат адресации является частью соответствующего протокола. • Виды соединений. Различают два вида организации взаимодействия в протоколах: с установлением соединения и без установления соединения. В первом случае для передачи серии сообщений устанавливается выделенное соединение, которое обеспечивает подтверждение доставки, обнаружение ошибок, повторную передачу и восстановление порядка следования сообщений. Примером связи с установлением соединения являются услуги телефонной сети. Во втором случае каждое сообщение передаётся независимо от остальных, содержит полную информацию об адресах отправителя и получателя и в принципе может передаваться по различным маршрутам. В общем случае такая форма передачи сообщений является ненадёжной, но быстрой. Она может приводить к потере, возникновению ошибок в сообщениях, изменению порядка их следования или повторным передачам. Это, однако, может быть выявлено и исправлено средствами верхних уровней. Пример такой связи — почтовая служба. • Ограниченность связей. Объекты взаимодействуют между собой на одном уровне "горизонтально" по протоколам, потоки данных движутся "вертикально" (за исключением самого нижнего уровня). Каждый уровень добавляет управляющую информацию, специфичную для протокола этого уровня. На самом нижнем уровне, таким образом, передаётся сложный конгломерат данных. Каждый уровень при такой форме связи "видит" только смежные с ним уровни. Классическим примером многоуровневой модели взаимодействия вычислительных систем является семиуровневая модель взаимосвязи открытых систем, описанная в стандарте ISO/IEC 7498 — Information technology — Open Systems Interconnection — Basic Reference Model, известная как модель OSI (см. п. 3.2.1). Кроме указанной, существует ещё большое количество многоуровневых моделей взаимодействия вычислительных систем и соответствующих им стеков протоколов: DNA (Digital Network Architecture), AppleTalk, SNA (System Network Architecture), TCP/IP и др. Вследствие несовместимостей между различными моделями добиться способности к взаимодействию на практике — существенно более сложная задача, чем это может показаться теоретически. Для этого требуется организовать "мосты" между различными моделями (стеками протоколов) и сделать их существование прозрачным для пользователей и приложений. Более того, исторически не существовало единого и чёткого разделения протоколов на указанные уровни. Поэтому различные стеки протоколов не обязательно согласуются между собой по разбиению на уровни, выполняемым на этих уровнях функциям и даже по числу уровней. Всё это порождает определённую зависимость протоколов верхних уровней от нижних для каждого конкретного стека протоколов.

Вторым необходимым условием взаимодействия систем, как уже отмечалось, является введение в систему набора распределённых сервисов приложений, которые используют сетевые сервисы АР и расширяют таким образом свои собственные сервисы. Распределённые сервисы удобно рассматривать, придерживаясь той же классификации, что и сервисы локальной платформы: • распределённые сервисы платформы; • распределённые сервисы данных; • распределённые сервисы человекомашинного взаимодействия. В качестве примеров сервисов из соответствующих групп можно привести: • вызов удалённых процедур; • передача файлов; • удалённый вход в систему. Дополнительно рассматриваются межкатегориальные сервисы. Такое представление согласуется с концепцией единой, распределённой системы, где все аспекты взаимодействия между отдельными системами регулируются внутри АР. Часто протоколы, соответствующие в стеке коммуникационных протоколов сетевым сервисам и распределённым сервисам приложений, называют соответственно транспортными провайдерами (transport provider) и транспортными пользователями (transport user). Первые обеспечивают базовые, не зависящие от приложений, функции по доставке сообщений через сеть. Вторые строятся на сетевых сервисах и расширяют сервисы АР в распределённых системах. В коммуникационных моделях они примерно соответствуют или отождествляются с самими приложениями. Сейчас понятие распределённой вычислительной среды часто ассоциируется с моделью вычислений «клиент - сервер». Эта модель означает совместную обработку запросов, подаваемых клиентом (как правило, программой), т.е. просителем услуг, серверу (как правило, тоже программе), т.е. поставщику услуг, который обрабатывает запросы и возвращает результаты клиенту. Известно несколько других моделей организации вычислений, получавших развитие на различных этапах эволюции распределённых вычислений: централизованная, хост-модель (host-based), модель "ведущий - ведомый" (master - slave), модель разделения устройств (shared device processing), одноранговая модель (peer-to-peer). Но наибольшее распространение получила именно клиент-серверная модель: она является самой оптимальной в условиях неоднородной распределённой вычислительной среды с дисбалансом вычислительных мощностей. Однако, клиент-серверная обработка предъявляет и определённые архитектурные требования: наличие надёжной связи между клиентами и серверами, разделение логики прикладных программ между клиентом и сервером, координация взаимодействий между клиентом и сервером, инициируемых клиентом, контроль сервера над сервисами и данными, которые запрашиваются клиентами, разрешение сервером конфликтующих запросов клиентов. Основные преимущества клиент-серверных вычислений включают возможности широкого включения в распределённые вычислительные относительно маломощных вычислительных систем, снижения сетевого графика (т.к. обработка данных приближается к источнику данных), использования графического пользовательского интерфейса, поддержки стандартов открытых систем. Клиент-серверные вычисления в распределённой вычислительной среде прочно связаны с концепцией "middleware". Этот термин является сокращением и может быть интерпретирован как "программное обеспечение среднего уровня". Идея дополнения системного ПО этим компонентом возникла из естественного стремления сократить трудоёмкость разработки прикладного ПО для работы в клиент-серверной модели. Middleware - это соединяющий уровень коммуникационного ПО между физической сетью передачи данных и приложениями пользователя, выполняющего функции транспортного пользователя, в общем случае эквивалентное уровням 5 и 6 модели OSI (см. п. 3.2.1). Со стороны приложений это ПО содержит упрощающие программирование высокоуровневые API, которые "экранируют" разработку прикладного ПО от сложных коммуникационных протоколов на нижних уровнях. Используя инструменты и продукты middleware, программисты могут сфокусироваться на создании собственно логики приложений,

не разрабатывая при этом сложные коммуникационные протоколы и интерфейсы. С появлением более сложных моделей открытых распределённых вычислений и постоянным расширением состава ПО, который можно отнести к "среднему уровню", концепция middleware стала "поглощаться" этими моделями. 1. Сетевые сервисы. Функция сетевых сервисов — предоставление общих услуг по транспортировке между системами сообщений, посылаемых приложениями. Сетевые сервисы могут быть в свою очередь подразделены на две группы согласно тому, видимы или нет они для транспортных пользователей. К сервисам, видимым приложениями напрямую, относятся: установление и разрыв соединения с партнёром, управление качеством сервиса для передачи данных, выбор функций сообщения о состоянии сети. Но даже эти сервисы могут быть скрыты от приложений в некоторых формах коммуникаций, например, при вызове удалённых процедур — RPC (Remote Procedure Call). Другие сервисы, невидимые для приложений, относятся к нижним уровням стека протоколов. Они обычно связаны с физическими аспектами сети: • сообщение об ошибках и восстановление после ошибок; • сегментация сообщений в пакеты установленного в сети размера и их повторная сборка; • директориальные сервисы, которые обеспечивают преобразование символических имён сетевых ресурсов в адреса; • многопутевая маршрутизация, которая позволяет сообщениям передаваться различными маршрутами от точки отправления до точки получения; • физический доступ к узлам сети; • управление потоками, включая средства обнаружения состояний переполнения и регулирования интенсивности трафика. Нижний уровень модели (транспортный провайдер) часто рассматривают как состоящий из двух подуровней: • Уровень сети передачи данных — нижний уровень, ответственный за управление графиком, передающимся от узла к узлу внутри единичной физической сети передачи данных (subnetwork). Примерами сетей передачи данных являются сети Х.25, локальные сети стандартов IEEE 802-x, Frame Relay, ATM, двухточечные линии связи. Сети передачи данных можно классифицировать по следующим признакам: • по используемой технологии передачи данных: • образование соединений; • метод разделения канала; • по территориальной распределённости и связанным с этим особенностям организации: • локальные (LAN — local area network); • глобальные (WAN — wide area network); • городские и сети среднего уровня (MAN — metropolitan area network). Существует большое количество стандартов по технологиям, связанным с организацией сетей передачи данных. Однако, они не имеют прямого отношения к достижению основных качеств открытой среды: переносимости и способности к взаимодействию. Скорее, они служат отправной точкой для разработки таких стандартов. • Межсетевой уровень — верхний (из двух) уровень транспортного провайдера, ответственный за формирование единой логической сети (internetwork) из совокупности физических сетей передачи данных (subnetworks). Этот уровень обеспечивает формирование единого адресного и маршрутного пространства, которое накладывается на все нижележащие сети передачи данных, но в то же время не зависимо ни от одной определённой сети передачи данных. Межсетевой уровень позволяет строить единую, прозрачную для пользователя логическую сеть из множества взаимно соединённых локальных и глобальных сетей. Конечной целью объединения сетей является обеспечение надёжной и прозрачной доставки сообщений между любыми системами через множество промежуточных систем, независимо от объединяемых сетей. Другими словами, формируется транспортная система, которая компенсирует любые различия во входящих в неё сетях, чтобы обеспечить необходимый уровень сервиса для приложений. Иногда такой компенсации не требуется, но транспортная систе-

ма всегда обеспечивает не зависящий от сети передачи данных данных коммуникационный механизм между двумя оконечными взаимодействующими системами. С точки зрения приложений она гарантирует, что сообщения успешно достигнут другой системы. Модели взаимодействия вычислительных систем и соответствующие им стеки протоколов, такие как OSI, SNA, DNA, не специфицируют API к своим сетевым сервисам. Это и не требуется: способность к взаимодействию уже может быть обеспечена за счёт единства протоколов и форматов данных. Однако, определение и использование стандартных API для сетевых сервисов содействует упрощению разработки и развёртывания в системе распределённых приложений, так как обеспечивает более высокоуровневое взаимодействие между системами. Этим, в частности, объясняется широкое распространение протоколов TCP/IP. Наиболее известными стандартами на API для доступа к транспортным сервисам являются: • Интерфейс сокетов (socket interface), берущий начало из версии UNIX BSD; • XSOCKET, стандартизованный X/Open; • TLI (Transport Layer Interface), частично основанный на socket, а частично на стандарте ISO 8072 по транспортному сервису; • XTI (X/Open Transport Interface) — базируется на TLI, может поддерживать несколько стеков протоколов: OSI, TCP/IP, NetBIOS, SNA. Несколько иной подход представляет технология MPTN (Multiprotocol Transport Networking), разработанная IBM и принятая X/Open. Она компенсирует неоднородности в функциональности различных транспортных протоколов за счёт введения дополнительного уровня над транспортным уровнем — CTS (Common Transport Semantics). MPTN позволяет "смешивать" в произвольной комбинации транспортные провайдеры и транспортные пользователи, делая приложения независимыми от используемых сетевых протоколов. Следовательно, приложения могут использовать транспортную систему, отличную от той, которая "ассоциирована" с высокоуровневыми прикладными протоколами. 2. Сервисы распределённой платформы. Любая прикладная программа включает три компонента: логику приложения, сервисы данных и сервисы представления информации. Логика приложения выполняет специфические для конкретного приложения функции и реализуется с помощью системных сервисов и сервисов языков программирования. Сервисы данных приложения выполняют операции ввода/вывода, требуемые приложением. Сервисы представления приложения управляют взаимодействием с пользователем. Эти компоненты эквивалентны соответствующим сервисам в рассматриваемой модели. Если приложение становится распределённым, существует три возможности "расщепления" приложений согласно перечисленным компонентам: • Разделение сервиса представления. Распределение приложения заключается в распределении сервиса представления — все остальные компоненты работают на одной локальной платформе. В этом случае приложение не осведомлено о том, что оно работает в распределённой среде, так как имеет доступ к сервисам представления на своей локальной платформе. Распределённый характер приложения выражается, например, в процедуре удалённого входа в систему (remote login) или распределённом графическом интерфейсе пользователя (GUI). • Разделение сервиса данных. В этом случае приложение также не имеет представления о том, что данные или ресурсы печати являются удалёнными. Приложение имеет доступ к сервисам данных так, как если бы они были локальными для приложения. • Разделение логики приложения. В этом случае различные функции приложения выполняются на удалённых друг от друга платформах, поэтому для взаимодействия между компонентами приложения требуется та или иная форма коммуникаций. Эта форма распределения наиболее значима для распределённых систем, так как позволяет достичь наибольших преимуществ (выигрыш в производительности, параллельная обработка, наиболее полная загрузка процессоров и т.д.). Все три случая имеют похожие требования, и все так или иначе используют коммуникационные сервисы. Различаются они только в том, что в первых двух случаях коммуникационные возможности задействуются системой, а в последнем случае их использование является

заботой приложения. Распределённое приложение в последнем случае, очевидно, сталкивается с необходимостью определённой координации функционирования своих компонентов. Основными требованиями со стороны распределённых приложений являются обеспечение возможности связи между компонентами приложения, обеспечение возможности обнаружения компонент в распределённой системе и обеспечение синхронизации работы компонент приложения. Сервисы распределённой платформы — это расширения внутренних сервисов платформы, рассмотренных в п. 2.2, перенесённые в распределённую среду. Они предоставляют основные механизмы распределения приложений, обеспечивают функции по координации распределённой работы приложений. Часто они также носят название «сервисы распределения». Сообразно основным требованиям приложений в распределённой среде можно выделить три класса таких сервисов: • сервисы межпроцессного взаимодействия; • сервисы именования ресурсов; • сервисы времени. • Сервисы межпроцессного взаимодействия. Существует три основные модели организации взаимодействия между программами: • Диалоговая (conversational) модель. Приложения общаются друг с другом посредством посылки вызовов: «установить соединение», «послать сообщение», «принять сообщение», «разрушить соединение» и пр. Это форма связи с установлением соединения. Наиболее известными стандартами, в которых определяются диалоговая модель коммуникаций, являются ISO 10026 — OSI Distributed Transaction Processing и архитектура АРРС (Advanced Program-to-Program Communication) фирмы IBM. • Вызов удалённых процедур (RPC — Remote Procedure Call). Эта модель является расширением традиционного метода вызова процедур в языках программирования. Вызов удалённой процедуры заключается в однократном обмене сообщениями между вызывающей и вызываемой процедурами, как при локальном вызове. При этом использование коммуникационных сервисов происходит невидимо для обеих процедур. RPC может иметь место как с установлением соединения, так и без него. Но с точки зрения приложения он является синхронной формой коммуникаций, так как оба партнёра должны быть активны в одно и то же время, а вызывающая процедура приостанавливается на время выполнения удалённой. Эта форма коммуникаций обычно ассоциируется с моделью вычислений "клиент/сервер". Основными стандартами по вызову удалённых процедур являются: - Sun RPC; - OSF RPC, являющийся основой OSF DCE (Distributed Computing Environment); - OSI RPC — стандарт ISO 11578. • Очереди сообщений (message queuing). При этой форме взаимодействия один из процессов помещает свои сообщения в очередь, другой извлекает их оттуда. Это форма коммуникаций без установления соединения. Существует проект международного стандарта по этому виду коммуникаций --ISO/IEC DIS 10026-7 Information technology - Open Systems Interconnection — Distributed transaction processing — Part 7: Message queueing. • Сервисы именования ресурсов. Сервисы именования ресурсов и директориальные сервисы являются критичными для распределённой среды, так как размещение и обнаружение ресурсов в ней намного сложнее, чем в локальной системе. Необходимым условием является присвоение всем объектам, ресурсам и приложениям в распределённой среде уникальных глобальных имён. Такие имена должны быть аппаратно- и архитектурно - независимыми. Другими словами, необходима единая логическая схема именования ресурсов, с помощью которой можно обращаться к любому объекту или ресурсу, существующему в системе. Другое требование состоит в том, что директориальный сервис должен самостоятельно отображать логические имена на реальные адреса объектов. Для этого необходимо определять местоположение объекта и предоставить подходящий коммуникационный протокол для доступа к нему.

Среди схем именования ресурсов наибольшее значение имеют схема ISO, являющаяся частью модели OSI, и доменная система имён (DNS — Domain Name System), используемая в Internet (RFC 1034, RFC 1035). Основным стандартом на директориальный сервис является рекомендация Х.500 и её эквивалент ISO 9594. Х/Ореn специфицировала стандарт на API для доступа к директориальному сервису Х.500 — XDS (X/Open Directory Services). Спецификация OSF DCE Directory Service обеспечивает механизм для совмещения обоих стандартов: DNS и Х.500. • Распределённые сервисы времени. В локальной системе обычно существует единственный системный таймер, услугами которого могут пользоваться все приложения. Однако, в распределённой среде, состоящей из множества вычислительных систем, различные системы вследствие многих причин (разница хода часов, задержки передачи в сети и пр.) могут иметь различные значения текущего времени. Для обеспечения нормальной работы приложений иногда необходима синхронизация показаний таймеров на всех системах, входящих в распределённую среду. Существуют следующие стандарты де-факто на распределённый сервис времени: DCE Distributed Time Service и RFC-1119 (Network Time Protocol). Реализация сервисов распределённой платформы отличается от реализации внутренних сервисов локальной АР. Если в локальной среде они представляются соответствующими элементами программного обеспечения: операционной системой, трансляторами, СУБД и пр., то в распределённой среде соответствующие сервисы реализуются специально назначенными для выполнения определённых функций аппаратно-программными системами — серверами, например, директориальными серверами, серверами времени. Система может выполнять роль сервера для нескольких сервисов одновременно, а может одновременно служить сервером для одного сервиса и быть клиентом другого. 3. Распределённые сервисы данных соответствуют разбиению приложений по сервисам данных. Они являются естественным расширением соответствующих сервисов в локальной среде. Выделяют следующие группы сервисов данных: • сервис обмена данными; • сервис передачи файлов; • сервис управления сообщениями (электронная почта); • распределённый файловый сервис; • сервис распределённых баз данных; • распределённый сервис печати; • сервис распределённой обработки транзакций. • Сервис обмена данными. Общим условием для реализации всех вышеперечисленных сервисов является требование представления данных в едином формате — синтаксисе, "понятном" всем приложениям и всем платформам. Это даёт возможность передавать и корректно интерпретировать данные, взятые с одной платформы, на другой платформе. Основными стандартами по синтаксису данных являются ISO/IEC 8824 — Information technology — Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.l) и ISO/IEC 8825 — Information technology — Open Systems Interconnection — Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.l). • Сервис передачи файлов. Передача файлов является одним из основных способов разделения данных между взаимодействующими системами. Сервис передачи файлов подразумевает, что всякий раз, когда приложение требует данные, которые, как оказывается, хранятся на другой системе, файл с этими данными целиком копируется с удалённой системы на локальную. Приложение может работать с переданным файлом и при необходимости имеет возможность возвратить его обратно, внеся на локальной системе изменения в содержание файла. Сервис передачи файлов в распределённой среде может сталкиваться с существованием множества различных файловых систем и методов доступа к файлам. Обычно сервис передачи файлов подразумевает, что существует пользователь или приложение, которое управляет передачей файла между двумя системами. Этот пользователь, как правило, размещается на системе-получателе. Передача файла включает два вида взаимодействия: управляющие операции, которые выполняются пользователем или приложением (контроль

доступа, выбор файла,управление файлами и атрибутами файлов) и протокол передачи файлов. Файловые системы обеих взаимодействующих систем должны представляться как некоторое условное хранилище файлов в форме, одинаково интерпретируемой обеими системами. Для доступа к реальным данным каждая система должна "спроецировать" этот образ на реальную файловую систему. Существует два основных стандарта по сервису передачи файлов: • стандарт де-юре ISO 8571 — Information processing systems — Open Systems Interconnection — File Transfer, Access and Management (FTAM); • стандарт де-факто RFC 959 — File Transfer Protocol (FTP), используемый в стеке протоколов TCP/IP. Стандарты ISO по сравнению со стандартами RFC обладают значительно большей функциональностью, но дополнительные функции приводят к значительно более объёмному и сложному программному коду при реализации и большим "накладным расходам" при исполнении этого кода системой. К тому же на практике обычно используется лишь небольшое подмножество этих функций. Это замечание остается справедливым и при сравнении многих других соответствующих стандартов ISO и RFC.

• Сервисы управления сообщениями. Сервис управления сообщениями имеет следующие основные характерные черты. • Для доставки сообщений используется метод "хранения и продвижения" (storeand- forward). Это означает, что пользователи не устанавливают между сбой непосредственно сеанс связи, а взаимодействуют с сервисом управления сообщениями, передавая ему поручения по пересылке сообщений. Локальная и удалённые системы совместно несут ответственность за посланное отправителем сообщение и гарантируют его доставку, даже если в текущий момент отсутствует соединение с удалённой системой-получателем или она является неактивной. Сервис управления сообщениями — асинхронная форма коммуникаций без установления соединения. • В отличие от сервиса передачи файлов отправитель и получатель здесь — это конечные пользователи (люди или прикладные программы), а не файловые системы. • Сервис предусматривает специальные возможности для групповой и широковещательной рассылки сообщений, ведения "адресной книги" и пр. • Сервис предусматривает пересылку различных видов сообщений: обычного текста, файлов, сложных документов, факсов и пр. • Сервис управления сообщениями не интересуется содержанием передаваемых сообщений. Термин "управление сообщениями" означает способность сервиса обеспечивать прозрачную пересылку по информационной системе любого сообщения, независимо от конкретного его типа. Интерпретация и использование сообщений возлагается на прикладные программы, которые пользуются этим сервисом. Частным случаем систем управления сообщениями является электронная почта. Она задумана как аналог обычной почтовой системы для работы с электронными документами и используется для доставки текстовых сообщений (возможно, с присоединёнными к ним файлами) от одного пользователя (программы) к другому. Существует две основные группы стандартов по сервису управления сообщениями: • стандарт де-юре ISO/IEC 10021 — Message Handling Systems (MHS) и их эквивалент — серия стандартов Х.400; • стандарты де-факто RFC 821, RFC 822 — Simple Mail Transfer Protocol (SMTP), используемый в стеке протоколов TCP/IP. SMTP использует для адресации доменную систему имён DNS. • Распределённые файловые сервисы обеспечивают прозрачный доступ к файлам независимо от их физического расположения в распределённой системе. Основное их отличие от сервиса передачи файлов — в том, что вместо передачи целого файла от одной системы к другой передаются только те его части, которые необходимы для выполнения конкретной операции. Распределённые файловые сервисы часто также называют прозрачным доступом к файлам (TFA — transparent file access). Распределённые файловые сервисы могут обеспечивать такие возможности как управление параллельным доступом, контроль доступа и пр.

Основным стандартом де-юре является ранее упомянутый OSI FTAM, определяющий в том числе возможность прозрачного доступа к файлам. Среди стандартов де-факто наибольшее значение имеют SunNFS, используемый с протоколом TCP/IP, OSF/DCE Distributed File Service (DFS), распределённая файловая система UNF (Universal File System) сетевой ОС Novell NetWare. • Сервисы распределённых баз данных. Рассмотренные до сих пор сервисы обеспечивают доступ к файловым системам, считая файлы неструктурированным набором данных, где любая интерпретация содержания файлов производится самим приложением. Базы данных обеспечивают для приложений функции более высокого уровня, определяя внутреннюю структуру данных и высокоуровневый механизм для хранения и доступа к данным, не касаясь их физической организации. При организации сервисов баз данных в распределённых средах необходимо решить проблемы пересылки запросов к БД и получения ответов через множество разнородных систем, а также согласовывать состояние БД на различных системах. Данные, которые запрашивает приложение, могут располагаться либо на локальной системе, либо на удалённой, либо быть распределёнными, т.е. составляться из данных, находящихся на нескольких системах. Имея в виду различия в моделях и структуре БД и множество различных СУБД, сервис должен обеспечить стандартизованную и прозрачную работу пользователя с распределёнными БД. Основными стандартами по данному сервису являются: • ISO/IEC 9579 — Information technology — Open Systems Interconnection -- Remote Database Access; • Distributed Relational Database Architecture (DRDA), — спецификация, разработанная фирмой IBM. • Распределённые сервисы печати организуют работу пользователя по печати документов в распределённых средах, обеспечивая тот же набор услуг, что и на локальной системе. Основной стандарт по распределённому сервису печати — ISO/IEC 10175 — Information technology — Text and office systems — Document Printing Application (DPA). • Сервисы распределённой обработки транзакций. В п.2.2 уже рассматривалась модель распределённой обработки транзакций и указывалось, что для обеспечения переносимости необходима спецификация интерфейсов между элементами модели и с приложениями. С точки зрения взаимодействия систем необходима стандартизация того элемента, который обеспечивает связь между системами, участвующими в транзакции — менеджера транзакций. Основным международным стандартом является ISO 10026 — Information technology - Open Systems Interconnection - Distributed transaction proccesing (OSI-TP). Организация X/Open стандартизировала API для доступа приложений к сервису, удовлетворяющему стандарту OSI-TP. Этот интерфейс носит название ХАР-ТР. 4. Распределённые сервисы человекомашинного взаимодействия соответствуют разбиению распределённых приложений в части сервиса представления. Основная задача — приложение и пользователь должны казаться друг другу расположенными локально несмотря на различия в системах. Поддержка человекомашинного взаимодействия в неоднородных средах требует стандартного набора протоколов для переноса данных сервиса представления. Распределённые сервисы человекомашинного взаимодействия характеризуются тем, что часть функций представления выполняется локально на системе пользователя, а часть — удалённо, на той системе, где выполняется приложение. Каждый из распределённых сервисов человекомашинного взаимодействия соответствует аналогичному локальному сервису, но принимает иные формы: • локальный командный интерфейс превращается в интерфейс для удалённого исполнения команд (распределённую оболочку); • символьный интерфейс пользователя обычно превращается в сервис удалённого терминала, или удалённого входа в систему; • GUI, обеспечивающий доступ к приложению через сеть, носит название распределённого оконного интерфейса. • Распределённая оболочка. В распределённой среде пользователь должен иметь командный доступ к сервисам операционных систем, отличных от той, которая установлена на

его локальной системе, без необходимости регистрации на каждой удалённой системе. Этот сервис включает следующие функции: • выполнение команд оболочки на удалённой системе; • выполнение пакетных заданий с обеспечением прозрачности; • контроль доступа к системам и ресурсам. Основной стандарт по сервисам оболочки — IEEE 1003.2 (его эквивалент--ISO/IEC 9945-2:1993 Information technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities). • Удалённый терминал. Символьный интерфейс для удалённого входа в систему часто также называют виртуальным терминалом. Этот сервис должен обеспечивать возможность входа в систему с различного оборудования и через различные транспортные системы. Существует два основных стандарта по данному сервису: • модель OSI Virtual Terminal (VT), изложенная в стандартах ISO/IEC 9040:1997 — Information technology — Open Systems Interconnection — Virtual Terminal Basic Class Service и ISO/IEC 9041 — Information technology — Open Systems Interconnection — Virtual Terminal Basic Class Protocol; • протокол TELNET из стека TCP/IP. • Распределённый графический интерфейс. Протоколы, специфицирующие распределённый графический интерфейс, должны поддерживать выполнение более сложных операций, чем просто чтение/запись в случае виртуального терминала. В неоднородной среде протокол должен поддерживать различные типы устройств ввода/вывода и быть прозрачным для приложений. Основные стандарты де-факто основаны на системе X-Window. 5. Межкатегориальные сервисы в распределённой среде являются расширением аналогичных сервисов локальной платформы. Рассмотрим два основных класса межкатегориальных сервисов: управления системой и безопасности — в аспекте взаимодействия систем. Управление системой и безопасность оказывают значительное влияние на все части распределённой системы и требуют единообразного подхода. • Сервисы административного управления распределёнными системами являются критичными для нормального функционирования распределённой системы. Как и в локальной среде, сервисы управления включают в себя много аспектов, такие как управление конфигурацией сети, управление нештатными ситуациями, управление производительностью, инсталляцию программного обеспечения и др. Но задача управления осложняется тем, что в гетерогенной системе присутствует различное аппаратное обеспечение, операционные системы, сети передачи данных; приложения используют различные методы доступа к ресурсам и т.д. Основным стандартом де-юре по административному управлению распределёнными системами служит модель управления OSI, изложенная в стандарте ISO/IEC 7498-4:1989 Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 4: Management framework. Основными элементами этой модели являются: • менеджер — процесс, который получает и отслеживает управляющую информацию и вызывает операции управления; • агент — процесс, который выполняет операции управления по команде менеджера и передаёт менеджеру информацию для принятия решений по управлению; • управляемый объект — представляет управляемые ресурсы. Собрание сведений об управляемых ресурсах называется управляющей информационной базой MIB (Management Information Base). Модель получает развитие в следующем наборе стандартов ISO: • ISO/IEC 9595 — Information technology — Open Systems Interconnection -- Common management information service (CMIS); • ISO/IEC 9596 — Information technology — Open Systems Interconnection -- Common management information protocol (CMIP) — определяет протокол прикладного уровня для передачи управляющей информации; • ISO/IEC 10040 — Information technology — Open Systems Interconnection — Systems management overview; • ISO/IEC 10164 — Information technology — Open Systems Interconnection — Systems

Management; • ISO/IEC 10165 — Information technology — Open Systems Interconnection — Management Information Services — Structure of management information. Аналогом стандартов ISO в стеке протоколов TCP/IP являются: • протокол SNMP — аналог CMIP; • RFC 1155 — структура управляющей информации; • RFC 1213 — структура MIB. Среди других стандартов по административному управлению системами следует отметить: • стратегию управления распределёнными системами DME (Distributed Management Framework) организации X/Open; • модель управления административной информацией CIM (Common Information Model) организации The Open Group. Многие ведущие фирмы-производители также специфицируют свои подходы к управлению распределёнными системами и API к сервисам управления. • Сервисы защиты. Сервис защиты в распределённой (в особенности, неоднородной) среде имеет много аспектов и включает много механизмов защиты: идентификация и аутентификация, целостность, конфиденциальность данных, контроль доступа и авторизация, неотказуемость, аудит, административное управление сервисом защиты и пр. Распределённый характер системы добавляет много дополнительных угроз безопасности по сравнению с локальными системами. Так, особенностями распределённых систем являются невозможность обеспечить физическую безопасность системы в целом и, как правило, открытость коммуникационных каналов.В силу высокой сложности проблемы существует большое количество стандартов по организации сервиса защиты в распределённой среде. Основные группы этих стандартов рассматриваются в гл. 4. В целом в настоящее время наблюдается стремление к интегрированному решению проблем защиты информации в распределённой вычислительной среде. Ссылки и замечания к гл. 2: п. 2.1: Гл. 2 во многом основана на материалах [20, ch. 3,4,5] как одного из наиболее удачных руководств по концепции открытых систем: из этой работы заимствованы базовая модель информационной системы, методика её декомпозиции и классификация сервисов базовой модели. За основу модели берётся стандарт POSIX std 1003.0 - 1995 — The IEEE Guide to the POSIX Open System Environment (POSIX.O). Данная модель, конечно, уступает по полноте и подробности тем, что вводятся в документах организаций по стандартизации, но она позволяет ясно и чётко представить основные функции системы обработки данных по поддержке прикладного ПО, ввести понятия сервисов как абстрактного представления компонентов информационной системы, широко применяемое в реальных стандартах, обосновать необходимость введения стандартизованных интерфейсов (п. 2.2) и многоуровневых коммуникационных архитектур (п. 2.3), классифицировать значительную часть стандартов по информационным технологиям. Такая модель создаёт основу для более детального изучения отдельных классов программного обеспечения (операционные системы, СУБД, стеки коммуникационных протоколов и др.), даёт возможность грамотно классифицировать и определять место в системе практически любого программного продукта. Часто в литературе можно встретить иную, более широкую трактовку понятий, связанных с распределённой обработкой данных. Так, под распределёнными вычислительными системами в ряде источников понимают вообще любую вычислительную систему, в которой обработка данных производится одновременно более чем на одном процессоре. В этом случае в класс распределённых вычислительных систем попадают также все многопроцессорные локальные вычислительные системы и комплексы: компьютеры с параллельной архитектурой, суперкомпьютеры, кластеры вычислительных систем и др. В данной работе такие вычислительные системы не выделяются специально: они считаются локальными, хотя, возможно, и используют для связи между своими обрабатывающими узлами какие-либо элементы сетевых технологий. Под распределёнными вычислительными системами мы прежде всего будем понимать системы с территориально распределёнными (локально или глобально) вычислительными и информационными ресурсами. п. 2.2, 2.3: Переносимость (portability) и способность к взаимодействию (interoperability) упоминаются как необходимые свойства открытых систем во всех без исключения определениях. Иногда к ним добавляют другие, которые, как правило, являются производными от них. В глоссарии к [24] эти два свойства определяются следующим образом (приводится исходный текст на английском языке): "Portability — (1) The ease with which a system or component can be transferred from one hardware or software environment to another. (2) A quality metric that can be used to measure the relative effort to transport the software for use in another environment or to convert software for use in another operating environment, hardware configuration, or software system environment. (3) The ease with which a system, component, data, or user can be transferred from one hardware or software environment to another." "Interoperability — (1) The ability of two or more systems or components to exchange and use information. (2) The ability of systems to provide and receive services from other systems and to use the services so interchanged to enable them to operate effectively together. " В данной работе намеренно не рассматриваются в подробностях методы построения, функционирования, управления вычислительными сетями и технологии передачи данных, так как этот вопрос представляет из себя отдельную, довольно обширную отрасль информационных технологий. Здесь вычислительные сети затрагиваются только с точки зрения предоставляемых системам и приложениям сетевых сервисов.

Хорошим руководством по теоретическим основам сетей передачи данных — нижнему уровню сетевых сервисов распределённых систем обработки данных - является книга [I]. В ней, в частности, рассматриваются вопросы многоуровневой архитектуры вычислительных сетей, управление каналами передачи данных, моделирование задержек в сетях передачи данных, методы доступа к среде передачи, маршрутизация, управление потоками. Теоретические основы организации локальных сетей рассматриваются в [4], основные стандарты по локальным сетям можно найти в [5].

Глава 3. ОСНОВНЫЕ МОДЕЛИ ОТКРЫТЫХ СИСТЕМ И ИХ РАЗВИТИЕ 3.1. Классификация моделей Появление очень большого числа стандартов в различных областях информационных технологий привело к необходимости систематизации их в абстрактных логических моделях, отображающих структуру информационной системы на более высоком уровне, облегчающих классификацию, размещение и применение стандартов. Данные модели не имеют целью подробную структуризацию всей информационной системы. Скорее, их задача — выявить принципы архитектурного построения системного и прикладного программного обеспечения и его размещения по аппаратным компонентам системы обработки данных. Аппаратура при этом выступает в качестве своеобразного "фона", "ячеек" для размещения программного обеспечения. Строгой классификации указанных моделей не существует, но различают несколько основных их видов: • Профиль. Отличается высокой точностью описания, фокусируется на подмножестве взаимосвязанных стандартов или архитектур. • Архитектура. Характеризуется очень высокой точностью описания всех концепций, отсутствием двусмысленностей, хорошо специфицированными описаниями сервисов и механизмов их реализации (за исключением деталей реализации). • Каркасная модель (framework). Имеют более низкую точность, описывают только общие концепции, не содержат подробных объяснений и детальных спецификаций. Этим понятием часто обозначаются модели высокой степени абстракции, описывающие общие соглашения, понятия и методы формирования более конкретных моделей. Часто вместо наименования "логическая модель" используют понятие "структура", означающее совокупность базовых концепций, кратких описаний сервисов, стандартов и интерфейсов, имеющих общую цель, и некоторые детали их реализации. По предмету описания модели можно подразделить на несколько категорий: модели систем, модели процессов, модели информационного наполнения. Некоторые документы объединяют в себе модели различных категорий в целях построения единого взгляда на предмет. Есть несколько типов организаций, создающих такие модели. Во-первых, это организации, занимающиеся разработкой стандартов де-юре и де-факто, во-вторых, это организации и ассоциации пользователей и, в-третьих, это крупные фирмы - разработчики и производители решений в области информационных технологий. Исторически модели появлялись в обратном порядке: сначала модели различных фирм, а затем уже, как правило, стандарты — результат их обобщения и достигнутых соглашений.

Рис. 7. Классификация моделей открытых систем

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

це 80-х гг., с развитием распределённой модели вычислений, различными фирмами и организациями предпринимаются попытки оформить достигнутый уровень понимания структуры и функций распределённых вычислительных систем в абстрактных моделях. Результатом явилось создание ряда независимых моделей, различающихся степенью детализации структуры систем, диапазоном охвата и пр., в различной степени совместимых (или несовместимых) между собой. Представителями этой "волны" являются модели SAA (System Application Architecture) фирмы IBM, ISO OSI, DNA/NAS фирмы DEC, CAE организации X/Open, Atlas организации Unix International. Некоторые из них оказались не очень удачными, другие, такие как модель OSI, оказали мощное влияние на всё дальнейшее развитие концепции открытых систем. Наконец, следующий этап (90-е гг.) характеризуется стремлением построить универсальные модели, систематически обеспечивающие совместимость различных архитектур и формирование открытой среды информационных технологий. Примерами могут служить модели POSIX OSE, XDCS, Networking Blueprint и Open Blueprint фирмы IBM. Для характеристики существующих на сегодняшний день моделей их удобно подразделить на несколько классов (рис. 7) согласно предмету описания и охватываемому ими диапазону (в качестве основы для классификации выбрана модель POSIX OSE, использовавшаяся в гл. 2.): • Структуры, описывающие операционные системы (operating system structures) — это спецификации, созданные преимущественно с целью обеспечения переносимости приложений между различными аппаратными платформами. Примерами таких структур являются OSF/1 и UNIX System V Release 4 (SVR4). • Коммуникационные архитектуры (communications architectures). Основной их целью является описание порядка обеспечения способности к взаимодействию между системами. Коммуникационные архитектуры предоставляют формальное определение многоуровневой модели взаимодействия вычислительных систем (см. п. 2.3) и определяют стандарты протоколов для каждого уровня. Примерами являются архитектуры OSI, SNA, DNA. • Каркасные модели сред (environment frameworks). Эти модели охватывают аспекты переносимости и способности к взаимодействию одновременно, т.е. полностью специфицируют среду открытых систем. Однако, в общем случае, они не специфицируют взаимосвязи между модулями каркасной модели. Они могут рассматриваться как общие профили вычислительных платформ (АР), так как описывают совокупность общих сервисов и средств управления ресурсами системы и определяют стандарты, которым вычислительные системы должны соответствовать, чтобы считаться открытыми. Примерами таких моделей могут служить модель САЕ организации Х/Ореn и модель AES организации OSF. • Каркасные модели распределённых систем (distributed systems frameworks). Это модели, которые также обеспечивают и переносимость, и способность к взаимодействию одновременно, но они не только описывают "каркас" из модулей, но и специфицируют связи между ними. Часто они предоставляют альтернативные подходы по включению того или иного модуля в "каркас". Заметим, что эти модели являются надмножествами коммуникационных архитектур в том смысле, что полностью включают их в себя. Примерами таких моделей могут служить модель XDCS организации Х/Ореn, модель Atlas организации Unix International, модель Open Blueprint фирмы IBM, модель OSF DCE. • Развитие и усложнение последнего типа моделей привело к попыткам создания обобщённых моделей открытых распределённых вычислений. К ним можно отнести модели высокой степени абстракции, формально описывающие структуру и функционирование распределённых систем, формулирующие основные принципы синтеза, анализа и управления открытыми распределёнными системами обработки данных, наборы стандартов и компонентов для конструирования архитектур систем. Указанные модели являются дальнейшим обобщением трёх основных видов логических моделей: профилей, архитектур и каркасных моделей. Модели предыдущего поколения описывали системы масштаба предприятия, но обобщённые модели идут дальше — они универсальны. Они описывают эталон абстрактной информационной системы любого уровня: от локальной до глобальной, всемирного масштаба. Примерами таких моделей являются модель RM-ODP, разработанная ISO и ITU, модель TAFIM Министерства обороны США, модель TOGAF организации The Open Group, модель SPIRIT Platform Blueprint органи-

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

3.2. Базовые стандартные модели 3.2.1. Модель ISO OSI Модель OSI (Open Systems Interconnection) является классическим примером коммуникационной архитектуры. Она определяет семиуровневую модель взаимодействия вычислительных систем. Модель OSI — старейшая из моделей открытых систем. Модель изложена в стандарте ISO 7498, состоящем из четырёх частей: • ISO/IEC 7498-1:1994 Information technology - Open Systems Interconnection — Basic Reference Model: The Basic Model; • ISO/IEC 7498-2:1989 Information processing systems — Open Systems Interconnection — Basic Reference Model — Part 2: Security Architecture; • ISO/IEC 7498-3:1997 Information technology - Open Systems Interconnection - Basic Reference Model: Naming and addressing; • ISO/IEC 7498-4:1989 Information processing systems — Open Systems Interconnection — Basic Reference Model — Part 4: Management framework. В первой части стандарта определяется базовая нормативная модель (reference model) взаимодействия открытых систем, остальные три части определяют модели безопасности (часть 2), управления (часть 4), именования и адресации (часть 3) в среде открытых систем. На разработку модели OSI оказали влияние уже существовавшие многоуровневые модели, такие как SNA и DNA. Выделение в модели именно семи уровней и разделение функций между ними было до некоторой степени произвольным. Оно явилось попыткой найти оптимальное соотношение между противоречивыми требованиями простоты модели и сложности описываемой структуры и стало "опорной точкой" в формировании сетевых архитектур и определении функций вычислительных сетей. Архитектура OSI довольно абстрактна и охватывает очень широкий круг аспектов: общие принципы взаимодействия открытых систем, описание каждого из семи уровней, оборудование. Модель оперирует элементами архитектуры: системы, уровни, логические объекты, сервисы, протоколы, блоки данных, соединения и определяет общие взаимоотношения между этими элементами.

Рис. 8. Модель взаимосвязи открытых систем OSI

Каждый уровень модели OSI (рис. 8) представляет собой группу взаимосвязанных функций обработки данных и связи между системами, которые могут быть выполнены стандартным образом с целью поддержки различных приложений. Каждый уровень обеспечивает хорошо определённый набор сервисов для вышележащего уровня и, в свою очередь, использует сервисы уровня, находящегося ниже его. Таким образом, процесс осуществления связи между системами разбивается на отдельные, легко управляемые блоки. Все вместе семь уровней обеспечивают коммуникационный сервис между оконечными пользователями (end-to-end). Изменения в протоколе любого уровня могут быть выполнены, не затрагивая соседних уровней. Стандартизация взаимосвязи открытых систем проявляется в том, что на каждом уровне разрабатываются и утверждаются базовые стандарты двух видов: • определение сервиса уровня, которое в абстрактной форме описывает доступные извне услуги данного уровня; • спецификация протокола уровня, которая регламентирует взаимодействие между равноправными объектами уровня, направленное на выполнение требуемого сервиса. Верхние уровни модели связаны с логическими аспектами коммуникаций и ориентированы скорее на пользователей сети (обычно это — прикладные программы), чем на саму инфраструктуру сети. Эти уровни включают механизмы для координации диалога между приложениями и для подготовки данных с целью обеспечения единой интерпретации их сторонами. Приложения могут иметь доступ к функциям этих уровней через соответствующие сервисы. Основные функции верхних уровней — следующие: • Прикладной уровень (уровень 7) обеспечивает приложения необходимым высокоуровневым интерфейсом к нижележащим коммуникационным сервисам с целью обеспечения их связи с приложениями-партнёрами на других системах. К прикладному уровню также принято относить набор специализированных сервисов-приложений, таких как передача файлов, управление сообщениями, виртуальный терминал, директориальный сервис и др. Этими сервисами могут, в свою очередь, пользоваться приложения конечного пользователя. В рамках сервисов, стандартизированных ISO, к ним относятся стандарты FTAM, X.400, VT, X.500. Сами приложения пользователя считаются расположенными над прикладным уровнем. • Уровень представления данных (уровень 6) предназначен для согласования синтаксиса и семантики данных для использования в процессе передачи данных между системами. • Сеансовый уровень (уровень 5) обеспечивает сервисы координации диалога между системами: синхронизацию, полномочия, активности. Нижние уровни обеспечивают транспортные функции сети: они ответственны за физические аспекты коммуникаций и доставку данных между оконечными транспортными пользо-

вателями. Основные функции нижних уровней заключаются в следующем: • Транспортный уровень (уровень 4) обеспечивает надёжную и эффективную доставку данных между любыми двумя абонентами потенциально ненадёжной сети передачи данных, независимо от характеристик и топологии сети. • Сетевой уровень (уровень 3) обеспечивает адресацию и маршрутизацию сообщений между системами, которые непосредственно не связаны друг с другом в сети. Модули данных на этом уровне обычно носят название "пакеты" или "дейтаграммы". • Уровень звена данных (уровень 2) связан с обменом неструктурированными данными между смежными узлами сети. На этом уровне происходит обмен модулями данных — фреймами — и обеспечивается обнаружение и исправление ошибок передачи. • Физический уровень (уровень 1) предоставляет физическое соединение для передачи данных: среду распространения сигнала, интерфейсы, процедуры передачи сигналов по линии связи. Уровни модели OSI можно сгруппировать в две категории, соответствующие понятиям "транспортный провайдер" (уровни 1 — 4) и "транспортный пользователь" (уровни 5 — 7) — см. п. 2.3. Первая версия нормативной модели OSI была принята в качестве стандарта в 1983 г., но и сегодня она имеет важное влияние на развитие концепции открытых систем, так как явилась первой попыткой формирования единого монолитного стека протоколов, который обеспечил бы универсальное взаимодействие всего спектра существующих вычислительных систем. Появление модели OSI послужило толчком к быстрому росту числа изделии и продуктов информационных технологий, согласующихся с концепцией открытых систем. Она стала основой разработки очень большого числа стандартов (как де-юре, так и де-факто), относящихся ко всем семи уровням этой модели. На любом национальном рынке крупнейшим потребителем информационных технологий наряду с крупными корпорациями часто является правительство государства. Стремление правительств обеспечить соответствие продуктов и изделий информационных технологий, приобретаемых различными подразделениями правительственных органов, текущим международным стандартам по взаимодействию открытых систем и тем самым обеспечить по меньшей мере некоторую гарантию их совместной работы обусловило появление правительственных профилей взаимосвязи открытых систем. Среди правительственных профилей наиболее широко известны профили GOSIP (Government OSI Profile) Великобритании и США. GOSIP США стал обязательным стандартом в этой стране в 1990 г., после чего почти каждый основной поставщик продуктов и услуг информационных технологий в США объявил о наличии совместимых с GOSIP изделий: локальных и глобальных вычислительных сетей, реализации систем обработки сообщений, передачи файлов и т.д. Свои собственные профили создали Франция, Швеция, Япония, Австралия, Гонконг, многие другие страны. Значительная часть работ по стандартизации Госпрофиля России взаимосвязи открытых систем была проведена в 1995 — 99гг. Следующий международный стандарт устанавливает общую классификацию, принципы построения и документирования профилей: • ISO/IEC TR 10000-1:1998 — Information technology -- Framework and taxonomy of International Standardized Profiles - Part 1: General principles and documentation framework — общая часть стандарта; • ISO/IEC TR 10000-2:1998 — Information technology - Framework and taxonomy of International Standardized Profiles — Part 2: Principles and Taxonomy for OSI Profiles — устанавливает принципы построения и классификацию профилей, создаваемых в рамках модели взаимосвязи открытых систем OSI; • ISO/IEC TR 10000-3:1998 — Information technology - Framework and taxonomy of International Standardized Profiles - Part 3: Principles and Taxonomy for Open System Environment Profiles — устанавливает принципы построения и классификацию профилей, создаваемых в рамках модели сред открытых систем OSE (сп. п. 3.2.2). Профили стандартов на основе модели OSI, безусловно, являются очень важным этапом развития стандартизации открытых систем. Однако профили дают несколько "однобокий"

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

3.2.2. Модель POSIX OSE Исторически модель POSIX развивалась от разработки интерфейса переносимой операционной системы через разработку профилей операционных сред до формулировки модели полноценной среды открытых систем, которая и получила название OSE (Open Systems Environment). Первая рабочая группа POSIX была образована в IEEE в 1985 г. на основе комитета по стандартизации операционных систем, ориентированного на ОС UNIX. Первоначально POSIX (Portable Operating System Interface for Computer Environments) — набор спецификаций для открытых систем, разработанный Техническим Комитетом по операционным системам (TCOS) IEEE. Цель POSIX— выработка спецификаций единого, унифицированного, широко поддерживаемого производителями интерфейса для операционных систем, обладающих свойствами переносимости между ними приложений, пользователей и данных. POSIX составляет большой набор документов, разрабатываемых множеством рабочих групп и комитетов. Основной набор соглашений и концепций для этих спецификаций сформулирован в документе IEEE "Guide to the POSIX Open Systems Environment, P1003.0". Он утверждён в качестве международных стандартов: • ISO/IEC 9945-1:1996 — Information technology - Portable Operating System Interface (POSIX) — Part 1: System Application Program Interface (API) [C Language]; • ISO/IEC 9945-2:1993 — Information technology -- Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities. Co временем число рабочих групп POSIX возросло до 18, а их тематика расширилась, охватив все операционные среды, интерфейсы которых соответствовали спецификациям POSIX. Задача рабочих групп трансформировалась в создание профилей различных сред: коммуникационных систем, систем реального масштаба времени, многопроцессорной обработки, суперкомпьютеров, а также отдельных функций этих систем: защита информации, прозрачный доступ к файлам, именование ресурсов, директориальные сервисы и т.д. Некоторые результаты их работы утверждены в качестве официальных международных стандартов: • ISO/IEC 14519:1999 — Information technology - POSIX Ada Language Interfaces — Binding for System Application Program Interface (API) — Realtime Extensions; • ISO/IEC 15068-2:1999 — Information technology - Portable Operating System Interface (POSIX) System Administration - Part 2: Software Administration. Осмысление единства различных сторон разрабатываемой проблемы привело в итоге к формулировке единой нормативной модели (функциональной) среды открытых систем, известной как OSE (POSIX Open System Environment Reference Model). Эта модель описана с точки зрения пользователя. Она является довольно простой, но ясно определяет основные компоненты систем обработки данных и основные концепции формирования открытой среды. Быть может, главное преимущество этой модели состоит в том, что она позволяет легко классифицировать стандарты по открытым системам по двум категориям: либо как интерфейсы (форматы) и протоколы, либо как спецификации, относящиеся к переносимости или способности к взаимодействию. Модель OSE не является уровневой (рис. 9). Она определяет три категории логических объектов: прикладное ПО (Application Software — AS), платформу приложений (Application Platform — АР) и внешнюю среду (External Environment — ЕЕ) — и два типа интерфейсов между ними: интерфейсы прикладного программирования (Application Programming Interface — API) и интерфейсы внешней среды (External Environment Interface — EEI). Рассмотрим более подробно существо каждого из этих понятий модели. Прикладное ПО — это часть программного обеспечения системы, специфичная для конкретного применения пользователя. Она составляется из программ (исполняемых модулей, ко-

мандных файлов, интерпретируемых записей исходного кода и пр.), данных (рабочих данных пользователя, параметров приложений, установок среды экрана пользователя и пр.) и электронной документации (электронных документов, справок помощи (on-line help) и пр., но бумажная документация сюда не включается). Примерами прикладного ПО являются текстовые редакторы, программы работы с электронными таблицами, программы обработки информации, хранящейся в базах данных, и многие другие программы, являющиеся специфически пользовательскими по отношению к той или иной платформе. Разработка, интерпретация и исполнение некоторых специальных видов прикладного ПО может осуществляться при посредстве специализированных сред, обеспечивающих определённый вид сервиса на платформе, например, системы управления базами данных (СУБД), системы автоматизированного проектирования (САПР), системы управления электронными таблицами и т.п. Одно или более приложений могут работать на одной платформе одновременно, так как каждое приложение трактуется как независимый логический объект. Платформа приложений — это все остальные элементы системы обработки данных, за исключением прикладного ПО: аппаратное обеспечение, операционная система и другие компоненты и подсистемы системного ПО. Приложения, требующие ресурсов платформы, запрашивают их путём вызова сервисов через API. Ресурсы, находящиеся вне платформы, запрашивают сервисы через EEI, и наоборот, EEI являются средствами, через которые сервисы достигают ресурсов внешней среды. Внутренняя структура платформы в модели OSE преднамеренно не рассматривается. Это связано с тем, что в научных и промышленных кругах не существует единого мнения о составе, структуре и взаимосвязях различных модулей платформы. Внешняя среда — это все компоненты информационной системы, находящиеся за пределами данной системы обработки данных: пользователи, коммуникационные каналы и средства связи, сменные носители данных, устройства ввода /вывода. Интерфейс между АР и ЕЕ включает форматы данных, интерфейсы и протоколы. По отношению к отдельно взятой вычислительной системе все другие вычислительные системы также выступают как объекты внешней среды. Модель POSIX OSE определяет распределённую среду как множество платформ приложений, которые могут взаимодействовать посредством коммуникационных механизмов, внешних по отношению к платформам. Когда приложению необходимо связаться с другим приложением на другой прикладной платформе, приложение подаёт запросы к своей локальной платформе через API. Так как АР взаимодействуют через коммуникационный интерфейс EEI, локальная АР транслирует эти запросы в соответствующие действия через EEI. OSE также определяет однородный набор стандартных сервисов, предоставляемых пользователям платформ, в соответствии с требованиями спецификаций POSIX о переносимости и способности к взаимодействию. Данная модель делает попытку описать более полный подход к совместимости вычислительных систем, чем подход, основанный на многоуровневых архитектурах типа модели OSI. Модель принята в качестве международного стандарта ISO/IEC TR 14252:1996 — Information technology - Guide to the POSIX Open System Environment (OSE). Классификация профилей, которые могут быть построены в рамках модели OSE, определена в стандарте ISO/IEC 10000 3.

Рис. 9. Модель POSIX OSE

Для информационных нужд правительства США был создан профиль на основе модели OSE, который получил название профиля переносимости прикладных программ (Application Portability Profile). Он изложен в документе: Application Portability Profile. The U.S. Government Open Systems Environment Profile. Ver. 3.0. NIST Special Publication 500-230, 1996. Важное значение модели OSE состоит также в том, что она, очень удачно сформулировав основы концепции открытых систем, явилась базой для создания многих последующих моделей открытых систем.

3.3. Модели сред открытых систем Если вычислительные системы полностью соответствуют спецификации POSIX 1003.1, это ещё не означает, что они образуют полноценную среду открытых систем с адекватным набором сервисов и интерфейсов, которая может служить готовой базой для построения решений для потребителя. Модели сред открытых систем обращаются к проблеме построения открытой системы в комплексе. Примерами моделей, которые специфицируют полную среду открытых систем, являются модель САЕ (Common Application Environment) организации Х/Ореn и модель AES (Application Environment Specification) организации OSF. По сути дела модели сред открытых систем являются профилями вычислительных платформ, претендующих на наименование "открытой системы". Каждая из моделей определяет набор общих сервисов и средств управления ресурсами для платформ и специфицирует стандарты, которым они должны следовать для того, чтобы соответствовать профилю открытой системы. • Модель САЕ (рис. 10) описана в документе XPG, разрабатывавшемся организацией Х/Ореn с 1984 г. Первая версия документа (XPG3) появилась в 1989 г., вторая версия (XPG4) — в 1992 г., последняя редакция документа— XPG5. Графическое изображение модели достаточно условно и схематично, основную часть документа составляют спецификации. Впоследствии модель САЕ и спецификации XPG стали частью большого проекта организации The Open Group по выработке единой стандартной спецификации для всех операционных систем семейства UNIX и критериев оценки на соответствие ОС этим спецификациям (т.е. оценки того, является ли ОС «настоящей UNIX» или нет), который получил название Single UNIX. Наименование документа первоначально расшифровывалось как Х/Ореn Portability Guide, но позднее такую трактовку названия было рекомендовано не использовать, так как содержание документа вышло за рамки проблемы обеспечения переносимости, а аббревиатура сохранена только в качестве идентификатора документа. XPG и его компоненты разработаны

на основе кооперации и консенсуса между организациями пользователей, поставщиками вычислительных систем, организациями по стандартизации. Он включает спецификации, основанные как на стандартах де-юре, так и на стандартах де-факто. XPG3 — семитомный документ, специфицирующий следующие компоненты системы: команды и утилиты, набор системных вызовов, язык программирования С, интерфейсы терминала, управление оконным интерфейсом, язык манипулирования данными SQL, языки программирования COBOL, FORTRAN, Pascal, Ada, транспортные интерфейсы и др. Кроме того, организация Х/Ореn предусмотрела сертификацию программного обеспечения вычислительных платформ на соответствие спецификации XPG. Предусмотрено три уровня сертификации: • Уровень BASE BRAND означает, что система прошла верификацию на наличие всех обязательных свойств операционной среды по трём спецификациям: команды и утилиты, набор системных вызовов, язык программирования С. • Индивидуальная оценка компонентов на уровень соответствия, например, языков программирования. • Уровень PLUS BRAND означает полное соответствие с уровнем BASE BRAND и наличие всех дополнительных необязательных компонент. XPG4 — пятитомный набор спецификаций и требований по сертификации систем на соответствие этим спецификациям, значительно более подробный по сравнению с документом XPG3. В документ включено много новых спецификаций по реляционным базам данных, поддержке спецификаций XWindow, директориальному сервису, сетевым файловым системам, системам управления сообщениями на основе стандартов серии Х.400, обработке транзакций и др. Все компоненты объединены в восемь функциональных групп: операционные системы и языки программирования, управление данными, пользовательский интерфейс, общие средства межсетевого взаимодействия, средства взаимодействия с мэйнфреймами, средства взаимодействия с персональными системами, носители данных, дополнительные компоненты.

Рис. 10. Модель САЕ

Проект Single UNIX - дальнейшее развитие предыдущих спецификаций и принципов сертификации вычислительных платформ. Как известно, UNIX-подобные операционные системы существуют в большом количестве реализации, созданных разными фирмами и университетами из разных стран, что ослабляет совместимость платформ приложений на основе этих ОС и ставит вопрос о том, какие именно версии UNIX-подобных ОС считать истинной ОС UNIX. Он поддерживается многими производителями программного обеспечения. Цель этого проекта создание архитектуры и спецификаций интерфейсов для «единого UNIX''a». Действующей версией документа является спецификация UNIX 98 (версия 2). Выход версии 3 этого документа намечен на 2001 г. • Модель AES первоначально преимущественно была связана с определением среды, поддерживающей переносимость приложений. Модель идентифицирует внутри среды откры-

тых систем шесть функциональных областей: операционные системы, сервисы среды пользователя, сетевые сервисы, сервисы графики, сервисы управления базами данных, языки программирования. Чтобы соответствовать спецификациям AES, система должна иметь интерфейсы, перечисленные в информационной базе модели. Модель основывается преимущественно на стандартах организаций ISO, IEEE, ANSI: • по операционным системам — стандарты POSIX, XPG BASE BRAND; • по сервисам среды пользователя — спецификации Х Window, OSF/Motif; • по сетевым сервисам — избранные сервисы ARPA/BSD, протоколы TCP, IP, SMTP, TELNET, FTP, некоторые протоколы OSI; • по сервисам графики — стандарты GKS, PHIGS; • по сервисам управления базами данных — язык SQL; • по языкам программирования — Ada, BASIC, С, COBOL, FORTRAN, LISP, Pascal. Модели XPG и AES не являются конкурирующими, хотя их содержание во многом идентично. Позднее модель AES фактически стала рассматриваться почти как подмножество спецификаций XPG. Основная роль рассмотренных моделей на сегодняшний день заключается в том, что они послужили важной отправной точкой для разработки в рамках объединённой организации The Open Group более совершенных моделей открытых распределённых вычислений, в которых была достигнута большая степень обобщения и выработана современная точка зрения на проблему организации таких систем.

3.4. Модели распределённых систем Основная цель организации распределённой системы обработки данных, как было установлено в п. 2.1,— формирование образа единой системы для любого пользователя и любого приложения системы с консистентным набором API и EEI к сервисам распределённой системы. Эти сервисы слишком обширны и многочисленны, чтобы их можно было реализовать в одном компоненте распределённой системы. Следовательно, система должна иметь модульную структуру. Для того чтобы специфицировать компоненты распределённой системы и взаимосвязи между ними, создаются каркасные модели распределённых систем. Компоненты такой модели носят название "менеджеры ресурсов", или "сервисные модули". (Модели распределённых систем, как правило, оперируют абстрактными понятиями высокого уровня, не связанными с технической реализацией компонентов в вычислительных системах.) Один или несколько взаимосвязанных и взаимодействующих менеджеров ресурсов обеспечивают реализацию сервисов, которые распределённая система предоставляет через API и EEI. Иными словами, данный класс моделей описывает внутреннюю структуру компонента "сервисы распределённой системы" на рис. 5. Приложения и пользователи не ощущают физического расположения ресурсов системы, и это качество сохраняется независимо от составляющего систему аппаратного, программного обеспечения и сетей передачи данных. Это делает возможным построение такой системы обработки данных, в которой ресурсы, сервисы, менеджеры ресурсов и элементы приложений были бы распределены между отдельными вычислительными системами и в полной мере использовали преимущества каждой отдельной системы. Модели распределённых систем являются надмножествами коммуникационных архитектур в том смысле, что последние полностью включаются в них. Но, в отличие от архитектур, модели распределённых систем определяют не просто форматы и протоколы, но также API, обеспечивающие переносимость и способность к взаимодействию. Кроме того, модели по сравнению с коммуникационными архитектурами проводят более чёткую границу между функциями транспортного провайдера и транспортного пользователя, так как выделяют их в различные компоненты. Некоторые модели предоставляют возможности выбора коммуникационных архитектур. Особенность каркасных моделей распределённых систем заключается в том, что они не вводят новых стандартов, а, подобно профилям, пользуются набором уже существующих стандартов де-юре и де-факто и определяют взаимосвязи между ними. • Модель XDCS (X/Open Distributed Computing Services) опубликована в 1992 — 93 гг., за основу для неё взяты спецификации XPG. Основная цель — описать распределённую среду

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

Рис. 11. Модель XDCS

Каждый из четырёх уровней сервисов имеет множество компонент, которые отображают менеджеры ресурсов, обеспечивающие сервисы определённого типа. Сервисы операционной системы. Их назначение — обеспечить на каждой платформе распределённой системы единообразную базу для формирования среды открытых систем в виде единого набора системных интерфейсов, команд и утилит. Модель поддерживает спецификации XSH, POSIX.l, POSIX.2. Коммуникационные сервисы служат для обеспечения надёжной, не зависящей от технической реализации сетей, связи между узлами в распределённой системе, позволяющей приложениям обмениваться данными независимо от сетевых протоколов, форматов, топологии сети и коммуникационного оборудования. Коммуникационные сервисы включают два компонента: сетевые сервисы и сервисы межпроцессного взаимодействия. Модель поддерживает две коммуникационные архитектуры: OSI и ТСРЛР, а также API для доступа к соответствующим протоколам: X/Open XTI и ХАР. Сервисы распределения обеспечивают для системного и прикладного ПО базовый набор сервисов по поддержке функций распределённой среды, которые не могут быть достигнуты с использованием сервисов операционной системы и коммуникационных сервисов. Это механизмы защиты, административного управления системами, синхронизации времени и директориальный сервис. Они существенно отличаются от аналогичных, поддерживаемых локальными системами в отдельности. Прикладные сервисы предоставляют поддержку для разработки распределённого прикладного ПО. В эту группу входят: • распределённые файловые сервисы: поддерживаются стандарты NFS, DFS, XFTAM; • сервисы управления сообщениями: поддерживаются стандарты Х.400, XMHS;

• сервисы обработки транзакций: поддерживаются стандарты ТХ, ХА; • сервисы управления данными: поддерживаются стандарты X-ISAM, SQL, RDA, X-SAG; • сервисы оконного интерфейса: поддерживается спецификация XWindows. Понятия "качеств сервисов" относятся ко всем четырём уровням сервисов. Они включают такие категории как безопасность, доступность, управляемость и интернационализация. XDCS — это каркасная модель. Она не специфицирует конкретные технологии и продукты, реализующие их, не поддерживает никаких конкретных производителей вычислительных систем, не требует никакой конкретной операционной системы. • Модель UNIX International's Atlas в настоящее время не имеет практического значения и представляет лишь исторический интерес. Так, именно при разработке этой модели было сформулировано положение о том, что ни один производитель не может за приемлемую цену снабдить потребителя всеми элементами системы обработки данных. Кроме того, она послужила базисом для модели XDCS. Однако графическое представление модели Atlas (рис. 12) заметно отличается от модели XDCS. Модель в основном опирается на технологические решения, принятые в семействе UNIX-подобных операционных систем. Модель имеет многоуровневую структуру. Внутри каждого из уровней находятся сервисные компоненты. Atlas специфицирует стандарты для компонент, а для некоторых из них — и конкретные технологии или продукты. Эти технологии не предполагают полного исключения других возможных реализации тех же сервисов, а скорее служат руководством. Уровни модели включают следующие сервисы: • Базовые сервисы операционной системы обеспечивают возможность интеграции основных версий операционной системы UNIX при условии обратной совместимости с предыдущими версиями этой операционной системы. Базовыми технологиями для реализации сервиса выбраны UNIX System V Release 4.1 ES с расширенными функциями защиты данных и UNIX System V Release 4.0 MP с поддержкой мультипроцессирования. • Коммуникационные сервисы включают поддержку коммуникационных архитектур OSI и ТСР/IР. • Системные сервисы обеспечивают единообразие, требуемое в распределённой среде, и аналогичны соответствующим сервисам XDCS. • Сервисы приложений обеспечивают поддержку для распределённых приложений. В качестве базовых технологий выбраны сетевая файловая система SunSoft NFS для файловых сервисов и USL Tuxedo для обработки транзакций. • Сервисы защиты включают аутентификацию на базе технологии Kerberos, шифрование, контроль доступа и др. • Сервисы межсистемного взаимодействия. Их цель — обеспечить способность к взаимодействию между различными системами и коммуникационными архитектурами. • Прикладные инструменты. Это средства для разработки прикладного ПО, такие как средства автоматизации разработки (CASE-системы), языки программирования.

Рис. 12. Модель UI-Atlas

• Модель IBM Open Blueprint стала основой стратегии фирмы IBM по построению открытой распределённой среды. Это глубоко продуманная и исключительно тщательно разработанная логическая модель. Она представляет собой итог важного этапа поиска подходов к организации распределённых сред. Структура Open Blueprint позволяет сети различных систем функционировать как единый модуль, как распределённая операционная система. Локальная система рассматривается как часть распределённой сети, а сеть рассматривается как единая система. Распределенная вычислительная система состоит из множества систем, соединённых друг с другом и взаимодействующих между собой через сеть. Сервисы на каждой системе управляют ресурсами совместно через сеть таким же образом, как обычная операционная система управляет ресурсами отдельной вычислительной системы. Каждый узел в сети может быть структурирован в соответствии с моделью Open Blueprint. Каждый сервис на конкретной вычислительной системе должен быть доступен приложениям со всех остальных вычислительных систем. Эквивалентные сервисы на каждой локальной системе работают совместно для поддержки общей распределённой сетевой среды. Для соответствия требованиям открытости компоненты модели Open Blueprint должны строго придерживаться стандартов при разработке элементов API, форматов и протоколов, которые позволяют различным программам выполняться на одних и тех же или разных вычислительных системах для совместной работы. Основной структурный элемент Open Blueprint — менеджер ресурсов — набор программ, которые определяют состояние, управляют и обеспечивающих доступ к некоторому набору ресурсов. Управление ресурсами — это логическая концепция. Менеджеры ресурсов предоставляют набор интерфейсов, в том числе API, через которые могут быть выполнены операции над их ресурсами. Примерами менеджеров ресурсов являются файловая система, сервер печати, менеджер баз данных и др. Управляемые ресурсы могут быть распределены среди множества серверов в гетерогенной сети. Менеджеры ресурсов подразделяются на локальные и распределённые. Локальный менеджер ресурсов - это менеджер, управляющий ресурсами, размещёнными на конкретной, единичной системе в сети. Распределённый менеджер ресурсов взаимодействует со многими системами. Он включает в себя клиентскую часть, которая поддерживает интерфейсы, используемые для запроса сервиса, и серверную часть, которая выполняет операции над ресурсами, необходимые клиентской части. Работа распределенного менеджера ресурсов представляет собой взаимодействие клиентской и серверной частей. Клиентская часть может выполнять некоторые вычисления и может определять, какая часть сервера должна обслуживать запрос, под-

держивает множество протоколов, необходимых для работы в гетерогенной среде. Серверная часть может обрабатывать запрос самостоятельно или передавать его другому менеджеру ресурсов. Клиентская и серверная части взаимодействуют посредством определенных протоколов, использующих сервисы модели Open Blueprint. Приложения, поддерживаемые системой, могут быть сконфигурированы так, что будут содержать только клиентские части распределённого менеджера ресурсов (обычная конфигурация рабочей станции конечного пользователя). Менеджеры ресурсов могут быть объединены в наборы, которые и будут поддерживать гетерогенные среды. Причем любой из менеджеров ресурсов в наборах может быть заменен без изменения в программах, которые его используют. Сервисы модели сгруппированы в несколько классов и функционально разделены по нескольким уровням (рис. 13): • нижний уровень — сетевые сервисы — включает: физическую сеть, сигнальную и управляющую систему сети, предназначенную для управления работой соединений в сети, транспортную систему, которая обеспечивает поддержку протоколов для передачи информации от одной системы к другой, таких как TCP/IP, SNA/APPN, NETBIOS, IPX, интерфейс CTS (Common Transport Semantics) как средство организации гетерогенных сетей; • средний уровень — сервисы распределенной системы — включает коммуникационные сервисы (communication services) для создания и поддержки механизмов взаимодействия частей распределённых приложений, сервисы управления объектами (object management services) для управления локальными и удаленными объектами в гетерогенной среде, распределённые сервисы (distribution services): директориальный, сервис управления транзакциями, сервис времени и сервис защиты; • верхний уровень — приложения, и сервисы поддержки приложений (application enabling services) — включает сервисы представления (presentation services) — механизмы взаимодействия между пользователями и приложениями, сервисы доступа к данным (data access services), сервисы поддержки приложений и групповой работы (application/workgroup services), средства разработки приложений (development tools). Указанные три группы сервисов распределённой платформы поддерживаются сервисами локальных операционных систем и средствами управления системой. Сервис локальной операционной системы (Local Operating System Services) представляет собой локальный менеджер ресурсов, который поддерживает сервисы распределённого менеджера ресурсов. Локальный менеджер ресурсов предназначен для управления ресурсами на локальной машине, такими как центральный процессор и периферийные устройства. Фактически, операционная система, построенная в соответствии с моделью, будет представлять собой именно такую службу, осуществляя при этом возложенные на нее функции. В соответствии с моделью Open Blueprint служба управления локальной системой должна обеспечивать и поддерживать следующие функции: управление задачами, поддержка и управление конфигурацией, управление системой защиты, управление работой приложений, поддержка работы системных журналов и обработка событий в системе, управление средствами доступа к ресурсам.Средства административного управления системами (Systems Management) обеспечивают и поддерживают механизмы, которые позволяют системным администраторам и автоматизированным процедурам управлять сервисами в распределенной среде.

Рис. 13. Модель Open Blueprint

Для реализации распределённой системы согласно этой модели на практике необходимо выбрать конкретные технологии для каждой функции или компонента в архитектуре. Не существует, однако, взаимно однозначного соответствия между компонентами модели OpenBlueprint и конкретными продуктами. Блоки модели в общем случае содержат множественные компоненты и не относятся к конкретным продуктам. В настоящий момент есть много продуктов корпорации IBM, а также других фирм, которые могут выполнять требуемые функции. • Модель OSF DCE (Distributed Computing Environment) отличается от до сих пор рассматривавшихся моделей распределённых систем. Во-первых, она является более узкой: определяет только набор сервисов, составляющих инфраструктуру для разработки и функционирования гетерогенных распределённых вычислительных сред. Во-вторых, DCE — не только набор спецификаций, но также и программный продукт, реализующий их. Тем самым. DCE является примером "middleware", т.е. прототипом слоя программного обеспечения "среднего уровня", который в уровневой модели находится выше системного ПО локальной системы, но ниже прикладного ПО и обеспечивает функциональность распределённой системы. Большинство других моделей (в том числе XDCS, UI-Atlas, IBM Open Blueprint) включает спецификации DCE для ключевых сервисов распределённой системы: защита информации, время, система именования и директорий. DCE формирует ядро технологий распределённых сервисов в этих моделях. Ценность модели DCE — в том, что в ней был не только чётко сформулирован полный набор распределённых сервисов различных уровней (рис. 14), но и выбраны оптимальные пути их практической реализации в программных продуктах. На самом нижнем уровне DCE обеспечивает механизм управления нитями, позволяющий распараллеливать процессы, вовлекая даже такие системы, которые не поддерживают механизм нитей. Для реализации этого механизма выбрана архитектура СМА (Concert Multi-thread Architecture) фирмы DEC. Для межпроцессного взаимодействия DCE использует вызов удалённых процедур (реализация — NCS (Network Computing System) RPC 2.0 фирмы HewlettPackard). Для обеспечения взаимодействия с другими системами используется механизм sockets. На более высоком уровне располагаются сервисы распределённой системы, которые включают сервис времени, директориальный сервис и сервис именования. В модели выбраны следующие реализации соответствующих сервисов: DECdts (разработка DEC), Dir-X (основанная на Х.500 разработка Siemens-Nixdorf), DECdns (сервис доменных имён, разработанный DEC с добавлениями Массачусетского технологического института). Также предусмотрена возможность включения дрих сервисов в буду-

щем. Чтобы распределённая система могла функционировать в защищённой среде, предусмотрены сервисы защиты, представленные в DCE сервисом аутентификации на основе системы Kerberos v.5, разработанной Массачусетским технологическим институтом с расширениями фирмы Hewlett-Packard. Этот сервис является обязательным компонентом любой среды, построенной по модели DCE. В модели также определён набор необязательных сервисов. Он включает распределённую файловую систему (в пакете выбрана AFS — Andrew File System — разработка Transarc Corp.), поддержку персональных систем и бездисковых рабочих станций. Также предусмотрена возможность добавления в будущем других факультативных возможностей. Сервис административного управления на самом деле не существует как единый блок. Он реализован в форме некоторого набора возможностей управления, включаемых в каждый компонент модели. Модель и поддерживающие её продукты DCE стали стандартом де-факто в промышленности и реализованы на большом количестве платформ с операционными системами MVS, Open VMS, AIX, OS/2, Windows и др.

Рис. 14. Модель OSF DCE

3.5. Обобщённые модели открытых распределённых вычислений 3.5.1. Модель RM-ODP Модель RM-ODP (Reference Model of Open Distributed Processing) — совместное усилие ISO и ITU-T по разработке общей основы для стандартизации открытых распределённых вычислений. Модель изложена в серии стандартов ISO 10746 и эквивалентных им стандартах ITUT из серии Х.900: • ISO/IEC 10746-1:1998 (ITU-T X.901) — Information technology -- Open Distributed Processing — Reference model: Overview; • ISO/IEC 10746-2:1996 (ITU-T X.902) Information technology - Open Distributed Processing — Reference Model: Foundations; • ISO/IEC 10746-3:1996 (ITU-T X.903) Information technology - Open Distributed Processing -- Reference Model: Architecture; • ISO/IEC 10746-4:1998 (ITU-T X.904) Information technology - Open Distributed Processing — Reference Model: Architectural semantics.

Цель этого стандарта — создание каркасной архитектуры для модели открытых распределённых вычислений. Архитектура основывается на точных концепциях, выведенных из существующих разработок различных фирм по распределённой обработке данных и, насколько это возможно, на использовании формальных описательных приёмов. Данный стандарт представляет также интерес как источник терминологии в области открытой распределённой обработки данных. Распределённая обработка данных в стандарте определяется как обработка информации, при которой дискретные компоненты системы обработки данных могут быть размещены в различных местах, причём коммуникации между компонентами могут вносить задержку в обработку или быть ненадёжными. Распределённым системам присущи следующие характеристики: • удалённость — компоненты распределённой системы могут быть "распылены" в пространстве, взаимодействия между ними могут быть либо локальными, либо удалёнными; • параллелизм — любой компонент распределённой системы может быть активен (может выполняться) параллельно с любым другим компонентом; • отсутствие глобального состояния — глобальное состояние распределённой системы не может быть точно зафиксировано и описано; • частичная ненадёжность — любой компонент распределённой системы может отказать независимо от любых других компонентов; • асинхронность — коммуникации и активность процессов не управляются едиными глобальными часами, взаимосвязанные изменения в распределённой системе не обязательно происходят одновременно. Распределённые системы могут пересекать границы организаций и подчиняться различным техническим условиям. Это обычно приводит к отсутствию единого центра управления и, как следствие, придаёт им дополнительные характеристики: • гетерогенность — означает, что нет гарантии, что компоненты распределённой системы строятся, используя одни и те же технологии, причём набор различных технологий может изменяться со временем; • автономность — различные части системы находятся в ведении нескольких (многих) автономных органов контроля и управления, без единой координации между ними; • эволюционность — за период своего жизненного цикла открытая распределённая система обычно сталкивается со многими изменениями, которые вызываются техническим прогрессом, изменением целей деятельности предприятий, новыми типами приложений; • мобильность — источники информации, обрабатывающие узлы, пользователи (и даже их рабочие места) могут быть физически перемещаемы по системе, программы и данные также могут передвигаться между узлами системы. Чтобы отвечать указанным требованиям, стандарты открытой распределённой обработки должны позволять строить системы в соответствии со следующими принципами: • Открытость — свойство, включающее переносимость и способность к взаимодействию (в смысле ранее введённых понятий). • Интегрируемость означает, что различные системы и ресурсы могут внедряться в целую систему без значительных дополнительных затрат и разработок. Это свойство включает, например, возможность интеграции систем с различными архитектурами, различных ресурсов с различной производительностью. Оно направлено на решение проблемы гетерогенности. • Гибкость — свойство поддержки эволюции системы, включая существование и продолжение работы в системе компонентов предыдущих поколений. Гибкость включает в том числе возможность динамической переконфигурации без остановки работы всей системы. Это требование направлено на решение проблемы мобильности. • Модульность — структурное свойство системы, означающее, что части системы автономны, но взаимосвязаны. Это — основа гибкости. • Федеративность — свойство объединяемых систем, находящихся в различных административных и технических доменах, достигать некоторой единой цели. • Управляемость — свойство мониторируемости, возможности контроля и управления ресурсами системы для поддержания определённой её конфигурации, обеспечения качества

сервисов и учётности ресурсов. • Обеспечение качества сервиса — свойство системы отвечать заданному набору требований по качеству предоставляемых пользователям услуг: времени ответа, доступности удалённых ресурсов, надёжности, устойчивости к сбоям и пр. • Безопасность — свойство, гарантирующее, что услуги, предоставляемые системой, и данные, хранящиеся в системе, защищены от неавторизованного доступа. • Прозрачность — свойство маскировать от приложений детали и различия в механизмах: гетерогенность аппаратного и программного обеспечения, расположение и размещение компонентов, механизмы для достижения требуемого качества сервисов в условиях сбоев в системе и др. Оно используется для преодоления проблем, вызванных распределённым характером системы. Средствами реализации указанных принципов в стандарте ISO 10746 названы общие сервисы системы. Принцип их выделения в системе также сформулирован в стандарте: посредством группировки вместе свойств (в смысле предоставляемых ими услуг, полезных качеств — features) различных сервисов каждой вычислительной платформы, входящей в распределённую систему, и достижения соглашений относительно этих свойств гетерогенность распределённой системы может быть структурирована контролируемым образом. Иными словами, все предоставляемые пользователю и приложениям услуги распределённой системы оказываются структурированными по категориям сервисов. Такого же принципа придерживаются и другие модели открытых распределённых вычислений. Стандарт также утверждает, что не может быть создана единая, общая инфраструктура, которая обеспечивает абсолютно все свойства, требуемые от распределённых систем. Таким образом, возникает необходимость выбирать компоненты, которые формируют инфраструктуру, отвечающую требованиям различных видов приложений. Следовательно, необходима также каркасная модель, описывающая компоненты и показывающая их совместную работу. Такой каркас модели RM-ODP может служить базой для разработки других, более детальных стандартов. Понятие "стандарты открытой распределённой обработки данных" (ODP — Open Distributed Processing standards) определяется в ISO 10746 как модель RM-ODP и те стандарты, которые прямо или косвенно согласуются с ним. Открытая распределённая обработка данных (open distributed processing)— распределённая обработка, сконструированная в соответствии со стандартами ODP. Система открытой распределённой обработки данных (ODP system)— система, которая согласуется с требованиями стандартов ODP. Основным содержанием модели RM-ODP является: • разделение спецификации систем открытой распределённой обработки данных на пять так называемых "точек зрения" (viewpoints), упрощающих описание сложных систем; • набор общих средств описания систем с каждой из этих "точек зрения"— так называемые "языки" (languages); • инструментарий для спецификации инфраструктуры распределённых систем через обеспечение так называемой "прозрачностей распределения" (distribution transparencies) — эти качества являются выборочными, для каждой конкретной системы могут достигаться только те из них, которые необходимы; • принципы оценки соответствия систем критериям ODP. Современные распределённые системы обработки данных являются, как правило, сложными системами. Они строятся для решения многоцелевой задачи, включают большое число сложно взаимосвязанных компонент. Полная спецификация распределённой системы может потребовать очень большое количество информации, что не осуществимо на практике. Более того, система сложна настолько, что не может быть описана специалистами одного профиля. Для описания различных аспектов системы используются различные средства, различные языки описания. В соответствии с моделью RM-ODP система открытой распределённой обработки данных может быть описана с пяти "точек зрения": • организационной (enterprise), которая рассматривает систему с точки зрения приклад-

ных целей её деятельности (бизнес-процессов); • информационной, которая рассматривает систему с точки зрения информации, которую необходимо хранить и обрабатывать в системе — этот взгляд интересует аналитика при создании информационного наполнения системы; • вычислительной, которая рассматривает систему как набор объектов, которые взаимодействуют через интерфейсы, т.е. производит функциональную декомпозицию системы; • инженерной, которая рассматривает механизмы, поддерживающие распределённый характер системы — этот взгляд интересует системного программиста; • технологической, которая детально рассматривает компоненты, из которых конструируется распределённая система (аппаратное и программное обеспечение) — этот взгляд необходим системному интегратору при выборе технологий для создания работающей и экономически эффективной системы обработки данных. Дополнительно в модели описываются так называемые "функции ODP". Это собрания функций, требуемых от открытых распределённых систем обработки данных для поддержания нужд инженерной и вычислительной точек зрения. Основные группы функций — следующие: функции управления, координации, обработки транзакций, репликации данных, защиты. Последние делятся на семь групп: функции контроля доступа, аудита, аутентификации, целостности, конфиденциальности, неотказуемости и управления ключами. Они детально рассматриваются в стандарте ISO 10181 — OSI Security Frameworks for Open Systems и стандарте ISO 11770 — Security techniques — Key management. Каждая "точка зрения" — это абстрактный взгляд, который охватывает вся систему в целом. Они должны рассматриваться как "проекции" определённых свойств, определённых сторон единого целого. Все "точки зрения" объединяет единый подход объектного моделирования, описанный в первой части стандарта. Вторая часть стандарта содержит определение концепций и аналитический каркас для нормализованного описания произвольной распределённой системы обработки данных — это описательная модель. Третья часть содержит спецификацию требуемых характеристик, которые квалифицируют распределённые вычисления как открытые, используя для этого методики описания из ч. 2 — это предписательная модель. Часть 4 содержит формализованную концепцию моделирования ODP. Каждая "точка зрения" интерпретируется в терминах различных стандартизованных формальных описательных методик. В этой же части стандарта устанавливается взаимосвязь с другой объектной моделью — CORBA, разработанной организацией Object Management Group.

3.5.2. Модель TOGAF Модель TOGAF (The Open Group Architectural Framework) — документ, разрабатываемый международной организацией The Open Group. TOGAF на сегодняшний день — наиболее полно представленная модель открытых распределённых вычислений. Фактически в ней обобщается опыт всех предыдущих поколений моделей, которые могут быть выведены из неё как частные случаи. И, что особенно важно, TOGAF формулирует принцип невозможности построения единой универсальной архитектуры для всех открытых систем, тем самым объясняя многообразие созданных моделей. В модели TOGAF не используются в явном виде определения "открытые", "распределённые" по отношению к системам обработки данных. Однако, открытый характер систем и распределённый характер обработки данных в общем случае подразумеваются как обычные и даже необходимые свойства компьютерных информационных систем. В целом модель TOGAF отражает возрастающее движение к модульности и стандартизации интерфейсов в информационных системах. Основой модели TOGAF являются модель POSIX OSE, модель XAF организации Х/Ореn и модель управления информацией TAFIM Министерства обороны США. Вторая версия TOGAF появилась в 1996 г., третья — в 1997 г., четвёртая — в 1998 г. В конце 1999 г. вышла пятая редакция модели.

Модель TOGAF представляет больший интерес с инженерной точки зрения, чем очень абстрактная и формальная модель RM-ODP. Документ состоит из четырёх основных частей. Первая часть — "введение" — описывает ключевые принципы, положенные в основу архитектуры современных информационных

систем вообще и подхода модели TOGAF в частности. Вторая часть — "Метод разработки архитектур" (ADM — Architecture Development Method) — является ядром модели TOGAF. Она описывает шаги, которым необходимо следовать в разработке архитектуры любой информационной системы, содержит принципы конструирования архитектуры, формально описывает цикл разработки системы. ADM опирается на другую важную составляющую модели — "Фундаментальную архитектуру" (TOGAF Foundation Architecture), которая изложена в одноимённой третьей части документа. Четвёртая часть документа — "Информационная база ресурсов" (Resource Base) — описывает набор инструментов и методик, доступных для использовании при практическом применении модели TOGAF и, в частности, методов ADM. Кроме того, документ содержит многочисленные приложения, примеры практического применения модели TOGAF, сравнение её с другими моделями. Рассмотрим кратко те части документа, которые представляют наибольший интерес: концепцию организационного континуума (ЕС), нормативную техническую модель и метод декомпозиции систем на так называемые "архитектурные взгляды". Архитектура определяется как формальное описание системы. Она является как бы детальным планом, на основе которого система может быть организована и реализована таким образом, что позволяет делать заключения о структурных свойствах системы. Любой сложной информационной системе необходима архитектура для обеспечения стратегического контекста её эволюции. Архитектура даёт описание компонентов, которые слагают информационную систему, прав и обязанностей каждого компонента и сложных взаимосвязей между ними, а способность видеть взаимосвязи между элементами целой информационной системы ведёт к лучшему пониманию глобальных проблем, таких как обеспечение безопасности информации и административное управление системой. Модель TOGAF утверждает: непрактично пытаться описать единую, универсальную архитектуру для открытых информационных систем. Неверно было бы строить одну архитектуру для всех целей и пытаться рассматривать информационную систему с одной точки зрения даже внутри одного предприятия, не говоря уже о существенно более сложных, глобальных информационных системах. Существует непрерывное и бесконечное множество — континуум архитектур, которые конструируются из каркасной модели посредством набора более узких моделей и строительных блоков. Такую каркасную модель под названием "архитектурный каркас" (architectural framework —AF) описывает TOGAF. AF является инструментом для конструирования широкого ранга архитектур, оценки различных архитектур, выбора и построения корректной архитектуры для информационной системы конкретной организации. С помощью AF путём выбора или модификации его компонентов может быть описано сразу целое семейство связанных архитектур. Преимущества AF заключаются в следующем:появляется возможность использования общих принципов, предположений и терминологии внутри семейства архитектур, определения единой структуры для них, разработки информационных систем в соответствии с общими принципами и содействия таким образом лучшей интеграции и взаимодействию систем. Организационный континуум (ЕС — enterprise continuum) — комбинация двух взаимосвязанных и взаимодополняющих друг друга концепций (рис. 15): континуума архитектур (architecture continuum — А С) и континуума решений (solutions continuum — SC). Под континуумом архитектур понимается широкий диапазон, непрерывное множество различных типов архитектур, которые могут быть синтезированы для всевозможных информационных систем на различных этапах их разработки, конструирования, выбора составных частей и моделей. Континуум архитектур отображает поступательное движение от абстрактного к конкретному, которое имеет место при создании архитектуры каждой информационной системы, на основе последовательной детализации и перехода от предельно общей модели (такой как TOGAF TRM) к архитектуре реальной информационной системы. В этом множестве архитектурных моделей может быть (условно) выделено несколько "опорных точек": • Фундаментальные архитектуры (foundation architectures — FA) — это архитектуры функций, которые поддерживаются всеми общесистемными архитектурами вместе взятыми (см. далее), т.е. все потенциально возможные функции, которые может выполнять какая бы то

ни было информационная система. Иными словами, FA описывают полную вычислительную среду. Примером FA является фундаментальная архитектура самой модели TOGAF. • Общесистемные архитектуры (common systems architectures — CSA) — это архитектуры, которые руководят выбором и интеграцией определённых сервисов из FA для создания архитектуры, полезной для решения широкого класса взаимосвязанных задач: архитектура защиты, архитектура административного управления, сетевая архитектура и т.п. Каждая из них неполна, если рассматривается с точки зрения общей функциональности информационной системы, но полна в рамках определённой проблемы: обеспечение безопасности информации, управляемости системы, организация телекоммуникационной среды и т.п. Решения, реализующие каждую такую архитектуру, составляют "строительные блоки" информационной системы. Они оказываются совместимыми с другими "строительными блоками" и могут быть использованы в любых комбинациях для создания функционально полных информационных систем. Примером служит архитектура модели IT DialTone, описывающая глобальную информационную среду на базе сети Internet (см. п. 3.5.3). Кроме того, The Open Group работает над несколькими архитектурными моделями такого класса, связанными с административным управлением системами, беспроводными коммуникациями, защитой данных. • Индустриальные архитектуры (industry architectures — IA) — архитектуры, которые руководят интеграцией общесистемных компонентов (компонентов из архитектур класса CSA) с компонентами архитектур из класса IA и созданием целевых решений для потребителя внутри определённой отрасли, например, для банковской сферы, нефтехимической, газовой промышленности, авиакомпаний и т.д. • Архитектуры организаций (organization architectures — ОА) описывают и руководят окончательным развёртыванием компонентов информационной системы, из которых слагается необходимое решение для определённой организации. Компоненты могут приобретаться пользователем в виде готовых решений, соответствующих архитектурам перечисленных выше классов, либо разрабатываться им самим.

Рис. 15. Организационный континуум

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

• Системные решения — это реализации CSA, составляемые из набора продуктов и услуг, которые могут быть определённым образом оценены или сертифицированы на соответствие некоторым требованиям или задачам, сформулированным в CSA, например, на соответствие критериям защищённости информации, высокой производительности и т.п. • Индустриальные решения — это реализации IA, которые обеспечивают универсальные "пакеты" компонентов и услуг, общих для определённой отрасли промышленности. Они могут "набираться" из стандартных продуктов и решений, но могут требовать и специального аппаратного и программного обеспечения. Например, в банковской сфере — банкоматы и пластиковые карты с соответствующим ПО. • Решения для организаций — это реализации ОА, которые обеспечивают требуемые функции для данной, конкретной организации. Они содержат наибольшее количество неповторимого, уникального содержания, чтобы максимально полно отвечать требованиям всех деловых процессов, должностных лиц и потребителей данной организации (предприятия, учреждения). Они могут сочетать внутри себя массовые, стандартные продукты и системы информационных технологий с единичными, разрабатываемыми под нужды одной, единственной организации. Фундаментальная архитектура TOGAF — это архитектура общих сервисов и функций, обеспечивающих базис, на котором могут быть синтезированы более специфичные архитектуры и архитектурные элементы. Она состоит из трёх компонент: нормативной технической модели (Technical Reference Model — TRM), информационной базы стандартов (Standards Information Base — SIB) и информационной базы строительных блоков (Building Blocks Information Base — BBIB). TRM обеспечивает классификацию и моделирование общих сервисов платформы. SIB представляет собой базу данных стандартов. Она может быть использована для определения конкретных сервисов и других компонент специфичной архитектуры, которая выводится из общей фундаментальной архитектуры TOGAF. Наконец, BBIB содержит информацию о строительных блоках, которые могут быть использованы в конструировании архитектур. TRM и SIB не являются строго обязательными для любой информационной системы. Потребитель вправе выбирать или разрабатывать такую техническую модель своей системы и такие правила её организации, которые лучше всего удовлетворяют его запросам. TRM и SIB, специфицированные The Open Group, отображают сложившуюся общемировую практику создания крупномасштабных информационных систем. TRM — достаточно общая модель, поэтому она может быть рекомендована как каркасная модель информационной системы в подавляющем большинстве случаев, за исключением, быть может, специализированных закрытых информационных систем: бортовых систем, систем управления технологическими процессами. При условии, если техническая модель и набор используемых стандартов совместимы между собой, TOGAF ADM остаётся действительным, каковы бы ни были их особенности.

Основное назначение TRM — описание функций платформы приложений, которые необходимы для поддержки приложений. TRM помогает осуществить классификацию информационных систем и, в особенности, сервисов платформ приложений. При разработке нормативной модели преследовалась цель обеспечить согласованное описание компонентов и структуры информационной системы, пригодное для их классификации, и наглядное представление этой классификации в виде графической модели (рис. 16). Пять основных элементов TRM: прикладное ПО (AS), платформа приложений (АР), коммуникационная инфраструктура, интерфейс платформы приложений (Application Platform Interface — API), интерфейс коммуникационной инфраструктуры (Communications Infrastructure Interface — CII). Как и в модели OSE, в TOGAF TRM не рассматривается конкретная структура платформы приложений. Основное отличие, однако, состоит в том, что последняя специфицирует полный набор стандартных сервисов из двенадцати групп сервисов, которые могут предоставляться платформой приложениям в любой потенциально возможной информационной системе. Реализация того или иного сервиса в конкретной системе определяется целями и задачами этой системы. Кроме того, определяются понятия "качества сервисов". Они применяются ко всем категориям сервисов и влияют на способ реализации и взаимодействия этих сервисов в конкретной информационной системе. Качества сервисов, размещённые по четырём категориям, описывают свойства, которые должны быть обеспечены однородно и взаимосвязанно через все категории сервисов, например, безопасность сервисов.

Рис. 16. Нормативная техническая модель TOGAF

"Внешняя среда" в ранних версиях модели TOGAF понималась точно так же, как и в модели OSE. Это — все внешние объекты, с которыми АР обменивается информацией, причём обмен производится через ЕЕ1. В дальнейшем (очевидно, под влиянием модели IT DialTone — см. п. 3.5.3) под "внешней средой" стала подразумеваться прежде всего коммуникационная инфраструктура, к которой "подключена" рассматриваемая информационная система. Вероятно, это можно мотивировать следующим образом. Предполагается, что в подавляющем большинстве случаев информационные системы не являются изолированными. Они имеют выход во "внешний мир", в том числе в сеть Internet — одну для всех пользователей информационных систем. Все же остальные объекты внешней среды: пользователи и средства обмена данными — свои для каждой информационной системы. К тому же пользователи рассматриваются во всех моделях информационных систем опосредованно — постольку, поскольку они сами являются "средствами" хранения, ввода/вывода и обработки информации, а средства обмена данными имеют на сегодняшний день существенно меньшее значение, чем коммуникационные средства. В TRM даётся детальная классификация сервисов АР. Перечислим основные группы, по которым размещаются сервисы в модели. • Сервисы графики и изображений обеспечивают функции, требуемые для создания, хранения, восстановления и манипулирования графическими образами. • Сервисы обмена данными обеспечивают специализированную поддержку для обмена информацией между приложениями и внешней средой. Обмен данными может производиться как между приложениями на одной платформе, так и на разных — гетерогенных платформах. Они включают сервисы распознавания типа и конверсии документов, сервисы обмена графическими данными (векторной и растровой графикой), сервисы обмена специализированными типами данных (факс, аудио, видео), гипертекстовые функции, сервисы обмена электронными документами и ряд других, которые в настоящее время относятся к прикладному ПО, но имеют тенденцию к включению в АР, такие как редакторы текста, издательские системы, мультимедиа-сервисы и т.п. • Сервисы управления данными обеспечивают управление данными, независимое от про-

цессов, создающих их, поддержку и разделение данных между процессами. Сюда включены сервисы словаря (репозитория) данных (т.е. хранение данных о данных — метаданных), системы управления базами данных, объектно-ориентированные СУБД, сервисы управления файлами и некоторые другие. • Сервисы интернационализации операций — это набор сервисов и интерфейсов, позволяющих пользователю определять, выбирать и изменять различные аспекты сред приложений, связанные с культурными особенностями той или иной страны. • Сервисы пользовательского интерфейса предназначены для человеко-машинного взаимодействия и включают текстовый интерфейс, графический интерфейс, сервисы печати, "помощь" в режиме on-line и др. сервисы. • Сервисы размещения ресурсов и директориальные сервисы (location and directory) включают сервисы именования и адресного поиска ресурсов, директориальные сервисы, сервисы фильтрации информации, регистрации и учёта. • Сервисы программной инженерии (software engeneering) — это инструменты для разработки и поддержки сложных комплексов ПО: языки программирования, сервисы связывания объектного кода, средства автоматизации проектирования ПО (CASE-системы), сервисы проектирования пользовательского интерфейса, сервисы отображения интерфейсов с языков программирования на сервисы АР и др. • Сервисы обработки транзакций предназначены для поддержки обработки информации в транзакциях в режиме on-line. • Сервисы защиты — это особая группа сервисов, так называемые межкатегориальные сервисы. Такое название они получили потому, что механизмы их реализации могут быть частью множества сервисов различных категорий. Эта категория включает в себя сервисы идентификации и аутентификации, сервисы контроля точек входа в систему, сервисы аудита, сервисы контроля доступа, объектные сервисы контроля доступа, сервисы обеспечения неотказуемости, сервисы шифрования, сервисы обеспечения доверенных каналов связи (trusted communication services), сервисы доверенного восстановления данных (trusted recovery services), сервисы управления защитой. Сервис шифрования является основой ряда других сервисов, таких как сервисы идентификации и аутентификации, сервисы контроля доступа, сервисы контроля точек входа в систему и др. • Сервисы административного управления системами и сетями. Их назначение — эффективное управление ресурсами информационной системы для достижения целей среды открытых систем. В эту группу входят сервисы управления пользователями, конфигурацией, производительностью, доступностью и надёжностью системы, учётом деятельности пользователей, безопасностью системы, сервисы управления сетями, дисками, печатью, резервным копированием и восстановлением информации, инсталляцией и лицензированием ПО, ёмкостью памяти и некоторые другие. Следующие две категории сервисов условно помещены в нижний уровень платформы приложений, так как они, как правило, являются основой реализации всех вышеперечисленных сервисов. • Сетевые сервисы обеспечивают поддержку распределённых приложений, требующих доступ к данным и взаимодействие приложений в гомогенных или гетерогенных сетевых средах. Сетевые сервисы состоят из интерфейсов и протоколов. Они включают: коммуникационные сервисы — интерфейсы и протоколы для надёжной, прозрачной передачи данных между абонентами сети, в том числе низкоуровневые функции, дающие прямой доступ к коммуникационным протоколам, и высокоуровневые функции (передача файлов, удалённый вход пользователя в систему, удалённое исполнение процессов и др.), сервисы управления сообщениями, сервисы организации групповой работы, видеоконференции, сервисы широковещательного распространения информации, телефонии, сервисы почтовой рассылки. В последней редакции модели в эту же группу были включены и сервисы, связанные с организацией распределённых вычислений, т.е. такие, которые поддерживают приложения, физически "распылённые" между множеством платформ, но поддерживающие общую среду обработки информации: распределённые сервисы времени, распределённые сервисы данных, распределённые файловые сервисы, распределённые сервисы именования, сервисы доступа к удалённым процессам, сервисы уда-

лённого вывода и распространения информации. • Сервисы операционной системы ответственны за управление аппаратными ресурсами платформы, включая процессор, память, файлы, ввод/вывод. Они экранируют приложения от особенностей аппаратного обеспечения той или иной платформы. Сервисы ОС включают: низкоуровневые сервисы ядра ОС, объектные сервисы ядра, интерпретаторы команд и утилиты, сервисы пакетной обработки, сервисы синхронизации файлов и директорий. Объектное обеспечение сервисов не выделяется как отдельная категория в TRM, так как все индивидуальные объектные сервисы включены в различные другие сервисные категории. Объектные сервисы обеспечивают способы создания, размещения, именования объектов и связывания их в распределённой среде. Модель выделяет следующие категории "качеств", присущих сервисам: • доступность, куда входят понятия управляемости, обслуживаемости, производительности, надёжности, восстанавливаемости, удобства размещения сервисов; • гарантированность, куда включаются безопасность, целостность и уровень доверия к системе; • используемость (лёгкость действий пользователей); • адаптируемость, а именно способность к взаимодействию, масштабируемость, переносимость, расширяемость функций системы. Очень важным элементом модели является SIB — это систематизированное собрание большого числа стандартов, наработанных за долгие годы различными международными организациями, апробированных или широко принятых в промышленности, выбранных членами The Open Group в качестве ядра для реализации открытых информационных систем. В SIB все стандарты классифицированы по категориям сервисов, соответствующих TRM. Так как современные информационные системы являются сложными системами, для описания тех или иных аспектов системы используются различные средства, различные инструменты описания (ср. с моделью RM-ODP — п. 3.5.1). Исторически сложилось несколько довольно самостоятельных отраслей, связанных с информационными технологиями. В связи с этим модель TOGAF вводит несколько так называемых "взглядов" (views) на информационную систему. Напомним, что в RM-ODP также есть понятия "точек зрения" (viewpoints), под которыми понимается "набор концепций, структур и правил, формирующих соответствующий язык [описания]": организационной, информационной, вычислительной, инженерной и технологической. "Точки зрения" RM-ODP не вполне совпадают со "взглядами" модели TOGAF. Более корректно, по-видимому, сравнивать их с различными уровнями детализации, которые используются моделью TOGAF для описания "строительных блоков". Функциональный взгляд (function view) рассматривает операционные аспекты системы, отталкиваясь от описания существующей среды информационных технологий и требований к функциям системы. Это взгляд со стороны специалиста в той предметной области, нужды которой обслуживает система. Взгляды на реализацию (implementation views)— это описание строения системы с точки зрения различных специалистов по информационным технологиям: • Взгляд на административное управление системой (management view) — это рассмотрение системы с точки зрения лиц, ответственных за её эксплуатацию: долгосрочное планирование целей деятельности информационной системы, оперативно-диспетчерское управление, конфигурирование и администрирование ПО и др. • Взгляд на защиту (security view) имеет целью обеспечить контролируемое использование информации в системе, сосредотачиваясь на аспектах защиты информации внутри информационной системы организации. • Взгляд на строение программного обеспечения (builder's view) охватывает те стороны создания и функционирования информационной системы, которые важны для разработчиков ПО: переносимость, способность к взаимодействию, методы разработки сложных программных систем и пр. • Взгляд на управление данными (data management view) изучает процессы хранения, доступа, обработки, архивации, передачи данных, в том числе средства и методы систематизиро-

ванного хранения и управления данными, защиту, администрирование данных. • Пользовательский взгляд (user view) включает эргономические аспекты работы пользователя: удобство, простоту видения системы, среду работы пользователей. Физические взгляды (physical views) — это взгляды на систему с точки зрения физической её организации и размещения в пространстве: • Взгляд на организацию вычислений (computing view) — это множество различных способов, которыми программные и аппаратные компоненты могут быть собраны в работоспособную структуру. Здесь рассматриваются различные модели организации вычислений: «клиент сервер», иерархическая , одноранговая («peer-to-peer»), объектная модель, мобильные вычисления. - Коммуникационный взгляд (communications view) рассматривает географический аспект организации системы, её коммуникационную инфраструктуру. Последняя рассматривается здесь с двух позиций: - физически — как состоящая из трёх уровней: локального, регионального и глобального, на каждом из которых используются вполне определённое коммуникационное оборудование, методы передачи данных, среды распространения сигнала; - логически — как состоящая из пяти архитектурных уровней на базе расширенной модели ISO/OSI: уровня передачи (transmission level) — ниже физического уровня модели OSI, уровня сетевых переключений (network switching level) — с 1-го по 3-й уровень OSI, уровня обмена данными (data exchange level) — с 4-го по 7-й уровни модели OSI, сервисов прикладного уровня модели OSI и уровня прикладных программ.

3.5.3. Модель IT DialTone IT DialTone — это каркасная модель архитектуры глобальной информационной системы для бизнес-приложений на базе общей коммуникационной инфраструктуры глобального масштаба: глобальных телекоммуникационных сетей, виртуальных частных сетей (VPN), открытых общедоступных сетей, в пределе — на основе сети Internet. Эта модель представляет интерес прежде всего как первая попытка теоретического описания глобальной информационной среды, сформировавшейся на базе всемирной сети Internet (рис. 17). Принципиально новым по сравнению со всеми предыдущими моделями, которые были рассчитаны на описание распределённых, но не глобальных информационных систем, является то, что с позиций каждого пользователя (потребителя информации) доступная ему информационная среда представляется как ряд разномасштабных информационных систем, соответствующих различным организационным структурам: от своей локальной вычислительной системы, информационной системы отдела, предприятия в целом, объединения, отрасли до среды Internet. Каждая информационная система предоставляет своим пользователям определённый набор ресурсов и услуг. Для систем различного масштаба он различен. Строение и функционирование каждой из них подчиняется своему набору условий. Для предприятия это может быть политика управления, политика безопасности предприятия. В масштабах предприятий-партнёров (например, в пределах одной отрасли, одного объединения предприятий) — соглашения и договора. В масштабах сети Internet — законы, международные соглашения, стандарты. Выделение таких "ступеней" вполне обоснованно: они проявляются и в объёме информационных потоков, и в структуре хранимых данных, и в организации управления, и в методах и средствах защиты информации. Так, для самого нижнего уровня организации, соответствующего отделу предприятия, лаборатории, небольшой группе работников, чаще всего представленного локальной сетью, характерно наличие общих единых баз данных, средств совместной (групповой) работы над проектами, схожий состав программного, а часто и аппаратного обеспечения рабочих мест пользователей. Для информационных систем больших организационных структур (крупная корпорация, министерство, отрасль промышленности, банковская система) характерны большая территориальная распределённость, гетерогенность среды информационных технологий, отсутствие едино-

Рис. 17. Модель информационной среды на основе сети Internet

Модель IT DialTone, как отмечалось в п. 3.5.2, является примером общесистемной архитектуры и согласована с моделью TOGAF. Основной магистралью для передачи данных в глобальной информационной системе, согласно модели IT DialTone, является глобальная коммуникационная инфраструктура (IT DialTone Core Infrastructure), — совокупность некоторого, возможно, большого или даже неопределённого числа взаимосвязанных и взаимодействующих между собой глобальных, региональных и локальных коммуникационных сетей. Коммуникационная инфраструктура характеризуется следующими качествами: • Повсеместностью. Она должна предоставлять одни и те же или схожие возможности в любой точке подключения к ней. Все пользователи должны иметь возможность использовать её одинаковым или почти одинаковым образом. • Единообразием базовых услуг. Нет необходимости в том, чтобы она обеспечивала большое количество разнообразных возможностей для своих пользователей: достаточно ограниченного набора услуг, который предоставляется всем единообразно. Например, фрагмент информации должен передаваться точно по обозначенному адресу за предсказуемый период времени при условии обеспечения надёжности и безопасности доставки. На базе этих услуг можно сформировать все остальные возможности. • Независимостью характера передачи данных от маршрута. Передача данных по коммуникационной инфрастуктуре полностью определяется в терминах протоколов и структур данных, но никак не связана с маршрутом, по которому приложения пересылают данные. • Независимостью передаваемых данных от приложений. Необходимо определить только структуры передаваемых данных, но нет необходимости определять семантику этих данных для приложений и содержание информации, переносимой внутри структур данных. На сегодняшний день наиболее полно удовлетворяет перечисленным условиям коммуникационная архитектура TCP/IP, которая стала стандартом в масштабах сети Internet. Подразумевается, что в глобальной информационной среде может одновременно существовать большое число распределённых приложений, в связи с чем в модели используется понятие сред приложений. Среды приложений, как правило, имеют зависимость от аппаратных платформ. Среда приложений, не зависящая от различий в аппаратном обеспечении, может быть сформирована на основе Java-технологий. Необходимым качеством глобальной инфраструктуры является открытость. В общем случае ни один производитель аппаратного или программного обеспечения не может удовлетворить все требования потребителя — пользователя и участника глобальной информационной системы. Она должна "собираться" из компонентов, доставленных различными поставщиками, которые следуют общим международным стандартам. Для среды Internet основным множеством стандартов, в том числе по защите информации, является серия документов RFC, публикуемых IETF. Основное назначение RFC — определить минимально необходимый набор спецификаций для обеспечения функционирования гло-

бальной информационной среды. Сегодня это множество включает более двух с половиной тысяч документов, среди них немало посвящено методам и средствам защиты информации. Значительная часть из них является стандартами де-факто. В остальном архитектура модели IT DialTone похожа на модель TOGAF: она включает нормативную архитектурную модель (Architecture Reference Model — ARM) — (в TOGAF — TRM) , SIB и ADM являются общими для обеих моделей. Согласно ARM, компоненты среды IT DialTone разделяются на три блока: • приложения и средства взаимодействия с пользователем обеспечивают прикладные сервисы, не зависимые от положения внутри распределённой среды; • сервисы распределённой системы предоставляют услуги, которые создают условия для "прозрачной" работы приложений; • коммуникации и платформы формируют основание, на котором строятся распределённые среды. Термин "платформа" употребляется в литературе в различных значениях. В модели IT DialTone платформа определяется как самодостаточный (минимальный) набор функциональности, который должен быть представлен необходимо зависимыми между собой компонентами. Платформа предоставляет основу, от которой зависят все остальные компоненты системы. Основные задачи платформы состоят в организованном исполнении кода программ и предоставлении программам доступа к аппаратным ресурсам. С течением времени реальное наполнение этого понятия изменяется. На начальных этапах развития вычислительной техники под платформой понималось только аппаратное обеспечение компьютера. Позднее — аппаратное обеспечение с операционной системой. В настоящее время потребитель обычно приобретает уже готовый комплекс аппаратного и программного обеспечения в соответствии с задачами, которые предполагается на нём решать, например, клиентскую платформу, файловый сервер, Internet-сервер, сервер баз данных, мэйнфрейм и др. Таким образом, для пользователя платформа представляется как "неделимое" образование, которое служит ему средством решения его задач. Несколько отличается состав категорий сервисов, предоставляемых системой (рис. 18): • сервисы представления и взаимодействия с пользователем; • сервисы интеграции ПО; • сервисы управления информационными потоками; • сервисы безопасности; • сервисы управления; • директориальные сервисы и сервисы размещения ресурсов; • сервисы данных; • сервисы распределённых вычислений; • коммуникационные сервисы; • сервисы платформ. Приложения подразделяются на два класса: бизнес-приложения и инфраструктурные. Функции бизнес-приложений выходят за рамки модели IT DialTone и потому в ней не рассматриваются. Инфраструктурные приложения обеспечивают общецелевые бизнес-функции, базируясь на сервисах инфраструктуры. С течением времени некоторые бизнес-приложения имеют тенденцию переходить в разряд инфраструктурных, а те, в свою очередь, в разряд сервисов системы. Многие положения модели IT DialTone оказали влияние на развитие модели TOGAF, в основном её пятой версии.

Рис. 18. Нормативная архитектурная модель IT DialTone

3.6. Подходы ведущих фирм-производителей к организации распределённых сред Мы не будем подробно останавливаться на моделях и решениях, предложенных даже ведущими фирмами-производителями и поставщиками решений в области информационных технологий: эти фирмы очень динамично развиваются, и информация об их разработках довольно быстро устаревает. Документы организаций по стандартизации отличаются гораздо большей стабильностью и преемственностью. Кроме того, документы фирм зачастую бывают необъективны, так как прежде всего имеют целью продвижение на рынок и рекламу своих собственных разработок. Актуальную информацию по разработкам крупных фирм всегда можно получить, обратившись к страницам соответствующих фирм в сети Internet. В целом среди различных фирм наблюдается два различных подхода к разработке архитектур распределённых сред: "от моделей" и "от продуктов". В первом случае фирма, занимаясь стратегическим планированием своей научной и производственной деятельности, разрабатывает более или менее подробную модель, отображающую суть предлагаемых решений. Модель позволяет легко классифицировать и размещать в ней те программные продукты, которые будут далее предлагаться этой, а может быть и другими фирмами, делать заключения о возможности их "сопряжения" между собой, использования различного аппаратного обеспечения. Во втором случае (подход "от продуктов") фирма сначала выпускает на рынок свои продукты, а затем "выводит" архитектуру из них, ставя пользователей перед фактом использования того или иного решения, которое может быть не совместимо с существующими стандартами и затрудняет "сопряжение" с продуктами других фирм, но уже получило некоторое распространение на рынке. Не всегда модель, которая преподносится фирмой как архитектура, является таковой на самом деле. В диаграмме, действительно изображающей архитектуру, каждый блок соответствует абстрактному представлению (в виде сервиса, менеджера ресурсов, функции и др.) определённого функционального модуля или группы модулей, которые должны в той или иной форме присутствовать в системе, а каждая граница между блоками представляет реально существующий, чётко определяемый, может быть даже опубликованный, интерфейс, например, API. Иногда в документах фирм используются архитектуро-подобные диаграммы, которые, однако, не имеют реального технического наполнения. Они перечисляют набор продуктов, компонент, библиотек, но ничего не говорят о том, как эта совокупность продуктов работает. Отличить такие псевдо-модели от настоящей архитектуры можно следующим образом: если с диаграммы

удалить все наименования продуктов, будет ли она при этом всё ещё помогать разработчику понимать природу задачи, для решения которой она предлагается? Корпорация IBM традиционно являлась одним из ведущих идеологов открытых распределённых вычислений. В разное время фирмой IBM предпринимались в различной степени удачные попытки теоретически сформулировать концепцию распределённых вычислительных сред. В п. 3.4 уже рассматривалась основная модель распределённых вычислительных сред Open Blueprint, предложенная фирмой в 1994 г. Это очень удачная модель распределённых вычислительных систем масштаба предприятия, богатая различными возможностями. В ней впервые были сформулированы многие важные принципы распределённых вычислений. Ей предшествовала «промежуточная» модель Networking Blueprint. Ещё ранее фирмой предлагалась модель SAA (System Applications Architecture), которая оказалась неудачной, так как не являлась архитектурой (см. выше), а лишь содержала перечень продуктов и поддерживаемых фирмой типов платформ. Разработки фирмы IBM опираются на мощную технологическую базу: несколько типов аппаратно-программно платформ (мэйнфреймы S/390, системы среднего уровня AS/400, рабочие станции RS/6000 с UNIX-подобной операционной системой AIX, персональные системы), несколько линий программных продуктов (WebSphere, VisualAge, DB2, MQSeries, SecureWay, Lotus, Tivoli). В 1998 — 99 гг. IBM одной из первых сформулировала концепцию глобальной информационной среды для электронного бизнеса, которая в документах фирмы получила название NCF - Network Computing Framework. Корпорацией DEC (Digital Equipment Corp.) до её поглощения корпорацией Compaq велась большая работа по формированию принципов и моделей организации распределённых вычислительных сред масштаба предприятия. Модель корпорации DEC получила название NAS — Network Application Support. Она появилась в 1987г., была одной из первых подобных архитектур, к 1993 г. модель была тщательно разработана. NAS — полновесная, хотя и не такая ясная и исчерпывающая как Open Blueprint, архитектура, которая позволила строить открытые, масштабируемые распределённые среды. Именно в документах DEC появился и стал широко использоваться термин "middleware" для обозначения ПО среднего уровня, реализующего сервисы распределённой платформы. В дальнейшем многие компоненты модели NAS были "взяты на вооружение" корпорацией Microsoft, в том числе при разработке операционной системы Windows NT. Фирма Hewlett-Packard не заявляла официально о создании архитектуры распределённых вычислительных сред. Она декларирует подход, основанный на решениях для конкретных организаций, которые включают продукты фирмы HP. На самом деле при создании своих решений HP пользуется моделью, которая имеет название EOSA (Emerging Open Systems Architecture), её создание относится к 1992 — 95 гг. Фирма Novell также разрабатывала свою модель ПО распределённой вычислительной среды масштаба предприятия, которая имела название AppWare, но фирма отказалась от неё в 1994 г. и сконцентрировалась на разработки сетевой ОС Novell NetWare. Фирма Apple выдвинула в 1989 г. модель VITAL (Virtually Integrated Technical Architecture Lifecycle), которая не претендует быть целостной архитектурой распределённой среды, а скорее посвящена организации клиент-серверных вычислений внутри такой среды. Применимость этой модели также ограничена поддержкой решений для конкретных предприятий. Модель не придерживается до конца принципов открытости: она представляет собой смесь открытых и неспецифицированных интерфейсов. В разработке решений фирма Apple поддерживала связь с DEC. Корпорация Microsoft показывает типичный пример подхода "от продуктов". Microsoft придерживается так называемого "компонентного подхода": продукты представляют себя внешнему миру через общий компонентный интерфейс, называемый OLE. Продукты Microsoft не отвечают в достаточной степени требованиям открытости: они пользуются "закрытыми", неспецифицированными интерфейсами. Структура этих продуктов предназначена преимущественно для продажи компонент, а не для предоставления пользователям действительно от-

крытых, независимых от поставщиков решений. В 1992 — 95 гг. модель архитектуры программного обеспечения Microsoft носила название WOSA (Windows Open Services Architecture). В рамках этой модели архитектура Microsoft может быть представлена как сумма имеющихся продуктов линии Windows с поддержкой спецификации OLE. Эта модель, однако, не могла считаться полноценной архитектурой для распределённых систем масштаба предприятия. Она охватывала далеко не все типы сервисов: в основном те, которые требуются в офисных приложениях. Впоследствии она была замещена единым стандартным интерфейсом OLE (Object Linking and Embedding) для взаимодействия приложений между собой и с сервисами операционной системы. Сейчас OLE — это целостная компонентная технология, в которую на нижнем уровне входит СОМ (Component Object Model) — не зависящий от языка программирования, двоичный стандарт для обеспечения способности к взаимодействию программных компонент. Название OLE сохранено только как аббревиатура, не наполненная смыслом. В настоящее время стратегия фирмы Microsoft обеспечения совместимости своих программных продуктов с изделиями других фирм основывается на четырёхуровневой модели: интеграции сетей, данных, приложений и управления. ПО фирмы Microsoft включает ряд базовых стандартов, обеспечивающих способность к взаимодействию, таких как поддержка коммуникационной архитектуры TCP/IP, эмуляция удалённого терминала, поддержка протоколов FTP, HTTP, Telnet, интеграция системы доменных имён (DNS), имеются дополнительные продукты для взаимодействия с ОС семейства UNIX, NetWare. Совместимость данных обеспечивается за счёт использования интерфейса ODBC (Open DataBase Connectivity), что позволяет разработчикам приложений иметь доступ к данным безотносительно и конкретным базам данных или ОС, на которых они работают. Совместимость управления системами достигается на основе протокола SNMP из стека ТСРЛР. Вероятно, решающее значение для Microsoft имеет такой аспект открытости как переносимость пользователей. Семейство ОС Windows сохраняет и совершенствует хорошо разработанный пользовательский интерфейс. Постепенно расширяется диапазон вычислительных систем, на которых работают ОС семейства Windows, ранее преимущественно рассчитанные на персональные компьютеры для офисной работы. Microsoft в большей степени заботится о переносимости пользователей и о стандартах де-факто, которые она установила, чем о строгом соответствии стандартам открытых систем. Продукты Microsoft опираются на сравнительно бедную технологическую базу, но получили распространение главным образом из-за удобного пользовательского интерфейса, широкого ассортимента программных средств и большого давления на рынок самой фирмы. В силу того, что они сейчас очень широко распространены, большинство других крупных фирм вынуждено считаться с этим и искать пути "состыковки" своих продуктов и решений с продуктами Microsoft. Ссылки и замечания к гл. 3: п. 3.1: За основу классификации моделей взята классификация из [23, ch.3], которая расширена с учётом моделей, появившихся за последние годы (1995 — 2000 гг.). Диаграммы с изображением графических моделей архитектур (рис. 7 — 12, 14 в пп. 3.1 — 3.4) приводятся, с небольшими изменениями, по этой работе с переводом названий всех компонентов моделей на русский язык. При написании данного параграфа использованы также материалы [19]. п. 3.2: Наряду с реферативным изложением каждой модели в пп. 3.2 — 3.5 даётся краткий обобщённый анализ каждого класса моделей и взаимосвязей между ними. Характеристика модели взаимосвязи открытых систем ISO OSI [12] составлена по материалам сборника [3], а также [20, пп. 7.6 — 7.8; 23, п. 3.4.1]. При характеристике профилей взаимосвязи открытых систем использованы материалы [6, стр. 41 — 42]. Значительная часть работ по стандартизации Госпрофиля России по взаимосвязи открытых систем на основе модели OSI была проведена в 1995 — 99 гг. Для характеристики модели POSIX OSE использованы материалы [6, стр. 90 — 98; 7; 21, ch.2; 23, п. 3.4.2]. Развёрнутую информацию об этой модели можно получить, например, в [2]. Термин "reference (model)" часто переводится на русский язык как "эталонная (модель)". Здесь и далее в этой работе при переводе используется определение "нормативная " вместо "эталонная ", так как в свете вновь появившихся в последние годы (после модели OSI) стандартов такой перевод представляется более точным: изложенные в них модели считаются скорее не точным образцом, к которому нужно стремиться при практической реализации системы, а некоторой нормой, мерой, шаблоном, который удобен для описания, формализации,

но который на практике можно заменить более удобной (точной, подходящей) моделью при наличии на то достаточных оснований. п. 3.3: Рефераты моделей САЕ и AES составлены на основе [20, п. 3.5; 23, пп.7.12 — 7.15]. С документами проекта Single UNIX можно ознакомиться в сети Internet no адресу: http:// www.opengroup.org/platform п. 3.4: Рефераты моделей XDCS и UI-Atlas составлены на основе [20, п. 3.6.1, 3.6.2; 22, пп. 3.2.3, 3.5.2; 23, п.7.16— 7.20]. Реферат модели OpenBlueprint и рис. 13 составлен на основе документов корпорации IBM, представленных в Internet на сервере, посвящённом программному обеспечению IBM: http://www-4.ibm.corn/software Реферат модели DCE и характеристика продуктов, составляющих обноимённый пакет, составлены на основе [20, п. 3.6.4; 22, п. 3.5.4; 23, п.7.22], а также материалов The Open Group, представленных в Internet no адресу: http:// www.opengroup.org/dce п. 3.5: Реферат модели RM-ODP составлен на основе текста проектов стандартов ISO [13 — 16] и учебного руководства, доступных в Internet no адресу: http://archive.dste.edu.au/AU/research_news/odp/ref_model/papers Дополнительная информация может быть получена по адресам: http://www.iso.ch:8000/RM-ODP http://www.exitl09.com/~kpt/ODPResources.html Модель TOGAF рассматривается по официальному тексту 5-й версии этого документа (январь 2000 г.) [24]. Использовались также материалы версии 4 этой же модели (декабрь 1998 г.). Предшественниками модели TOGAF являются модель XAF организации Х/Ореn (она утратила актуальность) и модель TAFIM [11] Министерства обороны США. Последняя отличается очень обширной и детально разработанной нормативной технической моделью. В 4-й части [24] имеется перечень др. моделей, представляющих интерес на сегодняшний день: это модели CORBA, DCE, NCR EAF, SPIRIT. Модель IT DialTone [17] разрабатывалась одновременно с TOGAF, конкретизируя её применительно к глобальной информационной среде. Это одна из первых попыток теоретически описать информационную среду на основе сети Internet. Модель чётко выражает сдвиг в понимании роли коммуникационных сетей и места отдельных информационных систем организаций (предприятий, учреждений) в глобальной среде Internet: в ней каждая система "подключена" к общей коммуникационной инфраструктуре подобно тому, как каждый телефонный аппарат подключен к общей телефонной сети, которая имеет выход на местную, городскую, междугородную, международную связь. (Эта аналогия отражена в названии модели и в формулировке её цели — "создать такую инфраструктуру информационных технологий, пользоваться которой было бы так же легко, как телефонным аппаратом".) IT DialTone подразумевает, что глобальная коммуникационная инфраструктура использует в своей основе коммуникационную архитектуру TCP/IP. Хорошим руководством по ней является книга [25]. Модель IT DialTone оказала обратное влияние на модель TOGAF — версия 5 модели TOGAF претерпела существенные изменения по сравнению с версией 4: стала более похожей на модель IT DialTone.

Глава 4. СТАНДАРТЫ И МОДЕЛИ ЗАЩИТЫ ИНФОРМАЦИИ В ОТКРЫТЫХ СИСТЕМАХ Архитектурные модели открытых систем, рассмотренные в главе 3, содержат большой набор сервисов платформы приложений. Но не все сервисы платформы являются одинаково равноправными, несмотря на то, что модели, как правило, не отражают взаимосвязь между сервисами и считают их равнозначными. Так, все модели в той или иной форме отмечают особенности сервисов защиты информации и сервисов административного управления системами. Как и прочие сервисы, они предоставляют услуги прикладному ПО, другим сервисам платформы и внешней среде; но имеют ряд особенностей: • При необходимости эти сервисы должны обеспечивать для других сервисов платформы необходимые для них качества: управляемость, готовность, безопасность, целостность. • Механизмы реализации этих сервисов могут быть частью множества других сервисов различных категорий. Так, защита информации вряд ли может быть обеспечена без механизмов поддержки, встроенных в операционную систему. • Независимо от территориальной распределённости системы услуги, предоставляемые этими сервисами, имеют смысл только будучи обеспечены во всей системе целиком, а не только на отдельных вычислительных системах. Учитывая особую роль сервисов защиты в архитектуре открытых информационных систем, построенных на основе распределённых систем обработки данных, рассмотрим рекомендованные международными стандартами состав, функции сервисов защиты и методы их реализации.

4.1. Защита информации в модели ISO OSI. Стандарты ISO Первым международным стандартом де-юре в этой области стал стандарт ISO 7498-2 (эквивалент — стандарт ITU-T X.800). Задача защиты информации рассматривается в нём в рамках модели взаимосвязи открытых систем. Защита информации в модели OSI осуществляется набором из четырнадцати (необязательных) сервисов защиты, из которых выделяются пять базовых: аутентификация, управление доступом, конфиденциальность данных, целостность данных, неотказуемость, — остальные их конкретизируют. • Аутентификация парного логического объекта происходит при установлении соединения или обмене данными для подтверждения того, что оконечный логический объект является тем, за кого себя выдаёт. • Аутентификация источника данных подтверждает, что источником блока данных является именно тот, кто ожидался, однако, не предотвращает дублирование или модификацию блока данных. • Управление доступом направлено на предотвращение несанкционированного использования ресурсов через среду вычислительной сети. • Конфиденциальность соединения направлена на обеспечение конфиденциальности всех данных пользователя этого соединения. • Конфиденциальность в режиме без установления соединения направлена на обеспечение конфиденциальности всех данных пользователя в отдельном сервисном блоке данных. • Конфиденциальность (выделенного) поля данных направлена на обеспечение секретности отдельного поля в блоке данных при установлении соединения или в сервисном блоке в режиме без установления соединения. • Конфиденциальность трафика направлена на предотвращение получения какой-либо информации путём наблюдения трафика. • Целостность соединения с восстановлением обеспечивает целостность всех данных пользователей соединения и позволяет обнаружить подстановку, модификацию, изъятие или переадресацию отдельных данных или сервисного блока данных с возможностью восстановления утраченных данных.

• Целостность соединения без восстановления обеспечивает те же возможности, но без средств восстановления. • Целостность (выделенного) поля данных в режиме с установлением соединения обеспечивает целостность отдельного поля сообщения во всём потоке сервисных блоков данных, проходящих через соединение, и обнаруживает подстановку, изъятие или модификацию этого поля. • Целостность блока данных в режиме без установления соединения обеспечивает целостность отдельного сервисного блока данных при работе без установления соединения и позволяет обнаружить модификацию, некоторые формы подстановки и переадресации. • Целостность поля данных в режиме без установления соединения позволяет обнаружить модификацию отдельного поля в отдельном сервисном блоке данных. • Доказательство отправки заключается в предоставлении получателю данных информации о том, что ему посланы данные, и аутентификации отправителя, предотвращая любые попытки отправителя отрицать впоследствии факт передачи данных. • Доказательство доставки заключается в предоставлении отправителю данных информации о том, что переданные им для доставки данные получены адресатом, и направлено на предотвращение любых попыток отрицать впоследствии факт приёма данных получателем. Сервисы реализуются при помощи восьми механизмов защиты, которые реализуются на одном или нескольких уровнях модели OSI: шифрования, цифровой подписи, управления доступом, обеспечения целостности данных, взаимной идентификации, заполнения графика, управления маршрутизацией, нотариального заверения. - Шифрование может обеспечить секретность данных пользователя или информации о трафике, а также дополнять ряд других механизмов защиты. Механизм шифрования предполагает управление криптографическими ключами. - Механизм цифровой подписи состоит из процедур генерации и проверки цифровой подписи. - Механизмы управления доступом используют идентификацию логического объекта или информацию о нём для проверки его полномочий. Если логический объект пытается получить доступ к ресурсу, использование которого ему не разрешено, механизм управления доступом отклоняет эту попытку и может оставлять в системе "след" неудачной попытки доступа. Механизмы управления доступом могут основываться на: - информационных базах управления доступом, где содержатся сведения о полномочиях всех логических объектов; - идентификационной информации (например, пароли); - специальных режимах и особенностях работы логического объекта, которое даёт право на доступ к определённым ресурсам; - специальных метках, которые, будучи ассоциированы с конкретным логическим объектом, дают ему определённые права доступа; - времени, маршруте и продолжительности доступа. - Механизмы обеспечения целостности данных подразделяются на два типа: - целостность единственного блока данных обеспечивается добавлением к нему при передаче кода, который является функцией самих данных и проверкой его при приёме данных (с возможным выполнением процедур восстановления); - целостность потока блоков данных или отдельных полей этих блоков требует явного упорядочения блоков данных с защитой его криптографическими методами либо проставления меток времени. - Механизмы взаимной аутентификации используют пароли, криптографические методы, а также характеристики и взаимоотношения подчинённости логических объектов. - Механизм заполнения трафика используется для защиты от попыток анализа трафика: он эффективен только в случае сплошного и непрерывного шифрования всего трафика, когда невозможно отличить момент передачи сообщения от передачи "пустого" заполнения. • механизм управления маршрутизацией позволяет использовать только определённые, безопасные звенья и сети передачи данных. • Механизм нотариального заверения обеспечивается так называемым "сервисом третьей

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

Примечание. Цифрами обозначены механизмы защиты: 1 - шифрование; 2 - цифровая подпись; 3 - контроль доступа; 4 - обеспечение целостности данных; 5 - взаимная аутентификация; б - заполнение трафика; 7 - управление маршрутизацией; 8 - нотариальное заверение. Распределение сервисов и механизмов защиты информации по уровням модели OSI показано в табл. 2. Таблица 2 . Распределение сервисов и механизмов защиты информации по уровням модели OSI

Примечания: 1. Цифры в таблице означают номера механизмов защиты из табл. 1. 2. * механизмы защиты реализуются на нижележащих уровнях. Как видно из табл. 2, на двух нижних уровнях применяется только шифрование потока данных, проходящих через канал. Сетевой уровень (3) способен обеспечить значительно больше сервисов защиты: в нём сосредоточено управление маршрутизацией. Сервисы сетевого

уровня обеспечиваются протоколами доступа к сети передачи данных, протоколами маршрутизации, трансляции. Управление доступом на сетевом уровне позволяет отклонять нежелательные вызовы, даёт возможность различным сетям передачи данных управлять использованием ресурсов сетевого уровня. На транспортном уровне (4) осуществляется защита индивидуальных транспортных соединений, которые могут быть изолированы от других транспортных соединений. На сеансовом уровне (5) не предусмотрены механизмы защиты информации. Уровень представления (6) содержит механизмы, связанные с шифрованием данных и с поддержкой сервисов прикладного уровня. Прикладной уровень (7) может обеспечить любой сервис безопасности, хотя некоторые из них обеспечиваются с помощью механизмов, реализуемых в нижележащих уровнях (отмечены значком *). Более того, пользователь прикладного уровня может сам предпринять дополнительные меры по защите своей информации. Методы управления защитой информации, отмеченные в архитектуре управления OSI, обеспечивают защиту ресурсов среды открытых систем посредством санкционированного использования ресурсов, управления доступом, шифрования и управления криптографическими ключами, идентификации, регистрации и проверки событий, связанных с защитой информации. Они включают: управление уровнем безопасности системы, управление сервисами защиты, управление отдельными механизмами защиты. Управление уровнем безопасности системы включает поддержку целостности общей политики безопасности системы, обеспечение взаимосвязи сервисов, механизмов и средств управления защитой, системный журнал, управление механизмом восстановления и др. Управление сервисами защиты реализует назначение или снятие отдельного сервиса, определяет правила выбора конкретных механизмов для реализации требуемых сервисов, согласует параметры механизмов защиты. Управление отдельными механизмами защиты включает, в частности, управление ключами, управление контролем доступа, управление маршрутизацией, управление арбитражем и пр. Средства защиты на различных уровнях модели OSI конкретизируются следующими стандартами: • ISO/IEC TR 13594:1995- Information technology - Lower layers security (защита нижних (1,2) уровней); • ISO/IEC 11577:1995 - Information technology - Open Systems Interconnection — Network layer security protocol (протокол защиты сетевого (3) уровня); • ISO/IEC 10736:1995 — Information technology — Telecommunications and information exchange between systems - Transport layer security protocol (протокол защиты транспортного (4) уровня); • ISO/IEC 10745:1995 - Information technology - Open Systems Interconnection - Upper layers security model (модель защиты верхних (5 - 7) уровней архитектуры OSI); • ISO/IEC 11586 — стандарт из шести частей, описывающий общую модель высокоуровневой защиты OSI с описанием архитектурных элементов модели защиты (сервисов, блоков данных, протоколов, синтаксиса): • ISO/IEC 11586-1:1996 - Information technology - Open Systems Interconnection — Generic upper layers security: Overview, models and notation; • ISO/IEC 11586-2:1996 - Information technology - Open Systems Interconnection — Generic upper layers security: Security Exchange Service Element (SESE) service definition; • ISO/IEC 11586-3:1996 - Information technology - Open Systems Interconnection — Generic upper layers security: Security Exchange Service Element (SESE) protocol specification; ISO/IEC 11586-4:1996 - Information technology - Open Systems Interconnection — Generic upper layers security: Protecting transfer syntax specification; • ISO/IEC 11586-5:1997 -- Information technology - Open Systems Interconnection — Generic upper layers security: Security Exchange Service Element (SESE) Protocol Implementation Conformance Statement (PICS) proforma; • ISO/IEC 11586-6:1997 - Information technology - Open Systems Interconnection — Generic upper layers security: Protecting transfer syntax Protocol Implementation Conformance Statement (PICS) proforma; Стандарт ISO 7498-2 сейчас приобрёл значение основного стандарта по защите информации в открытых телекоммуникационных сетях.

Дальнейшее развитие принципы защиты, сформулированные в модели ISO OSI, находят в модели RM-ODP (стандарт ISO/IEC 10746). В ней определяются семь групп функций защиты: функции контроля доступа, аудита, аутентификации, целостности, конфиденциальности, неотказуемости и управления ключами. Первые шесть из них рассматриваются в стандарте ISO/IEC 10181 из семи частей и его эквивалентах ITU-T X.810 — Х.816. В них формулируется серия каркасных моделей организации сервисов защиты для открытых систем: • ISO/IEC 10181-1:1996 - Information technology -- Open Systems Interconnection — Security frameworks for open systems: Overview; • ISO/IEC 10181-2:1996 - Information technology - Open Systems Interconnection — Security frameworks for open systems: Authentication framework; • ISO/IEC 10181-3:1996 - Information technology -- Open Systems Interconnection — Security frameworks for open systems: Access control framework; • ISO/IEC 10181-4:1997 - Information technology - Open Systems Interconnection — Security frameworks for open systems: Non-repudiation framework; • ISO/IEC 10181-5:1996 - Information technology -- Open Systems Interconnection — Security frameworks for open systems: Confidentiality framework; • ISO/IEC 10181-6:1996 - Information technology - Open Systems Interconnection — Security frameworks for open systems: Integrity framework; • ISO/IEC 10181-7:1996 - Information technology - Open Systems Interconnection — Security frameworks for open systems: Security audit and alarms framework. В отдельные стандарты вынесены: • каркасная модель сервиса аутентификации в открытых системах, основанного на криптографических методах (ISO/IEC 9594-8 и его эквивалент ITU-T Х.509); • функции аудита и оповещения о чрезвычайных ситуациях в системе защиты (ISO 10164-7,8); • управление системой защиты (ISO/IEC TR 13335); • общая модель и механизмы управления криптографическими ключами (стандарт ISO/IEC 11770 из трёх частей). Последний из них определяет основные этапы жизненного цикла криптографических ключей, модели распространения ключей, требования по защите ключевого материала (часть 1), механизмы распределения ключей, основанные на симметричных (часть 2) и асимметричных (часть 3) криптоалгоритмах. К общеархитектурным стандартам по защите можно также отнести ISO 2382-8:1998 — словарь терминов по защите информационных технологий. Указанные стандарты используют ряд более специальных стандартов по криптографическим методам и механизмам защиты информации: - ISO/IEC 9796 - стандарт, состоящий из трёх частей, который описывает схемы цифровой подписи с восстановлением сообщений: - ISO/IEC 9796:1991 Information technology -- Security techniques - Digital signature scheme giving message recovery; - ISO/IEC 9796-2:1997 Information technology - Security techniques - Digital signature schemes giving message recovery — Part 2: Mechanisms using a hash-function; - ISO/IEC 9796-3:2000 Information technology - Security techniques - Digital signature schemes giving message recovery — Part 3: Discrete logarithm based mechanisms; - ISO/IEC 9797 - стандарт, описывающий механизмы обеспечения целостности данных: - ISO/IEC 9797:1994 Information technology — Security techniques — Data integrity mechanism using a cryptographic check function employing a block cipher algorithm; - ISO/IEC 9797-1:1999 Information technology -- Security techniques --Message Authentication Codes (MACs) — Part 1: Mechanisms using a block cipher; - ISO/IEC 9798 — стандарт из пяти частей по механизмам аутентификации: - ISO/IEC 9798-1:1997 Information technology - Security techniques " Entity authentication — Part 1: General; - ISO/IEC 9798-2:1999 Information technology - Security techniques - Entity authentication — Part 2: Mechanisms using symmetric encipherment algorithm;

- ISO/IEC 9798-3:1998 Information technology - Security techniques - Entity authentication — Part 3: Mechanisms using digital signature techniques; - ISO/IEC 9798-4:1999 Information technology - Security techniques - Entity authentication — Part 4: Mechanisms using a cryptographic check function; - ISO/IEC 9798-5:1999 Information technology - Security techniques - Entity authentication — Part 5: Mechanisms using zero knowledge techniques; - ISO/IEC 10116 — Information technology — Security techniques — Modes of operation for an n-bit block cipher (режимы работы п-битного блочного шифра); - ISO/IEC 10118 — стандарт из четырёх частей по криптографическим хэш-функциям: - ISO/IEC 10118-1:1994 Information technology - Security techniques - Hash-functions - Part 1: General; - ISO/IEC 10118-2:1994 Information technology -- Security techniques - Hash-functions — Part 2: Hash-functions using an n-bit block cipher algorithm; - ISO/IEC 10118-3:1998 Information technology - Security techniques - Hash-functions — Part 3: Dedicated hash-functions; - ISO/IEC 10118-4:1998 Information technology - Security techniques - Hash-functions — Part 4: Hash-functions using modular arithmetic; - ISO/IEC 13888 — механизмы обеспечения неотказуемости: - ISO/IEC 13888-1:1997 Information technology - Security techniques - Non-repudiation — Part 1: General; - ISO/IEC 13888-2:1998 Information technology - Security techniques - Non-repudiation — Part 2: Mechanisms using symmetric techniques; - ISO/IEC 13888-3:1997 Information technology - Security techniques - Non-repudiation — Part 3: Mechanisms using asymmetric techniques; - ISO/IEC 14888 — цифровые подписи "с аппендиксом": - ISO/IEC 14888-1:1998 Information technology - Security techniques -Digital signatures with appendix — Part 1: General; - ISO/IEC 14888-2:1999 Information technology - Security techniques -Digital signatures with appendix — Part 2: Identity-based mechanisms; - ISO/IEC 14888-3:1998 Information technology - Security techniques -Digital signatures with appendix — Part 3: Certificate-based mechanisms. Указанные международные стандарты, однако, не обязывают применять те или иные конкретные криптографические алгоритмы — этот вопрос относится к компетенции национальных органов стандартизации каждого государства. В России также приняты государственные стандарты на основные криптографические алгоритмы: - ГОСТ 28147 - 89 - стандарт на симметричный алгоритм шифрования; - ГОСТ Р 3410-94 - стандарт на электронную цифровую подпись; - ГОСТ Р 3411-94 - стандарт на криптографическую функцию хэширования. Исключительно важным этапом создания средств и систем защиты является оценка достигнутого в продуктах и системах информационных технологий уровня защищённости информации. Основным международным стандартом является стандарт ISO/IEC 15408 — "Критерии оценки защищённости продуктов и систем информационных технологий" - из трёх частей: - ISO/IEC 15408-1:1999 — Information technology — Security techniques — Evaluation criteria for IT security - Part 1: Introduction and general model; - ISO/IEC 15408-2:1999 - Information technology -- Security techniques -Evaluation criteria for IT security - Part 2: Security functional requirements; - ISO/IEC 15408-3:1999 - Information technology - Security techniques -Evaluation criteria for IT security - Part 3: Security assurance requirements. В части 2 этого стандарта содержится методика применения этих критериев для оценки защищённости распределённых продуктов и систем. Следует заметить, что оценка в соответствии с этим стандартом носит качественный характер. Если какой-либо компонент информационной системы оценен и классифицирован по этим критериям, это не означает, что он автоматически, при любых условиях обеспечивает заданный уровень защищённости. Он может быть достигнут потенциально, при выполнении ряда внешних условий, например, при соответствии

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

4.2. Защита информации в модели POSIX OSE Методы и механизмы защиты информации в среде открытых систем в рамках модели POSIX OSE рассматриваются в основном стандарте по интерфейсу переносимых операционных систем IEEE Р 1003.1 (ISO/IEC 9945) и двух дополнительных стандартах: • IEEE P 1003.1е - Portable Operating System Interface - Amendment: protection, audit and control interfaces; • IEEE P 1003.2с - Portable Operating System Interface - Part 2: Shell and utilities - Amendment: protection and control utilities. Последние два стандарта специфицируют механизмы защиты и интерфейсы к ним, обеспечивающие такие функции защиты, которые не предусмотрены в базовом стандарте: • дискретционный контроль доступа; • механизмы аудита и записи событий, связанных с защитой (audit trail mechanisms); • механизмы привилегий (privilege mechanisms); • мандатный контроль доступа; • механизмы меток (information label mechanisms); • стандартные вызовы криптографических функций. Эти стандарты имеют целью: • обеспечить переносимые приложения теми интерфейсами, которые необходимы для использования информации, связанной с защитой; • расширить и улучшить механизмы защиты, определённые в базовом стандарте (базовый стандарт определяет лишь минимальные функции защиты для многопользовательской системы с POSIX-подобными интерфейсами: функции дискретционного контроля доступа и механизма привилегий). Стандарты POSIX по защите создавались с целью совмещения стандартов по переносимости и способности к взаимодействию для открытых систем и функциональных требований по защите информационных систем. Требования по переносимости и способности к взаимодействию определяются в базовых стандартах POSIX и расширяются в модели OSE. К моменту разработки стандартов POSIX функциональные требования уже существовали в форме критериев оценки защищённости компьютерных систем: • TCSEC (Trusted Computer System Evaluation Criteria) - американские критерии (так называемая "оранжевая книга"); • СТСРЕС (Canadian Trusted Conmuter Product Evaluation Criteria) - канадские критерии; • ITSEC (Informetion Technology Security Evaluation Criteria) - европейские критерии. На их основе был разработан и принят в 1999 г. стандарт ISO 15408 -"Общие критерии" оценки защищённости продуктов и систем информационных технологий. Цель этих документов - обозначить стандартный набор критериев для оценивания способности систем к выполнению функций защиты информации. Эти стандарты, однако, не связаны со стандартами по открытым системам: два продукта или системы, удовлетворяющие одним и тем же критериям и получившие одинаковую оценку защищённости, могут быть совершенно не совместимы между собой в терминах переносимости и способности к взаимодействию. Эти стандарты, однако, не могут полностью разрешить задачу защиты среды открытых систем. Критерии позволяют оценивать конечные продукты, но не спецификации, которым эти продукты могут следовать или не следовать. Кроме того, стандарты IEEE P 1003.1е и 1003.2с могут рассматриваться как относящиеся к внутреннему сервису платформы приложений. Для формирования более полного множества средств защиты они должны дополняться механизмами защиты остальных сервисов АР. С появлением АРР (см. п. 3.2.2), в котором были определе-

ны основные группы сервисов платформы приложений (сервисы операционных систем, человекомашинного взаимодействия, управления данными и сетевые сервисы) набор механизмов защиты существенно расширился. Эти механизмы описаны в различных формах в большом числе стандартов. На международном уровне были стандартизованы методы защиты информации в нескольких классах прикладных программ: СУБД, системах управления сообщениями на основе стандартов ITU серии Х.400, директориальных сервисах на основе стандартов Х.500. В дальнейшем методы защиты информации в компьютерных системах были обобщены и систематизированы в руководствах NIST: • Generally Accepted Principles and Practices for Securing Information Technology Systems. NIST special publication 800-14. — USA National Institute of Standards and Technology, Sept. 1996; • An Introduction to Computer Security: The NIST handbook. NIST special publication 80012. — USA National Institute of Standards and Technology, Oct. 1995. Они использовались при разработке последующих моделей защиты открытых систем.

4.3. Модели защиты информации в документах The Open Group Международная организация The Open Group сформировала самую полную на сегодняшний день систему стандартов по защите информации в открытых системах. Основывается она на общих рекомендациях моделей TOGAF и IT DialTone и следующем положении. Защищённые приложения строятся на фундаменте из сервисов защиты и надёжном наборе нижележащих механизмов защиты. Общую концепцию защиты приложений в распределённой вычислительной среде определяет модель XDSF (X/Open Distributed Security Framework). Набор сервисов защиты, их взаимодействие и управление ими, архитектуру системы защиты в распределённой вычислительной среде описывает модель CDSA (Common Data Security Architecture). Концепцию организованной поддержки механизмов защиты информации (прежде всего криптографических, которые лежат в основе большинства сервисов защиты) описывает модель APKI (Architecture for Public Key Infrastructure). Модель TOGAF рассматривает сервис защиты как кросс-категориальный, т.е. механизмы его реализации могут быть частью множества сервисов различных категорий. Как неизбежно связанные с защитой модель называет сервисы операционных систем, сетевые сервисы, сервисы управления системами и сетями. Независимо от локальной или распределённой системы понятие защиты информации должно быть приложено к целой системе. Модель отмечает, что набор сервисов защиты информации определяется, исходя из анализа предмета защиты, стоимости информации, угроз защищаемой информации. Отмечается четыре основные класса угроз: потеря конфиденциальности данных, потеря доступности, утрата целостности, утрата аутентичности. Противодействие этим угрозам обеспечивается наличием в системе следующих сервисов: • сервисы идентификации и аутентификации, • сервисы контроля точек входа в систему; • сервисы аудита — обеспечивают детальную регистрацию событий, имеющих значение для защиты информации, управление и защиту журналов регистрации событий в системе; • сервисы контроля доступа (в том числе объектного контроля доступа); • сервисы обеспечения неотказуемости (также могут быть объектными) — обеспечивают доказательство того, что пользователь произвёл некоторое действие, послал или принял информацию в определённый момент времени; • сервисы шифрования — являются основой ряда других сервисов, таких как сервисы идентификации и аутентификации, контроля доступа, контроля точек входа в систему и др. они составляют по сути "нижний уровень" сервисов, используемый другими, более высокоуровневыми сервисами защиты. • сервисы обеспечения доверенных каналов связи (trusted communication services) — обеспечивают безопасный способ аутентификации связывающихся сторон друг для друга без риска деперсонификации какой-либо стороны в последующем, безопасный способ генерации и проверки контрольных величин для обеспечения целостности данных, зашифрование/расшифрование данных в коммуникационных каналах, генерацию однонаправленных хэшфункций для поддержки других функций безопасности, способы генерации, распространения,

хранения, резервирования, восстановления и уничтожения криптографических ключей; • сервисы доверенного восстановления данных (trusted recovery services)— обеспечивают способы безопасного доступа к данным, связанным с обеспечением безопасности, такие как восстановление из резервной копии; • сервисы управления защитой — обеспечивают начальную загрузку и инициализацию системы защиты, контроль параметров, управление данными пользователей и системными ресурсами, ограничениями по использованию средств администрирования системы. Сервисы защиты зависят от сервисов административного управления системой и наоборот. Модель IT DialTone уделяет большое внимание организации подсистем защиты информации информационных систем масштаба предприятия, в том числе при их взаимодействии с внешней информационной средой. Утверждается, что в общем случае целью сервиса защиты является: • обеспечение конфиденциальности, аутентичности и целостности взаимных обменов данными между предприятиями и между предприятиями и внешними пользователями; • защита информационных ресурсов и инфраструктуры информационных технологий предприятий от неавторизованного и неучтённого внутреннего и внешнего доступа. С точки зрения задачи обеспечения безопасности информации от глобальной информационной среды необходимо потребовать, чтобы она была достаточно надёжной и безопасной для поддержки высокоценных коммерческих транзакций и для пересылки конфиденциальной информации внутри и между предприятиями. Важное требование заключается в том, что характеристики существующих систем никогда не должны быть существенно ослаблены интеграцией в среду IT DialTone — обычно они должны быть расширены. Графическое представление модели защиты IT DialTone показано на рис.

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

Подсистема защиты информационной среды предприятия состоит из: • множества средств защиты, которые используются прикладными программами и пользователями; • средств управления подсистемой защиты; • шлюзов со средствами управления системой защиты и со средствами защиты, которые не вписываются в данную модель, а достались информационной системе предприятия "по наследству". Вся совокупность средств защиты в модели подразделяется на три взаимосвязанных, но довольно самостоятельных блока: • Инфраструктура защиты информационных технологий предприятия (Enterprise IT

Security Infrastructure) обеспечивает реализацию самых базовых механизмов защиты, поддержку для общих сервисов защиты, а также интерфейсы с "наследственными" средствами и системами защиты. • Инфраструктура безопасного взаимодействия (Secure Intel-working Infrastructure) — это набор функций для поддержки безопасного обмена информацией между предприятиями. В архитектуре IT DialTone он имеет общий с инфраструктурой защиты информационных технологий предприятия набор функций и технологий управления открытыми криптографическими ключами. • Общие сервисы защиты (Generic Security Services — GSS) служат для поддержки распределённых приложений таким образом, при котором обеспечивается способность их к взаимодействию и масштабируем ость. Одни и те же базовые сервисы защиты могут быть логически использованы всеми приложениями через общий набор сервисных интерфейсов и протоколов. При этом самим прикладным программам уже не нужно иметь собственные модули аутентификации, шифрования, протоколов безопасной передачи данных и т.п. Эти сервисы условно подразделяются на четыре группы: сервисы защиты на уровне приложений, сервисы защиты сетевых взаимодействий, сервисы защиты клиент-серверной обработки, сервисы защиты блоков данных. В документах The Open Group описывается примерная структура подсистемы защиты информационной среды предприятия в целом, производится функциональная декомпозиция всех указанных групп средств защиты, приводятся примеры протоколов и спецификаций по каждой из групп. Напомним, что обе модели (TOGAF и IT DialTone) опираются на общую информационную базу стандартов (SIB), которая структурирована в соответствии с классификацией сервисов в TRM - это относится и к сервисам защиты. Так, в SIB включены базовые стандарты по сервисам защиты: ISO/IEC 7498-2:1990 (Архитектура безопасности модели OSI), стандарт Х.509, ряд спецификаций и интерфейсов Х/Ореn. Общий объём SIB довольно значителен. При выборе средств защиты для обеспечения соответствия моделям необходимо руководствоваться стандартами, включёнными в SIB. Однако, общих принципов, изложенных в модели, оказывается недостаточно для построения открытых архитектур защиты в распределённых вычислительных системах. Общая модель оставляет много возможностей для того, чтобы конкретные программные и аппаратные решения, внешне согласующиеся с этой моделью, оставались всё же несовместимыми между собой. Требуется конкретизация общей модели. С этой целью разработаны модели XDSF, CDSA и APKI. Модель XDSF (Х/Ореn Distributed Security Framework) представляет предельно общий взгляд на систему защиты информации в распределённой вычислительной среде с точки зрения прикладного программирования (рис. 20), Она была выдвинута в 1994 г. в качестве каркасной модели для разработки и реализации сервисов защиты в процессе перехода (миграции) от защиты отдельных платформ различных производителей к среде открытых систем. Ранее основным стандартом Х/Ореn, обеспечивающим переносимость средств защиты между отдельными системами, являлась спецификация XBSS (Х/Ореn Baseline Security Services) с набором общих интерфейсов защиты: • GSS-API (General Security Services API); • GCS-API (General Cryptographic Services API); • IDUP-GSS-API (Independent Data Unit Protection General Security Serv-

Рис. 20. Каркасная модель XDSF с точки зрения прикладного программиста

Основная цель модели XDSF - не составить исчерпывающий перечень сервисов защиты в распределённой вычислительной среде, а определить способ, обеспечения сервисов защиты в единообразной форме, изолируя приложения или сервисы АР от разнообразных специфических технологий и средств защиты. С момента создания XDSF организация The Open Group сконцентрировалась на выработке детальных спецификаций для отдельных сервисов (групп сервисов) защиты для гетерогенной распределённой среды: • Secure Communications Services - сервисы защищённых коммуникаций; • Distributed Audit Services (XDAS) - распределённые сервисы аудита; • Generic Cryptographic Services - общие криптографические сервисы; • Secure backup and restore - сервисы безопасного резервного копирования и восстановления данных; • Single Sign-On - сервис однократной регистрации пользователей в гетерогенной среде; • Authorization (Azn API) - сервис авторизации и контроля доступа, основанный на модели стандарта ISO 10181-3; • Information labelling - сервис классификации информации по степени конфиденциальности; • Smart Cards Services - сервисы поддержки интеллектуальных карт; • Trust Services - сервисы описания доверия в распределённой системе -и другие. The Open Group также более детально прорабатывает организацию защиты в некоторых специальных средах приложений: Java-приложения , среда мобильных вычислений, приложения для электронной коммерции, глобальная информационная среда. Модель CDSA (Common Data Security Architecture) основана на одноимённой разработке корпорации Intel. В ней формулируются и принимаются за основу следующие положения. • Цели обеспечения безопасности в открытых распределённых вычислительных средах изменились по сравнению с традиционными целями обеспечения безопасности на объектах (например, масштаба предприятия). В особенности это заметно по отношению к сети Internet: наряду с традиционными видами ресурсов появились новые, субъекты и объекты доступа не могут рассматриваться как размещённые на территориально ограниченном объекте — они "распылены" в среде, появились новые типы приложений (например, широковещательное распространение больших объёмов информации, видеоконференции, "электронная коммерция", "электронные деньги", удалённое управление системами и др.) и новые типы угроз. • Набор функций защиты остался тем же, что и ранее. Основным инструментом попрежнему остаются криптографические механизмы. В связи с этим модель предлагает изменить способы использования криптографических механизмов. Ранее каждое приложение строило

самостоятельное, полное и целостное, решение для выполнения своих функций, используя криптографические механизмы (например, СУБД — свои механизмы шифрования, аутентификации и т.д., программы "электронной почты" — свои механизмы шифрования, цифровой подписи и т.д.). Это приводило к невозможности использования фрагментов кода одних приложений для конструирования других, повышало вероятность ошибок в ПО (особенно, учитывая сложность криптографических алгоритмов и протоколов), не обеспечивало способности приложений к взаимодействию, в ряде стран накладывало ограничения на экспорт ПО. В настоящее время нет недостатка в программных и аппаратно-программных решениях по защите информации. Однако, обычно они создаются как "вертикальные" решения, которые работают только внутри узких границ одного пакета ПО или приложения и не могут быть используемы как сервисы вне этой среды. • Новый путь использования криптографических механизмов предполагает, во-первых, построение многоуровневой, горизонтально-вертикальной структуры сервисов защиты для использования её всеми приложениями, работающими на распределённой платформе, а вовторых, построение так называемой инфраструктуры защиты, т.е. составных частей общего устройства сервисов защиты, носящих подчинённый, вспомогательный характер и обеспечивающих нормальное функционирование защиты в целом (к примеру, механизмы задания правил доверия между компонентами системы, механизмы сертификации открытых ключей, механизмы безопасного хранения криптографических ключей и др.). Такой подход даёт следующие преимущества: сокращается время разработки приложений, улучшается качество и стойкость достигнутой защиты, ускоряется время разработки приложений (так как приложения используют хорошо проверенные, системные компоненты), обеспечивается возможность лёгкого обмена информацией, связанной с защитой, и защищаемыми данными между различными приложениями. CDSA определяет четырёхуровневую модель организации сервисов защиты (рис. 21).

Рис. 21. Архитектура CDSA

Самый нижний уровень занимают встраиваемые модули (add-ins), выполняющие базовые криптографические примитивы (шифрование/расшифрование, генерацию/проверку ЭЦП, вычисление хэш-функции, генерацию (псевдослучайных чисел, операции с криптографическими ключами и т.п.) и реализующие базовые элементы инфраструктуры: библиотеки сертификатов открытых ключей, библиотеки моделей доверия, библиотеки для хранения информации, связанной с защитой, службы доверенного доступа к криптографическим ключам и восстановления утраченных криптографических ключей (key recovery). Эти модули могут быть реализо-

ваны фирмами-производителями любым способом, который будет обеспечивать соответствие специфицированным в модели интерфейсам: аппаратно (датчики случайных чисел, смарткарты, электронные ключи, адаптеры и др.), программно (в том числе путём эмуляции аппаратной реализации модуля) либо аппаратно-программно. Предполагается возможность расширения номенклатуры таких модулей в будущем. Второй (снизу) уровень занимает так называемый общий менеджер серви-сов защиты (CSSM — Common Security Services Manager) — это ядро системы защиты, которое выполняет функции управления сервисами защиты, вызывает встраиваемые модули нижнего уровня и предоставляет стандартный интерфейс (CSSM Security API) для компонентов верхнего уровня. Функции CSSM в соответствии со спецификацией CDSA должны быть реализованы для каждой вычислительной платформы отдельно. Третий уровень слагают системные сервисы защиты, соответствующие по принятой терминологии middleware-уровню и программные продукты, предоставляющие инструменты для приложений, т.е. являются надстройкой над базовыми функциями вычислительных систем, которая обеспечивает формирование для прикладного ПО и пользователей образа единой распределённой системы. Примерами ПО этого уровня являются межсетевые экраны, антивирусные пакеты, пакеты для электронной коммерции и др. Наконец, последний, верхний уровень — это приложения, использующие стандартные высокоуровневые сервисы защиты и сервисы CSSM в своих целях. Продукты и решения, соответствующие CDSA, созданы уже многими ведущими фирмами-производителями: IBM (KeyWorks, ПО для AIX, OS/390, OS/400), Motorola (CipherNET), Apple, Compaq (Tru64 UNIX), HP (HP-UX vl 1), Group Bull (Linux Red Hut). Модель APKI (Architecture for Public Key Infrastructure). Инфраструктура открытых ключей (public key infrastructure — PKI) — это универсальная концепция организованной поддержки криптографических средств защиты информации в крупномасштабных информационных системах в соответствии с принятыми в них политиками безопасности, которая реализует управление криптографическими ключами на всех этапах их жизненного цикла, обеспечивая взаимодействие всех средств защиты распределённой системы. Известно много попыток создания стандартов инфраструктуры открытых ключей различными фирмами и международными организациями. Наиболее значительные из них — это проекты SPKI (Simple Public-key Infrastructure) и PKIX (Public-Key Infrastructure X.509 ) организации IETF, существующие в виде стандартов де-факто. Проект SPKI направлен на создание простой, минимально необходимой криптографической инфраструктуры. Проект PKIX обеспечивает существенно более широкую функциональность и основан на стандарте ITU X.509. В него включены несколько уже утверждённых стандартов RFC и порядка двадцати проектов (draft) стандартов RFC.

Рис. 22. Архитектурная модель APKI

Модель APKI (Architecture for Public-Key Infrastructure) является значительным расширением PKIX, она описывает архитектуру для инфраструктуры открытых ключей. Архитектура APKI является первой попыткой создания всеобъемлющей, полнофункциональной системы

поддержки всей многоуровневой иерархии криптографических средств защиты: от примитивов до протоколов. Основными уровнями APKI (рис. 22) являются: • криптографические примитивы - эти компоненты обеспечивают доступ к низкоуровневым криптографическим функциям, таким как генерация ключей, генерация (псевдо)случайных чисел, вычисление хэш-кодов, зашифрование и расшифрование блоков данных симметричным или асимметричным алгоритмом и т.п.; • криптографические сервисы - обеспечивают криптографические функции (включая и симметричные криптографические алгоритмы) для асимметричной криптосистемы защищаемой распределённой вычислительной среды: сервис конфиденциальности данных, сервис целостности данных, сервис подписывания данных, сервис распределения ключей, контролируемое использование ключей и т.д.; • сервисы манипулирования долговременными ключами (long-term key services) позволяют пользователям и другим субъектам распределённой системы управлять своими собственными долговременными ключами и сертификатами открытых ключей (на всех этапах их жизненного цикла), а также получать доступ и проверять действительность сертификатов других субъектов; • сервисы защиты протоколов предоставляют функции защиты, пригодные для использования при реализации приложений, "осведомлённых" о системных компонентах защиты (security-aware applications), таких как защищённые протоколы; они включают механизмы делегирования полномочий, управления контекстом защиты, механизмы соглашения о приобретении ключей и др.; • защищённые протоколы обеспечивают средства для защищённого взаимодействия приложений, "не осведомлённых" или "слабо осведомлённых" о системных средствах и сервисах защиты (security-unaware, "mildy" security-aware applications) и включают три группы сервисов: сервисы защиты сеансов связи (session-oriented services), сервисы, ориентированные на связь без установления соединения (store-and- forward services) и их частный случай - сервисы обеспечения неотказуемости (non-repudiation services). Дополнительно в архитектуру APKI включены: • системные сервисы обеспечения защиты (system security-enabling services) - обеспечивают функции, которые позволяют устанавливать идентичность пользователей и других субъектов распределённой системы и ассоциировать с ними их действия и события в распределённой системе; • сервисы реализации политики безопасности (security policy services) предоставляют информацию, связанную с политикой безопасности, которая должна переноситься в защищённых протоколах, чтобы сделать возможным контроль доступа и обеспечить возможности проверки доступа для таких приложений ("осведомлённых" о системной защите), которые должны "проводить в жизнь" политику безопасности; • сервисы поддержки (supporting services) обеспечивают функции, которые требуются для создания защиты, но не вовлечены непосредственно в реализацию политики безопасности: сервисы аудита, сервисы времени, директориальные сервисы. APKI опирается на широкую базу стандартов RFC. Ссылки и замечания к гл. 4: п. 4.1: Архитектура защиты информации в модели ISO OSI рассматривается в основном по [З], сведения о других стандартах ISO, упоминаемых в этом разделе, взяты со страниц ISO в сети Internet / http : //www. iso. ch/ и из [18, ch. 15]. п. 4.2: Характеристика защиты информации в модели POSIX основана на материалах [21]. п. 4.3: Модели защиты информации рассматриваются по материалам и текстам стандартов, опубликованным на страницах в сети Internet: /http://www.opengroup.org/security7, CDSA — по документам [9,10], APKI- no документу [8]. Информация о моделях носит справочный характер.

ЗАКЛЮЧЕНИЕ. Роль стандартизации в развитии информационных технологий Развитие методов и средств распределённой обработки данных, концепция открытых систем сыграли немалую роль в становлении современного сложного комплекса информационных технологий. Одной из основ этого процесса, в особенности в последнее время (конец 80-х 90-е гг.), являлась непрерывная аналитическая и исследовательская работа множества международных организаций, промышленных групп, фирм-производителей. Результатом такой работы становилась разработка технических документов и принятие их в качестве стандартов в сфере информационных технологий. Благодаря этому сегодня уже можно говорить о формировании определённой теоретической базы в области распределённой обработки данных и отдельных проблем, неизбежно возникающих при создании и использовании современных информационных технологий. Одной из центральных проблем является обеспечение безопасности информации при её обработке, передаче, хранении в информационных системах, построенных на основе сложных распределённых систем обработки данных. В настоящее время наблюдается тенденция заметного усиления роли стандартизации в области информационных технологий, резкого увеличения количественного и изменения качественного состава стандартов. Число и объём стандартов, выпускаемых различными международными организациями и промышленными группами, их сложность, нарастают лавинообразно. Представление о динамике этого процесса даёт такой пример (по данным The Open Group). Первые спецификации операционных систем для среды открытых систем, созданные в рамках проекта POSIX (начало 1990-х гг.), насчитывали порядка 100...200 интерфейсов, последующие стандарты в рамках модели AES - 400...500 интерфейсов, спецификация XPG4 Base - 607 спецификаций интерфейсов. Действующие в настоящее время стандарты Single UNIX (1995 г.) и Single UNIX v2 (1998 г.) включают в себя 1168 и 1434 спецификации соответственно, а профиль стандартов UNIX 98 Workstation с поддержкой графического интерфейса пользователя -3030 спецификаций. В то же время растущая сложность создания продуктов и систем информационных технологий подвигает различные фирмы ко всё более тесному схождению своих стратегий, позиций и взглядов на развитие информационных технологий. В документах The Open Group даже отмечается, что на первых этапах развития информационных технологий положение дел напоминало то, что происходило в XIX в. с железнодорожным строительством. Тогда множество компаний,совершенно не задумываясь о долговременном развитии транспорта, а заботясь только о сиюминутной выгоде, использовали каждая свою ширину рельсовой колеи, различные системы сигнализации и автоматики, различные габариты подвижного состава, напряжение в контактной сети, уклон и радиус поворота пути и т.д. В результате с ростом объёма перевозок грузов и пассажиров осуществить объединение всех железных дорог в единую глобальную мировую транспортную систему оказалось практически нереально, в то время как обеспечить "переносимость" вагонов и "способность к взаимодействию" между различными железными дорогами можно было бы, утвердив минимум обязательных для всех стандартов: предельную ширину колеи, предельные габариты вагонов, минимальную сигнальную систему. Из-за отсутствия даже таких стандартов обеспечить полную совместимость между железными дорогами разных стран оказалось вообще невозможно: этому мешают, например, узкие тоннели и мосты, негабаритные платформы станций и т.п. Положение было исправлено лишь с участием ISO, создавшей стандарты по единой системе контейнерных перевозок грузов. Развитие стандартизации открытых информационных систем явилось результатом понимания недопустимости повторения таких ошибок в сфере информационных технологий при формировании глобальной "информационной транспортной системы". Исправить их было бы, наверное, многократно тяжелее в силу высокой сложности современных информационных технологий. В этом очень велика заслуга стандартов и других координирующих документов международных организаций.