身份是指在雲環境中執行操作的實體。雲上主要有兩種身份類型：人員身份和程式身份。
人員身份通常代表組織中的個人，比如企業中的安全性系統管理員、營運管理員、應用開發人員。通常通過阿里雲的控制台、CLI、特定情境下的用戶端等方式對雲上的資源進行操作。
程式身份則代表應用程式或服務，往往是通過阿里雲的 OpenAPI 來訪問雲上的資源和資料。
在阿里雲上，針對兩種類型的身份管理，基於安全的最小化原則，核心有兩大原則：縮小暴露時間長度和縮小暴露面積。
縮小暴露時間長度指儘可能使用臨時身份或憑據替代固定身份或憑據，即使使用固定身份或憑據，也建議定期輪轉。
縮小暴露面積指儘可能安全保管密鑰或憑據，避免在不同身份類型之間混用憑據或身份。
基於這兩大核心原則，針對不同類型的身份管理，在阿里雲上有以下最佳實務可以參考。
人員身份
避免使用 Root 身份
在阿里雲上，註冊完一個阿里雲帳號後，即可通過使用者名稱和密碼的方式登入到阿里雲控制台，登入成功後，即獲得了 Root 身份。該身份具有該帳號下所有的許可權，一旦帳號密碼泄漏，風險極高。另外，如果多人共用該身份，每個人都保有該帳號的使用者名稱和密碼，會增加泄漏的可能。同時，多人共用的情況下，在雲上的動作記錄中無法區分出是組織中哪個人使用了該身份進行了操作，也無法進行進一步溯源。因此，除了極個別情境，應該儘可能的使用阿里雲 RAM（Resource Access Management，存取控制）身份進行雲上資源的訪問，避免使用阿里雲帳號的 Root 身份。對於 Root 身份的使用，參考下述“建立更安全的登入機制”一節中的最佳實務，提升 Root 身份的安全性。
實現人員身份的統一認證
通過集中化的身份供應商（Identity Provider，簡稱 IdP）來進行人員身份的統一認證，能夠簡化人員身份的管理，確保組織內在雲上、雲下的人員身份的一致性。當人員結構變更、人員入、離職時，能夠在一個地方完成人員身份的配置。 對於雲環境的使用者來說，也無需為其頒發額外的使用者名稱和密碼（如 RAM 使用者名稱和密碼），只需要保管好其在組織內的 IdP 中的身份和憑據即可。對於一些組織而言，通過一些網路上的存取控制措施，使其 IdP 僅能夠在企業內網訪問，給人員身份的認證過程增加了額外一個限制條件，進一步保障了企業人員身份的安全。
阿里雲支援基於 SAML 2.0 協議的單點登入（Single Sign On，簡稱 SSO）。在阿里雲上，我們建議通過 RAM SSO的方式跟組織內的 IdP 進行整合，實現人員身份的統一認證。對於雲上有多個阿里雲帳號的複雜組織，還可以通過雲SSO進行多帳號下的 SSO 集中化配置，進一步實現多帳號下的人員身份統一管理，提升管理效率。
建立更安全的登入機制
對於人員身份的登入方式，往往是通過使用者名稱和密碼的方式進行。一旦使用者名稱和密碼泄漏，攻擊者極有可能通過該身份登入阿里雲，造成一些不可挽回的損失。因此，對於人員身份來說，保護好使用者名稱和密碼顯得尤為重要。可以從以下幾種方式提升登入方式的安全性：
提升密碼強度。如增加密碼位元、混合使用數字、大小寫字母、特殊字元等。針對阿里雲 RAM 使用者，管理員可以設定密碼強度規則，強制 RAM 使用者使用更複雜的密碼，降低密碼泄漏和被破解的風險。
避免密碼混用。在不同的服務、網站，或不同的使用者共用一個密碼，增加了密碼的暴露面積，會增加密碼泄漏的可能性。如果其中一個服務或使用者的密碼泄漏，那攻擊者就可以通過嘗試登入的方式，找到共用密碼的其他服務。因此，確保不同服務、不同使用者使用不同的密碼，能夠降低密碼泄漏的風險。
定期輪轉密碼。密碼存在的時間越長，泄漏風險越高。通過定期重設密碼，降低單個密碼存在的時間長度，能夠進一步降低密碼泄漏風險。針對阿里雲 RAM 使用者，管理員可以在密碼強度規則中設定密碼有效期間，來實現密碼定期輪轉。
使用多因素驗證。多因素認證 MFA（Multi Factor Authentication）是一種簡單有效安全實踐，在使用者名稱和密碼之外再增加一層安全保護，用於登入阿里雲或進行敏感操作時的二次身分識別驗證，以此保護您的帳號更安全。阿里雲支援虛擬 MFA、U2F 安全密鑰等多種二次驗證方式。建議為雲上的人員身份都啟用二次驗證。對於使用雲下 IdP 進行統一身份認證的組織，也建議在 IdP 側提供二次驗證的選項。
通過角色扮演代替固定身份
基於縮小暴露面積的原則，使用臨時身份替代固定身份，能極大降低身份泄漏風險，同時對於人員身份來說，也能夠抽象人員許可權模型，如按人員職能進行角色劃分，有利於正常化人員使用權限設定，提升管理效率。
在雲上，建議通過單點登入（Single Sign-on，簡稱 SSO），基於角色扮演的方式，實現人員身份的管理。
程式身份
不使用雲帳號 AccessKey
雲帳號 AccessKey 等同於阿里雲帳號的 Root 許可權，也就是該帳號內的完全系統管理權限，而且無法進行條件限制（例如：訪問來源IP地址、訪問時間等），也無法縮小許可權，一旦泄漏風險極大。對於程式訪問的情境，請使用 RAM 使用者的 AccessKey 來進行阿里雲 API 的調用。
避免共用 AccessKey
多個程式身份共用 AccessKey，或程式身份、人員身份共用 AccessKey 的情況下，AccessKey 所關聯的許可權需要包含所有身份的使用情境，導致許可權擴大。另外，共用情境下，一處泄漏會導致所有應用都受到影響，風險擴大，同時增加了泄漏後的止血難度。對於同一個應用的不同環境，如生產環境、測試環境，往往需要訪問不同的資源，同時，測試環境代碼往往不夠穩定和健壯，更容易有泄漏風險，如果共用同一個 AccessKey，測試環境 AccessKey 泄漏後也極容易造成對生產環境的影響，導致業務安全風險。
因此，針對不同應用、大型應用的不同模組、同一個應用（或模組）的不同環境（如生產環境、測試環境等），都建議建立不同的 AccessKey 供程式身份使用，每個 AccessKey 只有該情境下所需要的許可權，避免共用 AccessKey 的情況。
定期輪轉 AccessKey
同人員身份的使用者名稱密碼一樣，AccessKey 建立和使用時間越長，泄漏的風險越高。每隔一段時間，通過建立新的 AccessKey，替換掉應用在使用的 AccessKey，並將舊 AccessKey 進行禁用和刪除，實現 AccessKey 的定期輪轉。另外，也可以通過阿里雲Key Management Service（Key Management Service，簡稱 KMS）的憑據管家功能，實現自動化的定期 AccessKey 輪轉。
除了 AccessKey，其餘類型的程式訪問憑據，都應該進行定期輪轉，降低憑據泄漏風險。
使用臨時憑據代替固定憑據
通過給 RAM 使用者或雲帳號的 Root 身份建立 AccessKey 供程式調用，都屬於固定憑據類型。一旦建立出來，在刪除之前，就是由固定的 AccessKey ID 和 AccessKey Secret 組成了該憑據。使用固定憑據會造成很多風險，比如應用研發人員將固定 AccessKey 寫入了代碼中，並將其上傳到了 Github 等公開倉庫，造成了 AccessKey 泄漏，最終導致業務受損。在阿里雲上，我們建議儘可能通過角色扮演的方式擷取臨時憑據 STS Token，代替固定 AccessKey 的使用。每個 STS Token 產生後，在超過角色最大會話時間（小時級）後，自動失效，從而降低了因固定憑據泄漏導致的風險。
針對不同類型的雲上應用部署方式，阿里雲提供了相應的功能，整合了 STS Token 憑據的使用：
針對在 ECS 執行個體上部署的應用，執行個體RAM角色，將 RAM 角色跟執行個體進行綁定，應用程式中即可通過執行個體中繼資料服務擷取臨時授權Token。
針對在 ACK 上部署的應用，通過RRSA功能，實現 RAM 角色和指定 ServiceAccount 進行綁定，在 Pod 維度即可扮演對應角色實現 STS Token 的擷取。
針對在Function Compute中部署的 Serverless 應用，可以為對應函數所屬服務授予Function Compute訪問其他雲端服務的許可權，實現 STS Token 的擷取。
無論哪種部署方式，在應用代碼中通過阿里雲官方提供的 SDK，根據部署類型設定相應的身分識別驗證（Credentials）配置，都可以便捷的直接擷取 STS Token，無需關心具體的憑據緩衝以及到期更新邏輯。