Раздел VII

СТАНДАРТИЗАЦИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

 

Глава 18

ОСНОВЫ ПОСТРОЕНИЯ СИСТЕМЫ СТАНДАРТОВ ИТ

 

18.1. Понятие открытых систем

 

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

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

Единое информационное пространство складывается из следующих основных составляющих:

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

• организационные структуры, обеспечивающие функционирова­ние и развитие единого информационного пространства: поиск, сбор, обработку, хранение, защиту и передачу информации;

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

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

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

История концепции открытых систем начинается с того момента, когда возникла проблема переносимости (мобильности) программ и данных между компьютерами с различной архитектурой [9]. Одним из первых шагов в этом направлении, оказавшим влияние на развитие отечественной вычислительной техники, явилось создание компью­теров серии IBM 360, обладающих единым набором команд и способ­ных работать с одной и той же операционной системой. Корпорация «IBM», кроме того, предоставляла лицензии на свою ОС пользовате­лям, которые предпочли купить компьютеры той же архитектуры у других производителей.

Частичное решение проблемы мобильности для программ обеспе­чили ранние стандарты языков, например ФОРТРАН и КОБОЛ. Языи позволяли создавать переносимые программы, хотя часто ограни­чивали функциональные возможности. Мобильность обеспечивалась также за счет того, что эти стандарты были приняты многими произ­водителями различных платформ. Когда языки программирования приобрели статус стандарта де-факто, их разработкой и сопровожде­нием начали заниматься национальные и международные организа­ции по стандартизации. В результате языки развивались уже незави­симо от своих создателей. Достижение мобильности уже на этом уровне было первым примером истинных возможностей открытых систем.

Следующий этап в развитии концепции открытости — вторая по­ловина 1970-х гг. Он связан с областью интерактивной обработки и увеличением объема продуктов, для которых требуется переносимость (пакеты для инженерной графики, системы автоматизации проекти­рования, базы данных, управление распределенными базами данных). Компания «DIGITAL» начала выпуск мини-ЭВМ VAX, работающих под управлением операционной системы VMS. Машины этой серии имели уже 32-разрядную архитектуру, что обеспечило значительную эффективность программного кода и сократило издержки на работу с виртуальной памятью. Программисты получили возможность напря­мую использовать адресное пространство объемом до 4 Гбайт, что прак­тически снимало все ограничения на размеры решаемых задач. Маши­ны этого типа надолго стали стандартной платформой для систем про­ектирования, сбора и обработки данных, управления экспериментом и т.п. Именно они стимулировали создание наиболее мощных САПР, систем управления базами данных и машинной графики, которые широко используются до настоящего времени.

Конец 1970-х гг. характеризуется массовым применением сетевых технологий. Компания «DIGITAL» интенсивно внедряла свою архитек­туру DECnet. Сети, использующие протоколы Интернет (TCP/IP), пер­воначально реализованные Агентством по перспективным исследова­ниям Министерства обороны США (DARPA), начали широко приме­няться для объединения различных систем — как военных, так и академических организаций США. Фирма «IBM» применяла собствен­ную сетевую архитектуру SNA (System Network Architecture), которая стала основой для предложенной Международной организацией по стан­дартизации ISO архитектуры Open Systems Interconnection (OSI).

Когда сетевая обработка стала реальностью и насущной необходи­мостью для решения большого числа технических, технологических, научных экономических задач, пользователи начали обращать внима­ние на совместимость и возможность интеграции вычислительных средств как на необходимые атрибуты открытости систем. Организа­ция ISO в 1977—1978 гг. развернула интенсивные работы по созда­нию стандартов взаимосвязи в сетях открытых систем. Тогда же впер­вые было введено определение открытой информационной системы.

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

Существует достаточное число определений, даваемых различны­ми организациями по стандартизации и отдельными фирмами. Напри­мер, Ассоциация французских пользователей UNIX и открытых сис­тем (AFUU) дает следующее определение: «Открытая система — это система, состоящая из элементов, которые взаимодействуют друг с другом через стандартные интерфейсы».

Производитель средств вычислительной техники — компания Hewlett Packard: «Открытая система — это совокупность разнородных компьютеров, объединенных сетью, которые могут работать как еди­ное интегрированное целое независимо от того, как в них представлена информация, где они расположены, кем они изготовлены, под уп­равлением какой операционной системы они работают».

Определение Национального института стандартов и технологий США (NIST): «Открытая система — это система, которая способна взаимодействовать с другой системой посредством реализации меж­дународных стандартных протоколов. Открытыми системами являют­ся как конечные, так и промежуточные системы. Однако открытая си­стема не обязательно может быть доступна другим открытым систе­мам. Эта изоляция может быть обеспечена или путем физического отделения, или путем использования технических возможностей, ос­нованных на защите информации в компьютерах и средствах комму­никаций».

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

• технические средства, на которых реализована информационная система, объединяются сетью или сетями различного уровня — от ло­кальной до глобальной;

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

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

• открытые системы предполагают использование унифицирован­ных интерфейсов в процессах взаимодействия в системе «человек — компьютер»;

• применение положений открытости предполагает некоторую из­быточность при разработке программно-аппаратных комплексов.

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

Это определение, сформулированное специалистами Комитета IEEE POSIX 1003.0 Института инженеров по электротехнике и элек­тронике (IEEE), унифицирует содержание среды, которую предостав­ляет открытая система для широкого использования. Базовым в этом определении является термин «открытая спецификация», имеющий следующее.толкование: «это общедоступная спецификация, которая поддерживается открытым, гласным, согласительным процессом, на­правленным на постоянную адаптацию новой технологии, и которая соответствует стандартам». Таким образом, под открытыми система­ми следует понимать системы, обладающие стандартизованными ин­терфейсами. Решение проблемы открытости систем основывается на стандартизации интерфейсов систем и протоколов взаимодействия между их компонентами.

В качестве примеров использования технологии открытых систем можно привести технологии фирм «Intel» Plug&Play и USB, а также операционные системы UNIX и (частично) ее основного конкурента — Windows NT. Многие новые продукты сразу разрабатываются в соот­ветствии с требованиями открытых систем, примером тому может слу­жить широко используемый в настоящее время язык программирова­ния Java фирмы «Sun Microsystems».

Общие свойства открытых информационных систем можно сфор­мулировать следующим образом:

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

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

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

• мобильность/переносимость — обеспечение возможности переноса прикладных программ и данных при модернизации или замене аппа­ратных платформ ИС и возможности работы с ними специалистов пользующихся ИТ, без их специальной переподготовки при измене­ниях ИС;

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

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

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

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

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

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

Трансформация унаследованных систем. Практически любая систе­ма после создания и внедрения противодействует изменениям и имеет тенденцию быстрого превращения в бремя организации. Унаследован­ные системы (Legacy Systems), построенные на «уходящих» техноло­гиях, архитектурах, платформах, а также программное и информаци­онное обеспечение, при проектировании которых не были предусмот­рены нужные меры для их постепенного перерастания в новые системы, требуют перестройки (Legacy Transformation) в соответствии с новы­ми требованиями бизнес-процессов и технологий. В процессе транс­формации необходимо, чтобы новые модули системы и оставшиеся компоненты унаследованных систем сохраняли способность к взаимо­действию.

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

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

Свойство интероперабельности информационных ресурсов явля­ется необходимой предпосылкой удовлетворения перечисленных выше требований.

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

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

Принципы создания и использования открытых систем применя­ются в настоящее время при построении большинства классов систем:вычислительных, информационных, телекоммуникационных, систем управления в реальном масштабе времени, встроенных микропроцес­сорных систем. В условиях широкого использования интегрирован­ных вычислительно-телекоммуникационных систем принципы откры­тости составляют основу технологии интеграции, В развитии и при­менении открытых систем заинтересованы все участники процесса информатизации: пользователи, проектировщики систем и системные интеграторы, производители технических и программных средств вы­числительной техники и телекоммуникации. В частности, по встроен­ным микропроцессорным системам (МПС) в рамках программы ESPRIT существует проект OMI (Open Microprocessor Initiative), на­правленный на создание коллективной пользовательской библиотеки МПС в соответствии с принципами открытых систем.

В условиях перехода к информационному обществу, когда государ­ственное управление и большинство секторов экономики становятся активными потребителями информационных технологий, а сектор производителей средств и услуг информационных технологий непре­рывно растет, проблема развития и применения открытых систем со­ставляет для каждой страны национальную проблему. Так, админист­рация Клинтона еще в 1993 г. объявила о программе создания Нацио­нальной информационной инфраструктуры на принципах открытых систем (National Information Infrastructure Initiative), вкладывала в эту программу большие деньги и содействовала инвестициям со стороны частного сектора. Совет Европы в 1994 г. в своих рекомендациях о пу­тях перехода к информационному обществу (Bangemann Report) под­черкнул, что стандарты открытых систем должны играть важнейшую роль при создании информационной инфраструктуры общества. Ве­дется работа по созданию глобальной информационной инфраструк­туры, также основанной на принципах открытых систем.

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

 

18.2. Международные структуры в области стандартизации информационных технологий

 

Значение принципа взаимосвязи открытых систем стало осозна­ваться, когда глобализация экономики и бизнеса в рамках единого эко­номического пространства Европы привела к необходимости унифи­кации применяемых информационных систем и технологий. Вначале каждая страна или компании развивали свои программные и сетевые концепции и технические средства, которые часто оказывались несов­местимыми. Различные концептуальные направления имели свои системы форматов данных и обмена данными, например система SWIFT в банковской сфере, EDIFAST в торговле, промышленности, на транспорте. Из-за различий в протоколах системы были несовмести­мы и не могли быть интегрированы в единое целое. Таким образом, подобные ситуации дали толчок развитию международной стандар­тизации в области ИТ.

Область ИТ очень динамична, она характеризуется быстрыми темпа­ми развития. При этом определяющую роль в формировании стратеги­ческих ориентиров процесса развития играют глобальные концепции. К важнейшим глобальным концепциям, прежде всего относятся концепция открытых систем и концепция Глобальной информационной инфраструк­туры (Global Information Infractracture — GII), которые для практичес­кого воплощения требуют не только развитой научно-методической базы и всеобъемлющей системы стандартов, но и сами могут рассматриваться как вехи процесса стандартизации ИТ. Отсюда следует, что процесс стан­дартизации ИТ также приобрел глобальный характер. Его целью являет­ся полномасштабная комплексная стандартизация ИТ.

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

• глобальные концепции развития области ИТ;

• концептуальный базис и эталонные модели построения основных разделов ИТ;

• функции, протоколы взаимодействия, интерфейсы и другие ас­пекты ИТ;

• языки программирования, языки спецификации информацион­ных ресурсов, языки управления базами данных;

• модели технологических процессов создания и использования систем ИТ, а также языки описания таких моделей;

• методы тестирования соответствия (конформности) систем ИТ исходным стандартам и профилям;

• методы и процедуры функционирования собственно системы стандартов ИТ;

• метаязыки и нотации для описания стандартов ИТ;

• общесистемные функции ИТ, например безопасность, админист­рирование, интернационализация, качество сервисов; и пр.

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

• несколько сотен международных и национальных стандартов не полностью и неравномерно удовлетворяют потребности в стандарти­зации объектов и процессов создания и применения сложных ИС;

• длительные сроки разработки, согласования и утверждения меж­дународных и национальных стандартов (3—5 лет) приводят к их кон­серватизму и хроническому отставанию от современных технологий создания сложных ИС;

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

• в области ИС функциональными стандартами поддержаны и рег­ламентированы только самые простые объекты и рутинные, массовые процессы (телекоммуникация, программирование, документирование программ и данных);

• наиболее сложные и творческие процессы создания и развития круп­ных распределенных ИС (системный анализ и проектирование, интегра­ция компонентов и систем, испытания и сертификация ИС и т.п.) почти не поддержаны требованиями и рекомендациями стандартов из-за раз­нообразия содержания, трудности их формализации и унификации;

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

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

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

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

На рис. 18.1 представлена система авторитетных международных организаций (ISO — Международная организация стандартизации, IEC — Международная электротехническая комиссия), играющие зна­чительную роль в решении задач стандартизации ИТ.

 

 

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

• IEEE (Институт инженеров по электротехнике и электронике — международная организация — разработчик ряда важных международ­ных стандартов в области ИТ);

• CEN (Европейский комитет стандартизации широкого спектра товаров, услуг и технологий, в том числе связанных с областью разра­ботки ИТ, аналог ISO);

• CENELEC (Европейский комитет стандартизации решений в электротехнике, в частности стандартизации коммуникационных ка­белей, волоконной оптики и электронных приборов — аналог IEC);

• ETSI (Европейский институт стандартизации в области сетевой инфраструктуры — аналог ITU-T);

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

• ЕСМА (Европейская ассоциация производителей вычислитель­ных машин — международная ассоциация, целью которой служит про­мышленная стандартизация информационных и коммуникационных систем); и др.

В 1987 г. ISO и IEC объединили свою деятельность в области стан­дартизации ИТ, создав единый орган JTC1 (Joint Technical Committee 1 — Объединенный технический комитет 1), предназначенный для формирования всеобъемлющей системы базовых стандартов в облас­ти ИТ и их расширений для конкретных сфер деятельности.

К основным целям Комитета JTC1 относятся разработка, поддер­жание, продвижение стандартов ИТ, являющихся необходимыми для глобального рынка, удовлетворяющих требованиям бизнеса и пользо­вателей и имеющих отношение:

• к проектированию и разработке систем и средств ИТ;

• производительности и качеству продуктов и систем ИТ;

• безопасности систем ИТ и информации;

• переносимости прикладных программ;

• интероперабельности продуктов и систем ИТ;

• унифицированным средствам и окружениям;

• гармонизированному словарю понятий области ИТ;

• дружеским и эргономичным пользовательским интерфейсам. Работа над стандартами ИТ в JTC1 тематически распределена по

подкомитетам (Subcommittees — SC). Ниже показаны подкомитеты и группы JTC1, связанные с разработкой стандартов ИТ, относящихся к окружению открытых систем OSE (Open Systems Environment).

• С2 — символьные наборы и кодирование информации;

• SC6 — телекоммуникация и информационный обмен между сис­темами;

• SC7 — разработка программного обеспечения и системная доку­ментация;

• SC18 — текстовые и офисные системы;

• SC21 — открытая распределенная обработка (Open Distributed Processing — ODP), управление данными (Data Management — DM) и взаимосвязь открытых систем (Open System Interconnection — OSI);

• SC22 — языки программирования, их окружения и интерфейсы системного программного обеспечения;

• SC24 — компьютерная графика;

• SC27 — общие методы безопасности для ИТ-приложений;

• SGFS — специальная группа по функциональным стандартам. Результатом целенаправленной деятельности по стандартизации

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

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

 

18.3. Методологический базис открытых систем

 

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

Такое толкование и единая методологическая база связаны с общи­ми принципами построения информационных систем и применяемы­ми средствами анализа и разработки. Она реализована в виде методо­логического базиса открытых систем [7].

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

• создание системы специализированных международных орга­низаций по целостной разработке и стандартизации открытых сис­тем;

• разработка эталонных моделей и соответствующих им базовых спецификаций для важнейших разделов области ИТ, что позволило сформировать концептуальный и функциональный базис простран­ства ИТ/ИС;

 • разработка и широкое использование концепции профиля, пре­доставляющей аппарат для спецификации и документирования слож­ных и многопрофильных открытых ИТ/ИС, задающих функциональ­ности базовых спецификаций и (или) профилей;

• разработка таксономии профилей, представляющей собой клас­сификационную систему ИТ/ИС и обеспечивающую систематичес­кую идентификацию профилей в пространстве ИТ/ИС;

• разработка концепции и методологии соответствия реализаций ИТ/ИС тем спецификациям, которые ими реализуются.

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

В данной модели выделены следующие уровни спецификаций ин­формационных технологий:

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

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

 

 

• предметные, или локальные, профили ЯГ (например, OSI-профили, API-профили), т.е. профили, разрабатываемые на основе исполь­зования базовых спецификаций, которые относятся к предметной об­ласти, описанной одной эталонной моделью (возможно вместе с про­филями форматов данных, т.е. F-профилями);

• OSE-профили — спецификации поведения открытых систем на их границах (интерфейсах), объединяющие базовые спецификации и (или) профили, базирующиеся на различных эталонных моделях, в Целевые комплексы;

• полные OSE-профили открытых платформ и систем — специфи­кации, предназначенные для описания поведения ИТ-систем на всех их интерфейсах;

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

• стратегические профили (например, International Standardized Profiles — IPS, Government Open System Interconnection Profile — GOSIP), т.е. профили, рассматриваемые в данном случае не как спе­цификации одной технологии, а как наборы стандартов, определяю­щих техническую политику в области телекоммуникации и открытых технологий крупной организации или даже государства.

 

18.4. Архитектурные спецификации (эталонные модели)

 

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

Эталонные модели определяют архитектуру наиболее важных и достаточно независимых разделов ИТ. Таким образом, каждая эталон­ная модель представляет собой концептуальный и методологический базис конкретного раздела ИТ, определяя структуру множества базо­вых спецификаций, соответствующих данному разделу. Наиболее из­вестными эталонными моделями являются (в квадратных скобках приведена ссылка на соответствующий стандарт, описывающий эта­лонную модель) [6]:

1. Базовая эталонная модель взаимосвязи открытых систем (Basic Reference Model for Open Systems Interconnection — RM-OSI) [ISO 7498:1984, Information processing systems —Open Systems Intercon­nection, Basic Reference Model, ITU-T Rec. X.200 (1994)].

2.  Руководство по окружению открытых систем POSIX (Portable Operating System Interface for Computer Environments — RM API) [ISO/IEC DTR 14252, Portable Operating System Interface for Computer Environments - POSIX-IEEE, P1003.0, Draft Guide to the POSIX Open System Environment, February 1995].

3.  Эталонная модель для открытой распределенной обработки (Reference Model for Open Distributed Processing - RM-ODP) [ITU-T Rec. 902|ISO/IEC 10746-2:1995, Reference Model for Open Distributed Processing].

4. Эталонная модель управления данными (Reference Model for Data Management- RM DF) [DIS 9075:1992, Information technology -Reference Model for Data Management].

5.  Эталонная модель компьютерной графики (Reference Model of Computer Graphics- RM CG) [ISO/IEC 11072:1992, Information Technology. Computer Graphics — Computer Graphics Reference Model].

6. Эталонная модель текстовых и офисных систем (Text and Office Systems   Reference   Model)   [ISO/IEC   TRTOSM-1,   Information technology. Text and office systems reference model — Part 1. Basic reference model].

7. Общая модель распределенных офисных приложений [ISO/IEC 10031/1:1991,   Information   technology—   Text   communication — Distributed-office-applications model — Part 1. General model].

В процессе разработки находятся следующие эталонные модели:

• модель конформности (Coformality — соответствия, подобия) и методы тестирования конформности, называемые также методами ат­тестационного тестирования;

• модель основ общей безопасности (Generic Security Frameworks);

• модель качества OSI-сервиса (Quality of Service for OSI).

 

