前言
「身份與存取權限管理」，英文作 Identity and Access Management (簡稱 IAM)，在資安領域是非常重要的一環，如同企業的資安守門人，除了識別來者身份外，有權決定其是否能對特定的服務進行存取。
隨著企業規模不斷地成長，IT 架構也快速增長，從作業系統、網路服務應用程式、電子郵件系統到資料庫，不僅是企業內部的 IT 環境，還有企業夥伴、供應商等外部使用者愈來愈多，如何精確掌控內/外使用者及跨多個系統的存取權與身份管理，成為企業面臨的重大課題。
此外，企業的重要資料遭到駭客竊取等事件頻傳，知名公司如 Colonial Pipeline 於 2021 年因員工帳號遭駭客竊取，即是身份和權限訪問管理的疏失所造成的威脅，導致公司約 440 萬美元的損失，而這類攻擊事件使得企業必須正視身分與資料存取權的管理問題，同時 IT 作業環境漸趨複雜，對身份與存取權限管理的需求越來愈大。
根據專業機構的統計報告，在過去幾年中，IAM 在 2021 年的市場價值已大幅增長到 134.1 億美元，預計到 2028 年將會增長到 345.2 億美元，從 2021 年到 2028 年，市場將以 14.5% 的年複合成長率發展。雲端服務的普及是推動 IAM 在市場上高速成長的其中一項主因，企業將更多資料遷移到雲端上，需要藉由良好且可供彈性整合的 IAM 設計，來保護機密資料並打造更安全和合規的環境。
根據調查報告， 身份與存取權限管理用於「雲端環境」的比例最高
AWS 提供了一套完整的 IAM 設計，作為其權限控管的機制，最大好處在於幾乎與 AWS 上其他的服務都有深度整合，讓使用者能夠根據實際案例來設計出最合適的解決方案。接著來看 AWS IAM 有哪些必須要懂的元件及概念吧～
AWS IAM
AWS IAM 中幾項重要元件:
- User
- Group
- Role
- Policy
上圖中可以看到這些元件在我們對 AWS 服務進行存取時，扮演非常重要的角色，用於識別來者的身份與其所擁有的權限， 決定「誰」可以「做什麼事」，確保每項服務是在「合法」的狀況下被使用。
IAM User
用於識別使用者的身份，可以是實際的人或是應用程式，一開始申請使用的 AWS 帳號會帶有 Root 權限，等同擁有最大權限的管理者帳號。
實務上會避免直接使用 Root 帳號對 AWS 資源做存取，而是在 Root 帳號下建另一個 User，並賦予 User 管理者 (Admin) 權限，後續在這個新的 Admin User 下做其他事情，如：建立其他特定用途的 User，而一個 Root 帳號可建立的 User 數量上限是 5,000。
每個 User 都有其專屬的 Account ID，因為不同 User 可能會有相同的自訂名稱，故以 Account ID 來辨別。
User 對 AWS 資源做存取時要經過驗證，方法分以下幾種：
- Email + Password: 給 Root 帳號使用
- User Name + Password: 給一般使用者
- Access Key + Secret Key：通常會給應用程式使用，透過 AWS API, CLI, SDK 等方式對 AWS 資源存取
另外，新建立的 User 預設不會帶有任何權限，需另外將權限加到指定的 User 身上，好處是您可以單獨為每個 User 分配權限，有關權限分配會於 Policy 的部分做進一步討論。
IAM Group
Group 的概念是將同性質的帳號群組起來統一管理，將權限設定在 Group 上，同個 Group 底下的所有 User 都會套用該 Group 擁有的權限。
如此一來，後續只需根據帳號的性質，將其加入所屬的 Group 即可，在權限分派上會更有效率。
上方範例中，一個組織下有多個部門，我們依據不同部門建立群組，並根據部門所需的權限加入其所屬的 Group，如：Finance Group 為財務部門，該部門只會擁有查看帳單的權限。
後續只要將新的 User 加到所屬部門的 Group，該 User 就會套用 Group 設定好的權限範圍，不會發生 RD Group 下的 User，有權查看 AWS 帳單資訊的情況，因為只有 Finance Group 下的 User 才有權查閱，即便未來這位 User 換部門，也只需將其變換至新的 Group 下，User 所擁有的權限會隨著 Group 改變。
IAM Policy
IAM Policy 提供權限控管的功能，也就是「有權能做哪些事情」，將定義好到 Policy 附加 (attach) 到指定的 User, Group 或是 Role 身上就能完成權限綁定的工作。
Policy 以 JSON 的形式來定義規則，除了 AWS 預先提供定義好的 Policy (稱作 AWS Managed Policy) 外， 使用者也可根據自身需求定義符合自身需求的 Policy，裡面的 Statement 結構會涵蓋下方列出的幾種元素 (Element)，來看個實際範例：
上方範例是自訂的 Policy，指定 S3 上的 Bucket 名稱 – mySampleBucket 設定唯讀 (Read Only Access) 的權限，代表綁定這個 Policy 的元件 (User, Group 和 Role) 只能對 mySampleBucket 做讀取的行爲，無法執行新增、修改、刪除等其他操作。
- Version 告訴 AWS 使用哪個版本的語法規則， 2012-10-17 為當前最新版
- Statement 定義規則允許 (Allow) 或拒絕 (Deny) 對哪些 AWS 資源進行操作
- Sid 可以作為識別 Policy 的用途，屬於選填的項目
- Effect Effect 只會有允許 (Allow) 和拒絕 (Deny) 兩種值，AWS 預設採用 Deny 的方式
- Principal 指定允許或拒絕存取資源的主體
值得注意的點是 Policy 分兩種：- User Based Policy: 套用在使用者身上
- Resource Based Policy: 套用在 AWS 資源
- 注意：在 User Based Policy 中，是無法設定 Principal ，因為這類的 Policy 需藉由附加 (attach) 的方式產生效果，正確作法是將 Principal 套用在 Resource Based Policy 上。
- Action 用於定義對 AWS 資源採取的行動，撰寫規則：“Action”: “<resource>:<verb>”
規則說明：- <resource>: 指定的 AWS 資源
- <verb>: 對資源採取的行動
上面的範例中，星號 (*) 作為萬用字元， 允許在所有 AWS resource 上進行所有操作(verb)，我們也能在同一個 Action 中，定義多個不同的 resource + verb 組合。
由於 AWS 服務非常多，每項資源可採取的行動也不同，實際上不可能所有內容都記得，可以參考文件內容，官方對每項服務的定義方法都寫在上面供大家查閱。
- Resource 指 AWS 提供的資源，如：S3, EC2, RDS 等，這部分會搭配 ARN 來明確定義是哪一項資源
- Condition 除了前面提及的 Action & Resource 之外，IAM 提供 Condition 的選擇，可做複雜條件的設定
若不熟悉 JSON 的方式來定義 Policy 沒關係，AWS 也提供點選的方式來撰寫 Policy，如下圖：
Amazon Resource Names (ARNs)
ARN 的用途是 AWS 替每一項資源建立一個獨一無二的名稱，如同上述第 7. Resource 提到，我們透過 ARN 來精確地指定是哪一項 AWS 資源，定義方式也適用星號 (*) 的規則，表示目標為所有的 AWS 資源。
ARN 有既定的規則可遵循，都以小寫 arn 作開頭，將下方語法結構與上圖範例一起比較：
arn:aws:s3:::mySampleBucket/*
arn:partition:service:region:account-id:resource-id
- partition: 指的是 AWS 區域，基本上是 aws 居多，除非是位處中國 (aws-cn) 或是特指美國政府 (aws-us-gov) 才會不同
- service: 識別 AWS 服務，如：EC2, S3, IAM 等
- region: AWS 服務上有數十個不同的區域 (region)，每個區域有其專屬的 region ID，如： Asia Pacific (Tokyo) 的 region ID 為 ap-northeast-1，相關資訊同樣能從 AWS 官方文件找到。 值得注意的是，若屬於 global service (如：S3)，這個資訊在 ARN 中不需要，在兩個冒號 ( : ) 之間什麼都不加
- account-id: 即識別帳號用的 Account ID，並非所有服務都需要這項資訊，例如：S3，表示方法也是在兩個冒號 ( : ) 之間什麼都不加
- resource-id: 即 resource 本身，可藉由路徑的方式來更詳細地描述 resource 資訊，如上面提到的 mySampleBucket/* 表 mySampleBucket 這個 S3 bucket 下的所有資源
最後是撰寫 Policy 時一些提醒事項：
- 元素名稱 (Version, Statement, Sid … etc.) 有大小寫之分，寫錯的話 Policy 無法生效
- ARN 的撰寫規則適用星號 (*) 作為萬用字元，可用來指定該資源路徑底下的所有內容
IAM Role
Role 的主要目的在於提供「非登入帳號」(登入帳號如：User 或 Group) 來使用這項服務，最具體的例子是 AWS 服務，把 Role 附加在 AWS 服務上，連結到 IAM 服務中。
舉個實際例子，有個應用程式部署在 AWS EC2 裡，我們希望這個應用程式能夠讀取存放在 S3 Bucket 上的檔案內容，藉由把 Role 附加在 EC2 的方式，賦予 EC2 讀取 S3 檔案的權限。
範例圖片取自 AWS [文件]
上圖範例中，使用者會先建一個擁有 S3 Bucket 存取權的 Role – Get-pics，並將這個 Role 附加到運行應用程式的 EC2 上，應用程式於 EC2 裡透過呼叫 AWS Security Token Service (簡稱 STS) API 的方式，取得有時效性且基於 Get-pics 這個 Role 權限的安全憑證 (security credentials)，再透過憑證去讀取 S3 Bucket 的內容。
常見的個人及組織在存取權管理上的實務做法
保護你的 Root User 及 IAM User
前面提到第一次申請 AWS 時，登入的帳號帶有 Root 權限，由於這組帳號擁有最大權限，所以可以加上多重身份驗證（Multi-Factor Authentication，MFA），作為額外的登入安全機制，強化對 Root User 的保護。
最常見的作法是「綁定 MFA 裝置」，在手機或其他裝置上安裝應用程式軟體 (如 Google Authenticator) 並完成綁定 AWS 帳號。
綁定的裝置會根據時間產生一串隨機的六位數字驗證碼，使用者須在登入期間於登入頁面上輸入裝置上顯示的一次性隨機驗證碼，如下圖所示：
帳號啟用 MFA 後，登入時會要求使用者輸入與帳號綁定的個人裝置在同時間產生的隨機數字，如下圖所示：
採用 Assume Role 進行跨帳號存取資料
實務上很常遇到需要跨多個帳號，存取其他帳號擁有的特定資源，我們可以借助 Assume Role 的方法來分派跨 AWS 帳號訪問資源的權限。
以上圖中的範例來說，Account B 的 User 想要存取 Account A 底下的 S3 Bucket，需於 Account A 設定 Trust Policy 允許 Account B assume role 到 A Account，並設定 Permissions Policy 賦予 Role 存取 S3 Bucket 的權限，最後 Account B 會藉由 Assume Role 呼叫 AWS Security Token Service (STS) API 取得具時效性的憑證 (Credentials)，如此一來便可存取 Account A 的 S3 Bucket 內容。
Single Sign-On
AWS 提供了 Single Sign-On (簡稱 SSO) 的服務，對使用者進行授權存取 AWS 資源，AWS SSO 對於第三方軟體的整合度非常高，只要是採用 SAML 2.0 的標準服務供應商，或是 Active Directory (簡稱 AD) 等都能支援，與 AWS SSO 進行整合來提供帳號認證的服務。
一般來說，組織內部會透過 AD 進行帳號管理，與 AWS SSO 服務做整合，在 AWS SSO 集中管理 AWS 權限，並允許使用者透過 AD 登入，存取 AWS 帳號及應用程式，管理者就能更輕鬆地替現有使用者和群組授權。
總結
AWS IAM 提供了多樣的彈性設計，若能充分了解 IAM 各項元件的功能，使用者便可根據自身需求或是組織內部規範打造出合適的權限管理策略，同時也提供廣泛的支援方案，方便與外部服務進行整合。
良好的 IAM 設計不僅能有效降低安全風險，同時簡化內外部服務存取權的管理工作，提高個人及組織的工作效率，故 IAM 是每位用戶使用 AWS 服務之前必定要熟悉的重要項目。
參考文件
- Security best practices in IAM
- AWS IAM – Policy evaluation logic
- AWS Best practices to protect your account’s root user
- How to use trust policies with IAM roles
