Tightening Security for Apache Cassandra: Part 1

Apache Cassandra is the open source NoSQL database for mission-critical data. Its adoption grows day-by-day in the industry, and it’s used by all sizes of organizations serving varied technical and business domains, such as IT Financial Services, Healthcare, Retail, Government, and Education, to name a few. You can find some interesting statistics from the 2020 survey about Apache Cassandra’s usage in the industry.

As the web traffic grows for business-to-consumer interactions, service providers need to ensure customer data is securely protected and the backing software can scale to handle growing demand without outages. Service providers use various technologies to support their business functions such as Online Transaction Processing (OLTP), serving internal analytical needs for customer insights, running risk and fraud detection systems, etc. As traffic grows, each sub-system and technology will need to scale with traffic while satisfying security requirements.

Primarily there are two avenues to consider for securing data: data in transit and data at rest.

Data in transit refers to the data traveling between computers over the network (sometimes referred as ‘over-the-wire’). For example, a customer’s credit card details travel to the service provider for payment processing, and, of course, customers expect that to be done securely.

Data at rest refers to the data digitally stored for durability. Like data in transit, data at rest needs to be secured with appropriate access control mechanisms and data encryption.

In this series, we’re focused on securing data in transit. We will cover the security aspects in more detail in Part 2, but first, a few basics of security followed by how Apache Cassandra enables operators with configurable options for securing data in transit, meaning between client nodes and Cassandra server nodes and from server to server.

TLS (Transport Layer Security) is an industry-standard cryptographic protocol to secure data over the wire between two computers. Typically, this is between a web server and a browser. It is a successor of SSL (Secure Socket Layer) protocol and many times you would notice SSL and TLS are used interchangeably by technologists for higher-level discussions. Here are some good guides for learning about TLS basics and understanding the TLS Handshake between client and server.

TLS requires the server to have an asymmetric key pair digital certificate. This enables the client to trust the server is what it claims to be, but the server will trust any client. In order to limit which clients the server trusts, you must provide the server with a similar certificate for each allowed client so the server can authenticate a client. This is also known as Client-TLS Auth, Two-way-SSL, Mutual-TLS, or mTLS (most commonly used) for short.

Apart from some higher level challenges with TLS, there are also operational challenges you will need to consider, which we will cover in Part 2. Next time, we will look at storing your private key and password, credential rotations, operations at scale, and how to configure TLS/mTLS on the server-side.

Head to our Security documentation section for more details.