「最小許可權訪問」依然有問題

最小許可權訪問原則是有效的特權訪問管理（PAM）項目中的關鍵組成部分，但並非唯一的原則。全面的PAM項目還應輔以口令管理、會話審計和分析，才能真正交付項目設計之初的安全目標。

自從身份驗證和授權成為訪問計算機系統的常規操作，最小許可權原則(POLP)就是實際上的安全底線。其核心思想在於僅為用戶分配供其完成任務所需訪問公司數據及系統的最小許可權——不多也不少，恰恰夠完成工作。理論上，遵守POLP似乎是最佳身份與訪問管理策略，但實現最小許可權往往說得容易做起來難。

為什麼最小許可權原則一直難以實現?

原因很多。首先，要實現最小許可權就得對每位用戶及其角色所需的恰當許可權有著清晰的理解。其次，要有某種工具來實施所定義的許可權等級。再次，授權的定義與實施一定不能干擾到用戶的正常工作。最小許可權原則能保護所有類型的用戶訪問，尤其是管理員許可權訪問。

有些系統角色定義良好，對與這些角色相關聯的許可權也有著細粒度的劃分，在這些系統上實現POLP就比較容易。但有些系統就沒那麼配合了，因為它們缺乏定義和實現各級許可權劃分的原生工具。對於後者，公司企業往往只能靠自己粗淺簡陋的許可權定義設備和有限的工具來實現POLP。造成的結果就是，很多公司企業非常想要施行最小許可權，但實際上卻只在非常有限的範圍內真正實現了POLP。

從管理員許可權的角度看，很多公司圖省事直接給所有可能需要該許可權的用戶都分發了管理員(或者說「超級用戶」)憑證，讓太多的員工掌握了對數據及系統的過多許可權，根本就是完全背離了POLP。

管理員許可權應用最小許可權原則的經典案例是Unix和Linux系統上的開源工具「sudo」(「 superuser do 」的縮寫)。該工具允許公司在「sudoer」文件中定義具有「全權」root憑證部分許可權的角色。管理員登錄後得在命令前加「su」前綴才可以嘗試執行特權命令，且該命令若不被sudoer策略允許，執行嘗試還會被拒絕。

sudo在很多情況下運行良好。但當Unix/Linux系統環境達到一定的規模，每台Unix/Linux伺服器上獨立運行sudo就讓最小許可權的施行變得難以控制，容易出錯，適得其反了。於是，各種特權訪問管理(PAM)解決方案應運而生，要麼用覆蓋整個環境的解決方案貫徹統一的策略和實現規則集並輔以鍵盤記錄，要麼以覆蓋所有實例的集中式策略增強sudo(相對於分散在各實例上的多個sudoer文件)。

但是，Unix/Linux通常只是PAM整體視圖中的一部分。還有其他系統會留有未經審查的管理員許可權訪問。比如說，大多數公司企業都會設置微軟活動目錄(AD)和Azure活動目錄(AAD)作為終端用戶的主要訪問入口。這就讓AD/AAD管理員成為了任何PAM項目的重要內容，POLP也應擴展到這些管理員身上。

然而，現實往往沒那麼簡單，除了Unix/Linux和AD/AAD平台，現代異構企業中非常難以貫徹一致的POLP。有些應用內置了供POLP實現的功能，而有些應用壓根兒就沒考慮過POLP。

前路艱險，為了儘可能展開PAM項目，幫助企業從POLP中收穫最多益處，可以參考下列建議：

1. 控制好你能控制的：

在Unix/Linux系統中尋找機會增強原生sudo，清除最小許可權實現過程中的漏洞並提升操作效率。用商業解決方案增強或替換sudo能帶來巨大的安全收益。同樣地，尋求第三方輔助，去除默認非此即彼的管理員許可權設置，是當下AD/AAD應用POLP的良好方式。

2. 使用特權口令管理器：

如果最小許可權無法實現，可以嘗試用特權口令管理器來共享管理員口令。隨著日常Unix/Linux和AD/AAD管理員訪問以最小許可權模式委託出去，我們很有必要在其他特權口令的核發、批准和管理上實現安全和自動化。這麼做可以去除掉未核准管理員訪問的匿名性，對整個過程加以管控。特權口令管理器還可提供向單個用戶發放被委託管理員賬戶整套許可權的另一種途徑。委託出日常行為許可權並為緊急事件賦予超級用戶訪問許可權。

3. 審計行為：

如果不能監視管理員用他們手中的特權都幹了些什麼，PAM項目就稱不上完整。運用會話審計和鍵盤記錄來增強管理員許可權委託，可以讓你知道這些許可權都被用來了幹了什麼。

4. 實現分析：

PAM拼圖的最後一塊就是實現分析功能。特權行為分析有助於檢測異常及危險行為，身份分析則可評估特權口令管理器和最小許可權模式中與管理員許可權相關的那些權利。對同類管理員進行權利與許可權分析，可以幫助公司發現其最小許可權模式中的弱點。

POLP是有效PAM項目中的關鍵組成部分，但並非唯一的原則。全面的PAM項目還應輔以口令管理、會話審計和分析，才能真正交付項目設計之初的安全目標。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！