Lately, we've been talking a lot about credentials for web services. It seems that most of the concern in the market focuses on the strength of our passwords and silly mistakes like using the same one everywhere. Other thought pieces fixate on the shift towards new technologies, such as whether cross-auth mechanisms like Facebook Connect are good or not. But if you provision web applications to users, there is a much more profound issue regarding passwords, and it’s pretty basic.
If your users know their credentials to websites, then you have no way of controlling what they do with your data. For businesses with simple requirements, this might be a nuisance. But if your business requires that users abide by certain data policies, this can cause real problems.
By giving users their own credentials, you're allowing them to access web services from any computer and unable to keep them from downloading your data to places they shouldn't. Vendors don't give admins the level of policy controls needed to safely deploy web applications.
Let’s say you're an admin at a company that deals with patient health information and therefore need to abide by HIPAA compliance guidelines. You're a progressive business, and you've embraced the cloud.
You've become comfortable with salesforce.com and their HIPAA compliance, so you start putting patient data in their system.
Now let’s say that you have a mobile workforce that is monitoring clinical trials, and those users need to access your cloud services from a variety of locations and maybe even from different computers -- that's the beauty of the cloud, right? Well, you can't do that without undermining your HIPAA compliance. HIPAA mandates formal protections around who can access and how data is handled. If a user accesses patient data through a browser on an untrusted machine, there is a real risk that the data gets downloaded and stored in a non-encrypted format on that machine -- and you as the admin wouldn't have any idea.
What about the policy controls built into web applications? Well, let's look at salesforce.com again as a leading example.
Salesforce.com offers configuration options that let you better control access from non-approved or "non-whitelisted" locations. If users log in from somewhere other than the whitelisted network, the system can prompt them for a second-factor challenge -- basically an email to the user with a link to confirm their request. Click the link, and the location is approved and the session is allowed. This does help minimize access from unauthorized users, but it doesn't keep the proper user from accessing the data on a machine outside of IT control. It's simply a tool to more rigorously verify the user, not enforce a data policy.
Salesforce.com offers an additional (and more hidden) access control called "Login IP Restrictions." Login IP Restrictions basically say that a user can only log in from a particular, predefined range of IP addresses. That means no off-network (or not-previously whitelisted network) access. But this is a very blunt control and basically undermines the "access from anywhere" utility of the cloud. It is a conundrum for admins -- they want to gain the benefits of the cloud, but taking advantage of those benefits may jeopardize their compliance.
This isn't meant to throw rocks at salesforce.com -- what they've done is necessary to maintain HIPAA compliance, and frankly, they're out in front of most of the other cloud vendors. Do a little Google searching, and you'll see that if any controls are available across other web applications, they're inconsistent and incomplete.
As an industry, we've taken a step backward with the cloud. In the old world of on-premise apps, Access Control Lists (ACLs) were the workhorse of data security and policy. When you controlled the machine, the network, and the app, it was easy to control who had access to what data and from where. But equivalent controls don't exist across the array of third party web services. "Fail closed" like salesforce.com is not a usable option if mobility is key to your business.
What organizations need is a more adaptive approach to implementing policy for access and use of web applications. At Authentic8, we think this is probably the critical missing ingredient of the cloud.
Wouldn't it be great if users could access web services through a browser that was able to adapt policy based on a set of variables? For instance, say a user logs in from their work-provisioned machine that has full disk encryption. In this case, the policy allows them to connect and get a full-featured experience including data upload, download, and more. But say that same user connects from a shared computer at the client's facility. Well, maybe that's OK; however, a different policy is triggered which requires more rigorous validation of the user's identity, allows the user to view but not download data, sets a shorter session time out, and purges all local data if the session goes inactive. In this scenario, the policies would be enforced within the browser the user was using across all their web applications.
Sounds too good to be true? Well, it's one of the key areas we've been thinking about when building Authentic8. Stay tuned, it won't be long...