虚拟防火墙支持黑白名单的细粒度访问控制吗

支持。根据查询相关资料显示，虚拟防火墙是虚拟私有云的安全服务，对一个或多个子网进行访问控制，支持黑白名单的细粒度访问控制。细粒度的访问控制功能数据库防火墙权限管控基于主体、客体和行为三元组进行设置。

为了保证数据库中的数据不受到非授权的查看和修改,必须控制用户对数据的访问。细粒度访问控制也就是虚拟专用数据库，它提供强大的行级安全功能。 应用程序上下文 VPDCTX 的属性 MAXBAL 可以在会话的前期设定，而函数在运行时可以容易地获得该数值。 请仔细注意该示例。谓词有两部分：小于号之前的部分和之后的部分。之前的部分是“balance”一词，它是文字符。后面的部分从某种程度而言是静态的，因为应用程序上下文变量在改变之前一直是常量。如果应用程序上下文属性不变，则整个谓词是常量，因此不需要重新执行函数。如果策略类型定义为对上下文敏感，则 Oracle 数据库 10g 可以识别此情况以用于优化。如果在会话期间没有发生会话上下文的变化，则不重新执行该函数，从而显著提高了性能。 有时业务 *** 作可以确保谓词更加静态。例如，在上下文敏感的策略类型示例中，我们将用户所见的最大余额定义为一个变量。当 web 应用程序中的 Oracle userid 由许多 web 用户共享，并且应用程序基于这些用户的权限来设置该变量(应用程序上下文)时，这种方法很有用。因此，web 用户 TAO 和 KARTHIK 都是以用户 APPUSER 连接到数据库的，二者可以在其会话中拥有两个不同的应用程序上下文的值。此时 MAXBAL 的值并不依赖于 Oracle userid，而是依赖 TAO 和 KARTHIK 各自的会话。 在静态策略的情况下，谓词更具有可预测性，其说明如下。 LORA 和 MICHELLE 分别是 Acme Bearings 和 Goldtone Bearings 的帐户管理员。当他们连接数据库时，他们使用自己的 id，并且只应该看到属于他们的那些行。在 Lora 方面，谓词变成 where CUST_NAME = 'ACME'而对于 Michelle，则是 where CUST_NAME = 'GOLDTONE'。在这里，谓词依赖于他们的 userid，因此他们所创建的任何会话在应用程序上下文中始终具有相同的值。 10g 可以利用这种情况，在 SGA 中对谓词进行高速缓存，并在会话中重用该谓词，而不必重新执行策略函数。策略函数类似于以下形式： create or replace vpd_pol_func

p_schema in varchar2,

end而策略定义为： policy_type =>dbms_rls.static 这种方法确保策略函数只执行一次。即使应用程序上下文在会话中改变，也从不重新执行该函数，使得此过程的速度非常快。 建议将静态策略用于在几个用户中托管应用程序的情况。在这种情况下，单个数据库拥有几个用户的数据。当每个用户登录时，登录后触发器可以设置用于策略函数的应用程序上下文的值，以便快速生成谓词。 但是，将策略定义为静态也是一把双刃剑。在以上的示例中，我们假设应用程序上下文属性 VPDCTX.CUST_NAME 的值在会话中不改变。如果这种假设不正确，将会怎样呢?如果该值改变，策略函数将不会执行，因此在谓词中将不会使用新值，而返回错误的结果!因此，在将策略定义为静态时要非常小心您必须绝对确信该值不会改变。

你说的这三款都是安华金和的产品，为何不直接找厂商咨询，我先来简单说下，从使用场景上来说数据库防火墙主要针对应用侧，需要对应用访问数据库的行为进行管控，创建语句黑白名单机制，防护应用侧可能被黑掉后产生的漏洞攻击。同时能够对运维侧 *** 作数据库的行为做出基于细粒度访问控制规则的限制。 数据库运维管控针对运维侧，除了能够对 *** 作数据库的行为做出基于细粒度访问控制规则限制外，还能够对运维行为进行规范，通过申请--审批机制，确保敏感运维行为可控。提供敏感数据掩码遮蔽返回能力，提供运维人员身份鉴别能力。 动态数据脱敏：针对应用侧和运维侧都可以，目前定位针对应用侧稍多一些。主要能力不是为了“控制”而设计，是为了规范敏感数据访问行为，对于不需要或者不应看到敏感数据的访问行为，提供敏感数据脱敏返回，包含了掩码遮蔽和仿真脱敏两种返回方式，其中仿真脱敏更利于业务系统的后续业务连续执行。个人看法，觉得不错就采纳吧~你的采纳 是我回答的动力。

---