IAM最佳實踐

企業使用公有云服務的第一件事情就是創建雲帳號，有了帳號之後如何讓企業員工安全合規的使用雲帳號下的各種資源是開啓雲之旅後的第一個考驗。

雲計算廠商針對企業上雲後面臨的第一個需求已經推出了完善的解決方案--Identity and Access Management。IAM可以幫助雲帳號安全地控制對雲計算服務資源的訪問。企業可以使用IAM控制對哪個用戶進行身份驗證 (登錄) 和授權 (具有權限) 以使用資源。

雲廠商是否提供完善的IAM服務可以作爲整體產品解決方案是否成熟的一個衡量指標，比如AWS的IAM和阿里雲的訪問控制都是較爲成熟完善的產品。國內某個以AI能力爲賣點的雲廠商，在IAM產品方面幾乎爲零，很難相信對安全合規有需求的企業會完整使用他的雲產品作爲解決方案。

IAM通常提供以下功能:

對雲賬戶的共享訪問權限

允許在一個雲賬戶下創建並管理多個用戶身份，並允許給單個身份或一組身份（既可以是當前雲帳號下也可以是其他雲帳號下）分配不同的權限策略，從而實現不同用戶擁有不同的雲資源訪問權限，而不必共享雲帳號根用戶的密碼或訪問密鑰。

精細權限

可以針對不同資源向不同人員授予不同權限。可以要求用戶必須使用安全信道（如 SSL）、在指定時間範圍、或在指定源 IP 條件下才能操作指定的雲資源。

多重驗證 (MFA)

可以向雲賬戶和各個用戶添加雙重身份驗證以實現更高安全性。藉助MFA，用戶不僅必須提供使用賬戶所需的密碼或訪問密鑰，還必須提供來自經過特殊配置的設備的代碼。

聯合身份

可以允許已在其他位置（例如，在企業網絡中或通過 Internet 身份提供商）獲得密碼的用戶獲取對雲賬戶的用戶訪問權限。

後面會有專門的文章來講如何實踐聯合身份。

統一賬單

雲賬戶接收包括所有用戶的資源操作所發生費用的統一賬單。

儘管IAM提供了上面種種功能，雲帳號的管理者仍可通過一些最佳實踐來更好的使用IAM產品來提升安全級別和減少運維成本。

IAM最佳實踐

• 儘量不要使用雲帳號的根用戶，不要爲根用戶創建AK。雲帳號管理員也使用各自獨立的子賬號。
• 爲企業中每一個需要使用雲服務的員工單獨創建子賬戶，且默認不允許創建AK。便於員工離職的時候，通過刪除帳號來完全清理用戶在雲計算平臺的各種權限。

• 密碼安全實踐，

  • 限制密碼強度不少於8位，必須由大小寫字母、數字和符號中的三種組成。
  • 強制密碼過期時間不超過90天，且過期後不可登錄。
  • 新密碼至少禁止使用前3次密碼。
  • 設置密碼重試約束，例如，一小時內使用錯誤密碼最大嘗試9次登錄。
• 強制所有用戶啓用兩步認證。
• 對訪問網絡有限制的企業，可以開啓登錄IP限制。
• [推薦做法]已有SSO單點登錄系統的企業，可以通過SAML 2.0標準實現從企業本地賬號系統登錄到阿里雲，從而滿足企業的統一用戶登錄認證要求。

• 細粒度的權限管理，

  • 爲各種雲資源創建最細粒度的權限策略。例如，分別爲RDS實例rds-instance-1創建只讀權限策略rds-instance-1-readonly-access，RDS實例rds-instance-2創建只讀權限策略rds-instance-2-readonly-access。
  • 根據職能、部門等維度爲雲帳號子用戶創建用戶組。例如，按項目創建用戶組，group-project-a，group-project-b。如果project-a用戶需要訪問rds-instance-1的信息，將自定義權限rds-instance-1-readonly-access授權給group-project-a。再將相關用戶加到用戶組group-project-a中，這樣這些用戶就具有隻讀訪問RDS實例rds-instance-1的權限。而不是將所有RDS的讀寫權限都授予這些用戶，最大限度的保證用戶不獲取超過實際需要的權限。
  • 在實際場景中，通常會通過雲計算服務的API來完成某些週期性任務，比如每日RDS中的慢查詢統計、雲帳號每日花費統計等。這些任務都需要一個雲帳號的AK來完成API的身份認證。最佳的做法是，爲每類相關的任務創建一個功能性子賬號，禁用他們的web登錄，且遵循特殊的命名規範(functional-開頭)，比如functional-rds-stats、functional-cost-stats。創建最小的權限策略，然後分配給這些功能性用戶。例如，functional-rds-stats僅被授予RDS只讀權限，functional-cost-stats僅被授予費用的只讀權限。爲這些子賬號創建AK，每類任務使用不同的AK來完成API認證，而不是都使用同一個AK。這樣的好處是，不同類型任務的AK具有不同的權限，最大限度的保護了雲帳號的安全，並且這些AK不跟實際的員工子賬號關聯，不會因爲員工帳號的變更而受影響。如有更高的安全合規的要求下，可以定期作廢已有AK，創建新AK替換。至於AK怎樣安全管理，之後會有專門的文章來詳解。