使用管控策略實現企業可用雲產品白名單 - Resource Management

使用管控策略的允許（Allow）效果，可以簡單方便地實現企業可用雲產品白名單，規範企業內部使用者訂購和使用雲產品的行為。

應用情境

企業上雲過程中，一般會根據企業自身情況，通過調研和挑選，圈定需要訂購的雲產品列表，並與雲廠商簽訂批量訂購協議，從而使企業利益最大化。企業內部會要求各使用者從圈定的雲產品列表中進行訂購，避免企業利益受損。這就是常見的企業需要啟用可用雲產品白名單的情境。

另外，基於安全合規考慮，企業需要啟用可用雲產品白名單，用來規範使用者的使用行為，避免有意或無意的違規。

方案對比

老方案：通過存取控制（RAM）授予使用者指定雲產品的許可權

該方案是授權到每個使用者，適用業務情境比較單一的情況。當授權的數量、授權維度增加時，通過該方式滿足企業可用雲產品白名單的要求就會比較難，且管理成本會比較高。具體體現在以下幾個方面：

針對使用者的點對點授權，複雜度與您所管理的使用者和資源數量成正比。
您要為每個使用者在對應環境內配置訪問不同資源的要求的權限。當某個使用者不再需要某個許可權，或者需要修改其許可權時，您需要找到這個使用者進行許可權更新。在新增使用者和減少使用者時，您需要設定和回收許可權。當可用雲產品白名單需要更新時，您不得不再次對所有已生效使用者同步這個更新，策略的維護成本不可避免。
授權策略複雜，需要滿足賦權和規避策略的雙重要求。
當授權的因素涉及到更多維度時（例如：需要考慮資源所在位置、所在業務環境等因素），需要根據不同維度授予不同許可權。例如：某地區的資源不允許使用者訂購、某專案訂購雲產品的特定限制、某些使用者或角色可以無限制操作等。這些情況會進一步增加授權管理的複雜性。
授權和管控耦合，帶來合規風險。
許可權管理員根據業務需要調整使用者的授權以達到業務要求，這些操作需要避開對合規類許可權的影響，他（她）需要瞭解許可權設計的所有細節，必要時可能需要合規管理員的協助才能完成。合規管理員也面臨同樣的問題。很明顯，兩種角色職能的操作耦合狀況，無論對許可權管理還是合規管控，都會存在極大的安全隱患。使用者身份和被訪問的資源間存在諸多特定限制，從而形成複雜的許可權配置要求，給管理帶來麻煩。

新方案（推薦）：通過管控策略的允許（Allow）策略進行頂層管控

資來源目錄的管控策略支援了"Effect": "Allow"，企業可以使用它，簡單高效地解決上述問題。管控策略樣本如下：

