9.1. Иерархический метод построения защиты .
В данном п. рассматривается еще один пример иерархической декомпозиции сложных систем. Если в п. 2.2 мы рассматривали примеры, не связанные непосредственно с задачей защиты, то сейчас основное внимание будет посвящено иерархическому построению ТСВ в электронных системах обработки данных. Как и раньше, основная задача ТСВ - поддержка монитора обращений. Однако, в отличие от теории предыдущего параграфа, где мониторы обращения были независимыми, сейчас мы покажем, что одни ТСВ-подмножества могут использовать ресурсы в других ТСВ-подмножествах. А именно, рассмотрим следующую модель.
Определение. ТСВ-подмножество М есть совокупность программно-аппаратных ресурсов системы, которые управляют доступами множества S субъектов к множеству О объектов на основе четко определенной политики Р и удовлетворяет свойствам:
1) М определяет и контролирует каждый доступ к объектам из О со стороны субъектов из S;
2) М гарантировано защищено;
3)М достаточно просто устроено, чтобы существовала возможность проанализировать его системой тестов, полнота которых доказана.
Зависимость ТСВ-подмножеств состоит в том, что М использует ресурсы точно определенного множества более примитивных ТСВ-подмножеств (то есть предполагается заданным некоторый частичный порядок на ТСВ-подмножествах), для того, чтобы создать объекты из О, создать и поддерживать структуры данных и поддерживать политику Р.
Если более примитивных ТСВ-подмножеств нет, то такое ТСВ-подмножество опирается в решении тех же задач на аппаратную часть.
Отметим, что кроме монитора обращений необходимо существование механизма поддержки этого монитора. Рассмотрим условия, при которых из ТСВ-подмножеств удается собрать ТСВ системы (то есть доказать, что выполняются все требования к ТСВ).
Пусть даны ТСВ-подмножества M(i), которые управляют доступом субъектов S(i) к объектам 0(i) в соответствии с политикой безопасности P(i). Предположим, что нет объектов в системе, которые контролируются более, чем одним ТСВ-подмножеством. Здесь принимается та же точка зрения, как в главе VI, состоящая в том, что ТСВ-подмножества могут экспортировать объекты, подлежащие управлению другим ТСВ-подмножеством. Однако принятый и переданный объекты - это разные объекты, контролируемые разными ТСВ-подмножествами. При этом политика безопасности P(i) ТСВ-подмножества M(i) может отличаться от политики безопасности P(j) ТСВ-подмножества M(j). Однако все вместе должны составлять единую политику Р системы, причем каждое правило из Р должно поддерживаться определенной системой ТСВ-подмножеств.
Необходимо также предполагать, что каждый доверенный субъект, то есть субъект, который может нарушать правила P(i) является частью ТСВ-подмножества M(i).
Рассмотрим ограничения на зависимости ТСВ-подмножеств.
Определение. ТСВ-подмножество А прямо зависит (в своей правильности) от ТСВ-подмножества В тогда и только тогда, когда доводы о подтверждении правильности А (верификация установки А обозначается vA) частично или полностью основаны на предположении, что В установлена верно в соответствии соспецификацией В (обозначается sB).
Определение. ТСВ-подмножество А менее примитивно, чем ТСВ-подмножество В, если:
а) А прямо зависит от В;
б) существует цепочка ТСВ-подмножеств от А к В такая, что каждый элемент цепи прямо зависит от предыдущего элемента цепи.
Рассмотрим примеры, поясняющие понятие зависимости, взятые из "Розовой книги".
Пример 1. Пусть ТСВ-подмножество В предоставляет услугу в виде "файла", которым В управляет в соответствии с политикой Р(В), а ТСВ-подмножествоА использует В-файл для хранения информации. Если vA использует факт, что различные В-файлы действительно различаются и доступ к ним определяется политикой Р(В), то vA полагается на факт, что sB и В соответствуют друг другу. Тогда А прямо зависит от В.
Пример 2. Пусть А и В взаимно не доверяющие друг другу системы бронирования авиабилетов, расположенные отдельно и принадлежащие различным организациям. Предположим sA и sB дают возможность получить заказ на бронирование по сети от других систем, используя взаимно согласованный протокол. Пусть этот протокол полностью определен и соответствует sA и sB. Пусть также vA и vB с заданной степенью уверенности подтверждают, что А и В соответствуют своим спецификациям sA и sB. А не зависит в правильности своей установки от правильности установки В, так как sA - полная, то есть какая бы последовательность бит не пришла от В, sA определяет, что А должна делать, а vA демонстрирует, что именно это и делается. Аналогично, В не зависит от правильности А. Поэтому А и В не зависят одна отдругой.
Пример 3. Пусть А является сервером электронной почты, а В управляет запросами в базу данных. Спецификация sA может совсем не упоминать систему управления базой данных, она просто определяет интерфейс почтовой системы. Однако в vA мы находим, что программа обеспечения А использует таблицы, предоставляемые В, для хранения сообщений А и В на различных, связанных машинах. Ни sB, ни vB не упоминают о почтовой системе. Как и в предыдущем примере, sB полностью определяет поведение В для всех получаемых последовательностей бит. Здесь А прямо зависит от В, но В не зависит от А. Отметим, что информационные потоки в обоих направлениях являются законными и никоим образом не компрометируют целостность В. Зависимость находится в другой плоскости от потока данных.
Этот пример замечателен тем, что анализ структуры элементов не позволяет выявить существование зависимости, при этом архитектура системы внешне совпадает с приведенной в примере 2 архитектурой взаимно независимых систем. Кроме того, этот пример показывает, что описания интерфейса не достаточно для выявления зависимостей.
Пример 4. Пусть А и В взаимно зависимые системы. А зависит от В и В зависит от А. Это значит, что правильность установки vA доказывается из предположения, что В установлена правильно в соответствии с sB. Также правильность установки vB доказывается из предположения, что А установлена правильно в соответствии с sA. Пусть vA и vB подтверждают правильность установки А и В. Однако отсюда не следует, что А и В функционируют правильно.
В самом деле, если А и В функционируют правильно относительно sA и sB, то vA и vB поддерживают правильность установки. Если А установлено неправильно по отношению к sA и В установлено неправильно по отношению к sB, то никто не мешает возникновению ситуации, когда vA подтверждает правильность исходя из того, что В не соответствует sB. Аналогично, vB подтверждает правильность установки sB, хотя А не соответствует sA. Тогда можно доказать, что vA и vB подтверждают правильность А и В, хотя А и В установлены неверно.
Для того, чтобы понять возникающую здесь коллизию, рассмотрим две системы бронирования билетов на самолеты А и В, как в примере 2. Предположим, что А содержит информацию об исходных пунктах и времени вылета всех полетов в США, а В - в Европе. Пусть sA включает утверждение, что А обеспечивает пассажирам услугу в подборе вылета по транзиту, минимизирующем время ожидания следующего полета. Пусть sB предлагает аналогичные услуги. Из утверждения А соответствует sA и В соответствует sB можно вывести истинность утверждения, что А соответствует спецификации sA в предоставлении услуги подбора транзитного рейса в Европе и Америке. Аналогичное утверждение можно вывести для В. Однако, если А хранит информацию в местном времени, а В - во времени по Гринвичу, то транзитный маршрут, составленный А и В на основе информации, полученной друг от друга, будет неправильным из-за различия во времени. То есть каждая система функционирует правильно, но результат неверен. Это происходит из-за того, что А и В зависимы.
Гарантии защищенности ТСВ-подмножеств имеют большое значение в проблеме построения единой ТСВ системы из ТСВ-подмножеств. В случае зависимых ТСВ-подмножеств менее примитивное ТСВ-подмножество может использовать объекты и субъекты, предоставленные более примитивным ТСВ-подмножеством. Потому первая проблема состоит в доказательстве того факта, что невозможны никакие изменения данных, критических для политики безопасности, или кодов ТСВ-подмножества. То есть никакая внешняя по отношению к ТСВ-подмножеству система (кроме, может быть, более примитивных ТСВ-подмножеств) не может инициировать произвольное изменение кодов ТСВ-подмножества или его структур данных. Вторая проблема состоит в доказательстве того, что данные, хранящиеся в ТСВ-подмножестве и критичные для политики безопасности, не могут изменяться иначе, чем в соответствии с логикой ТСВ-подмножества. Разумеется, эти доказательства возможны при условии правильности той информации, которая вносится в ТСВ-подмножество более примитивным ТСВ-подмножеством.
Ясно, что в доказательстве возможности построения единой ТСВ системы из ТСВ-подмножеств присутствуют условия не только на локальные свойства ТСВ-подмножеств, но также интегральные требования.
Суммируем перечень всех условий, которые необходимо выполнить, чтобы из семейства ТСВ-подмножеств можно было бы синтезировать ТСВ системы. Если, кроме нижеприведенных требований, выполняются требования какого-либо класса в стандарте "Оранжевая книга", то построенная таким образом система может быть аттестована по соответствующему классу.
Условия:
1. ТСВ-подмножества четко определены.
2. Политика безопасности системы распределена по ТСВ-подмножествам.
3. Каждое ТСВ-подмножество M(i) включает доверенные процессы по отношению к своей политике безопасности P(i).
4. Архитектура ТСВ-подмножеств четко определена .
5. Все ТСВ-подмножества занимают различные домены.
6.Во всех случаях примитивные ТСВ-подмножества поддерживают правильное функционирование монитора обращений в менее примитивном ТСВ-подмножестве.
- 2. Системообразующие основы моделирования. Модель действия.
- 3. Системообразующие основы моделирования. Модель объекта.
- 4. Системообразующие основы моделирования. Эффективность применения эвм.
- 5.Анализ и синтез при создании эвм. Концепция синтеза. Структура множества q.
- Концепция синтеза
- Модель Системы ↔ Условие замыкания ↔ Модель Действия
- 6. Принцип системности. Задача а.
- 7. Принцип системности. Задача б.
- 8. Принцип системности. Задача в.
- 9. Принцип системности. Задача г.
- 10.Теория подобия при синтезе модели эвм
- 11.Синтез модели и способов её применения, осложненный конфликтной ситуацией.
- 12.Структурная схема взаимодействия трёх базовых подсистем при разрешении конфликта.
- 13. Алгоритм логической последовательности выполнения команд пс в условиях разрушения множества q
- 14. Компенсация разрушения программной системы изменением аппаратной части
- 15. Компенсация разрушения аппаратной части изменением программной системы
- 16. Язык, объекты, субъекты. Основные понятия.
- 17. Язык, объекты, субъекты. Аксиома
- 18. Иерархические модели и модель взаимодействия открытых систем .
- Модель osi/iso.
- 19. Модель osi/iso.Прикладной уровень (пУ).
- 20. Модель osi/iso.Уровень представления (уп).
- 21. Модель osi/iso.Уровень сеанса (ус).
- 22. Модель osi/iso.Транспортный уровень (ту).
- 23. Модель osi/iso.Сетевой уровень (су).
- 24. Модель osi/iso.Канальный уровень.
- 25. Модель osi/iso.Физический уровень.
- 26. Информационный поток. Основные понятия.
- 27. Информационные потоки в вычислительных системах.
- 28. Ценность информации. Аддитивная модель.
- 29. Ценность информации. Анализ риска.
- 30. Ценность информации. Порядковая шкала ценностей.
- 31. Ценность информации. Модель решетки ценностей.
- 32. Ценность информации. Решетка подмножеств х.
- 33. Ценность информации. Mls решетка
- 64. Угрозы информации
- 65. Угрозы секретности. Утрата контроля над системой защиты; каналы утечки информации.
- 66. Угрозы целостности
- 67. Политика безопасности. Определение политики безопасности
- 68. Дискреционная политика.
- 69. Политика mls.
- 70. Классификация систем защиты. Доказательный подход к системам защиты .
- 71. Классификация систем защиты. Системы гарантированной защиты.
- 72. Классификация систем защиты. Пример гарантированно защищенной системы обработки информации. Записывает во внешнюю память все объекты, которые он хочет сохранить для дальнейших сеансов;
- 74. Два типа оценки: без учета среды, в которой работает техника, в конкретной среде (эта процедура называется аттестованием).
- 75. Политика.Требование 1. Требование 2 - маркировка
- 76. Подотчетность. Требование 3 – идентификация. Требование 4 - подотчетность
- 77. Гарантии. Требование 5 – гарантии. Требование 6 - постоянная защита
- 78. Итоговая информация по классам критериев оценки; идентификация и аутентификация гарантии на правильную работу системы
- Политика обеспечения безопасности.
- Идентификация и аутентификация.
- 79. Архитектура системы; целостность системы гарантии на жизненный цикл тестирование функции безопасности. Документация. Выбор класса защиты.
- 4.4. Выбор класса защиты.
- 80. Математические методы анализа политики безопасности. Модель "take-grant"
- 81. Математические методы анализа политики безопасности. Модель Белла - Лападула (б-л).
- 82. Математические методы анализа политики безопасности. Модель Low-water-mark (Lwm).
- 83. Математические методы анализа политики безопасности. Модели j.Goguen, j.Meseguer (g-m).
- 84. Математические методы анализа политики безопасности.Модель выявления нарушения безопасности.
- 85. Синтез и декомпозиция защиты в распределенных системах.
- 86. Анализ компонент распределенной системы.
- 87. Проблема построения гарантированно защищенных баз данных. Иерархический метод построения защиты .
- 9.1. Иерархический метод построения защиты .
- 88. Математические методы анализа политики безопасности. Гарантированно защищенные базы данных.