應(yīng)用

技術(shù)

物聯(lián)網(wǎng)世界 >> 物聯(lián)網(wǎng)新聞 >> 物聯(lián)網(wǎng)熱點新聞
企業(yè)注冊個人注冊登錄

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

2023-03-23 09:28 北方資訊網(wǎng)
關(guān)鍵詞:服務(wù)控制方案

導(dǎo)讀:構(gòu)建云上運行環(huán)境,安全是重中之重。亞馬遜云科技采用了“責(zé)任共擔(dān)模式”,邀您共同承擔(dān)構(gòu)建云上運行環(huán)境安全合規(guī)的責(zé)任。

構(gòu)建云上運行環(huán)境,安全是重中之重。亞馬遜云科技采用了“責(zé)任共擔(dān)模式”,邀您共同承擔(dān)構(gòu)建云上運行環(huán)境安全合規(guī)的責(zé)任。云上安全可二分為“云自身安全”和“云內(nèi)部安全”。前者由亞馬遜云科技負責(zé),后者由您負責(zé)。您必須對云上資源進行必要和恰當?shù)呐渲茫蛊渚邆湟欢ǖ陌踩?,甚至達到更高的安全標準,從而履行安全責(zé)任。

亞馬遜云科技提倡的完善架構(gòu)的多賬戶云上環(huán)境包含六大支柱,其中權(quán)限管理是安全性支柱的重要內(nèi)容之一。我們提供了一系列的服務(wù)、工具和方法幫助您有效管理權(quán)限:例如通過 Amazon Organizations 來集中監(jiān)控和管理賬戶,通過 Amazon IAM 來管理賬戶內(nèi)的各用戶、角色和群組等等。

在多賬戶的組織層面建立權(quán)限防護機制,服務(wù)控制策略是其中不可或缺的一環(huán)。為彌補此塊中國區(qū)域的服務(wù)差異,之前我們進行了許多有益的嘗試(博客甲2020-04、乙2021-05、丙2021-09),核心思想是利用權(quán)限邊界,盡可能模擬服務(wù)控制政策對賬戶的權(quán)限約束。最新的丙方案(以下稱“前方案”)有一些限制和不足之處:例如策略文件大小有限、不支持組織關(guān)系繼承等。此外前方案在易用性和可視化簡潔操作方面,和原生服務(wù)亦有一定差距。本文力圖改良不足和彌合差距,同時朝精簡資源方面努力。本方案千方百計向原生服務(wù)靠攏,亦有利于您在原生服務(wù)發(fā)布后順利遷移。

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

解決方案概覽

本方案的核心思想是“于權(quán)限邊界策略顯式允許,于客戶托管策略顯式拒絕”來限制 IAM 實體。實現(xiàn)則借助于亞馬遜云科技原生服務(wù),但是盡可能精簡所涉服務(wù)類型。此外設(shè)計理念是用戶友好,即借鑒原生服務(wù)的操作習(xí)慣,充分利用管理控制臺既有的用戶交互界面,強調(diào)可視化交互模式,盡量提高易用性,簡化不必要操作。在運維方面,利用流水線等工具提供一鍵部署和銷毀功能。

上圖是本方案架構(gòu)草圖,主要內(nèi)容有:

·方案主體置于安全賬戶,主要包含主函數(shù)管理各賬戶權(quán)限,主隊列序列化各觸發(fā)事件,策略參數(shù)存放和可視化編輯各控制策略,各事件規(guī)則過濾收集相應(yīng)觸發(fā)事件等。

·在管理賬戶捕獲組織結(jié)構(gòu)的增刪標簽及移動賬戶事件。默認策略函數(shù)輔助附加推薦的策略到組織根。

·在各成員賬戶捕獲創(chuàng)建角色和用戶事件。

以上是本方案的核心架構(gòu)和主要服務(wù)。和前方案相比減少了所用服務(wù)種類和資源數(shù)量,簡化了用戶操作和日常運維。本方案有一個通用公共字串作為“前綴”,方便標識本方案資源。

適用服務(wù)控制策略

>>新建策略并適用

適用服務(wù)控制策略(以下簡稱“策略”)主要分兩步,首先定義策略,其次綁定策略。登陸安全賬戶參數(shù)庫控制臺,新建標準敏感字串型參數(shù),名稱為 /前綴/ policy /名稱,密鑰源為 alias /前綴/ pbm,值為策略文檔。注意參數(shù)庫并不會檢查策略語法,您可以在 IAM 控制臺驗證策略是否合規(guī)。您可以按照原生服務(wù)的策略內(nèi)容進行定義。

定義好策略后,可以綁定并適用策略。登陸管理賬戶組織控制臺,在組織結(jié)構(gòu)中選擇組織部門或者賬戶,選擇標簽頁,新建標簽,其鍵為策略參數(shù)名,其值為空,然后保存。

對于成員賬戶而言,適用策略內(nèi)容包含賬戶標簽中的所有策略,以及上溯至根的所有組織部門以及組織根標簽的所有策略的并集。類似于用作拒絕列表的策略繼承。注意,本方案暫不支持嚴格的用作允許列表的繼承。我們在后面章節(jié)詳細分析。

我們會對適用策略內(nèi)容進行合并,根據(jù)語句標識去重,按策略大小限制創(chuàng)建數(shù)個客戶托管策略,以便附加到 IAM 實體和設(shè)置權(quán)限邊界。IAM 實體現(xiàn)有的權(quán)限邊界策略內(nèi)容會被合并保留,仍然有效。

>>修改策略內(nèi)容或刪除策略

要修改策略內(nèi)容,登陸安全賬戶參數(shù)庫控制臺,找到策略參數(shù),選擇編輯進行修改并保存。要刪除策略,找到策略參數(shù),選擇刪除進行刪除。建議刪除前先解綁該策略,即刪除策略在組織結(jié)構(gòu)里對應(yīng)的所有標簽。

增刪改策略參數(shù)都會觸發(fā)參數(shù)事件并被捕獲。對于策略所涉組織部門和賬戶,都會更新適用策略。

>>修改或解除綁定策略

要修改綁定,登陸管理賬戶組織控制臺,在組織部門或賬戶標簽頁刪除并新建標簽(因標簽不支持修改鍵)。刪除和新建標簽可在一步完成。要解除綁定,在組織部門或賬戶標簽頁刪除標簽。

增刪標簽都會觸發(fā)接口調(diào)用事件并被捕獲。對所涉組織部門或賬戶,會更新適用策略。

>>在組織結(jié)構(gòu)內(nèi)移動賬戶

登陸管理賬戶組織控制臺,選擇一個賬戶,選擇移動,選擇目的組織部門然后移動賬戶。移動賬戶事件會被捕獲,對該賬戶會根據(jù)新組織部門更新適用策略。

>>在賬戶內(nèi)新建用戶或角色

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

>>更新節(jié)點適用策略

我們用“節(jié)點”代指組織樹形結(jié)構(gòu)上的點,包括組織根,組織部門和賬戶。如果想對某節(jié)點的所有子賬戶,或者某賬戶更新策略,即重新適用最新策略,您可以在該節(jié)點新建或刪除任意非策略標簽,以觸發(fā)主函數(shù)執(zhí)行。

以上通過控制臺可視化方式進行的操作,都可以通過亞馬遜云科技命令行接口,軟件開發(fā)包等其他方式達到相同的效果。

監(jiān)控告警和日常運維

>>管控新成員賬戶

新建賬戶后,您需要登陸基礎(chǔ)賬戶 Amazon Step Functions 控制臺,執(zhí)行管控狀態(tài)機,以使得新賬戶受到本方案有效管控。完成之后移動賬戶到組織部門,以適用該部門的策略。

>>監(jiān)控策略適用狀態(tài)

