Software & Systems

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

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

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

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

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

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

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

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

Обозначим условия, в рамках которых рассматривается проблема:

1)    защищенная программная среда формируется неким СрЗИ, осуществляющим, помимо прочего, мандатный контроль доступа к защищаемым ресурсам (в том числе к объектам файловой системы – файлам и каталогам);

2)    реализация мандатного контроля доступа основывается на модели Белла–Лападула [1–3];

3)    работа пользователя в системе оформлена в виде сеанса с указанием в начале сеанса его уровня конфиденциальности (далее – уровень сеанса);

4)    рассматривается только иерархический (по уровням конфиденциальности) аспект мандатного контроля доступа (впрочем, при некоторых доработках описываемые далее методы могут быть применены и по отношению к мандатным категориям);

5)    у пользователя/приложения есть дискреционные права доступа к служебным файлам.

Подобные условия обеспечиваются большинством отечественных сертифицированных СрЗИ уровня ОС.

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

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

Сценарий работы с конфигурационными файлами предполагает, что приложение хранит свои и пользовательские настройки в виде одного или нескольких конфигурационных файлов на диске. Данный сценарий успешно функционирует в условиях отсутствия мандатного контроля доступа, однако при наличии последнего возникают определенные сложности. Как правило, информация, хранимая в конфигурационных файлах, не является конфиденциальной и касается только настроек приложения. При этом удобно (хотя и необязательно) хранить единый для различных сеансов набор настроек приложения, чтобы пользователю не пришлось несколько раз выполнять одну и ту же настройку. Более того, пользователю удобно иметь возможность изменять настройки приложения в различных сеансах. Желание разработчика обеспечить пользователю удобство работы с приложением приводит к конфликту с мандатным контролем доступа. Конфигурационный файл получает уровень конфиденциальности (далее – гриф) при создании, после чего запись в файл оказывается возможной только в сеансе, уровень которого не выше грифа файла (или равен грифу файла – для некоторых реализаций мандатного контроля доступа в СрЗИ). Даже при условии корректной обработки невозможности записи (чтобы приложение не завершило работу аварийно) попытки записи настроек в сеансах с уровнем, превышающим гриф файла, не приведут к сохранению настроек, что значительно ограничивает пользователя в возможностях конфигурирования приложения. Чтение же настроек из файла оказывается возможным, только если гриф файла не превышает уровень сеанса; в противном случае приложению не удастся считать свои настройки, оно сможет использовать только настройки по умолчанию (если в приложении заложена такая возможность).

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

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

Рассмотрим способы решения описанных проблем. Данные способы можно условно разделить на две группы: дополнение модели Белла–Лапа­дула и виртуализация контролируемых ресурсов.

Первая группа подразумевает, что классические правила модели Белла–Лападула – «простое условие защиты» («нет чтения сверху») и «*-свойство» («нет записи вниз») [1–3] – дополняются правилом, разрешающим при определенных условиях доступ к файлу без учета его грифа и уровня сеанса работы пользователя.

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

Дополнение модели Белла–Лападула можно реализовать двумя способами.

Первый способ (назовем его сервисом доступа к файлам) – это реализация специального сервиса, который должен использовать приложение вместо штатных системных функций работы с файлами. Для настройки такого сервиса должны указываться правила для объектов доступа (файлы, к которым необходимо получать доступ), а также субъектов доступа (процесс и/или пользователь). Реализация такого сервиса возможна, если в СрЗИ присутствует механизм доверенного контекста, когда приложение, неким образом обозначенное как доверенное, может получать доступ к ресурсам без учета мандатного контроля доступа.

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

Как видим, в обоих случаях дополнение модели Белла–Лападула характеризуется сохранением информации в едином для всех сеансов файле и возможностью обхода (при определенных условиях) правил «нет чтения сверху» и «нет записи вниз».

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

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

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

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

Сравнительный анализ способов доступа к служебным файлам

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

-      влияние на реализацию функционального ПО;

-      влияние на быстродействие файловых операций;

-      возможность задания отдельных настроек для каждого уровня сеанса;

-      соответствие модели Белла–Лападула.

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

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

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

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

