Question

我的政策在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;

但这只是隐藏了预先确定的专栏，其中包括“sa”字样。和＆＃39; comm＆＃39;。

我想要做的是有一个参考表，其中包含对我要隐藏的列的引用：

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

理想情况下，会自动生成用于添加策略的代码。

目标是使政策成为敏捷＆＃34;尽可能地，如果未经实验的用户想要隐藏新列，他们唯一要做的就是更改引用表，而不是修改某些Oracle代码。

感谢您的帮助

Answer 1

首先，我不是这种敏捷程度的忠实粉丝。一般来说，如果您已经达到了使用VPD的程度，这意味着您已经对哪些列包含敏感数据进行了相当多的分析。将列重新分类为敏感列或添加新的敏感列应包含合理的分析级别。它几乎总是涉及审计人员和其他有关人员将审查的文档更新。在开发方案中，让开发人员从列表中添加或删除列所需的工作量应该非常小。此外，如果您可以让人们轻松添加新列，您可以轻松地从列表中删除敏感列，运行一些查询以提取数据，然后快速重新隐藏列。对于真正最小的回报来说，这似乎是一大堆工作。

那就是说，如果你想做这类事，你可以

在要隐藏的列表上创建触发器。
在此触发器中，使用dbms_job包提交在事务提交后运行的作业。然后，这项工作将调用generateVPDPolicy程序。
generateVPDPolicy程序将查询要隐藏的列表，并生成相应的VPD策略。

这意味着在提交更改和更新VPD策略之间可能会延迟一两秒（或更多，具体取决于您拥有的其他后台作业和job_queue_processes设置）。这意味着，如果出现问题，现在有更多移动部件可供调试。例如，如果有人在编辑列列表时输入错误，则该过程可能会抛出一个错误，该错误将写入警报日志（或某些需要监视的自定义错误表）。如果某些事情导致作业无法运行（最常见的是将job_queue_processes设置为0作为某个补丁/升级脚本的一部分并且忘记再次将其放回），则有人需要知道调试它。大多数时候，这应该很顺利。但是，当某些事情失败时，您现在得到的系统要比简单的VPD策略功能更改复杂得多，而VPD策略功能更改是计划构建的一部分。

在Oracle VPD中动态隐藏列

1 个答案: