AWS 身份及驗證服務（四）

IAM

概述

• 集中管理訪問AWS資源的訪問權限和用戶身份認證
• 支持聯合訪問管理，支持LADP第三方服務 （Identity Provider）
• 是非區域相關的服務，全局有效
• 建立用戶、組和角色以應用策略
• 安全憑證類型包括： 電子郵件和密碼、IAM用戶名和密碼、訪問密匙、多重驗證（MFA）、密匙對
• 密碼策略管理和KMS加密解密管理
• 建議始終使用建立和管理IAM帳戶來進行操做
• IAM遵循最低特權原則，即全部權限被隱式拒絕，而顯式拒絕擁有最高優先級
• IAM是權限與實體進行匹配的正式語句
  • 策略能夠應用於任何實體，包括用戶、組和角色
  • 策略能夠一對多也能夠多對一

委託人

• 委託人是容許與AWS資源交互的IAM實體，能夠是人或應用程序，也能夠是臨時或永久的。

• 有三種委託人身份：根用戶、IAM用戶(組)和角色

  • 根用戶
    • 第一次建立AWS時的登陸主體，能夠徹底訪問全部帳戶中的AWS資源與服務
    • 強烈建議不要將根帳戶用於任何的平常任務或是管理員
    • 必須安全的鎖定根用戶的用戶憑證
    • 根用戶也是Billing Account
    • 等同於Owner ，建立AWS帳戶的實體和Email地址
  • IAM用戶
    • 能夠經過IAM服務建立持久性身份，能夠是我的或應用程序
    • IAM用戶能夠隨時由IAM管理權限的主體建立
    • 須要提供與AWS交互的方法, 支持AWS控制檯用戶名密碼、CLI或者SDK等方式管理IAM用戶
    • 能夠提供定製的URL用於IAM用戶訪問
    • 應該使用最小權限原則管理IAM用戶
    • 最佳實踐：建立對根帳戶擁有管理特權的獨立IAM帳戶
  • IAM用戶組
    • 用戶的集合
    • 策略應用於整組
    • 一個用戶能夠屬於多個組
    • 沒有默認組
    • 不能嵌套組

• 角色
  • 在特定時間段內向特定角色授予特定權限
  • 這些角色經過AWS或第三方系統進行身份驗證
  • 一般會將某個用戶或組的權限關聯到角色，以簡化管理防止配置錯誤
  • 當一個角色開始承擔任務時，AWS會提供AWS安全令牌（STS）的臨時安全令牌似的他可使用受權的AWS服務（STS 有效時間爲15分鐘-36小時）
  • IAM組沒法使用角色
  • 每一個帳戶只能建立最多1000個IAM角色
  • EC2應用程序角色
    • 傳統授予應用程序權限會很是麻煩，須要安全使用某種憑證，而且還須要考慮安全的存儲和訪問這些憑證，
      • 如一個應用程序須要訪問S3時，須要該程序使用IAM用戶的密鑰，而密鑰又云須要存儲在一個安全的位置被應用程序訪問，這樣會致使憑證輪換等存在不少問題，同時不利於敏捷開發。
      • 能夠利用IAM 角色功能，當該應用程序的EC2啓動時利用Config Profile分配該角色，程序利用API訪問S3時該角色會獲取一個臨時令牌，用AWS工具包將臨時令牌傳遞給API以容許訪問，這種方法不須要考慮任何密鑰管理和輪換。
    • 在實例運行過程當中能夠隨時替換或分離角色
    • 每一個EC2只能分配一個角色
    • 跨帳戶訪問(Cross Account )
      • 將訪問AWS資源授予其餘AWS帳戶中的IAM用戶
      • 一般用於與公司關聯的第三方供應商或客戶有限制的訪問公司資源
    • 臨時訪問管理 ( Federation)
      • 對聯合身份用戶提供臨時的訪問權限
      • 主要用於第三方服務，而組織又不但願爲它提供組織內長期憑證（如API管理）

認證

用戶名/密碼

• 人員登陸Console的設置，能夠設置密碼策略執行復雜性要求和過時
• 最大支持128個字符
• 建議設置密碼策略以確保使用強密碼且常常更改
• IAM帳戶登陸還必須提供帳戶ID或別名（URL包含）

訪問密鑰

• 密鑰ID AKI（20字符）和訪問密鑰 SAK（40字符）的組合
• 經過API時使用密鑰對REST調用，且SAK必須簽署全部的API請求
• 簽名有助於保護消息完整性，防止在傳輸過程當中被篡改，以及防止重播 attack
• 支持Signature v4， 使用SAK派生進行簽名
• 訪問密鑰須要放在安全的地方而不是嵌入代碼中
• 每一個IAM用戶最多同時擁有2個激活的密鑰
• 只在區域內有效

• 密鑰對

  • 支持RSA 2048 SSH密鑰
  • 首次訪問時實例使用顯式的私鑰授予訪問權限，公鑰放入實例中，是登陸EC2的首選方式
  • 密鑰對還可用於CloudFront 爲私人內容建立簽名URL實現私有分發
  • 若密鑰對丟失，不能被從新生成，可是能夠進行替換
• 訪問密鑰+會話令牌 （STS）
  • 在服務被假定角色使用時，使用的臨時令牌用於驗證訪問密鑰，包括臨時訪問密鑰對自己和一個會話令牌。
    • 訪問ID
    • 訪問密鑰
    • 安全令牌
    • 超時時間
• 不用爲訪問建立專門的IAM帳號
• 臨時認證無需進行密鑰rotation
• 配置超時 15min -36hr ，默認12小時

X.509

• 可用於簽署基於SOAP的請求
• AWS帳戶能夠建立X.509, IAM必須使用第三方軟件才能建立X.509
• 可做爲SSL/TLS服務器證書， 提交密鑰到CA進行證書籤名請求CSR
• 利用X.509爲EC2建立定製的Linux AMI

多因素認證

• MFA是在密碼/密鑰以外爲基礎架構添加的額外安全層，一般須要從外部設備輸入一次性密碼OTP
• 支持硬件和軟件的MFA認證
• 支持爲API實施MFA認證
• MFA能夠分配個任何IAM用戶，尤爲建議爲根用戶啓用MFA
• 每一個用戶只能與一個MFA綁定

聯合認證 （Identity Federation）

• IAM身份供應商IdP能夠將IAM和外部身份聯合起來由外部進行認證， 並將權限分配給IAM外進行認證的用戶。
• IAM會返回與角色關聯的臨時令牌進行工做，以便驗證用與調用AWS API的身份
  • 公共IdP
    • 採用 OIDC （OpenID Connect）集成
    • 主要是受權給主要的網絡IdP認證用戶，如Google，Facebook，Amazon等，稱爲Web Federation
  • 企業內部身份驗證
    • 如企業自有的AD或LADP身份驗證服務，支持SAML 2.0
• 注意： 默認建立IAM用戶是不包含任何密碼和密鑰對，管理員須要手工指定

受權

• 指定委託人能夠執行和不能執行操做的權限 ，經過策略定義。
• 策略是一個JSON文件，充分定義了一組權限的訪問和操做AWS資源
  • Version： 可選項，以日期爲格式
  • Effect - 容許或拒絕
  • Resource - 適用於特定權限的AWS基礎架構的資源、數據主體，利用ARN來惟一指定資源
    • Amazon 資源名稱 = Amazon Resource Name （ARN）
    • 一個AWS資源的惟一標識，當在全局環境中調用時指向惟一的一項資源
      • arn:<partition>:<service>:<region>:<account-id>:<resourcetype>:<resource>
      • 例如 arn:aws:rds:eu-west-1:1234567:db:mysql-db
  • Service - 適用的服務名稱
  • Action - 指定服務的操做子集
  • Condition - 可選項定義一個或者多個限制權限容許操做的附加條件。

• 將策略和委託人聯繫
  • 用戶策略
    • 顯式聲明的策略
    • 策略僅僅存在於所聯繫的用戶中
  • 託管策略
    • 預置的策略
    • 獨立於用戶而存在的，策略能夠與許多用戶或用戶組關聯。
    • 建議使用預約義的託管策略保證在添加新功能時用戶依舊保持正確的訪問權限。
  • 最佳實踐： 組策略
    • 經過將託管策略關聯到一個用戶組能夠大大簡化對多用戶的策略管理。一樣也爲用戶組策略和用戶組託管管理策略。
• 用戶權限
  • 無權限 - 新用戶建立時的默認權限
  • 受權用戶權限 - 根據需求對用戶進行受權
  • 特權（Power）權限 - 能夠訪問全部AWS 服務，可是沒法管理用戶和組
  • 管理員權限 - 根用戶權限

其餘主要特色

密鑰輪換

• 任何憑證的安全風險都會隨着憑證使用時長而增長，因此按期對密鑰進行更換很是必要。
  • 建立新的訪問密鑰
  • 從新配置全部應用程序使用新密鑰
  • 禁用老密鑰
  • 驗證新密鑰的全部應用程序操做
  • 刪除老密鑰

多權限問題

• 爲了解決委託人在執行某個操做時，可能適用於已經配置的多個權限。
  • 請求默認被拒絕
  • 當全部政策中有明確的拒絕，則拒絕
  • 當全部政策中有明確的容許而沒有明確的拒絕，則容許
  • 若沒有明確拒絕或容許，則保留默認拒絕
  • 策略沒法覆蓋角色所默認拒絕的任何權限

AWS Directory Service

AD概念

• AD包含組織信息、用戶、組、計算機和其它資源

MS AD Service

• 將MS AD做爲託管服務運行
• 在Win2012R2上運行
• AD是跨2個可用區部署的高可用域控制器
• 支持數據複製和自動每日快照
• 無需安裝軟件，AWS處理全部的bug和update
• 不能將現有AD遷移進來，只能新建
• 適用於超過5000人的場景

AD Connector

• 可使用AD Connector 鏈接現有本地AD
• 經過VPC VirtualPN或者Direct Connect 鏈接企業數據中心
• 使用現有憑證訪問AWS 應用程序
• 基於RADIUS 現有 MFA解決方案集成
• 適用於混合雲場景

Simple AD 服務

• 使用Samba 4服務器提供AD服務
• 支持經常使用AD功能，如用戶帳號和組身份
• 支持Linux 和 Windows EC2加入域
• 基於Kerberos的單一登陸（SSO）和組策略
• 也提供了每日快照和基於時間點恢復
• 提供日誌和審計功能
• 不支持與MS AD創建信任關係，不支持MFA、DNS動態更新、LDAP等高級功能
• 適用於不超過5000人的簡單場景

AWS Security Token Service

概念

• 輕量級Web服務，獲取臨時、有限權限的憑證
• 身份代理認證
  • 利用身份代理服務建立臨時憑證，用戶得到一個臨時URL訪問AWS管理控制檯（單點登陸） ，支持
    • 跨AWS帳戶的IAM用戶組
    • 當前帳戶中的IAM用戶
    • 第三方請求
• 身份代理主要用於：
  • 查詢STS
  • 肯定Web請求的用戶
  • 使用AWS憑證向AWS進行身份驗證
  • 經過AWS STS API頒發臨時憑證
• STS 返回
  • STS返回臨時安全憑證給應用程序，其中包括了：
    • AccessKeyId
    • SecretAccessKey
    • SessionToken和時限（1到36小時）

常見場景

• 基於SAML的SSO聯合認證
  • STS支持SAML 2.0的開放標準更快更容易實現聯合，利用現有身份管理軟件管理AWS的訪問，無需編碼
  • 身份供應商idP經過SAML2.0 使用HTTP-POST綁定啓動Web SSO，經過新的URL簡化SSO
  • 須要IAM建立SAML idP做爲IAM信任策略的委託人
  • 步驟
    • 用戶在應用程序內輸入帳號密碼，應用程序將其發送給Identity Provider (Identity Broker)
    • Identity Provider (IdP)將用戶名和密碼發送到企業的LDAP目錄進行驗證
    • 驗證成功後IdP發送一個SAML認證響應給應用程序
    • 應用程序使用AssumeRoleWithSAMLRequest API發送SMAL請求給STS
    • 應用程序使用臨時憑證訪問S3存儲桶

• 基於Web的聯合身份認證
  • 使用STS API AssumeRoleWIthWebIdentity
  • 支持Amazon、Google、Facebook的身份認證

• 跨帳戶訪問
  • 跨帳號訪問權限（Cross Account Access），能夠在AWS管理控制檯上輕鬆地進行帳號（角色）的切換，讓用戶在不一樣的開發帳號（角色）、測試帳號（角色）、生產帳號（角色）中進行快捷的切換。
  • 示例 ： 讓開發帳號擁有必定的訪問權限，讓其訪問生產帳號中的S3資源。
    • 生產帳號中的管理員須要在IAM中建立一個新的角色UpdateAPP，在角色中定義了策略（Policy），策略具體定義了容許特定的AWS帳號ID訪問名爲productionapp的S3存儲桶
    • 在開發帳戶中，管理員向開發人員組的成員受權切換角色的權限。向開發人員組授予針對UpdateApp角色調用AWS Security Token Service (AWS STS) AssumeRole API 的權限。
    • 用戶請求切換角色
    • 能夠在AWS控制檯使用Switch Role的按鈕切換到生產帳號
    • 或者使用AWS API/CLI，使用AssumeRole函數獲取UpdateAPP角色的憑證
    • AWS STS返回臨時憑證
    • 臨時憑證容許訪問AWS資源，這樣切換後的角色就能夠訪問productionapp的存儲桶裏的內容了。

AWS KMS （Key Management Service）

概述

• 託管型加密服務
• 採用雙層密鑰結構，經過主密鑰對不一樣的數據密鑰進行加密，數據密鑰對應用程序進行加密
• 數據密鑰是惟一的， 主密鑰不能脫離KMS系統
• 僅支持對稱加密。

CMK

