Данная статья посвящена анализу системы обязательного ограничения доступа для СУБД Oracle. В результате обнаруживается несколько каналов утечки.
Для многих информационных систем на базе СУБД часто возникает проблема реализации ограничения доступа, учитывающего ценность информации. Обычно это имеет решающее значение для крупномасштабных информационных систем государственного или корпоративного использования (например, географических информационных систем или систем управления документами). Такая система обычно подразумевает модель обязательного доступа. Одной из особенностей обязательной модели является предотвращение преднамеренного или случайного снижения ценности информации благодаря управлению информационными потоками. Модель обязательного доступа реализуется путем маркировки всех субъектов и объектов, принадлежащих системе ограничения доступа.
СУБД Oracle на данный момент является одной из самых мощных и популярных промышленных СУБД. Начиная с версии Oracle9i реализован компонент Oracle Label Security (OLS), позволяющий организовать обязательный доступ к хранимым данным. OLS — это набор процедур и ограничений, встроенных в ядро базы данных, которые позволяют реализовать контроль доступа на уровне записей. Чтобы включить OLS, необходимо создать политику безопасности, содержащую набор меток. Всякий раз, когда эта политика создается, ее следует применять к защищенным таблицам, а пользователи должны получать права на соответствующие метки.
Интересным для рассматриваемой системы представляется анализ возможных каналов утечки конфиденциальной информации.
Мы предлагаем следующий общий алгоритм анализа реализованной модели обязательного доступа.
1) Типы объектов доступа определяются в соответствии с опубликованной документацией и исследованием СУБД (например, таблицы, строки или столбцы).
2) Команды SQL анализируются с точки зрения того, как пользователи могут изменять объекты доступа.
3) Для каждого типа объекта доступа создается несколько объектов с разным уровнем конфиденциальности.
4) Создаются несколько учетных записей пользователей (субъектов доступа) с разными обязательными правами доступа.
5) Формируется последовательность SQL-запросов, которые выполняются с разными обязательными правами ограничения доступа и объектами с разным уровнем конфиденциальности. По результатам анализа выполнения этих запросов можно построить модель доступа и сделать вывод о наличии в системе уязвимостей, которые могут привести к утечке или повреждению конфиденциальной информации.
Давайте рассмотрим объекты доступа в OLS. Это записи таблицы, имеющие уникальные метки. Часто подразумевается, что таблицы являются объектами доступа в OLS, поскольку к таблицам применяется политика безопасности. Однако сами таблицы не имеют меток; они просто содержат помеченные строки.
Следующие основные операции SQL обрабатывают отдельные записи:
CREATE – создание новой записи;
SELECT – чтение существующей записи;
ОБНОВЛЕНИЕ – изменение существующей записи;
DELETE – удаление записи.
Наши эксперименты представляли собой последовательности запросов, вызываемых пользователями с разными обязательными правами доступа к объектам разного уровня конфиденциальности. Эти эксперименты позволили построить модель обязательного доступа OLS к записям. Мы определяем две переменные: I и J. I — значение метки объекта. Меньшие значения I указывают на более высокий уровень конфиденциальности (значение 0 соответствует «совершенно секретно»). J — значение уровня доступа субъекта.
Модель можно представить в следующем формализованном виде:
1. СОЗДАТЬ\ВЫБРАТЬ\ОБНОВИТЬ\УДАЛИТЬ, j = i
2. ВЫБОР, j i
Такая модель обязательного доступа на уровне записей вполне корректна и соответствует критериям модели безопасности Bell-La Padula. Таким образом, OLS корректно работает на уровне записей таблицы.
Однако помимо записей как представления хранимых данных, пользователи могут взаимодействовать с другими представлениями данных, на которые не влияет политика обязательного доступа. Таблицы являются примером таких объектов. Пользователи действительно могут изменять структуру таблиц, т.е. добавлять новые поля, изменять их имена и изменять типы данных. OLS теряет способность корректно работать на уровне таблицы.
Например, пользователь с более высокими обязательными правами имеет право создать новое поле в таблице. Имя поля само по себе может быть конфиденциальным, и механизм OLS не препятствует этой операции. Пользователь с более низкими правами доступа всегда имеет возможность запросить названия всех полей.
Например, создается новое поле с именем new_password_xxx (где xxx — совершенно секретная информация) с помощью следующего sql-запроса:
ALTER TABLE user1.test_table ADD (новый_пароль VARCHAR2(30));
Если другой пользователь, не имеющий каких-либо обязательных прав, выполнит следующий запрос (SELECT * FROM user1.test_table; ), он получит пустой набор данных, однако ему будут доступны все имена полей user1.test_table. Как было показано выше, имя столбца может содержать секретную информацию.
Показанные в примере операции создают дуплексные каналы обмена данными между субъектами с более высокими и более низкими правами доступа, в связи с чем могут стать причиной утечки секретной информации.
В связи с вышеизложенным модель обязательного доступа, реализованная в Oracle, не является полной, и это обстоятельство позволяет обмениваться секретной информацией без какого-либо контроля над системой обязательного доступа, что снижает ценность информации.
Также вы можете прочитать об актуальных методах аутентификации биометрической клавиатуры на нашем сайте: http://www.allmysoft.com/biometric-keyboard-signature-authentication.html.
Современные системы требуют высокой конфиденциальности данных. Хотя исследователи предлагают различные модели и методы для защиты баз данных, многие информационные системы на таких платформах оказываются уязвимыми.
Практическая реализация моделей позволяет эффективно планировать проектирование ограничений доступа к информации. Работая с научной литературой за последние двадцать лет, мы заметили, как заметное место в предложениях по предоставлению доступа регулярно занимает только уровень управления приложениями и определяют единые уровни конфиденциальности мультимедиа для отдельных полей поиска по ключевым словам.
Однако в случае управления производственными потоками или построения субъект-субъектных отношений использование одних классификаций становится невозможным. Следовательно, аутентификации некоторых частей с помощью ненадежных паролей, публичному доступу из-за отвлечения на поиски следует уделять особое внимание из-за еще большей опасности передачи таких данных злоумышленникам.
Особенностью, существенной при реализации некоторых мер, направленных на дополнительное повышение секретности данных, является рассмотрение вызова общеприкладных административных привилегий для отдельных идентификаторов пользователей (или доменных имен) абсолютно идентичным получению промежуточной информации о ключевых словах и административных правилах позиционно. Поскольку известно, что серверные секреты обычно распространяются по всей сети, использование общеизвестных векторов практических публикаций показывает, что злоумышленники знают, где получить информацию, какую информацию и как, а затем, упс, какой-то объект приложения может получить root-административный доступ.
-
Маршрутизатор — Как Это Работае?
19 Oct, 24 -
Баккара Для Новичков
19 Oct, 24 -
Что Такое Mcse
19 Oct, 24
