About Policies
Policy Configuration in Policy Tree
Policies can be and managed in the Policy tree. In the Policy tree hierarchy, policies are created only under other policies. Device, CA Template, Certificate, and Workflow objects are created directly under policies.
Policy Hierarchy
To apply a policy to system objects, you simply create the objects under the policy. Each time Trust Protection Platform references an asset in the Policy tree, it starts with the root policy at the top of the tree, then reads down through the policy hierarchy until it arrives at the asset. Every attribute you define in a policy is read for all subordinate assets.
This means that policy values are implemented in real time every time the asset is read.
The way in which a policy value is implemented, however, depends on whether the value is locked or not. When Trust Protection Platform looks up an object’s configuration in the tree and it encounters a locked value in a parent Policy, it stops reading down the tree. A locked value is the only value used for all subordinate objects in the tree. It doesn’t matter what is actually configured in the subordinate objects—Trust Protection Platform uses only the first locked policy value in the tree.
If you do not lock a policy attribute, the attribute functions as a default value—that is, it appears as the default option when you create new subordinate objects—but it can be overwritten at the object level. Unlocked policy values flow down the tree with the lowest value taking precedence. That means that when Trust Protection Platform looks up an object’s configuration in the tree and it encounters an unlocked policy value, it continues reading down the tree until it reaches the object configuration. Attributes defined at the object level always take precedence over unlocked values inherited from policies higher up the tree.
In the same way that policies are used to manage object configuration, they can also be used to manage user permissions assignments. In Trust Protection Platform, permissions flow down the tree. This means that when you grant permissions to a policy, all subordinate objects inherit those same permissions unless you explicitly grant different permissions at the individual object level. Policy structure provides a natural framework to distribute system administration. For example, if encryption system assets are managed by locale, you can define local permissions assignment in a policy for each locale. Similarly, if encryption assets are managed by function, you can manage administrative permissions using a policy for each type of encryption asset. Using this model, you assign general permissions at the policy level and specific permissions at the asset level. Using policies to manage permissions assignments simplifies permissions management by providing a central point of control, while still affording the flexibility to assign individual permissions at the object level.
Another way that administrators can use policies to facilitate system administration is in the use of management partitions. Management partitions control which servers provide provisioning and validation services for objects in the Policy tree. If there are multiple Trust Protection Platform servers in your encryption environment, you can assign a different server, or “processing engine,” to each policy. That server will then run the provisioning and validation processes for the policy’s subordinate objects. This functionality is particularly useful in heavily firewalled environments where you want the local server at each site to manage processing for the local certificates and keys.
For information on creating and configuring policies, see Using policies to manage encryption assets.