Обзор DB2 LUW, Часть 5: Функции разграничения и контроля доступа IBM DB2 LUW

Обзор встроенных функций разграничения и контроля доступа СУБД IBM DB2 для платформ Linux, Unix и Windows

Эта статья является пятой в серии, описывающей архитектуру, возможности и особенности системы управления базами данных (СУБД) IBM DB2 для платформ Linux, Unix и Windows (DB2 LUW). Темой статьи является обзор функций DB2 по разграничению и контролю доступа к данным, позволяющим реализовать самые сложные требования к обеспечению информационной безопасности и при этом сохранить контроль над настройками СУБД.

Максим Зиналь, Ведущий специалист по программному обеспечению, IBM

Maksim Zinal photoМаксим Зиналь - специалист по системам управления базами данных и разработчик программного обеспечения с большим опытом профессиональной деятельности и участия в разнообразных проектах, накопленным с 1999 года. В настоящее время занимается консультированием заказчиков по вопросам применения продуктов, входящих в состав аналитической платформы компании IBM, в том числе продуктов семейства DB2.



24.08.2016

Исходные материалы и контактная информация

Автор будет благодарен за любые сообщения о замечанных неточностях и недостатках изложения материала. Вопросы, замечания и предложения по содержанию статей можно направлять на электронную почту: mzinal@ru.ibm.com.

Основная часть материала статей является вольной интерпретацией официальной документации DB2. Представленная информация была реструктурирована и переформулирована для сжатого и в то же время максимально понятного изложения. Ссылки на использованные источники во всех случаях представлены в тексте статей и в разделе «Ресурсы».

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

Модель защиты DB2

Разграничение доступа к СУБД DB2 основано на двух различных механизмах:

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

Правильное совместное применение механизмов аутетификации и авторизации позволяет обеспечить предоставление доступа к информации DB2 только разрешённым субъектам доступа, и исключительно в допустимых контекстах.

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

Аутентификация

Механизм аутентификации обеспечивает проверку подлинности пользователя СУБД. Аутентификация пользователей реализуется внешними по отношению к СУБД DB2 LUW механизмами, с использованием специальных модулей аутентификации (security plug-ins).

Результатом успешного процесса аутентификации является полученный идентификатор пользователя (primary authorization name), а также набор идентификаторов групп безопасности, к которым относится пользователь. Идентификатор пользователя и идентификаторы групп пользователя, получаемые из внешнего по отношению к DB2 механизма аутентификации, используются впоследствии для выполнения контроля доступа встроенными средствами DB2 (включая механизмы авторизации и аудита доступа).

В поставку DB2 входят следующие модули аутентификации:

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

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

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

Протокол Kerberos не подразумевает передачу пароля пользователя через сеть, для других протоколов пароль передается от клиента на сервер и целесообразно использовать метод аутентификации с шифрованием пароля.

Используемый метод аутентификации определяется параметром AUTHENTICATION сервера СУБД. Состав возможных значений данного параметра и детальное описание результатов применения соответствующих значений приведены в документации. При использовании сторонних модулей аутентификации (не входящих в комплект поставляемых с DB2) необходимо настроить параметры, определяющие имена загружаемых библиотек применяемых сторонних модулей (в частности, параметры SRVCON_PW_PLUGIN, GROUP_PLUGIN, SRVCON_GSSPLUGIN_LIST), в дополнение к настройке параметра AUTHENTICATION.

Авторизация

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

Информация о предоставленных пользователям полномочиях сохраняется в служебных таблицах и конфигурационных файлах DB2. При проверке допустимости обращения к объектам и ресурсам СУБД, учитываются следующие виды полномочий:

  1. Основные полномочия: непосредственно предоставленные данному пользователю.
  2. Дополнительные полномочия: предоставленные тем группам и ролям (см. далее раздел о ролевом разграничении доступа), в которые включен данный пользователь.
  3. Публичные полномочия: предоставленные специальной служебной группе PUBLIC.
  4. Полномочия доверенного контекста: полномочия, предоставленные роли доверенного контекста (см. далее раздел о доверенных контекстах).

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

Предоставление полномочий осуществляется с использованием оператора GRANT, отзыв – с использованием оператора REVOKE.

