- 94 -

порождения субъектов с контролем неизменности объектов-источников, исходя из утверждений части 1 (о сохранении ИПС при дополнении множества субъектов попарно корректными), получим, что при t>t0 ИПС сохраняется.

Утверждение доказано.

Смысл данного утверждения состоит в описании процедуры мягкого администрирования, которая сохраняет ИПС при дополнении множества объектов-источников. С другой стороны, описанные в списке LIST объекты обеспечивают исполнение пользовательских свойства программного пакета P. Далее, процедура исключения объектов-источников из ОУ МБС, как было доказано выше, не приводит к нарушению изолированности программной среды.

Итак, метод мягкого администрирования состоит в фиксации на этапе опытной эксплуатации всех или избранных аргументов операций Create (исходный материал для составления множества E) и Stream (для составления ПРД). Ценность метода состоит в том, что администратор безопасности выполняет только операцию редуцирования (сокращения) списков и сравнение функций целостности объектов с эталонными. Возможность применения мягкого администрирования целесообразно предусмотреть еще на этапе проектирования. Применение метода мягкого администрирования позволяет говорить о процессе автоматизации составления ПРД, что является новым результатом.

3.6. Системы управления безопасностью при распределенном объекте управления

Рассмотрим различные представления объекта управления (для простоты будем рассматривать только ОУ МБС). Рассмотрим ОУ как единый объект или как распределенный объект в КС. Рассмотрим пример. Пусть с каждым объектом-источником Oj ассоциирован некоторый объект Ouj (с точки зрения МБС, т.е. при выполнении Create(Si,Oj) МБС обращается к Ouj). Данный объект содержит информацию о множестве разрешенных для порождения субъектов объектов-источников Ei для пользователя i. Предположим, что Ouj в свою очередь состоит из последовательности подобъектов (неразделяемых) Oumj. Каждый из этих подобъектов описывает информацию о пользователе i, который может инициировать порождение субъекта из данного объекта (IDi) и функцию контроля целостности hij (вычисленную на основе индивидуальной информации пользователя Ri, hij=H(Ki,Oj)). Данная информация является минимально достаточной для порождения ИПС.

В самом деле, для работы МБС необходимо определить для пользователя i включенность некоторого субъекта во множество Ei и проверить неизменность объекта-источника. Первое определяется по IDi, второе - по hij.

Рассмотрим параметр Pri - вероятность запуска случайно равновероятно выбранного объекта Oj*, не совпадающего с Oj в ИПС с КЦ для пользователя i. Причем, зададимся еще двумя априорно известными вероятностями: Pi - вероятность принять пользователя m, не равного i, за пользователя i (по IDi) и

- 95 -

Ph - вероятность совпадения хеш-значений для двух случайно равновероятно заданных объектов-источников. Поскольку события “ложная аутентификация пользователя i” (вероятность Pi) и “совпадение хеш-значений объектов” (вероятность Ph) независимы, то вероятность Pri вычисляется как произведение вероятностей соответствующих событий: Pri = Pi*Ph.

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

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

Рассмотрим преимущества распределенного ОУ с точки зрения технологии управления.

При использовании распределенного ОУ минимизируются затраты памяти для реализации МБС. Наконец, при различном отображении имен и путей объектов (mapping) положение ОУ не меняется (поскольку он находится по тому же пути). Распределенный ОУ соответствует конфигурациям 14 и 15, поскольку для удаленных объектов и подобъекты будут удаленными. Тем самым достигается свойство топологической однородности.

Обратимся теперь к понятию распределенного управления.

Рассмотрим процедуру управления в случае, когда ОУ является объектом произвольной локализации (локальным, удаленным или распределенным) и выделяются два субъекта управления - локальный субъект управления (ЛСУ) и удаленный субъект управления (УСУ). В качестве задачи будем рассматривать задачу разработки такого метода управления (для простоты будем рассматривать систему управления МБС), при котором:

-администратор управляет защитой со своего рабочего места, которое относительно пользователя является внешним сегментом КС,

-администратор не имеет физического доступа к ЛС КС.

Исходные положения следующие:

-в рамках ЛС КС действует ИПС с контролем целостности объектовисточников,

-ЛСУ входит для каждого пользователя в состав разрешенных субъектов. Необходимо заметить, что во время сеанса работы пользователя в рамках

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

Выше упоминалась задача обеспечения доступа администратора к ресурсам ЛС КС. В данном случае доступ осуществляется через ЛСУ и технически легко реализуем.

- 96 -

Сформулируем алгоритм управления.

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

объектов источников создался объект LISTi, который содержит полные имена локальных (и удаленных) объектов-источников и, при необходимости их хешзначения (см. описанный выше алгоритм мягкого администрирования) для i-го пользователя. Тогда инициируется Stream(ЛСУ, LISTi)->LISTi*. Объекты LISTi

иLISTi* тождественны, но имеют различную локализацию (первый принадлежит ЛС КС, второй - внешнему сегменту, доступному администратору). Следовательно, после выполнения п.1 администратору доступна информация о локальных объектах.

2.Проверка целостности объектов-источников ЛС КС путем вычисления

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

3.После выполнения процедуры п.2 образуется объект SOURCEi, содержащий имена объектов-источников для i-го пользователя. Данный объект должен обладать следующим свойством - быть доступным на запись только для УСУ.

4.Начало сеанса работы пользователя. Активизация ЛСУ, чтение объекта

SOURCEi, коррекция локальных и удаленных ОУ МБС.

В случае пользователя-злоумышленника угроза корректному управлению исходит от ЛСУ, который имеет доступ на запись к ОУ МБС. Естественным требованием является отсутствие возможностей внешнего управления. С другой стороны, либо в ассоциированном объекте ЛСУ, либо во внешнем

объекте должна содержаться информация локализации объекта SOURCEi (путь). В случае локализации внутри объекта-источника ЛСУ путь к объекту

SOURCEi защищен от изменений процедурой контроля неизменности объектаисточника ЛСУ. В случае локализации пути во внешнем объекте необходима коррекция ОУ МБО так, чтобы исключить возможность изменения данного объекта.

Докажем корректность управления в строгом смысле при условии ИПС в рамках ЛС КС и неизменности пути к объекту SOURCEi.

Утверждение 7 (условия корректности управления при мягком администрировании).

Пусть в рамках ЛС КС действует ИПС с контролем неизменности объектов-источников, в которую включен также ЛСУ, последовательность