Использование ролей

Создание роли

Для создания роли надо использовать оператор CREATE ROLE. По умолчанию, роль не имеет привилегий после создания. Для роли следует установить привилегии на объекты БД, перед тем как она получит к ним доступ. Любой пользователь может создать роль без привилегий. Для определения роли и сохранения ее, необходимо подключиться к БД. Вот пример создания роли:
CREATE ROLE FULL_ACCESS;

Предоставление роли привилегий

Когда роль создана, она не имеет привилегий на объекты БД, пока доступ не будет установлен непосредственно. Это следует из модели безопасности SQL. Для предоставления привилегий роли надо использовать оператор GRANT. Основной синтаксис предоставления привилегий для роли:
GRANT <privileges> ON [TABLE] {tablename | viewname} TO rolename;

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

• SYSDBA
• Владелец таблицы или представления
• Пользователь, имеющий право предоставления привилегий для данной таблицы или представления (WITH GRANT OPTION)

Предоставление доступа к роли для пользователя

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

Синтаксис предоставления роли пользователю:
GRANT {rolename [, rolename ...]} TO {PUBLIC | {[USER] username [, [USER] username ...]} } [WITH ADMIN OPTION];

WITH ADMIN OPTION устанавливает разрешение предоставлять роль другим пользователям. Если это добавить в конце оператора, то данный пользователь может предоставлять роль другим. Например, если USERA получает право на роль DEVELOPER с установкой WITH ADMIN OPTION, то USERA может предоставлять роль DEVELOPER другим пользователям.

Следующий пример создает роль FULL_ACCESS, устанавливает все привилегии на таблицу TEST_SCORES для этой роли и предоставляет доступ к роли пользователю BJONES.

CREATE ROLE FULL_ACCESS;
GRANT ALL ON TEST_SCORES TO FULL_ACCESS;
GRANT FULL_ACCESS TO BJONES;

SQL connect \temp\employee.gdb user bjones password bjones;
Database: \temp\employee.gdb, User: bjones
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 bjones password bjones role full_access;
Database: \temp\employee.gdb, User: bjones, Role: full_access
SQL select * from test_scores;

Присвоение роли

Мы уже затрагивали данный вопрос. Когда пользователь подключается к БД, он может принять роль, указывая ее в строке подключения. Только здесь он может указать принимаемую роль. InterBase не предоставляет пользователю способа для переключения ролей, оставаясь подключенным к БД. Пользователь должен отключиться и подключиться опять с новой ролью.

Типичная ошибка: Наиболее частое неправильно представление о роли - что, когда пользователю предоставлено право на роль, то он сразу имеет все привилегии данной роли. Это неверно. Чтобы получить эти привилегии, пользователь должен указать роль во время подключения к БД. Если он не указывает роль при подключении, то не имеет привилегий, которые предоставлены роли.

Вот пример подключения пользователя BJONES к БД с присвоением роли FULL_ACCESS. В этом примере пользователь ипользует ISQL, InterBase's interactive SQL processing utility.
SQL connect \temp\employee.gdb user bjones password bjones role full_access;
Database: \temp\employee.gdb, User: bjones, Role: full_access

Пример подключения этого же пользователя, но с использованием DSQL:

File: sampleapi.c
#include <stdio.h>
#include <string.h>
#include "ibase.h"

int main()
{
  ISC_STATUS isc_status[20];
  isc_db_handle db_handle;
  char *dpb;
  short dpb_length;
  int i;

/* clear database handle */
  db_handle = 0L;
/* add dpb version to dpb */
  dpb = (char *)0;
  dpb_length = 0;
/* add user, password, and role to dpb */
  isc_expand_dpb(&dpb, &dpb_length,
                 isc_dpb_user_name, "bjones",
                 isc_dpb_password, "bjones",
                 isc_dpb_sql_role_name, "full_access",
                 NULL);
/* attach to database */
  isc_attach_database(isc_status, 0, "testdb.gdb", &db_handle, dpb_length, dpb);
}

Аннулирование привилегий роли

Аннулировать привилегии роли, для которой они установлены, можно командой REVOKE. Если привилегии роли отменены, все пользователи, имеющие на нее право, больше не будут иметь этих привилегий. Синтаксис аннулирования привилегий роли:
REVOKE <privileges> ON [TABLE] tablename FROM rolename;
Пример, отменяющий привилегию INSERT на таблицу TEST_SCORES для роли FULL_ACCESS.
REVOKE INSERT ON TEST_SCORES FROM FULL_ACCESS;

Отмена пользователю доступа к роли

Как роль может быть предоставлена пользователю, так и аннулирована. Если роль аннулирована для пользователя, значит он больше не может при подключении указывать эту роль. Этот пользователь больше не имеет привилегий установленных для роли. Синтаксис аннулирования роли для пользователя:
REVOKE rolename FROM username;
В следующем примере аннулируется доступ пользователя Bjones к роли FULL_ACCESS. BJones больше не сможет подключаться с указанием роли FULL_ACCESS.
REVOKE FULL_ACCESS FROM BJONES;

Удаление роли