Полномочия могут быть предоставлены пользователям на следующих уровнях:

  1. Системный уровень авторизации: полномочия предоставляются на уровне экземпляра DB2 и обеспечивают возможность выполнения операций управления и обслуживания для экземпляра, баз данных и объектов баз данных.
  2. Уровень базы данных: полномочия предоставляются на уровне базы данных и обеспечивают возможность выполнения операций управления, разграничения доступа и обслуживания отдельной базы данных.
  3. Уровень объекта базы данных: определяют состав допустимых операций на уровне объекта базы данных, например, право на выборку данных из таблицы (SELECT), право на выполнение хранимой процедуры (EXECUTE) и т.п.
  4. Уровень данных: полномочия, определяющие состав записей и полей, доступных пользователю. Реализуется с использованием механизма контроля доступа на уровне строк и колонок (RCAC) и с использованием механизма контроля доступа на основе меток конфиденциальности (LBAC).

Виды полномочий и принадлежность объектов

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

В DB2 существует четыре основные формы полномочий: административные полномочия, объектные привилегии, полномочия RCAC и полномочия LBAC. Кроме того, к большинству объектов базы данных применимо понятие владельца, или принадлежности объекта определенному пользователю. Владелец объекта обладает правами по работе с объектом вне зависимости от других установленных для него полномочий. Владелец объекта может быть изменен с помощью команды TRANSFER OWNERSHIP.

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

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

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

Объектные привилегии представляют собой полномочия на выполнение определенного типа операций для заданного объекта базы данных. Примером объектной привилегии является право на выполнение определенного вида SQL-команд (SELECT, INSERT, UPDATE, DELETE) над указанной таблицей.

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

Предоставление привилегий для объектов базы данных может быть выполнено пользователем с привилегией CONTROL в отношении данного объекта (включая пользователя-владельца), либо пользователем с системными полномочиями SECADM и/или ACCESSCTRL. Также возможность предоставления отдельного вида привилегий для конкретного объекта базы данных может быть явно разрешена пользователю путем предоставления ему данной привилегии по данному объекту с указанием ключа WITH GRANT OPTION.

Отмена полномочий для объектов базы данных может быть выполнена пользователем с полномочием CONTROL в отношении данного объекта (включая пользователя-владельца), либо пользователем с системными полномочиями SECADM и/или ACCESSCTRL.

Краткое описание полномочий для основных видов объектов DB2 приведено в нижеследующих таблицах.

