Август 2004
Профессионалу администратору
Дарл Кун,
Стив Ротон
Теперь защищаем каждую строку
(Now Securing Every Row,
by Darl Kuhn and Steve Roughton)
Источник: журнал Oracle Magazine, July-August 2003
(
http://otn.oracle.com/oramag/oracle/03-jul/o43security.html).
Опция меточной безопасности Oracle (Oracle Label Security) позволяет контролировать пользовательский доступ к данным на уровне строк.
Большинству бизнес-приложений приходится иметь дело с вопросами безопасности. В приложениях часто требуется ограничивать доступ к конфиденциальным записям, создавать журналы аудита или обеспечивать выполнение потоков работ, и все это делать в соответствии с требованиями корпоративной политики безопасности. Создание безопасного программного обеспечения представляет собой сложную задачу и требует напряжения всех сил; администрирование правил разграничения доступа (security policies) на уровне всей организации может быть даже более трудной задачей.
Как проектировщик схем вы могли бы начать с добавления к таблицам столбцов защиты и создания для пользователей специальных представлений этих таблиц. Как АБД вы для защиты объектов базы данных, вероятно, должны были бы создавать роли и предоставлять пользователям привилегии. Как разработчик приложений вы могли бы написать PL/SQL-пакеты для инкапсуляции в приложениях безопасных транзакций. Все это – правильные и допустимые способы, но даже они имеют некоторые недостатки. Например, кто-то может случайно загрузить конфиденциальные данные в свою персональную схему, унаследованные приложения могут быть несовместимыми с вашими защищенными объектами, пользователи могут использовать утилиту SQL*Plus, чтобы полностью обойти защиту, встроенную в приложения.
В СУБД Oracle9i есть компонент, который может помочь в разрешении таких проблем: опция Oracle Label Security (меточная безопасность Oracle). Опция Oracle Label Security, первоначально появившаяся в СУБД Oracle8i Release 3 (8.1.7), представляет собой простой инструмент, который позволяет вам устанавливать и обеспечивать принудительное исполнение ваших бизнес-правил разграничения доступа.
Опция Oracle Label Security – это набор процедур и ограничений целостности, встроенных в машину базы данных, которые обеспечивают принудительный контроль доступа на уровне строк для отдельной таблицы или всей схемы. Для того чтобы использовать Oracle Label Security, вы создаете одно или более правил разграничения доступа, каждое из которых содержит набор меток. Вы используете метки для указания, какие пользователи имеют права доступа к тем или иным типам данных. После создания правил вы прикрепляете их к таблицам, которые требуется защищать, и предоставляете метки вашим пользователям, и это все, что нужно сделать. Опция Oracle Label Security прозрачно для пользователей модифицирует запросы и "на ходу" оценивает уровни доступа для принудительного исполнения ваших новых правил.
Как только сервер Oracle9i Database выполнит синтаксический разбор очередного SQL-оператора, он определит, не защищены ли какие-то таблицы правилами разграничения доступа. В зависимости от прав доступа пользователей сервер Oracle9i Database добавляет предикаты защиты к WHERE-предложению оператора. Это происходит внутри машины базы данных, поэтому механизм защиты невозможно обойти независимо от источника происхождения SQL-оператора.
Как это работает
Рассмотрим очень простой пример, демонстрирующий функционирование опции Oracle Label Security. Мы создали таблицу documents (документы), вставили в нее четыре записи и определили два уровня безопасности: PUBLIC (общедоступный) и INTERNAL (внутренний). Каждый уровень имеет также числовые значения: 1000 и 2000 соответственно. Затем мы назначим эти уровни строкам таблицы. Простой оператор запроса к этой таблице имеет следующий вид:
SQL> SELECT * FROM documents;
DOCID DOCNAME LEVEL DOC_LABEL
----- ----------- -------- ---------
1 SHARE_WARE PUBLIC 1000
2 WEST_PAYROLL INTERNAL 2000
3 EAST_SALES INTERNAL 2000
4 COMP_PAYROLL INTERNAL 2000
Теперь предположим, например, что имеется два пользователя нашей базы данных: EMP (employee – сотрудник) и MGR (manager – менеджер). Этим пользователям мы назначаем следующие уровни доступа:
- пользователю EMP назначается уровень доступа PUBLIC в режиме только для чтения;
- пользователю MGR назначаются уровни доступа PUBLIC и INTERNAL в режиме чтения-записи.
Когда эти пользователи обращаются к нашей таблице, то пользователь EMP сможет прочитать только первую строку, тогда как пользователь MGR имеет полный доступ ко всем четырем строкам в режиме чтения-записи.
Что происходит внутри сервера базы данных, когда эти пользователи обращаются к таблице documents? Предположим, пользователь EMP выполняет следующий запрос:
SELECT * FROM documents;
Сервер Oracle9i Database разбирает этот запрос и определяет, что данная таблица находится под контролем опции меточной безопасности. Опция Oracle Label Security добавляет к запросу предложение WHERE, чтобы гарантировать, что пользователь EMP увидит только строки, помеченные как PUBLIC:
SELECT * FROM documents
WHERE doc_label = 1000;
Пользователь EMP после выполнения запроса увидит следующее:
DOCID DOCNAME LEVEL DOC_LABEL
----- ---------- ------ ---------
1 SHARE_WARE PUBLIC 1000
Вы можете удивиться: "Почему бы не создать представление, которое ограничивает доступ, базируясь на значениях каких-то столбцов?" На самом деле, если вашему представлению требуются только несколько уровней и отсутствуют какие-либо специальные требования к безопасности, которые нужно учитывать, то добавление столбца защиты к вашей таблице и использование представлений представляет собой достаточный способ.
Но предположим, требования к вашей системе изменились и теперь вам нужно управлять несколькими иерархиями пользователей из различных организаций, с настраиваемыми (в соответствии с требованиями заказчиков) правами изменения наборов данных в режиме чтения-записи. Кроме того, организации находятся в разных странах, каждая из которых имеет собственное законодательство и ограничения, связанные с обеспечением безопасности. Обеспечить выполнение таких требований намного труднее, если вы используете только представления.
К счастью, опция Oracle Label Security спроектирована так, чтобы обеспечивать масштабирование; поэтому реализация такого типа защиты приложений более проста, чем вы могли бы ожидать.
Практический пример
Для применения опции Oracle Label Security необходимо выполнить следующие 10 шагов:
Для работы с опцией Oracle Label Security можно использовать графический интерфейс пользователя Policy Manager (диспетчер политики) инструментария Oracle Enterprise Manager или PL/SQL-пакеты опции Oracle Label Security. В нашей демонстрационном примере мы будем использовать PL/SQL-пакеты. В обоих способах работы с опцией используются одни и те же понятия.
Шаг 1: инсталлируйте опцию Oracle Label Security
Вы должны инсталлировать опцию Oracle Label Security только один раз для каждой базы данных. Инсталляция состоит из четырех шагов:
- Запустите универсальный инсталлятор (Universal Installer).
- Выберите в нем и инсталлируйте опцию Oracle Label Security.
- Как пользователь SYS выполните скрипт $ORACLE_HOME/rdbms/admin/catols.sql следующим образом:
SQL> CONN sys/пароль AS SYSDBA;
SQL> @?/rdbms/admin/catols
Замечание: в скрипте catols.sql на его последнем шаге выполняется команда SHUTDOWN IMMEDIATE (немедленно остановить экземпляр СУБД).
- Перезапустите экземпляр вашей СУБД и выполните оператор:
SQL> SELECT username FROM dba_users;
Вы обнаружите, что появился новый пользователь LBACSYS, в схеме которого содержатся все объекты опции Oracle Label Security. Пароль по умолчанию у этого пользователя – LBACSYS (так что, не забудьте сразу же изменить этот пароль). Этот пользователь будет заниматься администрированием ваших правил разграничения доступа.
Шаг 2: создайте правила разграничения доступа
Следующая задача – создание правил разграничения доступа. Правила – это набор записей, в которых содержатся ваши предписания безопасности и условия доступа. Метки данных на уровне строк и права доступа схем к строкам всегда связаны с правилами.
В этом примере вы имеете бизнес-требования для определения прав доступа к документам компании на уровне строк. На данном шаге вы создаете правила, названные DOC_POLICY. Для создания правил соединитесь с базой данных как LBACSYS и используйте процедуру sa_sysdb.create_policy:
SQL> CONN lbacsys/lbacsys
SQL> EXEC sa_sysdba.create_policy
('DOC_POLICY','DOC_LABEL');
Первый параметр, DOC_POLICY, – имя правил, а второй параметр, DOC_LABEL, – имя столбца, который опция Oracle Label Security добавит к таблице, которую вы переводите под меточный контроль.
Для проверки, что ваши правила были созданы, выполните следующий запрос к представлению DBA_SA_POLICIES:
SQL> SELECT policy_name, status
from DBA_SA_POLICIES;
POLICY_NAME STATUS
----------- -------
DOC_POLICY ENABLED
Для отключения, повторного включения и удаления правил используйте следующие процедуры соответственно:
SQL> EXEC sa_sysdba.disable_policy
('DOC_POLICY');
SQL> EXEC sa_sysdba.enable_policy
('DOC_POLICY');
SQL> EXEC sa_sysdba.drop_policy
('DOC_POLICY');
Шаг 3: определите уровни
Во всех правилах разграничения доступа должны содержаться уровни (levels), которые определяют различные степени доступности данных таблицы. В этом примере вы создаете два уровня конфиденциальности (levels of sensitivity): PUBLIC и INTERNAL:
SQL> EXEC sa_components.create_level
('DOC_POLICY', 1000,
'PUBLIC', 'Общедоступный уровень');
SQL> EXEC sa_components.create_level
('DOC_POLICY', 2000,
'INTERNAL', 'Внутренний уровень');
Для каждого уровня задаются имя правил, числовой идентификатор, короткое и длинное имена. Числовой идентификатор обозначает уровень конфиденциальности – чем больше число, тем выше конфиденциальность. В этом примере уровень INTERNAL является более конфиденциальным, чем уровень PUBLIC. Для просмотра созданных вами уровней выполните следующий оператор:
SQL> SELECT * FROM dba_sa_levels
ORDER BY level_num;
Шаг 4: определите отделения (необязательно)
Отделения (compartments) позволяют вам детализировать доступ к строкам данных в пределах одного уровня. (Прим. пер. Этот компонент меток безопасности иногда называется категорией.) В этом примере у вас имеются документы с одинаковыми уровнями конфиденциальности, но некоторые подразделения могут видеть только подмножества этих уровней. Здесь вы создаете отделения FINANCE (финансы) и HUMAN_RESOURCE (кадры):
SQL> EXEC sa_components.create_compartment
('DOC_POLICY', 200,
'FIN', 'FINANCE');
SQL> EXEC sa_components.create_compartment
('DOC_POLICY', 100,
'HR', 'HUMAN_RESOURCE');
Для отделений задаются имя правил, числовой идентификатор, короткое и длинное имена. Числовой идентификатор для отделений не задает их уровень конфиденциальности. Он используется только для упорядочивания отделений при выводе информации о правах доступа. Для получения информации о ваших отделениях выполните запрос к представлению DBA_SA_COMPARTMENTS.
Шаг 5: определите группы (необязательно)
Используйте группы (groups), как и отделения, в качестве еще одного дополнительного способа ограничения доступа в пределах уровня. Группы полезны, если вы имеете иерархии пользователей, как в организационной структуре компании.
Во время создания группы необходимо определять иерархию. В этом примере группа ALL_REGIONS (все регионы) – родительская группа, а WEST_REGION (западный регион) и EAST_REGION (восточный регион) – дочерние группы родительской группы ALL_REGIONS.
SQL> EXEC sa_components.create_group
('DOC_POLICY', 10,
'ALL', 'ALL_REGIONS');
SQL> EXEC sa_components.create_group
('DOC_POLICY', 20, 'WEST',
'WEST_REGION', 'ALL');
SQL> EXEC sa_components.create_group
('DOC_POLICY', 30, 'EAST',
'EAST_REGION', 'ALL');
Для групп, как и для отделений, задаются имя правил, числовой идентификатор, короткое и длинное имена. Числовой идентификатор не обозначает никакой конфиденциальности; он используется только для упорядочивания информации о группах. Для получения информации о ваших группах выполните запрос к представлению DBA_SA_GROUPS.
Шаг 6: создайте метки
Метки (labels) – это комбинации уровней, отделений и групп. Каждая группа должна содержать один уровень и, необязательно, отделения и/или группы. Метка позволяет вам зафиксировать вместе различные типы доступа, требующиеся для различных пользователей данных.
Метки – это комбинации коротких имен уровней, отделений и групп, которые имеют следующий синтаксис:
уровень : отделение, …, отделение_n : группа, …, группа_n
Уровень, отделения и группы необходимо разделять двоеточиями. Если вы задаете более одного отделения или группы, то их нужно разделять запятыми.
Например, у вас могут быть пользователи в финансовом отделе, имеющие доступ только к внутренним документам. Такая метка будет иметь следующий вид:
INTERNAL:FIN
В соответствии с изложенными выше требованиями создайте четыре метки следующим образом:
SQL> EXEC sa_label_admin.create_label
('DOC_POLICY', '10000',
'PUBLIC', TRUE);
SQL> EXEC sa_label_admin.create_label
('DOC_POLICY', '20200',
'INTERNAL:HR:WEST', TRUE);
SQL> EXEC sa_label_admin.create_label
('DOC_POLICY', '20400',
'INTERNAL:FIN:EAST', TRUE);
SQL> EXEC sa_label_admin.create_label
('DOC_POLICY', '30900',
'INTERNAL:HR,FIN:ALL', TRUE);
При создании меток им необходимо присваивать номера. Эти номера должны быть уникальными среди всех правил в вашей базе данных. Для получения информации о метках выполните запрос к представлению DBA_SA_LABELS.
Шаг 7: прикрепите правила разграничения доступа к таблице
Для перевода таблицы под контроль опции меточной безопасности прикрепите правила разграничения доступа к этой таблице. В следующей процедуре вы прикрепляете правила DOC_POLICY к таблице DOCUMENTS, принадлежащей пользователю APP. Опция Oracle Label Security будет контролировать доступ к этой таблице в режимах чтения и записи:
SQL> EXEC sa_policy_admin.apply_table_policy -
( policy_name => 'DOC_POLICY' -
, schema_name => 'APP' -
, table_name => 'DOCUMENTS' -
, table_options => 'LABEL_DEFAULT,
READ_CONTROL,WRITE_CONTROL');
Когда вы запустите эту процедуру, сервер Oracle9i Database добавит к таблице документов столбец с именем DOC_LABEL. Это имя столбца вы определили на шаге 2, когда создавали правила разграничения доступа. Если вы выведите структуру таблицы документов (командой DESCRIBE), вы увидите в ней новый столбец DOC_LABEL, как это показано ниже:
SQL> DESC app.documents
Name Type
--------- ------------
DOCID NUMBER
DOCNAME VARCHAR2(30)
DOC_LABEL NUMBER(10)
Вы можете также скрыть этот столбец от пользователей, задав во время прикрепления правил в параметре TABLE_OPTIONS (опции таблицы) опцию HIDE (скрыть):
table_options => 'LABEL_DEFAULT,
READ_CONTROL,WRITE_CONTROL,HIDE'
Параметр TABLE_OPTIONS позволяет вам определить тип контроля доступа к таблице. Опция LABEL_DEFAULT (метка по умолчанию) указывает, что в случае отсутствия метки, явно заданной в INSERT-операторе, следует использовать метку по умолчанию сеанса. Опция READ_CONTROL (контроль чтения) предписывает проверку доступа с помощью меток при выполнении операций SELECT, UPDATE и DELETE. Опция WRITE_CONTROL (контроль записи) определяет, какие операции INSERT, UPDATE и DELETE авторизуются с помощью меток.
Для определения, какие правила прикреплены, и к каким таблицам и схемам, выполните запрос к представлению DBA_SA_TABLE_POLICIES.
Шаг 8: назначьте пользовательские метки
Теперь вам нужно определить, какие пользователи имеют те или иные типы доступа в пределах правил. Именно здесь вы назначаете пользователям максимальные привилегии чтения-записи. В этом примере вы назначаете метки трем пользователям следующим образом:
- пользователю MGR назначается максимальный уровень чтения-записи;
- пользователю HR_EMP (human resource employee – сотрудник отдела кадров) назначается некоторый уровень чтения-записи документов HR WEST (кадры западного региона);
- пользователю EMP назначается общедоступный (PUBLIC) уровень чтения-записи.
На листинге 1 показан синтаксис назначения каждой из этих пользовательских меток.
Эти процедуры составляют карту отображения пользователей на уровни доступа и помеченные строки. Для получения информации о пользователях и уровнях доступа выполните запрос к представлению DBA_SA_USER_LABELS.
Шаг 9: предоставьте пользователям обычные привилегии доступа
Обеспечьте предоставление пользователям надлежащих CRUD-привилегий (CRUD: CREATE, READ, UPDATE и DELETE – создание, чтение, обновление и удаление). Опция Oracle Label Security работает совместно с механизмом проверки обычных табличных привилегий. Пользователи не смогут выполнять операторы SELECT, INSERT, UPDATE или DELETE, если им не были предоставлены надлежащие CRUD-привилегии. Когда SQL-запрос обращается к таблице, опция Oracle Label Security сначала проверяет наличие соответствующих прав CRUD-доступа и только потом проверяет правила разграничения доступа. Предоставьте вашим пользователям соответствующие CRUD-привилегии:
SQL> CONN app/app
SQL> GRANT SELECT ON documents TO emp;
SQL> GRANT SELECT, UPDATE ON documents
TO hr_emp;
SQL> GRANT SELECT, UPDATE, INSERT
ON documents TO mgr;
Шаг 10: назначьте подходящие метки
Теперь убедитесь, что каждая строка имеет соответствующую метку, назначенную ей. В данном случае вы будете загружать данные "с нуля". Вы можете либо загружать метки в виде их числового представления, либо, в качестве альтернативы, использовать функцию CHAR_TO_LABEL. В этом примере демонстрируются оба подхода. Соединившись с базой данных как пользователь MGR, вставьте данные в таблицу APP.DOCUMENTS следующим образом:
SQL> CONN mgr/mr_bigg
SQL> INSERT INTO app.documents VALUES
(1, 'SHARE_WARE',CHAR_TO_LABEL
('DOC_POLICY','PUBLIC'));
SQL> INSERT INTO app.documents VALUES
(2, 'WEST_PAYROLL', 20200);
SQL> INSERT INTO app.documents VALUES
(3, 'EAST_SALES', 20400);
SQL> INSERT INTO app.documents VALUES
(4, 'COMP_PAYROLL', 30900);
Если в таблице у вас уже есть данные, вам нужно обновить столбец меток (DOC_LABEL), вставив в него соответствующие значения меток. Таблица уже находится под контролем опции Oracle Label Security, поэтому вы должны использовать схему, которая имеет привилегии для обновления столбца меток. В качестве альтернативы вы можете временно отключить правила разграничения доступа, обновить столбец меток и вновь включить правила. Если для вставки данных в защищенную таблицу вы используете утилиту SQL*Loader, убедитесь, что выполняющий загрузку пользователь (схема) имеет надлежащие права записи меток.
Если для таблицы включен режим меточной безопасности, то даже владелец таблицы не сможет читать или писать в нее, не имея надлежащих меточных привилегий. У этого правила есть одно исключение: владельцы таблиц могут очищать их (truncate), даже не имея прав удаления строк (DELETE) в режиме меточной безопасности.
Манипулирование данными
Теперь, соединяясь с базой данных под именами различных пользователей, обратите внимание, что вы можете манипулировать данными только так, как это диктуется вашими правилами разграничения доступа и CRUD-привилегиями:
SQL> CONN mgr/mr_bigg
SQL> SELECT docname, doc_label
FROM app.documents;
DOCNAME DOC_LABEL
------------- ---------
SHARE_WARE 10000
WEST_PAYROLL 20200
EAST_SALES 20400
COMP_PAYROLL 30900
У пользователя HR_EMP этот же запрос возвратит следующее:
DOCNAME DOC_LABEL
------------- ---------
SHARE_WARE 10000
WEST_PAYROLL 20200
У пользователя EMP этот же запрос возвратит следующее:
DOCNAME DOC_LABEL
------------- ---------
SHARE_WARE 10000
Когда SQL-оператор обращается к таблице APP.DOCUMENTS, сервер Oracle9i Database сначала проверяет права CRUD-доступа, а затем проверяет правила разграничения доступа в опции Oracle Label Security. Таким образом, пользователям разрешается выполнять только санкционированные действия.
К сведению АБД
Если вы – АБД, необходимо рассмотреть несколько дополнительных вопросов. Когда вы экспортируете данные, защищенные опцией Oracle Label Security, экспортировать данные можно только в схеме, которая имеет соответствующие права доступа по чтению, назначенные ей. Например, если вы попытаетесь экспортировать таблицу APP.DOCUMENTS как пользователь SYSTEM, вы получите следующее сообщение:
EXP-00079: Data in table "DOCUMENTS" is protected.
(Данные в таблице "DOCUMENTS" защищены.
Conventional path may only be exporting partial table.
(В обычном режиме можно экспортировать только неполную таблицу.)
. . exporting table DOCUMENTS 0 rows exported
Вы не можете использовать правила разграничения доступа в схеме SYSTEM. Вы должны использовать другую схему, у которой имеются права доступа по чтению всех строк таблицы, защищенных метками. Например, если у вас есть схема EXPUSER, которую вы используете для экспорта своей базы данных, вы должны предоставить ей специальную привилегию чтения (READ) всех строк, защищенных правилами:
SQL> EXEC sa_user_admin.set_user_privs
('DOC_POLICY','EXPUSER','READ');
Для предоставления схеме полных привилегий чтения и записи всех данных, защищенных правилами, используйте ключевое слово FULL (полные):
SQL> EXEC sa_user_admin.set_user_privs
('DOC_POLICY','EXPUSER','FULL');
Заметим, любая схема с предоставленной ей привилегией SYSDBA (такая, как SYS), может видеть все данные, независимо от того, защищены они или не защищены опцией Oracle Label Security.
Независимо от любых специальных привилегий, таких, как FULL, вы не можете использовать утилиту экспорта для создания резервной копии схемы LBACSYS. Если вы попытаетесь экспортировать схему LBACSYS, вы получите сообщение об ошибке: "LBACSYS is not a valid username." (LBACSYS – недействительное имя пользователя). Следовательно, для создания резервной копии объектов схемы LBACSYS вы должны использовать средства физического резервирования вашей базы данных ("горячее", "холодное" или утилиту RMAN).
Перед импортом данных, защищенных метками, в другую базу данных вы должны предварительно инсталлировать опцию Oracle Label Security. Вам нужно будет также предварительно создать ваши правила разграничения доступа и метки и убедиться, что импортируемая схема (пользователь) имеет полные привилегии доступа по записи. Более подробно об этом см. главу 12 в книге Oracle Label Security Administrator's Guide.
Если у вас имеются большие объемы данных, защищенных опцией Oracle Label Security, вам потребуется выбрать методику настройки. В зависимости от кардинальности ваших меток вы можете рассмотреть возможность создания по вашему столбцу меток индекса в виде B-дерева или битового индекса. Например, если вы имеете метки с высокой кардинальностью, целесообразно создать индекс в виде B-дерева.
Корпорация Oracle рекомендует анализировать объекты схемы LBACSYS, а также таблицы и индексы приложений, чтобы повысить эффективность планов выполнения, генерируемых оптимизатором по стоимости. Мы рекомендуем анализировать объекты схемы LBACSYS после любых изменений правил разграничения доступа.
Заключение
Опция Oracle Label Security в сервере Oracle9i Database обеспечивает безопасный способ детального управления доступом. Эти функциональные средства, инкапсулированные в машине базы данных, не могу быть скомпрометированы (Прим. пер. Компрометация – получение критичной информации неавторизованными для этого субъектами (лицами, программами, процессами и т.д.)) и обеспечивают безопасный способ реализации и сопровождения комплексных потребностей защиты данных на уровне строк.
Дарл Кун (Darl Kuhn) (darl.kuhn@sun.com) – АБД Oracle и разработчик программного обеспечения с пятнадцатилетним опытом работы, в настоящее время работает старшим АБД в компании Sun Microsystems, Inc. в Broomfield, Colorado. Кун – соавтор книги Oracle RMAN Pocket Reference (O'Reilly & Associates, 2001) – Карманный справочник по утилите RMAN.
Стив Ротон (Steve Roughton) (steve.roughton@sun.com) – штатный инженер компании Sun Microsystems, Inc. с более чем двадцатилетним опытом работы в качестве разработчика и АБД.
Приложение
Листинг 1: назначение пользовательских меток
SQL> EXEC sa_user_admin.set_user_labels -
( policy_name => 'DOC_POLICY' -
, user_name => 'MGR' -
, max_read_label => 'INTERNAL:HR,FIN:ALL' -
, max_write_label => 'INTERNAL:HR,FIN:ALL' -
, min_write_label => 'PUBLIC' -
, def_label => 'INTERNAL:HR,FIN:ALL' -
, row_label => 'PUBLIC');
SQL> EXEC sa_user_admin.set_user_labels -
( policy_name => 'DOC_POLICY' -
, user_name => 'HR_EMP' -
, max_read_label => 'INTERNAL:HR:WEST' -
, max_write_label => 'INTERNAL:HR:WEST' -
, min_write_label => 'PUBLIC' -
, def_label => 'INTERNAL:HR:WEST' -
, row_label => 'PUBLIC');
SQL> EXEC sa_user_admin.set_user_labels -
( policy_name => 'DOC_POLICY' -
, user_name => 'EMP' -
, max_read_label => 'PUBLIC' -
, max_write_label => 'PUBLIC' -
, min_write_label => 'PUBLIC' -
, def_label => 'PUBLIC' -
, row_label => 'PUBLIC');
| 
