The Best in the Biz Chat App
Data Security
This page describes the measures of customer confidential data protection.
Encryption
We encrypt both the storages attached to EC2 instances hosting the application, AWS relational database (RDS) and also encrypted disc volumes allocated for MongoDB.
The data is protected by encryption at rest and in transit with AWS options and key management to support the encryption process for stored data.
Encryption at Rest and In Transit
Chazbiz uses the latest recommended secure cipher suites to encrypt all traffic in transit, including the use of TLS 1.2 protocols, AES-256 encryption. Data at rest in AWS relational databases are also encrypted by AES-256 encryption standards. For more information about how AWS encrypts data at rest see: https://d0.awsstatic.com/whitepapers/AWS_Securing_Data_at_Rest_with_Encry ption.pdf
With the aim of using the tools that implement our own Encrypted solution, we selected MongoDB as one of our database providers. MongoDB has adapted its database services to ensure the protection of PHI and sensible information. Particularly, the database meets the requirements for user authentication and authorization, system security audit, and encryption of data at rest.
For data traffic between AWS EC2 instances, we use the Amazon VPC with its integrated encryption mechanisms. For data exchange between the MongoDB database and external sources, we implement TLS/SSL encryption mechanisms with the help of stunnel TLS Proxy ensuring secure data traffic to and from the database.
For data caching, we use the Redis database that encrypts its data traffic with the help of Spiped utility.
Key Management
Chazbiz uses the AWS Key Management Service (KMS) for handling the lifecycle of the data encryption key, which applies access controls for the key’s generation, usage, and revocation.
Incident Management
Incidents are carefully investigated, documented, and reported to Dedicated CSR/ Incident manager and back-end team for timely mitigation, including suspected or known violations of privacy and security.
Network Security
The SDK synchronizes with the application server over a WebSocket connection secured by HTTPS using TLS 1.3.
Sync Session Process
To initiate, execute, and terminate a Device Sync session, a Realm SDK and application server send and receive a set of protocol-specific requests.
The SDK negotiates a WebSocket connection over HTTP and then establishes a sync session by sending BIND and IDENT requests to the server over the WebSocket connection. Once the session is established, the SDK and server send synced change sets for a given Realm file to each other via UPLOAD and DOWNLOAD messages. To end the session, the SDK sends an UNBIND request.
| Realm SDK App Server |
| | | |
| | <—- 1. HTTP Handshake —–> | |
| | | |
| | ——— 2. BIND ———–> | |
| | | |
| | <– 3. IDENT (first time) —- | |
| | | |
| | ——— 4. IDENT ———-> | |
| | | |
| | <—- 5. UPLOAD/DOWNLOAD —-> | |
| | | |
| | ——— 6. UNBIND ———> | |
The sync protocol is primarily handled over a WebSocket connection between the SDK and the server. To establish a connection, the SDK sends a handshake HTTP request that includes the following:
a protocol version
a WebSocket key
a valid access token for an authenticated App Services application user
The server sends an HTTP 101 Switching Protocols response that specifies a WebSocket connection for the SDK. The rest of the sync protocol occurs over this connection.
To begin a sync session, a Realm SDK sends a BIND request to a Device Sync server. The request identifies a specific local Realm Database file to sync and includes a WebSocket connection key that the server will use to open a bidirectional connection to the SDK.
If the SDK is attempting to sync a particular Realm Database file for the first time, it does not yet possess a server-generated client identifier for the file. In this case, the BIND request also indicates that the Device Sync server should allocate one
If a BIND request indicates that the SDK needs a client file identifier, the Device Sync server generates a unique value for the specified Realm Database file and sends it to the SDK in an IDENT response. When the SDK receives the IDENT, it stores the new client identifier persistently in the local Realm Database file.
An SDK only needs to request a client file identifier the first time it syncs each Realm Database file. For subsequent sync sessions, the SDK can use the persisted identifier.
Once an SDK has initiated a sync session with a BIND request, it must identify the local Realm Database file that it wants to sync. To do this, the SDK sends the application server an IDENT message that contains the client file identifier. If the SDK has previously synced the realm with the server, it can specify the most recently synced server version to optimize the sync process.
When it receives the IDENT message, the server establishes the session. The SDK and server can can now freely send upload and download sync changesets at any time.
Once a sync session is established, the SDK and server can freely send and receive UPLOAD and DOWNLOAD messages to sync changes whenever they occur.
The SDK sends an UPLOAD message for every changeset it applies except for those that it received in a DOWNLOAD message from the server.
When the server receives an UPLOAD message, it applies operational transformations to resolve any conflicts with other changesets and then applies the transformed changeset to the server version of the realm. This triggers the server to send DOWNLOAD messages to other connected clients, including the synced Atlas cluster which mirrors the server realm. A DOWNLOAD message groups one or more transformed changesets in chronological order from oldest to most recent according to the server’s history. The SDK applies the changesets in the same order.