第十三章：Cassandra安全--Cassandra：The Definitive Guide 2nd Edition

最新推荐文章于 2021-10-22 11:40:14 发布

sunchengquan

最新推荐文章于 2021-10-22 11:40:14 发布

阅读量992

点赞数

分类专栏： Cassandra

Cassandra 专栏收录该内容

14 篇文章 12 订阅

订阅专栏

使数据可访问一直是大数据运动的关键原则之一，在数据分析方面取得了巨大进步，并为企业，学术界和公众带来了实实在在的好处。与此同时，随着安全性和隐私需求的增长，这种数据可访问性也处于紧张状态。互联网规模系统暴露于不断变化的攻击集合中，这些系统保存的数据是最常见的目标。我们都知道多次引人注目的违规行为导致数据严重损失，包括个人数据，支付信息，军事情报和公司商业机密。而这些只是导致这一消息的漏洞。

这种威胁环境加剧的一个结果是，许多行业的监管和合规方案都在增加：

1996年的美国健康保险流通与责任法案（HIPAA）规定了对个人健康信息的保护和处理的控制。
德国的联邦数据保护法（Bundesdatenschutzgesetz或BDSG）于2009年进行了修订，以规范个人身份信息（PII）的收集和转移，包括限制此类数据在德国和欧盟之外的移动。
支付卡行业数据安全标准（PCI DSS）于2006年首次发布，是一套行业定义的安全处理支付卡数据的标准。
2002年美国萨班斯 - 奥克斯利法案规定了企业审计和报告，包括数据保留，保护和审计。

这些只是监管和合规标准的几个例子。即使这些示例都不直接适用于您的应用程序，也可能存在某种影响您系统的监管指南。

所有这些宣传和监管严格性使得对企业应用程序安全性的可见性大大提高，并且对于我们关于NoSQL数据库安全性的讨论更加有针对性。虽然数据库根据定义只是应用程序的一部分，但它确实构成了应用程序攻击面的重要部分，因为它充当应用程序数据的存储库。

安全性是否是NoSQL的弱点？

2012年信息周报告让NoSQL社区承担了NoSQL数据库中安全功能缺乏优先级的任务。虽然许多NoSQL技术（包括Cassandra）的安全性从那时起已经有了显着改善，但该文件可以提醒我们我们的责任以及持续保持警惕的必要性。

幸运的是，正如我们在第2章的发布历史中已经看到的那样，Cassandra社区已经证明了在相对较短的生命周期内不断改进安全性的承诺。

Cassandra的安全功能包括身份验证，基于角色的授权和加密，如图13-1所示。

在这里插入图片描述

在本章中，我们将探讨这些安全功能以及如何通过cqlsh和其他客户端访问它们，并对Cassandra如何适应更广泛的应用程序安全策略提出了一些看法。

身份验证和授权

我们来看看Cassandra的身份验证和授权功能。

密码验证器

默认情况下，Cassandra允许网络上的任何客户端连接到您的群集。这并不意味着没有开箱即用的安全性，而是Cassandra配置为使用允许所有客户端的身份验证机制，而无需他们提供凭据。安全机制是可插拔的，这意味着您可以轻松地将一种身份验证方法换成另一种身份验证方法，或者编写自己的身份验证方法

默认情况下插入的身份验证器是org.apache.cassandra。身份验证.AllowAllAuthenticator。如果您想强制客户端提供凭据，另一个替代方案是Cassandra，org.apache .cassandra .auth.Password Authenticator。在本节中，我们将了解如何使用第二个身份验证器。
配置身份验证器

首先，让我们关闭我们的集群，以便我们可以更改安全配置。我们将打开cassandra.yaml文件并搜索“authenticator”。你会发现以下行：

authenticator: AllowAllAuthenticator

让我们更改此行以使用PasswordAuthenticator：

authenticator: PasswordAuthenticator

如果您使用的是Cassandra 2.2或更高版本，您将在cassandra.yaml文件中看到一条注释，指示如果使用PasswordAuthenticator，则必须使用CassandraRoleManager。 CassandraRoleManager是Cassandra授权功能的一部分，我们将在稍后深入讨论它。

其他认证提供商

您可以提供自己的Cassandra身份验证方法，例如Kerberos票证，或者如果要将密码存储在其他位置（例如LDAP目录）。要创建自己的身份验证方案，只需实现IAuthenticator接口即可。 DataStax Enterprise Edition提供其他身份验证集成。

Cassandra还通过IInternode Authenticator接口支持节点之间的可插入身份验证。默认实现AllowAllInternode Authenticator不执行身份验证，但您可以自由地实现自己的身份验证器，以保护节点不与不受信任的节点建立连接。

添加用户

现在我们将保存cassandra.yaml文件并重新启动我们的节点或集群，并尝试使用cqlsh登录。我们马上就遇到了一个问题：

$ bin/cqlsh
Connection error: ('Unable to connect to any servers', 
  {'127.0.0.1': AuthenticationFailed('Remote end requires 
  authentication.',)})

Cassandra的早期版本可能允许登录，但不允许任何访问。 Cassandra 2.2及更高版本的版本甚至需要密码才能登录.Cassandra附带一个名为cassandra的默认用户，其中“cassandra”作为密码。让我们尝试使用这些凭据再次登录：

$ bin/cqlsh -u cassandra -p cassandra
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.0.0-rc1 | CQL spec 3.3.1 | 
  Native protocol v4]
Use HELP for help.
cassandra@cqlsh>

一旦我们成功登录，我们就会看到提示符表明我们以用户cassandra身份登录。我们要开始保护安装的第一件事就是更改这个非常重要的用户的密码。我们在这里使用随机密码生成器作为示例：

cassandra@cqlsh> ALTER USER cassandra WITH PASSWORD 'Kxl0*nGpB6'

确保将cassandra用户的密码存储在安全的位置。

现在，让我们创建一个新的用户帐户。我们将指定用户名和密码。密码是可选的，但当然建议使用。

cassandra@cqlsh> CREATE USER jeff WITH PASSWORD 'i6XJsj!k#9';

CREATE USER命令还支持IF NOT EXISTS语法，以避免多次尝试创建用户时出错。现在，我们将检查是否已使用LIST USERS命令成功创建了用户：

cassandra@cqlsh> LIST USERS;

 name      | super
-----------+-------
 cassandra |  True
      jeff | False

(2 rows)

您会注意到用户cassandra被列为超级用户。超级用户指定执行所有支持的操作的能力。只有超级用户才能创建其他用户。我们已经更改了内置用户cassandra的密码。您可能还想创建另一个超级用户并删除cassandra帐户的超级用户状态以获得额外的安全性。

配置自动登录

为避免在每次登录cqlsh时都输入用户名和密码，请在主目录中创建一个名为.cqlshrc的文件。您可以通过以下行输入登录凭据：

; Sample ~/.cqlshrc file.
[authentication]
username = jeff
password = i6XJsj!k#9

显然，您需要确保此文件是安全的，以便只有授权用户（例如您的帐户）才能访问密码。

对用户的其他操作包括ALTER USER命令，它允许我们更改用户的密码或超级用户状态，以及我们用来删除用户的DROP USER命令。非超级用户可以使用ALTER USER命令更改自己的密码，但所有其他操作都需要超级用户状态。

我们可以使用LOGIN命令在cqlsh中切换用户而无需重启：

cassandra@cqlsh> login jeff 'i6XJsj!k#9'
jeff@cqlsh>

您可以选择从命令中省略密码，在这种情况下，cqlsh将提示您输入密码。最好在shell提示符下输入密码，而不是命令行，因为cqlsh会将所有命令保存到主目录下名为.cassandra / cqlsh_history的文件中，包括使用LOGIN命令时在命令行中包含的任何密码。

通过DataStax Java驱动程序进行身份验证

当然，您的应用程序不使用cqlsh来访问Cassandra，因此了解如何使用DataStax客户端驱动程序向客户端进行身份验证将对您有所帮助。在第8章的简单Java驱动程序示例的基础上，让我们使用Cluster.Builder.withCredentials（）操作在构造Cluster实例时提供用户名和密码：

 Cluster cluster = Cluster.builder().addContactPoint("127.0.0.1").
   withCredentials("jeff", "i6XJsj!k#9").
   build();

这是一个硬编码登录凭据的简单示例，但您可以轻松使用存储在安全配置文件中或由应用程序用户提供的值。登录语法与其他DataStax驱动程序非常相似。

如果您在节点上配置了默认设置以外的身份验证器，则还需要在客户端中配置兼容的身份验证器。客户端身份验证提供程序实现com.datastax.driver.core.AuthProvider接口。默认实现是PlainTextAuthProvider类，当我们调用Cluster.Builder.withCredentials（）操作时，会注册其实例。

com.datastax.driver.auth包中提供了随驱动程序提供的其他实现。其中包括用于连接DataStax Enterprise群集的DseAuthProvider和KerberosAuthenticator。

通过调用Cluster.Builder.withAuthProvider（）操作构建Cluster对象时，可以选择这些提供程序。

使用CassandraAuthorizer

当然可以只使用身份验证，但在大多数情况下，您也希望使用Cassandra的授权功能。 Cassandra的开箱即用配置授权所有客户端访问集群中的所有键空间和表。与身份验证一样，身份验证机制是可插入的。

默认情况下插入的授权者是org.apache.cassandra.auth.AllowAllAuthorizer。要启用Cassandra基于角色的访问控制，我们需要配置org.apache.cassandra.auth.CassandraAuthorizer。

同样，我们将关闭群集以使我们能够更改授权人。在cassandra.yaml文件中，我们将搜索“authorizer”。我们会找到这条线：

authorizer: AllowAllAuthorizer

and change it to:

authorizer: CassandraAuthorizer

一旦我们重新启动集群，我们就可以再次以常规用户身份登录cqlsh，以查看我们可以访问的内容，利用我们在前面章节中存储在集群中的酒店数据：

$ cqlsh -u jeff –p 'i6XJsj!k#9'
...
jeff@cqlsh> DESCRIBE KEYSPACES;

hotel  system_schema  system_auth  system  system_distributed  
  system_traces

jeff@cqlsh> USE hotel;
jeff@cqlsh:hotel> DESCRIBE TABLES;

hotels

jeff@cqlsh:hotel> select * from hotels;
Unauthorized: code=2100 [Unauthorized] message="User jeff has no 
  SELECT permission on <table hotel.hotels> or any of its parents"

如您所见，我们能够浏览cqlsh以查看各种键空间和表的名称，但是一旦我们尝试访问数据，我们就会被拒绝访问。

要解决此问题，我们需要切换回超级用户角色并授予用户一些权限。例如，让我们的用户访问酒店表：

cassandra@cqlsh> GRANT SELECT ON hotel.hotels TO jeff;

现在，如果我们以常规用户身份重新登录并再次运行SELECT命令，我们将看到之前存储在酒店表中的数据。

获得权限帮助

使用cqlsh命令HELP GRANT和HELP PERMISSIONS获取有关配置权限的其他信息。

基于角色的访问控制

在大型Cassandra集群中，可能存在许多不同的键空间和表，以及许多不同的潜在用户。跟踪分配给许多不同用户的权限将很困难。虽然很容易与多个支持人员共享登录信息，但还有更好的方法。

从2.2版本开始，Cassandra提供基于角色的访问控制（RBAC）功能。这允许我们创建角色并为这些角色分配权限。角色可以任意组合授予个人用户。角色本身可以包含其他角色。

要了解其工作原理，让我们创建一个酒店管理角色，并将其授予酒店密钥空间中所有表的所有权限：

cassandra@cqlsh> CREATE ROLE hotel_management;
cassandra@cqlsh> GRANT ALL ON KEYSPACE hotel TO hotel_management;

我们在这里创建了一个简单的角色，您无法直接登录。您还可以创建具有超级用户权限的角色，以及支持登录和获取密码的角色。

现在我们将此角色应用于我们的常规用户：

cassandra@cqlsh> GRANT hotel_management TO jeff;

角色在Cassandra中是附加的，这意味着如果授予用户的任何角色具有授予的特定权限，则该权限将授予用户。

在幕后，Cassandra将用户和角色存储在system_auth键空间中。如果我们为集群配置了授权，则只有管理用户可以访问此密钥空间，所以让我们使用管理员登录在cqlsh中检查其内容：

cassandra@cqlsh> DESCRIBE KEYSPACE system_auth

CREATE KEYSPACE system_auth WITH replication = {'class': 'SimpleStrategy',
  'replication_factor': '1'}  AND durable_writes = true;

...

我们截断了输出，但是如果运行此命令，您将看到存储角色，权限和角色分配的表。实际上在数据库级别没有单独的用户概念 - Cassandra使用角色概念来跟踪用户和角色。

更改system_auth复制因子

重要的是要注意system_auth键空间是开箱即用配置的，以使用复制因子为1的SimpleStrategy。

这意味着默认情况下，我们配置的任何用户，角色和权限都不会分布在群集中，直到我们重新配置system_auth键空间的复制策略以匹配我们的群集拓扑。

加密

保护用户隐私是许多系统的重要方面，尤其是在健康，财务和其他个人数据方面。通常，我们通过加密数据来保护隐私，因此如果数据被截获，则对于没有加密密钥的攻击者而言，它是不可用的。数据可以在公共互联网和我们的内部系统中传输时加密，也称为动态数据，或者可以在持久存储的系统上加密。这被称为静止数据。

从3.0版本开始，Cassandra通过客户端和服务器（节点）之间的加密以及节点之间的加密来保护数据。从Cassandra 3.0开始，仅在Cassandra的DataStax Enterprise版本中支持数据文件（静态数据）的加密。

数据文件加密路线图

有几个Cassandra JIRA请求针对3.X版本系列提供加密功能。例如，3.4版本中添加了以下内容：

CASSANDRA-11040 - 提示加密
CASSANDRA-6018 - 提交日志的加密

另请参阅有关SSTables加密的CASSANDRA-9633和CASSANDRA-7922，它是文件级加密请求的总票。

在我们开始配置节点以启用加密之前，我们需要做一些准备工作来创建作为机器关键部分的安全证书。

SSL，TLS和证书

Cassandra使用传输层安全性（TLS）来加密运动中的数据。 TLS通常由其前身安全套接字层（SSL）的名称引用。 TLS是一种加密协议，用于保护计算机之间的通信，以防止窃听和篡改。更具体地说，TLS利用公钥加密（也称为非对称加密），其中一对密钥用于加密和解密两个端点之间的消息：客户端和服务器。

在建立连接之前，每个端点必须拥有包含公钥和私钥对的证书。公钥与通信伙伴交换，而私钥不与任何人共享。

为了建立连接，客户端向服务器发送请求，指示它支持的密码套件。服务器从它也支持的列表中选择密码套件，并使用包含其公钥的证书进行回复。客户端可选地验证服务器的公钥。服务器还可能要求客户端提供其公钥以执行双向验证。客户端使用服务器的公钥来加密到服务器的消息，以便协商会话密钥。会话密钥是由所选密码套件生成的对称密钥，用于后续通信。

对于公钥加密的许多应用，证书是从证书颁发机构获得的，但由于我们通常控制客户端和Cassandra节点，因此我们不需要那么高级的验证。出于我们的目的，我们可以使用Java（keytool）提供的简单工具生成证书。

以下命令给出了如何使用keytool上的-genkey开关生成公钥/私钥对的示例：

$ keytool -genkey -keyalg RSA -alias node1 -keystore node1.keystore
  -storepass cassandra -keypass cassandra 
  -dname "CN=Jeff Carpenter, OU=None, O=None, L=Scottsdale, C=USA"

此命令为我们的一个Cassandra节点生成密钥对，我们称之为“node1”，并将密钥对放在一个名为密钥库的文件中。我们称之为keystore node1.keystore。我们提供密钥库和密钥对的密码，以及根据轻量级目录访问协议（LDAP）格式指定的可分辨名称。

我们在此处显示的示例命令提供了用于生成密钥的最小属性集。我们还可以在命令行上提供更少的属性，并允许keytool提示我们剩下的属性，这对于输入密码更安全。

然后我们将每个证书的公钥导出到一个单独的文件，我们可以与他人共享：

$ keytool -export -alias node1 -file node0.cer -keystore node1.keystore
Enter keystore password:
Certificate stored in file <node0.cer>

我们通过与之前相同的别名来标识要从密钥库导出的密钥，并提供输出文件的名称。 keytool提示我们输入密钥库密码并生成证书文件。

我们重复此过程以为每个节点和客户端生成密钥。

节点到节点加密

现在我们已经为每个Cassandra节点提供了密钥，我们已准备好通过在cassandra.yaml文件中设置server_encryption_options来启用节点到节点配置：

server_encryption_options:
    internode_encryption: none
    keystore: conf/.keystore
    keystore_password: cassandra
    truststore: conf/.truststore
    truststore_password: cassandra
    # More advanced defaults below:
    # protocol: TLS
    # algorithm: SunX509
    # store_type: JKS
    # cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,...]
    # require_client_auth: false

首先，我们设置internode_encryption选项。我们可以选择all来加密所有节点间通信，dc来加密数据中心，以及机架以在机架之间进行加密。我们提供密钥库的密码并设置其路径，或者我们可以将之前创建的密钥库文件放在conf目录中的默认位置。

接下来，我们为类似于名为truststore的密钥库的文件配置选项。我们为每个节点生成一个信任库，其中包含集群中所有其他节点的公钥。例如，要将节点1的证书添加到节点2的密钥库，我们将使用以下命令：

$ keytool -import -v -trustcacerts -alias node1 -file node1.cer
  -keystore node2.truststore
Enter keystore password:
Re-enter new password:
Owner: CN=Jeff Carpenter, OU=None, O=None, L=Scottsdale, C=USA
Issuer: CN=Jeff Carpenter, OU=None, O=None, L=Scottsdale, C=USA
Serial number: 52cf9209
Valid from: Thu Dec 17 17:01:03 MST 2015 until: Wed Mar 16 17:01:03 MST 2016
Certificate fingerprints:
         MD5:  E2:B6:07:C0:AA:BB:71:E8:47:8A:2A:81:FE:48:2F:AB
         SHA1: 42:3E:9F:85:0D:87:02:50:A7:CD:C5:EF:DD:D1:6B:C2:78:2F:B0:E7
         SHA256: C1:F0:51:5B:B6:C7:B5:8A:57:7F:D0:F2:F7:89:C7:34:30:79:30:
           98:0B:65:75:CE:03:AB:AA:A6:E5:F5:6E:C0
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: C2 32 58 D0 55 27 5C D2   FB 1E 50 C9 76 21 30 5C  .2X.U'\...P.v!0\
0010: E6 1A 7D CF                                        ....
]
]

Trust this certificate? [no]:  y
Certificate was added to keystore
[Storing truststore.node1]

keytool提示我们输入新信任库的密码，然后打印出有关我们导入的密钥的摘要信息。

cassandra.yaml文件还向我们提供了一系列用于配置加密的“高级”选项。这些选项使您能够从Java的受支持加密算法和库菜单中进行选择。例如，对于Java 8，您可以在http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html上找到这些项的描述。

在大多数情况下，默认值就足够了，但了解哪些选项可用会很有帮助。我们可以通过检查Cassandra用于生成安全套接字的类org.apache.cassandra.security.SSLFactory来了解这些选项在Cassandra中的使用方式。

protocol选项指定将用于实例化javax.net.ssl.SSLContext的协议套件。从Java 8开始，支持的值包括SSLv2，SSLv3，TLSv1，TLSv1.1或TLSv1.2。您还可以使用快捷方式SSL或TLS获取任一套件的最新支持版本。

algorithm选项指定为获取javax.net.ssl.TrustManagerFactory的实例而提供的设置。默认为X.509证书。

store_type选项指定为获取java.security.KeyStore实例而提供的设置。默认值jks表示由keytool构建的密钥库，这正是我们所拥有的。

cipher_suites选项是按优先顺序排列的加密算法。要使用的密码套件由客户端和服务器根据此列表中指定的优先级协商其连接来确定。当您使用https：URL访问网站时，浏览器使用相同的技术与Web服务器协商。正如默认设置所示，您通常希望将更强的密码套件放在列表的前面。如果您无法完全控制您的客户，您甚至可能希望完全删除较弱的套件以消除降级攻击的威胁。

最后，我们还可以启用双向证书身份验证，其中客户端通过将require_client_auth设置为true来验证服务器。

客户端到节点加密

客户端到节点加密可在数据从客户端计算机移动到群集中的节点时对其进行保护。 cassandra.yaml文件中的client_encryption_options与节点到节点选项非常相似：

# enable or disable client/server encryption.
client_encryption_options:
    enabled: false
    optional: false
    keystore: conf/.keystore
    keystore_password: cassandra
    # require_client_auth: false
    # Set truststore and truststore_password if require_client_auth is true
    # truststore: conf/.truststore
    # truststore_password: cassandra
    # More advanced defaults below:
    # protocol: TLS
    # algorithm: SunX509
    # store_type: JKS
    # cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,...]

与server_encryption_options的主要区别在于enabled选项（可用作客户端到节点加密的开/关切换）和可选选项（指示客户端是选择加密连接还是未加密连接）。

密钥库和信任库设置通常与server_encryption_options中的设置相同，但可以为客户机选项提供单独的文件。

请注意，为客户端设置require_client_auth意味着每个节点的信任库将需要为将使用加密连接的每个客户端提供公钥。

简化的证书管理

如果要定期向群集或其他客户端添加节点，则为Cassandra节点配置信任库可能会成为一个后勤问题。通常的做法是为集群中的所有节点重用相同的证书，为所有客户端重用第二个证书。

此方法极大地简化了管理群集的过程，因为您不必重新配置信任库并重新启动节点以添加节点和客户端。这是以对您分配给各个节点和客户端的信任进行细粒度控制为代价的。

无论您选择何种方案来管理证书，Cassandra群集的整体安全性取决于限制对运行节点的计算机的访问权限，以便配置不会被篡改。

JMX安全

我们在第10章中了解了Cassandra如何通过JMX公开监视和管理功能。在本节中，我们将学习如何使该管理接口安全，以及我们可以使用JMX配置哪些与安全相关的选项。

保护JMX Access

默认情况下，Cassandra只允许从localhost访问JMX。这适用于您具有直接计算机访问权限的情况，但如果您正在运行大型集群，则登录到托管每个节点的计算机以使用nodetool或OpsCenter等工具进行访问可能不切实际。

因此，Cassandra提供了公开其JMX接口以进行远程访问的能力。当然，投入我们的努力以确保通过本地传输访问Cassandra将是一种浪费，并留下像JMX这样的主要攻击面。因此，让我们看看如何以安全的方式启用远程JMX访问。

首先，我们将停止我们的节点或集群并编辑conf / cassandra-env.sh文件（或Windows上的cassandra-env.ps1）。查找LOCAL_JMX设置，并按如下所示进行更改：

LOCAL_JMX=no

将此值设置为“yes”以外的任何值会导致设置其他几个属性，包括允许远程访问JMX端口的属性：

JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.port=$JMX_PORT"
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.rmi.port=$JMX_PORT"

接下来，有一个属性可以配置SSL是否用于加密JMX连接（我们将在稍后深入讨论）：

JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.ssl=false"

最后，还有一些为JMX配置远程身份验证的属性：

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

jmxremote.password文件的位置完全取决于您。请记住，您需要指定只有您有权访问的用户才能访问的文件的位置。我们将在一分钟内配置jmxremote.password文件，但首先让我们通过保存cassandra-env.sh文件来完成配置编辑。

您的JRE安装附带了jre / lib / management目录下的模板jmxremote.password文件。通常，您将在Windows上的C：\ Program Files \ Java，Mac OS上的/ Library / Java / JavaVirtualMachines和Linux上的/ usr / lib / java下找到已安装的JRE。将jmxremote.password文件复制到之前在cassandra-env.sh中设置的位置并编辑该文件，添加一行包含我们的管理员用户名和密码，如下面的粗体所示：

...
# monitorRole  QED
# controlRole   R&D
cassandra cassandra

我们还将编辑jre / lib / management目录下的jmxremote.access文件，为我们的管理用户添加读写MBean访问权限：

monitorRole readonly
controlRole readwrite \
            create javax.management.monitor.*,javax.management.timer.* \
            unregister
cassandra readwrite

配置jmxremote.password和jmxremote.access的权限。理想情况下，运行Cassandra的帐户应该具有对此文件的只读访问权限，而其他非管理用户应该没有访问权限。

最后，我们重新启动Cassandra并测试我们是否通过调用nodetool正确配置了安全访问：

$ nodetool status -u cassandra -pw cassandra

我们还可以为JMX连接配置SSL。为此，我们需要在cassandra-env文件中添加更多JVM选项：

JVM_OPTS="${JVM_OPTS} -Dcom.sun.management.jmxremote.ssl=true"
JVM_OPTS="${JVM_OPTS} -Djavax.net.ssl.keyStore=conf/node1.keystore"
JVM_OPTS="${JVM_OPTS} -Djavax.net.ssl.keyStorePassword=cassandra"
JVM_OPTS="${JVM_OPTS} -Djavax.net.ssl.trustStore=conf/node1.truststore"
JVM_OPTS="${JVM_OPTS} -Djavax.net.ssl.trustStorePassword=cassandra"
JVM_OPTS="${JVM_OPTS} -Dcom.sun.management.jmxremote.ssl.need.client.auth=true"

安全MBean

我们在第10章中了解了Cassandra公开的各种MBean。出于可以理解的原因，没有很多与安全相关的配置参数可以通过JMX远程访问，但是有一些功能通过org.apache.cassandra.auth域公开。

PermissionsCacheMBean

默认情况下，Cassandra会将有关角色和权限的信息作为性能优化进行缓存。缓存权限的时间量由permissions_validity_in_ms属性在cassandra.yaml文件中设置，默认为2秒。 PermissionsCacheMBean允许您覆盖此值以延长或缩短缓存时间，还提供一个命令以使缓存中的所有权限无效。如果您需要更改群集中的权限并需要它们立即生效，这可能是一项有用的操作。

总结

Cassandra只是企业应用程序的一部分，但仍然是一个重要的部分。在本章中，我们学习了如何配置Cassandra的可插拔身份验证和授权功能，以及如何管理和授予用户和角色的权限。我们在客户端和节点之间启用了加密，并学习了如何保护JMX接口以进行远程访问。

sunchengquan

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
第十三章：Cassandra安全--Cassandra：The Definitive Guide 2nd Edition

使数据可访问一直是大数据运动的关键原则之一，在数据分析方面取得了巨大进步，并为企业，学术界和公众带来了实实在在的好处。与此同时，随着安全性和隐私需求的增长，这种数据可访问性也处于紧张状态。互联网规模系统暴露于不断变化的攻击集合中，这些系统保存的数据是最常见的目标。我们都知道多次引人注目的违规行为导致数据严重损失，包括个人数据，支付信息，军事情报和公司商业机密。而这些只是导致这一消息的漏洞。这种威...
复制链接

扫一扫