The architecture of ESBeetle enables us to support any Interface as a Service request within single days.

Important things to notice:

• Each client’s data are processed in dedicated Virtual Private Cloud (VPC) – there’s no way that solution for one customer will get an access to data being processed for a different customer.
• For all communication cases with external world secure channels are employed, e.g., https, sftp, VPN connections.
• Apart from standard AWS security measures, we introduce encryption (AES) for all sensitive data being processed basing on customer’s expectations.

We’re following security best standards and practices developed over the years during our work with the cloud and basing on wide AWS community experience. 

The fundamentals of Amazon’s security we leverage to bring safety to our customer’s data are:

• A solution for a customer is contained in separate AWS account, in a dedicated set of cloud assets located in distinct VPC.
• Deployment of a solution for a new customer is automated as we are leveraging AWS CloudFormation capabilities. This approach eliminates human error while preparing a fresh environment for new operations. Infrastructure templates are securely stored and maintained by competent staff.
• Security Groups together with IAMs precisely define access grants between resources at the level that’s necessary for their operations.
• Least knowledge principle is implemented when it comes to administrator access – there is no single master AWS account the can access all customer’s solutions.
• If it’s not necessary, we do not expose customer’s data to outside world, i.e., most of our databases, HDDs, S3 buckets are available for reading or writing only through internal network interfaces – that means no one from the internet can see them.
• There are a number of security buzzers based on AWS CloudWatch, CloudTrail in place that notifies our maintenance staff of any suspicious or abnormal activities.
• Whenever customer sensitive data must be exposed to the internet, we are taking additional security measures to protect it:
  • in-transit-security is achieved by using secure protocols (SSL/TLS),
  • at-rest-security is achieved by encrypting data while it’s stored either on HDD, S3 or in a database.

Basing on our experience and successful implementation of multiple initiatives within integration domain, we came up with a simple recipe that allow us to bring transparent, reliable and secure solution to our Partners and Clients. 

• Edge system connectors always use encryption protocols. If that’s not possible due to system’s limitations, a VPN connection is established between our and customer’s network that is meant to secure data flow.
• If it’s possible, we avoid holding the state of in-transit data.
• If the above can’t be achieved, we encrypt all sensitive interim data and store them using the most appropriate persistence layer offered by AWS (RDS, S3, EBS, DynamoDB, etc.).

Thanks to all above we are the best way to enable  communication within your organization. Start with Interface as a Service and decide if you want to have a full SOA implementation or you will go in Hybrid Integration Platform scenario.