April 2016CIOAPPLICATIONS.COM 19Reth nking the Ways of Utilizing CloudPrasad Ramakrishnan, CIO, Veeva SystemsChallenges in Web Services Arena Web services, is a term that is commonly used, and sometimes mis-used. Web services are based on XML and leverage three core tech-nologies, SOAP, SDL, and UDDI to deliver the "service." In the pre-web services era, companies used Electronic Data Interchange (EDI ) standards to communicate business transactions between business applications. We can use web services to communicate between our internal business applications and external SaaS applications. While this is a handy way to communicate between disparate applications, un-less you have a security model around web services, you don't realize that you are potentially opening up your corporate assets and data to prying eyes. Some of the other security issues include: unauthorized access, parameter manipulation, network eavesdropping, Denial of Service (DoS) attacks, etc. Application architects need to be judicious with the what, the how, and the why of exposing functionality via web services. You need a series of checks and balances to prevent against runa-way queries and an external manageability layer, to effectively moni-tor and manage your web services. We also suffer from the law of unintended consequences where a publisher of a web service provides a window of opportunity to po-tential reconnaissance--which could then pave the way for a future targeted attack. Also, the publisher of the web service in most cases does not know the real and final end user. The end user accesses the service via a web browser by passing credentials. Architects need to keep these considerations in mind. Web services also increase the level of complexity for develop-ment organizations. Development teams have to factor both inter-nal and external stakeholders, as well as backward compatibility considerations before releasing new code into production.Implementing DMZ and FirewallsBefore AWS, you secured corporate apps within your own firewall and then granted access to those applications to people within your network. We protected the crown jewels and intellectual property by implementing Demilitarized Zones (DMZ) and multiple layers of firewalls. The minute you put something on AWS, such as your busi-ness applications or your data warehouse, you need to make sure only people in your network are granted access. Most IT practi-tioners overlook the potential exposure to company assets when deploying applications on the cloud (AWS or Azure). This would not have been an issue to consider with an internal on-premise or on-co location deployment. You need to architect and im-plement a VPN tunnel between your physical network and the AWS network and implement a virtual private cloud. That trans-lates to an extra level of overhead that you need to architect and maintain. When you put an application on AWS, you also need the cor-responding tools that can provide insight into the performance of that app at the server level and at the platform level. That means you must still invest in tools for proper app management and maintenance. CIOINSIGHTS
< Page 9 | Page 11 >