將數據安全捍衛到底：權限管理（acl）文檔全新發布

原文發表於 LeanCloud Blog

隨着使用 LeanCloud 的開發者愈來愈多，你們慢慢注意到一些在開發初期容易被忽視的漏洞，其中最容易被忽略但在咱們的文檔中又佔據了重要地位的內容就是：權限管理（ACL）的使用。

ACL 全稱爲 Access Control List，維基百科解釋爲：

存取控制串列，是使用以訪問控制矩陣爲基礎的訪問控制方法，每個對象對應一個串列主體。訪問控制表描述每個對象各自的訪問控制，並記錄可對此對象進行訪問的全部主體對象的權限。

等等，這個聽上去怎麼一陣頭暈，這跟個人應用數據安全到底有什麼關係？先彆着急，咱們固然不會用這麼晦澀的語言來說解 ACL，來看下面的例子：

公司的保險櫃只有財務人員才能打開，那麼對於保險櫃來講，其 ACL 能夠表示爲：

{
    "role:finance": {
        "access": true
    }
}

即只有角色（role）爲 財務（finance）的人才擁有打開保險櫃的權限（access ＝ true）。

<!--more-->

這即是實現 ACL 的一種方式。實際上 ACL 就是一張清單，羅列出誰均可以訪問和操做什麼，其機制至關於操做系統中「用戶」和「用戶組」—— 你若指定只有某個用戶或用戶組才能查看或修改文件或文件夾的內容，那不相干的人就被拒之門外了。在數據庫系統中這種控制管理也很常見，好比，工資表只能由人事部專員來讀取和修改，庫存表可讓銷售人員讀取，但不能修改等等。

那回到「應用數據安全」這個話題上來。在使用 LeanCloud 對數據進行增刪改查的時候，你是否想過也應該在應用中實施 ACL 機制來保護數據呢？

答案是確定的，並且是很是必要的。

使用 ACL 的必要性

你們知道，咱們在使用 LeanCloud SDK 時，須要在初始化代碼中明文寫入 AppId 和 AppKey。若是你的競爭對手或是惡意用戶，反編譯了你的 apk 或者打包好的安裝程序，就能提取出 AppId 和 AppKey，這樣就能夠模擬客戶端身份來提交請求，非法篡改數據。

而用 JavaScript SDK 作開發都涉及不到反編譯，只要在瀏覽器中查看源代碼，這些信息就都暴露無疑。再者，已離職的開發團隊成員也曾經使用或仍知曉這些關鍵信息，這也是隱患。因此很顯然，咱們不能把 AppId 和 AppKey 做爲應用僅有的防護體系，更況且有些高手還能直接從應用連接或網絡請求中截獲敏感數據來僞造請求。

可是，若是使用了 ACL，以上的安全隱患就均可以免了！

總體上講，由於使用了 ACL 的數據只容許指定的用戶或者指定的角色來讀取，而這種用戶或角色信息在反編譯的代碼中是不存在的，因此即便請求被模擬發送到 LeanCloud 服務端，也會由於鑑權失敗而被拒絕執行，從而數據安全有了保障。

具體來看，在 LeanCloud 後端的數據表中，每個 AVObject 都會有本身的 ACL，這個 ACL 就是提供給開發者用來管理權限的。例如，一個對象的默認的 ACL 以下：

{
    "*": {
        "read": true,
        "write": true
    }
}

這表示該對象的數據對全部人都是開放的，只要是合法的修改請求（即 AppId 和 AppKey 正確），都會被 LeanCloud 雲端執行。

若是正確設置了 ACL，咱們能夠只讓具備某些特定角色的用戶發來的修改請求生效：

{
    "*": {
        "read": true
    },
    "role:Administrator": {
        "write": true
    }
}

以上設置表明：全部人均可讀，可是隻有角色是 Administrator 的用戶才能修改。

關於 ACL 的深刻使用，咱們還編寫好了詳細的開發指南，歡迎圍觀。

• 《ACL 快速入門：iOS | Android | JavaScript》：ACL 原理和使用的必要性

• 《權限管理使用指南：iOS | Android | JavaScript》：ACL 的具體使用細則和代碼示例

最後，做爲開發者永遠的小夥伴，LeanCloud 在此向你舒適提示：

飛馳在道路上的時候別忘了給車加個保險桿！