I've reproduced both the contents of the blog and the comments section (which is probably more interesting than the article) below. Enjoy!
----
Identity Management technology can be tricky. But in most instances, it's not the technology that trips up an implementation. It's the policy development (or lack thereof) that causes the heartache.
Deprovisioning Policy is typically more complex than a simple policy that states that when HR says a person is terminated, the identity system terminates the user's access to all systems. Here are a few things to consider when developing your Deprovisioning Policy.
1. Deprovisioning Policy (Technical View)
The technical view of a deprovisioning policy is concerned with what the identity system should do once we know that the user should be deprovisioned for each target system.
- Should the user's account be hard deleted or just disabled?
- If disabled, how is that done? (Move the AD account to a disabled users OU, place the row into an archive table, etc.)
- How long should disabled users be kept in the system?
- What should happen to the person's shares, mailbox, etc.?
2. Deprovisioning Policy (Business Process View)
The business process view of a deprovisioning policy addresses the states that should trigger a deprovisioning action. Here are a few questions to ask your policy team:
- How do we calculate the actual last day a person should have access? Is there an effective date that can be used? Is HR using that field properly?
- How should 'leaves of absence' be handled?
- What should happen if a person wants to use his/her vacation days directly before retirement? What if the person may still provide off-site help during this time period and therefore needs access?
- How should sabbaticals be handled?
- Should a user's current access be terminated in a department transfer? What if they still need their old access for some time?
- How should unused sick days be taken into consideration?
3. Take Compliance Policy into Consideration
Besides the business process view of the policy, sometimes existing regulatory compliance rules may have an adverse impact on an otherwise sensible policy. For example, definitions of 'termination', 'employee job role change' and 'leave of absence' will directly impact the overall policy and should be taken into consideration.
By thinking through these issues, an effective Deprovisioning Policy can be put together prior to implementing an IAM solution.----
Comments:
Hi Ash, my suggestion (as always with IAM related decisions) is to start from the business view and try to stay out from the temptation to start analyzing the event from a technical standpoint.
Using business as starting point can be very helpful for example in fragmented, complex or very dynamic environments where could be very hard to find a common agreement on the right behavior to follow and where, probably, it can give you also a longer-term solution.
What do you think?
Posted @ Tuesday, April 13, 2010 7:10 AM by Luca
Hi Luca,
Interesting point.
From a policy standpoint, both sides (biz process view and tech view) have to be defined. And although the business process view (i.e. defining the states of the user should trigger a decommissioning of the user's access) is critical, the policy would simply be incomplete without the tech view.
From a dependency standpoint, I really don't see that one piece of this is dependent on the other...(although I'm still thinking through it). It's almost as if both sides of the policy can be developed independently.
Thoughts?
Interesting point.
From a policy standpoint, both sides (biz process view and tech view) have to be defined. And although the business process view (i.e. defining the states of the user should trigger a decommissioning of the user's access) is critical, the policy would simply be incomplete without the tech view.
From a dependency standpoint, I really don't see that one piece of this is dependent on the other...(although I'm still thinking through it). It's almost as if both sides of the policy can be developed independently.
Thoughts?
Posted @ Tuesday, April 13, 2010 11:13 AM by Ash Motiwala
Ash, for sure both sides (biz process view and tech view) have to be defined. My suggestion is to avoid developing them independently and where possible to start from the business view and requirements and understand how those requirements can be fulfilled from the technical standpoint.
My idea is based on two main assumptions:
1) Technology should support business and so we should start from it and try to define the best suitable tech solution. So, is it possible to keep them independent?
2) Deriving technical view from business view allows to have more stable policies because in my (very very short) experience I’ve saw more stability on the business requirement than that on the technical one. Technical side of policies could be more fragmented, detailed and sometimes system dependent and for this reason more subject to modifications when changes happen in the technical infrastructure (mergers, new systems, etc.). In my opinion, this approach allows to keep unchanged business view and most of the decisions related to the tech view.
Are, in your opinion, my assumptions valid?
My idea is based on two main assumptions:
1) Technology should support business and so we should start from it and try to define the best suitable tech solution. So, is it possible to keep them independent?
2) Deriving technical view from business view allows to have more stable policies because in my (very very short) experience I’ve saw more stability on the business requirement than that on the technical one. Technical side of policies could be more fragmented, detailed and sometimes system dependent and for this reason more subject to modifications when changes happen in the technical infrastructure (mergers, new systems, etc.). In my opinion, this approach allows to keep unchanged business view and most of the decisions related to the tech view.
Are, in your opinion, my assumptions valid?
Posted @ Wednesday, April 14, 2010 2:47 AM by Luca
Hi Luca,
I'd agree in general that business process development should happen before technical analysis, (as I've mentioned in other articles here).
In order to think through this, I posed myself the following: should the following 2 questions (1 business process oriented, the other technically oriented - as defined in the article) be answered in a specific order?
1. Should a leave of absence translate to termination of access?
2. What should happen to a person's shared folder contents once terminated?
Thinking through this, the 1st question should be posed to the business process owner - whose answer will provide context to the technical owner to answer his part of the question...since a leave of absence (as a state) will probably have a direct impact on how long to hold on to a person's mailbox or shares. And will probably have a different impact on a person who was terminated for cause.
So yes...I agree. Thanks for the insight, Luca!
I'd agree in general that business process development should happen before technical analysis, (as I've mentioned in other articles here).
In order to think through this, I posed myself the following: should the following 2 questions (1 business process oriented, the other technically oriented - as defined in the article) be answered in a specific order?
1. Should a leave of absence translate to termination of access?
2. What should happen to a person's shared folder contents once terminated?
Thinking through this, the 1st question should be posed to the business process owner - whose answer will provide context to the technical owner to answer his part of the question...since a leave of absence (as a state) will probably have a direct impact on how long to hold on to a person's mailbox or shares. And will probably have a different impact on a person who was terminated for cause.
So yes...I agree. Thanks for the insight, Luca!
Posted @ Wednesday, April 14, 2010 5:42 AM by Ash Motiwala
Posts
