Проектирование данных: Защита данных в DB2

Предоставляйте привилегии для чего-то, а не кому-то

Система безопасности на основе ролей, обеспечивающая защиту информационных активов организации, стала доступной, начиная с версии DB2 V9.5 для Linux®, UNIX® и Windows®(LUW), и DB2 9 для z/OS®. Однако многие пользователи еще не до конца понимают, когда использовать эту возможность. В данной статье Роберт Каттералл разъясняет цели и преимущества ролей и доверенных контекстов. Содержимое этой статьи является частью IBM Data Management Magazine.

Роберт Каттералл, специалист по IBM DB2, IBM

Роберт Каттералл (Robert Catterall) работает в IBM техническим консультантом по DB2 для платформы z/OS.



11.01.2013

Подпишитесь на журнал IBM Data Management

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

Система безопасности на основе ролей является отличным способом защитить информационные активы вашей организации и реализуется проще, чем вы думаете. DB2-роли и их близкие родственники доверенные контексты (trusted context) появились в версии DB2 9.5 для Linux, UNIX и Windows (LUW) и DB2 9 для z/OS. Но хотя эти версии были выпущены более трех лет назад, многие пользователи все еще не до конца осознают цели и преимущества ролей и доверенных контекстов. В данной статье я попытаюсь внести ясность в эти вопросы.

Более эффективный способ управления привилегиями в DB2

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

Подобное управление системой безопасности DB2 может принести большую пользу при работе по типичному сценарию клиент-серверных вычислений: приложение, работающее на сервере приложений Java или .NET (или других) выдает SQL-запросы, выполняемые на сервере базы данных DB2 (в среде DB2 для z/OS SQL-запросы, возможно, проходили бы через функциональность Distributed Data Facility, или DDF). Отдельные пользователи выполняют аутентификацию на сервере приложений, но само приложение предоставляет системе DB2 обобщенные пароль и идентификатор, жестко закодированные в программе.

Если SQL-выражения готовятся динамически на сервере DB2 (как это часто бывает с программами, использующими такие интерфейсы к базе данных как JDBC, ODBC или ADO.NET), обобщенному идентификатору авторизации приложения необходимо предоставить привилегии работы с таблицами (SELECT, INSERT, UPDATE, DELETE) для целевых объектов, чтобы запросы могли выполняться.

Но в таком случае многие программисты будут знать идентификатор авторизации приложения и пароль для DB2, поскольку, как уже отмечалось, они встроены в код программы. Потом кто-то из них может использовать этот идентификатор и его привилегии для доступа к данным в базе данных вне приложения, что существенно ослабит систему безопасности.


Полезная аналогия

Приведу аналогию из реального мира. Моя старшая дочь меньше года назад получила водительские права. Если бы я мог управлять ее вождением, используя что-то наподобие ролей и доверенных контекстов DB2, то, возможно, лучше контролировал бы ее доступ к нашим машинам. Я настроил бы все так, чтобы она использовала привилегию вождения только для поездок между домом и школой и только на минивэне (не на спортивном седане). Конечно, это несбыточная мечта для меня и, возможно, кошмарный сон для моей дочери.


Использование ролей и доверенных контекстов

Но в DB2 можно сделать что-то очень похожее, если вы используете DB2 9 для z/OS в новом функциональном режиме или DB2 10 для z/OS. Администраторы DB2 9.5 для LUW 9.7 и более новых версий имеют аналогичную возможность: вместо предоставления обобщенному идентификатору авторизации набора привилегий, необходимых для выполнения динамических SQL-запросов, мы можем предоставить привилегии для роли.

Но простое предоставление привилегий для роли почти ничего не означает. Почему? Потому что у DB2 нет возможности узнать, кем используются привилегии роли и в каких обстоятельствах эта роль используется.

Здесь на передний план выходит определение доверенного контекста. Доверенный контекст ограничивает применение ролевых привилегий к пользователям, подключающимся к DB2 с конкретного сервера приложений (идентифицируемого по IP-адресу) через приложение, предоставляющее DB2 определенный идентификатор авторизации, называемый "системным" идентификатором авторизации.

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


Но это еще не все!

