<iframe src="//www.googletagmanager.com/ns.html?id=GTM-MRFNVD" height="0" width="0" style="display:none;visibility:hidden">

Something Powerful

Tell The Reader More

The headline and subheader tells us what you're offering, and the form header closes the deal. Over here you can explain why your offer is so great it's worth filling out a form for.

Remember:

  • Bullets are great
  • For spelling out benefits and
  • Turning visitors into leads.

Soha Blog

Application Access in the Public Cloud is Broken

[fa icon="calendar"] Jan 26, 2015 4:38:20 AM / by Haseeb Budhani

Building out an application infrastructure in a public cloud (e.g. AWS or Azure) can be a liberating experience: No hardware to order and maintain; no WAN bandwidth contracts to worry about; even application images are available in the various public cloud market places. But when it comes to setting up a secure perimeter for your applications, the only models available are the ones that were designed for the cold, dark days when traditional data centers were the norm.

Consider the options available to enable secure access to AWS- or Azure-based applications for end users:

Option # 1: The Application Delivery Controllers (ADCs)

There are a number of ADC (or reverse proxy) options available that can be deployed in front of your cloud-based apps. Such solutions certainly provide a level of protection by adding an SSL layer to application traffic and optionally providing coarse services such as SYN flood protection and web application firewalling.

What If you want to set policies based on the identity of the user accessing a given application? Tom is allowed access to SharePoint but not to Jira. What would it take to build this logic without delegating all access control logic to the end application? The answer usually involves some level of scripting and possibly a software upgrade on the ADC.

Even if the ADC in question has an authentication proxy as an (expensive) option in place, how do you tie the ADC to your identity source that may be deployed in a different location?

 

Broken approach # 2: Virtual Private Networks (VPNs)

This is the de facto approach to enabling access for employees to critical applications. VPN generally require clients to be installed on endpoints, the distribution of which may become a challenge. The biggest challenge with VPNs is that they give the end user network access (its in the name!) and not just application access. Have you thought through the possible attacks that a bad device could carry out against your network if its given free rein in your network?

What If you run applications in multiple VPCs across multiple cloud providers? How many VPN gateway will you set up and how many VPN clients will you configure on all the endpoints out there?

What if you need to give your offshore QA team (or any other 3rd party) access to a single application? How do you ensure that these remote users (who may not even work for your company) don’t have network level access to your entire infrastructure? If your answer is micro segmentation, how much time and money did you spend building out a complicated network to ensure that certain packets (based on where they are coming from and where they are going) are routed a certain way?

 

Broken approach # 3: IP white listing

If you rely on security groups to control user access to applications, you already know how bad this option is.

We’ve had a number of companies tell us how they need to update IP whitelists every few days because the WAN IP associated with a particular remote user's cable modem or DSL just changed. This example speaks to the operational pain associated with managing IP white lists, but consider for a minute that one of your remote users may be sitting behind a NAT, and her public IP is in fact also the public IP for a few thousand random people. Are you sure none of these people are running scans against your cloud infrastructure to see if they can find a chink in someone's armor?

** ** ** ** **

Options (1) and (2) above are tried and tested solutions for secure application access and work reasonably well in traditional data centers. So what’s the problem in the cloud? The simple answer is that the cloud inherently allows customers to distribute their infrastructure across geographies, whereas traditional networks were built around a single, well-controlled entry point (the DMZ) behind which companies deployed a pair of ADCs, a pair of VPNs, and so on. Simply put, networking and security infrastructure that worked in a traditionally data center will more than likely have architectural challenges if you try to force-fit it into a cloud environment.

If you’re deploying applications in the public cloud and are evaluating traditional solutions, you should talk to us first. Not only have we addressed the issues I have outlined above, we have built a solution that is fundamentally more secure than traditional solutions and reduces your risk down to a supremely manageable size. I can guarantee that the engineer in you is going to love the elegance and security model of our solution.

Questions? Comments? Please feel free to get in touch.

Topics: Cloud, Engineering, AWS, Blog, Security

Haseeb Budhani

Written by Haseeb Budhani