We often get asked about security at Bonsai. How do you ensure only I can see my data? What kind of encryption do you offer? What if my credentials are compromised?
1. Unique, Randomized URL
We offer several levels of security to all customers by default, and it starts with your cluster’s hostname. Each cluster is assigned a unique, randomized subdomain known only to the customer. This is a fairly standard practice for cloud hosting providers (consider, for example, AWS Elastic Load Balancer or CloudFront URLs).
The randomized hostname is security by obscurity: a good start, but not the full story. A useful global identifier against which we can attach more tools.
Clusters are also provided with access credentials, which are required for all requests. The extra layer of credentials makes it impossible for an attacker to randomly guess the right combination to your cluster, and also provide a means of periodically replacing access credentials.
Altogether, this cluster URL with credentials should be treated as sensitively as any other database password, and only accessed from an application you control and trust.
We support HTTPS on all of our clusters by default, providing encryption of all traffic in transit via recent TLS encryption algorithms.
Encryption in transit works alongside your randomized URL and credentials, helping to keep both private from any prying eyes. Not to mention the contents of your data and search queries as your application interacts with the cluster.
Like any good network administrators, we operate under the principle of least privilege. Our servers are all tightly firewalled away from communication with the wider internet, for obvious security reasons.
Each cluster’s private URL — with proper authorization over an encrypted protocol — makes for a tightly controlled access path through our networks and over to your cluster’s resources.
This access to Elasticsearch is controlled and mediated by our custom-built, high-performance layer 7 routing proxy. This proxy serves as a central choke point where we can authorize and audit all of the traffic incoming to your traffic.
In addition to logging and access control, this proxy layer applies intelligent connection management policies to help ensure best access patterns and interacting with Elasticsearch itself. This lets us protect your cluster against unexpected traffic surges, but that’s a whole different kind of security that deserves its own article!
4. IP and Network CIDR Whitelisting
An additional benefit of our proxy layer is that it gives us tools to support more advanced networking functionality that are not present in a stock Elasticsearch deployment.
Currently in beta with select customers, we have the ability to also enforce IP and network CIDR whitelisting. This provides an extra level of comfort (or security compliance!) for customers whose deployments all route their outgoing traffic through a predictable network gateway.
5. Encrypted, Offsite Backups
Bonsai also ensures regular backups are encrypted and stored in a completely separate AWS account than the one that runs our servers. We use the bare minimum in credentials for access to backups to ensure that your data is safe from scrutiny, and always available for disaster recovery should the worst occur.
6. Encryption at Rest
Finally, we offer encryption at rest as a feature of single tenant clusters.
Generally speaking, we also have experience in designing and deploying clusters built to customer specifications in order to support sensitive data and comply with a range of regulatory policies, like HIPAA and Safe Harbor. Contact us with any specific questions you might have on security and compliance.