Internally, the application had only trusted users. Often, internal authentication services, such as LDAP and Microsoft Active Directory, are based on protected internal databases and used for secure user access and logging of user traffic.
Challenge: If there has not yet been any user management, solid and secure user management has to be developed and used 'on the cloud.' If the application continues using the current authentication services, the challenge is whether the user's credentials should be 'replicated' and made available on the cloud - if so, how can this be done in a secure way? Or should the user access management on the cloud ask in a secure way (i.e., through a VPN tunnel) the internal authentication databases? Therefore, the user's credential database does not leave the secure enterprise infrastructure, but the communication with it has to be secure.
Applications are typically built from the ground up using programming languages, such as PHP, JAVA or .NET by an internal development team or a third-party vendor with “For Internal Use Only” in mind. There has been a general assumption by development teams that users can always be trusted, the application will be used “as intended,” and all information (i.e., user data) and content (i.e., product data from databases or ERP systems) are coming from safe and secure sources.
As cloud computing becomes more favorable among companies, they are forcing their applications out of the internal network into the cloud, causing them to be vulnerable to Web threats. If the application, or part of the application, is moved into the cloud, there will be typically less security within the infrastructure and several more users will be accessing it. Therefore, vulnerabilities turn up and hacks occur. The following are typical challenges enterprises face when moving an application to the cloud, prepared by security vendor Art of Defence.