操作Cassandra（8）-安全性

安全性

Cassandra提供的安全功能有三个主要组件：:

• 用于客户端和节点间通信的TLS / SSL加密
• 客户端身份验证
• 授权

TLS / SSL加密

Cassandra在客户端机器和数据库集群之间以及集群中的节点之间提供安全通信。启用加密可确保正在运行的数据不会泄露，并且安全传输。客户端到节点和节点到节点加密的选项单独管理，可以独立配置。

当启用加密时，将使用支持的协议和密码套件的JVM默认值。这些可以使用cassandra.yaml中的设置覆盖，但不建议这样做，除非有规定某些设置的策略，或者在不能更新JVM的情况下需要禁用易受攻击的密码或协议。

可以在JVM级别配置符合FIPS的设置，并且不应更改cassandra.yaml中的加密设置。有关更多详细信息，请参阅FIPS上的Java文档。

有关生成SSL通信中使用的密钥库和信任库文件的信息，请参阅有关创建密钥库的Java文档

节点间加密

管理节点间加密的设置可在配置文件cassandra.yaml中的server_encryption_options部分找到。要启用节点间加密，请将internode_encryption设置从默认值none更改为：rack，dc或all中的一个值。

客户端和节点间加密

用于管理客户端到节点加密的设置可以在配置文件cassandra.yaml中的client_encryption_options部分找到。这里有两个用于切换启用加密的设置参数，enable和optional。

• 如果两者都不设置为true，则客户端连接完全未加密。
• 如果enabled设置为true，并且optional设置为false，则必须保护所有客户端连接。
• 如果两个选项都设置为true，则使用相同的端口支持加密和未加密的连接。使用此配置的加密的客户端连接将被服务器自动检测和处理。

作为可选设置的替代方案，还可以为操作要求所需的安全和不安全连接配置单独的端口。为此，将optional设置为false，并使用cassandra.yaml中的native_transport_port_ssl设置来指定用于安全客户端通信的端口。

角色

Cassandra在身份验证和权限管理中使用数据库角色，可以代表单个用户或一组用户。角色管理是Cassandra中的扩展点，可以使用cassandra.yaml中的role_manager设置进行配置。默认设置使用CassandraRoleManager，该实现将角色信息存储在system_auth键空间的表中。

验证（Authentication）

认证在Cassandra中是可插入的，并且使用cassandra.yaml中的authenticator设置进行配置。Cassandra带有默认分配中包含的两个选项。

默认情况下，Cassandra配置有AllowAllAuthenticator，不执行身份验证检查，因此不需要凭据。它用于完全禁用身份验证。认证是Cassandra的权限子系统的一个必要条件，所以如果认证被禁用，权限也是如此。

默认分配还包括PasswordAuthenticator，它将加密的凭据存储在系统表中。这可以用于启用简单的用户名/密码验证。

启用密码验证

在对集群启用客户端身份验证之前，客户端应用程序应使用其预期凭据进行预配置。当启动连接时，服务器只有在启用认证后才会请求凭据，因此提前设置客户端配置是安全的。相反，一旦服务器启用了认证，任何没有适当凭证的连接尝试将被拒绝，这可能引起客户端应用程序的可用性问题。一旦客户端设置并准备好启用认证，请按照此过程在集群上启用它。

选择要在其上执行初始配置的集群中的单个节点。 理想情况下，在安装过程中不应有客户端连接到此节点，因此您可能希望从客户端配置中删除它，在网络级别阻止它，或者可能为此目的向群集添加一个新的临时节点。在该节点上，执行以下步骤：

1. 打开cqlsh会话并更改system_auth键空间的复制因子。默认情况下，此键空间使用简单复制策略并且复制因子为1.建议为任何非平凡部署更改此选项，以确保该节点不可用，登录仍然可能。最佳做法是配置每个数据中心3到5的复制因子。

ALTER KEYSPACE system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1': 3, 'DC2': 3};

2. 编辑cassandra.yaml更改验证器（authenticator）选项，如下所示：

authenticator: PasswordAuthenticator

3. 重启节点。
4. 使用默认超级用户的凭据打开新的cqlsh会话：

cqlsh -u cassandra -p cassandra

5. 在登录期间，默认超级用户的凭据以一致性级别QUORUM读取，而所有其他用户（包括超级用户）的凭据在LOCAL_ONE中读取。为了性能和可用性以及安全性，操作员应创建另一个超级用户并禁用默认的超级用户。此步骤是可选的，但强烈建议。以默认超级用户身份登录时，创建另一个超级用户角色，可用于引导进一步配置。

# create a new superuserCREATE ROLE dba WITH SUPERUSER = true AND LOGIN = true AND PASSWORD = 'super';

