應用場景

企業(yè)上云過程中，一般會根據(jù)企業(yè)自身情況，通過調(diào)研和挑選，圈定需要訂購的云產(chǎn)品列表，并與云廠商簽訂批量訂購協(xié)議，從而使企業(yè)利益最大化。企業(yè)內(nèi)部會要求各用戶從圈定的云產(chǎn)品列表中進行訂購，避免企業(yè)利益受損。這就是常見的企業(yè)需要啟用可用云產(chǎn)品白名單的場景。

另外，基于安全合規(guī)考慮，企業(yè)需要啟用可用云產(chǎn)品白名單，用來規(guī)范用戶的使用行為，避免有意或無意的違規(guī)。

方案對比

老方案：通過訪問控制（RAM）授予用戶指定云產(chǎn)品的權限

該方案是授權到每個用戶，適用業(yè)務場景比較單一的情況。當授權的數(shù)量、授權維度增加時，通過該方式滿足企業(yè)可用云產(chǎn)品白名單的要求就會比較難，且管理成本會比較高。具體體現(xiàn)在以下幾個方面：

• 針對用戶的點對點授權，復雜度與您所管理的用戶和資源數(shù)量成正比。

  您要為每個用戶在對應環(huán)境內(nèi)配置訪問不同資源的所需權限。當某個用戶不再需要某個權限，或者需要修改其權限時，您需要找到這個用戶進行權限更新。在新增用戶和減少用戶時，您需要設置和回收權限。當可用云產(chǎn)品白名單需要更新時，您不得不再次對所有已生效用戶同步這個更新，策略的維護成本不可避免。

• 授權策略復雜，需要滿足賦權和規(guī)避策略的雙重要求。

  當授權的因素涉及到更多維度時（例如：需要考慮資源所在位置、所在業(yè)務環(huán)境等因素），需要根據(jù)不同維度授予不同權限。例如：某地域的資源不允許用戶訂購、某項目訂購云產(chǎn)品的特定限制、某些用戶或角色可以無限制操作等。這些情況會進一步增加授權管理的復雜性。

• 授權和管控耦合，帶來合規(guī)風險。

  權限管理員根據(jù)業(yè)務需要調(diào)整用戶的授權以達到業(yè)務要求，這些操作需要避開對合規(guī)類權限的影響，他（她）需要了解權限設計的所有細節(jié)，必要時可能需要合規(guī)管理員的協(xié)助才能完成。合規(guī)管理員也面臨同樣的問題。很明顯，兩種角色職能的操作耦合狀況，無論對權限管理還是合規(guī)管控，都會存在極大的安全隱患。用戶身份和被訪問的資源間存在諸多特定限制，從而形成復雜的權限配置要求，給管理帶來麻煩。

  

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

資源目錄的管控策略支持了"Effect": "Allow"，企業(yè)可以使用它，簡單高效地解決上述問題。管控策略示例如下：

{
  "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"

}

上述管控策略示例中包含以下兩個內(nèi)容：

• 僅允許對華北2（北京）和華東2（上海）地域的ECS和RDS進行操作（即允許訂購和使用），禁止對其他不符合條件的云產(chǎn)品進行操作。

• 名為a-project-admin-*的RAM角色可以無限制地操作。

使用管控策略的優(yōu)勢如下：

• 管控策略具備基于資源目錄樹形結構從上向下繼承的特點。

  您只需要將管控策略綁定到需要管控的節(jié)點（資源夾或成員）上，它將沿著資源目錄樹向下（當前節(jié)點及其下所有節(jié)點）影響節(jié)點下的所有成員。當成員的RAM用戶或RAM角色訪問阿里云服務時，都將受到管控策略的管控，實現(xiàn)預期管控的結果。在需要更新可用云產(chǎn)品白名單時，您只需要維護這條管控策略即可。

  
  重要

  管控策略對所有資源目錄成員中的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授權策略分開管理，共同生效。

  使用管控策略進行合規(guī)管理，使用RAM進行授權管理，使合規(guī)管理與授權管理職能分開，從而保護企業(yè)合規(guī)安全。管控策略屬于頂層管控決策，高于授權策略，是企業(yè)的基本原則，所有業(yè)務規(guī)范都必須在企業(yè)基本原則之下進行制定。

方案實施

當您充分了解了管控策略新方案后，您可以開啟管控策略功能、然后創(chuàng)建自定義管控策略，并將其綁定到資源目錄的目標節(jié)點上。具體操作，請參見開啟管控策略功能、創(chuàng)建自定義管控策略和綁定自定義管控策略。

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

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

  在資源目錄中，推薦您使用RAM用戶通過STS方式登錄到成員進行管理操作。此時，您需要在管控策略內(nèi)增加對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"
  
  }

• 在綁定了管控策略的目標節(jié)點上，解綁系統(tǒng)管控策略FullAliyunAccess。

  為了避免啟用自定義管控策略后因為沒有顯式允許（Allow）而直接導致隱式拒絕（Implicit Deny）所有操作，資源目錄會默認為每個節(jié)點綁定系統(tǒng)管控策略FullAliyunAccess，該策略允許所有訪問。在您使用了自定義Allow管控策略后，則需要解綁系統(tǒng)管控策略FullAliyunAccess，避免您自定義的Allow管控策略無效。關于管控策略的工作原理，請參見工作原理。

了解更多

在上述示例中，企業(yè)需要對ECS、RDS之外的所有云產(chǎn)品實施禁用，如果使用拒絕（Deny）語句，企業(yè)不得不列出ECS、RDS之外的所有云產(chǎn)品，這個操作非常繁瑣，且容易遺漏。在使用Allow語句后，實現(xiàn)過程就變得簡單可靠。

如果您有明確的禁用操作項，且數(shù)量不多時，您可以使用Deny語句顯式拒絕這類操作。例如：明確不允許訂購中國（香港）和華南3（廣州）地域的云產(chǎn)品，您可以使用Deny語句，策略示例如下。如果使用Allow語句，反而復雜了。

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

因此，您需要根據(jù)實際業(yè)務場景，靈活使用管控策略的Allow和Deny語句，簡化策略的編寫。

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