Есть несколько вариантов:

  • При использовании IBM WebSphere Application Server можно распространить идентификационную информацию о конечном пользователе на DB2, установив свойство базы данных propagateClientIdentityUsingTrustedContext в значение true.
  • Существуют интерфейсы прикладного программирования для JDBC (например, getDB2Connection), CLI (атрибут SQL_ATTR_TRUSTED_CONTEXT_USERID и функции SQLSetConnectAddr) и .NET (где ключевое слово UserID строки подключения соответствует идентификатору конечного пользователя), которые могут использоваться приложением для установки доверенного соединения с DB2, повторного использования доверенного соединения с идентификатором другого конечного пользователя и распространения идентификатора этого конечного пользователя на сервер DB2.
  • Если инициатором запроса является DB2 для z/OS, можно предоставить "системный" идентификатор авторизации для доверенного соединения в базе данных соединений инициатора запроса (в частности, в таблице SYSIBM.USERNAMES). Идентификаторы пользователей будут распространяться на сервер DB2, так как доверенное соединение используется повторно.

Данная функциональность не только позволяет назначить ролевые привилегии определенным пользователям конкретного доверенного соединения, но и получить контрольную информацию DB2 (и Resource Access Control Facility, или RACF), содержащую индивидуальные идентификаторы пользователей. Она работает даже тогда, когда эти пользователи подключаются к DB2 через приложение, которое само предоставляет обобщенный идентификатор авторизации при установке соединений с DB2.

Отправив идентификаторы конечных пользователей в DB2 с сервера приложений, можно получить еще более тонко настраиваемый доступ к ролям, ассоциированным с данным доверенным контекстом. Например, доверенный контекст может иметь роль по умолчанию ROLE_A. Если предположить, что приложение, для которого определяется доверенный контекст, распространяет идентификационную информацию о конечных пользователях в DB2, можно указать, что другую роль, ROLE_B, может использовать для доверенного соединения конечный пользователь SMITH, добавив WITH USE FOR SMITH ROLE ROLE_B в выражение CREATE TRUSTED CONTEXT. Если для использования пользователем SMITH роли ROLE_B требуется аутентификационная информация (например, пароль), нужно добавить WITH AUTHENTICATION в предыдущий оператор WITH USE FOR.

Обратите внимание, что отсутствие оператора WITH USE FOR в выражении CREATE TRUSTED CONTEXT равносильно указанию WITH USE FOR PUBLIC WITHOUT AUTHENTICATION. Это означает, что привилегии роли по умолчанию, ассоциированной с доверенным контекстом, доступны любому пользователю, который использует доверенное соединение, определенное доверенным контекстом.

В определении доверенного контекста можно даже указать, что инициатор запроса должен подключаться к DB2 по криптографическому протоколу Secure Sockets Layer (SSL). Просто сделайте ENCRYPTION 'HIGH' одним из атрибутов доверенного контекста. (ENCRYPTION 'LOW' соответствует 64-разрядному шифрованию DRDA.)

Теперь несколько важных замечаний о доверенных контекстах, о которых нужно помнить:

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

Заключение

Когда пользователь устанавливает доверенное соединение с подсистемой DB2 (в соответствии с определенным доверенным контекстом), он имеет привилегии ассоциированной роли плюс все привилегии, предоставленные непосредственно его идентификатору. Смысл в том, что роли и доверенные контексты ограничивают применение DB2-привилегий, только если эти привилегии не предоставлены большому числу идентификаторов авторизации пользователей DB2. Предполагается, что на определенном этапе использования ролей и доверенных контекстов вы начнете отменять (REVOKE) привилегии, ранее предоставленные идентификаторам отдельных пользователей (и/или идентификаторам группы RACF или эквивалентной группы).

Настроить систему безопасности, основанную на ролях, легче, чем кажется большинству пользователей. А поскольку организации стремятся к большему контролю над своей информацией, все более востребованным будет детализированный контроль активов данных, предоставляемый DB2. Это требование будущего. Усвойте это сейчас и будете во всеоружии.

Партнерские ресурсы
Applied Analytix, Inc DBIFourth Millennium Technologies
IBMIBM Client Reference ProgramIBM Information On Demand
International DB2 Users Group (IDUG)Informix ConferenceMelissa Data
NetezzaNiteo PartnersQuest Software
Relational Architects InternationalSafari Books Online

Ресурсы

Комментарии

developerWorks: Войти

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


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


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

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

 


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

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

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



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

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

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

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

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

 


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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=854669
ArticleTitle=Проектирование данных: Защита данных в DB2
publish-date=01112013