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

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

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

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

Перед дальнейшим описанием сделаны некоторые предположения относительно архитектуры информационной системы;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не нашли, что искали? Воспользуйтесь поиском: