X hits on this document

92 views

0 shares

0 downloads

0 comments

15 / 28

However, the Master Directory will contain additional attributes about the person, received from the HR update processes or other trusted sources of personnel information. Whenever possible, the Master Directory should avoid maintaining sensitive personal information, such as government issued identifiers. However, there may be cases where maintaining sensitive identifiers is required.

For example, suppose one of the IT systems that needs to have employee access removed is a personal health record portal that is deployed internally. This application may index its credentials by Social Security Number or Tax Payer ID number. In this case, it may need to know these identifiers in order to offboard employees and remove their access rights. In this case, the Master Directory would need to maintain this information so that the application can translate the UID into the Social Security Number that it understands.

In cases where the Master Directory is required to store sensitive personal information, the appropriate data security controls need to be put into place for both the stored information and the transmission of the information to other systems.

Note: The Master Directory change log is filtered by a process that detects on/offboarding events that are broadcast to a wide variety of systems for removing accounts and credentials. In some cases, this may represent a high volume of transaction processing with systems that may be dispersed across a wide geographic area, depending on how you manage the directory information tree and its nodes. In some cases, it may make sense to create replicas of the Master Directory in different geographies to offload some of the processing load and to improve the resiliency of the process. The discussion for the overall directory topology and locations of the Master Directory and replicas is not included in this guide, but should be considered when planning a deployment.

Block List

The Block List represents a list of people for whom a manager or authorized person has used the Emergency Block Application to immediately offboard individuals and terminate their access to IT systems. It is essentially a list of UIDs that is used to ensure that no other systems add information about an individual back to the directory.

Recently Deleted Entities Directory

The Recently Deleted Entities Directory, which could be a separate node within the Master Directory or a separate directory, maintains a list of records for people who have been offboarded within a certain time frame. These directory entries contain information about the deleted individuals that may be needed by downstream Identity Management Servers to resolve UIDs to identifiers they understand. Without this list, the information would be gone from the Master Directory before the IT systems receive notification of the offboarding event. Typically, this directory keeps records available for a specified time period, often 90 days, and then deletes them permanently.

The directory update process

As mentioned earlier, the trusted sources for personnel information send HR updates to the Directory Update Application to ensure that the Master Directory stays synchronized with the HR systems.

For HR events that represent the offboarding of an employee, the Directory Update Application must log the receipt of the offboarding request into the employee Offboarding Event Audit Server and then delete the person specified by the UID from the Master Directory and copy the record to the Recently Deleted Entities Directory.

13

Document info
Document views92
Page views93
Page last viewedFri Dec 09 06:16:40 UTC 2016
Pages28
Paragraphs457
Words10561

Comments