отчеты посредством пакетной очереди. Механизм, используемый для реализации этой схемы, зависит от того, какой планировщик пакетов используется в данной среде. Такое управление должно осуществляться как на этапе передачи заданий, так и во время выполнения. Проверку следует выполнять при передаче, потому что бессмысленно разрешить пользователям передавать задания, которые затем не будут выполнены из-за того, что у пользователя недостаточно прав. Однако в целях повыщения уровня безопасности эту проверку следует также производить во время выполнения - на случай, если кто-то сумел проникнуть через систему передачи.

Пакетные процессы, включая процессы, генерирующие отчеты, не всегда могут работать, используя только бюджет запускающего их пользователя. Даже если у пользователя есть разрещение на выполнение задания, он может не знать пароль базы данных, дающий достаточные привилегии для доступа к некоторым нужным таблицам. Вопрос о том, знают ли пользователи о паролях базы данных, используемых от их имени,- приобретает важное значение на тех узлах, где конечным пользователям доступен SQL*Plus.

Мы не перестаем удивляться тому, сколько существует узлов, на которых не обеспечена защита важнейших пакетных заданий на обновление данных от выполнения их неуполномоченными пользователями. Если вы опасаетесь, что пользователи-мошенники могут навредить вам, работая в интерактивном режиме, то представляете, что они могут сделать, если получат возможность инициировать массовое обновление, используя собственные драйверные файлы.

Безопасность данных

Если мы уверены, что подключаться к нашей базе данных могут лишь уполномоченные пользователи и что они могут запускать только те модули, на выполнение которых им явно предоставлено право, то нужно подумать о следующем уровне безопасности - ограничении доступа этих пользователей к данным.

Огромным шагом вперед в обеспечении безопасности данных стало введение ролей в Oracle?. До Oracle? каждому пользователю приходилось явно предоставлять права доступа к каждому объекту базы данных, который ему разрешено было использовать. Этот процесс упрощается за счет того, что доступ к совокупности объектов предоставляется роли, а затем право на использование этой роли предоставляется соответствующим лицам. С помощью команды GRANT мы можем предоставить пользователям право выполнять над объектами БД (например, над таблицами) операции SELECT, INSERT, UPDATE и DELETE. Однако само по себе это не обеспечивает значительной гибкости. Мы можем ограничить доступ пользователей частями таблицы, разделив ее по горизонтали (ограничив пользователя определенными строками), по вертикали (ограничив его определенными столбцами) или и по горизонтали, и по вертикали. Как это сделать?

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

пользователей так, чтобы они могли видеть только записи о сотрудниках их отдела. Видимая часть таблицы выделена в табл. 10.1 серым цветом.

Таблица 10.1. PAYROLL

Мы можем определить представление и предоставить пользователям доступ к этому представлению, а не к базовой таблице (PAYROLL). Они смогут запрашивать данные этой таблицы лишь через представление, которое ограничивает их доступ. Определение такого представления приведено ниже.

CREATE VIEW v payroll AS SELECT id

, name

, dept

, payment period FROM payroll WHERE dept = (SELECT dept

FROM mysys users WHERE username = USER) WITH CHECK OPTION;

Столбец SALARY в этом примере не включен в представление, поэтому зарплату в нем увидеть нельзя, а фраза WHERE гарантирует, что пользователи смогут запрашивать данные из таблицы PAYROLL только по своему отделу.

По поводу этого решения надо сказать следующее. Во-первых, мы должны сделать так, чтобы пользователи не могли изменить свой отдел, обновив значение MYSYS USERS, и затем запросить записи из другого отдела. Во-вторых, с помощью этого представления пользователи могли бы обновлять, вставлять и удалять даже не относящиеся к их отделу строки таблицы PAYROLL, если бы мы не отключили эту функцию с помощью фразы WITH CHECK OPTION.

Примечание

Вряд ли представление V PAYROLL будет обновляемым, потому что к столбцу SALARY почти наверняка применено ограничение NOT NULL. Тем не менее, мы рекомендуем использовать опцию WITH CHECK OPTION во всех ограничивающих представлениях, так как в версии 7.3 значительно увеличилось число обновляемых представлений.

Ограничение на просмотр данных с помощью представлений работает очень хорощо. Но для большой таблицы со сложными требованиями к безопасности, возможно, придется создать несколько представлений и заставить приложения решать, какое из них необходимо для конкретного пользователя. Реализовывать это внутри приложения нежелательно, поэтому нужно исследовать другие решения. Мы можем инкапсулировать все операции над таблицей PAYROLL в хранимый пакет или же разработать несколько триггеров. Давайте рассмотрим первое решение.

Использование пакетов

В пакете есть методы (процедуры/функции), позволяющие оперировать таблицей или запрашивать из нее строки. Пользователю, у которого есть разрешение на выполнение пакета, но нет полномочий на доступ к таблице, содержимое и структура таблицы непосредственно недоступны. Владелец пакета имеет полный доступ к PAYROLL, а вызывающий пользователь - нет. Когда пользователь выполняет хранимую процедуру, т.е., по сути, использует представление, он действует с разрешением на доступ, предоставленным ее владельцу.

Наша первая попытка создать такой пакет представлена в примере 10.2. Пакет к payroll гарантирует, что записи могут удаляться только начальником отдела и что устанавливать значение столбца SALARY может только начальник отдела.

Пример 10.2. Первая попытка построения пакета для обеспечения безопасности доступа к данным

CREATE OR REPLACE PACKAGE k payroll AS my clept payroll. clept%TYPE; mgr BOOLEAN;

PROCEDURE del (p emp id INTEGER);

PROCEDURE ins (p emp id INTEGER, p name VARCHAR2

,p dept INTEGER, p payment period VARCHAR2

,p salary INTEGER); PROCEDURE upd (p emp id INTEGER, p name VARCHAR2

,p payment period VARCHAR2 ,p salary INTEGER) ;

END k payroll;

CREATE OR REPLACE PACKAGE BODY k payroll AS mgr flag payroll.mgr flag%TYPE; CURSOR c me IS

SELECT dept,

mgr flag

FROM mysys users

WHERE username = USER;

FUNCTION checkdept (p emp id INTEGER) RETURN BOOLEAN IS dept payroll.dept%TYPE;