Привилегии
Привилегии
Поскольку просмотр является объектом базы данных, он требует специальных привилегий для доступа к нему пользователя. Предоставляя привилегии к просмотру, можно дать пользователям очень детализированный доступ к отдельным столбцам и строкам таблиц, не давая им доступ к другим, более чувствительным данным, хранимым в базовых таблицах. В этом случае просмотру предоставляются привилегии к таблицам, а пользователям - привилегии к этому просмотру.
Привилегии владельца
Пользователь, который создает просмотр, становится его владельцем. При создании просмотра пользователь должен иметь соответствующие привилегии к базовым таблицам.
* Некоторые просмотры по своей природе являются просмотрами только для чтения (см. разд. "Просмотры только для чтения и изменяемые"). Для формирования просмотра только для чтения создателю нужны привилегии SELECT К каждой базовой таблице.
* Для изменяемых просмотров создателю нужны привилегии ALL К базовым таблицам.
В дополнение к этому владельцы базовых таблиц и других просмотров, к которым обращается создаваемый просмотр, должны предоставить все требуемые привилегии для доступа и модификации этих объектов через просмотр самому просмотру. То есть привилегии к этим базовым объектам должны быть предоставлены просмотру.
Владелец просмотра имеет к нему все привилегии, включая возможность предоставлять привилегии к нему другим пользователям, триггерам и хранимым процедурам.
Привилегии пользователя
Создатель просмотра должен предоставить соответствующие привилегии пользователям, хранимым процедурам и другим просмотрам, которым нужен доступ к этому просмотру. Пользователь может получить привилегии к просмотру без доступа к его базовым таблицам.
В случае изменяемых просмотров привилегии INSERT, UPDATE и DELETE должны быть предоставлены всем пользователям, которым нужно выполнять операции DML над базовыми таблицами через просмотр. И наоборот, предоставляйте пользователям только привилегию SELECT, если вы собираетесь создавать просмотр только для чтения.
Если пользователь уже имеет требуемые права к базовым объектам просмотра, он автоматически будет использовать те же права к просмотру.
! ! !
ВНИМАНИЕ! Чем меньше привилегий предоставлено пользователю, тем больше защищены объекты базы данных. При этом потенциально большое количество привилегий в иерархии может вызвать проблемы, если цепь будет разрушена удалением привилегий владельца просмотра. Учитывая привлекательность просмотров в качестве механизма защиты данных от просмотра ненужными людьми, системному администратору следует поддерживать документацию по всем предоставленным привилегиям.
. ! .
Подробное описание привилегий SQL см. в главе 35.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКЧитайте также
Владение таблицами и привилегии
Владение таблицами и привилегии Когда создается таблица, Firebird автоматически применяет к ним безопасность схемы по умолчанию. Человеку, который создает таблицу (ее владелец), назначаются к ней все привилегии SQL, включая право передавать привилегии другим пользователям,
Привилегии на ссылки
Привилегии на ссылки Firebird поддерживает безопасность SQL для всех объектов в базе данных. Каждый пользователь, за исключением владельца базы данных, пользователя SYSDBA или с системными привилегиями root, должен получить (при использовании GRANT) необходимые привилегии доступа к
Привилегии
Привилегии Чтение из таблиц и запись в таблицы являются привилегиями базы данных, управляемыми объявлениями, выполненными с помощью операторов GRANT и REVOKE (см. главу
Привилегии
Привилегии Поскольку просмотр является объектом базы данных, он требует специальных привилегий для доступа к нему пользователя. Предоставляя привилегии к просмотру, можно дать пользователям очень детализированный доступ к отдельным столбцам и строкам таблиц, не давая
Привилегии к объектам
Привилегии к объектам Когда для триггера, хранимой процедуры или просмотра нужен доступ к таблице или просмотру, достаточно, чтобы владелец объекта, к которому требуется доступ, сам объект или пользователь, использующий триггер, процедуру или просмотр, имел необходимые
Привилегии через роли
Привилегии через роли Процесс реализации ролей состоит из четырех шагов:1. Создание роли с использованием оператора CREATE ROLE.2. Назначение привилегий этой роли посредством GRANT привилегия то роль.3. Назначение роли пользователям посредством GRANT роль то пользователь.4. Задание
Отмена права предоставлять привилегии
Отмена права предоставлять привилегии Для отмены права у пользователя предоставлять конкретную привилегию, но сохранить у него эту привилегию, используйте REVOKE GRANT OPTION:REVOKE GRANT OPTIONFOR <привилегия> [, <привилегия> [,...]]ON <таблица> | <объект>FROM <пользователь>
6.5. Привилегии (права) пользователя
6.5. Привилегии (права) пользователя Теперь попробуем изменить привилегии (права) пользователя. Нажмите кнопку Change напротив поля Тип учетной записи (см. рис. 6.8). В открывшемся окне (рис. 6.9) вы можете выбрать тип учетной записи: Administrator (администратор) или Desktop user (обычный
КАФЕДРА ВАННАХА: Права, привилегии, паспортизация Интернета и фашизм
КАФЕДРА ВАННАХА: Права, привилегии, паспортизация Интернета и фашизм Автор: Ваннах МихаилОдним из привычных раздражителей является спам. С удивительным упорством роботы синтезируют имена организаций, имеющих шанс протолкнуться через фильтры (в случае со служителем