應因公司資安政策，希望資料庫類型的 DynamoDB 是由 DBA 協助控管，而每個 Linked-Account Owner 能存取除了 DynamoDB 以外的服務，包含 IAM。
基本上會有幾個情境必須考量：
- Linked-Account Owner 擁有 IAMFullAccess 應因在產品開發需求時，建立給 Application 的 IAM Role 權限
- Linked-Account Owner 不允許存取 DynamoDB 服務，但可以向 DBA 申請指定 IAM ARN 白名單
- 除了申請通過的 IAM ARN 以外，僅有 DBA 擁有 DynamoDB 權限
為了產品可以快速開發，每個 Linked-Account Owner 擁有 IAMFullAccess 這條權限基本上就無敵了，可以自己到 IAM Policy 增加權限
如果在 Linked-Account 這一層無解，就要到更高層級 Master-Account 的 Organization SCPs 處理，Organization SCPs 是比 Linked-Account Root 更高層級的 Policy level，如果以權限分層來看：
Organization SCPs > Linked-Root – Linked-IAM
所以 Organization SCPs 依照此情境就必須做到以下：
- 允許 Linked-IAM/Root 擁有 FullAccess，除了 DynamoDB。
- 允許指定 IAM 可以存取 DynamoDB (Application 使用)
Organization SCPs 設定
在建立 Organization SCPs 之前，建議先建立 OU (Organizational units) 把帳號分類會比較好管理，以 DatabaseControlList 為例，把需要管理的 Account-Id 移進去這個 OU
而 Organization SCPs 可以參考以下 Policy 設計：
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAllService",
"Effect": "Allow",
"Action": "*",
"Resource": [
"*"
]
},
{
"Sid": "DefaultDenyDatabasesAction",
"Effect": "Deny",
"Action": [
"dynamodb:ListBackups",
"dynamodb:Create*",
"dynamodb:DeleteBackup",
"dynamodb:DeleteTable",
"dynamodb:DeleteTableReplica",
"dynamodb:RestoreTable*",
"dynamodb:UpdateContinuousBackups",
"dynamodb:UpdateContributorInsights",
"dynamodb:UpdateGlobalTable",
"dynamodb:UpdateGlobalTableSettings",
"dynamodb:UpdateTable",
"dynamodb:UpdateTableReplicaAutoScaling"
],
"Resource": [
"*"
]
"Condition": {
"ArnNotLike": {
"aws:PrincipalARN": [
"arn:aws:iam::*:role/DbaRole"
]
}
}
},
{
"Sid": "DenyDatabasesAction",
"Effect": "Deny",
"Action": [
"dynamodb:GetItem",
"dynamodb:GetRecords"
],
"Resource": [
"*"
],
"Condition": {
"ArnNotLike": {
"aws:PrincipalARN": [
"arn:aws:iam::123123123123:role/WebRole",
"arn:aws:iam::123123123123:user/shazi7804"
]
}
}
}
]
}- AllowAllService：先聲明所有權限都 Allow
- DefaultDenyDatabasesAction：預設一定不能存取的 Action，即天條，但是 DBA 要可以維護，所以例外開放 DbaRole。
- DenyDatabasesAction：允許白名單開放的 Action，依 Condition.ArnNotLike.aws:PrincipalARN 的清單為主
AWS Policy 原則：只要有 Deny 就 Deny
透過這條 Policy 就等於下了天條，不在 aws:PrincipalARN 的 IAM 都不能存取 DynamoDB。
限制
透過白名單限制的方法可以透過自動化機制的申請流程開放，但必須考量 “白名單” 的維護問題：
- SCP 不能對該 ARN 的註解，量一多就不好管理
- SCP 的量一多就會遇到限制 (Quotas for AWS Organizations)：
- 1 個 SCP 只能 5k (5,120 bytes)
- 1 個 OU 只能 Attach 5 個 SCP
- 1 個 Account 只能 Attach 5 個 SCP
測試
轉到 Linked-Account 這邊，測試幾種使用者情境：
- 使用 Linked-Root 擁有 AdministratorAccess 權限登入，無法執行
dynamodb:CreateTable、dynamodb:GetItem - 使用 Linked-User/scott.liao 擁有 AdministratorAccess 權限登入，無法執行
dynamodb:CreateTable、dynamodb:GetItem - 使用 Linked-User/shazi7804 擁有 AdministratorAccess 權限登入，無法執行
dynamodb:CreateTable可以執行dynamodb:GetItem - 使用 Linked-Role/WebRole 擁有 AdministratorAccess 權限登入，無法執行
dynamodb:CreateTable可以執行dynamodb:GetItem
參考
