“Shadow IT” hints at people doing bad things to deliberately make life difficult for the IT Department, and sounds as if the phrase probably originated in IT. Shadow IT often refers to people in a company using SaaS applications that have not been officially blessed by IT. However, they do so not just to annoy IT, but because they’ve found applications and tools that make their lives easier, allow them to work faster in a way that suits them, and ultimately make the company (and hopefully themselves) more successful.
In this blog post I’ll attempt to explain how IDaaS (Identity as a Service) can be used to help companies address issues brought about by Shadow IT.
The main problem with Shadow IT is security. End-users and their lines of business seek out applications that help them work, whereas the focus of IT is security. And as IT is usually responsible for the corporate data that finds its way into the SaaS applications, IT needs to know what’s going on.
There are many surprising (and frightening) statistics available detailing the widespread use of non-approved SaaS applications in companies, and quite a few tools available that IT can use to identify them. Once IT has tracked these apps down, what then? Should IT block their use, or try to find a way to allow the applications in a way that works for both IT and the business? If we accept that the “rogue” applications are satisfying a genuine need, then it will help everyone if it’s easier for IT to sanction and securely enable the business to use them. Also the fact that very often both users and SaaS applications are outside the firewalls makes it very difficult for IT to block them anyway.
Application security starts with authentication. Will users need yet another identity to authenticate to these apps? Are strong passwords required that need to be changed regularly and can’t be rotated ? Will accounts be locked if the account has too many failed login attempts, possibly caused by a brute-force attack? Is there a robust and secure unlock process for accounts locked by excessive login failures? Does the application provide multi-factor authentication?
Users must be encouraged to ensure authentication is secure. The best way to do this is to extend existing corporate IT password policies and procedures leveraging a user’s corporate identity to authenticate to applications wherever they may be, and from whatever device they’re using – whether on-premises or remote. Access must be able to be authenticated to in-house developed apps or external SaaS apps, such as those often used for file-sharing, payroll, CRM, collaboration, and so on.
This is where Identity as a Service, or IDaaS, will help. Using an IDaaS solution, such as the Centrify User Suite, the user logs on once to their corporate Active Directory, and that is the only time they will need to enter their password, as SAML and other standards are used to provide SSO (Single Sign-On) when applications are accessed.
IDaaS has other benefits too. It can introduce multi-factor authentication to applications that may not provide it. Different levels of authentication can be used based on a number of criteria, such as the user’s location or time of day. Finally, IDaaS solutions make it far easier to de-provision a user when they change departments or leave the company, simply because there is only one identity involved from which all access control flows. The fact that the interface of choice to apps is often a mobile device means that the IDaaS solution should also be able to ensure the device is locked down securely and the application lifecycle managed (such as delivering apps to the device and allowing remote lock/wipe in the event of loss or theft).
There you have it, a win-win for users and IT. Users can be assured of a smoother and more secure experience using the applications they like, and IT can make sure that access (and removal of access) to applications and configuration of applications and devices is under control.