Формирование отношений для связи М:М

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

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

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

 

 

Рис. 6.20 Диаграмма и отношение для правила 6

 

Применим правило 6 к примеру, приведенному на рис. 6.5. В нем степень связи равна М:М, класс принадлежности для сущности ПРЕПОДАВАТЕЛЬ обязательный, а для сущности ДИСЦИПЛИНА - необязательный. Соответ­ствующее этому примеру исходное отношение показано на рис. 6.21.

 

 

 

Рис. 6.21 Исходное отношение

 

 

В результате применения правила 6 получаются три отношения (рис. 6.22)

 

 

Рис. 6.22. Отношения, полученные по правилу 6

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

Средства автоматизации проектирования

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

Основные определения

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

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

Термин CASE (Computer Aided Software Engineering) дословно переводит­ся как разработка программного обеспечения с помощью компьютера. В на­стоящее время этот термин получил более широкий смысл, означающий ав­томатизацию разработки информационных систем.

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

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

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

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

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

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

Повторная разработка сводится к построению исходной модели программ­ной системы путем исследования ее программных кодов. Имея модель, мож­но ее усовершенствовать, а затем вновь перейти к разработке Так часто и по­ступают при проектировании. Одним из наиболее известных принципов та­кого типа является принцип «возвратного проектирования» - Round Trip Engineering (RTE).

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

Динамика изменения позиций структурных и объектно-ориентированных систем позволяет предположить, что перспективная CASE-система будет объектно-ориентированной/Рассмотрим требования к идеальной перспектив­ной CASE-системе.

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

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

1. динамического моделирования событий в системе;
2. динамической и согласованной коррекции всей совокупности диаг­рамм;
3. добавления пояснительных надписей к диаграммам моделей и в доку­ментацию;
4. автоматической генерации документации;
5. создания различных представлений и скрытия неиспользуемых слоев системы;
6. поддержки различных нотаций (это требование ослабевает в связи с пе­реходом к единому языку моделирования).

 

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

1. определения основной модели прикладной задачи (бизнес-модели, обычно объектно-ориентированной) и правил ее поведения (бизнес-правил);
2. поддержки процесса проектирования с помощью библиотек, оснащен­ных средствами хранения, поиска и выбора элементов проектирования (объектов и правил);
3. создания пользовательского интерфейса и поддержания распространенных программных интерфейсов поддержка стандартов OLE, OpenDoc, доступ к библиотекам HTML/Java и т. п.);
4. создания различных распределенных клиент-серверных приложений.

 

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

CASE-системы ближайшего будущего должны позволять создавать скелет­ные заготовки под классы, атрибуты и методы, готовые приложения на объек­тно-ориентированных языках программирования типа C++ или Smalltalk, либо программы на языках клиент-серверных продуктов (PowerBuilder, Forte, VisualAge, VisualWorks и т. д.). К поддерживаемым языкам, по-видимому, ско­ро добавится язык Java.

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

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

7.2. Модели жизненного цикла

Модель жизненного цикла (ЖЦ) цикла программного обеспечения ин-формационной системы (ПО ИС) при автоматизированном проектирова­нии ИС играет достаточно важную роль. Это обусловлено тем, что каждая из CASE-систем ориентирована на (поддерживает) определенную модель ЖЦПОИС.

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

Основным нормативным документом, регламентирующим ЖЦ ПО, яв­ляется международный стандарт ISO/IEC 12207 (International Or­ganization of Standardization - Международная организация по стандар­тизации/International Electrotechnical Commission - международная ко­миссия по электротехнике). В нем определяется структура ЖЦ, содержа­щая процессы, действия и задачи, которые должны быть выполнены при создании ПО.

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

Модели каскадная и с промежуточным контролем включают следующие этапы жизненного цикла ПО: анализ, проектирование, реализация, внедре­ние и сопровождение.

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

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

Спиральная модель жизненного цикла (рис. 7.1) позволяет устранить не­достатки предыдущих моделей. Основной упор в ней делается на начальные этапы: анализ и проектирование. На них реализуемость технических реше­ний проверяется с помощью создания прототипов.

 

 

 

 