Таблица 1. Административные полномочия на уровне экземпляра DB2
ПолномочиеОписание полномочияДетализация
SYSADMПолные права на управление экземпляром DB2 Управление всеми параметрами экземпляра СУБД (DBM CFG).
Изменение групп, которым предоставлены полномочия SYSADM, SYSCTL, SYSMAINT, SYSMON.
Обновление базы данных для использования новой версии СУБД;
Предоставление и отзыв полномочий в отношении табличных пространств.
SYSCTLПрава на выполнение операций управления экземпляром DB2 Все полномочия SYSMAINT.
Обновление реестров баз данных и узлов.
Создание баз данных (в том числе восстановлением из резервных копий).
Удаление существующих баз данных.
Прерывание пользовательских сессий.
Создание, удаление и изменение табличных пространств.
Размещение данных в любом табличном пространстве.
SYSMAINTПрава на выполнение операций обслуживания экземпляра DB2 Все полномочия SYSMON.
Резервное копирование баз данных и табличных пространств.
Восстановление существующей БД из резервной копии.
Запуск и остановка экземпляра.
Получение и изменение состояния табличных пространств.
Сбор отладочной трассировки.
Реорганизация таблиц.
Сбор статистик.
SYSMONПрава на выполнение мониторинга функционирования экземпляра DB2 Подключение к базам данных экземпляра.
Управление составом собираемой информации мониторинга.
Выборка информации мониторинга в виде снимков.
Таблица 2. Административные полномочия на уровне базы данных
ПолномочиеОписание полномочия
SECADMПрава на управление защитой базы данных, включая предоставление и отмену полномочий SECADM, DBADM, ACCESSCTRL, DATAACCESS. Возможность выдачи полномочий на доступ к объектам, владельцами которых являются другие пользователи. Полномочие SECADM не предполагает возможности чтения и записи данных.
DBADMПрава администрирования базы данных, без возможности доступа к хранимой информации. Сбор и анализ статистик, реорганизация данных, построение планов выполнения запросов.
ACCESSCTRLПредоставление и отмена любых полномочий и привилегий в рамках базы данных, за исключением полномочий SECADM, DBADM, ACCESSCTRL, DATAACCESS. Полномочие ACCESSCTRL не предполагает доступа к хранимой информации.
DATAACCESSПрава полного доступа к хранимой информации базы данных. Предоставляет возможность чтения и записи любой таблицы и представления, а также выполнения всех хранимых процедур и функций в рамках базы данных.
SQLADMМониторинг и настройка производительности SQL запросов.
WLMADMУправление политиками установки приоритетов и ресурсных ограничений для рабочих нагрузок.
EXPLAINПолучение планов выполнения запросов (без предоставления доступа к данным).
Таблица 3. Другие полномочия на уровне базы данных
ПолномочиеОписание полномочия
BINDADDВозможность создания новых пакетов, т.е. связывания статических SQL-операторов для работы программ, использующих статический SQL.
CONNECTПодключение к базе данных.
QUIESCE_CONNECTПодключение к приостановленной для обслуживания (quiesced) базе данных.
CREATETABСоздание новых таблиц в базе данных.
CREATE_EXTERNAL_ROUTINEСоздание внешних процедур (реализация которых представляет собой загружаемую динамическую библиотеку), выполняемых в защищенном (fenced) режиме.
CREATE_NOT_FENCED_ROUTINEСоздание внешних процедур, выполняемых в незащищенном (unfenced) режиме. Такие процедуры выполняются непосредственно в адресном пространстве DB2, что предъявляет высокие требования к качеству их реализации и уровню доверия к их разработчикам.
IMPLICIT_SCHEMAВозможность неявного (автоматического) создания пользователем схемы, совпадающей с его идентификатором пользователя, при попытке создании объекта базы данных без указания имени схемы.
LOADЗагрузка информации в таблицы базы данных с использованием оператора LOAD.
Таблица 4. Полномочия над таблицами и представлениями
ПолномочиеОписание полномочия
CONTROLПолный набор операций, включая возможность изменения определения, удаления, а также возможность назначения полномочий в отношении данного объекта другим пользователям.
Для предоставления привилегии CONTROL необходимо обладать административными полномочиями ACCESSCTRL и/или SECADM.
Владелец таблицы или представления неявно получает привилегию CONTROL.
В случае явного присвоения привилегии CONTROL пользователь также автоматически получает все остальные привилегии в отношении указанной таблицы. Для их отмены после отмены привилегии CONTROL рекомендуется использовать оператор REVOKE ALL ON tabname FROM USER username.
ALTERИзменение описания таблицы (не применимо к представлениям).
INDEXСоздание индексов над таблицей (не применимо к представлениям).
REFERENCESВозможность создания и удаления в других таблицах внешних ключей, ссылающихся на данную таблицу (не применимо к представлениям).
SELECTВыборка данных (использование в запросах и подзапросах).
DELETEУдаление записей. Возможность выполнения оператора DELETE над представлением зависит от характеристик представления (см. deletable view), либо от наличия INSTEAD-OF триггера.
INSERTВставка записей. Возможность выполнения оператора INSERT над представлением зависит от характеристик представления (см. insertable view), либо от наличия INSTEAD-OF триггера.
UPDATEОбновление записей. Возможность выполнения оператора UPDATE над представлением зависит от характеристик представления (см. updatable view), либо от наличия INSTEAD-OF триггера.
Таблица 5. Полномочия над программными объектами (процедурами, функциями, пакетами статических SQL-операторов)
ПолномочиеОписание полномочия
EXECUTE (routine)Право на выполнение функции или процедуры.
EXECUTE (package)Возможность запустить пакет статических SQL-операторов (т.е. запустить приложение, использующее статический SQL, в состав которого входит данный пакет).
BIND (package)Возможность пересвязать пакет (обновить планы выполнения) или добавить новую версию пакета.
CONTROL (package)Полный набор полномочий над пакетом с возможностью их передачи другим пользователям.
Для предоставления привилегии CONTROL необходимо обладать административными полномочиями ACCESSCTRL и/или SECADM.
Владелец пакета неявно получает привилегию CONTROL.
Таблица 6. Полномочия над другими видами объектов
ПолномочиеОписание полномочия
SETSESSIONUSERРазрешает пользователю, которому предоставлено полномочие, переключать идентификатор пользователя на указанный в полномочии, с помощью оператора SET SESSION AUTHORIZATION.
USE (tablespace)Размещение объектов в табличном пространстве. Неявно предоставляется владельцу табличного пространства.
CREATEINПраво на создание объектов в рамках схемы.
ALTERINПраво на изменение определения объектов в рамках схемы.
DROPINПраво на уничтожение объектов, существующих в рамках схемы.
CONTROL (index)Право на удаление индекса из базы данных. Автоматически предоставляется владельцу индекса.
ALTER (sequence)Изменение последовательности командой ALTER SEQUENCE.
USAGE (sequence)Обращение к последовательности выражениями NEXT VALUE и PREVIOUS VALUE.
USAGE (workload)Использование рабочей нагрузки.
Для рабочей нагрузки SYSDEFAULTUSERWORKLOAD привилегия USAGE предоставлена группе PUBLIC.
Для рабочей нагрузки SYSDEFAULTADMWORKLOAD привилегия USAGE предоставлена пользователям с полномочиями ACCESSCTRL, DATAACCESS, WLMADM, SECADM и DBADM, и не может быть предоставлена в явном виде каким-либо другим группам или пользователям.

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

