Dev Talks

[AWS] 初探 AWS IAM(Identity and Access Management)

CY Chen, 網站工程師 Oct 20, 2022

照片來源:AWS Official website

什麼是 IAM 呢?

  • 簡單來說就是權限管理,在我們團隊使用 AWS 時,需要根據使用者等級給予不同的權限,而 IAM 就是來限制使用者在 AWS 中的使用哪些範圍。
  • IAM 服務是不需要收費的。
  • 在 AWS 建議下,使用 IAM 創建帳戶登入,會比使用帳號密碼的 root 帳戶來的安全許多。

IAM 能為我們提供的服務是?

帳號管理

透過 IAM,我們可以清楚知道,目前有多少類型的使用者,而分別的權限為何,一旦問題發生時,可以快速了解,是哪個層級的問題。也因為權限分享,令工作夥伴在安全且方便之下,有更高的工作效率。

良好的服務整合

在 AWS 眾多服務,IAM 都可以有良好的整合,讓在使用服務下,更順暢安全。


IAM 核心架構

照片來源:msp360

IAM 主要圍繞在四個核心概念,分別為:

  • Users: AWS 的登入帳號都是。
  • Group: 許多 User 的集合,在底下的 User 都會繼承 Group 的權限。
  • Roles: 權限綁定,這個主要是被設計出來給不是 User 和 Group 使用的。
  • Policies: policy 是用來規範某個使用者的 AWS 使用資源權限。

IAM Policy

照片來源:AWS Official website

每個 policy 底下,會有多個 statements。

statement 是讓我們去定義如何使用特定的 AWS 服務,所以認識 statement,對我們來說是相當重要的。

這邊來介紹一下 statement 底下幾個重要元素:

  • Effect: 是指這個 policy 要 Allow or Deny (註:Allow => 允許權限, Deny => 阻擋權限。)

  • Action: 是指到這個服務要執行怎麼樣的操作。
  • Resouces: 主要是去針對某個 AWS 資源,因此會指向某個 AWS 服務(例如:某個 S3 Bucket)。

而設定好的這些 policy 是要給誰用呢?讓我們繼續往下看。


IAM User & Group

照片來源:AWS Official website

在上一步我們介紹完 policy,接下來就是要套用在 User 和 Group 上面。

User

首先介紹 User,在 AWS 的登入帳號就是 User,而我們可以使用 IAM 來創建許多的 User,這邊可能會好奇 User 和 Policy 之間的關聯為何?

對於 Policy 來說,可以被很多 User 套用,而對 User 來說,則是可以擁有很多 Policy。

Group

Group 就如字面上的意思,在每個 Group 底下可以有許多的 User,而 User 也可以參與很多 Group,至於和 Policy 的關聯,就和 User 一樣。


IAM Role

照片來源:AWS Official website

定義:是一項機制,為了讓 User,Group 或其他 AWS Resource 取得權限。

Role 和 Policy 的關聯,與 User 相同。

那為什麼 AWS 要多設計一個 Role 出來呢? 是因為我們需要對不是 User 和 Group 以外的東西進行權限管理,最直接例子就是 EC2。

舉個例子,如果我們要使一個 EC2 上傳檔案到某個 S3 的 Bucket ,這時候我們就可以使用 IAM Role 來管理該 EC2 對特定 AWS serivce 權限,但這裡要特別注意,一台 EC2 只能有一個 Role,所以要謹慎安排。

說實在,筆者第一次看到 Role 的時候,頓時間還搞不清楚怎麼使用,後來看了官方文件,又和同事討論後,才明白原來給不是 User 和 Group 用的。


IAM Security Token Service (STS)

照片來源:AWS Official website

筆者在使用 SSM (AWS Systems Manager Agent)來存取 EC2 的時候,剛好接觸到 STS ,這邊剛好來介紹一下。

基礎概念

當我們要來存取 AWS 資源的時候,需要臨時取得該權限,而權限是以 token 形式來判別,這個服務就是 STS。因此我們所獲得的 credential 有時間限制的,可以來根據設定來調整時間,一旦過期,就會失效。

而這個 credentail 只能透過 STS 來轉換獲得,內容則是 access key ID 、 secret access key 、 session token。再搭配 Role 就可使用 SSM 來存取 EC2,讓過程更加安全。

Assume Role

STS 的 Assume Role,可以實現角色轉換的功能,比如我們原本的帳號是無法對 S3 來進行存取的權限,但是透過 Assume Role 我們可以轉換某個角色的權限,來操作 S3,可以想像戴上工地帽就可以進去工地一樣,那個工地帽就是讓我們短暫獲得進出工地的權利。


IAM API Access Key

這邊特別提到一下 API Access Key,如果我們在 AWS console 登入的話,是不用透過 API Access Key,但如果和筆者一樣經常使用 AWS CLI,那 API Access Key 就是那個 Key man 了。

根據 API Access Key 有幾點需要注意:

  • 相對應的 Secret Access Key 只會在產生時顯示,僅此一次,所以要好好記錄下來,錯過就要重新再來了。
  • 可以產生多把 API Access Key,但就安全考量,建議汰舊換新。
  • API Access Key 只有 IAM User 有,藉由 API Access Key 來存取相對應的權限。
  • 避免將 API Access Key 和 Secret Access Key 暴露在不安全的環境下,例如直接放在 EC2 中,建議搭配 Assume Role 來進行各項服務。

結語

最後補充和複習:

  • 使用 IAM 創建帳號登入,更為安全,IAM 是不限於哪個 Region 的。
  • 創建 Group 可以將需要同一規範的 User 管理在一起。
  • 給除了 User 和 Group 用的權限規範,請使用 Role。
  • 使用 STS Assume Role 來轉換角色權限。
  • Secret Access Key 只有在 Access Key ID 產生時顯示。

以上是對 AWS IAM 初步介紹,此篇文章有任何問題歡迎來信與我討論。

最後,希望透過這篇文章,能讓大家對 AWS IAM 不再陌生。

謝謝你的閱讀!


參閱資料

AWS Identity and Access Management Documentation


想要閱讀更多來自五倍紅寶石軟體開發的技術分享?歡迎訂閱我們的月報,每月將自動幫你送上最新文章。


分享