18.5. Эталонная модель взаимосвязи открытых систем

 

18.5.1. Эталонная модель среды открытых

систем (модель OSE)

 

Требование совместимости и взаимодействия прикладных про­грамм привело к разработке системы стандартов «Интерфейс перено­симой операционной системы» (свод POSIX-стандартов) и стандар­тов коммуникаций. Однако эти стандарты не охватывают требуемый спектр потребностей даже в рамках установленной для них области распространения. Дальнейшее развитие стандартизации в области информационных технологий и формирования принципа открытых систем нашло выражение в создании функциональной среды откры­тых систем (Open Systems Environment — OSE) и построении соот­ветствующей модели, которая охватывала бы стандарты и специфика­ции по обеспечению возможностей ИТ [2].

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

• системы реального времени (Real Time System — RTS) и встроен­ные системы (Embedded System — ES);

• системы обработки транзакций (Transaction Processing System — TPS);

• системы управления базами данных (DataBase Management System - DBM);

• разнообразные системы поддержки принятия решения (Decision Support System - DSS);

• управленческие информационные системы административного (Executive Information System — EIS) и производственного (Enterprise Resource Planning — ERP) назначения;

• географические информационные системы (Geographic Infor­mation System — GIS);

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

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

• выполняются на любой используемой платформе поставщика или пользователя;

• используют любую ОС;

• обеспечивают доступ к базе данных и управление данными;

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

• взаимодействуют с пользователями через стандартные интерфей­сы в системе общего интерфейса «пользователь — компьютер».

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

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

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

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

Рабочая группа 1003.0 POSIX IEEE разработала эталонную модель OSE (Open Systems Environment / Reference Model — OSE/RM). Эта модель описана на международном уровне в техническом отчете TR 14250 комитета JTC1 (рис. 18.3).

В ее описании используется два типа элементов:

• логические объекты, включающие в себя ППО, прикладные плат­формы и внешнюю функциональную среду;

• интерфейсы, содержащие интерфейс прикладной системы и ин­терфейс обмена с внешней средой.

Логические объекты представлены тремя классами, интерфейсы — двумя.

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

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

Внешняя среда платформ состоит из элементов, внешних по отно­шению к ППО и прикладной платформе (например, внешние перифе­рийные устройства, услуги других платформ, операционных систем или сетевых устройств).

Интерфейс прикладной программы (Application Program Interface — API) является интерфейсом между ППО и прикладной платформой. Основная функция API — поддержка переносимости ППО. Класси­фикация API производится в зависимости от типа реализуемых ус­луг: взаимодействие в системе «пользователь — компьютер», обмен ин­формацией между приложениями, внутренние услуги системы, ком­муникационные услуги.

Интерфейс обмена с внешней средой (External Environment Interface — EEI) обеспечивает передачу информации между приклад­ной платформой и внешней средой, а также между прикладными про­граммами, которые выполняются на одной платформе.

   Эталонная модель OSE/RM реализует и регулирует взаимоотношения «поставщик — пользователь». Логические объекты прикладной платформы и внешней среды являются поставщиком услуг, ППО — пользователем. Среда OSE обеспечивает функционирование ППО, используя определенные правила, компоненты, методы сопряжения элементов системы (Plug Compatibility) и модульный подход к разра­ботке программных и информационных систем. Достоинствами моде­ли являются выделение внешней среды в самостоятельный элемент, имеющий определенные функции и соответствующий интерфейс, и возможность ее применения для описания систем, построенных на основе архитектуры «клиент-сервер». Относительный недостаток — еще не все требуемые спецификации представлены на уровне между­народных гармонизированных стандартов.

 

18.5.2. Базовая эталонная модель взаимосвязи открытых систем

(модель OSI)

 

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

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

2) среды или системной части, обеспечивающей исполнение при­кладных программ.

С этим разделением и обеспечением взаимосвязи тесно связаны две группы вопросов стандартизации:

1) стандарты интерфейсов взаимодействия прикладных программ со средой ИС, прикладной программный интерфейс (Application Program Interface — API);

2)  стандарты интерфейсов взаимодействия самой ИС с внешней для нее средой (External Environment Interface — EEI).

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

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

Эта модель используется более 20 лет, она «выросла» из сетевой архитектуры SNA (System Network Architecture), предложенной ком­панией «IBM». Модель взаимосвязи открытых систем OSI (Open Systems Interconnection) используется в качестве основы для разработ­ки многих стандартов ISO в области ИТ. Публикация этого стандарта подвела итог многолетней работы многих известных телекоммуника­ционных компаний и стандартизующих организаций.

В 1984 г. модель получила статус международного стандарта ISO 7498, а в 1993 г. вышло расширенное и дополненное издание ISO 7498-1-93. Стандарт имеет составной заголовок «Информационно-вычис­лительные системы — Взаимосвязь (взаимодействие) открытых сис­тем — Эталонная модель». Краткое название — «Эталонная модель взаимосвязи (взаимодействия) открытых систем» (Open Systems Interconnection / Basic Reference Model — OSI/BRM).

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

 

 

 

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

В соответствии с ISO 7498 выделяют семь уровней (слоев) инфор­мационного взаимодействия, которые отделены друг от друга стандарт­ными интерфейсами:

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

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

3) сеансовый (уровень сессии);

4) транспортный;

5) сетевой;

6) канальный;

7) физический.

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

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

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

Инкапсуляция — это процесс помещения фрагментированных бло­ков данных одного уровня в блоки данных другого уровня.

При разбиении среды на уровни соблюдались следующие принципы:

• не создавать слишком много мелких разбиений, так как это ус­ложняет описание системы взаимодействий;

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

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

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

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

• проводить границу между уровнями в таком месте, где в опреде­ленный момент должен существовать соответствующий стандартный интерфейс.

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

Уровень 1 — уровень приложения (прикладной уровень). Этот уро­вень связан с прикладными процессами. Протоколы предназначены для обеспечения доступа к ресурсам сети и программам-приложени­ям пользователя. На данном уровне определяется интерфейс с комму­никационной частью приложений. В качестве примера можно привес­ти протокол Telnet, который обеспечивает доступ пользователя к хосту (глазному вычислительному устройству, одному из основных Элементов в многомашинной системе, или любому устройству, под­ключенному к сети и использующему протоколы TCP/IP) в режиме удаленного терминала.

Уровень 2 — уровень представления. На этом уровне информация преобразуется к такому виду, в каком это требуется для выполнения прикладных процессов. Например, выполняются алгоритмы преобра­зования формата представления данных — ASC II или КОИ-8. Если для представления данных используется дисплей, то эти данные по заданному алгоритму формируются в виде страницы, которая выво­дится на экран.

Уровень 3 — сеансовый уровень (уровень сессии). На данном уровне устанавливаются, обслуживаются и прекращаются сессии между пред­ставительными объектами приложений (прикладными процессами). В качестве примера протокола сеансового уровня можно рассмотреть протокол RPC (Remote Procedure Call). Как следует из названия, дан­ный протокол предназначен для отображения результатов выполне­ния процедуры на удаленном хосте. В процессе выполнения этой про­цедуры между приложениями устанавливается сеансовое соединение. Назначением данного соединения является обслуживание запросов, которые возникают, например, при взаимодействии приложения-сер­вера с приложением-клиентом.

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

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

Уровень 5 — сетевой уровень. Основной задачей протоколов сете­вого уровня является определение пути, который будет использован для доставки пакетов данных при работе протоколов верхних уров­ней. Для того чтобы пакет был доставлен до какого-либо хоста, этому хосту должен быть поставлен в соответствие известный передатчику сетевой адрес. Группы хостов, объединенные по территориальному принципу, образуют сети. Для упрощения задачи маршрутизации се­тевой адрес хоста составляется из двух частей: адреса сети и адреса хоста. Таким образом, задача маршрутизации распадается на две: по­иск сети и поиск хоста в этой сети.

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

На канальном уровне данные передаются в виде блоков, которые называются кадрами. Тип используемой среды передачи и ее тополо­гия во многом определяют вид кадра протокола транспортного уров­ня, который должен быть использован. При использовании тополо­гии «общая шина» и Point-to-Multipoint средства протокола каналь­ного уровня задают физические адреса, с помощью которых будет производиться обмен данными в среде передачи и процедура доступа к этой среде. Примерами таких протоколов являются протоколы Ethernet (в соответствующей части) и HDLC. Протоколы транспорт­ного уровня, которые предназначены для работы в среде типа «точка-

точка», не определяют физических адресов и имеют упрощенную про­цедуру доступа. Примером протокола такого типа является протокол РРР.

Уровень 7 — физический уровень. Протоколы этого уровня обеспе­чивают непосредственный доступ к среде передачи данных для прото­колов канального и последующих уровней. Данные передаются с по­мощью протоколов данного уровня в виде последовательностей битов (для последовательных протоколов) или групп битов (для параллель­ных протоколов). На этом уровне определяются набор сигналов, кото­рыми обмениваются системы, параметры этих сигналов (временные и электрические) и последовательность формирования сигналов при выполнении процедуры передачи данных. Кроме того, на данном уров­не формулируются требования к электрическим, физическим и меха­ническим характеристикам среды передачи, передающих и соедини­тельных устройств.

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

18.6. Базовые спецификации

 

Базовые спецификации являются основными строительными бло­ками, из которых конструируются конкретные открытые технологии, и относятся к понятию «общедоступные спецификации» (Publicly Available Specifications — PAS). Система PAS охватывает стандарты де-факто, которые не являются международными стандартами. Однако сейчас интенсивно осуществляется процесс принятия наиболее рас­пространенных и сопровождаемых PAS в качестве международных стандартов, что открывает возможность использования PAS в качестве элементов стандартизованных профилей ИТ.

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

