Главная страница
Навигация по странице:

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

  • Модели ЗИ мондатная модель. Модели защиты информации Модели защиты информации. Основные модели защиты информации


    Скачать 78.33 Kb.
    НазваниеМодели защиты информации Модели защиты информации. Основные модели защиты информации
    Дата06.01.2019
    Размер78.33 Kb.
    Формат файлаdocx
    Имя файлаМодели ЗИ мондатная модель.docx.docx
    ТипДокументы
    #53971

    Модели защиты информации

    Модели защиты информации.

    1.1.      Основные модели защиты информации.

    Существует множество моделей защиты информации. Но все они являются модификациями трёх основных: дискреционной, мандатной и ролевой.

     

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

     

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

     

    1.       Субъект имеет право читать только те документы, уровень безопасности которых ниже или равен уровню субъекта.

     

    2.       Субъект имеет право заносить информацию только в документы, уровень которых выше или равен уровню субъекта.

     

    Ролевая модель представляет собой существенно усовершенствованную дискреционную модель, однако её нельзя отнести ни к дискреционным, ни к мандатным моделям, потому что управление доступом в ней осуществляется как на основе матрицы прав доступа для ролей, так и с помощью правил, регламентирующих назначение ролей пользователям и их активацию во время сеансов. В ролевой модели классическое понятие субъект замещается понятиями пользователь и роль (см. рисунок 1.).

     



     

    Рисунок 1  Ролевая модель управления доступом

     

     

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

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

    • изолированность. Монитор должен быть защищен от отслеживания своей работы;

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

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

     

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

     

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

    • Вся информация в ней представлена в виде атрибутов (свойств, полей, членов-данных) объектов определенных в системе классов.

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

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

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

     

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

     

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

     



     

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

     

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

     

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

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

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

    • разделение доступа к методам данного объекта со стороны субъекта;

    • регистрация изменений состояния данного объекта.

     

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

     

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

     

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

     

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

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

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

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

     

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

     

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

     

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

     

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