Когда роль больше не нужна, она может быть удалена из БД. Удалить роль может SYSDBA или создатель роли. Если роль удалена, все привилегии предоставленные ей удаляются из БД. Синтаксис удаления роли:
DROP ROLE rolename;
Следующий пример удаляет роль FULL_ACCESS:
DROP ROLE FULL_ACCESS;

Где и как поддерживаются роли

Для того чтобы роли были действительны, клиентское приложение должно иметь возможность определить роль во время подключения к БД. Первый шаг для InterBase - дать возможность использовать роли при подключении к БД. Второй шаг для инструментария разработчика - использовать один из методов предоставляемых InterBase для предоставления ролей в клиентском приложении. Эти два шага делают возможным использование ролей конечными пользователями в приложении доступа к БД.

InterBase обеспечивает три интерфейса для ролей

InterBase позволяет клинтским приложениям и инструментариям разработчика использовать роли SQL. InterBase поддерживает роли через собственный API, встроенный SQL, и интерактивные интсрументы запросов. Все инструменты построенные с использованием одного из этих методов доступа могут поддерживать роли.

Собственный API InterBase - это набор функций, позволяющих разработчику программно конструировать и посылать SQL запросы серверу и получать результат. Вся работа с БД может выполняться через вызовы API. InterBase API обеспечивает наиболее гибкий и производительный способ доступа. Гибкость и производительность достигается посредством использования интерфеса низкого уровня. API возлагает на разработчика управление многими сложными аспектами при работе с сервером. Разработчик должен создавать и заполнять основные структуры данных, которые скрыты в других высокоуровневых интерфейсах.

Следующий пример использует API сервера InterBase для подключения к БД. Роль FULL_ACCESS используется для подключения, таким образом, пользователь BJONES имеет привилегии установленные для этой роли.

File: sampleapi.c
#include <stdio.h>
#include "ibase.h"

int main()
{
  ISC_STATUS isc_status[20];
  isc_db_handle db_handle;
  char *dpb;
  short dpb_length;
  int i;

/* clear database handle */
  db_handle = 0L;
/* add dpb version to dbp */
  dpb = (char *)0;
  dpb_length = 0;
/* add user, password, and role to dpb */
  isc_expand_dpb(&dpb, &dpb_length,
                 isc_dpb_user_name, "bjones",
                 isc_dpb_password, "bjones",
                 isc_dpb_sql_role_name, "full_access",
                 NULL);
/* attach to database */
  isc_attach_database(isc_status, 0, "testdb.gdb", &db_handle, dpb_length, dpb);
}

Встроенный SQL позволяет пользователю встраивать запросы SQL в приложение, и предоставляет разработчику простой путь для выполнения их без изучения сложностей InterBase API. Многие сложности операций выделения памяти и структур данных скрыты от разработчика. Компромисом при использовании встроенного SQL является то, что разработчик не имеет большой гибкости или контроля при работе с сервером.

Следующий пример подключается к БД testdb.gdb, используя роль FULL_ACCESS. После подключения производится вставка в таблицу TEST_SCORES.

File: sampleesql.e
#include <stdio.h>

EXEC SQL
  SET DATABASE db = "testdb.gdb";

int main()
{
  EXEC SQL
    CONNECT db USER "bjones" PASSWORD "bjones" ROLE "full_access";
  EXEC SQL
    INSERT INTO TEST_SCORES VALUES ("History", 83, "Bobby", "Jones");
  EXEC SQL
    COMMIT;
  return;
}

InterBase предоставляет разработчикам интерактивные утилиты для работы с БД. ISQL и WISQL обеспечивают разработчикам интерфейс для легкого ввода команд SQL на выполнение в БД. ISQL - команднострочная утилита, а WISQL - версия той же утилиты, но с графическим интерфейсом. И ISQL и WISQL обрабатывают детали управления транзакциями и командами. Пользователь должен только ввести команду SQL для выполнения. Обе версии интсрументария также позволяют выполнять скрипты содержащие SQL-запросы к БД.

Вот пример скрипта ISQL, который подключается к БД testdb.gdb, используя роль FULL_ACCESS.

File: sampleisql.sql
connect "testdb.gdb" user "bjones" password "bjones" role "full_access";
select * from test_scores;
commit;

Ниже представлен диалог подключения WISQL. Для указания роли подключения к БД есть отдельное поле ввода.

Более подробное описание InterBase API, встроенного SQL и интерактивных утилит InterBase можно найти в InterBase Operations Guide.

Клиенты InterBase должны выполнять свои обязанности

Второй шаг в процессе использования ролей - это отвественность клиентского инструментария. Клиентский инструментарий должен позволять приложениям использовать роли. Недостаточно просто просто предоставить интерфейс для ролей на сервере InterBase. Клиентский инструментарий тоже должен поддерживать роли. Для работы приложения конечного пользователя с ролями обе части должны быть согласованы.

Роли делают защиту управляемой

В общем, защита БД - это необходимость. Стандартная модель безопасности SQL соответствует тербованиям защиты данных. Роли построены на стандартной модели и добавляют эффективности в управлении безопасностью. Роли предоставляют групповой уровень защиты, который отсутствует в стандартной модели безопасности SQL. Их использование делает жизнь проще.