The security policy state indicates whether users can apply a security policy to data
objects and whether the system enforces the ACEs set in the security policy. An administrator
can change the state of a security policy through the allowtagging and
accesscontrol parameters when creating or modifying a security policy from
the maprcli or equivalent REST API comands.
The following table describes the
allowtagging and
accesscontrol parameters.
| Parameter |
Default |
Accepted Values and Descriptions |
| allowtagging |
false |
false
- Disables tagging; users cannot apply the security policy to data
objects.
- This is the default setting if the administrator creates a security policy,
unless the administrator changes the setting when creating the security
policy.
- In cases where a security policy is active
(
allowtagging=true) but needs to be deprecated, modify the
policy and set allowtagging=false. This prevents users from
tagging any other data objects with the policy. Note that the system continues
to enforce the security controls set in the security policy for data objects
that were already tagged with the security policy.
true
- Enables tagging; users can apply the security policy to data objects.
- When creating or modifying a security policy, an administrator can set
allowtagging=true.
- When creating a security policy, the administrator may want to set this
parameter to true to test the security settings in the policy or to use
tagging tools to discover data content and tag the data.
- An administrator can set
allowtagging=true to enable a
deprecated security policy.
|
| accesscontrol |
Disarmed |
Disarmed
- This is the default setting if the administrator creates a security policy,
unless the administrator changes the setting when creating the security
policy.
- The system does not enforce the ACEs set in the security policy during data
operations on the data objects tagged with the security policy.
Armed
- The system enforces the ACEs set in the security policy during data
operations on the data objects tagged with the security policy.
- When creating or modifying a security policy, the administrator can set
accesscontrol=Armed.
- When creating a security policy, the administrator may want to set this
parameter to
Armed to verify that ACEs are correctly defined
in the policy and the system correctly enforces them.
- The administrator can set
accesscontrol=Armed to enforce
ACEs set in a deprecated security policy. The system continues to enforce ACEs
set in the security policy for all data operations on the data objects tagged
with the policy.
Denied
- Denies all access to data objects tagged with the security policy.
|
Changing the State of a Security Policy
An administrator can change the state of a security policy through the
allowtagging and accesscontrol parameters to move a
security policy through a life cycle, as shown in the following image where the security
policy moves from new to retired.
The following table describes each of the stages in the security policy life cycle:
| Stage |
Description |
| New (default) |
- Default upon security policy creation.
- Users cannot tag data objects with the security policy.
- The system does not enforce ACEs set in the security policy.
|
| In-use |
- Users can tag data objects with the security policy.
- The system enforces all security controls set in the security policy during
data operations on data objects tagged with the security policy. Security
controls set in the policy can include ACEs, auditing, and wire-level
encryption.
|
| Deprecated |
- Users can no longer tag the security policy to data objects.
- The system still enforces the security controls set in the security policy
for all data operations on the data objects tagged with the policy. Users
cannot tag any additional data objects with the policy.
|
| Retired |
- Users cannot tag the security policy to data objects.
- All data operations on the data objects tagged with the security policy are
denied by the system.
|