|
Программирование >> Oracle
Тщательный контроль доступа 1449 SOME DATA OWNER Некие данные TKYTE Данные, принадлежащие пользователю SCOTT SCOTT Новые данные SCOTT Новые данные, принадлежащие пользователю SYS SYS Итак, пример показывает, что на пользователя TKYTE правило защиты не распространяется. Интересно отметить, что в случае регистрации от имени пользователя SYS наблюдается следующая особенность: tkyte@TK:E816> connect sys/change on install Connected. sys@TKE816> select * from datatable; SOME DATA OWNER Некие данные TKYTE Данные, принадлежащие пользователю SCOTT SCOTT Новые данные SCOTT Новые данные, принадлежащие пользователю SYS SYS Правила зашиты не применяются для специального пользователя SYS (а также при регистрации от имени INTERNAL или как SYSDBA). Это сделано специально. Учет-н1е записи с привилегиями SYSDBA предназначены для решения задач администрирования и соответствующим пользователям доступны все данные. Это особенно важно учитывать при экспортировании данных. Если только экспортирование не выполняется с привилегиями SYSDBA, применяются правила защиты. При использовании учетной записи без привилегий SYSDBA и обычном экспорте вы получите не все данные! Пример 2: Использование контекстов приложений В этом примере мы реализуем правила защиты информации о сотрудниках (для отдела кадров крупной компании). Будем использовать простые таблицы ЕМР и DEPT, принадлежащие пользователю SCOTT, и добавим таблицу с информацией о сотрудниках, которые отвечают за кадровые вопросы в том или ином отделе. При этом необходимо реализовать следующие правила защиты. Руководитель отдела может: просматривать свою собственную запись, а также записи для всех своих подчиненных; изменять записи своих непосредственных подчиненных. Рядовой сотрудник может: просматривать свою собственную запись. Ответственный за кадровые вопросы в отделе может: читать все записи для отдела (предполагается, что ответственный за кадровые вопросы в определенный момент времени работает только в одном отделе); 1450 Глава 21 изменять все записи для отдела; вставлять записи для соответствующего отдела; удалять записи для соответствующего отдела. Как было сказано, приложение будет использовать копии существующих таблиц ЕМР и DEPT из схемы пользователя SCOTT и дополнительную таблицу, HR REPS, позволяющую назначить ответственного за кадровые вопросы в отделе. При регистрации желательно автоматически назначать пользователю соответствующую роль в приложении. Так что, например, при регистрации ответственного за кадровые вопросы он сразу бы получал соответствующую роль в приложении. Для начала необходимо создать в базе данных ряд учетных записей. Эти учетные записи создаются для владельца приложения и пользователей. В данном случае владелец приложения - пользователь TKYTE, и соответствующая схема будет содержать копии таблиц ЕМР и DEPT из демонстрационной схемы SCOTT. Пользователи именуются так же, как сотрудники в таблице EMP (KING, BLAKE и т.д.). Для создания и настройки всех этих учетных записей использовался следующий сценарий. Сначала удаляем и пересоздаем пользователя TKYTE, предоставляя ему роли CONNECT и RESOURCE: sys@TKYTE816> drop user tkyte cascade; User dropped. sys@TKXTE816> create user tkyte identified by tkyte 2 default tablespace data 3 temporary tablespace temp; User created. sys@TKYTE816>grant connect, resource to tkyte; Grant succeeded. Теперь предоставим пользователю минимальные привилегии, необходимые для организации тщательного контроля доступа. Вместо привилегии EXECUTE ON DBMS RLS можно предоставить роль EXECUTE CATALOG: sys@TKYTE816> grant execute on dbms rls to tkyte; Grant succeeded. sys@TKYTE816>grant create any context to tkyte; Grant succeeded. Следующая привилегия необходима для создания триггера на событие регистрации в базе данных, который надо будет создать в дальнейшем: KIE81 grant administer database trigger to tkyte; Grant succeeded. Теперь создадим учетные записи сотрудников и руководителей для пользователей приложения. Для каждого сотрудника в таблице ЕМР (кроме SCOTT) будет создана учетная запись, имя которой совпадает со значением в столбце ENAME. Во многих базах данных учетная запись SCOTT уже существует: Тщательный контроль доступа 1451 sys@TKYTE816> begin 2 for x in (select ename 3 from scott.emp where ename <> SCOTT) 4 loop 5 execute immediate grant connect to x.ename 6 identified by x.ename; 7 end loop; 8 end; PL/SQL procedure successfully completed. sys@TKYTE816> connect scott/tiger scott@TKYTE816> grant select on emp to tkyte; Grant succeeded. scott@TKYTE816> grant select on dept to tkyte; Grant succeeded. Приложением используется следующая простая схема. Сначала копируются таблицы ЕМР и DEPT из схемы пользователя SCOTT. Для этих таблиц мы также добавим декларативные требования целостности ссылок: scott@TKYTE816> connect tkyte/tkyte tkyte@TKYTE816> create table dept as select * from scott.dept; Table created. tkyte@TKYTE816> alter table dept add constraint dept pk primary key(deptno); Table altered. tkyte@TKYTE816> create table emp base table as select * from scott.emp; Table created. tkyte@TKYTE816> alter table emp base table add constraint 2 emp pk primary key(empno); Table altered. tkyte@TKYTE816> alter table emp base table add constraint emp fk to dept 2 foreign key (deptno) references dept(deptno); Table altered. Теперь добавим несколько индексов и требований. Создадим индексы, которые будут использоваться функциями контекста приложения для повышения их производительности. Мы должны иметь возможность быстро определять, является ли данный пользователь руководителем отдела: tkyte@TKYTE816> create index emp mgr deptno idx on emp base table(mgr); Index created. Необходимо также быстро получать по имени пользователя значение EMPNO и обеспечить уникальность имен пользователей в приложении:
|
© 2006 - 2025 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки. |