Базовые функции ОС: определяются стандартами по окружению открытых систем POSIX (Portable Operating System Interface for Computer Environments) [ISO/IEC 9945/1:1990, (IEEE Std 1003.1 -1990), Information technology. Portable Operating System Interface(POSIX) - Part 1: System Application Program Interface (API) [C Language]].

Функции управления базами данных:

• язык баз данных SQL (Structured Query Language);

• информационно-справочная система IRDS (Information Resource Dictionary System);

• протокол распределенных операций RDA (Remote Database Access);

• PAS Microsoft на открытый прикладной интерфейс доступа к ба­зам данных ODBC API.

Функции пользовательского интерфейса, которые включают в себя следующие стандарты ИТ:

• MOTIF из OSF для графического пользовательского интерфейса

• стандарт OPEN LOOK;

 • X Window вместе с GUI и телекоммуникациями;

 • стандарты для виртуального терминала (Virtual Terminal — VT),

включая процедуры работы VT в символьном режиме через TCP/IP;  

• стандарты машинной графики GKS (Graphical Kernel System);

• GKS-3D (Graphical Kernel System - 3 Dimentional);   

• PHIGS (Programmers Hierarchical Interactive Graphics System);

• CGI (Computer Graphics Interface).

   Функции взаимосвязи открытых систем, включающие в себя:   

• спецификации сервиса и протоколов, разработанные в соответ­ствии с моделью OSI (рекомендации серии Х.200);

• стандарты для локальных сетей (IEEE 802) [IEEE Std 802-1990];

• спецификации сети Интернет [Transmission Control Protocol (TCP) - RFC 793, User Datagram Protocol (UDP) - RFC 768, Internet Protocol (IP)-RFC 791].

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

• вызов удаленной процедуры RPC (Remote Procedure Call);

• фиксация, параллельность и восстановление CCR (Commitment, Concurrency and Recovery);

• протокол надежной передачи (RT);

• обработка   распределенной   транзакции   DTP   (Distributed Transaction Processing);

• управление файлами, доступ к файлам и передача файлов FTAM (File Transfer, Access and Management);

• управление открытыми системами (OSI Management);

• API для доступа к сервису Object Request Broker (ORB) в архи­тектуре CORBA и API, определяющий базовые возможности такого сервиса (Commom Object Services — COS);

• язык спецификации интерфейсов объектов  IDL (Interface Definition Language) и его проекции на объектно-ориентированные языки.

Распределенные приложения: спецификации специальных сервис­ных элементов прикладного уровня модели OSI, стандартов Internet OMG, Х/Open. Как, например:

• система обработки сообщений MHS (Message Handling System -Х.400)],

• служба справочника (The Directory — Х.500);

• спецификации распределенных приложений с архитектурой «кли­ент-сервер» и распределенных объектных приложений.

Структуры данных и документов, форматы данных.

• средства языка ASN. 1 (Abstract Syntax Notation One), предназна­ченного для спецификации прикладных структур данных — абстракт­ного синтаксиса прикладных объектов;

• форматы метафайла для представления и передачи графической информации CGM (Computer Graphics Metafile);

• спецификация сообщений и электронных данных для электрон­ного обмена в управлении, коммерции и транспорте EDIFACT (Electronic Data Interchange for Administration, Commence and Trade);

• спецификации документов — спецификации структур учрежден­ческих документов ODA (Open Document Architecture);

• спецификации структур документов для производства, например SGML (Standard Generalized Markup Language);

• языки описания документов гипермедиа и мультимедиа, напри­мер: HTML (Hypertext Markup Language); HyTime, SMDI»(Standard Music Description Language), SMSL (Standard Multimedia/Hypermedia Scripting Language), SPDS (Standard Page Description Language), DSSSL (Document Style Semantics and Specification Language);

• спецификация форматов графических данных, например форма­тов JPEG, JBIG и MPEG.

Спецификации инструментальных окружений (в частности, языков реализации и их библиотек) и CASE-окружений (например, ISO/IEC DIS 13719, ЕСМА Portable Common Tool Environment).

Кроме базовых в настоящее время существуют сотни различных типовых и конкретных спецификаций, разработанных и разрабатыва­емых в десятках организаций, занимающихся стандартизацией ИТ. Для оценки пригодности и актуальности той или иной спецификации разработана система оценки спецификаций, которая предназначена для поставщиков и пользователей. В рамках этой системы каждая специ­фикация оценивается с позиции ее соответствия некоторым выделенным критериям: степени согласованности, полноте, зрелости, стабиль­ности, степени актуализации, доступности. Например, низкая оценка по степени согласованности назначается тем спецификациям, которые являются частной (корпоративной) принадлежностью и используют­ся ограниченной группой поставщиков и пользователей. Напротив, высоко оцениваются спецификации, ставшие общепризнанными на­циональными или международными стандартами.

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

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

Идентификация спецификаций производится по следующим эле­ментам: имя (наименование) спецификации, дата публикации (дата, когда спецификация стала доступной для общего использования), орга­низация-спонсор (организация, ответственная за разработку и/или поддержание, и/или существование данной спецификации), примени­мость, степень согласованности, доступность изделия, полнота, зре­лость, стабильность, проблемы/ограничения, аттестационное тестиро­вание, привязки, дальнейшие возможности развития, альтернативные спецификации [2].

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

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

 

Глава 19

ИНСТРУМЕНТЫ ФУНКЦИОНАЛЬНОЙ СТАНДАРТИЗАЦИИ

 

19.1. Понятие профиля открытой системы

 

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

Профиль — это совокупность нескольких (или подмножество одно­го) базовых стандартов с четко определенными и гармонизированны­ми подмножествами обязательных и рекомендуемых возможностей, предназначенная для реализации заданной функции или группы фун­кций ИТ/ИС в конкретной функциональной среде. Функциональная характеристика объекта стандартизации является исходной позицией для формирования и применения профиля этого объекта или процес­са [4].

Примерами такой среды могут быть среда рабочей станции, управ­ления встроенными вычислительными устройствами, распределенная среда передачи и обработки данных, среда офисного документооборо­та и т.д. Если все программно-аппаратные и коммуникационные сред­ства, поставляемые различными производителями для использования в рамках целостной ИС, соответствуют профилю, т.е. выполнены в соответствии с необходимыми стандартами, то они будут работать в

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

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

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

 Основными целями применения профилей при создании и исполь­зовании ИС являются:

• снижение трудоемкости и повышение связности проектов ИС;

• обеспечение переносимости ППО;

• обеспечение расширяемости ИС по набору прикладных функций и масштабируемости;

• предоставление возможности функциональной интеграции в ИС задач, которые раньше решались раздельно и менее эффективно;

• повышение качества компонентов ИС.

Выбор стандартов и документов для формирования конкретных профилей ИС зависит от того, какие из этих целей определены при­оритетными.

В качестве методологической базы построения и применения про­филей сложных, распределенных ИС предлагается использовать тех­нический отчет ИСО/МЭК'ТО 10000. Части 1.и 2 этого документа введены в России в качестве стандарта ГОСТ Р. Часть 3, определяю­щую основы и таксономию профилей среды открытых систем, пред­лагается задействовать при построении и использовании профилей И С как документ прямого применения.

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

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

 

19.2. Классификация профилей

 

Существующие базовые профили имеют достаточно жесткую смыс­ловую и иерархическую структуру. По широте охвата области стандартизации, степени признания и области функционального приме­нения профили можно разделить на следующие виды: стратегические   (ISP, GOSIP), OSE-профили прикладных технологий, полные OSE-  профили (профили платформ, систем), OSE-профили (специализация поведения открытых систем), локальные (OSI-профили).

На верхнем уровне находятся международные стандартизованные профили (International Standardized Profiles — ISP), признанные соот­ветствующим комитетом ИСО. В области международной стандарти­зации ИТ профили ISP имеют такой же статус, что и международные базовые стандарты, и предназначены для широкой области примене­ния.

Определение профиля включает в себя следующие элементы:

• область действия функции, для которой определяется профиль;

• иллюстрация сценария, показывающего пример применения про­филя, при этом желательно использование диаграммного представле­ния ИТ-системы, самого приложения и имеющих место интерфейсов;

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

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

• раздел, определяющий требования на соответствие данному про­филю реализующих его ИТ-систем;

• ссылка на спецификацию аттестационных тестов для реализации данного профиля, если таковые имеют место;

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

Типовая структура описания ISR FOREWORD // Предисловие. INTRODUCTION//Введение.

1. SCOPE // Область применения + Сценарии.

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

3. DEFINITIONS//Определения.

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

5. CONFORMANCE // Соответствие.

6. Requirements specifications related to each base standard // Специ­фикации требований для каждого базового стандарта.

NORMATIVE ANNEXES // Нормативные приложения, задающие требования соответствия профиля в табличном представлении. Л4. INFORMATIVE ANNEXES // Объяснения и руководства, если это требуется.

Требования к содержанию и формату ISR

1) профили непосредственно связаны с базовыми стандартами, и аттестация на соответствие профилю подразумевает аттестацию на соответствие этим базовым стандартам;

2) ISP должен удовлетворять правилам ISO/IEC для представле­ния проектов и самих международных стандартов;

3) ISP должен быть компактным документом, не повторяющим тек­ста документов, на которые он ссылается;

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

5) многие профили документируются и публикуются в виде отдель­ных ISP. Однако для тесно связанных между собой профилей может быть использован более подходящий для такого случая» механизм многоком­понентных ISP (Multipart ISPs). Многокомпонентные ISP позволяют избежать копирования общего текста для связанных профилей;

