На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Локализация прав доступа стандартных приложений к ресурсам

Включение в схему управления доступом субъекта «ПРОЦЕСС» предос­тавляет широкие возможности по локализации прав доступа стандартных приложений к ресурсам, что, прежде всего, позволяет эффективно про­тиводействовать скрытым угрозам. Рассмотрим лишь некоторые приме­ры реализации дополнительных функциональных возможностей защиты информации.
Локализация прав доступа к ресурсам виртуальных машин
Как отмечалось ранее, важнейшим требованием при реализации диспетче­ра доступа является следующее: «управление доступом должно осуще­ствляться как для явных действий субъекта, так и для скрытых». Под «явными» подразумеваются действия, осуществляемые с использованием санкционированных системных средств, а под «скрытыми» — иные действия, в том числе с использованием собственных программ субъектов доступа.
Наиболее критичными, с точки зрения обеспечения информационной бе­зопасности, являются скрытые каналы взаимодействия виртуальных машин. К таковым, например, относятся макросы для офисных приложений и не-регламентированные действия JVM (например, виртуальная машина JAVA).
Серьезные проблемы безопасности, связанные с защитой от несанкцио­нированных действий виртуальных машин* вызваны тем, что виртуаль­ная машина «видна» только именем своего исполняемого файла (напри­мер, winword.exe) или процессом внешнего интерпретатора команд (если интерпретатор команд не встроен в приложение). При этом машина имеет встроенные средства программирования, например, VBA для создания макросов в редакторе Word и других офисных приложениях.
Встроенными средствами программирования виртуальной машины мо­гут быть запрограммированы скрытые каналы доступа к ресурсам. При этом невозможно будет определить запуск соответствующей несанкцио­нированной программы (соответственно, разграничить для нее доступ к ресурсам), т.к. в качестве запущенного процесса будет отображаться имя
процесса виртуальной машины вне зависимости от того, какую внутрен­нюю программу она исполняет.
Настройкой прав доступа виртуальных машин (процесса виртуальной маши­ны, либо процесса внешнего интерпретатора команд) к различным частям
файловой системы можно создать некоторую «рабочую область» для данной виртуальной машины (например, каталог), вне которой она не сможет что-
либо изменять. Сделать это возможно благодаря средствам разграничения доступа для субъекта «ПРОЦЕСС». При этом для виртуальных машин, дос­туп которых к ресурсам следует разграничивать отдельно, можно:
* предотвратить запуск каких-либо программ, установленных на ком­пьютере (если запретить к ним доступ виртуальной машины);
» предотвратить доступ к настроечным и критичным файлам данных, располагающемся на компьютере (в том числе к системному диску).
Таким образом, можно минимизировать возможный ущерб от скрытых каналов доступа к ресурсам, которые априори могут быть организованы средствами программирования виртуальной машины [19]. Решение дан­ной задачи является весьма существенным моментом в рамках реализа­ции механизма обеспечения замкнутости программной среды.
Локализация прав доступа к ресурсам стандартных приложений со встроенными средствами защиты информации
Ранее рассматривались вопросы защиты информации на уровне ОС. Тем
не менее ряд приложений имеют собственные механизмы защиты. В
результате возникает задача эффективной интеграции механизмов защи-
ты ОС и приложений в единой автоматизированной системе. Проиллю­стрируем сказанное на примере реализации СУБД.
Выше рассматривались механизмы управления доступом к файловым объек­там, где объектами доступа являлись структурные элементы файловой сис­темы — логический диск (или том), каталог, файл. Важной проблемой за­щиты информации является включение в объекты доступа элементов приложений, в частности, таблиц для СУБД. Рассмотрим возникающие при
этом проблемы на примере реализации разграничений доступа для СУБД.
СУБД осуществляет управление доступом к таблицам. Все таблицы, до­ступ к которым разграничивается между пользователями, могут находиться в одном или нескольких файлах, т.е. разграничения для файлов и таб­лиц в общем случае не совпадают. Однозначное соответствие реализует­ся только в том случае, когда каждая таблица базы данных располагает­ся в собственном файле.
Т.к. разграничения доступа для файлов и таблиц в одной системе в об­щем случае не совпадают, возникает противоречие. С одной стороны, чтобы разрешить доступ пользователю к таблице на более низком уров­не иерархии (системном), ему должен быть разрешен доступ ко всему
файлу. С другой стороны, один файл в СУБД, как правило, содержит таб­лицы нескольких различных пользователей. Таким образом, не выпол­няется требование к диспетчеру доступа, в рамках которого управление доступом должно осуществляться как для явных действий субъекта (до­ступ к файлу), так и для скрытых (доступ к таблицам внутри файла).
Корректно задача управления доступом решается здесь только в том слу­чае, если функционируют разграничения доступом обоих уровней — и для
файлов, и для таблиц. Это становится возможным только при использова­нии специальных приложений, которые при доступе к файлам БД позволя­ют осуществлять управление доступом к таблицам. Используя иные прило­жения, например, проводники, пользователь сумеет получить доступ ко всему
файлу, т.е. получить несанкционированный доступ к таблицам других пользо­вателей — имеет место скрытый канал доступа к ресурсам.
С целью разрешения отмеченного противоречия в современных распрос­траненных СУБД реализуется следующий подход. При инсталляции СУБД в ОС создается специальный пользователь, от имени которого работает сам процесс СУБД. Иным пользователям средствами защиты ОС доступ к файлам БД должен запрещаться (средствами администрирования механиз­мов защиты ОС). Внутри СУБД осуществляется разграничение прав дос­тупа на уровне таблиц БД непосредственно самой СУБД. Т.е. СУБД, по
сути, встраивается в ОС, создавая собственный поток обращений к табли­цам БД. Очевидно, что подобный подход к решению задачи интеграции механизмов защиты обусловлен возможностями механизмов управления доступом, встроенных в ОС (т.к. СУБД здесь выступает в качестве прило­жения и должна опираться на встроенные возможности ОС).
Включение в субъекты доступа субъекта «ПРОЦЕСС», позволяет принци­пиально иным образом решать данную задачу при построении СУБД, т.к. в этом случае настройками диспетчера доступа можно организовать доступ к файлам, содержащим таблицы, только приложением, имеющим встроенные средства разграничения доступа к таблицам. Иным же приложениям (в ча­стности проводникам, работающим с файлами) доступ к файлам, содержа­щим таблицы, должен быть запрещен. Таким образом, применение рассмат­риваемой возможности управления доступом позволяет кардинально изменить подход к интеграции механизмов защиты ОС и приложений.
Аналогичным образом может быть локализован доступ к ресурсам и дру­гим стандартным приложениям со встроенными механизмами защиты информации. При этом рассматриваемая возможность управления дос­тупом может в значительной мере упростить подходы к реализации при­ложений со встроенными механизмами защиты, в смысле их интеграции со средствами защиты, реализуемыми на уровне ОС.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика