技術基礎 | 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架構和安全性的資訊？點擊這裡獲取我們的白皮書。
