The Art of Readable Code && High Performance Comments

AWS IAM Role and STS logos

還債系列

Why Role

使用 IAM User / Group 管理「人」的權限相當方便,然而若要在專案(透過 API)運用,須將 Access / Secret Key Pair 以某些方式寫進伺服器;這是潛在資安風險,並且更新手續繁雜。而 IAM Role 便是設計來應付這類狀況。

IAM Role

IAM Role 與 IAM User 類似,能以相同的表述句賦予權限 (Policy, Statement);然而 IAM Role 不允許密碼登入,也沒有存取 Key Pair 的界面,因此能避免帳號密碼或 Key Pair 外洩的安全問題。

IAM Role 目前分為三大類,分別適用於 AWS 服務其他 Amazon (Root) 帳號第三方驗證 (IdP) 授權。其中 AWS 服務指的是帳號下的其他服務(Direct Connect 有特殊流程,其他似乎都在這了),常見如 EC2 、Elastic Transcoder 等。有種權限控制模式便是透過 EC2 Role 使 EC2 Instance(必須在 initiate EC2 時指派)自動獲得 AWS 權限。對資訊安全分級有嚴格的場景,也可以透過 role 給予 S3 bucket 的讀取權限,並將各種不同等級的 Key Pairs 存放其中。

第二類的「其他 Amazon 帳號」又分為自己的帳號與 3rd Party 所有。我手邊沒有其它 Root Account 可供測試,因此只能以 manual 為準:若授權方選為自己的帳號,則對方可在 IAM Policy 中授權給所持有的 User / Group / Role,一如操作自己的資源 (Delegating Cross-Account Permissions to IAM Users);若選為後者,則對方只能透過 STS Assume Role 取得 token (Delegating API Access to Third Parties)。

針對其他 Root Account 的授權,目前 AWS 支援 SAML 以及 WIF 兩類 IdP:前者如 AD Server,後者則包含 Amazon, Google 與 Facebook 三間 OAuth service provider (特別推薦 OAuth 補充材料: 鴨七 OAuth 2.0 筆記)。

Security Token Service (STS)

STS 從屬於 IAM ,用於產生暫時 token,可配合第三方驗證 (IAM Role IdP, WIF) 與 Amazon / IAM User 運作。常用情景如:暫時授權、低安全性環境(給予短期有效之 Token)、透過第三方授權等。在大多情況下,STS 會與 IAM Role 並用,這也是將這兩者寫做同一篇的主因。由於 STS 提供的 API 不多,透過分類介紹這些 API ,將有助於理解 STS 的全貌。

  • GetSessionToken,功能最單純的 API,用於產生對應調用者(IAM or Amazon User) 的暫用 Token。由於調用者無法對產生出的 Session Token 權限加以限制,這隻 API 的功能相當侷限,官方文件建議用於生成暫用 Token,以滿足某些要求使用 MFA 的 Statement。
  • GetFederationToken,由持有長效 Token 者,可以帶入 Federation Name 以及(給生成的 Token 的) User Policy;而暫用 Token 的實際權限,會是長效 Token 與 User Policy 的交集。輸入的 federation name 會對應 STS 中的 federated-user/* ,因此能以 Policy 中的 Principal 加以限制。到又因為調用這隻 API 需先有權限較大的長效 Token,若用於 Front End (JS SDK in the Browser) 或 Mobile APP 必然洩漏,會造成安全風險;這種情況下應改用 AssumeRoleWithWebIdentity。
  • AssumeRoleWithWebIdentity 負責讓透過 WIF SSO 登入的用戶,能夠取得對應特定 Role 的暫用 Token。管理者需先建立對應的 IAM Role,輸入授權方 (Facebook, Google 或 Amazon) 與 APP ID;用戶在向授權端完成驗證後,透過這隻 API 送出 role name、ProviderId (授權端)、WebIdentityToken (Access Token) 等資料,以取得對應該 Role 的暫用 Token。雖然這隻 API 接受輸入額外的 Policy 以限制 Token 權限,但因為由客戶端呼叫,因此可能在惡意入侵時被繞過;將所有 Policy 寫入 Role 中是唯一王道。
  • AssumeRole 是其中唯一接受 ExternalId 者,其他參數大致相仿。ExternalId 係用於對其他 Amazon 帳號的驗證,是第三方服務提供者的 shared secret。這隻 API 與 Get* 相似,要由已登入者調用(限 IAM User / Role,Amazon User 呼叫會授權失敗)。
  • AssumeRoleWithSAML: 跳過,手邊沒有可以玩/測的機器 XD 總之與 SAML 有關。

由此可知,若要由第三方對用戶認證,可以使用 WIF 搭配 AssumeRoleWithWebIdentity,由 AWS 查驗 OAuth 授權端與用戶端資訊,或在用戶登入的 return url 頁面透過 GetFederationToken 生成暫用 Token,並由開發者自行管理驗證資訊。

如果是系統日常操作,需要臨時授予較高權限,應使用 AssumeRole;若只是要帶入 MFA 驗證碼,則應採用 GetSessionToken。

在理解如何透過第三方驗證用戶身份,並取得 AWS 操作權限後,下一篇將簡介 DynamoDB,AWS 官配 NoSQL。

發表迴響

分類

%d 位部落客按了讚: