OM-BP-0003: Best Practice Ownership IAM Objects
In addition to the ownership of accounts, every object in your IAM landscape must have an owner.
The following objects can be identified:
Account: see David’s contribution. accounts can be split up in personal and non-personal accounts.
non-personal accounts can also be divided in service accounts (machine to machine), robot accounts, test accounts etc.personal accounts can be regular or special accounts (such as admin accounts)
We also see the following objects that need ownership:
1. Relations between objects (relation between account and role)
2. Roles
3. Targetsystems (that can be provisioned)
4. Entitlements (in the targetsystem and IAM system) In some targetsystems permissions are allready combined in a technical role. Permissions can be sensitive if for example they give access to sensitive information. This may lead to a higher frequency of recertification.
The owner of the permissions should, in cooperation with a business manager, be able to identify sensitive of critical permissions. They should also be able to identify which permissions should never be allowed to be given to a single account.
5. Organization (If your using RBAC and automatic role assignment based on the organizational unit)
6. Documentation. To maintain and develop your IAM landscape you need to document it. Documentation consists of: Policies (organization and business rules), technical documentation, process documentation (Joiner, Leaver, Mover, but also role creation, exception process to break SoD etc.)
You can use your IAM tooling to check for ownership, on the objects by checking the correct attribute on the object in the IAM-tooling.
Follow us on LinkedIn | Discuss on Slack | Support us with Patreon | Sign-up for a free membership.
This wiki is owned by Open Measure, a non-profit association. The original content we publish is licensed under a Creative Commons Attribution 4.0 International License.
I really like the five items listed here. What about adding one more - the processes themselves? For example, a document describing the process, workflow, and environment for a system or application provisioning. There should be an owner of this process to review and update it annually or when an upgrade or other change occurs. Thoughts?