Ролевое разграничение доступа

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

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

Применение механизма ролей обеспечивает следующие преимущества:

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

С ролью могут быть любые полномочия, управление которыми осуществляется в рамках базы данных, включая административные полномочия (DBADM, SECADM, …), полномочия уровня базы данных (CONNECT, CREATETAB, …) и любые привилегии над объектами базы данных (включая CONTROL).

В DB2 предоставленные пользователю роли (и ассоциированные с этими ролями полномочия) всегда автоматически включаются при подключении пользователя, необходимость вызова оператора SET ROLE для включения роли отсутствует. Оператор SET ROLE может быть использован приложением для проверки наличия у текущего пользователя необходимой роли.

Создание роли осуществляется с использованием оператора CREATE ROLE, ассоциирование полномочий с ролью осуществляется командой GRANT полномочие TO ROLE роль. Предоставление пользователю ролей выполняется командой GRANT ROLE роль TO USER пользователь.

Существует возможность создания иерархии ролей, путём включения одних ролей в другие (оператором GRANT ROLE роль1 TO ROLE роль2). При определении иерархии ролей в DB2 не допускается создание циклов.

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

Администратор защиты может делегировать управление созданной ролью другому пользователю с использованием оператора GRANT ROLE rolename TO USER username WITH ADMIN OPTION. Пользователь, которому делегировано управление ролью, имеет возможность предоставить данную роль другим пользователям либо отозвать ранее предоставленную роль.

Доверенные контексты и доверенные соединения

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

  • ограничить состав полномочий, доступных пользователю в сеансе работы с базой данных, в зависимости от характеристик соединения с базой данных;
  • обеспечить приложениям трехзвенной и многозвенной архитектуры возможность работать с базой данных от имени учетной записи конечного пользователя, обладающей правильным (минимально необходимым) набором привилегий – вместо типичного случая применения технологической учетной записи с полным (максимальным) набором привилегий.

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

  • разрешить подключение пользователей базы данных только с определенного набора IP-адресов;
  • исключить доступ к таблицам, содержащим чувствительную информацию, через сетевые соединения, не использующие шифрование;
  • разрешить администратору базы данных вход только с собственной рабочей станции либо локальный вход непосредственно на сервере СУБД.

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

Установление отношений доверия основано на анализе следующего набора атрибутов:

  • идентификатор пользователя, осуществляющего подключение к базе данных;
  • IP-адрес либо доменное имя компьютера, с которого осуществляется подключение;
  • признак использования шифрования информации при подключении к базе данных.

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

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

Установление доверенного соединения может быть запрошено приложением явно (с указанием соответствующего атрибута и/или путем использования специального программного вызова) или неявно (стандартным путем, без использования особых программных механизмов).

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

Наличие явно затребованного доверенного соединения дополнительно позволяет приложению:

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

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

Создание доверенных контекстов выполняется командой CREATE TRUSTED CONTEXT.

Механизм контроля доступа на уровне строк и колонок

Контроль доступа на уровне строк и колонок (Row and Column Access Control, RCAC) основан на использовании набора правил (строчные привилегии, колоночные маски), ограничивающих пользователям доступ к строкам и колонкам таблиц.

Правила контроля доступа на уровне строк и колонок применяются во всех случаях, вне зависимости от уровня доступа пользователей (включая пользователей с самыми высокими уровнями доступа СУБД). Управление правилами RCAC осуществляется администратором защиты (пользователем с административным полномочием SECADM).

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

Колоночная маска (column mask) – объект базы данных, определяющий правило контроля доступа к колонкам таблицы. Правило определяется в виде выражения SQL CASE, которое позволяет вычислить отображаемое значение колонки в зависимости от установленных ограничений.

Создание строчных привилегий осуществляется оператором CREATE PERMISSION. Строчные привилегии применяются только для тех таблиц, для которых активирован функционал построчного контроля доступа (ALTER TABLE … ACTIVATE ROW ACCESS CONTROL).

Создание колоночных масок осуществляется оператором CREATE MASK. Колоночные маски применяются только для тех таблиц, для которых активирован функционал контроля доступа по колонкам (ALTER TABLE … ACTIVATE COLUMN ACCESS CONTROL).

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

Примеры использования механизма контроля доступа на уровне строк и колонок приведены в соответствующем разделе документации DB2.

Механизм контроля доступа на основе меток конфиденциальности

Согласно требованиям ФСТЭК России, мандатное управление доступом являются ключевым отличием систем защиты Государственной Тайны РФ старших классов 1В и 1Б от младших классов защитных систем на классическом разделении прав по матрице доступа. Мандатное управление доступом в DB2 реализовано с помощью механизма контроля доступа на основе меток конфиденциальности.

Контроль доступа на основе меток конфиденциальности (Label Based Access Control, LBAC) основан на построении системы классификации данных с точки зрения их секретности. Объектам доступа (таблицам, колонкам, записям) присваиваются метки конфиденциальности, соответствующие присвоенной категории в принятой системе классификации. Пользователям (субъектам доступа) предоставляются полномочия доступа к данным в виде разрешений на обращение к информации соответствующего уровня конфиденциальности.

При первоначальной настройке LBAC администратор защиты (пользователь с полномочием SECADM) создает компоненты меток конфиденциальности (security label components). Компонента метки конфиденциальности – это объект базы данных, характеризующий (атрибутирующий) объект доступа с точки зрения уровня его конфиденциальности.

Допустимы следующие виды компонентов меток конфиденциальности:

  • список (ARRAY) – линейный набор возможных значений, упорядоченный в соответствии с уровнями конфиденциальности (первый элемент имеет наивысший уровень конфиденциальности);
  • множество (SET) – неупорядоченный набор возможных значений, уровень конфиденциальности всех элементов считается одинаковым;
  • дерево (TREE) – иерархически организованный набор возможных значений, уровень конфиденциальности определяется положением в иерархии, корневой элемент имеет наивысший уровень конфиденциальности.

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

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

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

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

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

Настройка LBAC завершается применением политики безопасности к объектам доступа. Для защищаемых таблиц активируется созданная политика безопасности (оператором ALTER TABLE … ADD SECURITY POLICY …). В отношении колонок защищаемых таблиц устанавливаются метки конфиденциальности (оператором ALTER TABLE … ALTER COLUMN … SECURED WITH …). Для обеспечения разграничения доступа к строкам таблицы в данную таблицу необходимо добавить дополнительную колонку типа DB2SECURITYLABEL, и установить значение этой колонки исходя из содержимого данной таблицы (в случае, если таблица уже содержит данные).

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

Более подробная информация о настройке и применении LBAC приведена в документации.

Аудит доступа

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

Аудит может осуществляться как на уровне экземпляра СУБД, так и на уровне отдельных баз данных, с ведением раздельных журналов аудита.

Настройка аудита на уровне экземпляра производится системным администратором (пользователем с полномочием SYSADM) с использованием утилиты db2audit. Данная утилита также используется для архивирования журналов аудита и для выгрузки журналов аудита из архивов.

