如何避免濫用用戶界面的角色和權限？

Question

是否有任何方法或體系結構設計模式實現安全，乾淨的基於角色/權限的訪問控制和UI方便，而無需將它們耦合在一起？

長話短說。

我在許多Web應用程序中看到了對角色和權限的模糊使用，並且我經常體驗到這些歧義是如何引起誤解和實現困難的。

這裏是一個簡化的例子。

業務需求說某些特定角色的權限集應拒絕訪問顯示完整地址列表的系統的某個部分。但同時，該角色的用戶需要閱讀其他網頁上的自動完成列表的地址。

我已經看到開發人員多麼魯莽地創建一個權限條目來禁止訪問地址，後來他們發現用戶實際上需要從系統的其他部分讀取地址。然後，他們爲可以讀取地址的特殊情況制定了另一項特定許可。

但對我來說，它似乎模糊和潛在的風險情況。如果用戶無法訪問某些特定數據，則他/她根本無法訪問它。期。爲下拉列表添加特殊權限看起來像是一個故意的安全漏洞。如果用戶通過異步請求加載列表並且服務器使用相同的控制器操作來返回列表（並且它應該 - 避免代碼重複），那麼服務器將如何知道它何時不應該返回地址，如果它們是有時禁止？

這種情況提出了一個問題：「爲什麼不應該在某些特定角色的用戶看到擺在首位地址的完整列表，如果他們通過一些其他途徑訪問列表？」而答案我經常從業務分析師那裏得到這樣的信息：「好的，地址列表並不是出於數據安全的原因而被禁止的，而僅僅是因爲這個特定角色的用戶不希望對地址列表做任何事情，並且這將是他們工作區中的冗餘項目」 。

所以，現在這個問題在我看來很清楚：存在一些權限只是爲了控制UI而不是嚴格控制對某些數據的訪問。這種（ab）使用權限對我來說是錯誤的。因此，這是最初提出的問題。

Answer 1

好寫！幾乎覺得你已經有了答案。

IMO用戶分析和用戶訪問不是同一回事。應該儘可能低地處理訪問權限（例如，如果用戶是否具有對特定SQL表的讀取訪問權限），並且此情況下的配置文件應該僅應用於UI級別（「用戶實際上想要或需要的內容看到」）。

當我們談論具有某種訪問權限控制的應用程序時，UI背後幾乎總是有某種「引擎」實際上存放着所有數據。你可以做的最糟糕的事情是在發動機本身以外的任何地方實施安全。除了通過引擎自己的訪問控制，否則數據不能以任何其他方式訪問，否則不能訪問控制 - 這是UI限制。

但是，這是完美世界：/在現實中，像在工作的各個領域，軟件開發也已行駛torwards被越來越多的成本效益，靈活性和響應到客戶端。毫不奇怪，這引導人們做快速和廉價的決定......像「地獄，我們只是使拉動數據的另一個SQL程序出來作爲管理員」，而不是「我們需要重新評估用戶的訪問權限，和/或可能重新設計我們的表，以保持一致性的訪問權限」。當它完成時，它始終是一個短期（壞）解決方案，但有些解決方案肯定比其他解決方案更多。

作爲指導我會說，如果你不是110％肯定，你在做什麼，這是一個最大的NO-NO存在。

TL; DR：如果有些數據甚至應該在一個地方進行訪問，它不是由訪問控制限制。如果不需要在某處顯示可訪問的數據，請使用用戶/應用程序分析進行過濾。