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

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

Правило 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-системе.

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

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

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

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

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

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

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

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

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

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

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

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (International Organization 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 Management 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. Перехвата данных в линиях связи и системах передачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Статьи к прочтению:

Какие типы связей между таблицами существуют в БД Access

Похожие статьи: