Реализация контроля доступа с использованием виртуальной сущности «сессия»

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

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

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

Рисунок 17.Схема выбора сессии с использованием программы выбора сессии

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

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

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

Остановимся на ключевых недостатках данного подхода к реализации метода сессионного контроля доступа.

1) Механизмами защиты операционной системы и приложений (в том числе реализованных «но умолчанию» без настройки соответствующих механизмов защиты) разделительная политика доступа между сессиями не реализуется.

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

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

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

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

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

Напомним, что для альтернативного решения, рассмотренного выше, обоснована необходимость использования метода разделения файловых объектов, не разделяемых между учетными записями системой и приложениями. Подобных объектов в системе не так уж и много, поэтому их разделение средством защиты достаточно просто решаемая на практике задача. В данном же случае речь идет о разделении между сессиями файлов, записываемых приложениями в процессе их работы под одной и той же учетной записью. Данная задача принципиально также может быть решена с использованием метода разделения файловых объектов с соответствующим заданием субъекта доступа (сессия, учетная запись), но вопрос в другом. Сколько и каких файлов создается и модифицируется в процессе работы приложениями, и какими приложениямипод учетной записью пользователя? А ведь каждый подобный файл -это «канал» утечки информации. Не должно быть в системе файлов, в которые разрешена запись приложениям, не разделенных между сессиями, что, как отмечали, является основополагающим требованием к корректности реализации сессионного контроля доступа, выполнение которого является обязательным при построении безопасной системы! Подобные объекты не то, чтобы разделить, а элементарно выявить в системе в полном объеме уже является большой проблемой!

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

Все сказанное позволяет нам сделать важнейший вывод.

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