Способы с дополнением модели Белла–Лапа­дула характеризуются хранением служебных данных в общем для всех сеансов файле. Как следствие, пользователю достаточно задать настройки один раз, чтобы использовать их во всех сеансах. Виртуализация контролируемых ресурсов, напротив, потребует отдельного (для каждого уровня сеанса) задания настроек приложения. С другой стороны, в некоторых случаях пользователю может быть удобнее иметь отдельные наборы настроек для различных сеансов. Виртуализация контролируемых ресурсов даст ему такую возможность «из коробки», в то время как при использовании дополнения модели Белла–Лапа­дула этот функционал придется специально реализовывать в приложении. Таким образом, использование и единого файла, и нескольких виртуальных файлов может являться как достоинством, так и недостатком того или иного способа в зависимости от потребностей пользователя.

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

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

Выбор способа доступа к служебным файлам

<img data-cke-saved-src="uploaded/image/2013-2/image300.gif" src="uploaded/image/2013-2/image300.gif" alt="\" Подпись:"="" style="float: left; width: 611px; height: 196px;" class="thumb">Необходимость использования того или иного способа доступа к служебным файлам может определяться множеством различных факторов. Поскольку отдельные факторы могут блокировать применение различных способов, выбор конкретного способа осуществляется по результатам суммарной оценки всех факторов.

Предлагается следующий алгоритм выбора: для каждого оцениваемого фактора определяются множество рекомендуемых способов Ri и множество допустимых способов Pi. Далее рассматривается множество R, являющееся пересечением всех полученных множеств рекомендуемых способов. Если полученное множество R не пусто, необходимо применять любой из входящих в него рекомендуемых способов (выбор конкретного способа может определяться по результатам рассмотрения прочих факторов, например трудоемкости реализации). Если же множество R пусто, необходимо рассмотреть множество P, являющееся пересе- чением всех полученных множеств допустимых способов. Если данное множество не пусто, необходимо применять любой из входящих в него допустимых способов. Если же множество P пусто, значит, существующая комбинация факторов не позволяет использовать описанные способы и необходимо либо скорректировать исходные требования и повторить процесс выбора, либо искать другие способы решения проблемы доступа к служебным файлам.

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

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

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

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

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

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

Второй вариант позволяет дополнительно к указанным способам использовать также корневой указатель ресурса и виртуализацию уровня ФС.

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

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

В качестве примера рассмотрим выбор способа доступа к служебным файлам при следующих исходных данных:

–      в используемом СрЗИ имеются средства поддержки работы со служебной информацией: сервис доступа к файлам, механизм доверенных файлов, корневой указатель ресурса, виртуализация уровня ФС;

–      должно использоваться только уже существующее функциональное ПО, возможность его доработки отсутствует;

–      присутствуют высокие требования по быстродействию системы;

–      требования по организации настройки системы (в плане различных сеансов) не заданы;

–      необходима верификация модели защиты.

Для обозначения способов доступа к служебным файлам будем использовать их сокращенные наименования: сервис доступа к файлам (СДФ), механизм доверенных файлов (МДФ), корневой указатель ресурса (КУР), виртуализация уровня ФС (ВУФС).

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

R1={СДФ, МДФ, КУР, ВУФС}, P1={СДФ, МДФ, КУР, ВУФС};

R2={МДФ, ВУФС}, P2={МДФ, ВУФС};

R3={МДФ, КУР, ВУФС}, P3={СДФ, МДФ, КУР, ВУФС};

R4={СДФ, МДФ, КУР, ВУФС}, P4={СДФ, МДФ, КУР, ВУФС};

R5={КУР, ВУФС}, P5={СДФ, МДФ, КУР, ВУФС}.

R={ВУФС}, P={МДФ, ВУФС}.

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

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

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

Литература

1.     Гайкович В.Ю., Першин А.Ю. Безопасность электронных банковских систем. М.: Единая Европа, 1994. 363 с.

2.     Грушо А.А., Тимонина Е.Е. Теоретические основы защиты информации. М.: Изд-во Агентства «Яхтсмен», 1996. 187 с.

3.     Девянин П.Н. Модели безопасности компьютерных систем: учеб. пособие для студ. вузов. М.: Академия, 2005. 144 с.

References

1.  Gaykovich V.Yu., Pershin A.Y.,  Bezopasnost elektronnykh bankovskikh sistem  [Electronic banking system security], Moscow, Edinaya Evropa, 1994, 363 p.

2.  Grusho A.A., Timonina E.E.,  Teoreticheskie osnovy zashchity informatsii  [Theoretical foundations of information secu-rity], Moscow, Yakhtsmen Publ., 1996, 187 p.

3.  Devyanin P.N., Modeli bezopasnosti kompyuternykh sistem [Computer systems security order], Moscow,  Akademiya,  2005, 144 p.