Распространение Internet изменило методы ведения бизнеса. Сеть позволяет эффективно использовать ресурсы, и теперь пользователи предприятия, его партнеры и поставщики могут легко получать доступ к централизованным данным. Но такое использование информации предполагает организацию надежной защиты информации.
Системы на базе Internet предъявляют серьезные требования к контролю доступа на очень высоком уровне детализации, вплоть до отдельного пользователя. Кроме того, предприятия все в большей степени сосредотачиваются на своих основных направлениях и предпочитают отдавать обеспечивающие функции независимым организациям. Это делает актуальным разработку инструментария для создания систем, обладающих возможностями надежной персонификации и контроля доступа к данным.
Когда механизм контроля доступа встроен в приложение, а не накладывается непосредственно на данные, остается вероятность его обойти. Средства защиты, управляемые централизованно и применяемые непосредственно к данным, призваны обеспечить качественно иной уровень безопасности.
Известные подходы
Хорошо известный принцип «минимальных привилегий» гласит, что пользователь должен иметь только те привилегии, которые ему необходимы для выполнения своей работы, и ничего больше. К средствам СУБД, помогающим реализовать этот принцип, можно отнести:
- роли, упрощающие администрирование за счет определения групп детализированных привилегий, ограничивающих права доступа;
- представления (view), позволяющие контекстно ограничить доступ к данным;
- хранимые процедуры, реализующие корректные транзакции без прямого предоставления привилегий конкретному пользователю.
Эти возможности используются для реализации принципа минимальных привилегий и предоставляют контроль доступа на уровне таблиц, однако этот подход не всегда удобен для контроля на более детальном уровне. В СУБД Oracle предусмотрены средства, благодаря которым можно обеспечить более «тонкий» контроль доступа [1].
Представления
Представления — основа многих механизмов защиты, встраиваемых в приложения. Представления могут ограничивать доступ к информации, содержащейся в базовой таблице, по содержимому или контексту. Например, представление таблицы, где собраны имя, адрес и отдел, в котором работает сотрудник, а также информация о зарплате, позволяет кадровику видеть только те столбцы таблицы, к которым у него есть доступ. Представления также полезны для управления доступом с учетом контекста. К примеру, правила организации защиты на предприятии могут позволять просматривать информацию о зарплате только в рабочие часы. Тогда можно создать представление, выбирающее из таблицы необходимую информацию, с дополнительным ограничением, например, что обратиться к нему можно только с 10 до 19 часов.
Впрочем, представления нельзя считать оптимальным инструментом для решения задачи ограничения доступа. Такой подход не удобен, если для реализации правил защиты необходимо создавать множество представлений. К примеру, использование представлений для ограничения доступа к данным по регионам вполне оправдано, если регионов всего десять. С другой стороны, если необходимо ограничить доступ только данными конкретного пользователя, при условии, что этих пользователей тысячи, абсолютно неприемлемо.
К тому же, если пользователи могут обращаться к исходным таблицам, защита, построенная на представлениях, не работает. Это общая проблема для ситуаций, когда защита встраивается в приложения и не реализуется посредством механизмов самой базы данных.
Виртуальная частная база данных
Концепция виртуальных частных баз данных (Virtual Private Database, VPD) представляет собой комбинацию реализуемого на сервере детализированного контроля доступа с защитой приложения на сервере баз данных. Посредством динамически применяемых SQL-запросов с соответствующим предикатом VPD ограничивает доступ к данным на уровне строк и связывает правила защиты с самой таблицей.
Работа с виртуальными частными базами данных обладает рядом преимуществ. Прежде всего, защиту придется создавать только однажды на сервере баз данных, а не реализовать ее многократно в каждом приложении, которое обращается к данным. Кроме того, пользователи не могут обойти правила защиты, встроенные в приложения, поскольку эти правила применяются к данным и автоматически поддерживаются на сервере данных вне зависимости от метода доступа. Наконец, обеспечивается своего рода «прозрачность», поскольку виртуальная частная база данных реализуется на уровне базы данных и не принимает в расчет логику конкретных приложений; в результате возможности детального доступа к данным могут использовать как готовые коммерческие приложения, так и созданные самими пользователями.
|
| Рис. 1. Oracle9i с виртуальной частной базой данных динамически изменяет запросы SQL. Оба пользователя выполняют одинаковые запросы. С помощью VPD база данных возвращает результаты, персонифицированные для каждого пользователя. |
Динамически изменяемые запросы
Детальный контроль доступа к данным базируется на механизме динамической модификации запросов, который позволяет реализовать правила защиты, связанные с конкретными объектами. (В данном случае под «запросом» понимается доступ к данным с помощью конструкций удаления, добавления или обновления, а не только выбора.)
SQL-запросы пользователей к таблицам базы данных модифицируются с помощью соответствующих правил защиты, накладываемых посредством динамически вычисляемой декларации WHERE. Такая декларация вырабатывается специальной функцией, реализующей правила защиты; это может быть любой предикат, выражение или некая формула, возвращаемая функцией. Функции, которые возвращают предикаты, могут также вызывать другие функции. В PL/SQL можно интегрировать вызовы функций на Си или Java, которые могут либо получать доступ к информации операционной систем, либо возвращать условия WHERE, извлеченные из файла операционной системы или центрального хранилища правил. Благодаря такому решению достигается дополнительная гибкость, поскольку оно может возвращать различные предикаты для каждого пользователя, каждой группы пользователей или каждого приложения.
Виртуальная частная база данных может ограничивать доступ к данным в определенных таблицах для всех пользователей, как того требует корпоративная политика. Например, компания может ограничивать доступ к определенным таблицам таким образом, чтобы они были открыты только в течение рабочего дня. Для реализации такого доступа VPD анализирует значение системной переменной SYSDATE и игнорирует запросы, переданные в неурочные часы. К другим таблицам в той же самой базе данных такие правила не применяются, и доступ к ним не ограничивается.
Предположим, что служащему отдела кадров разрешено просматривать данные о сотрудниках, работающих только в конструкторском отделе. Когда он посылает запрос SELECT * FROM сотр, функция, реализующая правила защиты, возвращает предикат отдел = 'КОНСТРУКТОРСКИЙ', и база данных прозрачным образом преобразует запрос в SELECT * FROM сотр WHERE отдел = 'КОНСТРУКТОРСКИЙ'.
Защищенный контекст приложения
Решения о предоставлении доступа могут приниматься на основе информации о пользователе, например, о его должности, подразделении и статусе. Механизм контекстов приложений (Application Context) позволяет определять, устанавливать и проверять атрибуты защиты, которые помогают осуществлять детальный контроль доступа, реализуя виртуальные частные базы данных.
Контексты приложений выступают как своего рода защищенные кэши данных, которые могут использоваться для организации детального контроля доступа к конкретной таблице. При регистрации пользовательского сеанса в базе данных Oracle устанавливает некоторый контекст приложения. Информация в контексте приложения определяется разработчиком с учетом сведений, относящихся к конкретному приложению. Например, приложение «Оформление заказа», которое будет запрашивать данные из таблицы «Заказы», может предоставлять доступ пользователям в зависимости от их должности и географического положения. В этом случае приложение инициализирует контекст для каждого пользователя в момент его регистрации и передает его вместе с данными, запрашиваемыми из таблиц «Сотрудники» и «Продажи» при выяснении должности и местонахождения (региона), где соответственно работает пользователь. Ссылаясь на контекст приложения при передаче данных о должности и местонахождении пользователя при каждом запросе, можно отказаться от необходимости многократного выполнения подзапросов, снижающих производительность.
При реализации детального контроля доступа могут использоваться два следующих механизма.
- Выбор предикатов. Разработчик может обратиться к контексту приложения внутри функции реализации правил защиты для того, чтобы определить корректный возвращаемый предикат. Например, если атрибутом контекста "Оформление заказа" является "должность", то в зависимости от должности могут возвращаться различные предикаты. Для сотрудника будет установлен предикат, в соответствии с которым по запросу будет возвращена информация обо всех заказах, а пользователю будут предоставлены данные, касающиеся только его заказа.
- Связывание переменной в предикате. Атрибут контекста может использоваться в самом предикате для предоставления связанной переменной. Например, чтобы пользователи могли видеть только свои записи, можно вернуть предикат, который ограничивает записи с учетом уникального для каждого пользователя атрибута контекста оформления заказа. При этом создается ровно один SQL-запрос, применяемый всеми пользователями, но для каждого из них он выполняется по-разному.
Контекст приложения обеспечивает защиту благодаря ряду своих свойств.
- Уникальность контекста. Oracle9i обеспечивает уникальность имен контекстов во всей базе данных, гарантируя, что отдельные пользователи не смогут их дублировать ни случайно, ни преднамеренно. Возможность создавать контекст - отдельная системная привилегия, и определять контекст могут только пользователи с соответствующими полномочиями.
- Проверка атрибутов. При переустановке атрибутов контекста гарантируется корректность значений этих атрибутов, а также наличие у пользователя права оперировать доступом с соответствующим набором атрибутов; для этого могут выполняться запросы к метаданным приложения.
- Установка атрибутов защиты. База данных гарантирует, что всякий раз, когда устанавливается атрибут контекста, это выполняет заслуживающий доверия пользователь или процесс. В результате, приложениям можно предоставить возможность принимать решения о защите на основе контекста приложения, поскольку контекст наверняка установлен корректно известным и заслуживающим доверия, а не злонамеренным пользователем или процессом.
Предопределенные атрибуты, называемые примитивами сеанса (session primitive) позволяют контексту приложения для осуществления контроля доступа использовать информацию, уже имеющуюся в базе данных относительно сеанса пользователя. СУБД Oracle поддерживает встроенное пространство имен для контекстов приложений, USERENV, обеспечивающее доступ к примитивам сеанса, т.е. информации, которую база данных получает о сеансе пользователя. К примеру, через USERENV можно получить IP-адрес, с которого пользователь устанавливает соединение, уникальное имя (distinguished name, DN) из сертификата открытого ключа пользователя, имя пользователя и имя прокси.
Новое в механизме виртуальных частных баз данных
СУБД Oracle9i по сравнению с предыдущей версией, Oracle8i, пополнилась несколькими новыми средствами организации виртуальных частных баз данных.
- Разделенный детальный контроль доступа, который позволяет задавать уникальный контекст для каждого приложения.
- Глобальный контекст приложения, который поддерживает объединение соединений, общих для многоуровневого развертывания, в то же время, сохраняя возможность принятия решений о контроле доступа на базе пользовательской информации.
- Диспетчер правил - графический пользовательский интерфейс для управления правилами VPD.
- Поддержка синонимов, которая позволяет функциям, реализующим правила VPD, работать с синонимами (в дополнение к таблицам и представлениям) таким образом, что приложения могут использовать детальный контроль доступа. Приложения баз данных часто используют синонимы как псевдонимы для таблиц, представлений или других объектов. Механизм синонимов полезен при маскировке имени и владельца объекта схемы, обеспечивая открытый доступ к объекту схемы, прозрачность местонахождения для таблиц, представлений и программных модулей удаленной базы данных, а также для упрощения SQL-запросов.
|
| Рис. 2. Контекст представлений содержит информацию, полезную для принятия решений, связанных с контролем доступа |
Разделенный детальный контроль доступа
База данных, предоставляющая данные для различных приложений, может поддерживать различный контекст для каждого из них. При развертывании виртуальной частной базы данных на сервере с множеством приложений полезно поддерживать отдельные контексты для каждого приложения таким образом, чтобы разработчикам не пришлось согласовывать совместные правила. Это позволяет развертывать VPD на большем количестве систем, поскольку пользователи могут теперь поддерживать общие данные для различных приложений, совместно использующих общие таблицы, и при этом определять разные правила VPD для каждой из систем.
Рассмотрим два приложения, «Ввод заказов» и «Анализ продаж», использующих базу данных «Товары». (Допустим, приложение «Ввод заказов» было разработано в самой организации, а «Анализ продаж» — коммерческий продукт.) Они используют множество одних и тех же таблиц и представлений в базе данных «Товары», и каждая их них должна поддерживать свои условия контроля доступа к данным. Приложение «Ввод заказов» должно препятствовать оформлению заказов на чужое имя и вне своего региона, а «Анализ продаж» требует, чтобы пользователи проверяли показатели продаж в своих регионах и выполняли анализ только по тем группам товаров, за которые они отвечают. «Рабочий» контекст приложения определяет, какое из приложений обращается к данным, после чего выбираются правила, которые применяются к данному приложению. В этом примере группа правил для «Ввода заказов» (пользователи могут изменять только свои собственные заказы и только в своем регионе) реализуется, если активен рабочий контекст «Ввода заказов». Если же запрос выполняется через «Анализ продаж», ее группа правил (ограничение доступа по региону и по серии продуктов) вступает в действие в соответствии с другим рабочим контекстом. За счет использования механизма разделенного детального контроля доступа предикат WHERE, добавляемый к SQL-запросам, отличается в зависимости от приложения.
Можно также определить группу правил по умолчанию, действующих всегда в рамках контекста. Например, можно реализовать правила, в соответствии с которыми база данных накладывает ограничение «пользователи видят только те продукты, которые выпущены их собственными филиалами» в дополнение к любым ограничениями, накладываемым приложением. Такие правила присоединяются (с помощью логического оператора AND) к контексту приложения, ориентированного на Приложение A, когда пользователь обращается к таблице через данное приложение, либо к контексту Приложения B, если пользователь работает с ним. Кроме того, в случае, если база данных не имеет информации о том, какой должен применяться контекст приложения, база данных применяет все правила ко всем приложениям. Это делается для того, чтобы пользователь не мог получить большие привилегии, если он обращается напрямую, минуя приложение (скажем, с помощью инструментария формирования запросов SQL*Plus), чем при передаче запроса через приложение.
Модель разделенного детального контроля доступа позволяет сочетать приложения собственной разработки с коммерческими продуктами, устанавливая различные правила защиты для каждого из них индивидуально.
Глобальный контекст приложения
Глобальный контекст приложения служит для поддержки идентичности пользователя в базе данных, на основании которой принимаются решения о доступе. Приложение промежуточного уровня или сервер приложений в трехзвенной клиент-серверной архитектуре программных систем формирует необходимую логику приложения и выполняет специфические для данного приложения операции, в то время как база данных обеспечивает масштабируемость, защиту и готовность. Глобальный контекст, который может разделяться многими приложениями, увеличивает производительность систем, работающих в трехзвенной среде. Поскольку сервер промежуточного уровня не создает новые сеансы пользователей для каждого соединения с базой данных, глобальный контекст приложения позволяет масштабировать приложения, не снижая защищенность системы. Впрочем, забота о производительности, являясь основной причиной, по которой разработчики приложений используют этот механизм, — все же не единственная причина.
Использование глобального контекста приложения позволяет совместить преимущества функций защиты базы данных с применимостью часто используемых архитектурных решений. Другими словами, эта функция в трехзвенных средах позволяет использовать детальный контроль доступа, а также проверять личность конечного пользователя, который не обязательно должен быть пользователем базы данных.
Часто серверы приложений используют агрегирование соединений для увеличения производительности и сокращения количества физических соединений между сервером промежуточного уровня и сервером базы данных.
Большинство серверов приложений не инициирует отдельного сеанса для каждого пользователя, поскольку это значительно увеличивает нагрузку в сети. Вместо этого, приложения часто связываются с сервером базы данных просто как application_user («пользователь приложения»). Эта модель хорошо масштабируется, уровень ее защиты довольно низок, поскольку почти вся защита должна встраиваться в приложение, и при этом любой пользователь, направляющий свои запросы помимо этого приложения, потенциально может получить неограниченный доступ к данным без защиты контроля доступа. Глобальный контекст приложения усиливает защиту приложений, функционирующих в такой среде. Разработчикам при этом не приходиться полностью менять архитектуру всей прикладной среды; им нужно только встроить поддержку глобального контекста и передавать базе данных соответствующую информацию посредством идентификатора клиента.
Диспетчер правил
Диспетчер правил Oracle Policy Manager представляет собой новый инструментарий администрирования на базе Java для управления правилами детального контроля доступа в виртуальных частных базах данных Oracle9, а также контекстами приложений. Тот же инструментарий служит для работы с еще одним средством дополнительной защиты, Oracle9i Label Security. Диспетчер правил, упрощающий администрирование правил и контекстов приложений, оказывается особенно полезен в крупных реализациях, предусматривающих применение различных правил для разных таблиц, представлений и синонимов. Этот инструментарий не избавляет от кодирования, однако значительно упрощает администрирование в рамках управления правилами виртуальных частных сетей, контекстами приложений и глобальными контекстами приложений.
Механизм Oracle Label Security играет роль своеобразного посредника при доступе к данным, сопоставляя метки, присвоенные фрагментам данных, с меткой прав доступа, полученной пользователем приложения. Такое «посредничество» при доступе позволяет разделить данные на различные категории доступа в одной базе данных.
Правила Oracle9i Label Security состоят из названия правила, параметров применения, определения меток, меток предоставления прав пользователю и списка защищенных объектов. С помощью диспетчера правил Oracle можно создавать правила, определять компоненты меток, создавать метки, устанавливать метки прав доступа пользователя, регулировать условия применения, применять правила к схемам и таблицам, удалять правила из схем и таблиц, отменять правила и конфигурировать параметры проверки Oracle Label Security.
Дополнительные возможности VPD
Виртуальная частная база данных дает пользователям возможность расширить собственные механизмы контроля доступа, уже предлагаемые Oracle9i, для увеличения уровня детализации.
Что касается применения правил к таблице или представлению, следует отметить, что можно создать представление, отражающее сложную политику защиты, в частности, в сочетании с контекстом приложения. Однако в результате можно получить громоздкий предикат и сложный план запроса. Например, если создается представление, рассчитанное на обращение к нему множества пользователей, причем каждый из них имеет свои условия доступа, само представление должно содержать множество данных, а также потенциально правила с множеством условий OR. Хотя лишь немногие из них могут иметь отношение к конкретному пользователю, если все возможные условия контроля доступа связываются с представлением, оптимизатор будет вынужден интегрировать их в план запроса каждого пользователя. В случае же применения детального контроля доступа к базовому объекту, а не к представлению, каждый может ссылаться на базовый объект с помощью только тех предикатов, которые актуальные для конкретного пользователя. Реализация детального контроля доступа для базового объекта (а не для представления) позволяет динамически создавать представление перед исполнением, а не во время исполнения, поэтому производительность оказывается намного выше.
Virtual Private Database в Oracle9i обеспечивает максимальную гибкость для поддержки как встроенной защиты приложений, так и выполнения настройки с учетом локальных условий.
Литература
[1]. The Virtual Private Database in Oracle9iR2. Understanding Oracle9i Security for Service Providers. An Oracle Technical White Paper. January 2002
