Security in the Cloud: Protecting Your Applications

motif

around public cloud offerings has always been a major point of concern (and controversy) for users. How do cloud providers protect customer data? How is log data protected? How is the surrounding infrastructure secured? We previous talked about how iON stays up and running even through EC2 outages. Today, we will talk about iON security to show how we protect customer information and the infrastructure used in building iON.

Meet iON’s Custom VPN Solution

The heart of iON’s security lies with our custom VPN solution. We were forced to build our own VPN, which is a combination of OpenSwan and IPsec, for multiple reasons.

  • At the time that we started developing iON, AWS did not provide a VPC solution that spanned across different EC2 regions.
  • Our MongoDB replica set-up has 2 nodes: 1 in the US-East region of 1 node in the US-West region of EC2. Moreover, Mongo does not have any in-flight encryption as part of its native functionality .
  • Elasticsearch did not offer an authentication mechanism out-of-the-box, nor does it currently have any data encryption functionality.

iON’s air-tight VPN setup contains both Mongo and elasticsearch within it as shown in the diagram to the above. Upstart scripts are used in order to ensure that the VPN is always fully started and configured before either Mongo or elasticsearch are started. Moreover, both Mongo and elasticsearch are set up with an IP address that is only recognized when it is within the VPN.

Protecting Customer Data

For an extra layer of security, authentication for all of the Mongo replicasets has been enabled. Before any data is written or read from, the iON web aplication also must authentication against Mongo using a specific API-only user.

Reading and writing data from elasticsearch requires a log token. This token is unique for each application. When an application reads or writes data, it must present the correct token to the logging aggregation tier. This tier then validates that token against a token service, and if it matches, then it completes the log request (either the read or write), as shown in the diagram to the right.

This also ensures that no other applications can access your log data. Because each server has its own token as well, if an application with domain abc were deleted and a new application with that same domain name were created, the token would be different, so none of the log data from the deleted application would be displayed.

Application Security

HTTPS support for applications is done by automatically forwarding requests on the normal HTTPS port via nginx, our load balancer. For security of the Mule instance itself, iON automatically configures AWS security groups for the workers to ensure that no other applications or users can access them. The iON console application itself uses Apache Shiro for authentication and authorization.

Connecting Your iON Application with Enterprise Data Sources

The Secure Data Gateway (SDG) can be used to securely connect your iON application with data sources that are on-premise. In order for your iON application to access your data sources, the SDG client must be installed within the firewall of where the data sources are running.

The SDG client sets up an SSH tunnel (using user-provided hosts and ports) and uses reverse port-forwarding over HTTP to connect to the requested endpoint on all of the application’s workers. As a result of this, the communication between the SDG client and the iON web application is all done via HTTPS. In order to establish the connection, the client must present the correct private key, which corresponds with a public key on each instance. This key-pair is unique for each application.

In Conclusion…

Now you have learned how iON’s infrastructure is laid out, how it resists EC2 outages, and how it stays secure. Try it out and deploy an application on iON – it only takes 10 minutes to get started! Stay tuned for more news about additional platform services that will be released shortly for iON.


We'd love to hear your opinion on this post


2 Responses to “Security in the Cloud: Protecting Your Applications”

  1. Sweta,

    Excellent post. The part I am not following is “OpenSwan and IPsec”, since OpenSwan is an implementation of IPSec for linux. What do you really mean with this?

  2. Thanks Andrés! You are right – OpenSwan is an implementation of IPSec for Linux. To clarify about our set-up a bit: We use OpenSwan, but we actually had to do quite a few customizations in order to get it to work with EC2 NAT and be able to have the VPN span multiple EC2 gions. This post explains it in some more technical detail.