技术基础 | Cassandra RBAC助你打击“虚拟海盗”，让他们对数据“战利品”望而不得

现如今，我们称虚拟世界里的海盗们为“黑客”，他们所追寻的战利品就是在你数据库某处的数据。

 

而我们能够保证你的数据安全的工具之一，就是“Cassandra基于角色的访问控制(Cassandra Role-Based Access Control, aka, RBAC)”这一功能。

---

 

“入侵者要当心

摧毁死亡与悲伤

浸润在盗贼的

鲜血之中”

 

这是美国冒险喜剧电影《七宝奇谋》（The Goonies）中，宝藏所在地的寻宝地图上对海盗的警语。

 

我们肯定写不出一篇像是海盗寻宝一样有意思的关于数据库访问控制的文章，但我们未尝不能借用一些跟海盗寻宝有关的想象来渲染一下气氛。

 

现如今，我们称虚拟世界里的海盗们为“黑客”，他们所追寻的战利品就是在你数据库某处的数据。

 

而我们能够保证你的数据安全的工具之一，就是“Cassandra基于角色的访问控制(Cassandra Role-Based Access Control, aka, RBAC)”这一功能。通过实施一些相当简单的策略，我们可以遵循一些Cassandra RBAC的基本步骤来让我们的数据变得更为安全。

 

注意，此处我们讲的是严格意义上的“授权(authorization)”过程，而不是“身份验证(authentication)”过程。这两者纵然相关，但其实是两个不同的话题。相比之下，前者比后者稍微简单直白、易于理解一些。

 

毕竟，你应该已经知道不能在没有身份验证功能的加持下就把数据库暴露在互联网上，对吧？（链接里的录像由本文作者配音）

 

就以下建议而言，我们的前提假设是用户都是Cassandra管理的内部用户，而不是来自像是LDAP（轻型目录访问协议）这样的外部访问源。不过，其实这两种情况的安全管理原则大致相同。

---

 

Cassandra的模式容易让人产生疑惑：它将所有的角色(role)视为角色(role)，同时也将所有的用户(user)视为角色(role)。注意不要混淆。

 

相比将用户和角色视为两种不同的数据库对象，Cassandra用“角色(role)”对象来指代那些作为权限的集合的角色，也用这个词来指代那些使用这些权限登录的实体。这种情况引起的，至少是人们的困惑。

 

就长期的内部管理而言，用两个不同的类别(bucket)来管理这两者可能会是更好的方案——你的用户(user)们包括了自然人以及需要登录数据库的应用程序软件；而你的角色(role)们则包括了多个有特定适用范围的数据库权限集合，这些权限集合在之后会被分配给用户(user)。

 

除非你有非常特定的原因，否则尽量避免直接将数据库权限赋予一个用户。为了更清晰地展示这点，下方是一个例子：

 

CREATE ROLE alicethehuman with LOGIN=true;

CREATE ROLE READONLY;

GRANT SELECT, DESCRIBE ON mykeyspace.mytable TO READONLY;

GRANT SELECT, DESCRIBE on mykeyspace.myothertable TO READONLY;

GRANT ROLE READONLY TO alicethehuman;

在上方的例子中，请注意，我们的自然人用户是通过“被赋予了LOGIN=true”这个特点来和作为权限集合的角色进行区分的。

 

之后，我们又创建了一个被清晰标识的作为权限集合的角色，并且将特定的许可条件指定给了它。最后，我们将这个角色赋给了alicethehuman这个自然人用户。

 

我们需要避免的是像下面的这种语句：

 

GRANT SELECT ON mykeyspace.mytable TO alicethehuman; #Don't do this

组成企业的员工们总是来来往往，也会变换工作职责。只要遵循此常规模式，你的数据库权限就会更加易于维护。

---

 

为一些像是“只读”一类的非常常见的权限创建基础的角色，并对其进行标准化管理。

 

这是一个相对简单直白的建议，不过它真的有助于使你的验证设置更加清晰明确。

 

根据公司的角色和职责的不同，我们可以举出不同的例子，不过通常来说会有这些例子：READONLY（只读）、READWRITE（可读可写）以及CREATOR（创建者）。

 

在常用的角色指代名称中添加前缀或后缀可能也会有所帮助。

 

比如如果一个角色是特属于某一个键空间(keyspace)的，可以在这个角色名的前面加一个该键空间的名字缩写。类似的，如果一个角色是特属于某个数据库表的，可以在这个角色名的后面加一个表名的缩写。

 

以上这些只是一些帮助你理解和入门建议而已，你可以发挥自己的创造力来创建规则。记得要将这些规则记录在案，并在你的数据库团队中标准化地使用它们。

---

 

别嵌套得太深！

 

最后一条建议，别把你的RBAC体系(scheme)嵌套得太深。我的意思是，别给角色们赋予太多层级的角色。过多的层级或嵌套会让人难以明确这样的设置的最终效果会是哪些特定的权限。所以，就让事情简单一些吧。

 

大多数情况下，角色应该只由能够赋予其特定对象权限的GRANTS组成，而用户被赋予的角色应该只有一个或者是非常少的数量。

 

请避免将“角色的角色”赋给用户，而且即使系统并没有禁止这种行为——拜托一定不要用GRANT将一个用户赋给另一个用户（记住，它们其实是角色中的一种特殊的类型）。

 

过于复杂的角色结构很容易变成一团乱麻缠绕不清。请别让这种情况发生，让事情简单一些吧。

 

如果你想要更深入探索以上这些想法，但是你还没有已配置权限设置的Cassandra集群，不妨注册Astra并用免费套餐来进行一番试验吧。

 

想要了解更多有关Astra架构和安全性的信息？点击这里获取我们的白皮书。