How to Integrate Cloud Applications with Dedicated Utility Accounts

    

With all the cloud products and applications now available, more organizations are finding it valuable to integrate them, such as linking Salesforce.com to your accounting package so data from both can be viewed together. However, as companies integrate cloud accounts, we’ve noticed a number of them run into problems maintaining those integrations down the road. When integrating cloud accounts, you often need to choose an internal user account to create the bi-directional connections and truly link the applications. For example, if we were to connect Hubspot to Salesforce, we would need to enter a Salesforce account (username and password) into Hubspot. This process works fine until the person who owned that Salesforce account leaves the company. When that happens, the integration you previously had is now useless.

One company we talked with said they completely removed an ex-employee’s accounts which had been used as the account to link cloud applications. They didn’t know all the places his account was being used, so they re-provisioned it. But that ended up causing all kinds of problems. “Everything broke” is how they described it to us. 

Integrating cloud applications

Obviously that’s not the right way to handle it, but it’s not uncommon, and raises a valid question.

How do you get around this issue of keeping your cloud integrations in the face of inevitable employee turnover? 

We’ve found one way to avoid this problem – the creation of “utility” accounts.

In addition to personal accounts, organizations should create “utility” accounts used specifically to connect cloud systems. For instance, salesforce-connector@idauto.net and HR@idauto.net are two examples of utility accounts. These utility accounts aren’t associated to any one person, so when someone leaves the company, any integrations that use them are uninterrupted. Additionally, by making utility accounts application-specific, we can manage our security around those applications, deprovisioning the account when we’re no longer using it, or limiting our risk in case the application provider is compromised.

Steps for implementing utility accounts

1.     Incorporate utility accounts into your IT policies. You should clearly state when, how and why utility accounts are used, as well as the steps needed to request and create a new utility account.

2.     Institute pre-defined utility accounts so some already exist when they’re needed or requested.

3.    Make your utility accounts easily accessible. A “set it and forget” attitude won’t work because occasionally a vendor will need to recertify the email address or your account through that address. Salesforce is one example of a company that does this. Multiple people from your organization need access to the utility accounts. If only one person has access to a connector account, you’ll run into the ‘old’ issue people experienced when using personal accounts.

4.    Place security parameters around the number of people who need access to the utility accounts. More than one is needed, but do ten people need access? Probably not.

Of course, I need to point out that technical solutions can only go so far. Companies are still reliant on people to implement and use them. If an “Innovative” rogue employee wants to connect two systems and the company makes it difficult to do so using one of the utility accounts, they’ll end up using a personal account. Your policies should show others in your organization that you support agile and innovative uses of technology. 

Done right, utility accounts provide consistent integration of cloud apps and also demonstrate agile IT policies to your organization’s staff.

is-your-legacy-iam-system-doing-more-harm-than-good

Additional Resources

Comments

Subscribe Here!