Модель безопасности СУБД IBM DB2

Система управления базами данных IBM DB2 начинает свое развитие в далеких 70-х годах и сейчас занимает прочное положение на рынке корпоративных СУБД, отвечая высоким требованиям к производительности, надежности, безопасности и масштабируемости. В частном секторе система DB2 не получила широкого распространения, несмотря на наличие бесплатной версии IBM DB2 Express. Возможно, именно из-за этого в Интернете не так много статей по поводу настройки и использования DB2.

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

Однако неподготовленному пользователю сложно с нуля разобраться во всем этом многообразии, поэтому некоторые важные аспекты будут рассмотрены в данной статье.

Точка входа

Точка входа в DB2 выглядит следующим образом: СУБД -> экземпляр (instance), который может быть привязан к определенному порту -> имя конкретной базы данных. Настройки безопасности могут быть изменены как в конкретном экземпляре, так и в конкретной базе данных.

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

Аутентификация – это первоочередной механизм безопасности, который применяется, когда вы пытаетесь соединиться с сервером DB2. При аутентификации проверяется корректность предоставляемых учетных данных. Главной особенностью в DB2 является то, что аутентификация пользователей производится только внешними плагинами. Внутренних пользователей, в отличие от Oracle или MS SQL Server, здесь не существует. Даже функция создания пользователя, которая есть в программе IBM Data Studio, на самом деле не создает пользователя, а назначает указанному пользователю привилегию на соединение с базой данных.

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

Просмотреть конфигурацию менеджера базы данных можно с помощью запроса к таблице sysibmadm.dbmcfg, но для этого нужно иметь доступ к любой из баз данных, что не всегда возможно. Если у вас есть локальный доступ к серверу, то можно открыть процессор командной строки (db2 или db2.exe в Windows), соединиться с экземпляром и выполнить следующие команды:

db2 => attach to db2inst1
db2 => get database manager configuration

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

Рассмотрим, каким образом выглядит перехваченная информация в Wireshark.


Переданные от клиента логин и пароль видны в пакете при просмотре EBCDIC.

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

Значение изменяется следующим образом:

db2 => attach to db2inst1
db2 => update database manager configuration using authentication server_encrypt
db2 => db2stop force
db2 => db2start

Пакет аутентификации при этом будет выглядеть так:


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

Пакет с запросом в Wireshark:


Пакет с ответом в Wireshark:


В случае, если для параметра AUTHENTICATION настроено значение DATA_ENCRYPT, то шифруются учетные данные пользователя, а также информация, передаваемая между клиентом и сервером.

Значение изменяется аналогично рассмотренному выше примеру:

db2 => attach to db2inst1
db2 => update database manager configuration using authentication data_encrypt
db2 => db2stop force
db2 => db2start

После этого передаваемые данные также будут шифроваться:


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

Если же вдруг по какой-то причине необходим такой тип аутентификации, то нужно учесть, что существует еще два дополнительных параметра, которые в конечном итоге влияют на то, как будет проходить проверка учетных данных пользователя. Это параметр trust_allclnts, с помощью которого можно указать, каких клиентов считать доверенными, и параметр trust_clntauth, определяющий, где проверять логин и пароль, если они были переданы при соединении. Оба этих параметра влияют на аутентификацию, только если параметр AUTHENTICATION имеет значение CLIENT.

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

Авторизация

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

Полномочия уровня конкретного экземпляра прописываются в конфигурации менеджера БД. Речь идет о следующих полномочиях:

• SYSADM (полномочия администратора системы)
• SYSCTRL (полномочия на управление системой)
• SYSMAINT (полномочия на обслуживание системы)
• SYSMON (полномочия на мониторинг системы)

Задаются данные привилегии с помощью указания той группы, в которую будет входить пользователь. Для этого используются следующие параметры файла dbmcfg (соответственно указанным выше полномочиям):

• SYSADM_GROUP
• SYSCTRL_GROUP
• SYSMAINT_GROUP
• SYSMON_GROUP

Легко получить список пользователей, которые входят в группу, средствами DB2 нельзя, нужно делать это в самой операционной системе или анализировать, в какие группы входит конкретный пользователь (запрос см. в «полезные запросы»).

При настройке DB2 обязательно необходимо проверить список пользователей, которым назначено полномочие SYSADM. Это полномочие позволяет управлять всеми объектами базы данных.

Полномочия конкретной базы можно посмотреть в представлении SYSCAT.DBAUTH. Нужно обратить внимание на привилегию CONNECTAUTH, которая определяет, будет у пользователя доступ к БД или нет, и привилегию NOFENCEAUTH, которая отвечает за создание неизолированных (not fenced) процедур и функций. Такие процедуры выполняются в адресном пространстве базы данных и, в случае ошибки, могут нарушить целостность базы данных и таблиц в ней.

