Bxp - End to End encryption and High Availability

1 Overview

End to End encryption : At no point between the users browser and data stored in the databases is the data ever unencrypted and is only accessible by the system owners. This is not to be confused with the E2EE paradigm ( http://en.wikipedia.org/wiki/End-to-end_encryption ) though its not far off and something All n One are working towards.

High Availability : There is no single device point of failure, there is physical backup for every point in the infrastructure.

Hosting

Firstly all of our storage is the secure operating facility of AWS in Ireland EU-west-1. For more information (https://www.bxpsoftware.com/wixi/index.php/The_bxp_Infrastructure)

bxp uses an n-Tier design architecture ( http://en.wikipedia.org/wiki/Multitier_architecture )

2 Logical Architecture

2.1 End User Browser

The first part of the data journey starts with the end users browser. All communications with the bxp service are encrypted using an SSL certificate verified by Thawte.

For more information on HTTPS : HTTPS_and_Thawte_SSL

2.2 Firewall Tier

The Firewall tier is implemented using AWS network Firewalls. More information (https://www.bxpsoftware.com/wixi/index.php/The_bxp_Infrastructure#Security)

2.3 Load Balancing Tier

The load balancing tier decrypts and re-encrypts the packets to add extra security information vital to the bxp service, including the remote users IP address.

The load balancers detect slow down and the responsiveness of the web tier and swaps users seamlessly between servers to ensure the fastest response times possible to our end users.

The load balancing tier is designing in such a way as to allow numerous other load balancers to be added into the infrastructure seamlessly as demand requires.

This is provided by AWS application and network load balancers. For more information (https://www.bxpsoftware.com/wixi/index.php/The_bxp_Infrastructure#Load_Balancing)

2.4 Web Tier

The web tier is implemented using the High Availability Microsoft Internet Information Server (IIS) again in an architecture way that allows numerous servers to be added as demand requires.

It is finally at this tier that the encrypted SSL packets from the users browser are decrypted and used. Instructions at this stage usually require some form of database interaction. Communications from the web servers to the database tier are then encrypted using SSL over ODBC. ( http://dev.mysql.com/doc/refman/5.6/en/ssl-connections.html )

At no point is decrypted data stored on the IIS server.

2.5 Database Tier

Finally the data, such as a customer record, reaches the database tier. The data is stored in a primary server, with a secondary mirroring backup server in identical configuration logging the data.

The data from IIS is decrypted and stored in the database.

However the hard drives in the database server are also encrypted at the operating system level. The term for this is that "the data is encrypted at rest". ( http://technet.microsoft.com/en-us/library/cc732774.aspx )

All data backups at this point are encrypted into Zip files using AES 256 encryption. ( http://www.winzip.com/aes_info.htm )