Блог

У меня есть политика, которая хорошо работает в рамках VPD, и я пытаюсь скрыть столбцы. Я знаю, что могу использовать это:

 BEGIN
 DBMS_RLS.ADD_POLICY(
   object_schema         => 'scott', 
   object_name           => 'emp',
   policy_name           => 'hide_sal_policy', 
   policy_function       => 'hide_sal_comm',
   sec_relevant_cols     =>' sal,comm',
   sec_relevant_cols_opt => dbms_rls.ALL_ROWS);
END;
 

Но это скрывает только предопределенные столбцы, в которых есть ‘sal’ и ‘comm’.

Что я хотел бы сделать, так это иметь справочную таблицу, содержащую ссылки на столбцы, которые я хотел бы скрыть:

 SCHEMA TABLE COLUMNS_TOHIDE
my_schema my_table my_column1;my_column2
my_schema2 my_table2 my_column3;my_column4;my_column5
 

В идеале код для добавления политики должен быть сгенерирован автоматически.

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

Спасибо за вашу помощь

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

Тем не менее, если вы хотите делать подобные вещи, вы могли бы

• Создайте триггер в таблице столбцов для скрытия.
• В этом триггере используйте dbms_job пакет для отправки задания, которое выполняется после фиксации транзакции. Затем это задание вызовет generateVPDPolicy процедуру.
• Затем generateVPDPolicy процедура запрашивает таблицу столбцов для скрытия и генерирует соответствующие политики VPD.

Это означает, что, вероятно, будет задержка на секунду или две (или больше, в зависимости от того, какие другие фоновые задания у вас есть, и ваших job_queue_processes настроек) между фиксацией изменения и обновлением политики VPD. Это означает, что теперь есть больше движущихся частей для отладки, если и когда что-то пойдет не так. Например, если кто-то допустит опечатку при редактировании списка столбцов, процедура предположительно выдаст ошибку, которая будет записана в журнал предупреждений (или в какую-либо пользовательскую таблицу ошибок, которую необходимо отслеживать). Если что-то приводит к тому, что задания не выполняются (чаще всего устанавливается значение job_queue_processes 0 как часть какого-либо сценария исправления / обновления и забывается, чтобы вернуть его обратно), кому-то нужно знать, чтобы отладить это. В большинстве случаев это должно работать довольно гладко. Однако, когда что-то выходит из строя, теперь у вас есть гораздо более сложная система, чем простое изменение функции политики VPD, которое является частью запланированной сборки.