Читать книгу The Official (ISC)2 SSCP CBK Reference - Mike Wills - Страница 162

Having made the decision to create a new identity and having decided what privileges it will have associated with it, it's time to actually provision it. Provisioning is the process of implementing the management decisions about a subject's identity and the privileges associated with it into the logical, physical, and administrative aspects of the access control functions throughout all of the systems this identity will require (and be allowed) access to and use of. (Note that I separate proofing from provisioning here for clarity.) Depending upon your overall systems architecture, this “push” of a new identity, and all subsequent updates to it, might be simple and straightforward or complex and time-consuming.

 Typical SOHO-style architectures that do not use an integrated identity management and access control set of technologies will require creating the new identity and provision its access privileges on each system, endpoint, or platform the user needs access to. This might include creating the username and credentials on each Windows, Mac, or Linux workstation and endpoint device and then creating similar credentials on each network-attached storage system, website, or cloud-hosted storage, database, or applications platform that the employee will use. Every one of these systems, sites, and platforms will need to be “touched” or updated every time this user's privileges are modified, revoked, or suspended.

 Integrated identity and access management (IAM) systems can reduce this to a single creation/update task and then push this information to all connected systems. Systems, platforms, and apps that support the organization's single sign-on access process are also updated with a single push, whether for the initial provisioning or for updates.

Note that the IAM/SSO “single push” process is not instantaneous. Depending upon the scale and complexity of your information architecture, it can take minutes or hours for every server, every platform, every applications suite, and every affected endpoint to process the update. (Globe-spanning organizations, even ones of 500 people or fewer, can often see this take half a day or more.) Creation and update of identities can and should be a deliberate process, and “next business day” availability is quite often acceptable. However, systems administrators need to be able to support rapid updates to meet urgent and compelling needs, either to grant new identities new privileges or to revoke or suspend them.

Deprovisioning is the process of temporarily or permanently revoking both the privileges associated with an identity and the identity itself. Typically, deprovisioning is done in a series of steps that disable (but do not remove) privileges and accounts and then remove them completely. As with provisioning, this is either a straightforward, single “unpush” kind of action supported by your integrated identity and access management system or a laborious system-by-system, app-by-app, site-by-site effort. Since many deprovisioning actions are related to situations involving an employee being disciplined or terminated from employment, two special considerations should apply.

 The employee's work unit managers or directors, the human resources management team, and the information systems security specialists should coordinate informing the employee of their change of status and the deprovisioning itself. This is necessary to prevent a disgruntled employee from inflicting damage to systems or exfiltrating data from them.

 The deprovisioning should be something that can be done rapidly, across all systems, and in ways that can be readily confirmed or validated.

When it comes to the identities you manage for the people in your systems, nothing is forever; every such identity you create and provision will at some point need to be modified, suspended, and then ultimately removed. Whether this commonsense notion holds for the identities associated with devices remains to be seen.