Информационная безопасность / Golikov - Osnovi informatsiooonoy bezopasnosti 2007

80

дополнительные функции: FL:S L такая, что FL(s) есть наибольшая нижняя граница множества {F(s) / s S} и FH:S L, такая, что FH(s) есть наименьшая верхняя граница множества{F(s) / s S}.

Критерии безопасности состояния для такой системы формулируются следующим образом:

1. Состояние системы является безопасным но чтению тогда и только тогда, когда для каждого индивидуального или группового субъекта, имеющего в этом состоянии доступ чтения к объекту, наибольшая нижняя граница множества уровней безопасности этого субъекта доминирует над уровнем безопасности этого объекта: s S, o O, read M[s,o] FL(s)>F(o).

2. Состояние системы является безопасным по записи тогда и только тогда, когда для каждого индивидуального или группового субъекта, имеющего в этом состоянии доступ записи к объекту, уровень безопасности этого объекта доминирует над наименьшей верхней границей множества уровней безопасности этого субъекта: s S, o O, write

M[s,o]->F(o)> FH(s).

Тогда теорема Белла-ЛаПадулы для совместного доступа формулируется следующим образом [3]:

Система (vo,R, T) безопасна тогда и только тогда, когда: а) начальное состояние V0 безопасно и

б) функция перехода Т такоdа, чго для любого состояния v, достижимого из v0 путем применения конечной последовательности запросов из R, таких, что T(v,r) = v*, v=((F,FH,FL),M) и v*=((F*,F*H,F*L)*,M*) для каждого s S, o O выполняются следующие условия:

1.если read M*[s,o] и read M[s,o], то FL*(s)> F*(o);

2.если read M[s,o] и FL*(s)<F*(o), то read M* [s,o];

3.если write M*[s,o] и write M[s,o], то F*(o)> FH*(s);

4.если write M[s,o] и F*(o)<FH*(s), то write M* [s,o].

4.2.13 Применение мандатных моделей

В завершении обзора мандатных моделей необходимо отметить трудности, которые связаны с их применением на практике. Все мандатные модели, как и модель Белла - ЛаПалулы, используют только два права доступа – чтение и запись. Па практике информационные системы поддерживают значительно более широкий спектр операций над информацией, например, создание, удаление, передачи и т. д. Следовательно, для того чтобы применить мандатную модель к реальной системе, необходимо установить подходящее соответствие между чтением и записью и операциями, реализованными в конкретной системе. Самым простым примером непрактичности мандатной модели является невозможность ее применения для сетевых взаимодействий — нельзя построить распределенную систему, в которой информация передавалась бы только в одном направлении, потому что всегда будет существовать обратный поток информации, содержащий ответы на запросы, подтверждения получения и т.д.

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

81

выявление тех способов, с помощью которых информация может передаваться в обход правил мандатной модели.

Чем больше потоков информации мы поставим под контроль мандатной модели, тем менее гибкой будет наша система, но и тем меньше потоков информации придется исследовать в процессе анализа скрытых каналов.

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

4.2.14. Ролевая политика безопасности

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

Вролевой модели классическое понятие субъект замещается понятиями пользователь

ироль. Пользователь -— это человек, работающий с системой и выполняющим определенные служебные обязанности. Роль — это активно действующая в системе абстрактная сущность, с которой связан ограниченный, логически связанный набор полномочий, необходимых для осуществления, определенной деятельности. Самым распространенным примером роли является присутствующий почти в каждой системе административный бюджет (например root для UNIX и Administrator для Windows NT), который обладает специальными полномочиями

иможет использоваться несколькими пользователями.

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

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

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

82

управление сервером БД, а права простых пользователей ограничиваются минимумом, необходимым для запуска прикладных программ. Кроме того, количество ролей в системе может не соответствовать количеству реальных пользователей — один пользователь, если на нем лежат различные обязанности, требующие различных полномочий, может выполнять (одновременно или последовательно) несколько ролей, а несколько пользователей могут пользоваться одной и тон же ролью, если они выполняют оди наковую работу .

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

Ролевая модель описывает систему в виде следующих множеств [3]:

U - множество пользователей;

R - множество ролей;

Р - множество полномочий на доступ к объектам, представленное, например, и виде матрицы прав доступа;

S - множество сеансов работ пользователей с системой.

Для перечисленных множеств определяются следующие отношения (риc. 4.6.):

РА PxR - отображает множество полномочии на множество ролей, устанавливая для каждой роли набор присвоенных ей полномочий;

UA UxR - отображает множество пользователей на множество ролей, определяя для каждого пользователя набор доступных ему ролей.

Правила управления доступом ролевой политики безопасности определяются следующими функциями:

user: S U - для каждого сеанса S эта функция определяет пользователя, который осуществляет этот сеанс работы с системой: user(s) = u

roles : S P(R) - lля каждого сеанса S эта функция определяет набор ролей из множества R которые могут быть одновременно доступны пользователю в этом сеансе: roles(s)={ri | (user(s), ri) UA};

permissions : S P - для каждого сеанса S эта функция задает набор доступных в нем полномочии, который определяется как совокупность полномочий всех ролей, задействованных в этом сеансе: permissions(s) = Ur roles(s){Pi, (Pi, r) PA)

83

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

В качестве критерия безопасности ролевой модели используется следующее правило:

система считается безопасной, если любой пользователь системы, работающий в сеансе S, может осуществлять действия, требующие полномочия р только в том случае, если р permissions(s).

Из формулировки критерия безопасности ролевой модели следует, что управление доступом осуществляется главным образом не с помощью назначения полномочий ролям, а путем задания отношения UA, назначающего роли пользователям, и функции roles, определяющей доступный в сеансе набор ролей. Поэтому многочисленные интерпретации ролевой модели различаются видом функции user, roles и permission, а также ограничениями, накладываемыми на отношения РА и UA. В качестве примеров рассмотрим ролевую политику управления доступом с иерархической организацией ролей, а также несколько наиболее часто встречающихся типовых ограничений на отношения РА и UA и

функции user и roles.

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

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

84

Другие реализации ролевой политики безопасности также связаны с введением различных ограничений на отношения PA, UA, и функции user, roles и permissions. Главным для этих ограничений является то, что все они отражают специфику распределения полномочий и сфер ответственности между участниками различных процессов обработки информации. Рассмотрим несколько примеров, демонстрирующих богатые возможности применения ролевой модели управления доступом:

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

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

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

Поскольку в процессе сеанса пользователь может переключаться между различными ролями, он должен при этом избегать конфликтов несовместимости между ними, эта политика получила название динамического разделения обязанностей. Такая политика является более гибкой по сравнению со статическим разделением обязанностей, поскольку позволяет реализовать более сложные схемы контроля доступа. В частности она позволяет запретить пользователю, обладающему значительным набором ролей и полномочий, пользоваться ими всеми одновременно. В определенных ситуациях это позволяет защититься от атаки «троянского коня» — например, пользователю можно запретить одновременно осуществлять доступ к ценной информации и запускать «недоверенные» программы, внесенные в систему другими пользователями. Правильно подобранные ограничения на одновременное использование ролей позволяют реализовать контроль за информационными потоками, что вообще - то характерно для мандатных моделей безопасности.

3.Количественные ограничения при назначении ролей и полномочий. Эта модель предназначена для тех случаев, когда роль может быть назначена только ограниченному числу пользователей, и/или предоставление некоторых полномочии допускается только для ограниченного числа ролей.

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

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

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

85

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

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

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

4.2.15. Вероятностные модели

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

Задача модели – минимизация преодоления системы защиты.

Игровая модель

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

86

Модель системы безопасности с полным перекрытием

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

Рис. 4.7. Множество отношений объект-угроза

Множество отношений объект-угроза образуют двухдольный граф, в котором ребро <ti oj> существует тогда и только тогда, когда ti ( ti T) является средством получения доступа к объекту oi ( oi O). Связь между объектами и угрозами типа "один ко многим", т.е. одна угроза может распространяться на любое число объектов и объект может быть уязвим со стороны более чем одной угрозы. Цель защиты состоит в том, чтобы перекрыть каждое ребро графа и воздвигнуть барьер для доступа по этому пути.

Завершает модель третий набор, включающий средства безопасности М, которые используются для защиты информации в вычислительной системе. Идеально каждое mk ( mk M) должно устранять некоторое ребро <ti oj> из графа на рисунке. Набор Μ средств обеспечения безопасности преобразует двухдольный граф в трехдольный граф. В защищенной системе все ребра представляются в виде <ti mk> и <mk oj>. Любое ребро в форме <ti oj> определяет незащищенный объект. Одно и то же средство обеспечения безопасности может перекрывать более одной угрозы и (или) защищать более одного объекта. Отсутствие ребра <ti oj> не гарантирует полного обеспечения безопасности (хотя наличие такого ребра дает потенциальную возможность несанкционированного доступа за исключением случая, когда вероятность появления ti равна нулю).

Понятие системы с полным перекрытием

Система с полным перекрытием – система в которой имеются средства защиты на каждый путь проникновения [1].

Пусть:

Т – набор угроз; О – набор защищаемых объектов;

M – набор средств обеспечения безопасности;

V – набор уязвимых мест – отображение Т О на набор упорядоченных пар V = {ti ,O}i , представляющих собой пути проникновения в систему;

В – набор барьеров – отображение Т О М или V M на набор упорядоченных троек {ti oj mk}, представляющих собой точки, в которых требуется осуществить защиту.

Если {ti oj} V предусматривает {ti oj mk} B , то j ий объект защищен.

Основное преимущество данного типа моделей состоит в возможности численного получения оценки степени надежности системы защиты информации. Данный метод не

87

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

4.2.16. Информационные модели

Потоковые модели определяют ограничения на отношение ввода/вывода системы, которые достаточны для реализации системы. Данные модели являются результатом применения шенноновской теории информации к проблеме безопасности систем. К данным моделям относятся модели невмешательства и невыводимости.

Модель невмешательства

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

Рассмотрим систему, вывод которой пользователю u определен функцией out(u, hist.read(u)), где hist.read(u) – история ввода системы (traces), чей последний ввод был read(u) - команда чтения, исполненная пользователем u. Безопасность определена в терминах очищения (purge) историй ввода, где purge удаляет команды, исполненные пользователем, чей уровень безопасности не доминирует над уровнем безопасности u.

Для определенных систем, модель невмешательства особенно хороша в том, что если последовательность входа X не смешивается с последовательностью вывода У, и X независима от ввода других пользователей, то I(X, У)=0, где I(X, У) — взаимная для X и У информация.

Модель невыводимости

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

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

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

4.3 Модели контроля целостности

4.3.1. Модель Биба

Мандатная модель целостности Биба

Данную модель часто называют инверсией модели Бела – Лападула и следовательно основные правила этой модели просто переворачивают правила модели Бела – Лападула: NRU «нет чтения снизу(NRD)» и NRD «нет записи наверх(NWU)».

88

Правило NRD определяется как запрет субъектами на чтение информации из объекта с более низким уровнем целостности. Правило NWUопределяется как запрет субъектам на запись информации в объект с более высоким уровнем целостности.

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

С другой стороны, модель представляет собой очевидное противоречие с правилами NRU и NWD. Это значит, что если необходимо построить систему, которая предотвращает угрозы, как секретности, так и целостности, то одновременное использование правил моделей БЛМ и Биба может привести к ситуации, в которой уровни безопасности и целостности будут использоваться противоположными способами.

Модель понижения уровня субъекта

Вторая модель Биба заключается в небольшом ослаблении правила чтения снизу. Здесь субъекту разрешается осуществлять чтение снизу, но в результате такого чтения

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

Модель понижения уровня объекта

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

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

4.3.2. Модель Кларка–Вилсона

Эта модель была создана в 1987г Кларком и Вилсоном. Ее созданию способствовал анализ методов управления коммерческими организациями целостностью своих бумажных ресурсов в неавтоматизированном офисе.

Введем некоторые обозначения: D – конечное множество данных;

CDI – ограниченные элементы данных; UDI – неограниченные элементы данных,

Причем: D = CDI UDI, CDI UDI= .

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

89

данных). ПП могут быть представлены в виде функции, ставящих в соответствие субъект и элемент данных с новым элементом данных следующим образом: ПП: субъекты xD D.

ПП – действия, которые выполняют субъекты (способные изменить определенные данные) над данными.

У данной модели, как и у других моделей, существуют свои правила. Рассмотрим их. Правило1: в системе должны иметься процедуры утверждения целостности ( IVP

(Пример-проверка контрольной суммы) – утверждают, что данный CDI имеет надлежащий уровень целостности, утверждающие любой CDI.

Правило2: применение любого ПП к любому CDI должно сохранять целостность CDI. Правило3: только ПП может вносить изменения в CDI.

Правило4: субъекты могут инициировать только определенные ПП над определенными CDI.

Правило5: соответствующая политика в отношении разделения обязанностей субъектов. Т.е. компьютерная система определяет такую политику, чтобы не позволить субъектам изменять CDI без соответствующего вовлечения других субъектов.

Правило 6: некоторые специальные ТР могут превращать UDI в CDI.

Это правило позволяет определенным ПП получать на вход UDI и после соответствующего повышения целостности выдавать на выходе CDI.

Правило 7: каждое применение CDI должно регистрироваться в специальном CDI, в который может производиться только добавление информации, достаточной для восстановления картины о процессе работы этого CDI. Т.е. применение специального регистрационного журнала.

Правило 8: система должна распознавать субъекты, пытающая инициализировать ПП. Это правило определяет механизмы предотвращения атак, при которых один субъект

пытается выдать себя за другого.

Правило 9: система должна разрешать производить изменения в списках авторизации только специальным субъектам.

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

Преимущество модели в том, что она основана на проверенных временем бизнес – методов обращении с бумажными ресурсами. Недостатком является трудность реализации VIP и методов предотвращения CDI от искажения целостности.

Основным преимуществом данной модели является то, что она основана на проверенных временем бизнес методах обращения с бумажными ресурсами. Поэтому ее не следует рассматривать как академическое исследование, а скорее как комплекс существующих методов. Модель Кларка–Вилсона также предоставляет исследователям методы работы с целостностью, отличные от традиционных уровне - ориентированных подходов, таких как модели Белла–Лападула и Биба.

Основным недостатком модели является то, что IVP и методы предотвращения CDI от искажения целостности нелегко реализовать в реальных компьютерных системах.

4.4. Механизм защиты от угрозы отказа в обслуживании

4.4.1. Мандатная модель

Мандатная модель включает в себя многие характеристики моделей Белла–Лападула и

Биба.

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