Введение

В данной работе рассматривается реализация ядра безопасности в информационных системах, проектирование которых осуществляется с применением объектно-ориентированной парадигмы. Более подробно объектный подход освещен, например, в [3].

В "Оранжевой книге" [1] надежная система определяется как "система, использующая достаточные аппаратные и программные средства, чтобы обеспечить одновременную обработку информации разной степени секретности группой пользователей без нарушения прав доступа". Поскольку в данной работе мы не будем рассматривать особенности аппаратно-технических средств (конкретных вычислительных платформ) и математического обеспечения (операционных систем и СУБД), термин "надежная вычислительная база" будет применен к программному обеспечению информационной системы. Предполагается, что аппаратный уровень, уровень операционной системы и уровень СУБД являются достаточно надежным для реализации на их основе информационной системы с заданными требованиям к безопасности доступа к информации.

Основные понятия

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

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

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

Конфиденциальность определена в ISO 7498-2 как "свойство информации быть недоступной или нераскрываемой для неуполномоченных лиц, сущностей или процессов".

Согласно "Оранжевой книге", политика безопасности должна включать в себя, по крайней мере, следующие элементы:

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

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

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

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

Реализация ядра безопасности

Перед началом описания сделаны некоторые предположения относительно архитектуры информационной системы. Вся информация в ней представлена в виде атрибутов (свойств, полей, членов-данных) объектов определенных в системе классов. Доступ к информации осуществляется через свойства объектов, а изменение информации происходит посредством выполнения методов объектов. Информация об объектах, свойствах и методах хранится в базе данных, которая может являться обычной реляционной СУБД. В этом случае необходимо применение объектно-ориентированного расширения, например, в виде слоя хранимых процедур. Возможна также схема с выделением объектного расширения в виде специализированного сервера объектов. Ниже расширение рассматривается и выделено на схеме, как виртуальная объектно-ориентированная машина.

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

Рассмотрим схему взаимодействия системы с пользовательскими процессами посредством ядра безопасности:

Рис.1. Схема взаимодействия субъектов и объектов системы

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

Рассмотрим обобщенные требования к безопасности для объекта абстрактного класса системы:

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

Очевидно также, что потребность в безопасности необходима для общедоступных (public) и публикуемых (published) свойств и методов. Различия между общедоступными и публикуемыми методами состоит в том, что публикуемый метод также является общедоступным, но может быть инициирован пользователем, когда тот запрашивает у объекта список возможных операций с ним. Таким образом, он является общедоступным методом для внешних по отношению к системе объектов через определенный в системе интерфейс опубликования, на уровне взаимодействия "пользователь-система". Например, класс имеет методы "Рассчитать значение по параметру" (public, используется другими объектами) и "Показать текущие значения параметров" (published, выдается в качестве возможного варианта действия пользователю).

Friend-отношения могут рассматриваться только как заранее оговоренный случай внутреннего взаимодействия объектов системы, например получение значений некоторых членов данных напрямую. Некорректное применение friend-отношений может привести к образованию "дыры" в ядре безопасности, через которую можно будет неконтролируемо извлекать или изменять информацию. По личному мнению автора, применение friend-отношений можно полностью исключить на этапе проектирования.

Состояние объекта в системе определяется вектором его свойств и, соответственно, текущими состояниями каждого из этих свойств, то есть: Obj(Property1, Property 2, ..., Property N). С другой стороны, объект предоставляет субъектам свои методы: Obj(Method1, Method 2, ..., Method M). С точки зрения обеспечения безопасности, нас интересуют только те свойства и методы, которые являются общедоступными и публикуемыми. Способы доступа к самому объекту со стороны субъекта могут быть описаны, как множество значений: [нет, есть]. Способы доступа к свойствам могут быть описаны, как множество значений: [нет, чтение, запись]. Способы доступа к методам могут быть описаны, как множество значений: [нет, выполнение].

Для математического описания подобной схемы доступа достаточно использования трех матриц:

M1: (объекты Х субъекты) со множеством значений [нет, есть];
M2: (свойства Х субъекты) со множеством значений [нет, чтение, запись]
M3: (методы Х субъекты) со множеством значений [нет, выполнение].

Все три матрицы являются динамически изменяющими размерность и разреженными, поэтому возможно их хранение в виде массива кортежей <субъект, объект, значение>, то есть хранение матриц по столбцам для непустых значений.

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

Для этого необходимо определять права доступа субъекта к свойствам и методам класса, так же, как и к его объекту. Данные установки будут также использоваться, как "установки по умолчанию" для созданного объекта в системе. Таким образом, мы будем иметь "шаблон прав доступа" для субъекта по отношению к данному классу объектов. Это позволяет еще более разрядить матрицу схем доступа и хранить в ней только схемы тех объектов, доступ к которым для одного и более субъектов был изменен.

Рис.2. Диаграмма классов реализации безопасного доступа

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

Политика назначения прав и наследование

Существуют две граничные (крайние) политики назначения прав в системе:

Разрешено все, что не запрещено
Запрещено все, что не разрешено

Отличие в реализации той или иной политики ядром безопасности будет состоять в организации пустых значений разреженной матрицы схемы доступа и логической интерпретации этих значений. Так, для политики (1) пустыми (нулевыми) значениями будут "Yes" из определенного выше множества, а интерпретация пустого значения будет наличие прав к объекту, свойству или методу. Наоборот, для политики (2) нулевыми значениями являются "No", а их интерпретация говорит об отсутствии таковых прав доступа.

Наследование прав доступа проявляется только на этапе назначения прав доступа для классов, то есть создания так называемого шаблона прав или схемы "по умолчанию". Наследование прав доступа также зависит от политики назначения. В случае (1), если для пользователя определены права на класс, то автоматически эти права переносятся на все подклассы. В случае (2) этого не происходит и необходимо явно указывать права для каждого класса. Оптимальным может быть решение о смешанной политике назначения прав.

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

Реализация для системы на основе реляционной схемы БД

Рис.3. Модель реализации безопасного доступа (IDEF1X)

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

execute HaveAccess @ObjectID, @SubjectID, @MemberID, @AccessType output

В ядре безопасности системы также определены процедуры:

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

Процедуры используются ядром виртуальной ОО-машины в протоколах обмена данными с клиентским приложением непосредственно перед отправкой данных.

Литература

Department of Defense Trusted Computer System Evaliation Criteria. - DoD 5200.28-STD, 1993.
В.А.Галатенко "Информационная безопасность - основы", журнал СУБД №1/1996, с. 6
Г. Буч. Объектно-ориентированный анализ и проектирование: с примерами приложений на C++, 2-е изд./Пер. с англ. - М.: "Издательство Бином", СПб.: "Невский диалект", 1998. - 560 с., ил.