What are seals?
Passwords are selectively made available to the different user groups by means of the . Nevertheless, there are many scenarios in which the ability to view and use a record should be linked to a release issued in advance. In this context, the seal is an effective protective mechanism. This double-check principle protects passwords by securing them with granular release mechanisms. If you want to see a password, this must be requested and released. The release can also be temporary.
The following option is required to add a seal.
- Can add seal
Firstly, the user must have the ”authorize” right for the record in order to create seals. The read right to all users and roles that are contained in the seal is also required. The exact configuration of password masking and permissions for records is described in detail in the .
What exactly is sealed?
Even with sealed data sets, not all fields are sealed. This s the case only with the passwords that need to be protected. Technically speaking, the password itself is not sealed. It is the right to see a password field that is protected by a seal. This allows for the most sensitive configurations, in which one group can use the password without restrictions, but the same password is sealed for the other user group. The wizard assists users in applying seals, as well as in future maintenance thereof.
All seal configurations are performed in the wizard. Both the application of new seals as well as the processing and erasing are possible here. The current state of a seal can also be viewed in an overview, which is also reached via the button in the ribbon. When the seal wizard is opened via the ribbon, the wizard appears in the case of unsealed data sets, which runs in four steps through the configuration of the seal.
1. Apply seal
All objects that are sealed are displayed at the beginning. Depending on the data record, this can be one object, or several. It is also possible to use existing . Optionally, you can enter a reason for each seal.
2. Double-check principle
The seal logic is the most basic element of this protective mechanism. Here, you define for which users or roles the record should be sealed or released in the future. All those for whom the record is to be sealed are displayed in red, while all users with the required permissions to issue a release are displayed in blue.
To avoid having to perform any configuration manually, roles and users are copied directly from the authorizations of the data record. Compare with the ”permissions” for the record (can be viewed via the ribbon).
The relationships are obvious. As a rule, supervisors should issue the releases for their employees. Therefore, the checkbox also follows the existing authorizations. The following scheme is used:
Here is a closer look at the permissions of the role Administrators on the record:
Adjusting the seal logic
Although standard authorizations are used as a basis for the sealing concept, these can, of course, be adapted. The number of releases generally required is just as configurable as the required number of releases from a role. In the following example, the seal has been extended so that a total of three release authorizations are required in order to release the seal (double-check principle). The role of the administrators has been marked in the mandatory column. This means that it must grant at least one release In summary: A total of three releases must be made, whereby the group of administrators must grant at least one release.
In order to be not only dependent on existing authorizations on the data set, other users can also be added to the seal. The role accounting under “sealed for” has been added below.
3. Advanced settings
Advanced seal settings allow you to adjust the double-check principle. Both the time validity of a release request as well as a granted release can be configured. Multiple break defines whether after the breaking of a seal by a user, other users may still break it.
4. Saving the seal
The rights already present on the data set form the basis for any complex seal configurations. It is thus freely definable which users have to go through a release mechanism before accessing the password. The roles, which may be granted, are freely definable. An always accessible allows all authorized persons to view the current state of the seals. The describes in detail the individual steps, from the initial release request to the final release.