假使你是剛拿到 AWS 帳號的新人，用自己的 IAM 使用者登入，密碼打對、手機上的 MFA 驗證碼也過了

點開 IAM 看使用者清單，OK 有東西。再點 EC2 想看主機，畫面直接一排紅字 AccessDenied .. 冏

這時候很多人會想：是不是 MFA 要再做一次？還是改用指令就進得去？

因為可以登入，和最高管理者 root 有沒有給你各個服務的權限是兩碼子事情，來介紹下

• 第一關「你是誰」：密碼、MFA 代表最高管理者讓你可以登入。這主要是認證（Authentication）
• 第二關「你能做什麼」：每點一個東西，AWS 就會去翻 root 最高管理者提供給你權限政策有哪些，這動作是叫做授權（Authorization）

寫過後端的人比喻來說，就很像是你確實登入成功，但你只是一般會員權限，是沒有授權給你來造訪管理者後台的~

以下面畫面為例子：

not authorized to perform: ec2:DescribeInstances because no identity-based policy allows...

這個權限是 ec2:DescribeInstances（列出 EC2 主機），但如果這會員沒有這個權限政策允許，就會顯示你沒有授權使用這權限~

MFA 和 IAM，各是什麼？

前面一直講 MFA、IAM，先把這兩個名詞講清楚

MFA 全名多因素驗證，白話就是除了密碼再多一道證明。最常見的是手機 Auth App 上 30 秒換一次的六位數，登入時密碼打完再輸入它。這樣好處在密碼被偷了，沒有你的手機還是進不來

IAM 全名是身分與存取管理，就是 最高管理者能透過它來 管「誰能登入、登入後能做什麼」的服務，可以參考 IAM 官方說明。

使用者、群組、權限政策都是在 IAM 設定，MFA 也是在 IAM 裡面幫使用者開的

IAM 詳細節少

開始建東西之前，先知道三件事：

1. 帳號剛開好的時候只有一個身分，叫 root，什麼都能做，權限是最高的。官方也明講不要拿它做日常工作，把第一個 IAM 使用者建好之後 root 就可以包袱款款收起來，並且鎖好 MFA，然後平常都用 IAM 使用者登入
2. IAM 是整個帳號共用的，沒有分 Region
3. IAM 本身不收錢，本身設置許多權限是不收費用的

IAM 裡面主要就這三個東西：

那這三個東西怎麼接在一起？

使用者是人，人可以加入群組；政策可以想像成權限文件，文件就能掛在群組上，當然也能直接掛在某一個使用者身上

這樣好處在你登入 AWS 後，AWS 就去翻你拿得到的政策，看裡面有沒有一條允許這個動作

所以之後要查「這個人為什麼能／不能做某件事」，順序就是：他在哪些群組 → 那些群組掛了哪些政策 → 政策裡有沒有授權讓他做那個動作~

權限政策長什麼樣？

一份政策就是一份 JSON 文件，會寫程式的人看到就懂。這篇用的那份長這樣，兩條規則：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListIAMUsers",
      "Effect": "Allow",
      "Action": "iam:ListUsers",
      "Resource": "*"
    },
    {
      "Sid": "AllowPublicCloudShell",
      "Effect": "Allow",
      "Action": [
        "cloudshell:CreateEnvironment",
        "cloudshell:CreateSession",
        "cloudshell:GetEnvironmentStatus",
        "cloudshell:StartEnvironment",
        "cloudshell:PutCredentials"
      ],
      "Resource": "*"
    }
  ]
}

幾個看懂政策的小訣竅：

Action 的名字怎麼來的？ 冒號前面是服務、後面是動作，iam:ListUsers 就是「IAM 的列出使用者」，ec2:DescribeInstances 就是「EC2 的列出主機」。

沒寫到的動作呢？ 沒寫預設就是不給。像是這份政策從頭到尾沒有出現 ec2: 開頭的東西，所以點 EC2 被擋是照設定在擋

一定要自己寫 JSON 嗎？ AWS 準備了一堆現成的政策，像 ReadOnlyAccess（什麼都能看不能改）、AdministratorAccess（什麼都能做），在畫面上勾一下就能掛。AWS 自己的建議是可以先拿現成的起步，之後再收斂成剛好夠用的版本，像是現在有 AI 後，就好寫很多，以前真的寫到流鼻血 (欸

政策可以掛在哪？ 可以直接掛在使用者身上，也可以掛在群組上

為什麼政策要掛在群組上？

重點是：政策不是直接貼在每個人身上，是掛在群組上；人進了群組，就拿到那份權限

假使三個後端同事做一樣的事，直接貼在人身上你要貼三次；之後多一人少一人都要改就很麻煩

掛在群組上就只要動群組。而且每個人還是用自己的帳號登入，誰做了什麼查得出來，例如說建立後端部門權限，以後就針對後端部門來 + 人就方便許多

IAM 常建設計流程

常見順序順序是先建人、再寫政策、再建群組把兩個接起來

第一步：IAM → Users → Create user

填名字、勾「可以登入 Console」，密碼自己設。這一步先不要直接掛任何政策，權限等從群組來

第二步：IAM → Policies → Create policy

切到 JSON，把上面那份貼進去，Action 只放你要開的動作。取個名字，例如 BackendEngineerOnboardingAccess

第三步：IAM → User groups → Create group

取名 backend-engineers，同一個畫面往下勾要加入的使用者、勾剛建好的政策，建立

建完回到那個使用者的 Permissions 分頁看一眼，政策旁邊會寫 Attached via backend-engineers，意思是這份權限是從群組來的，不是直接掛在他身上。這樣就 ok 了~

一個允許、一個拒絕，這才叫驗證

設完不要只看畫面說有掛就好，要用那個使用者本人的身分去試

而且要試兩件事，一個應該過、一個應該被擋

先試該過的。開 CloudShell（Console 右下角那個終端機）打 aws iam list-users，看得到自己的名字就對了

再試該被擋的。點 EC2 → Instances，出現剛剛那排 AccessDenied，就能看到被拒絕了

這樣才代表政策真的在照你寫的運作~

小結

最後小結一下~

帳號管理很重要，所以記得切記不要做以下事情哩~

• 直接給整個管理權限「反正以後也會用到」：以後的事以後再說，該做的把關一定還是得做好
• 把 MFA 關掉：不要圖方便關掉 MFA 欸，關掉只會讓帳號更不安全

希望這篇帳號驗證跟服務權限管理有讓你學到東西，我們下篇見 :D