{
  "Statement":[
    {
      "Effect": "Allow",
      "Action":[
                "ecs:*",
                "rds:*"
      ],
      "Resource": [
                "acs:*:*cn-beijing*:*:*",
                "acs:*:*cn-shanghai*:*:*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*",
      "Condition": {
          "StringLike": {
                    "acs:PrincipalARN": [
                    "acs:ram:*:*:role/a-project-admin-*"
                       ]
                  }
            }
      }
  ],
  "Version": "1"

}

上述管控策略樣本中包含以下兩個內容：

僅允許對華北2（北京）和華東2（上海）地區的ECS和RDS進行操作（即允許訂購和使用），禁止對其他不合格雲產品進行操作。
名為a-project-admin-*的RAM角色可以無限制地操作。

使用管控策略的優勢如下：

管控策略具備基於資來源目錄樹形結構從上向下繼承的特點。
您只需要將管控策略綁定到需要管控的節點（資源夾或成員）上，它將沿著資來源目錄樹向下（當前節點及其下所有節點）影響節點下的所有成員。當成員的RAM使用者或RAM角色訪問阿里雲服務時，都將受到管控策略的管控，實現預期管控的結果。在需要更新可用雲產品白名單時，您只需要維護這條管控策略即可。
重要
管控策略對所有資來源目錄成員中的RAM使用者和RAM角色生效，但對成員的根使用者不生效。同時，資來源目錄的管理帳號位於資來源目錄外部，不歸屬於資來源目錄，所以管控策略對管理帳號內的所有身份也不生效。
管控策略不進行授權，它只定義許可權的邊界，可以在不改變使用者原有授權的基礎上疊加影響。
假設某使用者具有訪問ECS和EIP的許可權，當該使用者被上述樣本中的管控策略影響後：
- 該使用者可以訪問華北2（北京）和華東2（上海）地區的ECS。
  該使用者本身具有訪問ECS的許可權，且管控策略也允許訪問華北2（北京）和華東2（上海）地區的ECS，所以該使用者可以訪問華北2（北京）和華東2（上海）地區的ECS。
- 該使用者不能訪問EIP。
  雖然該使用者具有訪問EIP的許可權，但管控策略中未包含EIP的允許語句，所以該使用者不能訪問EIP。
- 該使用者不能訪問RDS。
  雖然管控策略允許訪問華北2（北京）和華東2（上海）地區的RDS，但該使用者本身沒有被授予訪問RDS的許可權，且管控策略不會對使用者授權，所以該使用者不能訪問RDS。
管控策略與RAM授權策略分開管理，共同生效。
使用管控策略進行合規管理，使用RAM進行授權管理，使合規管理與授權管理職能分開，從而保護企業合規安全。管控策略屬於頂層管控決策，高於授權策略，是企業的基本原則，所有業務規範都必須在企業基本原則之下進行制定。

方案實施

當您充分瞭解了管控策略新方案後，您可以開啟管控策略功能、然後建立自訂管控策略，並將其綁定到資來源目錄的目標節點上。具體操作，請參見開啟管控策略功能、建立自訂管控策略和綁定自訂管控策略。

另外，在實施過程中還需要完成以下任務：

在自訂管控策略中，增加允許sts:AssumeRole策略。

在資來源目錄中，推薦您使用RAM使用者通過STS方式登入到成員進行管理操作。此時，您需要在管控策略內增加對sts:AssumeRole的允許語句，確保系統管理使用者的登入許可權可用。修改後的管控策略樣本如下：

{
  "Statement":[
    {
      "Effect": "Allow",
      "Action":[
                "ecs:*",
                "rds:*"
      ],
      "Resource": [
                "acs:*:*cn-beijing*:*:*",
                "acs:*:*cn-shanghai*:*:*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*",
      "Condition": {
          "StringLike": {
                    "acs:PrincipalARN": [
                    "acs:ram:*:*:role/a-project-admin-*"
                       ]
                  }
            }
      },
    {
      "Effect": "Allow",
      "Action":[
                "sts:AssumeRole"
      ],
      "Resource": "*"
    }
  ],
  "Version": "1"

}

在綁定了管控策略的目標節點上，解除綁定系統管控策略FullAliyunAccess。
為了避免啟用自訂管控策略後因為沒有顯式允許（Allow）而直接導致隱式拒絕（Implicit Deny）所有操作，資來源目錄會預設為每個節點繫結系統管控策略FullAliyunAccess，該策略允許所有訪問。在您使用了自訂Allow管控策略後，則需要解除綁定系統管控策略FullAliyunAccess，避免您自訂的Allow管控策略無效。關於管控策略的工作原理，請參見工作原理。

瞭解更多

在上述樣本中，企業需要對ECS、RDS之外的所有雲產品實施禁用，如果使用拒絕（Deny）語句，企業不得不列出ECS、RDS之外的所有雲產品，這個操作非常繁瑣，且容易遺漏。在使用Allow語句後，實現過程就變得簡單可靠。

如果您有明確的禁用操作項，且數量不多時，您可以使用Deny語句顯式拒絕這類操作。例如：明確不允許訂購中國（香港）和華南3（廣州）地區的雲產品，您可以使用Deny語句，策略樣本如下。如果使用Allow語句，反而複雜了。

{
      "Effect": "Deny",
      "Action":[
                "*"
      ],
      "Resource": [
                "acs:*:*cn-hongkong*:*:*",
                "acs:*:*cn-guangzhou*:*:*"
      ]
}

因此，您需要根據實際業務情境，靈活使用管控策略的Allow和Deny語句，簡化策略的編寫。

在一個管控策略中可以包含多組Allow和Deny語句，您需要評估其合并後產生的最終結果，在設計時避免它們之間產生衝突。一旦衝突，會遵照Deny優先原則。同一節點上綁定的所有管控策略，也會被合并在一起進行鑒權，只要命中Deny語句，系統會直接判定結果為顯式拒絕（Explicit Deny），結束整個鑒權流程。