在數(shù)字化時代，數(shù)據(jù)已成為企業(yè)最寶貴的資產(chǎn)之一。如何管理這些資產(chǎn)，確保數(shù)據(jù)的安全和有效利用，是每個企業(yè)都必須面對的挑戰(zhàn)。本文深入探討了數(shù)據(jù)運營中的權(quán)限問題，分析了數(shù)據(jù)權(quán)限跨產(chǎn)品打通的復(fù)雜性、權(quán)限分配的限制以及角色劃分的重要性。

面向開發(fā)的數(shù)據(jù)權(quán)限，在數(shù)據(jù)管理篇中提到過了，開發(fā)的權(quán)限主要是在開發(fā)團隊，開發(fā)體系內(nèi)進行授權(quán)設(shè)置，可以說還是相對比較固定的，范圍相對較小的。

這里主要說面向運營場景下的數(shù)據(jù)權(quán)限，運營的數(shù)據(jù)權(quán)限面向的群體是整個公司的數(shù)據(jù)消費者，范圍就要更大，因此在功能上需要更加的靈活。但本質(zhì)上，這兩者都是對于數(shù)據(jù)訪問權(quán)限的分配。

一、數(shù)據(jù)權(quán)限的跨產(chǎn)品打通

數(shù)據(jù)運營過程中數(shù)據(jù)的查詢，數(shù)據(jù)服務(wù)API，可視化的報表、大屏，都需要有權(quán)限限制，一個API能查哪些數(shù)據(jù)？一個報表、大屏能夠看到哪些數(shù)據(jù)？使用統(tǒng)一登陸的用戶身份本身就已經(jīng)申請了一些表權(quán)限，這些權(quán)限能不能在其他的產(chǎn)品中直接獲取對應(yīng)的權(quán)限，如果可以，如何做到的？如果不可以為什么要讓用戶反復(fù)申請權(quán)限？這個其實就是一個數(shù)據(jù)權(quán)限跨產(chǎn)品打通的問題。

面對數(shù)據(jù)消費者，一個平臺提供方的理想視角是，我提供了一次數(shù)據(jù)權(quán)限的授權(quán)，那么后續(xù)用戶在使用我平臺提供的其他產(chǎn)品的時候，都能夠自動的獲取到對應(yīng)的數(shù)據(jù)權(quán)限，而不是用戶每到一個產(chǎn)品里，都需要在對應(yīng)的產(chǎn)品里面走一遍申請數(shù)據(jù)權(quán)限的流程。

舉個例子來說，我在即席查詢中申請了一張表A的數(shù)據(jù)權(quán)限，審批通過之后。有用戶基于表A開發(fā)了一張報表，那么只需要對這張報表權(quán)限進行設(shè)置就行了，而不需要再對表A進行權(quán)限操作了。同理，基于表A開發(fā)了一個數(shù)據(jù)服務(wù)API，那么也是能夠自動獲取相應(yīng)的數(shù)據(jù)權(quán)限的。

上面這是一種理想狀態(tài)，實際情況就要復(fù)雜不少了。不同產(chǎn)品中權(quán)限的開通授權(quán)流程不同。不同產(chǎn)品使用的底層數(shù)據(jù)存儲不同。不同產(chǎn)品的權(quán)限授權(quán)模型不同，等等。都讓上面的理想狀態(tài)顯的不那么現(xiàn)實。但是，我想說的是，雖然道路是曲折的，但是目標確實清洗明確的。我們只需要盡量往目標上靠近。來最終打造一個圍繞元數(shù)據(jù)為中心的數(shù)據(jù)權(quán)限體系。（當(dāng)然，也有可能這條路是一條彎路，誰知道那。）

二、權(quán)限分配上的限制

在數(shù)據(jù)運營部分的權(quán)限主要是數(shù)據(jù)的查詢權(quán)限。雖然，僅僅是查詢權(quán)限，但是復(fù)雜的點在于，權(quán)限的二次分配。

權(quán)限分配上的限制的話，需要轉(zhuǎn)換一個視角，數(shù)據(jù)平臺的數(shù)據(jù)開發(fā)者，或者說主要的使用者是數(shù)據(jù)中臺部門的。這個部門在申請數(shù)據(jù)權(quán)限時，數(shù)據(jù)開發(fā)者可能會申請—創(chuàng)建、修改、刪除、查詢等權(quán)限，而在數(shù)據(jù)運營過程中的數(shù)據(jù)消費者，對于數(shù)據(jù)中臺已經(jīng)加工好的表，只能申請查詢權(quán)限。

而且，在數(shù)據(jù)運營過程中的權(quán)限分配存在大量二次分配的場景，一個業(yè)務(wù)部門，部門數(shù)據(jù)相關(guān)同事申請了權(quán)限之后。在部門內(nèi)部希望做到二次分配，而又不能分配出部門。（其實開發(fā)的過程中也希望有類似的）。這就希望能夠和組織架構(gòu)進行結(jié)合了。

能看到哪些，不能看到哪些？權(quán)限分配下去了，如何進行在產(chǎn)品內(nèi)的權(quán)限二次分配。這些都是需要考慮的。和數(shù)據(jù)管理篇中【數(shù)據(jù)權(quán)限是個大問題】中提到的RBAC模型不一定適用所有場景類似，相同的，在運營過程中的權(quán)限分配也不一定一個準則適用全部場景，需要和內(nèi)部的用數(shù)流程，組織機構(gòu)等等相結(jié)合。

三、角色劃分

既然說到權(quán)限的二次分配，就需要將權(quán)限分配給一個二級的管理員，讓二級的管理員在對應(yīng)的小組織內(nèi)部進行二次權(quán)限分配。這個很重要，能夠減少平臺方大量的權(quán)限分配。但是，二級管理員分出去的權(quán)限也需要能夠可查看，可收回。

題外話：寫到角色劃分突然發(fā)現(xiàn)上面的一系列內(nèi)容都沒有涉及到功能和角色說明的，這個在一個平臺內(nèi)也是很重要的。但是既然寫到這里了都沒有發(fā)現(xiàn)什么缺失的地方，而且在前言二里面也說了平臺的使用用戶，一定程度上算是一個粗的角色劃分吧。暫時就不補這一部分了，后續(xù)有機會再添加吧。

四、總結(jié)

整個數(shù)據(jù)平臺最終目標是支撐業(yè)務(wù)的。所以數(shù)據(jù)運營是一個很關(guān)鍵的部分，相當(dāng)于一個價值出口。運營過程中的權(quán)限則是這個出口的一個守門員。既要讓數(shù)據(jù)出去，又要讓數(shù)據(jù)安全的出去。