Volume-Level Security Policy Enforcement Mode
Prior to Core 6.2.0, Data Fabric supported enforcement based on mode and ACEs set directly on data objects. Starting in 6.2.0, security policies provide an additional or alternative way to control access to data. The volume-level enforcement mode specifies which of these methods a volume uses to govern access to data.
NOTE If you upgraded to Data Fabric
6.2.x from a pre-6.2.0 version, data objects in volumes behave as they did in the pre-6.2.0
version of Data Fabric if security
policies have not been applied to them.
Volume-Level Enforcement Modes
Regardless of the enforcement mode set, the system always enforces the ACEs directly set on a volume. HPE Ezmeral Data Fabric Database tables inherit the enforcement mode setting from the parent volume.
The enforcement mode governs access checks on volumes, as described in the following
table:
Enforcement Mode | Enforce Security Policies | Enforce Data ACEs and POSIX Mode Bits | Details |
---|---|---|---|
PolicyAceAndDataAce (Default) | Yes | Yes | The system enforces the ACEs set in security policies AND the ACEs and POSIX mode bits set directly on objects. If the volume is tagged with security policies, the ACEs set in the security policies apply to all data objects within that volume, including files and tables. If ACEs set in a security policy conflict with ACEs and POSIX mode bits directly applied to data objects, the system enforces the most restrictive setting. |
PolicyAceOnly | Yes | No |
If a data object is associated with one or more security policies, the system
enforces the ACEs set in the security policies only; the system ignores the ACEs
and POSIX mode bits set directly on the data object. However, if the access
check on a data object does not encounter at least one security policy (no
security policy tagged at the volume-level or data-object level ), the system
will enforce the ACEs and POSIX mode bits set directly on the data object.
|
DataAceOnly | No | Yes | The system enforces the ACEs and POSIX mode bits applied directly to data objects only. The system ignores all ACEs set in security policies. This mode is useful when you want to switch off the Policy-Based Security feature on a per-volume basis in an emergency situation. |
PolicyAceAuditAndDataAce (Permissive mode) | Performs checks, but does not fail; audits instead | Yes | Evaluates the policies, but does not enforce them. If auditing is enabled,
the system only audits operations when a policy fails access. The audit log will
contain the issues that would arise if the policy had actually been enforced, for
example:
Permissive mode is useful for testing to ensure security policies work before
using them. You can access the logs in the location configured to store the
volume's audit logs. Note that the file server logs data access to the node on
which the data is being accessed. IMPORTANT To enforce permissive
mode across the entire cluster (regardless of the volume-level enforcement mode
set), run:
Permissive
mode at the cluster level overrides volume-level mode. The behaviour is as
though the volume has set the SecurityPolicy mode to AuditOnly .
When applied at the cluster level, the volume level mode behaves as follows: ATTENTION This mode does not apply to snapshots. If the
mode is PolicyAceAuditAndDataAce when the snapshot is taken,
the snapshot performs the access check as if the mode is
DataAceOnly and will not evaluate the security policy for
audit purposes. |
Important Information Related to the Enforcement Mode
The following sections describe some additional requirements, options, and behaviors
related to the enforcement mode:
- Modifying the enforcement mode
- You must have volume-level ACL permission to change the enforcement mode. You can change the enforcement mode when you create or modify a volume through the Control System, CLI, or REST API. See Enforcing Security Policies at the Volume-Level for instructions.
- Volume-level enforcement mode override
- The only setting that supersedes the volume-level enforcement mode is the
cldb.pbs.access.control.enabled
cluster-level setting. If you disablecldb.pbs.access.control.enabled
, the ACEs set in all security policies are disabled across the cluster. Typically, you would only disable security policies at the cluster-level if the security policies caused a serious issue. See Disabling Policy Access Controls at the Cluster-Level. - Auditing and wire-level encryption
- The enforcement mode does not govern auditing and wire-level encryption; auditing
and wire-level encryption is always enforced regardless of the enforcement mode
set.
- Wire-level encryption for tables is controlled by the filesystem through
hadoop mfs -setnetworkencryption on|off <table_path>
. - Auditing must be enabled at the volume level for auditing to occur. To enable
audit for all data objects in the volume, use the
-forceauditenable
parameter. If auditing is disabled, permissive mode will not audit operations. - You can selectively turn all volume-level audit operations on or off through an
optional
audit
flag. You cannot set this flag on individual objects within a volume. When you set this flag on a volume, it applies to all objects within that volume. See volume create and volume modify. - Data Fabric Database
JSON tables also have an
audit
flag that controls the auditing of database operations. See table create and table edit. - Although you can tag resources at the volume, table, column family, and column (field) level in the database, the database only performs auditing and wire-level encryption at the volume and table level. The database does not perform auditing and wire-level encryption at the column family and column (field) level.
- Wire-level encryption for tables is controlled by the filesystem through
- Snapshot of a volume
- The Snapshot of a volume is set to the enforcement mode that was set on the
volume when the snapshot was taken. For example, if the enforcement mode on a volume
was
PolicyAceOnly
when the snapshot was taken and later changed toPolicyAceAndDataAceOnly
, access to the snapshot is based onPolicyAceOnly
. When you restore a volume from a snapshot or promote a snapshot to a read-write volume, the security policies and settings applied to the volume at the time of the snapshot are also restored.