Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Теоретические основы защиты информации. Учебное пособие
.pdf
Посылка
документов
по почте
Отсутствие классификации на
внешнем конверте.
Метка «Конфиденциально» на обложке или титульном листе. Подтверждение о получении по требованию владельца
информации
Требования
определяются
владельцем
информации
Нет специальных требований
Уничтожение
документов
Владелец наблюдает за уничтожением документов и
невозможностью
их восстановления
Контролируется физическое
разрушение
Нет специальных требований
Хранение
документов
Заперты, если не
используются
Оригинал
охраняется от
уничтожения
Оригинал охраняется от уничтожения
Доступ
к документу
Владелец организует правила доступа к документу,
обычно сильно
ограниченные
Владелец организует правила доступа к
документу,
обычно широко доступные
Нет специальных требований.
Обычно документы доступны
внутри и вне
организации
Рассмотрение
уровня классификации
документа
Владелец определяет дату пересмотра классификации документа
(не реже раза в
год)
Владелец пересматривает
классификацию документа
(не реже раза в
год)
Нет специальных требований
В качестве другого примера неформального описания политики
безопасности можно привести описание политики безопасности использования электронных коммуникаций организации. В данном
описании учтены не только требования, соответствующие политике
разграничения доступа, но и требования вспомогательных политик
безопасности. Описание включает в себя следующие положения.
1. Собственность. Под сообщениями электронных коммуника-
ций понимаются голосовая и электронная почта, а также факсы.
81
Все сообщения, создаваемые и обрабатываемые с помощью электронных коммуникаций организации (включая резервные копии),
принадлежат организации, а не пользователям электронных коммуникаций.
2. Авторизация. Система электронных коммуникаций органи-
зации может быть использована только в целях бизнеса. Личное
использование электронных коммуникаций возможно, если оно:
– занимает мало ресурсов;
– не влияет на производительность труда;
– не влияет на бизнес-процесс.
3. Минимальные привилегии. Пользователям должен быть дан
минимум привилегий по использованию системы электронных
коммуникаций, необходимых им для выполнения работы (например, рядовой пользователь не должен иметь прав изменять конфигурацию коммуникационного программного обеспечения).
4. Разделение пользователей. Система должна по возможности
разделять деятельность разных пользователей, распознаваемых
с помощью идентификаторов пользователей и паролей (это может
быть затруднительно, например, для факсовых аппаратов).
5. Полномочия пользователей. Пользователи не должны
разделять пароли или сообщения. При необходимости обмена
полученными сообщениями следует использовать механизм
распространения и другие авторизованные механизмы обмена
ин формацией.
6. Отсутствие защиты по умолчанию. В системе не применяется шифрование сообщений по умолчанию. При пересылке чувствительной к раскрытию информации она должна быть зашифрована или защищена с помощью аналогичных шифрованию технологий.
7. Уважение права на тайну. За исключением специально оговоренных случаев, пользователи не могут вмешиваться в нормальную работу системы электронных коммуникаций с целью нарушения целостности или конфиденциальности сообщений. Компания
уважает разумную конфиденциальность сообщений пользователей,
организуя защиту системы электронных коммуникаций.
8. Отсутствие гарантий тайны сообщений. Компания не может
гарантировать тайну сообщений. Пользователи должны быть осве-
82
домлены, что система электронных коммуникаций базируется на
технологиях, которые не могут дать полной уверенности в конфиденциальности информации. Более того, их сообщения в особых
случаях (см. ниже) могут быть доступны другим пользователям.
9. Регулярный мониторинг сообщений. Содержимое сообщений не просматривается регулярно. Однако такой мониторинг может быть осуществлен в целях безопасности, поддержки функционирования бизнеса, а также при расследовании инцидентов. Пользователи должны быть проинформированы о возможности мониторинга.
10. Статистика. В организации собирается статистика по использованию системы электронных коммуникаций. На основании
данной статистики можно сделать заключения, например, о доступности системы.
11. Раскрытие при происшествиях. Администратору системы
может понадобиться просматривать содержимое сообщений при
расследовании происшествий. При этом беспричинный просмотр
содержимого сообщений запрещен.
12. Распространение сообщений. Вследствие того что некоторые виды информации предназначены для использования определенными пользователями, а не все ми пользователями системы,
необходимо аккуратно распространять сообщения. Служебная информация организации не должна распространяться за пределы
системы электронных коммуникаций организации без разрешения
специального лица.
13. Удаление сообщений. Сообщения, необходимость которых
для целей бизнеса исчерпана, должны периодически удаляться. По
истечении определенного периода (обычно 6 месяцев) резервные
копии сообщений удаляются. Если компания находится в особом
режиме работы (например, вовлечена в судебный процесс), то сообщения могут удаляться только с разрешения специально оговоренного лица.
14. Запрещена посылка спама, в том числе рекламных сообщений, без получения предварительного запроса.
15. Запрещена подделка заголовков сообщений электронной
почты.
83
Данная политика безопасности сформулирована в виде списка
требований. Требования, относящиеся к политике разграничения
доступа, желательно определить отдельно.
Преимуществом такого способа представления политики безопасности является то, что она гораздо легче для понимания пользователями, чем формальное описание, так как для ее понимания
не требуется специальных математических знаний. Это снижает
вероятность атак на вычислительную систему по причине ее некорректной эксплуатации вследствие непонимания принципов разработки системы.
Основным недостатком неформального описания политики
безопасности системы является то, что при такой форме представления правил доступа в системе гораздо легче допустить логические ошибки при проектировании системы и ее эксплуатации, приводящие к нарушению безопасности системы. Особенно это справедливо для политик безопасности нетривиальных систем, подобных распределенным вычислительным системам.
Необходимо отметить, что неформально могут быть описаны
не только политики, но и модели безопасности. Примером неформального описания модели безопасности может служить модель
Кларка–Вилсона, рассматриваемая далее.
5.3. Формальное описание политики безопасности
Требование формального описания характерно для систем, область применения которых критична. В частности, можно отметить
тот факт, что для защищенных вычислительных систем высокой
степени надежности необходимы формальное представление и
формальный анализ системы. Практическое значение применения
формальных методов при анализе систем заключается в возможности анализа всех реакций сложной программной системы.
В основе формального описания политики безопасности лежит модель безопасности, или модель защиты.
В соответствии с [2] модель защиты (безопасности) есть абстрактное (формализованное или неформализованное) описание
комплекса программно-технических средств и (или) организационных мер защиты от несанкционированного доступа.
К модели безопасности должны предъявляться требования,
общие для всех моделей:
84
– адекватность;
– способность к предсказанию;
– общность.
Для автоматизации процесса доказательства свойств системы
используются так называемые «доказатели теорем» – программное
обеспечение, проводящее формальную дедукцию на основе комбинации эвристик и непосредственного поиска. Другим видом программного обеспечения, используемого при формальном анализе
систем, являются «контроллеры доказательств» – программы,
предоставляющие пользователю возможность проводить последовательность шагов в процессе логических выводов о свойствах системы, но проверяющие корректность каждого шага. Естественно,
самыми эффективными средствами формального анализа являются
средства, сочетающие в себе свойства двух приведенных выше видов программного обеспечения.
Преимуществом формального описания является отсутствие
противоречий в политике безопасности и возможность теоретического доказательства безопасности системы при соблюдении всех
условий политики безопасности.
С другой стороны, можно сказать, что применение формальных методов для анализа систем, содержащих программное обеспечение, имеет недостаток, присущий всем методам моделирования: формальные методы имеют дело не с самой системой, а с ее
моделью, которая может не отражать реальность или отражать ее
неадекватно.
Данная проблема может возникнуть вследствие использования
модели, учитывающей не все факторы, оказывающие влияние на
реальную систему. С другой стороны, излишняя подробность описания системы ведет к резкому росту временных затрат на проведение формального анализа и к неэффективности применения данного метода.
Таким образом, возникает задача корректного выбора уровня
абстракции в описании модели безопасности. Под уровнем абстракции понимается множество требований к реальной системе,
которые должны найти свое отражение в модели для адекватного
отображения моделируемой системы.
85
Недостатки использования формальных методов хорошо описаны Дороти Деннинг. В своей статье она описала опыт работ
в области безопасности с использованием формальных методов и
выявила следующие проблемы.
1. Неразрешимость некоторых проблем безопасности с ис-
пользованием формальных методов; в качестве примера можно
привести модель Харрисона–Руззо–Ульмана (см. главу 5), а также
результаты Коэна, свидетельствующие о том, что невозможно построить антивирусное средство, детектирующее все возможные
вирусы.
2. Использование формальных методов при разработке систем
может привести к появлению систем, практическое использование
которых весьма неудобно; в качестве примера Деннинг приводит
свое участие в разработке СУБД SeaView; в данной СУБД для
внедрения мандатной модели безопасности была использована
концепция (оправданная с теоретической, но не с практической
точки зрения), состоящая в поддержании многочисленных экземпляров значения поля базы данных (по одному для каждого уровня
безопасности), что привело к большим сложностям реализации и
неудобству использования СУБД.
3. Использование формальных методов при разработке систем
приводит к дорогостоящим и отнимающим много времени проектам; этот вывод был сделан на основе работ Деннинг над проектом
по разработке формально безопасной операционной системы VAX
Secure Virtual System; при начале работ над данным проектом планировалось завершить его за три года, затратив миллионы долларов; однако вместо этого проект был через три года закрыт в связи
с тем, что ожидаемые объемы продаж не могли покрыть расходов
на продолжение разработки.
4. Многие нарушения безопасности происходят вследствие
некорректного использования пользователями компьютерных систем; даже в том случае, если в основу разработки системы заложена самая стойкая модель безопасности и устранены все каналы
утечки информации, безопасность системы может быть нарушена
в результате использования слабого пароля, оставленной слабости
или ошибки реализации.
86
5. Модели безопасности часто не обеспечивают безопасности
реальной системы; безопасность обеспечивается только в рамках
формальной модели, которая часто бывает упрощенной; любой
выход за пределы модели влечет нарушение безопасности.
Примером формального описания модели безопасности может
служить модель Белла и Лападула.
Контрольные вопросы
1. Что понимается под политикой безопасности вычислитель-
ной системы организации.
2. Как оформляется политика безопасности?
3. Сравните формальное и неформальное описание политики
безопасности. Опишите достоинства и недостатки каждого подхода.
4. Приведите примеры политик безопасности, связанных со
сферой деятельности организации.
5. Поясните схему процесса разработки политики безопасно-
сти вычислительной системы.
6. Какие правила используются для описания политики без-
опасности на различных уровнях политики безопасности в процессе ее разработки?
7. Какие формы используются для описания политики без-
опасности?
8. Приведите примеры неформального описания политики
безопасности.
9. Какие основные операций выполняются субъектами систе-
мы над объектами при описании политики безопасности?
10. Какие внешние условия учитываются при описании огра-
ничений на операции в системе?
11. В чем заключается сущность формального описания поли-
тики безопасности.
12. Что понимается под моделью безопасности и какие требо-
вания к ней предъявляются?
13. В чем заключаются недостатки использования формаль-
ных методов?
14. Разработайте неформальную политику безопасности для
учебного класса.
87
6. ДИСКРЕЦИОННЫЙ КОНТРОЛЬ
Объекты
Субъекты
Файл 1
Файл 2
Файл 3
Процесс 1
Процесс 2
Процесс 1
R RWOX
Процесс 2
RW R RW
RWOX
Процесс 3
RW
Процесс 4
И УПРАВЛЕНИЕ ДОСТУПОМ
В данной главе рассмотрим основные модели безопасности,
описывающие дискреционный (произвольный) контроль и управление доступом, а также механизмы, которые необходимо реализовать в вычислительных системах для его поддержки.
Дискреционное управление доступом в соответствии с [2] есть
разграничение доступа между поименованными субъектами и поименованными объектами. Передача прав доступа к объектам
между субъектами производится также в соответствии с правами
доступа субъектов к объектам на основании правил, определенных
конкретной дискреционной моделью.
6.1. Матрица доступа
Для того чтобы описать дискреционный контроль доступа, используется матрица доступа. Матрица доступа является таблицей,
отображающей правила разграничения доступа. Матрица доступа
является концептуальной моделью, которая специфицирует права
доступа, которые имеет каждый субъект по отношению к каждому
объекту. Задачей механизма контроля доступа является обеспечение того, что в системе авторизованными являются операции с
правами доступа, определенными в матрице доступа.
Строки матрицы доступа соответствуют субъектам, а столбцы –
объектам.
В ячейках матрицы содержатся права доступа субъектов к
объектам. Пример матрицы дискреционного контроля доступа
приведен в табл. 6.1.
Таблица 6.1
Матрица дискреционного контроля доступа
88
В данной таблице:
R – права доступа пользователя по чтению;
W – права доступа пользователя по записи;
X – право на выполнение процесса;
О – управление доступом к файлу для других пользователей.
Например, в Windows используется набор стандартных прав,
которые можно устанавливать для каталогов и файлов. Стандартными правами для каталогов являются No Access, Read, Add,
Add&Read, Change и Full Control. Стандартными разрешениями
для файлов являются No Access, Read, Change и Full Control.
Стандартные права представляют собой группы индивидуальных разрешений. Каждому стандартному праву соответствует
определенная установка фиксированного набора индивидуальных
разрешений. Индивидуальные разрешения могут быть следующими: Read (R), Write (W), Execute (X), Delete (D), Change Permission
(P), Take Ownership (O).
При установке стандартного разрешения для каталога или
файла посредством графического интерфейса Windows рядом с
ним в скобках отображаются заглавные буквы установленных индивидуальных разрешений. Например, при установке для файла
стандартного разрешения Read рядом со словом Read появляется
аббревиатура RX, которая означает, что стандартному разрешению
Read соответствует установка двух индивидуальных разрешений –
Read и Execute.
Для файлов имеется следующее соответствие индивидуальных
и стандартных разрешений:
No Access – Ни одного
Read – RX
Change – RWXD
Full Control – Все разрешения
Стандартные разрешения для каталога представляют собой
объединения индивидуальных разрешений для каталога и для файлов, входящих в этот каталог:
No Access – (Ни одного) (Ни одного)
List – (RX) (Не определены)
Read – (RX) (RX)
Add – (WX) (He определены)
89
Add&Read – (RWX) (RX)
Change – (RWXD) (RWXD)
Full Control – (Все разрешения) (Все разрешения)
6.2. Модель Харрисона, Руззо и Ульмана
В 1976 году Харрисон, Руззо и Ульман (HRU) доказали, что
в самом общем случае вопрос определения безопасности компьютерной системы неразрешим. Иными словами, не существует алгоритма, позволяющего определить, будет ли компьютерная система
безопасна или небезопасна в общем случае.
Модель HRU используется для анализа системы защиты, реализующей дискреционную политику безопасности, и ее основного
элемента – матрицы доступов. При этом система защиты представляется конечным автоматом, функционирующим согласно определенным правилам перехода.
Приведем формальное описание модели.
Обозначим: О – множество объектов системы; S – множество
субъектов системы (SO); R – множество прав доступа субъектов к
объектам, например права на чтение (read), на запись (write), владения (own); М-матрица доступа, строки которой соответствуют
субъектам, а столбцы – объектам; М [s, о]R – права доступа субъекта s к объекту о.
Отдельный автомат, построенный согласно положениям модели HRU, будем называть системой. Функционирование системы
рассматривается только с точки зрения изменений в матрице доступа. Возможные изменения определяются шестью примитивными операторами:
1. "Внести" право rR в M[s, о] (enter r into (s, о)) – добавле-
ние субъекту s права доступа r к объекту о. При этом в ячейку
M[s,o] матрицы доступов добавляется элемент r.
2. "Удалить" право r R из М [s, о]( delete r from (s, о)) – уда-
ление у субъекта s права доступа r к объекту о. При этом из ячейки
M[s,o] матрицы доступов удаляется элемент r.
3. "Создать" субъекта s'(create subject s') – добавление в си-
стему нового субъекта s'. При этом в матрицу доступов добавляются новые столбец и строка.
90
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]