企業IGA落地的七點建議

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

定義身份

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

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

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

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

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

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

有效身份

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

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

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

認證身份

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

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

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

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

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

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

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

云身份認證

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

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

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

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

內部授權

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

1.通過梳理現有資產、系統與服務，根據相關“等?！钡囊蠛统醪斤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.在上述普通用戶通用配置文件的基礎上，豐富最小權限的具體基線內容。進而通過該基線來設定預期的正?；顒宇愋图?，并將其作為異常檢測系統的參考依據。

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

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

外部權限

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

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

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

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

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

問責審查

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

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

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

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

結語

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