smiklosovic commented on code in PR #4828: URL: https://github.com/apache/cassandra/pull/4828#discussion_r3283127238
########## doc/modules/cassandra/pages/reference/security-model.adoc: ########## @@ -0,0 +1,594 @@ += Apache Cassandra Security Model + +== Overview + +This document outlines the security model for Apache Cassandra, identifying potential security threats, +trust boundaries, and the security controls that protect against them. *This threat model assumes +that Apache Cassandra has been configured correctly from a security point of view, with its strongest +security settings applied*, including authentication (password-based or mutual TLS-based), +authorization (`CassandraAuthorizer`), TLS encryption for all communication channels +(client-to-node and node-to-node), and JMX bound to the local interface only with Cassandra integrated +authentication. Threats are evaluated against this hardened baseline -- not against Cassandra's +out-of-the-box defaults. Vulnerability reports that do not adhere to the assumptions outlined in this +document may not be accepted. + +This threat model is informed by +https://cassandra.apache.org/doc/latest/cassandra/operating/security.html[Cassandra's own security documentation]. + +== System Architecture + +Apache Cassandra is a distributed NoSQL database system with the following key components: + +* *Client Applications*: Applications that connect to Cassandra via the CQL binary protocol to + read/write data +* *Client Drivers*: Official Apache Cassandra drivers (e.g., Java driver, Python driver) that + implement the CQL binary protocol on behalf of client applications +* *Cassandra Nodes*: Individual database servers forming a peer-to-peer cluster +* *Inter-node Communication*: Gossip protocol and data replication channels between Cassandra nodes +* *Storage Layer*: On-disk SSTables, commit logs, and hints +* *JMX Interface*: Java Management Extensions interface for monitoring and administration +* *System Keyspaces*: Internal keyspaces (e.g., `system_auth`, `system_schema`) that store cluster + metadata, authentication, and authorization data + +== Root of Trust + +The root of trust for a Cassandra deployment converges to: + +* *The infrastructure operator*: The party responsible for provisioning and maintaining the underlying + hardware, operating system, JVM, and network infrastructure on which Cassandra runs +* *The Cassandra distribution*: The integrity of the Apache Cassandra software itself, verified through + official Apache release signatures and checksums (signed with keys from the + https://downloads.apache.org/cassandra/KEYS[Apache Cassandra PMC KEYS file]) +* *The JVM*: Cassandra runs on the Java Virtual Machine; the security properties of the JVM (including + its TLS implementation, cryptographic providers, and sandboxing) are assumed to be correct + +Before deploying Cassandra in a security-sensitive environment, operators should verify the authenticity +of the distribution and ensure the underlying infrastructure meets their trust requirements. + +== User Types + +Apache Cassandra distinguishes the following user types with different trust levels: + +=== Trusted Users + +* *Infrastructure Operators / Administrators*: Users with OS-level access to nodes running Cassandra. + They have access to configuration files (`cassandra.yaml`, `cassandra-env.sh`), data directories, JMX + interfaces, and can start/stop nodes. These users are fully trusted. It is the responsibility of the + organization to restrict who holds this role guided by the principle of least privilege. +* *Database Administrators (Superusers)*: Users with Cassandra superuser roles. They can + create/alter/drop roles, keyspaces, and tables, and grant/revoke permissions. They are trusted within + the CQL authorization model but should not require OS-level access. +* *Application Developers*: Users who write applications that connect to Cassandra. They are trusted + to use the CQL API correctly, construct safe queries, and manage credentials securely within their + applications. + +=== Untrusted Users + +* *Database Users (Non-superuser Roles)*: Authenticated users with limited, explicitly granted + permissions. They are not trusted beyond the permissions assigned to their role. The authorization + subsystem (`CassandraAuthorizer`) enforces their access boundaries. +* *Unauthenticated Network Actors*: Any party with network access to Cassandra's client or + inter-node ports who has not authenticated. Under this threat model's assumed configuration, all + communication channels require authentication and TLS, and JMX is bound to localhost only, so + unauthenticated connection attempts are rejected. These actors remain a threat only if they can + exploit vulnerabilities in the TLS handshake, authentication protocol, or network stack itself. +* *External Clients and End Users*: Users of applications that interact with Cassandra indirectly. + Their input should never be trusted by the application layer and must be validated before being + passed to CQL queries. + +== Data Sources + +=== Trusted Sources + +Cassandra trusts the following data sources. It is the responsibility of the deployer to protect them: Review Comment: we should probably also mention all possible extension points Cassandra offers in the fashion of implementing an appropriate interface (ICompressor, IAuthenticator, ISeedProvider ...). Also all SPIs. Basically, anything an operator puts on class path and Cassandra picks it up one way or another is trusted too. We do not have control over third party implementations. Given that these implementations might in theory contain any Java code, basically, they can hook into Cassandra's internals freely and call whatever they want. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
