EditIntroduction
Management access only confirms that users have access to a computer system or a subsystem (module) and can be managed by the Service Centre, via the execution of a service request.
Using the Octopus CMDB can cover all the needs of a healthy access management but certain conditions must be met, including;
- All access requests must go through a service request (SR)
- There must be a specific task of updating the CI type "Access" in the Service Request
EditImplementation
1. Go to
Tools > Reference Data Management... > CI > Types
2. Create a new CI Type named
« Access »
3. Go back to the module "Configurations" and create a CI for each type of access to manage (
Octopus – Administrator, for example)
Example of a list of CI of "Access" type :
| Name : |
Access type (unique identifier) |
| Main contact : |
Responsible party for access creation (the owner of a system that can combine multiple access could be defined in a CI Type called "Information System") |
| Status : |
"In production", "Retired" (you can add additional ones) |
| Criticality : |
We can identify 3 levels of criticality for a CI: 1-High, 2-Medium, 3-Low |
4. Once the service request for a new access is completed, add the user to the corresponding "Access" CI.
we can easily obtain two types of information:
List of users with specific access
All access held by a user
5. Associate the service request to the "Access" CI to track all access requests for specific types.
Other configuration possibilities :
Creation of a CI Type « Access profile »
Useful if you create profiles that contain a combination of access.
Instead of associating access to the user, you associate the CI type "Access profile".
Association of CI "Access" (and / or "Access Profile") to the CI type "information systems"
If your information systems are documented in Octopus, associate various access to information systems.
EditScenario of processing an access request
- A manager submits via self-service Web application, an access request to an employee
- At the form submission, the service request (SR) and the tasks are automatically assigned to the group(s) (or to the responsible assignee), based on what has been configured in the service request type
- The tasks of creating access are performed by the responsible assignees
- The speaker marks the task completed, combines the service request to "Access" CI and adds the user to Ci Type "Access"
- When all tasks are completed, the Service Center marks the service request as resolved (completed)
Recommendations:
- It is good practice to entrust the management of service requests at the Service Center which takes care of 1) executing tasks and/or 2) to make the request to the responsible assignees. It has a responsibility for ensuring that delivery is complete and the requester / user is satisfied.
- To facilitate the traceability of grants, see specific instructions to specify the tasks, reminiscent of:
- To add the user to the "Access" CI
- To associate the service request (SR) to the "Access" CI
EditQUESTIONS
EditAccess management for the ABC system is made by a person outside of an IT department, how to integrate that person into the process of a service request?
- Create an Octopus account for this person - a service request may then be assigned
- Restrict access to consultation of his requests only (by unchecking "Web application for technicians - See opened incidents / SR") and the ability to mark them as resolved (by checking the permission "Incidents /SR - Modify an incident"). It can be accessed via the Web Self-Service application for technicians, which is very easy to use. ***Special pricing applies for this type of user.***
Note :
At the moment, only incidents, events and notifications can be accessed from the self-service Tech Web portal (for technicians) - not the tasks. We must therefore create separate SR.
EditHow to proceed if the request implies creating several access by different persons ?
Octopus has introduce the concept of tasks in SR. Each type of SR can be configured with specific customizable tasks.
EditHow to record an SR in the name of a new user who is not yet in Octopus?
To ensure linking at all times your SR to their beneficiary users, you can create a generic user of the type « New user » and change it once the SR has been completed (a task could be created on this). This will prevent a requester to be associated with multiple applications that do not belong to him.
EditWhat to do if an approval is required ?
A complete process of approval specific for each type of SR will be integrated into the Winter 2011 version.
Depending on your internal procedures, several contexts can occur, here are some examples:
- Service requests are only submitted by the authorized managers - the requests received are ready to be executed
- Service requests are submitted by the end user, and approval is managed by the IT department - we must get the approval before executing them
The following procedure is applied in the context 2 :
- Create a type of activity "Approval required" containing a model of e-mail addressed to the approver. This email will be sent through the selection of this type of activity at the time of execution of the task of approval.
- Create a task "Approval" in the type of service request
- IT assignees must suspend the service request without suspending the tasks et select the reason « Waiting for approval » to stop the request execution meter
- They add an activity type "Approval required" and send it to the designated approver in the Web form.
- Upon receipt of the email, the approver can respond by email or log on to the self-service Web portal to add a message of acceptance or rejection of the SR. The answer will appear in the request.
- If the task is approved, the assignee completes the task and reactivates the service request - other tasks will activate.