Подсистема аудита DB2 функционирует независимо от экземпляра, и обычно остается активной даже при остановке сервера СУБД.

Администратор защиты (пользователь с полномочием SECADM) использует создаваемые им политики аудита и оператор AUDIT для настройки и контроля параметров аудита на уровне базы данных. Также администратор защиты может использовать комплект встроенных хранимых процедур DB2 для решения следующих задач:

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

Администратор защиты также может предоставить права на выполнение указанных действий другому пользователю базы данных.

Средства аудита DB2 обеспечивают фиксацию следующих категорий событий аудита:

  • AUDIT – изменение настроек аудита и доступ к журналу аудита;
  • CHECKING – проверка авторизации на выполнение доступа к объектам защиты;
  • OBJMAINT – создание и удаление объектов базы данных, изменение описания объектов;
  • SECMAINT – изменение полномочий на доступ к объектам базы данных;
  • SYSADMIN – выполнение операций, требующих полномочий SYSADM, SYSMAINT или SYSCTRL;
  • VALIDATE – аутентификация пользователей или получение информации защиты;
  • CONTEXT – дополнительные записи с контекстуальной информацией, используемой для облегчения интерпретации других видов данных аудита;
  • EXECUTE – выполнение SQL запросов.

Для событий перечисленных категорий возможен аудит успешного и/или неуспешного выполнения.

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

  • база данных в целом – сбор событий указанного вида в рамках базы данных;
  • таблицы – сбор событий указанного вида в отношении указанных таблиц;
  • доверенные контексты – сбор событий указанного вида в рамках указанного доверенного контекста;
  • пользователи, группы или роли – сбор событий указанного вида, инициированных соответствующими пользователями;
  • системные полномочия (SYSADM, SECADM, DBADM, SQLADM, WLMADM, ACCESSCTRL, DATAACCESS, SYSCTRL, SYSMAINT, SYSMON) – сбор событий указанного вида, инициированных пользователями с соответствующими полномочиями.

Для конкретного объекта может быть установлена только одна действующая политика аудита.

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

Данные аудита могут быть загружены из файлов аудита в таблицы базы данных для проведения анализа. Создание необходимых таблиц может быть выполнено скриптом db2audit.ddl, поставляемым с DB2. Описание полей записей аудита приведено в документации.

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

  1. Данные аудита выгружаются в текстовом формате посредством команды db2audit extract либо с использованием хранимой процедуры AUDIT_DELIM_EXTRACT().
  2. Выполняется загрузка данных аудита в созданные таблицы с использованием набора команд, приведенных в специальном разделе документации DB2:
    • LOAD FROM audit.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.AUDIT
    • LOAD FROM checking.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.CHECKING
    • LOAD FROM objmaint.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.OBJMAINT
    • LOAD FROM secmaint.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.SECMAINT
    • LOAD FROM sysadmin.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.SYSADMIN
    • LOAD FROM validate.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.VALIDATE
    • LOAD FROM context.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.CONTEXT
    • LOAD FROM execute.del OF DEL MODIFIED BY DELPRIORITYCHAR LOBSINFILE INSERT INTO schema.EXECUTE

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

Существуют продукты (как компании IBM, так и других производителей программного обеспечения), обеспечивающие консолидацию и обработку данных аудита DB2, а также поддерживающие совместный анализ данных аудита из различных источников (например, различные типы СУБД, сервера приложений, операционные системы).

Более подробная информация о настройке и применении средств аудита DB2 приведена в документации.

Заключение

В данной статье были рассмотрены возможности средств разграничения и контроля доступа к данным, предоставляемые продуктами семейства IBM DB2 for Linux, Unix and Windows, включая методы аутентификации пользователей, состав поддерживаемых полномочий, возможности гранулярного (на уровне отдельных колонок и строк) и мандатного (с использованием меток безопасности) разграничения доступа, а также функции аудита доступа к информации.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


  • Bluemix

    Узнайте больше информации о платформе IBM Bluemix, создавайте приложения, используя готовые решения!

  • Библиотека документов

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management, Большие данные и аналитика
ArticleID=1036507
ArticleTitle=Обзор DB2 LUW, Часть 5: Функции разграничения и контроля доступа IBM DB2 LUW
publish-date=08242016