• KMS使用客戶主密鑰（CMK）來加密和解密數據。CMK能夠是客戶託管的密鑰也可使AWS託管的密鑰
• CMK不能以未加密的狀態脫離AWS KMS，可是數據密鑰能夠。
• 默認狀況下，啓用KMS集成後，每一個帳戶都會生成一個AWS託管的默認密鑰，若是沒有特別指定CMK，這個默認密鑰就會做爲CMK對資源進行加密。
• CMK密鑰長度爲256位，數據密鑰爲128位或256位
• CMK的建立須要有相應的權限，並定義IAM中哪些用戶和角色能夠管理和使用密鑰，也能夠容許其餘AWS帳戶使用該密鑰。
• CMK支持對最大4KB數據的加密和解密
• AWS能夠選擇自動進行每一年的CMK輪換
• CMK刪除能夠設置7-30天的等待期，以確保沒有任何影響
• 每一個區域的每一個帳戶最多能夠建立1000個CMK

• 信封加密

  • CMK加密數據密鑰加密後，會返回明文和加密版本
  • 明文版本用於對數據加密，完成後應當即從內存中刪除
  • 加密版本可與加密數據一塊兒存放
  • 加密上下文
    • 全部加密操做都支持附加上下文信息的可選Key/value對
    • 加密和解密操做必須先肯定上下文相同，不然沒法解密
    • 上下文可用細粒度受權和額外審計

安全實踐

• 爲密鑰建立惟一的別名和描述
• 定義哪些IAM用戶和角色能夠管理密鑰
• 選擇讓KMS每一年輪換密鑰
• 臨時禁用和啓用密鑰
• 檢查和審覈CloudTrail日誌中密鑰的使用狀況
• KMS只能在生成的區域使用，沒法傳輸到另外一區域

KMS+HSA

• AWS KMS提供簡單的Web接口RESTful API，用戶訪問彈性、多租戶的強化安全設備（HSA）
• 使用CMK構建基於HSA的加密上下文，僅可在HSA上訪問，用於常駐HSA的加密操做
• KMS是一項分級服務，由面向Web的KMS主機和一個HSA梯隊組成
• 客戶對KMS全部請求經過SSL發出，在KMS主機上停止
• KMS主機使用協議和程序經過HSA完成相關的加密解密操做。

KMS加密EBS卷

AWS CloudHSM

• 在AWS雲中部署專用的硬件安全模塊，使用SafeNet Inc 的 Luna SA7000 HSM設備
• 提供防篡改的硬件模塊內的安全密鑰加密和存儲，且不會將其暴露在設備的加密邊界外

• CloudHSM主要針對專用的VPC中，爲單租戶提供HSM服務，支持對稱和非對稱加密

  • 使用 AWS CloudHSM 服務時，您須要建立 CloudHSM 集羣。
  • 集羣能夠包含多個 HSM 實例，這些實例分佈在一個區域的多個可用區中。
  • 集羣中的 HSM 實例會自動同步並進行負載均衡。
  • 您可得到對集羣中每一個 HSM 實例的專用單租戶訪問權限。
  • 每一個 HSM 實例在 Amazon Virtual Private Cloud (VPC) 中都顯示爲網絡資源。向集羣中添加 HSM 或將其從中刪除只需調用 AWS CloudHSM API（或在命令行上使用 AWS CLI）便可完成。
  • 建立和初始化 CloudHSM 集羣后，您能夠在 EC2 實例上配置一個客戶端，以容許您的應用程序經過通過身份驗證的安全網絡鏈接使用該集羣。
  • Amazon 管理員可監控 HSM 的運行情況，但無權配置、管理和使用它們。
  • 您的應用程序將標準的加密 API 與應用程序實例上安裝的 HSM 客戶端軟件配合使用，以向 HSM 發送加密請求。客戶端軟件可維護通向集羣中全部 HSM 的安全通道，並在此通道上發送請求，而 HSM 執行相關操做並經過該安全通道返回結果。而後，客戶端經過加密 API 將結果返回到應用程序。
• 建議配置高可用的HSM服務

Amazon Cognito 服務

• Cognito爲移動和基於Web應用的程序提供身份和同步服務
• 與公共的IdP合做，如Google、Facebook和Amazon
  • 利用SDK訪問IdP，並利用它進行身份識別和受權
  • IdP認證成功後會回傳一個OAuth或OpenID Connect給Cognito，Cognito會給用戶返回一個新的Cognito ID以及一組臨時AWS憑證
  • Cognito 做爲代理，須要建立一個身份池，用於AWS帳戶中特定的用戶信息存儲，即角色和權限
  • Cognito會有限的建立新角色對AWS資源進行訪問，而最終用戶實際只能訪問到Cognito Sync服務和Mobile Analytics服務
• Cognito利用客戶端SDK管理本地的SQLite存儲做爲讀寫緩存，並異步同步到雲端，
  • 用戶即便處於脫機狀態依舊能夠繼續進行數據交互，但數據可能過期
  • 但多帳戶同步時必須獲得Cognito的驗證
  • Cognito身份只會同步和存儲角色受權的本身的數據，且數據傳輸使用HTTPS加密