Created
December 20, 2017 00:08
-
-
Save zznate/fc9892590aacbec8b165743518e0f3a3 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There are three main components to the security features provided by Cassandra: | |
- TLS/SSL encryption for client and inter-node communication | |
- Client authentication | |
- Authorization | |
By default, these features are disabled as Cassandra is configured to easily find and be found by other members of a | |
cluster. In other words, an out-of-the-box Cassandra installation presents a large attack surface for a bad actor. | |
Enabling authentication for clients using the binary protocol is not sufficient to protect a cluster. Malicious users | |
able to access internode communication and JMX ports can still: | |
- Craft internode messages to insert users into authentication schema | |
- Craft internode messages to truncate or drop schema | |
- Use tools such as ``sstableloader`` to overwrite ``system_auth`` tables | |
- Attach to the cluster directly to capture write traffic | |
Correct configuration of all three security components should negate theses vectors. Therefore, understanding Cassandra's | |
security features is crucial to configuring your cluster to meet your security needs. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment