去年底，由于位于外網主機上的某個多年未用的管理員級賬號被黑，導致了筆者單位內網普通賬號的大面積頻繁被鎖，以及部分文件的被竊事故。事后我們的IT安全部門協(xié)同各個職能部門從根源上入手，對整個現(xiàn)有系統(tǒng)和服務開展了用戶身份的治理和管理（Identity Governance and Administration，IGA）工作。此次整飭涉及到了賬號權限在系統(tǒng)中的整個生命周期和使用的各個方面。我們總結起來可以用“WVA3R”來高度概括，而具體的落地則包含有如下的七個要點。

定義身份

作為第一步，我們首先要定義好登錄訪問者可能是誰（Who）的問題。其中包括：

1.遵循“按需分配”的原則。雖然這是老生常談，但是我們在企業(yè)實踐中往往無法執(zhí)行到位，經常會為了避免后續(xù)的麻煩而事先定義了過剩的身份標識（ID），從而導致了長久以來一些賬號、甚至是用戶組空置在系統(tǒng)之中，不但造成了資源的浪費，而且給攻擊埋下了隱患。

2.標準化普通用戶的通用配置文件（Profile）模板。套用安全治理的理論，這叫做設定好基線。通過在初始化時定義各種屬性標簽的默認值，系統(tǒng)內可以產生統(tǒng)一的配置原點。而我們在后續(xù)的運維中也可能按照實際情況去調整和更新基線。

3.為部分特定、且要求嚴格的應用或服務添加并分配細粒度的用戶組。同時我們也要做好相應的配置與變更記錄，以及確保在整個系統(tǒng)中名稱的唯一性。

4.身份標識的命名規(guī)則要做到標準化。當然這是一個雙刃劍，雖然方便了運維人員能從名稱上判定其基本身份，不過同樣也方便了攻擊者一眼看出ID的用途，并輕易推測出相應權限。因此在實際設置中，應選擇性將一些“高?！钡南到y(tǒng)管理員賬號進行重命名式的隱藏。

5.隨著DevOps理念在各個企業(yè)的廣泛應用，身份標識的定義可以不僅局限服務于真實用戶，我們完全可以對硬件資源、軟件服務、以及需要訪問到的對象、模塊和數(shù)據(jù)庫等應用進行靈活定義與分配。

有效身份

有了身份標識就確定了用戶在系統(tǒng)中的存在性。而第二步需要解決的是有效性（Validity）問題，也就是要掌控ID的時效性。因此我們要做到以下幾點。

1.事先定好規(guī)則：對超過一定天數(shù)（如90天）未被使用過的ID，系統(tǒng)應自動設置為暫停（Suspended）狀態(tài)；而對超過更多時間（如180天）的ID，則在理論上應被系統(tǒng)自動刪除。當然在企業(yè)的具體實務中需靈活應對。例如，通過使用歸檔轉存的方式可以僅保留其分配過的記錄，這樣既滿足了合規(guī)的要求，又方便了人員回歸和資源重用時的ID延續(xù)性。

2.事后及時處理：這主要和管理有關，需要定期向各個部門發(fā)送相應部門員工ID的列表，并各自通過反饋來確認列表的有效性。

認證身份

身份認證是A3中的第一個 A，即 Authentication，其中密碼是必不可少的一種基礎驗證方式。此處羅列出一些通用原則來比對檢查和查缺補漏：

1.用戶的登錄界面上不應顯示前一次登錄所使用過的ID信息。

2.各種內部服務都一律需要執(zhí)行密碼驗證，且密碼不能為空。

3.通過復雜程度和變更周期等維度實施強密碼策略。

4.基于用戶體驗和系統(tǒng)效率，部署單點登錄（Single Sign On，SSO），同時也能簡化用戶持有的密碼數(shù)量。

5.設置專有的中央存儲庫（Repository），用來統(tǒng)一存放ID和密碼。

6.對于部分特殊應用、以及遠程訪問，應采用多因素登錄認證（Multi-factor Authentication，MFA）的方式。充分融合：你知道什么（如密碼口令）、你擁有什么（如移動手機或特定設備）、以及你是什么（如人臉識別或指紋傳感）等多維度的信息，予以綜合驗證。

云身份認證

區(qū)別于上述傳統(tǒng)的認證模式，我們針對企業(yè)中用到的SaaS，采用了云身份認證。它可以被理解為是將SSO的服務延伸到了云端。通過所謂身份認證即服務（IDaaS）的方式，我們補足并實現(xiàn)了企業(yè)在如下方面的應用需求：

1.當員工擁有并使用多臺移動設備去訪問企業(yè)服務時，能結合雙/多因素信息實現(xiàn)身份認證。

2.打通了云上與云下，將IDaaS的存儲庫與企業(yè)現(xiàn)有的AD及LDAP目錄無縫集成，實現(xiàn)了聯(lián)合高效的服務認證。

3.通過各種API，企業(yè)不但可以將身份認證服務轉交給云端處理，還能前瞻性地為耗費流量的、將來可能上馬的各種可穿戴設備、以及物聯(lián)網（IoT）設備做好了技術和策略上的準備。

內部授權

遵循經典的基于角色控制（RBAC）和按需而用（Need to Use）原則，實現(xiàn)第二A，即Authorization。具體在企業(yè)的實踐管控中，我們從如下方面進行了治理：

1.通過梳理現(xiàn)有資產、系統(tǒng)與服務，根據(jù)相關“等?！钡囊蠛统醪斤L險評估的結果，來構建不同的訪問級別。

2.通過諸如No Access(NA)、Read(R)、Write(R)、Execute(X)、Delete(D)、List(L)、Full Control(FC)的權限定義，和諸如Guest(R-L)、Group(R-X)、Owner(R-W-X-D)、Admin(FC)的角色對應，來細粒度地管理電子和紙質的文件及服務。

3.在上述普通用戶通用配置文件的基礎上，豐富最小權限的具體基線內容。進而通過該基線來設定預期的正?；顒宇愋图?，并將其作為異常檢測系統(tǒng)的參考依據(jù)。

4.針對各類用戶對于權限的申請、增加、削減和變更需求，引入委員會的標準批復與管理流程，并文檔化全程記錄。

5.實現(xiàn)技術部門與人事的聯(lián)動關系，保證在接報有關崗位變動的24小時內，完成系統(tǒng)權限的相應調整。

外部權限

如今，隨著移動辦公和云服務的廣泛應用，我們企業(yè)IT系統(tǒng)所面對的安全風險，無論是在時間上還是在空間上，都已突破了舊的規(guī)律和屏障。因此我們需要通過如下方面管理好外部人員，通過互聯(lián)網運用手持設備對系統(tǒng)的各種訪問。

1.羅列出提供遠程訪問的所有服務條目，一般包括：虛擬桌面、Web版郵箱、VPN、移動應用以及MDM/MAM管理界面等。

2.對不同的外部應用設置不同的會話保持時限（Idle Session）。

3.執(zhí)行嚴格的權限申請流程，通過預定義各種風險向量和相應權值，得出申請方基于風險的評估值（Risk Based Assessment，RBA）。

4.以明確且特定的任務為導向，僅授予最小權限。

問責審查

如果說上面提到的六點是針對賬號與權限管理的“充分條件”的話，那么它的“必要條件”就是問責與審查（Account and Review）。只有記錄和掌握了各類ID的各種活動，我們才能形成正反饋，去不斷地調整和改進控制措施。具體內容包括如下方面：

1.借用日志系統(tǒng)或安全信息與事件管理（Security Information and Event Management，SIEM）工具，記錄各個ID從登錄系統(tǒng)時所檢驗的信任憑證、獲取的相應權限、執(zhí)行的各類操作、到結果成功與否、以及是否安全退出的全過程。

2.對歷史信息的匯總和保存，報告的生成與趨勢的分析。

3.設定管理委員會定期（如每90天）引導各個部門人員對當前系統(tǒng)中的各種ID和相應的權限列表進行自查；定期與各類所有者合作，對資源秘級要求進行核實；定期對賬號相關的違規(guī)事件進行審查，及時注銷ID或回收權限。

結語

可以說，企業(yè)在日常運維中正是以上述七點為管控的依據(jù)，在與內外部威脅的“零和博弈”中持續(xù)保護著自己的安全與可控。希望讀者通過參考和借鑒上述原則，也能動態(tài)地實現(xiàn)企業(yè)資源的“帕累托最優(yōu)”。