Защита информации в инфокоммуникационных системах и сетях.-3

111

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

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 Применение мандатных моделей

В завершении обзора мандатных моделей необходимо отметить трудности, которые связаны с их применением на практике. Все мандатные модели, как и модель Белла -

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

111

112

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

содержащий ответы на запросы, подтверждения получения и т.д.

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

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

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

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

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

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

112

113

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

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

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

для UNIX и Administrator для Windows NT), который обладает специальными полномочиями и может использоваться несколькими пользователями.

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

которые никак не связаны с их личностью.

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

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

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

в реальной системе обработки информации могут работать системный администратор,

менеджер баз данных и простые пользователи.

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

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

113

114

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

Ролевая модель описывает систему в виде следующих множеств [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)

114

116

роль, то ему автоматически назначаются и все подчиненные ей по иерархии роли. Иерархия ролей допускает множественное наследование.

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

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

Иерархия ролей в точности отражает эту ситуацию.

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

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

1. Взаимоисключающие роли. Множество ролей разбивается на подмножества,

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

Взаимоисключающие роли реализуют, т. н. статическое разделение обязанностей,

когда конфликт несовместимости полномочий разрешается на стадии назначения ролей.

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

осуществляющего контроль за их выполнением.

2. Ограничения на одновременное использование ролей в рамках одной сессии. В

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

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

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

116

117

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

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

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

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

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

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

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

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

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

когда некоторый пользователь, осуществляющий руководство работой других пользователей,

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

117

118

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

Следовательно, свойства системы, построенной в соответствии с ролевой моделью,

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

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

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

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

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

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

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

118

119

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

Модель описывает процесс эволюции системы защиты в течении времени.

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

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

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

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

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

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

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

защищенной системе все ребра представляются в виде <ti mk> и <mk oj>. Любое ребро в

119

120

форме <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 ий объект защищен.

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

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

Потоковые модели определяют ограничения на отношение ввода/вывода системы,

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

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

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

120