亞馬遜雲科技帶來一款直觀易用的服務控制策略新替代方案

構建雲上執行環境，安全是重中之重。亞馬遜雲科技採用了“責任共擔模式”，邀您共同承擔構建雲上執行環境安全合規的責任。雲上安全可二分為“雲自身安全”和“雲內部安全”。前者由亞馬遜雲科技負責，後者由您負責。您必須對雲上資源進行必要和恰當的配置，使其具備一定的安全性，甚至達到更高的安全標準，從而履行安全責任。

亞馬遜雲科技提倡的完善架構的多賬戶雲上環境包含六大支柱，其中許可權管理是安全性支柱的重要內容之一。我們提供了一系列的服務、工具和方法幫助您有效管理許可權：例如透過 Amazon Organizations 來集中監控和管理賬戶，透過 Amazon IAM 來管理賬戶內的各使用者、角色和群組等等。

在多賬戶的組織層面建立許可權防護機制，服務控制策略是其中不可或缺的一環。為彌補此塊中國區域的服務差異，之前我們進行了許多有益的嘗試（部落格甲2020-04、乙2021-05、丙2021-09），核心思想是利用許可權邊界，儘可能模擬服務控制政策對賬戶的許可權約束。最新的丙方案（以下稱“前方案”）有一些限制和不足之處：例如策略檔案大小有限、不支援組織關係繼承等。此外前方案在易用性和視覺化簡潔操作方面，和原生服務亦有一定差距。本文力圖改良不足和彌合差距，同時朝精簡資源方面努力。本方案千方百計向原生服務靠攏，亦有利於您在原生服務釋出後順利遷移。

下表羅列了原生服務、本方案和前方案的主要異同點，以供您對比參考。

解決方案概覽

本方案的核心思想是“於許可權邊界策略顯式允許，於客戶託管策略顯式拒絕”來限制 IAM 實體。實現則藉助於亞馬遜雲科技原生服務，但是儘可能精簡所涉服務型別。此外設計理念是使用者友好，即借鑑原生服務的操作習慣，充分利用管理控制檯既有的使用者互動介面，強調視覺化互動模式，儘量提高易用性，簡化不必要操作。在運維方面，利用流水線等工具提供一鍵部署和銷燬功能。

上圖是本方案架構草圖，主要內容有：

·方案主體置於安全賬戶，主要包含主函式管理各賬戶許可權，主佇列序列化各觸發事件，策略引數存放和視覺化編輯各控制策略，各事件規則過濾收集相應觸發事件等。

·在管理賬戶捕獲組織結構的增刪標籤及移動賬戶事件。預設策略函式輔助附加推薦的策略到組織根。

·在各成員賬戶捕獲建立角色和使用者事件。

以上是本方案的核心架構和主要服務。和前方案相比減少了所用服務種類和資源數量，簡化了使用者操作和日常運維。本方案有一個通用公共字串作為“字首”，方便標識本方案資源。

適用服務控制策略

>>新建策略並適用

適用服務控制策略（以下簡稱“策略”）主要分兩步，首先定義策略，其次繫結策略。登陸安全賬戶引數庫控制檯，新建標準敏感字串型引數，名稱為 /字首/ policy /名稱，金鑰源為 alias /字首/ pbm，值為策略文件。注意引數庫並不會檢查策略語法，您可以在 IAM 控制檯驗證策略是否合規。您可以按照原生服務的策略內容進行定義。

定義好策略後，可以繫結並適用策略。登陸管理賬戶組織控制檯，在組織結構中選擇組織部門或者賬戶，選擇標籤頁，新建標籤，其鍵為策略引數名，其值為空，然後儲存。

對於成員賬戶而言，適用策略內容包含賬戶標籤中的所有策略，以及上溯至根的所有組織部門以及組織根標籤的所有策略的並集。類似於用作拒絕列表的策略繼承。注意，本方案暫不支援嚴格的用作允許列表的繼承。我們在後面章節詳細分析。

我們會對適用策略內容進行合併，根據語句標識去重，按策略大小限制建立數個客戶託管策略，以便附加到 IAM 實體和設定許可權邊界。IAM 實體現有的許可權邊界策略內容會被合併保留，仍然有效。

>>修改策略內容或刪除策略

要修改策略內容，登陸安全賬戶引數庫控制檯，找到策略引數，選擇編輯進行修改並儲存。要刪除策略，找到策略引數，選擇刪除進行刪除。建議刪除前先解綁該策略，即刪除策略在組織結構裡對應的所有標籤。

增刪改策略引數都會觸發引數事件並被捕獲。對於策略所涉組織部門和賬戶，都會更新適用策略。

>>修改或解除繫結策略

要修改繫結，登陸管理賬戶組織控制檯，在組織部門或賬戶標籤頁刪除並新建標籤（因標籤不支援修改鍵）。刪除和新建標籤可在一步完成。要解除繫結，在組織部門或賬戶標籤頁刪除標籤。

