Is the Provisioning approach really all that bad?? - it doesn't have to be. There are things that you can do to guard against the pitfalls.
For example... if the provisioning system you are looking at deploying has as its first dialog, do you want to "Create a New User" or do you want to "Modify an Existing User" - run the other way as fast as you can. The first dialog should be...
"Enter the demographic data for the person you wish to operate on: " By getting the name, phone number, SSN fragment DOB, or other personally identifying info, you have a chance of making it out alive. By getting this info first, you allow the system to see if there appears to be a match in the provisioned system already. (And for the love of God, - don't perform the match check on any variation of name!).
Even better, use a different identifier altogether. Look at all the new measures that banks are taking in order to make sure that they have the right person. Have you forgotten the password to your online banking account lately? If you have, you probably have seen the need for going back to the basics of system authentication: "something you have, or something you know". For strong authentication, require 2 forms of authentication in serial. The point is, once a bank establishes an account (checking or savings account); they associate that account with an Identity (with a capital "I") and all access from the consumer side requires comprehensive knowledge of the Identity details. From the provider side, no action is taken until the authentication happens. A new "create" event for an account should only be programmatically allowed after there is a substantiation that the data entered matches no existing Identities. For a "modify" event - it must perfectly match an existing Identity...
Note: I said Identities, not accounts. Your system design may require that an Identity have multiple accounts, and in almost any modern real-world system, likely will. This point of contention must be addressed. Programmatic controls must be devised that link new / existing accounts to the correct Identity. Without solid Identity data that is linked to personal attributes (date of birth and SSN leap out) you can't strongly ensure appropriate Identity matching.
So - fun detour; back to avoiding the pitfalls of the Provisioning approach; - if you firmly establish a process for acquisition of personal data at all provisioning "points of administration" prior to account actions, you stand a chance. The trick is to acquire the data and still honor organizational requirements for privacy and security. There are actually some very straightforward ways for achieving this that I will hopefully address in a post fairly soon.
Bottom line - in your design phase, make sure that you establish the difference between an Identity and an account. Make sure that you establish the Identity before any / all of the account actions. What is required for your organization will be different for another organization. Talk to your lawyers / Chief Privacy Officer about what they feel needs to happen. By all means, get down into the weeds about what will be the possible relationship between accounts and identities. Will it be possible for an account to have more than one owner? (Think of a joint checking account that a husband or wife share.) In the corporate LDAP world, a service account may require (or be allowed) more than one owner. All Secondary accounts need to be linked to a primary. In this case, the primary is tightly coupled to the Identity, and the secondary is coupled to the primary. Your design should include smooth handling of all instances where a secondary or primary account goes away, and the Identity is retained; in accordance with your organizational needs / regulatory requirements.
Above all - look at your environment, if you are creating accounts based on arbitrary, "non-business event driven" conditions, you will have a major headache in some amount of time. The smaller, less complex your environment is (under 5,000, or 2,000 accounts) the more the issue may be masked. When your environment is complex, or large (more than 10,000 complex accounts) it will very quickly become apparent.
Again, everything in this post addresses an approach to account provisioning that offers alternatives to direct, comprehensive linking of Authoritative Source data to operational account data. Use Authoritative Sources as much as is practical. This is another careful consideration in your design phase. Provisioning needs to happen for systems that offer discretionary services. This is a rabbit hole trip down into RBAC theory, and will be saved for another lesson, but an example may be an account in the corporate email system, or certain services for an ISP. Someone may be approved to, or buy into access to a system that is completely discretionary. Before you take action in that system, adhere to the principles we are discussing.
No comments:
Post a Comment