6) для каждого профиля должна обеспечиваться спецификация те­стирования профиля (Profile Test Specification), которая определяет­ся или как часть ISP, или как отдельный самостоятельный ISP. В пос­леднем случае в исходном ISP используется ссылка на этот документ.

В дополнении к ГОСТ Р ISO/IEC TR-10000-1 приводятся правила составления каждого из элементов ISP, соответствующие правилам ISO/IEC. (В случае разбиения ISP на части каждая часть должна удов­летворять этой структуре.)

Ступенькой ниже в иерархии следуют национальные профили, в соответствии с которыми должна строиться национальная система ИТ-стандартизации. Несмотря на то что инициатива разработки концеп­ции таких профилей принадлежит Великобритании, примерами наиболее «влиятельных» могут служить профиль переносимости прило­жений АРР (Application Portability Profile — АРР), разработанный по заказу Правительства США, а также входящий в него государствен­ный профиль взаимосвязи открытых систем GOSIP (Government Open System Interconnection Profile) (рис. 19.1). Мощным фактором, уси­лившим престиж GOSIP США, стало то, что в 1990 г. он получил ста­тус федерального стандарта по обработке информации FIPS (Federal Information Processing Standard) и стал обязательным стандартом при разработке и применении соответствующих технологий. Из рисунка видно, что GOSIP строится на базе семиуровневой модели.

В мае 1993 г. Национальным институтом стандартов и технологий США был выпущен документ «Application Portability Profile АРР. The U.S. Government's Open System Evironment Profile OSE/1 Version 2.0». Этот документ определяет рекомендуемые для федеральных учреж­дений США спецификации в области информационных технологий, обеспечивающие мобильность персонала, системных и прикладных программных средств.

Профиль АРР строится на основе модели OSE/RM, описанной выше, как профиль открытой среды, предназначенный для использо­вания Правительством США. Он охватывает широкую область при­кладных систем, представляющих интерес для многих федеральных агентств. Индивидуальные стандарты и спецификации, входящие в АРР, определяют форматы данных, интерфейсы, протоколы и (или) их комбинации.

Все виды функционального обслуживания в рамках АРР могут быть  представлены следующими семью функциональными областями:

             1) функции, реализуемые операционной системой;

 2) функции, реализующие человекомашинные интерфейсы;

             3) поддержка разработки программного обеспечения;

             4) управление данными;

             5) обмен данными;

             6) компьютерная графика;

             7) сетевые функции.

             На рис. 19.1 была приведена модель OSE/RM, на которой представ-

 лены эти функциональные области и их отношение к элементам модели.

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

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

 

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Документы — спецификации для кодирования данных (текст, ри­сунки, числа, специальные символы и т.д.) и как логические, так и ви­зуальные структуры электронных документов.

Графические данные — независимые от устройств определения эле­ментов рисунков.

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

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

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

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

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

Уровень 4 (семантика и синтаксис языков) — это уровень языка представления данных.                                      

Уровень 5 (прикладной) — уровень приложений, который может использовать любые из нижних уровней для обмена с другими при­кладными программами.

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

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

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

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

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

Дистанционное обращение к процедурам — спецификации для обра­щения к процедурам, расположенным во внешней распределенной среде.

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

Национальные профили GOSIP имеют Великобритания, Франция, Швеция, Япония, Австралия, Гонконг (Сянган). В январе 2000 г. госу­дарственный профиль взаимосвязи открытых систем России был ут­вержден Госстандартом (ГОСТ Р 50.1.22—2000). Этот профиль разра­ботан на основе базовых и функциональных стандартов семиуровне­вой эталонной модели взаимосвязи открытых систем (ВОС ИСО/ МЭК) с учетом опыта по разработке и применению GOSIP указанных стран. Вследствие общего отставания России в области разработки ИТ, состояния и развития стандартизации в этой области, уровня приме­нения ИТ/ИС на федеральном уровне государственный профиль ВОС России имеет некоторые заметные отличия от GOSIP других стран. Однако, несмотря на некоторые различия между национальными и региональными версиями GOSIP, их объединяет функциональная идентичность по следующим обстоятельствам:

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

• уменьшение зависимости от поставщиков;

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

Основное преимущество института GOSIP заключается в том, что все протоколы, на которых основаны GOSIP, обладают общими ха­рактеристиками, такими, например, как:

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

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

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

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

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

 

19.3. Основные свойства и назначение профилей

 

Эталонная модель среды открытых систем (OSE/RM) определяет разделение любой информационной системы на приложения (приклад­ные программы и программные комплексы) и среду, в которой эти приложения функционируют. Между приложениями и средой опре­деляются стандартизованные интерфейсы, которые являются необхо­димой частью профилей любой открытой системы. Кроме того, в про­филях ИС могут быть определены унифицированные интерфейсы вза­имодействия функциональных частей друг с другом и интерфейсы взаимодействия между компонентами среды ИС.          

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

1) API (Application Program Interface — интерфейс прикладной про­граммы);

2) CSI (Communication Services Interface — интерфейс коммуника­ционных услуг);

3)  HCI (Human/Computer Interface — человекомашинный интер­фейс);

4)  ISI (Information Services Interface — интерфейс информацион­ных услуг).

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

Под API понимается интерфейс между ППО и поставщиком необ­ходимого для функционирования этого программного обеспечения сервиса, т.е. прикладной платформой.

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

Через интерфейс HCI осуществляется физическое взаимодействие пользователя и системы ИТ. Примерами такого интерфейса служат клавиатуры для ввода информации и оконные системы взаимодей­ствия с пользователем.

Интерфейс ISI рассматривается как граница взаимодействия с внешней памятью долговременного хранения данных, для переноси­мости и интероперабельности которых необходима стандартизация форматов и синтаксиса представления данных.

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

Полный OSE-профиль — это профиль, который специфицирует все поведение ИТ-системы или часть ее поведения на одном или большем числе интерфейсов OSE. Он состоит из выбранного набора открытых, общедоступных, согласованных стандартов и спецификаций, опреде­ляющих различные услуги в среде эталонной модели OSE/RM.

Профиль OSI — конкретный (локальный) профиль, составленный из базовых стандартов, соответствующих модели OSI (Open System Interconnection), и (или) базовых стандартов представления форма­тов и данных, т.е. F-профилей.

На основании этих определений можно сформулировать следую­щие общие свойства профилей:

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

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

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

Основными целями OSE- и OSI-профилей является реализация основных свойств открытости проектируемой, внедряемой, эксплуатируемой или развиваемой системы. В связи с этим формируемый OSE-профиль должен обеспечивать [6]:

1. Переносимость ППО и многократную используемость ПО на уровне исходного кода и стандартных библиотек (Application Software Portability and Software Reuse at the Source Code Level). Именно пере­носимость между различными платформами исходного текста ПО счи­тается одной из основных практически достижимых задач, решение которой позволяет организациям защитить себя от необходимости дополнительного инвестирования в существующее ПО для его пере­проектирования при переходе на новые прикладные платформы. Если под переносимостью приложений понимается перенос всего соответ­ствующего данному приложению ПО на другие платформы, то под его переиспользумостью, как правило, понимается перенос в новые приложения некоторой части работающих программ, что также имеет боль­шое практическое значение и непосредственно относится к целям от­крытости систем.

 Переносимость данных (Data Portability). He менее важной целью открытых систем является переносимость на новые прикладные плат­формы данных, хранящихся во внешней памяти существующих систем ИТ, что обеспечивается разработкой OSE на основе стандартов и ISP, строго регламентирующих форматы и способы представления данных.

3.  Интероперабельность прикладного программного обеспечения (Application Software Interoperability). Здесь имеется в виду возмож­ность обмена данными между сущностями ПО, в том числе между сущ­ностями, реализуемыми на разнородных прикладных платформах, а также возможность совместного использования ими обмениваемых данных. Данное свойство на нижнем уровне обеспечивается построе­нием стандартизованных коммуникационных интерфейсов, т.е. CSI-интерфейсов, систем на основе стандартов сетевых протоколов, в час­тности OSI-профилей. Реализация его в полном объеме приводит к необходимости решения проблемы семантической интероперабельности, т.е. понимания разнородными платформами семантики данных, которыми они обмениваются друг с другом.

4. Интероперабельность управления и безопасности (Management and Security Interoperability). Для целей интеграции и совместного использования разнородных платформ в рамках распределенных сис­тем ИТ необходима унификация и концептуальная целостность средств административного управления и управления информацион­ной безопасностью систем ИТ независимо от реализационных окру­жений. Поэтому для обеспечения бесшовной интеграции систем их средства административного управления и средства защиты должны строиться в соответствии с международными стандартами.

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

6. Использование существующих стандартов и аккомодацию к стан­дартам перспективных технологий (Accommodation of Standards). Про­фили OSE являются эффективным средством продвижения существу­ющих стандартов в практику. В то же время они являются объектами, способными эволюционировать с учетом изменения стандартов, тех­нологий и пользовательских требований, прежде всего потому, что они конструируются посредством ссылок на базовые стандарты. Таким образом, на основе понятия OSE-профиля поддерживается такое свой­ство открытых систем, как адаптируемость к изменению стандартов.

7. Легкую настраиваемость на новые технологии создания инфор­мационных систем (Accommodation of New Information System Techno­logy). Профили OSE, являясь исходным материалом при построении открытых систем, не связаны непосредственно с нижележащими тех­нологиями. Однако развитие таких технологий влечет развитие сие- . темы стандартов. Гибкость аппарата OSE-профилей позволяет учиты­вать тенденции перехода к новым стандартам и соответственно к но­вым технологиям.

