Административные средства защиты информации в БД

БД, обладает набором возможных действий.
Например, для объекта типа таблица возможны

следующие операции: SELECT, INSERT, DELETE и UPDATE.
При этом операции INSERT и UPDATE можно ограничить только конкретными столбцами.
Права доступа (привилегии, полномочия) определяются набором действий, которые разрешено выполнять с какими-то объектами.

полномочий.
Введение понятия «роль» позволяет упростить управление привилегиями пользователей и

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

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

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

который создавал этот объект).
Владельцу может предоставляться право передавать другим пользователям

полномочия по работе со своими объектами.
Операторы языка SQL для управления полномочиями
Оператор предоставления полномочий имеет следующий синтаксис:

GRANT { 〈список_действий〉 ⎜ ALL PRIVILEGES }
ON 〈имя_объекта〉
ТО { 〈список_пользователей〉 ⎜ PUBLIC }
[ WITH GRANT OPTION ]

объекта, указанного в разделе ON.
Ключевое слово ALL PRIVILEGES указывает, что

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

причем он может передавать другим пользователям права на работу с

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

TO User2;
GRANT SELECT ON Tab1 TO User3;
При назначении полномочий по

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

другой пользователь User4 мог замещать его в случае отсутствия.
Тогда пользователь

User1, как владелец объекта Tab1, может предоставить пользователю User4 все права по работе с этой таблицей:

GRANT ALL PRIVILEGES
ON Tab1 TO User4
WITH GRANT OPTION;

В этом случае пользователь User4 получает право самостоятельно назначать привилегии по работе с Tab1 для других пользователей.

User5;
Тогда другому оператору (пользователь User5) предоставляется право вводить новые строки

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

GRANT SELECT, UPDATE, DELETE
ON Tab1 TO User4
WITH GRANT OPTION;

Какой результат в этом случае будет иметь предыдущая директива ????

защиты данных являются представления (views).
Эти объекты создаются для конкретных пользователей

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

REVOKE { 〈список_действий〉 ⎜ ALL PRIVILEGES }
ON 〈имя_объекта〉
FRОM { 〈список_пользователей〉 ⎜ PUBLIC }
{ CASCADE ⎜ RESTRICT }

отменяет привилегии по всей цепочке, которая возникает при передаче владельцем

своих прав другим пользователям.
Например, пусть введена следующая команда:

REVOKE ALL PRIVILEGES ON Tab1
FRОM User4 CASCADE

Тогда одновременно отменяются привилегии и пользователя User5, которому пользователь User4 успел передать свои права.

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

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

REVOKE ALL PRIVILEGES ON Tab1
FRОM User4 RESTRICT

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