Best Practices for Security Labels and Agreements
Consider the following best practices for a system with security labels configured:
Set a null security label value on objects that do not contain sensitive information. Setting a non-null informative marking is also acceptable. Objects with null security label values and non-null informative markings do not restrict access, which means your Windchill system will not need to verify that the user is an authorized participant.
Use security labels only when one or more values restrict access to an object. Otherwise, use global attributes rather than non-null informative markings on an object. Security labels that are purely informative markings are not a replacement for global attributes.
For objects that do contain sensitive information, add participants to the label value's authorized participant's group unless the participants only need access for a limited time. Agreements should be used only as an exception to a security label value restriction. While there is no limit to the amount of time an agreement can be active, agreements should not be used as the primary means to grant a large number of users access to a security-labeled object.
All the name/value pairs applied to a business object are stored together in a single database column with a size limit of 4000. For standard security labels, keep the name attribute of the SecurityLabel element and the name attribute of the SecurityLabelValue element as short as possible as these values are not generally seen in the user interface. For more information, see Edit the Security Labels Configuration File.
Use caution when specifying an authorized participant for a security label value or an agreement. Specifying a group or an organization as an authorized participant gives those with permission to change group or organization membership control over who is authorized by the security label value or agreement. Make sure that you select groups and organizations whose membership can only be modified by administrators that should be allowed to extend access to objects with the security label value applied or that are associated with the agreement. For example, if you select a system group associated with a context team role as the authorized participant for an agreement, by default the context administrator is able to change the team membership and therefore also change who is an authorized participant for the agreement. Unless the context administrator is also an agreement administrator, the context administrator may not understand the impact of changing the team membership.
The Select Authorized Related Changes step when creating or editing an agreement aids in managing agreement authorized objects. However, including large change objects as related change objects in an agreement can negatively impact Windchill performance.
By default, all security labels are available as columns in the Object List table on the Edit Security Labels window. A custom table view can be set up for the Object List table to limit the security label columns displayed. If the Edit Attribute Values action is launched from the table, only the columns for security labels that are available are displayed in the window. If you plan to create a custom table view and share the view with your users, the view should be created and shared prior to making the system available to users to prevent unintended authorization to modify values.
Ensure that an administrator is able to modify a standard security label value, in case it is mistakenly set by a user to a value that restricts the user access, and the user needs assistance correcting the value.
Was this helpful?