Привилегии

Привилегии в DB2 могут быть выданы на различные объекты. Привилегии доступа к таблицам можно просмотреть в представлении SYSCAT.TABAUTH. Данные о типе выданной привилегии хранятся в отдельных колонках, в зависимости от самой привилегии (SELECTAUTH, DELETEAUTH и т. д.). При выдаче привилегии с помощью команды GRANT для привилегий REFERENCES и UPDATE можно также указать имена колонок, на которые будут распространяться данные привилегии. Информацию об этом можно посмотреть в представлении SYSCAT.COLAUTH
Привилегии подпрограмм (функций, процедур и методов) можно посмотреть в представлении SYSCAT.ROUTINEAUTH. Здесь все не совсем тривиально, в зависимости от полей SPECIFICNAME и TYPENAME привилегии могут быть выданы на все подпрограммы заданной схемы.

Пользователи, группы, роли

Все полномочия базы данных и различные привилегии могут быть выданы пользователям, группам или ролям. Существование пользователей, групп и членство пользователей в группах регулируется вне самой базы данных. В связи с этим желательно учитывать определенные рекомендации и знать некоторые тонкости при выдаче полномочий и привилегий. Не рекомендуется выдавать привилегии и полномочия базы данных, в особенности возможность соединения с базой данных (CONNECTAUTH), группам. Следует выдавать привилегии конкретным пользователям или ролям, которым это необходимо. Поддержка ролей появилась в DB2 начиная с версии 9.5. Управление членством в ролях производится внутри самой базы данных.

Также, в DB2 существует встроенная роль PUBLIC. Пользователю базы данных нет необходимости предоставлять роль PUBLIC: отозвать у пользователя роль PUBLIC невозможно. Когда привилегия предоставляется роли PUBLIC, фактически происходит предоставление привилегии всем пользователям базы данных. Не следует выдавать какие-либо полномочия базы данных роли PUBLIC. Привилегии на таблицы и представления стоит выдавать с крайней осторожностью, только на просмотр и без возможности переназначения (WITH GRANT OPTION).

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

SELECT authid FROM sysibmadm.authorizationids WHERE authidtype = 'U' AND authid NOT IN (SELECT username FROM TABLE(sysfun.USERS()) AS W)

Для поиска подобных групп используется аналогичный запрос, но при этом в запросе указывается, что данные о PUBLIC выводить не нужно:

SELECT authid FROM sysibmadm.authorizationids WHERE authidtype = 'G' AND authid NOT IN (SELECT groupname FROM TABLE(sysfun.groups()) AS W) AND authid != 'PUBLIC'

LBAC

В DB2 есть мощный механизм разграничения доступа к данным в таблицах на основе меток (Label-based access control). Механизм позволяет установить метки защиты на конкретные строки или столбцы таким образом, что пользователь, у которого нет доступа к защищенным данным, не будет даже знать об их существовании. Нет смысла подробно рассказывать о методах реализации LBAC, так как у производителя есть учебное руководство по этой теме:

www.ibm.com/developerworks/ru/edu/dm0605wong/index.html

Автоматические средства сканирования

При настройке безопасности сервера IBM DB2 важным моментом является использование каких-либо сканеров безопасности (например, NGS SQuirreL for DB2, MaxPatrol и т. п.). Сканеры явно укажут на уязвимости настроек, которые вы могли пропустить, или выведут информацию в удобном для анализа виде:
NGS SQuirreL for DB2:

MaxPatrol:

Полезные запросы и команды

Получить настройки менеджера базы данных:
select name, value from sysibmadm.dbmcfg
либо
db2 => get dbm cfg

Изменить параметр менеджера базы данных:
db2 => update database manager configuration using
После этого необходим перезапуск экземпляра:
db2 => db2stop force
db2 => db2start

Получить настройки базы данных:
select name, value from sysibmadm.dbcfg
либо
db2 => get db cfg for

Список пользователей операционной системы:
select username from table(sysfun.USERS()) AS t

Список групп операционной системы:
select groupname from table(sysfun.GROUPS()) AS t

Вывести авторизационные идентификаторы (пользователей, групп или ролей, которым назначались привилегии):
select AUTHID, AUTHIDTYPE from sysibmadm.AUTHORIZATIONIDS

Вывести текущее имя базы данных:
select current server from sysibm.sysdummy1

Ввести текущее имя пользователя:
select user from sysibm.sysdummy1

Получить список групп, в которые входит пользователь:
select GROUPNAME from table(sysfun.groups_for_user('<username>')) as t

Список всех установленных СУБД:
$ db2ls

Список всех экземпляров в СУБД:
$ db2ilist

Ограничить количество выводимых строк:
select * from tabname fetch first 5 rows only