Security 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.