8.  Масштабируемость прикладных платформ и распределенных систем (Application Platform Scalability). Масштабируемость относит­ся к важнейшим свойствам открытости систем ИТ. Применительно к прикладной платформе оно означает возможность разных типов реа­лизаций некоторого OSE-профиля, отличающихся техническими и ресурсными характеристиками (например, суперкомпьютеры и рабо­чие станции), поддерживать одну и ту же функциональность, т.е. один и тот же набор сервисов.

9. Прозрачность реализаций процессов (Implementation Transparency). Данное свойство поддерживается благодаря систематическому исполь­зованию через аппарат OSE-профилей стандартизованных специфи­каций (стандартов и ISPs), одним из принципов разработки которых является независимость от конкретных реализаций. Таким образом, все особенности реализации OSE-профилей скрываются за интерфей­сами открытых систем, что и обеспечивает свойство прозрачности ре­ализаций для конечных пользователей систем ИТ.

10. Поддержку пользовательских требований (Support Clear State­ment of User Requirements). Важным свойством открытых систем яв­ляется точная спецификация пользовательских требований, опреде­ленных в виде наборов сервисов, предоставляемых открытыми систе­мами на их интерфейсах. Это свойство адекватно поддерживается применением аппарата OSE-профилей.

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

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

• идентифицировать стандарты и нормативные документы, вари­анты их использования и параметры, которые необходимо включить в профиль;

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

• формализовать профиль в соответствии с его категорией, вклю­чая стандарты, различные варианты нормативных документов и до­полнительные параметры, которые непосредственно связаны с профи­лем;

• опубликовать профиль и (или) продвигать его по формальным инстанциям для дальнейшего распространения.

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

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

 

19.4. Пример компоновки функционального профиля

 

Наиболее актуальными в настоящее время представляются откры­тые распределенные ИС с архитектурой «клиент-сервер». Рассмотрим подходы к построению функциональных профилей таких систем [4].

Профиль среды ИС должен определять ее архитектуру в соответ­ствии с выбранной моделью распределенной обработки данных, на­пример DCE (Distributed Computing Environment) или CORBA (Common Object Request Broker Architecture). В первом случае модель определяется стандартами Консорциума OSF, в частности механизма удаленного вызова процедур RPC (Remote Procedure Call) с учетом стандартов де-факто, которые специфицируют применяемые монито­ры транзакций (например, монитор транзакций Tuxedo) [3]. Во вто­ром случае модель определяется стандартами консорциума OMG, в частности спецификацией брокера объектных запросов ORB (Object Request Broker). Стандарты интерфейсов приложений со средой ИС (Application Program Interface — API) должны быть определены по функциональным областям профилей ИС. Декомпозиция структуры среды функционирования ИС на составные части, выполняемая на стадии эскизного проектирования, позволяет детализировать профиль среды ИС по функциональным областям эталонной модели OSE/RM:

• графического пользовательского интерфейса (Motif консорциу­ма «OSF» или стандарт X Window IEEE);

• реляционных или объектно-ориентированных СУБД (например, стандарт языка SQL-92 и спецификации доступа к разным базам дан­ных);

• операционных систем с учетом сетевых функций, выполняемых на уровне ОС (например, набора стандартов POSIX — ISO и IEEE);

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

Х.500), доступа к удаленным базам данных RDA (по стандарту ISO ; 9594-1.2), передачи файлов, доступа к файлам и управления файлами  (по стандарту ISO 10607 - 1, 2, 3, 4, 5, 6).

 Профиль среды распределенной ИС должен включать в себя стандарты протоколов транспортного уровня (по ISO OSI или стандарт  де-факто протокола TCP/IP), стандарты локальных сетей (например,  стандарт Ethernet IEEE 802.3 или стандарт Fast Ethernet IEEE 802.3 u), а также стандарты средств сопряжения проектируемой ИС с сетями передачи данных общего назначения (например, по рекомендациям ITU-T X.25,X.3,X.29 и др.).

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

форм; надежности. Профиль среды И С содержит стандарты, опреде­ляющие параметры технических средств и способы их измерения (на­пример, стандартные тесты измерения производительности).

Профиль защиты информации в ИС должен обеспечивать реали­зацию политики информационной безопасности, разрабатываемой в соответствии с требуемой категорией безопасности и критериями бе­зопасности, заданными в техническом задании на систему [8]. Пост­роение профиля защиты информации в распределенных системах «клиент-сервер» методически связано с точным определением компо­нентов системы, ответственных за те или иные функции, сервисы и услуги, и средств защиты информации, встроенных в эти компонен­ты. Функциональная область защиты информации включает в себя функции защиты, реализуемые разными компонентами ИС, а именно функции:

• защиты, реализуемые ОС;

• защиты от несанкционированного доступа, реализуемые на уров­не ЦР промежуточного слоя;

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

• защиты программных средств, включая средства защиты от ви­русов;

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

• администрирования средств безопасности. Основополагающим документом в области защиты информации в распределенных системах являются рекомендации Х.800, принятые МККТТ (сейчас ITU-T) в 1991 г. Подмножество указанных рекомен­даций должно составлять профиль защиты информации в ИС с уче­том распределения функций защиты информации по уровням концеп­туальной модели ИС и взаимосвязи функций и применяемых меха­низмов защиты информации. При использовании профиля защиты информации при проектировании, разработке и сопровождении ИС целесообразно учитывать методические рекомендации, изложенные в интерпретации «Оранжевой книги» национального центра компьютерной безопасности США для сетевых конфигураций. Профиль защиты информации должен включать в себя указания на методы и средства обнаружения в применяемых аппаратных и программных средствах недекларированных возможностей («закладных» элементов и виру­сов). Профиль должен также содержать указания на методы и сред­ства резервного копирования информации и восстановления инфор­мации при отказах и сбоях аппаратуры системы.

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

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

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

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

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

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

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

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

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

На основе профиля должно проводиться тестирование и сертифи­кация приложений на соответствие требованиям открытости. Основу большинства применяемых в настоящее время профилей составляют стандарты серии POSIX. Общий их перечень состоит из более 45 наи­менований. Перечень российских стандартов в области реализа­ции открытых систем составляет 92 стандарта [1].

 

Раздел VII

БЕЗОПАСНОСТЬ ИНФОРМАЦИОННЫХ СИСТЕМ

 

Глава 20

ЗАЩИЩЕННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА

 

20.1. Определение защищенной информационной системы

 

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

Межсетевые экраны, системы обнаружения атак, сканеры для вы­явления уязвимостей в узлах сети, ОС и СУБД, фильтры пакетов дан­ных на маршрутизаторах — достаточно ли всего этого мощного арсе­нала (так называемого «жесткого периметра») для обеспечения безо­пасности критически важных информационных систем, работающих в Интернет и Интранет? Практика и накопленный к настоящему вре­мени опыт показывают — чаще всего нет!

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


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

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

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

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

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

Эти общие положения являются основой для проектирования и реализации безопасности открытых информационных систем [4].

 

20.2. Методология анализа защищенности

информационной системы

 

При разработке архитектуры и создании инфраструктуры корпо­ративной ИС неизбежно встает вопрос о ее защищенности от угроз. Решение вопроса состоит в подробном анализе таких взаимно пересе­кающихся видов работ, как реализация ИС и аттестация, аудит и об­следование безопасности ИС [1].

Основой формального описания систем защиты традиционно счи­тается модель системы защиты с полным перекрытием, в которой рассматривается взаимодействие области угроз, защищаемой области и системы защиты. Таким образом, модель может быть представлена в виде трех множеств: Т= {ti} — множество угроз безопасности, О = {oj} — множество объектов (ресурсов) защищенной системы, М= {mk} — мно­жество механизмов безопасности.

Элементы этих множеств находятся между собой в определенных отношениях, собственно и представляющих систему защиты. Для опи­сания системы защиты обычно используется графовая модель. Мно­жество отношений «угроза — объект» образует двухдольный граф {Т, О}. Цель защиты состоит в том, чтобы перекрыть все возможные ребра в графе. Это достигается введением третьего набора М; в результате получается трехдольный граф {Т, М, О}.

Развитие модели предполагает введение еще двух элементов. Пусть V— набор уязвимых мест, определяемый подмножеством декартова произведения {ТхО}: vr = <ti, oj>. Под уязвимостью системы защиты понимают возможность осуществления угрозы Т в отношении объекта O. (На практике под уязвимостью системы защиты обычно понима­ют те свойства системы, которые либо способствуют успешному осу­ществлению угрозы, либо могут быть использованы злоумышленни­ком для ее осуществления.)

Определим В как набор барьеров, определяемый декартовым про­изведением {VxM}: b1 = < ti, oj, mk >, представляющих собой пути осу­ществления угроз безопасности, перекрытые средствами защиты. В результате получаем систему, состоящую из пяти элементов: <Т, О, М, V, В>, описывающую систему защиты с учетом наличия уязвимостей.

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

В идеале каждый механизм защиты должен исключать соответству­ющий путь реализации угрозы. В действительности же механизмы за­щиты обеспечивают лишь определенную степень сопротивляемости угрозам безопасности, поэтому в качестве характеристик элемента на­бора барьеров b1= <ti, oj, mk> может рассматриваться набор

<Р 1, L1, R1>, где Р1 — вероятность появления угрозы; L1 — величина ущерба при удачном осуществлении угрозы в отношении защищаемых объектов (уровень серьезности угрозы); a R1 — степень сопротивляемости меха­низма защиты mk, характеризующаяся вероятностью его преодоления.

Надежность барьера b1 = <ti, oj, mk> характеризуется величиной остаточного риска Risk1, связанного с возможностью осуществления угрозы ti в отношении объекта информационной системы оj при ис­пользовании механизма защиты тk. Эта величина определяется по следующей формуле: Risk1 = Pk Lk (1 — Rk). Для нахождения пример­ной величины защищенности S можно использовать следующую про­стую формулу: S = 1/Risk0, где Risk0 является суммой всех остаточных рисков, (0 < [Ph Lk] < 1), (0 ≤ Rk  < 1).

