InterBase 5.0 вводит расширение в безопасность SQL, называемое роли SQL. Роли осуществляют концепцию группового уровня защиты, а также действуют как шаблоны предопределенных наборов привилегий. SQL-роли - это расширение стандартного механизма безопасности SQL реализованного в InterBase. Роль определяет набор SQL-привилегий для одной или более таблиц в БД.
К примеру, программист должен принимать множество ролей на время жизни продукта. Изначально программист должен принять роль сотрудника маркетинга для определения продукта и его возможностей. Затем - роль разработчика на время проектирования продукта. В заключение, программист должен принять роль конечного пользователя и QA для обеспечения качества продукта. SQL-роли делают то же для безопасности БД.
Роль выступает в качестве группового шаблона для пользователей. В вышеупомянутом примере программист может быть одним или несколькими пользователями. Роли также позволяют пользователю принимать различные наборы привилегий. Роль сотрудника маркетинга имеет привилегии определенные для него, в то время как роль QA имеет совершенно другой набор привилегий.
Повторимся, роли - это как шаблон или набор привилегий. Сначала роль создается, потом для нее устанавливаются привилегии на объект БД. Пользователи получают право принимать роль во время подключения. При попытке подключения пользователь может определить роль, которую он примет когда подключится. При присваивании роли пользователь получает все привилегии назначенные данной роли.
Как сказано ранее, роли - это расширение базовой безопасности SQL. Привилегии присваиваются когда принимается роль, добавляются к привилегиям установленным непосредственно пользователю. Например, для роли TEST_ADMIN установлена привилегия INSERT на таблицу TEST_SCORES. USERA имеет привилегию SELECT и имеет право принимать роль TEST_ADMIN. Когда пользователь USERA подключается, определяя роль TEST_ADMIN, он имеет сложенные привилегии: INSERT и SELECT на таблицу TEST_SCORES.
SQL роли доступны в InterBase v5.0. Если модернизировать с предыдущей версии InterBase, необходимо сделать backup БД и восстановить ее на сервере с InterBase v5.0. Недостаточно просто переместить БД на сервер v5.0, нужны backup и restore для того, чтобы включить в БД поддержку SQL-ролей.
Здесь некоторые главные требования и условия для ролей:
Роли имеет несколько преимуществ над базовой моделью безопасности SQL. Эти преимущетсва делают их проще для DBA в администрировании безопасности БД. Как сказано раньше, роли обеспечивают весьма необходимый групповой уровень безопасности для InterBase. Поэтому DBA проще добавить защиту для нескольких пользователей. Также роли обеспечивают степень гибкости, которую нелегко достигнуть с базовой моделью безопасности SQL.
Пересмотрим пример с установкой безопасности для 100 пользователей в БД со 100 таблицами. С базовой SQL-безопасностью получается, что DBA должен выполнить 10000 команд GRANT для полной установки безопасности. При использовании ролей, в лучшем случае необходимо только 200 команд GRANT. Данная ситуация будет, если каждый пользователь получает одинаковые привилегии на все таблицы. В этом случае DBA устанавливает одну роль, для которой надо 100 команд GRANT. Для добавления 100 пользователей к роли потребуется дополнительно 100 команд GRANT, что в итоге эквивалентно 200 команд GRANT заявленных ранее. В общем случае потребуется 100x + 100 команд GRANT, где x равно количеству необходимых различных ролей. Если надо 5 ролей, тогда общее количество команд GRANT будет 600. Очевидно, что использование ролей делает установку безопасности на данной БД намного проще для DBA.
Роли также упрощают поддержание безопасности для существующей БД. Поскольку роли расширяют базовую SQL-безопасность, нет необходимости переконструировать защиту БД для использования ролей. Роли позволяют DBA оставить уже определенные привилегии нетронутыми и строить новые рядом с ними. Есть пара ключевых областей, где роли действительно делают работу DBA проще при поддержании безопасности существующей БД. Первая, роли позволяют легко добавить в БД новую привилегию пользователя. Второе, роли реализуют групповой уровень безопасности, который делает выполнимой работу по изменению существующих привилегий для большого числа пользователей.
С базовой моделью SQL-безопасности при добавлении пользовательских привилегий в БД необходимо установить привилегии пользователю для каждой таблицы БД. Роли работают как шаблоны при установке привилегий для новых пользователей. Роль может быть определена в БД для общего набора привилегий. При добавлении нового пользователя, DBA должен только предоставить ему право принимать роль, которая определяет необходимый пользователю набор привилегий.
Один распространенный метод, используемый DBA, при работе с базовой моделью безопасности SQL за неимением групп - предоставление привилегий одному общему пользователю и всем пользователям возможность подключения с одним именем пользователя. Этот способ делает установку и поддержание привилегий проще в управлении. Главный недостаток этого метода - каждый подключенный пользователь имеет одинаковое имя, и невозможно их различить. Для InterBase они как один пользователь, т.к. только по имени можно их различать. Использование ролей в качестве шаблонов облегчает данную проблему. В этом случае DBA также один раз устанавливает привилегии. Когда пользователи подключаются, они имеют свои уникальные имена, только еще добавляется роль которую они используют, что позволяет InterBase поддерживать привилегии безопасности, и вто же время различать отдельных пользователей. Есть только два различия между использованием ролей и общего пользователя Первое, пользователи должны указывать роль при подключении. Второе, DBA должен предоставить всем пользователям право использовать роль.
Второе главное преимущество использования ролей - управление группами пользователей. Роли определены в концепции группового уровня защиты. Роли позволяют DBA управлять привилегиями целых групп пользователей, а не одним пользователем за раз как в базовой модели SQL-безопасности. Когда DBA изменяет привилегии роли, то действующие привилегии всех пользователей изменяются также. Привилегии изменяются для целой группы, каждого кто имеет право использовать роль.
Например, роль FULL_ACCESS определена с привилегией ALL на таблицу TEST_SCORES.
SQL create table test_scores (i1 integer); SQL create role FULL_ACCESS; SQL grant all on test_scores to full_access; SQL show grant test_scores; GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON TEST_SCORES TO FULL_ACCESSПользователи TEST и TEST2 имеют привилегию использовать эту роль.
SQL grant FULL_ACCESS to TEST; SQL grant FULL_ACCESS to TEST2;Пользователи TEST и TEST2 теперь имеют ALL-привилегию на таблицу TEST_SCORES, когда они подключаются присваивая роль FULL_ACCESS. Если TEST или TEST2 попробуют подключиться к БД без указания роли FULL_ACCESS, они не будут иметь привилегий на таблицу TEST_SCORES.
SQL connect \temp\employee.gdb user test password test; Database: \temp\employee.gdb, User: test SQL select * from test_scores; Statement failed, SQLCODE = -551 no permission for read/select access to table TEST_SCORES SQL connect \temp\employee.gdb user test password test role full_access; Database: \temp\employee.gdb, User: test, Role: full_access SQL select * from test_scores;Теперь DBA для изменения привилегий обоих пользователей TEST и TEST2, надо только изменить роль FULL_ACCESS. В примере привилегия INSERT удалена из роли. TEST и TEST2 могут использовать роль и имеют привилегии UPDATE, DELETE, SELECT, и REFERENCES на таблицу TEST_SCORES.
SQL show grant test_scores; GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON TEST_SCORES TO FULL_ACCESS SQL revoke insert on test_scores from full_access; SQL show grant test_scores; GRANT DELETE, SELECT, UPDATE, REFERENCES ON TEST_SCORES TO FULL_ACCESS SQL connect \temp\employee.gdb user test password test role full_access; Database: \temp\employee.gdb, User: test, Role: full_access SQL select * from test_scores; SQL insert into test_scores values (96); Statement failed, SQLCODE = -551 no permission for insert/write access to table TEST_SCORESВыборка, хотя записей не вернула, прошла успешно. Вставка, однако, вернула сообщение об ошибке (нет прав). Хотя в данном примере демонстрируется группа только с 2 пользователями, этот же пример может быть легко расширен с включением сотен пользователей.
Роли позволяют пользователю изменять назначенные привилегии, принимая разные роли при подключении к БД. Это позволяет защищать БД, предоставляя гибкость при изменении потребностей пользователей. Вернемся к представленному ранее примеру с жизненным циклом продукта и рассмотрим как роли добавляют гибкости, необходимой в данном сценарии. Для каждой роли, принимаемой программистом, установлен набор привилегий. Когда программист принимает роль маркетинга, он не имеет привилегий предоставленных разработчику. Также как, когда программист работает в роли разработчика, он не имеет привилегий роли QA.
Переместив этот пример в область БД, будут определены три роли: маркетинг, разработка и QA. Каждая роль будет иметь свой собственный набор привилегий на таблицы в БД. Когда пользователь подключается к БД используя одну из ролей, он будет иметь только привилегии установленные для данной роли.
Роли также обеспечивают гибкость, т.к. они работают в сочетании с базовой моделью безопасности
SQL. Как разъяснялось ранее, совокупные привилегии пользователя накапливаются:
Совокупные привилегии = Привилегии непосредственно установленные для пользователя + Привилегии
установленные для используемой роли
Продолжая пример о жизненном цикле продукта, предположим, что пользователь BJONES имеет привилегии использовать роль QA. Каждый месяц BJONES ответственен за сбор всех изменений кода разработчиками. Пока BJONES имеет только привилегии на использование роли AQ, он не может получить доступ к таблицам, которые используются разработчиками. DBA не хочет давать BJONES привилегии на использование роли разработчикаe, т.к. привилегии BJONES требуют подмножество всех привилегий, которые даны роли разработчика. DBA может явно предоставить привилегии на подмножество таблиц непосредственно для BJONES. Когда BJONES подключается используя роль QA, он будет иметь доступ как к таблицам разработчиков так и к таблицам QA, в связи со свойством сочетания ролей с базовой моделью безопасности SQL. BJONES имеет привилегии предоставленные посредством роли плюс все привилегии, которые непосредственно ему установил DBA.
| Привилегии SQL | Содержание | Использование ролей |