You can also use TLS to make sure the data has not been tampered with whilst traveling the network. This is especially important if we don't control the network. If data includes private information, SSN number, credentials (password, username), credit card numbers or account numbers, then we want to make that data unintelligible (encrypted) to any and all 3rd parties. Encrypting the transportsĭata that travels over the client transport across a network could be accessed by someone you don't want accessing said data with tools like wire shark. Later articles will cover various aspects of compliance and encryption. This article will focus just on setting up encryption for the Cassandra client transport (CQL) and the cluster transport. Cassandra’s has essential security features: authentication, role-based authorization, transport encryption (JMX, client transport, cluster transport), as well as data at rest encryption (encrypting SSTables). Or it just might be a corporate policy to encrypt such transports.Īnother area of concern is for compliance is authorization, and encrypted data at rest. Or you might work for a bank or other financial institution.
The Payment Card Industry Data Security Standard (PCI DSS), or U.S. Health Insurance Portability and Accountability Act (HIPAA), Germany’s Federal Data Protection Act, You may work in an industry that requires the use of encrypted transports like the U.S. Also if possible avoid using TLS/SSL on the client transport and do client operations from your app tier, which is located in a non-public subnet. If possible, use no encryption for the cluster transport ( storage transport), and deploy your Cassandra nodes in a private subnet, and limit access to this subnet to the client transport. This is especially true in the JVM world which is not as performant for handling SSL/TLS unless you are using Netty/OpenSSl integration.
Cassandra allows you to secure the client transport (CQL) as well as the cluster transport (storage transport).
0 kommentar(er)
