剛聽見某公司丟 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。