AWS Organizations SCPs 限制 Linked-Account 允許 IAM 白名單存取 Dynamodb

shazi7804

5 年前

應因公司資安政策，希望資料庫類型的 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

參考

Service Control Policy and IAM Policy with AWS Organization

分享此文：