本方案通過事件捕獲和傳遞機制觸發(fā)主函數(shù)來適用策略,故存在分鐘級別的延遲。您可以通過狀態(tài)郵件,或者登陸安全賬戶日志組控制臺,查看名為 /aws/lambda/前綴-lambda-pbm 的日志組,了解運行狀態(tài)。

在安全賬戶預(yù)置了狀態(tài) Amazon SNS 主題,接收方案主要運行狀態(tài)和告警信息。內(nèi)容會發(fā)送到您訂閱的電子郵箱。主要的告警信息包含:

Amazon SNS:

·無法識別的標簽鍵:即沒有以 /前綴/policy/名稱 形式創(chuàng)建的標簽鍵。

·不合規(guī)的策略內(nèi)容:策略內(nèi)容不合策略語法,或者不合 JSON 語法。

JSON:

·顯式允許語句過多:顯式允許語句只能置于權(quán)限邊界策略,受到6,144字節(jié)的限制。

·無法附加策略到實體:有可能 IAM 實體附加托管策略數(shù)已達上限20個。

·無法更新現(xiàn)有邊界策略:有可能現(xiàn)有邊界策略語句標識與控制策略語句標識沖突。

>>白名單和使用限制

您可以定義 IAM 實體白名單,以躲避本方案的權(quán)限約束。但是我們強烈不建議您使用,且原生服務(wù)也沒有對應(yīng)的功能。白名單是一個逗號分隔的字串,存儲于基礎(chǔ)賬號的參數(shù)中。只要實體名稱在白名單中,就不會適用策略。定義好白名單后,您可以在某節(jié)點更新適用策略,使之生效。

本方案和原生服務(wù)類似,有以下主要限制:

和原生服務(wù)類似:

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

·不影響服務(wù)相關(guān)角色,即路徑中有 aws-service-role 的角色。

服務(wù)相關(guān)角色:

·不影響維持本方案正常運行的核心角色。我們用這些核心角色管理成員賬戶權(quán)限。

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

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

>>策略大小和附加數(shù)

在原生服務(wù)中,策略文檔最大值為5,120字節(jié),最多附加5個策略到節(jié)點,組織部門最大深度為5層。所以理論上適用到賬戶的策略內(nèi)容最大值為5,120*5*5 =128,000。

在本方案中,策略文檔以托管策略形式存在,最大值為6,144字節(jié)。 最多附加20個標簽到實體。但是附加到 IAM 實體上的托管策略最多20個,所以理論上適用到賬戶的策略內(nèi)容最大值為6,144*20=122,880。

需要注意的是,顯式允許語句只能置于權(quán)限邊界策略中,故顯式允許語句最多只能是6,144字節(jié)。所以,我們建議您以用作拒絕列表的方式使用本方案,可有效突破限制到122,880字節(jié)。

但是我們建議您充分考慮原生服務(wù)的限制,而非用盡本方案的限制以便遷移:例如單個策略內(nèi)容不要超過5120字節(jié)。附加到節(jié)點的標簽數(shù)不要超過5個。另外默認附加數(shù)上限是10個,需要申請增加服務(wù)限額到最多20個。

標簽策略替代方案的載體

標簽策略也是目前中國區(qū)服務(wù)差異之一。我們也為此提供了替代解決方案(博客丁2022-08)。在對標簽策略轉(zhuǎn)寫為顯式拒絕的普通策略文檔后,可將其以用作拒絕列表的服務(wù)控制策略適用到相應(yīng)的組織部門或賬戶,達到替代原生標簽策略的目的。

用作允許列表的策略繼承

在策略評估邏輯中,有如下基本關(guān)系:顯式拒絕 > 顯式允許 > 隱式拒絕。> 的含義是覆蓋。因此服務(wù)控制策略有兩種主要使用方式,即用作拒絕列表和用作允許列表。本方案對策略的處理方法是從葉遍歷到根取并集,然后按許可情況分別適用為客戶托管策略和權(quán)限邊界策略。假設(shè)有如下組織結(jié)構(gòu),虛線框內(nèi)為節(jié)點附加策略內(nèi)容,對最右側(cè)路徑的賬戶3而言:

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

