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

Содержание

Слайд 2

Во многих современных СУБД вводится понятие «роли» как поименованного набора полномочий.

Во многих современных СУБД вводится понятие «роли» как поименованного набора полномочий.


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

Слайд 3

Пользователи обычно объединяются в группы, причем одному пользователю разрешается входить в

Пользователи обычно объединяются в группы, причем одному пользователю разрешается входить в

разные группы.

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

Слайд 4

Каждый объект в БД имеет владельца (обычно в лице пользователя, который

Каждый объект в БД имеет владельца (обычно в лице пользователя, который

создавал этот объект).

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

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

Слайд 5

Здесь 〈список_действий〉 определяет набор действий из допустимого перечня операций для объекта,

Здесь 〈список_действий〉 определяет набор действий из допустимого перечня операций для объекта,

указанного в разделе ON.

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

Слайд 6

Пример административного управления полномочиями Пусть пользователь User1 является владельцем объекта Tab1,

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

Пусть пользователь User1 является владельцем объекта Tab1, причем

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

Тогда администратор БД должен сделать следующие назначения: GRANT INSERT ON Tab1

Тогда администратор БД должен сделать следующие назначения:

GRANT INSERT ON Tab1 TO

User2;

GRANT SELECT ON Tab1 TO User3;

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

Слайд 8

GRANT SELECT, UPDATE(COST) ON Tab1 TO User3; Пусть пользователю User1 требуется,

GRANT SELECT, UPDATE(COST)
ON Tab1 TO User3;

Пусть пользователю User1 требуется, чтобы другой

пользователь User4 мог замещать его в случае отсутствия.
Тогда пользователь User1, как владелец объекта Tab1, может предоставить пользователю User4 все права по работе с этой таблицей:

GRANT ALL PRIVILEGES
ON Tab1 TO User4
WITH GRANT OPTION;

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

Слайд 9

Пусть, например, пользователь User4 ввел команду: GRANT INSERT ON Tab1 TO

Пусть, например, пользователь User4 ввел команду:

GRANT INSERT ON Tab1 TO User5;

Тогда

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

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

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

Слайд 10

Кроме непосредственного назначения прав по работе с таблицами, эффективным методом защиты

Кроме непосредственного назначения прав по работе с таблицами, эффективным методом защиты

данных являются представления (views).

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

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

Слайд 11

Здесь параметры CASCADE и RESTRICT определяют режим отмены привилегий. Режим CASCADE

Здесь параметры CASCADE и RESTRICT определяют режим отмены привилегий.

Режим CASCADE отменяет

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

REVOKE ALL PRIVILEGES ON Tab1
FRОM User4 CASCADE

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