Рис. 7.1 Спиральная модель жизненного цикла

 

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

 

7.4. Объектно-ориентированные модели

Большинство моделей объектно-ориентированного проектирования близки по возможностям, но имеют отличия в основном в форме представ­ления. Популярность объектно-ориентированных технологий привела к сближению большинства известных моделей. Многообразие моделей порож­дает трудности проектировщиков по выбору модели и по обмену информа­цией при работе над разными проектами. В этой связи известные специали­сты Г.Буч, Д.Рамбо и И.Джекобсон при поддержке фирмы Rational Software Corporation провели работу над унифицированной моделью и методом, по­лучившим название UML (Unified Modeling Language - унифицирован­ный язык моделирования).

Общая характеристика UML

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

•Booch, получившая название по фамилии автора Гради Буча (Grady Booch);

• ОМТ (Object Modeling Technique - метод моделирования объек­тов);

• OOSE (Object-Oriented Software Engineering - объектно-ориентирован­ное проектирование программного обеспечения).

На заключительной стадии разработки, унификации и принятия UML в качестве стандарта большой вклад внес консорциум OMG (Object Mana­gement Group - группа управления объектом). UML можно определить так­же как промышленный объектно-ориентированный стандарт моделирова­ния. Он включает в себя в унифицированном виде лучшие методы визуаль­ного (графического) моделирования. В настоящее время имеется целый ряд инструментальных средств, производители которых заявляют о поддержке UML, среди них можно выделить: Rational Rose, Select Enterprise, Platinum и Visual Modeler.

Типы диаграмм UML

Создаваемый с помощью UML проект информационной системы может включать в себя следующие 8 видов диаграмм (diagrams):

• прецедентов использования (use case),

• классов (class),

• состояний (statechart),

• активности (activity),

• следования (sequence),

• сотрудничества (collaboration),

• компонентов (component),

• размещения (deployment).

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

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

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

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

• представляет различные уровни детализации,

• обеспечивает достижение конкретной цели.

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

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

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

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

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

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

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

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

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

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

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

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

Примеры диаграмм UML

Чтобы получить более наглядное представление, приведем ряд диаграмм UML. Рассмотрим пример, в котором описана объектная модель, построен­ная в Rational Rose 98. В качестве предметной области используем описание работы библиотеки, которая получает запросы от клиентов на различные из­дания и регистрирует информацию об их возвращении в фонды библиотеки. Пример диаграммы прецедентов использования приведен на рис. 7.5. На диаграмме приведен ряд выделенных при анализе реализуемых информаци­онной системой функций: администрирование пользователей (Administrative Client); учет книг (Administrative Books); составление отчетов (Report) и по­иск издания (Find Book).

 

Рис. 7.5 Диаграмма прецедентов использования

 

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

 

Рис. 7.6 Диаграмма следования

 

 

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

7.5. Классификация CASE-средств

При классификации CASE-средств используют следующие признаки:

• ориентацию на этапы жизненного цикла;

• функциональную полноту;

• тип используемой модели;

• степень независимости от СУБД;

• допустимые платформы.

Рассмотрим классификацию CASE-средств по наиболее часто используе­мым признакам.

По ориентации на этапы жизненного цикла выделяют следующие основ­ные типы CASE-средств:

• средства анализа, предназначенные для построения и анализа моделей
предметной области, например: Design/IDEF (Meta Software) и BPwm (Logic Works);

• средства анализа и проектирования, обеспечивающие создание проект­ных спецификаций, например: Vantage Team Builder (Cayenne), Silverrun (Silverrun Technologies), PRO-IV (McDonnell Douglas) и CASE. Аналитик (МакроПроджект);

• средства проектирования баз данных, обеспечивающие моделирова­ние данных и разработку схем баз данных для основных СУБД, на­пример: ERwin (Logic Works), S-Designor (SPD), DataBase Designer

(ORACLE);

• средства разработки приложений, например: Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Centura) и Delphi (Borland).

 

По функциональной полноте CASE-системы и средства можно условно разделить на следующие типы:

• системы, предназначенные для решения частных задач на одном или не­скольких этапах жизненного цикла, например, ERwin (Logic Works), S-Designor (SPD), CASE.Аналитик (МакроПроджект) и Silverrun (Silverrun Technologies);

