Identity Center 的延伸議題與資訊補充

昨天設定 Identity Center，設定的過程中心裡不時就會冒出疑問，於是出現了這篇原本沒有預計要寫的補充。

關於 Permission Set

• 設定畫面是這個樣子：
  

雖然當下只有一個 Account 可以選 (因為我也就開了一個 AWS Account)，但它的畫面看起來是可以多選的。

那假設一個組織有多個 Account，一個 User 就可以指派到多組 Account 囉?

沒錯，還真的是。

Identity Center 的 User 可以被指派多個帳戶，也可以在同一個帳戶中被指派多組 Permission Set。
這樣靈活的特性讓這個管理中心可以彈性的應對絕大部分實務情境。

例如：同一個員工，在不同專案中可能有不同的職務

再換個企業情境：公司中的每個單位都有自己的 Account，避免互相干擾。
當有些員工需要兼任...

如果再加上群組管理，就能規劃出更多符合企業使用的權限架構，也難怪在正式的環境下，更適合用 Identity Center 取代單純的 IAM User。

⚠️ 設定限制
當要把 Permission Set 分配到不同 Account 的時候，一次的設定上限是 10 組。
如果要將 Permission Set 分配到更多不同的 Account ，需要多次操作才能達成，或者透過 CLI 或 API 自動化分配。

AWS Identity Center User ╳ AWS Accounts ╳ Permission Sets
既然 User 可以指派多個 Account，那 Permission Set 是不是也可以在不同 Account 之間共用?

是的，沒錯！
在 Organization 中的 Account 和 Permission Set 是各自獨立的，Permission Set 可以被指派到多個 Account 下。

也。就。是。說！

Permission Set 其實並不適合用太細節的設定上，比如：

{
  "Sid": "ListBucket",
  "Effect": "Allow",
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::ithome-ironman-2025"
}

對，就是上一篇的設定。自己犯的錯自己訂正。

因為這些 Resource ARN 很有可能只存在於某一個專案之中。
所以在 Permission Set 做資源級、專案級的細節權限設計，其實就已經違背了它「跨帳戶重用」的精神。

Permission Set 應該被設計成適合跨 Account 使用的情境。

官方推薦的最佳實務

• Permission Set 更適合設計成職能或職位導向（Admin、Dev、Auditor、Billing 等）
• 不要把顆粒度在專案資源的權限硬塞進 Permission Set，這會讓管理成本直接爆炸。

那如果需要針對特定資源做限制怎麼辦?

如果顆粒度在資源，優先考慮 資源型策略 (Resource-based Policy)
以 Identity Center Role：developer 只能存取 S3 的特定 Bucket 為例

Permission Set: DeveloperAccess

{
  "Effect": "Allow",
  "Action": [
    "s3:ListAllMyBuckets",
    "s3:GetObject"
  ],
  "Resource": "*"
}

Account 中的 S3 Bucket Policy：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowDevAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::590184072539:role/aws-reserved/sso.amazonaws.com/ap-southeast-2/AWSReservedSSO_s3-ironman2025_6412f133167f3e39"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::ithome-ironman-2025/*"
    }
  ]
}

補充說明：Principal
這裡填寫的是 Permission Set 在 Account 中建立的 Role ARN，且 ARN 格式會以 AWSReservedSSO_ 開頭。

S3、SNS、SQS、KMS... 等服務都支援 Resource policy，在設計權限時，是否支援也需要考慮進去喔！

已經完成登入後再修改 Permission Set，會立即生效嗎?

官方文件的說明不是太明確：

As you modify the permission set, IAM Identity Center ensures that the corresponding IAM policies and roles are updated accordingly.

當修改 Permission Set 時，IAM Identity Center 會確保對應的 IAM policies 和 roles 一併更新。
但是敘述中並沒有提及具體的生效的時間點和對驗證的影響。

不如就來測試看看！

• 這是設定好權限，可以讀取 S3 Bucket 中檔案的 Permission Set
  
• 利用無痕分頁登入「系統管理者」，並修改 Permission Set (移除讀取 Bucket Object 的權限)
  
• 等待更新完成
  
• 再次嘗試開啟文件，會發現已經失效了。
  

developer 在這段期間並沒有登出或重新登入。

AWS 中的授權驗證方式很多，這次用 Console 的方式測試是即時生效，不過是否適用於所有服務和授權方式，還需要進一步驗證。
不過網路上倒是有找到相關的討論，表示遇到 Permission Set 修改後沒有立刻生效的情況：
Sep 2023 | IAM Identity Center/AWS SSO Propagation Delay
可惜文章中並沒有說明情境。

既然如此，應該可以推斷出 AWS 的設計目標就是盡可能即時，不會因為已經完成登入和驗證步驟，就會在 Permission Set 已經變更的情況下繼續持有舊有權限。

官方文件參考請至：
What is IAM Identity Center?
Manage AWS accounts with permission sets