談身份管理之進階篇 - 快速瞭解從管理到治理的最佳方案

簡介： 雲上身份安全是當今企業管理者和雲上運維團隊所面臨的挑戰之一，針對雲上身份管理不全面所產生的風險究竟又哪些？又應當如何應對？本文將結合案例和最佳實踐與您分享。

引言

雲上身份安全是當今企業管理者和雲上運維團隊所面臨的挑戰之一。例如員工離職後發現權限未收回，惡意刪除了大規模應用形成企業損失慘重；又好比員工密鑰泄露致使被惡意攻擊，形成數據泄漏，服務中斷等影響。這些真實且震撼的案例還有許多，針對雲上身份管理不全面所產生的風險究竟又哪些？又應當如何應對？本文將結合案例和最佳實踐與您分享。

從員工入職到離職，進行帳號的全生命週期管理

典型場景一

員工離職是一個典型的身份管理場景， 員工離職後，企業沒有回收或清理員工對於帳號的訪問，離職的員工依然能夠持續訪問和管控企業在雲上的資源和數據。將直接致使企業的數據泄漏；若是離職員工蓄意破壞，將直接致使企業的服務中斷，形成企業形象、經濟損失。

如何回收離職員工的訪問權限？遵循「先禁用，後刪除」原則

1. 禁用離職員工帳號的控制檯登陸。

禁用控制檯登陸會較快的將共用帳號的問題暴露出來。若是存在共用的狀況，首先重置密碼止血，再爲共用的員工分配新帳號。

2. 查看離職員工帳號下是否持有永久AK。

若是有，則先凍結AK的訪問。員工的帳號中的AK是不能用在生產系統中。若是不肯定員工帳號下的AK是否有在生產系統中使用，能夠在用戶的AK列表中查看最近使用時間。若是某把AK最近訪問時間至今已經有一段時間，則能夠放心禁用。若是上一次訪問之間至今時間較短。則能夠配合ActionTrail的能力，排查訪問的服務，以確認是否有使用在生產系統中。若是有使用，則儘快作輪轉。

3. 先禁用再刪除。

在禁用完離職員工帳號訪問控制檯以及API的訪問能力後，經過ActionTrail服務的能力，持續監控一段時間是否有活躍，若是在一段時間內沒有活躍動做（登陸或API調用），則可將用戶及其密鑰刪除。

典型場景二

企業員工在使用阿里雲RAM用戶的時候，會設置用戶的密碼做爲登陸控制檯的憑證。可能因爲密碼保存不當，共享密碼、被釣魚等方式形成泄漏。經過審計的方式發現有異常登陸的狀況，或者發現有不熟悉的IAM帳號，非本身建立的資源等。均有多是密碼泄漏致使。密碼泄漏的問題可致使攻擊者冒充員工身份進行資源建立和刪除操做，數據讀取等操做。形成數據泄漏，服務中斷等影響。

如何處置員工密碼泄漏？兩步快速止血

1. 經過重置用戶的密碼進行登陸阻斷，防止攻擊者使用已經泄漏的密碼進一步登陸。
2. 經過審計日誌檢查是否有新建立的帳號或AK。若是有，則對新生成的帳號禁用登陸，並禁用AK。

如何防止密碼泄漏？三招下降風險

1. 增強密碼自己保護是重中之重，從建立用戶那刻開始：

-設置足夠的密碼強度，設置密碼複用的限制。減小弱密碼或舊密碼的時候

-設置密碼的過時時間，按期更換密碼。

-對於登陸密碼錯誤設置嚴格的阻斷策略。一段時間內密碼錯誤次數過多將凍結登陸。

1. 登陸保護，啓用MFA：

MFA爲除密碼之外的新的認證因素。當用戶密碼嚴重經過後，還須要輸入正確的MFA Code才能夠驗證經過。阿里雲的MFA是基於TOTP協議的動態口令，每30秒生成一個新的6位數口令。當密碼泄漏被攻擊者使用，攻擊者沒法獲取MFA動態口令也將致使登陸失敗。

1. 審計異常的登陸行爲：

經過ActionTrail中的登陸成功和失敗的日誌，經過UA，IP等方式定位疑似異常登陸行爲的用戶。並經過重置密碼，啓用MFA等方式進行保護。

在阿里雲，進行員工入職，離職場景身份管理的最佳實踐

一家企業的員工入職和離職，涉及到分配雲平臺的帳號的時候。雲上的帳號身份的生命週期管理須要和本地的員工的身份管理統一處理。

用戶入職

-分配新帳號：經過阿里雲控制檯或集成IMS OpenAPI同步建立用戶，不要與其餘用戶共用，不然將致使不可審計，沒法回收權限的問題。

-爲帳號分配密碼：在目錄級別配置密碼強度及合適的密碼生命週期，爲用戶建立合適的密碼，開啓MFA，配置合適的登陸策略

-爲帳號分配密鑰：區分員工使用的帳號和服務使用的帳號，員工使用的帳號開啓永久AK，使用CloudShell替代。服務使用的帳號保護好AK Secret，有條件按期作輪轉。

員工離職

-遵循先禁用，後刪除的原則，禁用用戶的控制檯登陸，禁用用戶的AK，有問題可及時回滾配置。

-經過OpenAPI的方式集成在本地IDP，或經過控制檯的方式進行關聯操做。

-離職員工刪除：人員離職一段時間後，經過CredentialReport和ActionTrail的審計日誌確認不活躍後，刪除不活躍的帳號和AK。

生命週期內按期審計

使用ActionTrail和CredentialReport，對員工的帳號活躍度以及操做記錄作持續審計，發現不活躍的帳號並及時整改。

一勞永逸的解決身份管理和認證的統一問題

一般在企業內，分配和回收員工的工做由HR的系統觸發，(或企業本身的雲管平臺觸發)，上雲帳號的管理員/系統接受到了這個事件後，人肉/系統自動分配或回收用戶的登陸權限。可是這裏可能要依賴人肉管理，或依賴企業開發系統去實現。所以也給企業的管理帶來了額外的管理和研發審計的成本。一旦忘記操做或系統存在bug，將給企業的數據安全和生產穩定性帶來風險。

那麼，有沒有更好的辦法，不額外給員工頒發阿里雲RAM用戶的登陸密碼，將登陸認證集中在企業本地的員工系統？答案是有的，企業能夠經過使用如下兩種方式將身份管理和身份認證統一到本地IDP進行集中管理：

方案一：使用SSO將身份認證統一到本地IDP。

阿里雲做爲SP（Service provider），支持SAML協議。企業本地身份系統可使用SAML 協議，打通本地到雲上的控制檯訪問。無需在雲上額外的爲用戶配置訪問控制檯的認證方式。

企業的管理員首先配置好企業本地IDP和阿里雲帳號的信任關係，用戶在企業本地IDP認證完成後，企業IDP向阿里雲發起SAML SSO。基於配置好的信任關係，阿里雲側按照SAML SSO中描述的身份信息和session信息生成登陸態。完成了指定身份的登陸。目前登陸行爲包含兩種方式：

1）基於RAM用戶的SAML SSO

企業用戶經過OpenAPI或SCIM將企業員工的信息同步到雲上，經過SAML Response中指定的用戶肯定阿里雲RAM的用戶，以指定用戶的身份登陸到阿里雲上。好處是以RAM用戶的身份登陸到阿里雲的控制檯，權限能夠根據用戶作定製。

2）基於RAM角色的SAML SSO

企業經過OpenAPI或控制檯建立角色並授予權限，經過SAML Response中指定的角色肯定阿里雲的RAM的角色，以指定角色的身份登陸到阿里雲上。好處是以RAM角色的身份登陸到阿里雲的控制檯，無需配置額外的身份，企業員工能夠共用角色。

企業基於這兩種方式SSO到阿里雲控制檯，只需在本地的IDP維護認證信息，無需爲員工在阿里雲的RAM帳號上建立密碼。員工只須要保管好本身在企業IDP中的密碼便可。同時當員工發生離職後，企業只須要回收本地員工的帳號，員工沒法直接訪問雲端的帳號。

方案二：使用IMS OpenAPI/SCIM將員工身份管理統一到本地IDP

• IMS 提供OpenAPI供企業管理系統集成，當本地員工發生入職，離職或調崗的時候，能夠經過IMS 的OpenAPI在雲端進行異步的管理動做。
• 企業服務若是支持SCIM，能夠經過RAM提供的SCIM接口，自動的管理用戶的新增和刪除操做。（員工對應的帳號的AK不要用於生產系統，若是企業員工發生離職或者調崗，觸發了雲端帳號的刪除動做，將直接刪除帳號。對應的AK一併刪除。若是員工帳號的AK用於生產系統，可能直接致使故障）。

總結

阿里雲企業IT治理身份管理高級技術專家冬山結合產品研發和客戶服務的經驗總結了核心原則：「對於身份管理的最佳實踐，核心是『統一管理身份和認證』，並『進行按期的用戶認證審計』。」

原文連接本文爲阿里雲原創內容，未經容許不得轉載