Суммарная величина остаточных рисков характеризует приблизи­тельную совокупную уязвимость системы защиты, а защищенность оп­ределяется как величина, обратная уязвимости. При отсутствии в сис­теме барьеров by «перекрывающих» выявленные уязвимости, степень сопротивляемости механизма защиты Rk принимается равной нулю.

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

Для защиты информации экономического характера, допускающей оценку ущерба, разработаны стоимостные методы оценки эффектив­ности средств защиты. Для этих методов набор характеристик барье­ра дополняет величина С1 затраты на построение средства защиты ба­рьера b1. В этом случае выбор оптимального набора средств защиты связан с минимизацией суммарных затрат W{w1}, состоящих из зат­рат C={c1} на создание средств защиты и возможных затрат в результа­те успешного осуществления угроз N={n1}.

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

 

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

 

Идеология открытых систем (см. гл. 19) существенно отразилась на методологических аспектах и направлении развития сложных ИС.

Она базируется на строгом соблюдении совокупности профилей, про­токолов и стандартов де-факто и де-юре. Программные и аппаратные компоненты по этой идеологии должны отвечать важнейшим требо­ваниям переносимости и возможности согласованной, совместной ра­боты с другими удаленными компонентами. Это позволяет обеспечить совместимость компонент различных информационных систем, а так­же средств передачи данных. Задача сводится к максимально возмож­ному повторному использованию разработанных и апробированных программных и информационных компонент при изменении вычис­лительных аппаратных платформ, ОС и процессов взаимодействия [4, 5, 10].

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

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

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

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

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

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

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

• проектирование И С на принципах открытых систем, следование признанным стандартам, использование апробированных решений, иерархическая организация ИС с небольшим числом сущностей на каждом уровне — все это способствует прозрачности и хорошей уп­равляемости ИС;

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

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

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

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

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

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

Анализ безопасности И С при отсутствии злоумышленных факто­ров базируется на модели взаимодействия основных компонент ИС (рис. 20.1).                                                                

В качестве объектов уязвимости рассматриваются:

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

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

• данные и информация, накопленная в базах данных;

•  информация, выдаваемая потребителям и на исполнительные механизмы.

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

 

 

20.4. Этапы построения системы безопасности ИС

 

Концепция информационнной безопасности определяет этапы по­строения системы информационной безопасности в соответствии со стандартизованным жизненным циклом ИС: аудит безопасности (об­следование) существующей системы защиты ИС, анализ рисков, фор­мирование требований и выработка первоочередных мер защиты, про­ектирование, внедрение и аттестация, сопровождение системы [7]. Рассмотрим кратко содержание отдельных этапов.

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

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

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

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

• изучение исходных данных по структуре, архитектуре, инфра­структуре и конфигурации ИС на момент обследования;

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

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

• анализ конфигурационных файлов маршрутизаторов и Proxy-сер­веров, почтовых и DNS-серверов (Domain Name System), шлюзов виртуальных частных сетей (VPN), других критических элементов сете­вой инфраструктуры;

• сканирование внешних сетевых адресов локальной сети;

• сканирование ресурсов локальной сети изнутри;

• анализ конфигурации серверов и рабочих станций при помощи специализированных программных агентов.

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

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

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

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

• настройка параметров системы регистрации событий;

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

• настройка механизмов оповещения об атаках и реагирования;

• наличие и работоспособность средств контроля целостности;

• версии используемого ПО и установленные обновления.

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

Один из современных и быстро развивающихся методов автомати­зации процессов анализа и контроля защищенности распределенных компьютерных систем — использование технологии интеллектуальных программных агентов. На каждую из контролируемых систем устанав­ливается программный агент, который выполняет соответствующие настройки ПО, проверяет их правильность, контролирует целостность файлов, своевременность установки обновлений, а также решает дру­гие задачи по контролю защищенности ИС. Управление агентами осу­ществляет по сети программа-менеджер. Такие менеджеры, являющи­еся центральными компонентами подобных систем, посылают управ­ляющие команды всем агентам контролируемого ими домена и сохраняют все полученные от агентов данные в центральной БД. Ад­министратор управляет менеджерами при помощи графической кон­соли, позволяющей выбирать, настраивать и создавать политики безопасности, анализировать изменения состояния системы, осуществ­лять ранжирование уязвимостей и т.п. Все взаимодействия между аген­тами, менеджерами и управляющей консолью осуществляются по за­щищенному клиент-серверному протоколу. Такой подход, например, использован при построении комплексной системы управления безо­пасностью организации ESM (производитель — компания «Symantec Enterprise Security Manager»).

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

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

Объекты или приложения? При проектировании архитектуры си­стемы информационной безопасности применяются объектный, при­кладной или смешанный подходы.

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

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

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

Службы и механизмы безопасности. Стратегию защиты можно ре­ализовать двумя методами: ресурсным и сервисным. Первый метод рассматривает ИС как набор ресурсов, которые «привязываются» к конкретным компонентам системы ИБ. Этот метод хорош для неболь­ших ИС с ограниченным набором задач. При расширении круга задач и разрастании ИС приходится во многом дублировать элементы за­щиты для однотипных ресурсов, что часто приводит к неоправданным затратам. Сервисный подход трактует ИС как набор служб, программных и телекоммуникационных сервисов для оказания услуг пользова­телям. В этом случае один и тот же элемент защиты можно использо­вать для различных сервисов, построенных на одном и том же ПО или техническом устройстве. Сегодня сервисный подход представляется предпочтительным, поскольку он предполагает строгий функциональ­ный анализ существующих многочисленных служб, обеспечивающих функционирование ИС, и позволяет исключить широкий класс угроз при помощи отказа от «лишних» служб и оптимизации работы остав­шихся, делая структуру системы ИБ логически обоснованной. Имен­но сервисный подход лежит в основе современных стандартов по бе­зопасности, в частности ISO 15408.

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

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

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

• экспертное обследование объекта информатизации и анализ доку­ментации по защите информации на предмет соответствия требованиям;

• испытания отдельных средств и систем защиты информации на аттестуемом объекте с помощью специальной контрольной аппарату­ры и тестовых средств;

• испытания отдельных средств и систем защиты информации в испытательных центрах (лабораториях);

• комплексные аттестационные испытания объекта информатиза­ции в реальных условиях эксплуатации;

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

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

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

• администрирование штатных средств защиты и их техническое обслуживание;

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

• мониторинг и установку выпускаемых обновлений и программ­ных коррекций средств защиты, а также используемых ОС, СУБД и приложений;

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

• диагностику неисправностей и проведение восстановительных работ при возникновении аварийных и нештатных ситуаций;

• периодическое тестирование системы информационной безопас­ности и оценка эффективности защиты.

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

 

20.5. Cтандартизация подходов к обеспечению информационной безопасности

 

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

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

1)  оценочные стандарты, предназначенные для оценки и класси­фикации ИС и средств защиты по требованиям безопасности;

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

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

Из числа оценочных необходимо выделить стандарт Министерства обороны США «Критерии оценки доверенных компьютерных систем» и его интерпретацию для сетевых конфигураций, «Гармонизирован­ные критерии Европейских стран», международный стандарт «Крите­рии оценки безопасности информационных технологий» и конечно, Руководящие документы Гостехкомиссии России. К этой же группе от­носится и Федеральный стандарт США «Требования безопасности для криптографических модулей», регламентирующий конкретный, но очень важный и сложный аспект информационной безопасности.

Технические спецификации, применимые к современным распре­деленным ИС, создаются главным образом «Тематической группой по технологии Интернет» (Internet Engineering Task Force — IETF) и ее подразделением — рабочей группой по безопасности. Ядром техничес­ких спецификаций служат документы по безопасности на IP-уровне (IPsec). Кроме этого, анализируется защита на транспортном уровне (Transport Layer Security — TLS), а также на уровне приложений (спе­цификации GSS-API, Kerberos). Интернет-сообщество уделяет долж­ное внимание административному и процедурному уровням безопас­ности, создав серию руководств и рекомендаций: «Руководство по информационной безопасности предприятия», «Как выбирать поставщика Интернет-услуг», «Как реагировать на нарушения информаци­онной безопасности» и др.

В вопросах сетевой безопасности невозможно обойтись без специ­фикаций Х.800 «Архитектура безопасности для взаимодействия от­крытых систем», Х.500 «Служба директорий: обзор концепций, моде­лей и сервисов» и Х.509 «Служба директорий: каркасы сертификатов открытых ключей и атрибутов».

Критерии оценки механизмов безопасности программно-техничес­кого уровня представлены в международном стандарте ISO 15408— 1999 «Общие критерии оценки безопасности информационных тех­нологий» («The Common Criteria for Information Technology Security Evaluation»), принятом £ 1999 г. «Общие критерии» («ОК») опреде­ляют функциональные требования безопасности (Security Functional Requirements) и требования к адекватности реализации функций бе­зопасности (Security Assurance Requirements).

«Общие критерии» содержат два основных вида требований безо­пасности:

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

2) требования доверия, соответствующие пассивному аспекту; они предъявляются к технологии и процессу разработки и эксплуатации.

Требования безопасности формулируются, и их выполнение про­веряется для определенного объекта оценки — аппаратно-программ­ного продукта или ИС. Безопасность в «ОК» рассматривается не ста­тично, а в соответствии с жизненным циклом объекта оценки. Кроме того, обследуемый объект предстает не изолированно, а в «среде безо­пасности», характеризующейся определенными уязвимостями и угро­зами. «Общие критерии» целесообразно использовать для оценки уров­ня защищенности с точки зрения полноты реализованных в ней функ­ций безопасности и надежности реализации этих функций. Хотя применимость «ОК» ограничивается механизмами безопасности про­граммно-технического уровня, в них содержится определенный набор требований к механизмам безопасности организационного уровня и требований по физической защите, которые непосредственно связаны с описываемыми функциями безопасности.

Британский стандарт BS 7799 «Управление информационной бе­зопасностью. Практические правила» без сколько-нибудь существен­ных изменений воспроизведен в международном стандарте ISO/IEC 17799—2000 «Практические правила управления информационной бе­зопасностью» («Code of practice for Information security management»). В этом стандарте обобщены правила по управлению ИБ, они могут быть использоваться в качестве критериев оценки механизмов безо­пасности организационного уровня, включая административные, процедурные и физические меры защиты. Практические правила разбиты на десять разделов.

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

2. Организация защиты.

3. Классификация ресурсов и их контроль.

4. Безопасность персонала.

5. Физическая безопасность.

6. Администрирование компьютерных систем и сетей.

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

8. Разработка и сопровождение информационных систем.

9. Планирование бесперебойной работы организации.

10. Контроль выполнения требований политики безопасности.

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

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

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

 

20.6. Обеспечение интегральной безопасности

информационных систем

 

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

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

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

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

• безопасность ПО (защита от вирусов, логических бомб, несанк­ционированного изменения конфигурации и программного кода);

• безопасность данных (обеспечение конфиденциальности, целост­ности и доступности данных).

Задача обеспечения ИБ появилась вместе с проблемой передачи и хранения информации. На современном этапе можно выделить три подхода к ее решению:

1)  частный — основывается на решении частных задач обеспече­ния ИБ. Этот подход является малоэффективным, но достаточно час­то используется, так как не требует больших финансовых и интеллек­туальных затрат;

2)  комплексный — реализуется решением совокупности частных задач по единой программе. Этот подход в настоящее время применя­ется наиболее часто;

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

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

На рис. 20.2 представлена блок-схема интегрального комплекса фи­зической защиты объекта, обеспечивающего функционирование всех рассмотренных выше систем, а на рис 20.3 — соотношение эффективно­сти современных электронных средств контроля физического доступа.

 

 

 

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

• средства обеспечения надежного хранения информации с исполь­зованием технологии защиты на файловом уровне (File Encryption System — FES);

• средства авторизации и разграничения доступа к информацион­ным ресурсам, а также защита от несанкционированного доступа к информации с использованием технологии токенов (смарт-карты, touch-memory, ключи для USB-портов и т.п.);

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

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

• средства обеспечения конфиденциальности, целостности, доступ­ности и подлинности информации, передаваемой по открытым кана­лам связи с использованием технологии защищенных виртуальных частных сетей (Virtual Private Net — VPN);

• средства обеспечения активного исследования защищенности информационных ресурсов с использованием технологии обнаруже­ния атак (Intrusion Detection);

• средства обеспечения централизованного управления системой ИБ в соответствии с согласованной и утвержденной политикой безо­пасности.

Защита информации на файловом уровне. Эти технологии позволя­ют скрыть конфиденциальную информацию пользователя на жестком диске компьютера или сетевых дисках путем кодирования содержимо­го файлов, каталогов и дисков. Доступ к данной информации осуществ­ляется по предъявлению ключа, который может вводиться с клавиату­ры, Храниться и предоставляться со смарт-карты, HASP-ключей или USB-ключей и прочих токенов. Помимо перечисленных выше функций указанные средства позволяют мгновенно «уничтожить» информацию при подаче сигнала «тревога» и при «входе под принуждением», а так­же блокировать компьютер в перерывах между сеансами работы.

Технологии токенов (смарт-карты, touch-memory, ключи для USB-портов). Электронные ключи-жетоны (Token) являются сред­ством повышения надежности защиты данных на основе гарантиро­ванной идентификации пользователя. Токены являются «контейне­рами» для хранения персональных данных пользователя системы и некоторых его паролей. Основное преимущество токена заключается в том, что персональная информация всегда находится на носителе (смарт-карте, ключе и т.д.) и предъявляется только во время доступа к системе или компьютеру. Эта система находит все новых и новых при­верженцев, так как позволяет унифицировать правила доступа и по­местить на одном персональном электронном носителе систему паро­лей для доступа на различные устройства и системы кодирования и декодирования информации. В настоящее время получают распрост­ранение токены с системой персональной аутентификации на базе био­метрической информации, которая считывается с руки пользователя. Таким «ключом» может воспользоваться только тот пользователь, на которого настроен этот ключ.

Межсетевые экраны. Использование технологии межсетевых эк­ранов предлагается для решения таких задач, как:

• безопасное взаимодействие пользователей и информационных ресурсов, расположенных в Экстранет- и Интранет-сетях, с внешни­ми сетями;

• создание технологически единого комплекса мер защиты для рас­пределенных и сегментированных локальных сетей подразделений предприятия;

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

В зависимости от масштабов организации и установленной поли­тики безопасности рекомендуются межсетевые экраны (FireWall), от­личающиеся по степени функциональности и по стоимости [межсете­вые экраны Checkpoint Fire Wall-1, Private Internet Exchange (PIX) компании «Cisco» и др.]. Устройства содержательной фильтрации  (Content Inspection) устанавливаются, как правило, на входы почто­вых серверов для отсечения большого объема неопасной, но практи­чески бесполезной информации, обычно рекламного характера (Spam), принудительно рассылаемой большому числу абонентов электронной почты.

Антивирусные средства. Лавинообразное распространением виру­сов («червей», «троянских коней») действительно стало большой про­блемой для большинства компаний и государственных учреждений. В настоящее время известно более 45 000 компьютерных вирусов и каж­дый месяц появляется более 300 новых разновидностей. При этом счи­тается, что основной путь «заражения» компьютеров — через Интер­нет, поэтому наилучшее решение, по мнению многих руководителей, — отключить корпоративную сеть от Интернет. Часто говорят: «Есть Интернет — есть проблемы, нет Интернет — нет проблем». При этом не учитывается, что существует множество других путей проникнове­ния вирусов на конкретный компьютер, например при использовании чужих дискет и дисков, пиратское программное обеспечение или пер­сональные компьютеры «общего пользования» (например, опасность представляют домашние или студенческие компьютеры, если на них работает более одного человека). Системное применение лицензион­ных антивирусных средств (например, Лаборатории Касперского) су­щественно уменьшает опасность вирусного заражения.

Защищенные виртуальные частные сети. Для защиты информа­ции, передаваемой по открытым каналам связи, поддерживающим про­токолы TCP/IP, существует ряд программных продуктов, предназна­ченных для построения VPN на основе международных стандартов IPSec. Виртуальные сети создаются чаще всего на базе арендуемых и коммутируемых каналов связи в сетях общего пользования (Интер­нет). Для небольших и средних компаний они являются хорошей аль­тернативой изолированным корпоративным сетям, так как обладают очевидными преимуществами: высокая гарантированная надежность, изменяемая топология, простота конфигурирования, легкость масш­табирования, контроль всех событий и действий в сети, относительно

невысокая стоимость аренды каналов и коммуникационного оборудо­вания.

Продукты работают в операционных системах Windows 98/2000/ NT и Solaris и обеспечивают:

• защиту (конфиденциальность, подлинность и целостность) пере­даваемой по сетям информации;

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

• идентификацию и аутентификацию пользователей сетевых объек­тов;

• централизованное управление политикой корпоративной сетевой безопасности.

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

Технологии обнаружения атак (Intrusion Detection). Постоянное изменение сети (появление новых рабочих станций, реконфигурация программных средств и т.п.) может привести к появлению новых уяз­вимых мест, угроз и возможностей атак на ИР и саму систему защиты. В связи с этим особенно важно своевременное их выявление и внесе­ние изменений в соответствующие настройки информационного ком­плекса и его подсистем, и в том числе в подсистему защиты. Это озна­чает, что рабочее место администратора системы должно быть укомп­лектовано специализированными программными средствами обследования сетей и выявления уязвимых мест (наличия «дыр») для проведения атак «извне» и «снаружи», а также комплексной оценки степени защищенности от атак нарушителей. Например, в состав про­дуктов ЭЛВИС+, Net Pro VPN входят наиболее мощные среди обшир­ного семейства коммерческих пакетов продукты компании «Internet Security Systems» (Internet Scanner и System Security Scanner), а так­же продукты компании «Cisco»: система обнаружения несанкциони­рованного доступа NetRanger и сканер уязвимости системы безопас­ности NetSonar.

Инфраструктура открытых ключей (Public Key Infrastruture — PKI). Основными функциями РК1 являются поддержка жизненного цикла цифровых ключей и сертификатов (т.е. их генерация, распреде­ление, отзыв и пр.), поддержка процесса идентификации и аутентификации пользователей и реализация механизма интеграции существу­ющих приложений и всех компонент подсистемы безопасности. Не­смотря на существующие международные стандарты, определяющие функционирование системы PKI и способствующие ее взаимодействию с различными средствами защиты информации, к сожалению, не каж­дое средство информационной защиты, даже если его производитель декларирует соответствие стандартам, может работать с любой систе­мой PKI. В нашей стране только начинают появляться компании, пре­доставляющие услуги по анализу, проектированию и разработке инф­раструктуры открытых ключей. Поскольку при возрастающих масш­табах ведомственных и корпоративных сетей VPN-продукты не смогут работать без PKI, только у разработчиков и поставщиков VPN есть опыт работы в этой области.

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

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