- 1. Теоретическое введение
- 1.2. Основные понятия объектно-ориентированного подхода
- 1.3. Применение объектно-ориентированного подхода к рассмотрению защищаемых систем
- 1.4. Недостатки традиционного подхода к информационной безопасности с объектной точки зрения
- 2. Порядок выполнения работы
- 4. Контрольные вопросы Вариант 1 1. Объектно-ориентированный подход помогает справляться с
- 2. Объектно-ориентированный подход использует
- 3. Требование безопасности повторного использованияобъектов противоречит
- Вариант 2 1. Любой разумный метод борьбы со сложностью опирается на принцип
- 2. В число основных понятий объектного подхода не входит
- Предположим, что при разграничении доступа учитывается семантика программ. В таком случае на просмотрщик файлов определенного формата могут быть наложены следующие ограничения
- Вариант 3 1. Структурный подход опирается на
- 2. Контейнеры в компонентных объектных средах предоставляют
- 3. Метод объекта реализует волю
оиб л.р.2. оиб л.р. Лабораторная работа 2 " Распространение объектноориентированного подхода на информационную безопасность "
 Скачать 91.5 Kb.
|
|
ЛАБОРАТОРНАЯ РАБОТА № 2 “ Распространение объектно-ориентированного подхода на информационную безопасность ”Цель работы:Изучить необходимые понятия объектно-ориентированного подхода, уровни мер в области ИБ с небольшим числом сущностей на каждом из них. 1. Теоретическое введение 1.1 О необходимости объектно-ориентированного подхода к информационной безопасностиВ настоящее время информационная безопасность является относительно замкнутой дисциплиной, развитие которой не всегда синхронизировано с изменениями в других областях информационных технологий. В частности, в ИБ пока не нашли отражения основные положения объектно-ориентированного подхода, ставшего основой при построении современных информационных систем. Не учитываются в ИБ и достижения в технологии программирования, основанные на накоплении и многократном использовании программистских знаний. На наш взгляд, это очень серьезная проблема, затрудняющая прогресс в области ИБ. Попытки создания больших систем еще в 60-х годах вскрыли многочисленные проблемы программирования, главной из которых является сложность создаваемых и сопровождаемых систем. Результатами исследований в области технологии программирования стали сначала структурированное программирование, затем объектно-ориентированный подход. Объектно-ориентированный подход является основой современной технологии программирования, испытанным методом борьбы со сложностью систем. Представляется естественным и, более того, необходимым, стремление распространить этот подход и на системы информационной безопасности, для которых, как и для программирования в целом, имеет место упомянутая проблема сложности. Сложность эта имеет двоякую природу. Во-первых, сложны не только аппаратно-программные системы, которые необходимо защищать, но и сами средства безопасности. Во-вторых, быстро нарастает сложность семейства нормативных документов, таких, например, как профили защиты на основе "Общих критериев", речь о которых впереди. Эта сложность менее очевидна, но ею также нельзя пренебрегать; необходимо изначально строить семейства документов по объектному принципу. Любой разумный метод борьбы со сложностью опирается на принцип "devide et impera" - "разделяй и властвуй". В данном контексте этот принцип означает, что сложная система (информационной безопасности) на верхнем уровне должна состоять из небольшого числа относительно независимых компонентов. Относительная независимость здесь и далее понимается как минимизация числа связей между компонентами. Затем декомпозиции подвергаются выделенные на первом этапе компоненты, и так далее до заданного уровня детализации. В результате система оказывается представленной в виде иерархии с несколькими уровнями абстракции. Важнейший вопрос, возникающий при реализации принципа "разделяй и властвуй", - как, собственно говоря, разделять. Упоминавшийся выше структурный подход опирается на алгоритмическую декомпозицию, когда выделяются функциональные элементы системы. Основная проблема структурного подхода состоит в том, что он неприменим на ранних этапах анализа и моделирования предметной области, когда до алгоритмов и функций дело еще не дошло. Нужен подход "широкого спектра", не имеющий такого концептуального разрыва с анализируемыми системами и применимый на всех этапах разработки и реализации сложных систем . Объектно-ориентированный подход удовлетворяет таким требованиям . 1.2. Основные понятия объектно-ориентированного подхода Объектно-ориентированный подход использует объектную декомпозицию, то есть поведение системы описывается в терминах взаимодействия объектов. Что же понимается под объектом и каковы другие основополагающие понятия данного подхода? Прежде всего, введем понятие класса. Класс - это абстракция множества сущностей реального мира, объединенных общностью структуры и поведения. Объект - это элемент класса, то есть абстракция определенной сущности. Подчеркнем, что объекты активны, у них есть не только внутренняя структура, но и поведение, которое описывается так называемыми методами объекта. Например, может быть определен класс "пользователь", характеризующий "пользователя вообще", то есть ассоциированные с пользователями данные и их поведение (методы). После этого может быть создан объект "пользователь Иванов" с соответствующей конкретизацией данных и, возможно, методов. К активности объектов мы еще вернемся. Следующую группу важнейших понятий объектного подхода составляют инкапсуляция, наследование и полиморфизм. Основным инструментом борьбы со сложностью в объектно-ориентированном подходе является инкапсуляция - сокрытие реализации объектов (их внутренней структуры и деталей реализации методов) с предоставлением вовне только строго определенных интерфейсов. Понятие "полиморфизм" может трактоваться как способность объекта принадлежать более чем одному классу. Введение этого понятия отражает необходимость смотреть на объекты под разными углами зрения, выделять при построении абстракций разные аспекты сущностей моделируемой предметной области, не нарушая при этом целостности объекта. (Строго говоря, существуют и другие виды полиморфизма, такие как перегрузка и параметрический полиморфизм, но нас они сейчас не интересуют.) Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. Наследование является важным инструментом борьбы с размножением сущностей без необходимости. Общая информация не дублируется, указывается только то, что меняется. При этом класс-потомок помнит о своих "корнях". Очень важно и то, что наследование и полиморфизм в совокупности наделяют объектно-ориентированную систему способностью к относительно безболезненной эволюции. Средства информационной безопасности приходится постоянно модифицировать и обновлять, и если нельзя сделать так, чтобы это было экономически выгодно, ИБ из инструмента защиты превращается в обузу. Мы еще вернемся к механизму наследования при рассмотрении ролевого управления доступом. Пополним рассмотренный выше классический набор понятий объектно-ориентированного подхода еще двумя понятиями: грани объекта и уровня детализации. Объекты реального мира обладают, как правило, несколькими относительно независимыми характеристиками. Применительно к объектной модели будем называть такие характеристики гранями. Мы уже сталкивались с тремя основными гранями ИБ - доступностью, целостностью и конфиденциальностью. Понятие грани позволяет более естественно, чем полиморфизм, смотреть на объекты с разных точек зрения и строить разноплановые абстракции. Понятие уровня детализации важно не только для визуализации объектов, но и для систематического рассмотрения сложных систем, представленных в иерархическом виде. Само по себе оно очень простое: если очередной уровень иерархии рассматривается с уровнем детализации n > 0, то следующий - с уровнем (n - 1). Объект с уровнем детализации 0 считается атомарным. Понятие уровня детализации показа позволяет рассматривать иерархии с потенциально бесконечной высотой, варьировать детализацию как объектов в целом, так и их граней. Весьма распространенной конкретизацией объектно-ориентированного подхода являются компонентные объектные среды, к числу которых принадлежит, например, JavaBeans. Здесь появляется два новых важных понятия: компонент и контейнер. Неформально компонент можно определить как многократно используемый объект, допускающий обработку в графическом инструментальном окружении и сохранение в долговременной памяти. Контейнеры могут включать в себя множество компонентов, образуя общий контекст взаимодействия с другими компонентами и с окружением. Контейнеры могут выступать в роли компонентов других контейнеров. Компонентные объектные среды обладают всеми достоинствами, присущими объектно-ориентированному подходу:
Понятия же компонента и контейнера необходимы нам потому, что с их помощью мы можем естественным образом представить защищаемую ИС и сами защитные средства. В частности, контейнер может определять границы контролируемой зоны (задавать так называемый "периметр безопасности"). На этом мы завершаем описание основных понятий объектно-ориентированного подхода. 1.3. Применение объектно-ориентированного подхода к рассмотрению защищаемых систем Попытаемся применить объектно-ориентированный подход к вопросам информационной безопасности. Проблема обеспечения информационной безопасности - комплексная, защищать приходится сложные системы, и сами защитные средства тоже сложны, поэтому нам понадобятся все введенные понятия. Начнем с понятия грани. Фактически три грани уже были введены: это доступность, целостность и конфиденциальность. Их можно рассматривать относительно независимо, и считается, что если все они обеспечены, то обеспечена и ИБ в целом (то есть субъектам информационных отношений не будет нанесен неприемлемый ущерб). Таким образом, мы структурировали нашу цель. Теперь нужно структурировать средства ее достижения. Введем следующие грани:
В дальнейшей части курса мы поясним подробнее, что понимается под каждой из выделенных граней. Здесь же отметим, что, в принципе, их можно рассматривать и как результат варьирования уровня детализации (по этой причине мы будем употреблять словосочетания "законодательный уровень", "процедурный уровень" и т.п.). Законы и нормативные акты ориентированы на всех субъектов информационных отношений независимо от их организационной принадлежности (это могут быть как юридические, так и физические лица) в пределах страны (международные конвенции имеют даже более широкую область действия), административные меры - на всех субъектов в пределах организации, процедурные - на отдельных людей (или небольшие категории субъектов), программно-технические - на оборудование и программное обеспечение. При такой трактовке в переходе с уровня на уровень можно усмотреть применение наследования (каждый следующий уровень не отменяет, а дополняет предыдущий), а также полиморфизма (субъекты выступают сразу в нескольких ипостасях - например, как инициаторы административных мер и как обычные пользователи, обязанные этим мерам подчиняться). Очевидно, для всех выделенных, относительно независимых граней действует принцип инкапсуляции (это и значит, что грани "относительно независимы"). Более того, эти две совокупности граней можно назвать ортогональными, поскольку для фиксированной грани в одной совокупности (например, доступности) грани в другой совокупности должны пробегать все множество возможных значений (нужно рассмотреть законодательные, административные, процедурные и программно-технические меры). Ортогональных совокупностей не должно быть много; думается, двух совокупностей с числом элементов, соответственно, 3 и 4 уже достаточно, так как они дают 12 комбинаций. Продемонстрируем теперь, как можно рассматривать защищаемую ИС, варьируя уровень детализации. Пусть интересы субъектов информационных отношений концентрируются вокруг ИС некой организации, располагающей двумя территориально разнесенными производственными площадками, на каждой из которых есть серверы, обслуживающие своих и внешних пользователей, а также пользователи, нуждающиеся во внутренних и внешних сервисах. Одна из площадок оборудована внешним подключением (то есть имеет выход в Internet). При взгляде с нулевым уровнем детализации мы увидим лишь то, что у организации есть информационная система (см. рис. 2.0).  Рис. 2.0. ИС при рассмотрении с уровнем детализации 0. Подобная точка зрения может показаться несостоятельной, но это не так. Уже здесь необходимо учесть законы, применимые к организациям, располагающим информационными системами. Возможно, какую-либо информацию нельзя хранить и обрабатывать на компьютерах, если ИС не была аттестована на соответствие определенным требованиям. На административном уровне могут быть декларированы цели, ради которых создавалась ИС, общие правила закупок, внедрения новых компонентов, эксплуатации и т.п. На процедурном уровне нужно определить требования к физической безопасности ИС и пути их выполнения, правила противопожарной безопасности и т.п. На программно-техническом уровне могут быть определены предпочтительные аппаратно-программные платформы и т.п. По каким критериям проводить декомпозицию ИС - в значительной степени дело вкуса. Будем считать, что на первом уровне детализации делаются видимыми сервисы и пользователи, точнее, разделение на клиентскую и серверную часть (рис. 1). ИС органтзации : Сервисы ( без конкретизации ) Пользователи ( без конкретизации ) Рис.1. ИС при рассмотрении с уровнем детализации 1. На этом уровне следует сформулировать требования к сервисам (к самому их наличию, к доступности, целостности и конфиденциальности предоставляемых информационных услуг), изложить способы выполнения этих требований, определить общие правила поведения пользователей, необходимый уровень их предварительной подготовки, методы контроля их поведения, порядок поощрения и наказания и т.п. Могут быть сформулированы требования и предпочтения по отношению к серверным и клиентским платформам. На втором уровне детализации мы увидим следующее (см. рис.2).  Рис. 2. ИС при рассмотрении с уровнем детализации 2. На этом уровне нас все еще не интересует внутренняя структура ИС организации, равно как и детали Internet. Констатируется только существование связи между этими сетями, наличие в них пользователей, а также предоставляемых и внутренних сервисов. Что это за сервисы, пока неважно. Находясь на уровне детализации 2, мы должны учитывать законы, применимые к организациям, ИС которых снабжены внешними подключениями. Речь идет о допустимости такого подключения, о его защите, об ответственности пользователей, обращающихся к внешним сервисам, и об ответственности организаций, открывающих свои сервисы для внешнего доступа. Конкретизация аналогичной направленности, с учетом наличия внешнего подключения, должна быть выполнена на административном, процедурном и программно-техническом уровнях. Обратим внимание на то, что контейнер (в смысле компонентной объектной среды) "ИС организации" задает границы контролируемой зоны, в пределах которых организация проводит определенную политику. Internet живет по другим правилам, которые организация должна принимать, как данность. Увеличивая уровень детализации, можно разглядеть две разнесенные производственные площадки и каналы связи между ними, распределение сервисов и пользователей по этим площадкам и средства обеспечения безопасности внутренних коммуникаций, специфику отдельных сервисов, разные категории пользователей и т.п. Мы, однако, на этом остановимся. Мы постараемся показать, что объектно-ориентированный подход удовлетворяет таким требованиям. 1.4. Недостатки традиционного подхода к информационной безопасности с объектной точки зрения Исходя из основных положений объектно-ориентированного подхода, следует в первую очередь признать устаревшим традиционное деление на активные и пассивные сущности (субъекты и объекты в привычной для дообъектной ИБ терминологии). Подобное деление устарело, по крайней мере, по двум причинам. Во-первых, в объектном подходе пассивных объектов нет. Можно считать, что все объекты активны одновременно и при необходимости вызывают методы друг друга. Как реализованы эти методы (и, в частности, как организован доступ к переменным и их значениям) - внутреннее дело вызываемого объекта; детали реализации скрыты, инкапсулированы. Вызывающему объекту доступен только предоставляемый интерфейс. Во-вторых, нельзя сказать, что какие-то программы (методы) выполняются от имени пользователя. Реализации объектов сложны, так что последние нельзя рассматривать всего лишь как инструменты выполнения воли пользователей. Скорее можно считать, что пользователь прямо или (как правило) косвенно, на свой страх и риск, "просит" некоторый объект об определенной информационной услуге. Когда активизируется вызываемый метод, объект действует скорее от имени (во всяком случае, по воле) своего создателя, чем от имени вызвавшего его пользователя. Можно считать, что объекты обладают достаточной "свободой воли", чтобы выполнять действия, о которых пользователь не только не просил, но даже не догадывается об их возможности. Особенно это справедливо в сетевой среде и для программного обеспечения (ПО), полученного через Internet, но может оказаться верным и для коммерческого ПО, закупленного по всем правилам у солидной фирмы. Для иллюстрации приведем следующий гипотетический пример. Банк, ИС которого имеет соединение с Internet, приобрел за рубежом автоматизированную банковскую систему (АБС). Только спустя некоторое время в банке решили, что внешнее соединение нуждается в защите, и установили межсетевой экран. Изучение регистрационной информации экрана показало, что время от времени за рубеж отправляются IP-пакеты, содержащие какие-то непонятные данные (наверное, зашифрованные, решили в банке). Стали разбираться, куда же пакеты направляются, и оказалось, что идут они в фирму, разработавшую АБС. Возникло подозрение, что в АБС встроена закладка, чтобы получать информацию о деятельности банка. Связались с фирмой; там очень удивились, поначалу все отрицали, но в конце концов выяснили, что один из программистов не убрал из поставленного в банк варианта отладочную выдачу, которая была организована через сеть (как передача IP-пакетов специфического вида, с явно заданным IP-адресом рабочего места этого программиста). Таким образом, никакого злого умысла не было, однако некоторое время информация о платежах свободно гуляла по сетям. В дальнейшей части курса, в лекции, посвященной разграничению доступа, мы обсудим, как можно кардинальным образом решить подобные проблемы. Здесь отметим лишь, что при определении допустимости доступа важно не только (и не столько), кто обратился к объекту, но и то, какова семантика действия. Без привлечения семантики нельзя определить так называемые "троянские программы", выполняющие, помимо декларированных, некоторые скрытые (обычно негативные) действия. По-видимому, следует признать устаревшим и положение о том, что разграничение доступа направлено на защиту от злоумышленников. Приведенный выше пример показывает, что внутренние ошибки распределенных ИС представляют не меньшую опасность, а гарантировать их отсутствие в сложных системах современная технология программирования не позволяет. В до объектной ИБ одним из важнейших требований является безопасность повторного использования пассивных сущностей (таких, например, как динамически выделяемые области памяти). Очевидно, подобное требование вступает в конфликт с таким фундаментальным принципом, как инкапсуляция. Объект нельзя очистить внешним образом (заполнить нулями или случайной последовательностью бит), если только он сам не предоставляет соответствующий метод. При наличии такого метода надежность очистки зависит от корректности его реализации и вызова. Одним из самых прочных стереотипов среди специалистов по ИБ является трактовка операционной системы как доминирующего средства безопасности. На разработку защищенных ОС выделяются значительные средства, зачастую в ущерб остальным направлениям защиты и, следовательно, в ущерб реальной безопасности. В современных ИС, выстроенных в многоуровневой архитектуре клиент/сервер, ОС не контролирует объекты, с которыми работают пользователи, равно как и действия самих пользователей, которые регистрируются и учитываются прикладными средствами. Основной функцией безопасности ОС становится защита возможностей, предоставляемых привилегированным пользователям, от атак пользователей обычных. Это важно, но безопасность такими мерами не исчерпывается. Далее мы рассмотрим подход к построению программно-технического уровня ИБ в виде совокупности сервисов безопасности. 2. Порядок выполнения работы 1.Ознакомиться с методическими основами курса . 2.Выполнить практическое задание. 3.Ответить на контрольные вопросы. 3. Практические задания 1. Разработать интерфейс пользователя «Основных понятий объектно-ориентированного подхода». 2. Разработать интерфейс пользователя «Применение объектно-ориентированного подхода к рассмотрению защищаемых систем». 4. Контрольные вопросы Вариант 11. Объектно-ориентированный подход помогает справляться с:
2. Объектно-ориентированный подход использует:
3. Требование безопасности повторного использования объектов противоречит:
4. Предположим, что при разграничении доступа учитывается семантика программ. В таком случае на текстовый редактор могут быть наложены следующие ограничения:
Вариант 2 1. Любой разумный метод борьбы со сложностью опирается на принцип:
2. В число основных понятий объектного подхода не входит:
Вариант 3 1. Структурный подход опирается на:
2. Контейнеры в компонентных объектных средах предоставляют:
3. Метод объекта реализует волю:
4. Предположим, что при разграничении доступа учитывается семантика программ. В таком случае на игровую программу могут быть наложены следующие ограничения:
|