Модели и методы ролевого и сессионного контроля доступа. 
Вопросы идентификации ролей и сессий

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

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

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

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

Замечание. На взгляд авторов, реализация модели сессионного контроля доступа является единственным эффективным решением задачи защиты от утечек конфиденциальной информации, в том числе от ее хищения легальным пользователем, допущенным к се обработке в И С. Этот вопрос подробно исследован в работе [18].

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

1. Для идентификации роли (сессии) используется учетная запись, т. е. для одной учетной записи создается одна роль или сессия (ЗРОИ). Разграничения прав доступа реализуются для учетных записей (в общем случае, как отмечали, субъект доступа в разграничительной политике целесообразно идентифицировать как «пользователь, процесс»). В этом случае учетной записью идентифицируется не пользователь, а роль (сессия), различные же пользователи, допущенные к работе в одной роли (сессии), должны входить в систему под одной и той же учетной записью. Ограничения — в системе не могут одновременно работать в одной роли (сессии) несколько пользователей, между пользователями, работающими в одной роли, не могут разграничиваться нрава доступа к объектам.

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

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

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

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

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

Построим абстрактную модель ролевого контроля доступа. Будем исходить из того, что множества С = {С_р …, С,} и О = {О_р …, ОД — соответственно линейно упорядоченные множества субъектов (пользователей) и объектов доступа; R — {г, w, d, х} — конечное множество прав доступа (чтение, запись, удаление, исполнение); множество D = {D_v …, DJ — линейно упорядоченное множество ролей в ИС; право включения субъекта доступа в роль будем обозначать, как C,(1)D, запрет этого права — как С;(0)?>_;-.

Матрица контроля доступа (дискреционного) ролей к объектам М_р имеет следующий вид:

Матрица включений пользователей в роли М :

Поскольку рассматриваемую абстрактную модель характеризуют уже две матрицы, в отношении их обеих должны формулироваться соответствующие требования к построению безопасной системы. В любой момент времени система описывается своим текущим состоянием Q_{ = (Д О, М), M[D, О] — ячейка матрицы, содержит набор прав доступа роли, и Q, = (С, Д М), М[С, D] — ячейка матрицы, содержит право включения субъекта доступа в роль.

Для заданной системы состояние Д, ⁼ (Д> О₀" ^о) следует считать безопасным относительно некоторого права R, если не существует применимой к Qoi последовательности действий, в результате выполнения которых ролью Д приобретается право R доступа к объекту О₀, исходно отсутствующее в ячейке матрицы М₀[Д, С₍₎]. Если же право R, отсутствующее в ячейке матрицы М₀[Д, С₀], приобретается ролью Д, то следует говорить, что произошла утечка права R_} а система небезопасна относительно права R. Кроме того, для заданной системы состояние Д₂ = (С₀, Д, М₀) следует считать безопасным относительно права включения субъекта доступа в роль, если не существует применимой к Qo₂ последовательности действий, в результате выполнения которых субъектом доступа С₀ приобретается право включения в роль, исходно отсутствующее в ячейке матрицы М₍₎|С₀, D₍₎|. Если же право включения субъекта доступа в роль, отсутствующее в ячейке матрицы М₀|С₀, Д], приобретается ролью субъектом доступа С₀, то следует говорить, что произошла утечка права включения субъекта доступа в роль, а система небезопасна относительно этого права.

Аналогичным образом строится абстрактная модель сессионного контроля доступа, уже с использованием меток безопасности (мандатов). Будем считать, что множество Н = {Д, …, Н,} — линейно упорядоченное множество сессий в И С, и что чем выше уровень конфиденциальности обрабатываемой в сессии информации, тем меньше ее порядковый номер в линейно упорядоченном множестве Я = {H_v …, Н₇}, и тем меньшее значение метки безопасности М, i = 1, …, / присваивается сессии, т. е. М, < < М₂ < М₃ < … <�М_У. Метка безопасности сессии назначается, исходя из максимального уровня конфиденциальности обрабатываемых в сессии данных.

Матрица контроля доступа (мандатного) сессий к объектам М_с имеет следующий вид:

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

^11ие> М_вклс:

Теперь о принципиальном ограничении реализации данных методов. Методы контроля доступа, предполагающие использование для идентификации роли (сессии) дополнительно создаваемой в системе сущности «роль» («сессия»), могут использоваться исключительно в том случае, когда ОС и приложения работают с этими сущностями, т. е. реализуют соответствующие методы ролевого (сессионного) контроля доступа, так как в противном случае задача реализации контроля доступа к ЗРОИ (рассмотренная выше) становится неразрешимой.

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

Вывод. Методы контроля доступа, предполагающие использование для идентификации роли (сессии) создаваемой в системе сущности «роль» («сессия»), могут быть отнесены к потенциально опасным (не рекомендуемым к реализации), если соответствующая ролевая (сессионная) модель контроля доступа не реализуется собственно ОС и используемыми в ИС приложениями.