6. 启动新的cqlsh会话，此时以new_superuser身份登录并禁用默认超级用户。

ALTER ROLE cassandra WITH SUPERUSER = false AND LOGIN = false;

7. 最后，使用CREATE ROLE语句为用户设置角色和凭据。

在这些步骤结束时，一个节点配置为启用密码认证了。如果在集群中的每个节点上重复步骤2和3，将在整个集群中启用身份验证。

注意，使用PasswordAuthenticator也需要使用CassandraRoleManager。

授权

授权在Cassandra中是可插入的，并且使用cassandra.yaml中的authorizer设置进行配置。Cassandra带有默认分配中包含的两个选项。

默认情况下，Cassandra配置有AllowAllAuthorizer，不执行检查，因此有效地授予所有角色的所有权限。如果AllowAllAuthenticator是配置的认证者，则必须使用此选项。

默认分配还包括CassandraAuthorizer，它实现完全权限管理功能并将其数据存储在Cassandra系统表中。

启用内部授权

权限被建模为白名单，默认假设给定角色无权访问任何数据库资源。这意味着，一旦在节点上启用授权，该给定角色所有请求都将被拒绝，直到授予所需的权限。因此，强烈建议在不处理客户端请求的节点上执行初始设置。

以下假设已通过启用密码验证中概述的过程启用验证。执行以下步骤以在集群中启用内部授权：

1. 在所选节点上，编辑cassandra.yaml以更改authorizer选项，如下所示：

authorizer: CassandraAuthorizer

2. 重新启动节点。
3. 使用具有超级用户凭据的角色的凭证打开新的cqlsh会话：

cqlsh -u dba -p super

4. 使用GRANT PERMISSION语句为客户端配置适当的访问权限。在其他节点上，直到配置更新并且节点重新启动都不会受到影响，从而避免对客户端连接的中断。

GRANT SELECT ON ks.t1 TO db_user;

5. 一旦授予了所有必需的权限，则对每个节点轮流重复步骤1和2。当每个节点重新启动并且客户端重新连接时，将开始强制授权。

缓存

启用身份验证和授权会因为频繁从system_auth表读取导致集群的负载增加。此外，这些读取是许多客户端操作的关键路径，因此具有严重影响服务质量的潜在风险。为了减轻这种情况，身份验证数据（例如凭据，权限和角色详细信息）会缓存一段可配置的时间段。缓存可以从cassandra.yaml或使用JMX客户端配置（甚至禁用）。JMX接口还支持各种缓存的无效，但是通过JMX进行的任何更改都不是持久的，并且在节点重新启动时将从cassandra.yaml重新读取。

每个缓存有3个选项可以设置：

有效期（Validity Period）

控制缓存条目的到期时间。到期后条目将失效并从高速缓存中删除。

刷新率（Refresh Rate）

控制在后台执行选取底层数据的任何更改的速率。 当执行这些异步刷新时，缓存将继续提供（可能）陈旧的数据。 通常，这将被设置为比有效期短的时间。

最大条目（Max Entries）

控制高速缓存大小的上限。

cassandra.yaml中的这些选项的命名遵循惯例：

• <type>_validity_in_ms
• <type>_update_interval_in_ms
• <type>_cache_max_entries

其中<type>是凭据，权限或角色之一。

如上所述，这些也通过JMX在org.apache.cassandra.auth域下的mbeans中公开。

JMX访问

JMX客户机的访问控制与CQL的访问控制分开配置。 对于认证和授权，两个提供商可用; 第一种基于标准的JMX安全性，第二种与Cassandra自己的授权子系统更紧密地集成。

Cassandra的默认设置使JMX只能从localhost访问。要启用远程JMX连接，请编辑cassandra-env.sh（或Windows上的cassandra-env.ps1）将LOCAL_JMX设置更改为yes。在标准配置下，当启用远程JMX连接时，也会打开标准JMX身份验证。

请注意，默认情况下，仅本地连接不受身份验证，但可以启用验证。

如果启用远程连接，建议也使用SSL连接。

最后，在启用身份验证和/或SSL之后，确保使用JMX的工具（如nodetool）已正确配置并按预期工作。

标准JMX认证

允许连接到JMX服务器的用户在一个简单的文本文件中指定。 此文件的位置在cassandra-env.sh中通过以下行设置：

JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password"

编辑密码文件以添加用户名/密码对：

jmx_user jmx_password

保护凭据文件，以便只有运行Cassandra进程的用户可以读取它：

$ chown cassandra:cassandra /etc/cassandra/jmxremote.password$ chmod 400 /etc/cassandra/jmxremote.password