• интегрированные системы, поддерживающие весь жизненный цикл И С и связанные с общим репозиторием, например система Vantage Team Builder (Cayenne) и система Designer/2000 с системой разработки при­ложений Developer/2000 (ORACLE).

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

комбинированные.

Исторически первые структурные CASE-системы основаны на методах структурного и модульного программирования, структурного анализа и син­теза, например, система Vantage Team Builder (Cayenne).

Объектно-ориентированные методы и CASE-системы получили массовое использование с начала 90-х годов. Они позволяют сократить сроки разра­ботки, а также повысить надежность и эффективность функционирования ИС. Примерами объектно-ориентированных CASE-систем являются Rational Rose (Rational Software) и Object Team (Cayenne).

Комбинированные инструментальные средства поддерживают одновремен­но структурные и объектно-ориентированные методы, например: Designer/ 2000 (ORACLE).

 

По степени независимости от СУБД CASE-системы можно разделить

на две группы:

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

• встроенные в СУБД.

Независимые CASE-системы поставляются в виде автономных систем, не входящих в состав конкретной СУБД. Обычно они поддерживают несколько форматов баз данных через интерфейс ODBC. К числу независимых CASE- систем относятся S-Designor (SDP, Powersoft), ERwin (Logic Works) и Silverrun (Computer Systems Advisers Inc.).

Встроенные CASE-системы обычно поддерживают главным образом фор­мат баз данных СУБД, в состав которой они входят. При этом возможна поддержка и других форматов баз данных. Примером встроенной системы явля­ется Designer/2000, входящая в состав СУБД ORACLE.

 

Защита информации

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

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

 

Основные определения

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

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

Движение информации в ЭВМ неразрывно связано с функционирова­нием программ ее обработки и обслуживания, поэтому при рассмотрении защиты информации в ВС говорят об информационно-программном обес­печении (ИПО).

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

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

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

Для эффективного построения системы защиты необходимо:

1. выделить уязвимые элементы вычислительной системы;
2. выявить угрозы для выделенных элементов;
3. сформировать требования к системе защиты;
4. выбрать методы и средства удовлетворения предъявленным требо­ваниям.

 

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

 

Основными видами угроз в ВС являются следующие:

1. Несанкционированного использования ресурсов ВС:

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

• копирование и модификация программ;

• исследование программ для последующего вторжения в систему.

2. Некорректного использования ресурсов ВС:

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

• случайный доступ к системным областям дисковой памяти;

• некорректное изменение баз данных (ввод неверных данных, нарушение ссылочной целостности данных);

• ошибочные действия пользователей и персонала.

 

3. Проявления ошибок в программных и аппаратных средствах.

4. Перехвата данных в линиях связи и системах передачи.

5. Несанкционированной регистрации электромагнитных излучений.

6. Хищения устройств ВС, носителей информации и документов.

7. Несанкционированного изменения состава компонентов ВС, средств пе­редачи информации или их вывода из строя и т. д.

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

1. получение секретных сведений;
2. снижение производительности или остановка системы;
3. невозможность загрузки операционной системы с жесткого диска;
4. материальный ущерб;
5. катастрофические последствия.

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

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

• защита информации от хищения;

• защита информации от потери;

• защита ВС от сбоев и отказов.

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

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

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

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

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

1. Внешний уровень, охватывающий всю территорию расположения ВС.

2. Уровень отдельных сооружений или помещений расположения устройств ВС и линий связи с ними.

3. Уровень компонентов ВС и внешних носителей информации.

4. Уровень технологических процессов хранения, обработки и передачи ин­формации.

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

Методы и средства защиты

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

• физические;

• аппаратные;

• программные;

• организационные.

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

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

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

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

• кабельные системы, в которых небольшие объекты окружают кабелем, чувствительным к приближению нарушителя;

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

• механические и электронные замки на двери и ворота;

• системы нейтрализации излучений.

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

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

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

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

Остановимся более подробно на наиболее гибких и мощных методах за­щиты - программно-аппаратных методах, реализуемых в ВС.