? 左圖:原生服務(wù)只有操作 B 會被允許(所有節(jié)點允許)。

? 左圖:本方案會允許操作 B (所有節(jié)點允許)和操作 C(任意節(jié)點允許)。

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

? 右圖:操作 ABC 都被顯式拒絕,其他操作被允許(本方案和原生服務(wù)一致)。

回顧之前策略語句的處理辦法,即顯式允許置于權(quán)限邊界策略,顯式拒絕置于客戶托管策略。如果您的策略語句沒有顯式允許,我們會添加一個類似允許所有操作的顯式允許語句。如果您的策略語句有至少一個顯式允許,我們會把所有的顯式允許置于權(quán)限邊界策略中,而不做任何額外添加。

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

遷移到原生服務(wù)

上面章節(jié)在不同方面討論了遷移到原生服務(wù)的注意事項,此處做一個總結(jié)。

● 單個策略小于5,120字節(jié),且和原生服務(wù)策略一一對應(yīng);

● 組織結(jié)構(gòu)節(jié)點附加標簽小于等于5個;

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

我們建議您提早規(guī)劃,當原生服務(wù)發(fā)布后,盡早遷移過去。遷移之前,請在沙盒環(huán)境進行充分測試。

● 按照現(xiàn)有策略一一對應(yīng)創(chuàng)建服務(wù)控制策略;

● 按照現(xiàn)有綁定關(guān)系一一對應(yīng)附加新建的服務(wù)控制策略到節(jié)點;

● 刪除所有組織結(jié)構(gòu)節(jié)點上的策略標簽以解綁所有策略;

● 卸載本方案。

>>非組織多賬戶架構(gòu)管控

如果由于各種原因,您不能或者不便使用 Amazon Organizations 組織,則本方案不適用此種場景。不過在前方案的基礎(chǔ)上,我們提供對非組織多賬戶架構(gòu)的支持,進行類似服務(wù)控制策略的管控。您可以訪問 Cloud Foundations 解決方案頁面聯(lián)系亞馬遜云科技專家獲取解決方案。此外本方案支持亞馬遜云科技全球區(qū)域部署。

安全措施與考量

作為安全功能的替代方案,我們十分重視本方案的安全性,盡可能“自我約束”。例如對所有適用之處用 Amazon KMS 客戶密鑰進行靜態(tài)加密。安全賬戶不經(jīng)過管理賬戶直接代入成員賬戶,且代入角色遵循最小權(quán)限原則嚴格限定 IAM 相關(guān)操作。各用戶密鑰、事件總線、隊列、主題的資源權(quán)限也遵循最小權(quán)限原則。

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

>>適用推薦的強制策略

我們預(yù)置了十幾個策略,涵蓋了 Amazon Control Tower 里所有的強制護欄,并額外新增了幾個。建議您在組織根適用所有預(yù)置策略,以增強安全。適用方法是運行管理賬戶中的 前綴-lambda-pbm-policy 函數(shù),輸入任意參數(shù)。

卸載解決方案

本方案提供銷毀狀態(tài)機一鍵銷毀所有資源。卸載之前務(wù)必確認您的云上環(huán)境已經(jīng)遷移至原生服務(wù)或者其他類似方案,以避免出現(xiàn)安全漏洞。此外您需確認已經(jīng)刪除組織結(jié)構(gòu)中的所有策略標簽。

總結(jié)

本文介紹了一款直觀易用的服務(wù)控制策略替代新方案,力圖彌合服務(wù)差異,并在可視化交互和簡化操作方面著力提升用戶體驗。同時在使用習(xí)慣和策略管理上,充分考慮日后平穩(wěn)有序遷移到原生服務(wù)的各方面問題。您可以訪問 Cloud Foundations 解決方案頁面了解更多信息,或者聯(lián)系亞馬遜云科技專家獲取解決方案。