引言
雲上身份安全是當今企業管理者和雲上運維團隊所面臨的挑戰之一。例如員工離職後發現權限未收回，惡意刪除了大規模應用造成企業損失慘重；又比如員工密鑰泄露導致被惡意攻擊，造成數據泄漏，服務中斷等影響。這些真實且震撼的案例還有許多，針對雲上身份管理不全面所產生的風險究竟又哪些？又應當如何應對？本文將結合案例和最佳實踐與您分享。
從員工入職到離職，進行賬號的全生命週期管理
典型場景一
員工離職是一個典型的身份管理場景， 員工離職後，企業沒有回收或清理員工對於賬號的訪問，離職的員工依然可以持續訪問和管控企業在雲上的資源和數據。將直接導致企業的數據泄漏；如果離職員工蓄意破壞，將直接導致企業的服務中斷，造成企業形象、經濟損失。
如何回收離職員工的訪問權限？遵循「先禁用，後刪除」原則
1. 禁用離職員工賬號的控制檯登錄。
禁用控制檯登錄會較快的將共用賬號的問題暴露出來。如果存在共用的情況，首先重置密碼止血，再爲共用的員工分配新賬號。
2. 查看離職員工賬號下是否持有永久AK。
如果有，則先凍結AK的訪問。員工的賬號中的AK是不能用在生產系統中。如果不確定員工賬號下的AK是否有在生產系統中使用，可以在用戶的AK列表中查看最近使用時間。如果某把AK最近訪問時間至今已經有一段時間，則可以放心禁用。如果上一次訪問之間至今時間較短。則可以配合ActionTrail的能力，排查訪問的服務，以確認是否有使用在生產系統中。如果有使用，則儘快做輪轉。
3. 先禁用再刪除。
在禁用完離職員工賬號訪問控制檯以及API的訪問能力後，通過ActionTrail服務的能力，持續監控一段時間是否有活躍，如果在一段時間內沒有活躍動作（登錄或API調用），則可將用戶及其密鑰刪除。
典型場景二
企業員工在使用阿里雲RAM用戶的時候，會設置用戶的密碼作爲登錄控制檯的憑證。可能由於密碼保存不當，共享密碼、被釣魚等方式造成泄漏。通過審計的方式發現有異常登錄的情況，或者發現有不熟悉的IAM賬號，非自己創建的資源等。均有可能是密碼泄漏導致。密碼泄漏的問題可導致攻擊者冒充員工身份進行資源創建和刪除操作，數據讀取等操作。造成數據泄漏，服務中斷等影響。
如何處置員工密碼泄漏？兩步快速止血
1. 通過重置用戶的密碼進行登錄阻斷，防止攻擊者使用已經泄漏的密碼進一步登錄。
2. 通過審計日誌檢查是否有新創建的賬號或AK。如果有，則對新生成的賬號禁用登錄，並禁用AK。
如何防止密碼泄漏？三招降低風險
1. 加強密碼本身保護是重中之重，從創建用戶那刻開始：
- 設置足夠的密碼強度，設置密碼複用的限制。減少弱密碼或舊密碼的時候
- 設置密碼的過期時間，定期更換密碼。
- 對於登錄密碼錯誤設置嚴格的阻斷策略。一段時間內密碼錯誤次數過多將凍結登錄。
2. 登錄保護，啓用MFA：
MFA爲除密碼以外的新的認證因素。當用戶密碼嚴重通過後，還需要輸入正確的MFA Code纔可以驗證通過。阿里雲的MFA是基於TOTP協議的動態口令，每30秒生成一個新的6位數口令。當密碼泄漏被攻擊者使用，攻擊者無法獲取MFA動態口令也將導致登錄失敗。
3. 審計異常的登錄行爲：
通過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治理身份管理高級技術專家冬山結合產品研發和客戶服務的經驗總結了核心原則：“對於身份管理的最佳實踐，核心是『統一管理身份和認證』，並『進行定期的用戶認證審計』。”
本文爲阿里雲原創內容，未經允許不得轉載。