增刪標籤都會觸發介面呼叫事件並被捕獲。對所涉組織部門或賬戶，會更新適用策略。

>>在組織結構內移動賬戶

登陸管理賬戶組織控制檯，選擇一個賬戶，選擇移動，選擇目的組織部門然後移動賬戶。移動賬戶事件會被捕獲，對該賬戶會根據新組織部門更新適用策略。

>>在賬戶內新建使用者或角色

登陸成員賬戶 IAM 控制檯，新建使用者或者角色。新建事件會被捕獲。如果新建 IAM 實體不在白名單列表中，則會根據所屬賬戶及組織部門更新適用策略。

>>更新節點適用策略

我們用“節點”代指組織樹形結構上的點，包括組織根，組織部門和賬戶。如果想對某節點的所有子賬戶，或者某賬戶更新策略，即重新適用最新策略，您可以在該節點新建或刪除任意非策略標籤，以觸發主函式執行。

以上透過控制檯視覺化方式進行的操作，都可以透過亞馬遜雲科技命令列介面，軟體開發包等其他方式達到相同的效果。

監控告警和日常運維

>>管控新成員賬戶

新建賬戶後，您需要登陸基礎賬戶 Amazon Step Functions 控制檯，執行管控狀態機，以使得新賬戶受到本方案有效管控。完成之後移動賬戶到組織部門，以適用該部門的策略。

>>監控策略適用狀態

本方案透過事件捕獲和傳遞機制觸發主函式來適用策略，故存在分鐘級別的延遲。您可以透過狀態郵件，或者登陸安全賬戶日誌組控制檯，檢視名為 /aws/lambda/字首-lambda-pbm 的日誌組，瞭解執行狀態。

在安全賬戶預置了狀態 Amazon SNS 主題，接收方案主要執行狀態和告警資訊。內容會傳送到您訂閱的電子郵箱。主要的告警資訊包含：

Amazon SNS：

·無法識別的標籤鍵：即沒有以 /字首/policy/名稱 形式建立的標籤鍵。

·不合規的策略內容：策略內容不合策略語法，或者不合 JSON 語法。

JSON：

·顯式允許語句過多：顯式允許語句只能置於許可權邊界策略，受到6,144位元組的限制。

·無法附加策略到實體：有可能 IAM 實體附加託管策略數已達上限20個。

·無法更新現有邊界策略：有可能現有邊界策略語句標識與控制策略語句標識衝突。

>>白名單和使用限制

您可以定義 IAM 實體白名單，以躲避本方案的許可權約束。但是我們強烈不建議您使用，且原生服務也沒有對應的功能。白名單是一個逗號分隔的字串，儲存於基礎賬號的引數中。只要實體名稱在白名單中，就不會適用策略。定義好白名單後，您可以在某節點更新適用策略，使之生效。

本方案和原生服務類似，有以下主要限制：

和原生服務類似：

·僅影響成員賬戶中的 IAM 角色和使用者，對管理賬戶沒有影響。

·不影響服務相關角色，即路徑中有 aws-service-role 的角色。

服務相關角色：

·不影響維持本方案正常執行的核心角色。我們用這些核心角色管理成員賬戶許可權。

·不影響名為 OrganizationAccountAccessRole（組織賬號訪問角色）。我們用此角色部署和銷燬方案。

請注意，我們保留組織賬號訪問角色，以供您在緊急情況下使用。如果您繞過本方案使用該角色對實施了管控的 IAM 實體或者策略進行修改，您的賬戶可能產生新的安全漏洞或者進入許可權管理的未知狀態。您可以重新適用策略以鞏固安全。

>>策略大小和附加數

在原生服務中，策略文件最大值為5,120位元組，最多附加5個策略到節點，組織部門最大深度為5層。所以理論上適用到賬戶的策略內容最大值為5,120*5*5 =128,000。

在本方案中，策略文件以託管策略形式存在，最大值為6,144位元組。 最多附加20個標籤到實體。但是附加到 IAM 實體上的託管策略最多20個，所以理論上適用到賬戶的策略內容最大值為6,144*20=122,880。

需要注意的是，顯式允許語句只能置於許可權邊界策略中，故顯式允許語句最多隻能是6,144位元組。所以，我們建議您以用作拒絕列表的方式使用本方案，可有效突破限制到122,880位元組。

但是我們建議您充分考慮原生服務的限制，而非用盡本方案的限制以便遷移：例如單個策略內容不要超過5120位元組。附加到節點的標籤數不要超過5個。另外預設附加數上限是10個，需要申請增加服務限額到最多20個。

標籤策略替代方案的載體

標籤策略也是目前中國區服務差異之一。我們也為此提供了替代解決方案（部落格丁2022-08）。在對標籤策略轉寫為顯式拒絕的普通策略文件後，可將其以用作拒絕列表的服務控制策略適用到相應的組織部門或賬戶，達到替代原生標籤策略的目的。

用作允許列表的策略繼承

在策略評估邏輯中，有如下基本關係：顯式拒絕 > 顯式允許 > 隱式拒絕。> 的含義是覆蓋。因此服務控制策略有兩種主要使用方式，即用作拒絕列表和用作允許列表。本方案對策略的處理方法是從葉遍歷到根取並集，然後按許可情況分別適用為客戶託管策略和許可權邊界策略。假設有如下組織結構，虛線框內為節點附加策略內容，對最右側路徑的賬戶3而言：

● 用作允許列表的策略繼承，特點是以顯式允許為主，且刪除託管的 FullAWSAccess （允許所有操作）策略。由於原生服務策略繼承採取篩選器模式，故要在賬戶允許操作，則該操作的顯式允許必須被該賬戶及其之上的每個組織部門直至組織根顯式允許。

• 左圖：原生服務只有操作 B 會被允許（所有節點允許）。

• 左圖：本方案會允許操作 B （所有節點允許）和操作 C（任意節點允許）。

● 用作拒絕列表的策略繼承，特點是以顯式拒絕為主，且每個節點附加託管的允許所有操作策略。由於顯式拒絕覆蓋顯式允許，故該模式較為簡單。即如果該賬戶及其之上的每個組織部門直至組織根的任意節點有顯式拒絕，則操作都會被拒絕。本方案與原生服務一致。

• 右圖：操作 ABC 都被顯式拒絕，其他操作被允許（本方案和原生服務一致）。

回顧之前策略語句的處理辦法，即顯式允許置於許可權邊界策略，顯式拒絕置於客戶託管策略。如果您的策略語句沒有顯式允許，我們會新增一個類似允許所有操作的顯式允許語句。如果您的策略語句有至少一個顯式允許，我們會把所有的顯式允許置於許可權邊界策略中，而不做任何額外新增。

綜上，本方案可視為用作拒絕列表的策略繼承。在用作允許列表的策略繼承情況下，本方案沒有原生服務那麼“嚴格”，即允許操作要求任意而非所有節點顯式允許。您需要充分考慮這個區別，以便遷移。例如若日後希望遷移至用作允許列表的策略繼承，則路徑上所有節點都應顯式允許該操作。

遷移到原生服務

上面章節在不同方面討論了遷移到原生服務的注意事項，此處做一個總結。

● 單個策略小於5,120位元組，且和原生服務策略一一對應；

● 組織結構節點附加標籤小於等於5個；

● 按照用作拒絕列表的方式繼承策略。如果用作允許列表的方式，則所有節點都需要顯式允許。

我們建議您提早規劃，當原生服務釋出後，儘早遷移過去。遷移之前，請在沙盒環境進行充分測試。

● 按照現有策略一一對應建立服務控制策略；

● 按照現有繫結關係一一對應附加新建的服務控制策略到節點；

● 刪除所有組織結構節點上的策略標籤以解綁所有策略；

● 解除安裝本方案。

>>非組織多賬戶架構管控

如果由於各種原因，您不能或者不便使用 Amazon Organizations 組織，則本方案不適用此種場景。不過在前方案的基礎上，我們提供對非組織多賬戶架構的支援，進行類似服務控制策略的管控。您可以訪問 Cloud Foundations 解決方案頁面聯絡亞馬遜雲科技專家獲取解決方案。此外本方案支援亞馬遜雲科技全球區域部署。

安全措施與考量

作為安全功能的替代方案，我們十分重視本方案的安全性，儘可能“自我約束”。例如對所有適用之處用 Amazon KMS 客戶金鑰進行靜態加密。安全賬戶不經過管理賬戶直接代入成員賬戶，且代入角色遵循最小許可權原則嚴格限定 IAM 相關操作。各使用者金鑰、事件匯流排、佇列、主題的資源許可權也遵循最小許可權原則。

您可以刪除組織賬號訪問角色以進一步提高安全性。在此之前，我們建議您充分測試控制策略的影響，以免陷入困境。請注意，本方案基於該角色部署和解除安裝。

>>適用推薦的強制策略

我們預置了十幾個策略，涵蓋了 Amazon Control Tower 裡所有的強制護欄，並額外新增了幾個。建議您在組織根適用所有預置策略，以增強安全。適用方法是執行管理賬戶中的 字首-lambda-pbm-policy 函式，輸入任意引數。

解除安裝解決方案

本方案提供銷燬狀態機一鍵銷燬所有資源。解除安裝之前務必確認您的雲上環境已經遷移至原生服務或者其他類似方案，以避免出現安全漏洞。此外您需確認已經刪除組織結構中的所有策略標籤。

總結

本文介紹了一款直觀易用的服務控制策略替代新方案，力圖彌合服務差異，並在視覺化互動和簡化操作方面著力提升使用者體驗。同時在使用習慣和策略管理上，充分考慮日後平穩有序遷移到原生服務的各方面問題。您可以訪問 Cloud Foundations 解決方案頁面瞭解更多資訊，或者聯絡亞馬遜雲科技專家獲取解決方案。