或者，启用访问控制以限制已定义用户可以通过JMX执行的范围。在这种情况下，这是一个效率相当地下的工具，因为Cassandra中的大多数操作工具都需要完全的读/写访问。要配置一个简单的访问文件，请取消注释cassandra-env.sh中的此行：

#JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.access.file=/etc/cassandra/jmxremote.access"

然后编辑访问文件以授予您的JMX用户读写权限：

jmx_user readwrite

必须重新启动Cassandra才能接收新设置。

Cassandra集成验证

JMX认证的替代方法是使用Cassandra自己的认证和/或授权提供程序用于JMX客户端。这可能更灵活和安全，但它有一个主要警告。也就是说，直到节点加入环之后才可用，因为auth子系统直到那个点才被完全配置。然而，对于监视目的来说，特别是在引导期间，JMX访问通常是至关重要的。因此，建议在可能的情况下在引导期间使用本地仅JMX auth，然后如果需要远程连接，则在节点加入环并初始设置完成后切换到集成身份验证。

使用此选项，用于CQL身份验证的相同数据库角色也可用于控制对JMX的访问，因此可以使用cqlsh集中管理更新。此外，可以通过GRANT PERMISSION来控制被特定MBean允许的操作。

要启用集成身份验证，请编辑cassandra-env.sh以取消注释以下行：

#JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.remote.login.config=CassandraLogin"#JVM_OPTS="$JVM_OPTS -Djava.security.auth.login.config=$CASSANDRA_HOME/conf/cassandra-jaas.config"

并通过注释此行禁用JMX标准验证：

JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password"

要启用集成授权，请取消注释此行：

#JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.authorizer=org.apache.cassandra.auth.jmx.AuthorizationProxy"

通过确保此行被注释掉，检查标准访问控制是关闭的：

#JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.access.file=/etc/cassandra/jmxremote.access"

通过启用集成的身份验证和授权，运营商可以定义特定的角色，并授予他们访问他们所需的特定JMX资源。例如，具有必要权限的角色在只读模式下使用工具（如jconsole或jmc）将被定义为：

CREATE ROLE jmx WITH LOGIN = false;GRANT SELECT ON ALL MBEANS TO jmx;GRANT DESCRIBE ON ALL MBEANS TO jmx;GRANT EXECUTE ON MBEAN 'java.lang:type=Threading' TO jmx;GRANT EXECUTE ON MBEAN 'com.sun.management:type=HotSpotDiagnostic' TO jmx;# Grant the jmx role to one with login permissions so that it can access the JMX toolingCREATE ROLE ks_user WITH PASSWORD = 'password' AND LOGIN = true AND SUPERUSER = false;GRANT jmx TO ks_user;

还支持对单个MBean的访问控制：

GRANT EXECUTE ON MBEAN 'org.apache.cassandra.db:type=Tables,keyspace=test_keyspace,table=t1' TO ks_user;GRANT EXECUTE ON MBEAN 'org.apache.cassandra.db:type=Tables,keyspace=test_keyspace,table=*' TO ks_owner;

这允许ks_user角色调用MBean上表示test_keyspace中单个表的方法，同时将该键空间中的所有表级MBean的相同权限授予ks_owner角色。

初始设置完成后，将动态处理添加/删除角色和授予/撤销权限，因此更改权限后不需要进一步重新启动

JMX使用SSL

JMX SSL配置由多个系统属性控制，其中一些属性是可选的。要打开SSL，请编辑cassandra-env.sh（或Windows上的cassandra-env.ps1）中的相关行以取消注释，并根据需要设置属性的值：

com.sun.management.jmxremote.ssl

设置为true以启用SSL

com.sun.management.jmxremote.ssl.need.client.auth

设置为true以启用客户端证书的验证

com.sun.management.jmxremote.registry.ssl

为客户端从其获取JMX连接器存根的RMI注册表启用SSL套接字

com.sun.management.jmxremote.ssl.enabled.protocols

默认情况下，将使用JVM支持的协议，使用逗号分隔列表。通常这不是必需的，并且使用默认值是首选选项。

com.sun.management.jmxremote.ssl.enabled.cipher.suites

 默认情况下，将使用JVM支持的密码套件，用逗号分隔列表。 通常这不是必需的，并且使用默认值是首选选项。

javax.net.ssl.keyStore

在包含服务器私钥和公用证书的密钥库的本地文件系统上设置路径

javax.net.ssl.keyStorePassword

设置密钥库文件的密码

javax.net.ssl.trustStore

如果需要验证客户端证书，请使用此属性指定包含受信任客户端的公用证书的信任库的路径

javax.net.ssl.trustStorePassword

设置truststore文件的密码

另请参见:Oracle Java7 Docs,Monitor Java with JMX