+86 135 410 16684 如果你在使用中有任何aws上云服务器维护问题,可以随时联系我们!AWSOK你最好的合作伙伴!Mon. - Fri. 10:00-22:00

AWS 上的安全建議

AWS 上的安全建議

AWS 上的安全建議

剛聽見某公司丟 AWS Access / Secret Keys ,被開 spot instance 噴了些錢。因此想分享 AWS 的一些(安全相關)心得。

  1. 閱讀並遵照官方建議 (Best Practices)

    這乍看這與安全無關,但 AWS 係根據實際案例經驗來撰寫建議;很可能其中某些項目,背後便隱藏著安全考量。逆天土砲前,先照建議做過一輪,明瞭各環節的選擇及取捨,再開始設計自己的系統,比較能避免錯誤。
    最近聽過一集 AWS Podcast 即以安全為主題,但我剛沒能找到;另外可參考 Security Best Practice whitepaper AWS Security Center 則是個不錯的閱讀起點。

  2. 權責劃分

    AWS 採用 Shared Responsibility Model,而用戶要對自己上傳的程式、發出的 API Request、以及有管理權限的 instance (例如透過 EB 開出來的機器)負責。因而善用 Managed Service 能節省維護環境的時間。

  3. 備份

    AWS 的服務之間整合完整,善用 S3 / Glacier 進行備份,或選用內建備份(例如 snapshot, RDS, 或調用 Data Pipeline 轉存),能省下不少相關功夫。

  4. 稽核

    除了官方服務 Trusted Advisor 以外,有不少第三方服務能做到自動化權限稽核;現在 marketplace 上也有試用 Security Software 送 $175 AWS Credits 的活動(5/15 止)。除事先檢查設置之外,透過稽核 Log 或用量,往往是更實際的手段;為此可使用 CloudWatch, CloudTrail (遲早全區上線) 與 Billing Alert。

  5. 網路連線管理

    VPC 與其下 subnet, NetACL, Security Group 能在 instance-based service 間,建立起類似 Vlan 與 firewall 的低階防護。

  6. 權限管理

    IAM 是 AWS 服務中的權限稽核中樞,應善用 user, group 與 role 功能,提供可能的最低權限給各用戶 / instance / worker。透過 S3 作為轉介,也可以實作出預設低權級(IAM role),需要時使用高權級(例:透過 S3 取得具寫入權限的 Access Keys)的 Pattern。
    另外記得常 Rotate Keys,系統必須能輕鬆做到這點。

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。