1、 云采用框架白皮書 文檔版本：1.0 1 云采用框架白皮書 文檔版本：1.0 2 目錄 目錄.2 作者.5 序言 1.6 序言 2.7 法律聲明.8 1.背景介紹.9 1.1.什么是云采用框架.9 2.上云戰略.10 2.1.企業上云的主要動機.10 2.2.上云所需的企業組織模型及其核心職責.11 3.上云準備.14 3.1.云上管理和治理框架 Landing Zone.14 3.2.阿里云上 Landing Zone 的主要組成部分.16 3.2.1.資源規劃.16 3.2.2.財務管理.18 3.2.3.網絡規劃.21 3.2.4.身份權限.30 云采用框架白皮書 文檔版本：1.0 3

2、3.2.5.安全防護.35 3.2.6.合規審計.40 3.3.基于 IaC 理念快速部署 Landing Zone.42 4.應用上云.47 4.1.企業應用上云規劃.47 4.1.1.上云評估模型.47 4.1.2.業務調研.48 4.1.3.應用上云策略及決策流程.48 4.1.4.應用上云優先級及計劃.49 4.2.應用上云實施.50 4.2.1.應用上云實施流程.50 4.2.2.應用調研.50 4.2.3.應用上云方案設計.51 4.2.4.上云遷移實施.58 4.2.5.測試與驗證.59 4.2.6.割接與上線.60 5.運營治理.63 5.1.風險治理方法論.63 5.1.1.

3、風險治理的方法論.63 5.1.2.風險治理的工作開展.65 云采用框架白皮書 文檔版本：1.0 4 5.2.阿里云上的治理基線.66 5.2.1.身份權限基線.66 5.2.2.數據安全基線.68 5.2.3.通用安全基線.71 5.2.4.業務連續性基線.73 6.結束語.75 7.基本概念.76 云采用框架白皮書 文檔版本：1.0 5 作者 出品人|何登成（阿里云開放平臺及企業 IT 治理負責人）核心作者|陳云龍、沈繹、王梓宏、魏俊欣 劉云飛、黃歡歡、劉文祥、李猛 任亞博、王觶程、劉自慧、管驥 張子軒、李超 總監制|蔣江偉（阿里云基礎產品事業部負責人）袁千（阿里云國際事業部負責人）編輯與

4、設計吳公博、黃冠超 特別鳴謝 中國信息通信研究院及楊玲玲女士提供指導 云采用框架白皮書 文檔版本：1.0 6 序言 1 云計算經過十幾年的發展，已經從最初的概念，演變成為企業發展所必須的基礎設施。今天，大家不會再去質疑云計算對企業發展的意義，而是開始探索如何在云的道路上走得更遠。一方面，云計算實現了基礎設施的快速交付和彈性擴展，也提供了豐富的云服務。企業可以在數小時內創建好自己的虛擬數據中心，也可以快速獲得各類的 PaaS 和 SaaS 服務。另一方面，企業對于云上的安全合規、風險可控、資源可管的訴求隨著業務大規模上云日益增加。因此，企業在使用云的時候需要平衡業務敏捷性和可管控性，在安全可控的

5、前提下實現業務的快速創新。阿里云開放平臺團隊在過去兩年拜訪了上百家企業客戶，在跟客戶相互交流學習的過程中，我們發現客戶在云上管理與治理時，有兩類比較顯著的特征：業務優先和治理優先。業務優先型的客戶上云以業務敏捷性為主，在云上的用量達到一定規模后，開始重新設計云上的 IT 管理和治理體系，返工成本和治理難度較大；治理優先型的客戶，在上云準備的過程中對如何使用和管理云進行全面細致的設計和規劃，規避規?；显坪髱淼某杀?、合規、安全和管理等方面的風險，從而實現上云價值的最大化。通過總結這上百家企業客戶在上云、管云過程中沉淀下來的經驗和最佳實踐，我們堅信各種行業的企業，無論規模大小，在云上構建起一個安

6、全合規、IT 資產可管可控的框架，并在此框架下實現業務的快速上云、快速創新，魚與熊掌兼得，是完全可行的。但前提是，需要有一個比較好的方法論來指導，基于此，在 2021年初，阿里云聯合信通院，編寫了這本云采用框架白皮書。白皮書通過總結阿里云上百家企業客戶的案例，在方法論層面對上云和管云進行探討，并提供了基于 Landing Zone 的一系列最佳實踐和自動化工具、腳本，幫助企業快速在阿里云上落地，在安全可控的環境下充分發揮云計算帶來的技術優勢，助力企業業務的敏捷創新與快速發展。蔣江偉 阿里巴巴高級研究員 阿里云基礎產品事業部負責人 云采用框架白皮書 文檔版本：1.0 7 序言 2 近年來，越來越

7、多的大型企業采用公有云作為核心的 IT 基礎設施，而云原生技術也成為了企業的數字化轉型的助推器。但隨之而來，傳統的 IT 管理和服務方法已經不能很好的適應并有效解決企業上云面臨的諸多挑戰，諸如安全合規、成本管理、資源的靈活使用和變更，敏捷開發和運維等等。為了確保業務在云上的快速落地和高效運營，以及將云原生的能力和企業 IT 管理戰略能夠更好的結合，需要有良好設計的云上 IT 管理和治理體系和可實踐方法來支持。阿里云總結了多年的客戶上云經驗和最佳實踐，輸出了自己的云采用框架方法論，并且編寫了這本云采用框架白皮書。該書不僅從 IT 管理的角度闡述了如何合理規劃、使用和管理云資產以及構建合規、敏捷和

8、高效的企業 IT 服務體系；同時也從業務的視角描述了對云計算給企業帶來的核心價值，比如有效利用云的標準服務模版來實現業務應用快速在云端落地、通過有效的成本和資源監控降低企業業務經營風險，使用云上自動化工具和方法提升企業敏捷開發和運維的能力和文化。未來，云計算將無處不在，企業對云使用要求也越來越高，阿里云的云采用框架將作為企業云治理的標準方法，助力企業管好云、用好云。袁千 阿里云國際事業部負責人 云采用框架白皮書 文檔版本：1.0 8 法律聲明 本文檔的版權歸阿里云所有，您應當通過阿里云網站或阿里云提供的其他授權通道下載、獲取本文檔，且僅能用于自身的合法合規的業務活動。一、文檔使用及更新說明 1

9、.1 本文檔僅作為用戶使用阿里云產品及服務的參考性指引，阿里云以產品及服務的“現狀”、“有缺陷”和“當前功能”的狀態提供本文檔。阿里云在現有技術的基礎上盡最大努力提供相應的介紹及操作指引，但阿里云對本文檔內容的準確性、完整性不作任何明示或暗示的保證。1.2 由于產品版本升級、調整或其他原因，本文檔內容有可能變更。阿里云保留在沒有任何通知或者提示下，對本文檔的內容進行修改的權利，并在阿里云授權通道中不時發布更新后的文檔。您應當實時關注用戶文檔的版本變更，并通過阿里云授權渠道下載、獲取最新版的用戶文檔。二、知識產權聲明 本文檔中的材料和信息，包括但不限于文本、產品、圖片、數據、檔案、建議、資料，均

10、由阿里云和/或其關聯公司依法擁有其知識產權，包括但不限于商標權、專利權、著作權等。非經阿里云和/或其關聯公司書面同意，任何人不得擅自使用、修改、復制、公開傳播、改變、散布、發行或公開發表。三、如何聯系我們 您對本聲明內容有任何疑問和意見，或者您發現本文檔存在任何錯誤，您可以登錄阿里云官網，點擊首頁下方“聯系我們”與我們聯系。云采用框架白皮書 文檔版本：1.0 9 1.背景介紹 1.1.什么是云采用框架 云采用框架為企業上云提供策略和技術的指導原則和最佳實踐，幫助企業上好云、用好云、管好云，并成功實現業務目標。本云采用框架是基于服務大量企業客戶的經驗總結，將企業云采用分為四個階段：上云戰略、上云

11、準備、應用上云和運營治理，并詳細探討企業應在每個階段采取的業務和技術策略；同時，還提供了一系列最佳實踐、文檔和輔助工具，幫助云架構師、云管理團隊等干系人能夠實現組織協同達成目標。ITIL（Information Technology Infrastructure Library）是 IT 服務管理的經典方法論，被企業廣泛采用。ITIL 中核心的概念是 IT 服務，IT 服務是用來支持企業業務發展的技術服務，它的全生命周期包含服務戰略、服務設計、服務轉換、服務運營以及服務的持續改進五個階段，其中：服務戰略階段：定義服務、明確服務的價值以及服務管理與業務之間的關系。服務設計階段：定義服務的目標和要

12、素、模型和風險，定義管理服務的流程。服務轉換階段：提供發展和改進能力將服務交付到運營階段。服務運營階段：在服務交付和支持中保證效率和效果，為客戶提供價值。云服務是當下最流行的 IT 服務之一，云服務的采用應遵循上述生命周期。我們的云采用框架就是以這樣的理論體系為指導，定義了企業引入云服務的四個階段：在上云戰略階段，領導層需要思考上云能為業務帶來什么價值，并在公司層面確定戰略。在上云準備階段，IT 團隊需要制定云采用的頂層設計，確保組織協同和可管可控。在應用上云階段，開始遷移原有的系統上云或者在云上開展新的業務。在運營治理階段，企業不斷發現和解決運營過程中的問題和風險，提升服務質量。云采用框架白

13、皮書 文檔版本：1.0 10 2.上云戰略 2.1.企業上云的主要動機 概述 明確上云動機是制定企業上云戰略的第一步。本章將討論企業上云背后不同種類的動機，以及和這些動機相匹配的業務產出。企業上云動機的分類 我們可以根據上云的業務對上云動機進行分類。如果上云的業務是一個在云下已經存在的業務，那么上云主要是把云下的應用遷移到云上，這稱為業務遷移上云。如果上云的業務是一個新構建的業務，首次部署運行就在云上，這稱為業務創新上云。業務遷移上云 業務遷移上云是最為常見的一類上云動機，也是云計算技術商業化后最早期的企業普遍采用的上云方式。業務遷移上云的主要目的是：加速資源的交付效率，提高對業務需求的反應速

14、度 傳統 IDC 采購周期從一個月到幾個月不等。如果涉及到出海，對于企業來說 IDC 的規劃甚至長達數年，而云上資源的交付效率近乎實時。降低成本 云計算將 IT 資產的成本由傳統的 Capex 資產折舊模型轉變為 Opex 的按量付費模型。這樣做一方面減少企業的一次性 IT 投入，另一方面也可以讓企業按需購買需要的資源，以節省成本。使用云提供的最新技術 云采用框架白皮書 文檔版本：1.0 11 云廠商通常在產品技術的投入非常大。因此，云廠商提供的云服務通常在行業中比較領先，例如我們常說的云原生服務，如容器、中間件。提高服務的安全性 云廠商提供的是規?；诰€服務。在安全性方面，云廠商有大量的數據

15、能夠幫助客戶更好的應對互聯網上的攻擊。業務創新上云 隨著數字化轉型的浪潮，當前許多企業開始業務創新。云上提供了較為豐富的 PaaS 和 SaaS 服務，因此云也是這部分轉型的最佳選擇。業務創新上云的主要目的是：云上提供豐富的創新能力，例如 IoT、大數據、業務中臺，能夠大幅降低企業業務創新的門檻。需要將業務快速推向新的市場。2.2.上云所需的企業組織模型及其核心職責 概述 企業上云和用云的整個生命周期，需要專業團隊進行合理的規劃、實施以及持續優化云采用方案，推進企業更好的利用上云的優勢促進業務發展。本章討論企業上云過程中所需要的組織模型和對應的核心職責。背景 企業通常至少有一個云管理團隊，或由

16、相關負責人組建一個云卓越中心(Cloud Center of Excellence，簡稱 CCoE)負責規劃和對接上云的整體方案，包括在公司層面確認上云的整體計劃、步驟，以及收集業務團隊的具體需求。了解云卓越中心 CCoE 上云所需的企業組織模型 首先，我們看一下一個典型的企業組織架構。為了便于理解，我們對這個組織結構進行了適當的簡化。在這個架構中，不同的團隊對公司的整體目標進行拆解，例如業務團隊主要貢獻公司的營收、流入目標，財務、法務等團隊對公司的整體運營風險進行控制，產品技術團隊則為業務團隊提供技術支撐。云采用框架白皮書 文檔版本：1.0 12 核心職責 企業采用云服務的過程中有以下核心工

17、作項：上云策略：從公司戰略層面確定企業上云的動機和期望的業務結果。在充分論證企業上云的收益和風險后，最重要的是在公司上下充分傳達和教育，確保公司高層、業務、研發、運維、財務、人力資源等各個相關團隊統一認識，明確上云戰略，各團隊能夠配合做出相應的計劃和調整。制定企業上云計劃，包括業務范圍、上云的計劃節奏、各階段目標以及最終結果。協調各部門準備相應的預算、調配人員和組建必要的團隊。上云準備：準備上云的基礎環境，對云服務進行學習和測試，選擇小規模的業務進行遷移驗證。設計業務上云的整體架構，其中包括遷移方案和基于云技術的創新。規劃業務上云的流程，協調業務部門配合實施業務上云。分階段逐步實施業務遷移上云

18、，并在過程中調整方案，確保業務連續性和穩定性。應用上云：梳理企業應用系統清單，調研應用上云兼容性等相關特征，篩選需要上的云的應用，制定應用的上云策略。持續治理：充分預見和評估企業安全合規等風險，規劃企業 IT 治理的整體方案、策略和基本規則，包括資源結構、身份權限、費用賬單、合規審計、網絡架構、安全策略以及監控規則等。在企業上云和用云過程中，通過治理規則預防、發現和及時治理風險。為了適應云采用框架，組織需要進行以下準備：企業管理層：企業管理層需要明確云在公司的戰略地位以及各個團隊應該如何使用云。云卓越中心：該團隊可以是虛擬的組織，設計提供云服務的模式和管理體系，并提供相應的技術準備。其中的成員

19、包括 o 架構師和專業技術人員，負責上云架構設計和業務上云遷移工作；o 安全、合規等領域專家，負責設計企業 IT 治理方案、預估風險和制定治理規則；o 財務專家，負責制定財務的管理流程，成本分攤原則。云采用框架白皮書 文檔版本：1.0 13 云管理團隊：在企業業務全面上云之后，持續優化上云架構，為新業務提供云上環境。建立企業云上運維體系，搭建運維平臺，以及通過自動化運維的方式，對云上環境進行持續治理和管理。根據新業務需求，分配所需云資源和所需權限，并對資源進行初始化配置后交付。應用運維團隊只需用云，無需關注基礎設施搭建。綜上，平臺運維工作也可細分為架構優化、云平臺建設、資產管理、權限管理、云自

20、動化等多種職責。云采用框架白皮書 文檔版本：1.0 14 3.上云準備 3.1.云上管理和治理框架 Landing Zone 定義 如果把上云框架的搭建比作建設社區，那么企業的中心 IT 團隊就是社區的總設計師。一個好的社區通常具備較為完善的頂層設計，最終才能提供優質服務給社區租戶。社區規劃首先要考慮的是基礎設施的布局和建設，包括道路的規劃、門禁的管理、停車場的布局、樓房規格的規劃等。其次，社區一般也會提供通用服務，例如垃圾分類、水電維修等，以及制定相應的社區規約來管理租戶，例如裝修時間規定、噪音規定。作為增值服務，高檔社區還會提供統一的不同類型的樣板間，比如統一水電、裝修等。在阿里云，我們建

21、議企業在第一個應用上云前，需要有一整套頂層設計和一系列基礎框架，為后續的業務上云掃清障礙。否則，可能會導致后續業務上云面臨成本、網絡、安全、效率等多方面的問題。業界通常把這些基礎框架叫做 Landing Zone，我們也遵循這一命名方法。如上所述，在成熟的運維模型中，通常由企業的中心 IT 團隊負責集中管理和管控，然后將云環境交付到業務團隊。為了高效地提供安全、穩定的云環境，中心 IT 團隊需要搭建一套企業級的管理和治理框架作為云環境的基礎設施，為企業上云打好基礎。例如，某跨國企業使用阿里云支撐公司多個業務系統，其中包含公司的互聯網業務和 ERP，以及內部的 OA等系統，這些系統由不同的團隊負

22、責。為了更高效地使用云，公司成立新的“云管理團隊”負責和云的對接?！霸乒芾韴F隊”的內部定位是公司負責提供云能力的團隊，以此加速 IT 和業務升級。具體而言，“云管理團隊”負責云上資源的快速交付、成本控制、質量保證，同時賦能業務部門在安全的前提下進行創新?！霸乒芾韴F隊”在阿里云提供的 Landing Zone 的基礎上，構建了整個云服務體系。云采用框架白皮書 文檔版本：1.0 15 架構 那么，一個完整的 Landing Zone，究竟包括哪些方面？基于服務眾多企業客戶的實踐總結，我們定義了Landing Zone，其包含如下幾個功能模塊。后面我們將會對這些模塊的設計進行詳細的分解以及舉例說明。

23、下表簡要描述了上述功能模塊。Landing Zone 模塊 描述 資源規劃 規劃云上賬號及其組織結構。根據公司的運維模式，定義所需要的管控關系。財務管理 管理云平臺的合同、優惠、付款關系、賬單，以及認證公司在云平臺的實體、發票抬頭等財務相關的屬性。網絡規劃 規劃云上 VPC 的拓撲結構、混合云網絡的互聯、網絡的流量走向、相關的安全措施，以及如何構建高可用和可擴展的網絡架構。身份權限 規劃誰能夠訪問云，并通過單點登錄 SSO 和細粒度授權實現人員按需訪問。安全防護 通過在云上構建基礎的安全環境，幫助業務系統在云上快速的安全落地。合規審計 設計治理的目標和流程，并通過相應的工具來實現對于治理規則的

24、監督。云采用框架白皮書 文檔版本：1.0 16 運維管理 構建以 CMDB 為核心的運維管理體系，包含標準的發布變更流程，應用和基礎設施的統一監控，集成企業的 ITSM 系統，提供自助服務。自動化 定義自動化場景和目標，并通過相應的工具實現自動化。常見的場景如 Landing Zone 自身的搭建以及 CI/CD 流水線的自動化。3.2.阿里云上 Landing Zone 的主要組成部分 3.2.1.資源規劃 概述 企業在上云過程中采購云資源滿足業務需要，云服務提供商一般會要求企業注冊賬號作為容器來放置和管理云資源。隨著企業上云業務的增多，企業業務自身的復雜度及相互間的關系管理要求更為嚴苛，企

25、業一般會注冊多個賬號來應對問題：借助賬號間的天然隔離性，使用多個賬號實現企業不同業務或應用間的相互獨立。針對業務復雜的大型企業，多個賬號可以解決多法律實體、差異化結算關系等業務訴求。使用多個賬號，可以突破單賬號下云資源服務配額限制等約束。在阿里云，我們建議上云之初就規劃采用多賬號、組織化的資源（賬號）管理架構，通過合理的組織結構和規則配置，以滿足業務日后擴展的需求。資源目錄概述 方案示例 X 公司有多個業務系統，由不同的團隊管理。公司在搬遷上云期間，以賬號為單元來承接一個個業務系統，并按照公司的業務線結構來組織賬號進行管理。每一個應用分為生產、測試環境，用不同的賬號隔離開。業務團隊根據自己管轄

26、的范圍獲得相應的權限。接下來，我們將為您介紹多賬號資源管理體系建立的設計思路與建議。云采用框架白皮書 文檔版本：1.0 17 多賬號結構規劃 設計建議 使用阿里云的資源目錄進行多賬號的統一管理。按照業務的組織架構規劃賬號的組織結構。典型的架構可以選取在根資源夾下創建兩個資源夾：Core、Applications。o 在 Core 資源夾中放置共享服務賬號，用于集中橫向管理類服務的部署，例如共享 VPC。o 在 Applications 資源夾中放置具體的應用。使用資源夾作為日后管控策略和基線實施單元。企業管理賬號為資源目錄的超級管理員，建議不要將其用于資源目錄管理之外的其他任何用途。妥善管理此

27、賬號，并設置 MFA 雙重驗證，加強安全訪問管理措施。使用成員賬號代表一個應用。建議通過角色扮演的方式訪問成員賬號。特殊限制 阿里云支持角色扮演方式訪問的產品 使用標簽描述資源 標簽是對資產進行分類的簡便方法。標簽將元數據關聯到資產。該元數據可用于基于各種數據點對資產進行分類。當使用標簽對資產進行分類作為成本管理工作的一部分時，公司通常需要以下標簽：業務部門，部門，計費單元，地理位置，環境，項目或“應用程序分類”。阿里云費用中心的“分賬賬單”可以使用這些標記創建成本數據的不同視圖。設計建議 提前定義標簽的目錄和取值范圍。綁定標簽的背后是一個流程，因此提前設計好如何綁定標簽非常重要。明確標簽的使

28、用場景。我們建議使用標簽用于包括但不限于如下場景：o 使用標簽描述應用：一般情況下，組織可根據日常管理層級構建資源歸屬的標簽組合。組合形式一般不會超過 3 個標簽。例如，某企業為了能夠快速找到對應資源，設計如下標簽：云采用框架白皮書 文檔版本：1.0 18 project：描述資源項目歸屬。env：描述資源環境信息。user：描述資源持有者信息。o 使用標簽進行分賬：阿里云費用中心的“分賬賬單”支持按標簽細分阿里云成本的功能。最常見的情況，客戶可以使用成本中心（costcenter）、業務單元（businessunit）或者項目組（project）將成本與業務部門進行關聯。在分賬賬單中，費用報

29、告可以以任何標簽維度歸納賬單。因此，客戶也可以輕松地將成本與技術/安全性維度作為分賬維度，例如特定應用程序（application）、環境（env）等。o 自動化運維和監控：自動化運維/自動化開通是在日常業務中比較常見的場景。技術人員往往通過一類標簽來定義批量運維、檢測的策略。例如：某公司為其日常巡檢進行了標簽化，創建用途標簽鍵 purpose 來進行日常資源巡檢，標簽值為 autocheck-8am，即每日早 8 點自動巡檢。如果巡檢發現異常，通過資源持有者標簽 owner 來通知具體責任人進行處理。建立標簽的巡檢機制，及時發現沒有綁定標簽的云產品并評估影響和制定應對策略。特殊限制 阿里云支

30、持標簽的產品 3.2.2.財務管理 概述 財務管理通常指合同、資金、發票、賬單等方面的管理。財務管理是企業上云后面臨的第一個問題。通常云廠商會提供較為通用的功能來滿足大部分企業的需求，企業則需要根據自己的組織模式選擇最優的商業關系。企業在這個階段遇到的常見問題是：公司如何統一的管理和云廠商的合同、付賬、發票？公司如何能夠集中監控成本？例如，X 公司選擇“云優先”的戰略，逐漸將各個業務遷移上云。在出臺統一的財務規劃之前，部分業務已經先行上云，單獨和云廠商簽訂云服務。在確定“云優先”的戰略后，公司針對云廠商制定了統一的財務管理方式，由原來的分散管理模式，改為由公司整體和云廠商簽訂合同和結算，以便于

31、整體的管理和成本核算。對于不同業務，由業務部門申請相應預算和云賬號進行云資源的購買。每個月公司對不同業務使用的云資源的費用進行統計，將成本分攤到不同的業務。在每個月的成本會議上，成本信息會同步到各個業務負責人以及CFO。對于超出預算的業務，業務部門會及時調整預算或者優化成本。財務管理的成功實施，通常要考慮企業財務組織結構、商務合同優惠、結算模式、預算管控等。下面將對這幾個方面逐一闡述。企業財務組織結構 云采用框架白皮書 文檔版本：1.0 19 企業財務組織結構，通常代表一家企業的成本管理結構。這個結構是多層級的，包括財務管理部門、業務部門和云資源。財務管理部門負責評估和管理云業務預算，為業務部

32、門的云上費用做統一結算，持續跟蹤和分析消費賬單。財務管理部門的職責通過財務管理部門賬號來承載。業務部門負責在預算范圍內開通和管理云資源。每個業務部門開通獨立的云賬號。云資源由業務部門開通和管理，歸屬于相應的業務部門賬號下。使用企業財務服務提供的關聯賬號能力，將組織多層級結構搭建起來。在這種結構下，財務人員能清晰完整地了解整個企業的云上成本，便于進行消費預測和成本優化。業務部門的技術人員在預算范圍內可以靈活地按需實時開通云資源，省去傳統企業繁瑣的資源申請流程，提升了工作效率。各企業的內部組織結構雖然不盡相同，但業務部門可以同時是項目或小組等成本管理的單元，可以按照自己的組織模式映射成上述結構。我

33、們的建議 財務人員需要與業務部門加強溝通，及時收集業務部門的資源采購計劃，定期向業務部門同步成本分攤信息。財務人員需要持續關注費用趨勢。財務人員設計標簽分類，鼓勵技術人員在開通云資源時綁定對應標簽，便于基于標簽做細粒度的分賬。技術人員按需開通資源，在預算范圍內優化資源結構。特殊說明 目前阿里云企業財務支持標準企業兩級財務管理結構。對于集團公司，當前無法直接滿足集團-子公司-部門的三級財務管理結構，需要按照子公司維度拆分成上述多個組織結構分別管理。在企業財務中，財務部門管理賬號又稱為“主賬號”，業務部門賬號又稱為“關聯子賬號”。更多信息，請參見企業財務概述。商務合同優惠 商務合同優惠，指企業與云

34、廠商簽訂的商務優惠合同條款中約定的折扣。云采用框架白皮書 文檔版本：1.0 20 企業與云廠商簽訂商務優惠合同時，需要將財務部門管理賬號（主賬號）設置為折扣生效的目標賬號。這么做的好處是，業務部門賬號的開通和云資源的消耗，結算時可以享受到主賬號的折扣優惠。結算模式 在企業財務組織結構中完成多層級賬號關系的搭建，設置由主賬號統一結算，省去各部門獨立結算開票的繁瑣操作。上圖是某企業 10 月份的費用結算圖。財務部門管理賬號（主賬號）有 4 個關聯子賬號。在 10 月份結算周期內，財務人員可以從系統中看到各部門的費用賬單和明細，最終由財務人員統一結算并開具發票。企業財務賬號關聯包括兩種業務模式：財務

35、管理、財務托管。這兩種模式的能力對比如下：合同優惠共享 賬單統一查看 合并發票 統一付款 關聯子賬號使用代金券 財務管理 財務托管 關于企業財務業務模式的更多介紹，請參見：企業財務概述。特殊說明 財務管理模式下，不支持為所有子賬號的消費合并開一張發票。需要篩選子賬號，為指定子賬號的消費開票。財務管理模式下，只有當主賬號申請了阿里云信控身份，并且將信控身份同步給關聯子賬號時，主賬號才可以為子賬號歷史消費賬單實現統一付款。財務托管模式下，暫不支持關聯子賬號使用代金券。如果子賬號要做 POC（Proof of Concept）測試，目前只能將代金券發放給主賬號，且發放給主賬號的代金券可能被其他子賬號

36、消費而自動沖抵。預算管控 云采用框架白皮書 文檔版本：1.0 21 預算管控有強管控和弱管控兩種方式。企業可以根據自己的實際情況進行選擇。強管控要求業務部門必須在預算內開通和使用資源，超出預算將無法開通新資源，已開通的資源也需要在申請追加預算后才能繼續使用。弱管控是一種預警機制，為業務部門分配 quota（配額）額度，對額度做預警通知。即便業務部門的消費已超出額度，也不影響資源的開通和使用。特殊說明 財務托管模式，尚且不支持預算管控。財務管理模式支持強管控方式。主賬號可通過信控劃撥或余額劃撥的能力，為子賬號劃撥可消費的信控額度或現金余額。子賬號信控或余額已用完時，將無法開通新資源或進行升級操作

37、，已開通的資源也將受停機影響，需要聯系主賬號申請追加預算。3.2.3.網絡規劃 概述 企業業務上云需要有一個可擴展、安全可控的網絡環境。公共云的網絡環境與線下 IDC 類似，也是使用 IP地址段作為基本單元劃分不同的網絡空間，公共云一般以 VPC 為基本單元，每個 VPC 使用一個 IP 網段，若干個 VPC 組成企業云上整體網絡空間。由于相同 IP 地址不能互通和 IPv4 地址空間相對較小兩個限制，企業在進行上云早期規劃時，需要提前做好網絡規劃，保證網絡能夠承載企業存量業務的同時，能夠具備高可靠和可擴展性，以保證業務的穩定和未來的系統擴容和升級。關鍵步驟 在網絡規劃，有三個關鍵步驟需要決策

38、：1.一是確定所使用的地域，按照業務屬性劃分若干個 VPC 和各自使用的 IP 地址段。比如，使用阿里云上海地域，共分成 5 個 VPC，分別用來承載公網出入口、官方網站生產環境、官方網站 UAT 環境、內部 CRM 系統生產環境和內部 CRM 系統 UAT 環境。各自的 IP 地址段分別為 10.0.0.0/24、10.0.1.0/24、10.0.2.0/24、10.0.3.0/24 和 10.0.4.0/24。2.二是規劃不同 VPC 間的互通、隔離邏輯，決定不同資源之間的路由、安全組或 NACL（Network Access Control List）規則。3.三是確定云上線下環境互聯的

39、方式。如果企業有混合云需求，需要確定使用的上云連接方式，比如物理專線、SDWAN、VPN 等。網絡規劃方案 網絡規劃的主要場景有云上網絡架構設計、云上云下網絡互通、云上企業內部網絡互通、云上企業間私網訪問等，以下將展開說明。云采用框架白皮書 文檔版本：1.0 22 場景一：云上網絡分區 用戶業務系統搬站上云，需要考慮業務系統之間的調用和訪問關系，需要關心路由邊界，需要關心未來的規模擴展，實現最合理的分區設計、最簡單的運維管理、最靈活的彈性擴展。每個分區可以由一個獨立的 VPC 承載，VPC 內按照部署的業務模塊選擇創建不同的虛擬交換機（子網），不同業務系統之間的互通即不同 VPC 之間的路由打

40、通，可以使用云企業網 CEN 打通，同時可以按需進行路由表隔離、路由過濾、路由策略設置等，來滿足企業用戶的個性化需求。按照使用習慣和業務訪問關系，常見的分區有：業務生產區、開發測試區：這兩個區域分別用于承載客戶生產環境和測試環境的資源?；ヂ摼W出口區：這個區域類似于線下 IDC 中的 DMZ 區，用于承載互聯網出口資源，如 EIP，NAT 網關，SLB，云防火墻等資源。東西向安全區：用來承載南北向防火墻或其他云上 IDS/IPS 防護設備。內聯運維區：用來承載跳板機，堡壘機等企業內部人員連接云上環境入口的資源。外聯網區：用來承載連接第三方 IDC 等外部環境的跳板機，堡壘機的入口資源。場景二：本

41、地網絡和云上網絡的連通 云采用框架白皮書 文檔版本：1.0 23 在云上構建新的業務系統時，也需要考慮和線下已有的網絡進行打通，滿足兩方面的需求：業務搬站或系統遷移過程中，需要有大帶寬、穩定、安全的網絡通道。企業用戶都會選擇先把前置系統優先上云，比較重要的業務系統仍放在云下，一方面需要一個過渡，另一方面利舊云下已投入的 IT 資源，所以混合云狀態會長期存在。線下分支機構會有和總部辦公室、企業 IDC 之間的內網互通需求，當業務逐步上云后，會涉及到線下分支既需要和線下總部互通，也需要和云上互通。那最好的方案便是打通一張覆蓋云上云下多地域的內網，同時確保每兩點之間直接互通，不出現繞行。按照云下網絡

42、環境的定位、規模和與云上系統的關系，推薦不同的互通方式：IDC 和大型企業總部：推薦使用物理專線互通。針對集團性企業，云下 IT 資源大多在一個大的機房內，通過物理分區或者邏輯分區隔離不同子公司之間的網絡，但云上是不同的賬號（賬號間完全獨立），此時可以由集團統一部署大帶寬的專線，通過路由子接口和 VLAN 映射的方式把專線分成多個二層通道，每個二層通道關聯一個 VBR（虛擬邊界路由器），不同的 VBR 供不同的子公司使用，這樣不僅資源共享投入產出比高，而且子公司之間的三層網絡完全隔離。關于物理專線連接的更多信息，請參見專線介紹。企業分支和小型總部：推薦采用智能接入網關 SAG，通過 SAG 就

43、近入云，打破地域限制，覆蓋各種分支形態，形成云上云下一張內網。因為阿里云提供非常多的 POP 接入點，所以分支最后一公里（采用VPN 加密通道）的距離會很短，長傳全部走阿里云內網，端到端網絡質量僅次于專線，但是價格接近VPN。關于智能接入網關 SAG 更多信息，請參見什么是智能接入網關。特殊分支：針對不方便部署 SAG（如海外偏遠分支等）、企業想利舊資產等情況，通過 VPN 網關快速和云上內網打通。雖然效果不如智能接入網關 SAG，但是可以讓偏遠的分支先解決內網互通的訴求。關于 VPN 網關更多信息，請參見 VPN 網關。云采用框架白皮書 文檔版本：1.0 24 場景三：企業內網絡互通和隔離

44、因業務發展需要，子公司的業務系統需要和其他子公司或集團業務系統路由互通，但又不能影響其與公司內部其他業務系統的正常通信和安全策略。方案 1：使用 CEN 連接多個 VPC 當企業在不同業務賬號中使用 VPC，可以讓該 VPC 同時可以接入多個 CEN（可以是同賬號的 CEN，也可以跨賬號的 CEN），此時該業務系統的網段路由就可以在不同 CEN 的路由域里面，實現按需路由互通，且相互不影響。這樣做的好處是：1）簡單方便：無需改動業務架構，無需復雜的規劃，只需要有一個加入的動作，即可實現異構路由域的快速互通，且不影響已有訪問關系。2）邊界清晰：VPC 的資源歸屬未發生任何變化，只是在路由層面進行

45、了網絡通道的打通。方案 2：使用共享 VPC 采用共享 VPC，提供一個共享的私有網絡環境，參與的業務團隊各自部署資源，可以同時解決基礎網絡互通、資源獨立、資產獨立等問題。使用效果：1）方便分賬：各子公司可以自己購買資源，共享 VPC 一方提供平臺和共享資源（如 NAT、VPN、公網出口等）。2）快速滿足業務需求：各子公司的資源部署在統一 VPC，路由天然互通。云采用框架白皮書 文檔版本：1.0 25 多賬號 VPC 的 CEN 互聯和共享 VPC 的對比：特性 共享 VPC 方案 多帳號跨 VPC 互聯方案 連通性 同 VPC 內天然路由互通。不同 VPC 之間天然路由隔離，使用CEN-TR

46、 進行路由配置。隔離性 使用 NACL 和安全組規則進行隔離。除了使用 NACL 和安全組之外，還可以使用 CEN-TR 進行路由層面的隔離。高級功能 無 可以通過安全VPC設置統一的東西向安全設備來提升內網安全級別。成本 同 VPC 內無收費項。同 region 使用 TR 互聯，TR 按加載的實例數和實例之間的流量收費。運維 較簡單 較簡單 云采用框架白皮書 文檔版本：1.0 26 使用限制 默認單個VPC內可創建24個不同帳號的 VSW。默認單個TR最多連接同region內200個TR Attachment（VPC/VBR/CCN）。場景四：公網出口及南北向網絡安全管控 隨著企業業務云化

47、進程逐漸進入深水區，簡單地使用云上資源出公網已經無法滿足業務的訴求，安全、成本、權限、監控等訴求的迭代，需要企業有系統性的視角來考慮如何做好公網出口的規劃設計：安全：統一 DMZ-VPC 設計，對于企業/集團內的公網出入訪問有嚴格的訪問策略加以控制，同時具備可監管能力。成本：所有公網 IP 需具備共享一份或多份帶寬的能力，提升帶寬利用率，滿足業務訴求的情況下做到成本最優。權限：由于組織架構及智能原因，在安全部門的要求下，IT/架構團隊需要統一管控公網準入/出權限。各業務方需向 IT 申請才能開通公網訪問權限。監控：統一監控，內網/外網訪問情況做到可視可追溯，便于及時排查異常流量原因。在企業安全

48、、成本、權限、監控等訴求的迭代下，云上公網出口方案逐漸從原來的分布式公網出口演進為統一公網出口。前者適合企業上云初期，各部門/業務團隊可按需使用 EIP/NATGW/SLB 進行各自的公網出口部署，自動度和靈活性較高，同時也帶來了企業的云上安全和管理隱患問題；后者將公網出口進行統一部署、統一管理、統一監控、統一安全策略部署，更能滿足企業云上的整體監管要求。簡單場景統一公網出口架構設計 云采用框架白皮書 文檔版本：1.0 27 WAN 區域設計 1）DMZ-VPC 設計：將企業云上整體的 WAN 能力均放在共享服務的 DMZ-VPC，該 VPC 內可按需部署 NATGW、Proxy、FW、行為管

49、理等公網產品。2）安全設計：聯動 DDos、WAF、云防火墻等原生安全產品，保障公網出口安全，并結合 NACL實現安全訪問策略。3）成本優化：啟用共享帶寬，并將所有 EIP 加入其中，節約成本。4）權限劃分：利用將公網能力統一收口至 IT 部門，部署 DNAT+SNAT，業務 VPC 均通過 CEN實現跨 VPC 訪問公網。5）監控管理：使用 NATGW+Flowlog 組合能力，監控公網出入口流量信息，并根據異動排查原因。統一公網出向設計 統一公網出：使用增強型 NATGW，并開啟跨 VPC 訪問 NATGW 能力。統一公網入向設計（可選）1）統一公網入：使用 DNAT+SLB（私）的方式。

50、2）獨立公網入：適用個別業務獨立性較強、一定規模的 Web/APP 服務，可在所屬的業務 VPC中結合大規格 SLB/ALB 獨立部署公網入口。復雜場景統一公網出口架構設計 云采用框架白皮書 文檔版本：1.0 28 隨著企業云上業務的發展，對于公網訪問的場景和功能的豐富度也會增加，包含基礎公網能力、第三方供應商 API 接口調用、指定域名訪問出口等能力實現。本方案設計 3 個設計點，默認公網出口、第三方供應商 API 接口調用的特殊公網出口，以及指定域名訪問出口，均部署在統一出口區域 DMZ-VPC。默認公網出口 在DMZ-VPC內部署增強型NATGW，并申請“統一網絡出口”權限開通跨VPC訪

51、問功能DMZ-VPC公網能力，實現統一公網出口。賬號-1和賬號-2的APP-VPC均可通過DMZ-VPC的默認NATGW的SNAT策略出局訪問公網，同時并通過 DNAT 策略實現跨 VPC 的公網入口效果。第三方供應商 API 接口調用的特殊公網出口 在 VPC 已有默認 NATGW 的情況下，由于第三方供應商 API 接口調用時需要雙方互相針對 IP 地址加白名單，且出口獨立性較強，不能影響其他業務或被其他業務影響，需于 DMZ-VPC 再部署一個特殊的 NATGW，將三方目標網段路由給此 NATGW，實現特殊出口。賬號-2 VPC 中的 ECS 訪問常規公網時從默認 NATGW 出口出局，

52、調用第三方供應商 API 時從特殊公網出口出局。指定域名訪問出口 云采用框架白皮書 文檔版本：1.0 29 使用 SLB+EIP（ECS）+PrivateZone 方式實現特殊域名出口，將需要指定出口訪問的域名部署在 PrivateZone 中并應用于本 VPC。當業務訪問指定域名時，會被 PrivateZone 自動解析為 DMZ-VPC 的特殊域名出口的 SLB 私網IP，通過代理的方式從后端服務器的公網出口出局。下面我們將通過一個案例，為網絡規劃做一個整體性的介紹。方案示例 客戶背景和業務系統 客戶 X 公司是一家大型企業客戶，企業內部各種 IT 應用系統眾多，其中部分業務放在云上，如

53、CRM、文件服務、API 服務等。企業核心數據部分仍然部署在線下 IDC 中，需要云上業務系統能夠訪問到線下 IDC 中的數據?？蛻粜枰鉀Q的問題 需要建立云上線下之間的高可靠混合云連接。根據業務需求為每個應用建立隔離的虛擬網絡和對應的賬號。部分業務支持 Internet 公網訪問及流量審計。東西向網絡安全防護。阿里云網絡解決方案介紹 X 公司采用了阿里云標準的企業級云網絡解決方案架構，所有云資源都使用中國香港地域部署，與線下 IDC保持一致。公司按照業務應用劃分賬號：3 個業務生產賬號、3 個業務測試賬號。VPC 方面，分別是接入層 3 個公共服務的 VPC、3 個生產 VPC 和 3 個測

54、試 VPC?；旌显七B接方面，線下 IDC 使用 2 條物理專線與公共云 VBR 打通，兩條專線通過 BGP 路由協議實現主主冗余。所有 VPC 和 VBR 都使用云企業網轉發路由器連接到一起，確保轉發路由器可以自定義 VPC和 VBR 之間的互通路由。網絡安全方面，公網出入口的安全審計通過 DMZ VPC 中的第三方防火墻實現，云網絡架構可以實現將所有進出企業云上網絡的公網流量通過統一的云原生或第三方安全設備進行過濾。內網東西向流量的安全防護通過安全 VPC 中的第三方防火墻實現，阿里云網絡在國內云廠商中率先提供的路由穿透功能，可以實現將企業網絡東西向流量進行統一管控，節省了分布式部署的成本支

55、出，同時大大降低了運維復雜度。解決方案架構圖 云采用框架白皮書 文檔版本：1.0 30 3.2.4.身份權限 概述 身份管理和訪問控制是 Landing Zone 的基礎模塊之一。在企業在上云之初，應該首先考慮如何設計和落地身份管理和訪問控制方案，而不是創建云資源。這樣做的好處是：確保對云資源的任何訪問都使用適當的身份，且每個身份擁有“最小夠用”（既不過大，也不過?。┑臋嘞?。確保從不同網絡環境、設備、地理位置發起的對云資源的訪問都是安全的。當身份、權限發生變化（如新增用戶，用戶職責發生變化，員工離職、轉崗等）時，可以做到持續管理，降低配置難度和管理成本，避免信息泄漏、誤操作等風險。在阿里云，我

56、們使用訪問控制（RAM）等產品和服務來實現身份管理與訪問控制的能力。RAM 概覽 方案示例 在上云規劃過程中，X 公司識別出有下列身份需要對云資源進行訪問。身份類型 權限需求 超級管理員 10 人的云管理團隊，其成員需要擁有對云治理服務（如身份、權限、資源、合規、安全、網絡、監控、備份等）的管理權限，無需擁有對計算、存儲等業務所需資源的直接管理權限，但在需要時可以接管控制權。該團隊還可以細分為財務管理員、安全合規管理員、網絡管理員、數據庫管理員等角色，側重于云治理框架中某一方面的管理工作。云采用框架白皮書 文檔版本：1.0 31 企業員工 各業務團隊成員，他們需要使用歸屬于本部門的云資源進行開

57、發、測試、運維等工作，一般不允許訪問其他部門的資源，但如果出現跨部門合作，也應該可以被授權訪問其他部門的資源。企業外部人員 部分業務團隊，需要合作伙伴獲取本部門少量資源的讀寫權限。企業客戶 有些業務部門開發的應用提供代客戶保存數據的服務，其業務場景需要允許客戶直接訪問由客戶上傳，但保存在企業的云存儲中的數據。為了滿足上述需求，X 公司按照“最小夠用”原則，對所有身份進行精細化權限管理：對于超級管理員、企業員工 使用 RAM 的“單點登錄”（Single Sign On,SSO）功能，將阿里云身份系統與企業自有身份系統打通，實現單點登錄，并要求所有訪問云資源的超級管理員、企業員工等使用 SSO

58、登錄阿里云。對于企業外部人員 o 長期使用者，在企業身份系統中創建用戶，采用同樣的單點登錄措施。o 臨時使用者，在需要訪問的云賬號中創建 RAM 角色并授予帶時間限制的有限資源訪問權限，允許其使用自己持有的云賬號進行角色切換登錄。對于企業客戶 每次客戶需要訪問云資源時，由企業應用程序為其生成短時有效的安全訪問令牌（STS Token），供客戶在應用程序內使用。我們用一個圖更直觀地說明上述精細化權限管理方案。云采用框架白皮書 文檔版本：1.0 32 其中，身份集成部分的設計邏輯如下圖所示。方案設計思路 下面我們詳細說明身份管理和訪問控制模塊的設計思路。身份管理 針對超級管理員、企業員工和需要長期

59、使用企業云資源的外部人員，應使用企業自有的身份系統，以外部身份憑證登錄阿里云。與只使用由云平臺頒發的身份憑證相比，這樣做有著諸多優勢，包括：企業員工可以使用同樣的用戶名和密碼登錄企業自身應用和云平臺。根據用戶在企業身份系統中的指定屬性，例如：根據其所屬的組，來對應在云上不同賬號、不同資源的操作權限。當員工轉崗、離職時，只需要在本地進行轉移組、刪除等操作，即可解除其在云上的權限，不會造成信息泄露。云采用框架白皮書 文檔版本：1.0 33 在各類外部身份憑證中，最常用的是由企業自有的身份系統（Identity Provider,IdP）提供的基于 SAML 2.0協議的身份憑證。阿里云提供基于 S

60、AML 2.0 協議的 SSO 能力，以滿足企業使用外部身份憑證登錄阿里云的需求。根據登錄后轉換成的云平臺身份不同，SSO 又可以分為用戶 SSO 和角色 SSO 兩種。詳細信息，請參考 SSO 概覽。我們建議企業客戶使用角色 SSO，并將企業 IdP 中的用戶組映射到阿里云 RAM 角色，從而實現對企業內外部員工的有效管理。下面簡要介紹企業對使用云資源的人員進行身份集成管理的工作模式。準備自有 IdP 企業需要首先準備自有 IdP，才能完成 SSO 配置。企業應做如下考慮：如果企業已經具有支持 SAML 2.0 協議的身份管理系統，如 Azure AD，ADFS 或企業自建 IdP，可以直接

61、用來與阿里云 RAM 進行 SSO 配置。對跨國企業、除云資源外還有其他云上應用需要訪問的企業、需要與釘釘進行集成的企業等，可以考慮購買 Okta、阿里云 IDaaS 服務等云上 IdP 服務。對希望快速搭建 IdP 并開始使用的企業，可以考慮用開源軟件如 KeyCloak、Shibboleth 搭建 IdP，也可以參考簡單的開源實現。上云初期的一次性配置 在上云初期，企業需要進行一次性的初始化身份集成配置，主要步驟包括：1.在 IdP 配置一個與阿里云進行角色 SSO 的應用。2.為該應用分配使用的用戶和用戶組。3.根據阿里云角色 SSO 配置要求進行 SAML 屬性配置。4.在每個阿里云賬

62、號中配置身份提供商。5.測試配置結果。新增或移除阿里云賬號時的配置 在企業新增或移除阿里云賬號時，需要相應進行 SSO 配置修改，包括如下：根據 IdP 的 SAML 屬性配置方式不同，可能需要進行配置修改，或重新分配用戶與用戶組。在新增賬號中配置身份提供商。在移除賬號中刪除身份提供商。人員變動時的配置 當企業發生訪問云資源的人員配置（新增用戶，刪除用戶，變更用戶權限）時，通常不需要進行 SSO 配置修改，只需要對用戶和用戶組進行操作，包括如下：云采用框架白皮書 文檔版本：1.0 34 新增用戶時，應在 IdP 中將其加入到已經配置了 SSO 訪問的用戶組。刪除用戶時，可以直接刪除即可，IdP

63、 通常會自動移除其訪問權限。用戶權限發生修改時，應修改其用戶組配置。訪問控制 阿里云實現了基于屬性的訪問控制（Attribute Based Access Control,ABAC），這是一種權限描述能力強，可感知訪問上下文以進行精細權限管理的先進訪問控制機制。當客戶請求到達阿里云時，阿里云將評估當前訪問的請求特征、身份特征、資源特征，并與身份所配置的權限進行匹配，從而完成鑒權。每個云產品支持的身份和訪問控制粒度可以參見支持 RAM 的云服務和支持 STS 的云服務。針對大部分人員用戶來說，可以根據其職責進行較粗粒度的權限劃分即可，一個企業通常針對如下幾種角色進行權限設計：全局云管理員：擁有企

64、業在阿里云上資源的全部權限。網絡管理員：擁有對各類網絡產品的管理權限。數據庫管理員：擁有對各類云上數據庫的管理權限。監控管理員：擁有云監控、應用實時監控等服務的管理權限。安全管理員：擁有全部安全產品的管理權限。合規管理員：擁有合規相關產品的管理權限。日志管理員：擁有日志服務的管理權限。日志查看者：擁有讀取日志的權限。應用管理員：只擁有某個應用所對應的資源權限。普通用戶：不具備任何云上資源訪問權限，只在必要時進行單個權限點授權。同時，還需要根據人員訪問條件進行限制：所有人員必須在企業內網訪問云資源（使用 IP 限制策略）。對于臨時身份，同一種應用場景可以只使用一個 RAM 角色，但針對每個會話授

65、予單個資源、具有訪問時間限制的權限，以確保權限最小化。說明 在進行角色 SSO 配置前，需要了解企業所使用的云產品是否支持 STS（即 RAM 角色訪問），如果有不支持角色訪問的產品，可能需要進行特殊考慮，如使用額外的 RAM 用戶訪問此類產品，或配置用戶 SSO 等。最佳實踐 RAM 角色集成企業 AD FS 身份認證 RAM 角色集成企業 OpenLDAP 身份認證 云采用框架白皮書 文檔版本：1.0 35 3.2.5.安全防護 概述 Landing Zone 的安全架構主要包括：訪問控制（這部分內容已在“3.2.4 身份權限”章節中描述）網絡安全 計算安全 數據安全 通過在云上構建基礎的

66、安全環境，幫助業務系統在云上快速且安全地落地，如下圖所示。1.網絡安全 阿里云上的網絡區域通常是以層次化的方式由外部向內部進行劃分的，概括來說，通常會有三個層級的網絡區域結構：第一層級（地域與可用區）第二層級（虛擬專有網絡 VPC）第三層級（子網與資源邊界）云采用框架白皮書 文檔版本：1.0 36 基于阿里云上三個層級的網絡區域，自然也就形成了云上三道網絡邊界，也就是網絡安全中常見的“層次化防御”的推薦架構：第一邊界：互聯網邊界（南北向流量）云上業務如果對互聯網開放，或是需要主動訪問互聯網，那流量必定會穿過阿里云與互聯網的邊界，也就是云上網絡的第一道邊界互聯網邊界。對于該類流量，我們通常稱之為

67、南北向流量。針對這類流量的防護，在等保中有明確的要求。由于存在流量主動發起方的區別，防護的重點一般也會區分由外向內和由內向外的不同流量類型。第二邊界：VPC 邊界（東西向流量）VPC 是云上最重要的網絡隔離單元，客戶可以通過劃分不同的 VPC，將需要隔離的資源從網絡層面分開。但同時，由于業務的需要，部分流量又可能需要在 VPC 間傳輸，或是通過諸如專線、VPN、云連接網等方式連接 VPC，實現 VPC 間應用的互訪。因此，如何實現跨 VPC 邊界流量的防護，也是云上網絡安全很重要的一環。第三邊界：云資源邊界（微隔離流量）由于 VPC 已經提供了很強的隔離屬性，加上類似安全組的細顆粒度資源級管控

68、能力，通常在 VPC 內部不建議再進行過于復雜的基于子網的隔離管控，通常會使用安全組在資源邊界進行訪問控制。如果客戶需要更精細化的 VPC 內子網隔離，也可以使用網絡 ACL 功能進行管控。云采用框架白皮書 文檔版本：1.0 37 2.計算安全 云上計算安全維度一般包含云主機安全和云容器安全：云主機安全 防護重點 1：入侵檢測 阿里云用戶可以通過云安全中心為用戶提供的實時入侵檢測能力，對異常登錄、網站后門查殺（Webshell）、主機異常行為、主機系統及應用的關鍵文件篡改和異常賬號等行為進行檢測。同時，云安全中心還提供智能學習應用白名單的能力，識別可信和可疑/惡意程序形成應用白名單，防止未經白

69、名單授權的程序悄然運行，可避免主機受到不可信或惡意程序的侵害。防護重點 2：病毒檢測 對主流勒索、挖礦、DDoS 木馬等病毒的實時攔截能力，由云安全中心提供：在系統內核層面實現云上文件和進程行為的全局監控和實時分析，有效繞過頑固木馬和惡意程序的反查殺能力 基于程序行為分析，挖掘出黑名單未能辨識的惡意威脅，實現主動攔截 云端病毒庫實時更新，集成了國內外主流殺毒引擎、阿里云自研沙箱和機器學習引擎等前沿技術，可以避免因病毒庫更新不及時而造成的損失。防護重點 3：漏洞管理 阿里云用戶可以通過在主機上安裝輕量級安全代理，實現和云端安全中心聯動，提供最新的漏洞掃描的安全能 力，幫助用戶實現同時對多個系統和

70、應用進行掃描和修復的安全運維工作。目前已支持檢測主流 Windows 系統漏洞、Linux 軟件漏洞、Web-CMS 漏洞、應用漏洞，同時還能為官方未能提供補丁的應用提供應急漏洞修復，以及臨時提供針對網絡上突然出現的緊急漏洞的檢測和修復服務。防護重點 4：OS 和鏡像加固 阿里云自研的 Aliyun Linux 2 OS 已經發布了經過國際第三方 Cyber Internet Security（CIS）組織認證的 OS Benchmark。用戶可以遵循 CIS Benchmark 中的安全最佳實踐（Remediation）操作規范來對 OS 進行安全加固，也可以通過遵循 CIS Benchma

71、rk 中最佳實踐的加固腳本（Remediation Kit）來對 Aliyun Linux 2 OS 進行自動加固。CIS Benchmark 文檔和加固腳本可以通過 CIS 官方網站免費獲取。云容器安全 防護重點 1：入侵檢測 云采用框架白皮書 文檔版本：1.0 38 與主機安全類似，阿里云容器服務當前已經支持基于云安全中心的入侵檢測，當前云安全中心在容器服務產品支持容器內 Web-CMS 漏洞檢測和修復、Webshell 檢測和修復、云查殺、進程異常行為、異常網絡連接、進程啟動日志、網絡連接日志的功能。防護重點 2：鏡像掃描和簽名 針對基于 Linux 的部分基礎鏡像，阿里云容器鏡像服務已

72、經提供了鏡像安全掃描的功能，發現與掃描鏡像相關的最新 CVE 安全漏洞信息，同時在適用的情況下會向用戶提出漏洞修復建議。同時容器鏡像的簽名和校驗可確保僅在 ACK 上部署經過容器使用方簽名確認的容器鏡像。通過強制執行驗證，可以確保僅將經過驗證的鏡像集成到構建和發布流程中，從而對容器環境實施更嚴格的安全控制。同時也可以依賴二進制授權校驗進行進一步的安全策略配置。防護重點 3：容器運行基線檢查 通過針對容器環境的基線檢查，發現潛在的基線合規問題，參考業界常用的 CIS Benchmark for Docker、CIS Benchmark for Kubernetes，以及阿里云容器最佳實踐，進行安

73、全配置的維護。3.數據安全 云上數據安全參考數據安全成熟度模型，提煉出在云上構建數據安全的基礎能力。防護重點 1：數據分類分級 每個企業都會有適用于其自身所在行業以及業務特點的標準和體系。分類分級標準的制定，并不應當只是紙面上的工作，而應該結合企業所在的行業和業務特點，有針對性的進行設計，并通過自動化的手段，輔以手 云采用框架白皮書 文檔版本：1.0 39 工的方式，對海量的企業全域數據資產進行識別與分類，有效定位企業關鍵以及敏感類信息在企業數據資產中的分布和流轉情況，并通過定級有針對性的進行保護。數據安全中心提供對數據源中保存的敏感數據的自動識別能力，對文件提供基于內容的敏感數據識別，且支持

74、 OCR（印刷文字識別）技術，對圖片中保存的敏感信息進行提取和識別；同時內置深度神經網絡和機器學習等先進技術，通過樣本掃描、特征萃取、特征對比和文件聚類等算法，實現多達 44 種敏感數據的精準識別。同時數據安全中心提供了敏感數據發現后的自動分類分級以及統計展示能力，通過對結構化和非結構化數據源的敏感數據識別，自動對敏感信息進行識別結果歸類。防護重點 2：靜態數據防護 隨著企業的數字化轉型，數據會存儲在各類云中提供的存儲服務中。從最傳統的塊和文件類存儲，到數據庫、數據倉庫類型的結構化存儲，再到緩存、對象存儲等新型存儲方式，企業的數據會分布在各類應用系統和所使用的數據存儲中。如何在數據存儲的過程中

75、保護數據的保密性、一致性和可用性，是數據安全在存儲階段的重點。其中對于數據的加密和脫敏，是企業最常見的保護手段。數據加密 加密服務通過在阿里云上使用經國家密碼管理局檢測認證的硬件密碼機，幫助客戶滿足數據安全方面的監管合規要求，保護云上業務數據的機密性。借助加密服務，用戶可以進行安全的密鑰管理，并使用多種加密算法來進行加密運算。密鑰管理 密鑰管理服務提供安全合規的密鑰托管和密碼服務，助您輕松使用密鑰來加密保護敏感的數據資產，控制云上的分布式計算和存儲環境。您可以追蹤密鑰的使用情況，配置密鑰的自動輪轉策略，以及利用托管密碼機所具備的中國國家密碼管理局或者 FIPS 認證資質，來滿足您的監管合規需求

76、。數據脫敏 數據安全中心通過多年的內部沉淀，為廣大云上開發者提供了近 30 種數據匿名化和去標識化算法，無論是應用開發人員，還是數據安全管理者，都可以根據實際業務場景靈活選擇，自定義參數，做到個性化數據脫敏。數據安全中心提供了自定義脫敏模板能力，真正做到安全自適應。企業數據安全管理者可以通過自適應的脫敏解決方案，完成各類不同場景的數據脫敏分發，例如定期從生產環境向開發測試環境脫敏，不同數據類型（如 OSS 中的 csv 向 RDS 的數據表）之間的異構脫敏，數據庫層面的原庫/原表脫敏等等。防護重點 3：動態數據防護 數據傳輸過程中使用的網絡通道不同，保護方式也會不同。對于客戶端通過互聯網發起的

77、訪問，一般建議企業使用 SSL/TLS 證書來加密傳輸通道，防止發生中間人攻擊竊取傳輸過程中的重要數據；對于企業站點間的數據傳輸，通常會使用 VPN 或專線對通信鏈路進行加固。云采用框架白皮書 文檔版本：1.0 40 阿里云通過提供 VPN 服務，幫助企業構建端到端的數據加密通道，保障數據傳輸過程中的通信安全。同時阿里云還為用戶訪問網站提供了 SSL/TLS 協議來保護數據。阿里云證書服務可以在云上簽發第三方知名 CA 證書頒發機構的 SSL 證書，實現網站 HTTPS 化，使網站可信，防劫持、防篡改、防監聽，并對云上證書進行統一生命周期管理，簡化證書部署，一鍵分發到其它阿里云的產品（包括 C

78、DN、SCDN、DCDN 和 SLB 等）。防護重點 4：數據安全審計 等保2.0 針對數據安全提出了“安全審計”和“個人信息保護”的相關要求。隨著數字化轉型的深入發展，企業重要數據已經從傳統單一的數據庫存儲擴大到各類數據存儲、大數據和數據中臺等，統一的數據安全審計成為管理難題。數據安全中心可以實現對云上各類數據源的安全審計，并在此基礎上深耕防泄漏場景，幫助客戶實現全域數據的風險感知。利用機器學習技術，為數據的訪問行為建立安全基線，在發生潛在數據風險，例如異常時間或地點訪問時，及時預警并提供針對性的溯源能力和防護建議，化靜態檢測為動態感知，幫助客戶快速應對突發的數據安全事件，提升整體響應能力。

79、3.2.6.合規審計 概述 企業往往需要應對來自企業外部和內部的審計合規要求。企業外部的三方審計認證機構會依據國家法律法規和行業標準對企業進行審計評測，要求企業在管理IT 系統時具備足夠的可見和可控性，如必須保留 180 天及以上的審計日志。外部審計評測不通過則很可能會影響企業的經營資質和正常的商業活動。而在企業內部IT運維團隊和安全合規團隊往往承擔著巨大的風險。為了充分利用云的靈活性和敏捷性，企業將業務搬遷上云。相比于傳統云下的 IT 系統，運維團隊面對更龐大的 IT 規模、更復雜的拓撲關系、更高頻的運維動作，這使每天的運維工作潛藏著巨大的風險，也讓安全合規團隊的監管工作面臨更大的挑戰。一旦

80、運維管控或安全監管不充分，就很容易發生錯誤操作、失誤操作、遺漏操作，致使業務中斷或重要業務數據泄露，使企業遭受巨大損失。阿里云建議企業通過審計合規能力構建一個可見、可控、可追溯的安全運維環境：可見：可見的才是可控的，企業首先要確保能看到 IT 資源清單、IT 資源狀態、IT 資源的詳細配置、IT資源拓撲關系，以及實時的運維動作及資源變更?？煽兀涸谄髽I的運維團隊管控云上 IT 資源的整個過程中，在合適的環節設置卡點。阻止紅線行為的發生，及時發現并修復非法配置?？勺匪荩河涗浽粕瞎芸氐恼麄€過程并長期留存，這對于故障排查和歷史問題回溯有必不可少的作用。也讓企業能夠基于歷史不斷完善和優化運維框架。云采用

81、框架白皮書 文檔版本：1.0 41 如果把企業運行在云上的業務比作行駛在高速上的車隊，那審計合規就是高速護欄、違章攝像頭和行車記錄儀，這會使企業 IT 運維團隊和安全合規團隊有可見的抓手和可控的手段，是使自身工作低風險進行所必需的能力。審計：客觀記錄云上 IT 運維的全過程，并做長期留存。合規：通過限制和持續監控，確保 IT 配置始終符合合規預期。示例 X 企業在上云之初啟用了完整的審計合規能力，在后續長達數年的持續運營中，依賴審計數據和合規能力解決諸多問題。在上云之初開始記錄云上 IT 的操作日志并長期留存。這些日志一方面可以滿足三方審計的要求（留存180 天及以上的審計日志），另一方面通過

82、對歷史日志的建模分析得到該企業的安全運維數據畫像，該畫像將有助于在后續運維中及時發現異常的來訪 IP 和異常的管控動作，及時制止風險發生。企業持續記錄云上資源的配置變更歷史。即便是某些資源已經被釋放，仍然能在數月后回溯當時保有的資源以及資源的詳細配置，包括資源全生命周期的變更和標簽信息。測試業務在云上運行一段時間后，在正式業務上云之前，X 企業先在云上實施了最基本的合規管控策略，讓業務一開始就跑在一個可控環境下：除了指定的幾個用戶和角色，禁止授予其他用戶角色 Admin 權限 禁止授權中出現“*”限定資源采購的地域、規格、數量 除了指定的幾個用戶和角色，其他人禁止采購和釋放資源 強制設定強密碼

83、策略 必須開啟基礎計算、存儲資源的刪除保護功能 .審計合規管理工具 IT 運維團隊管理云上資源的過程中，有三個關鍵環節：事前限制、事中及時發現和修復、事后審計記錄，對應的環境在阿里云上都有匹配的云服務或功能。云采用框架白皮書 文檔版本：1.0 42 事前限制：禁止零容忍違規的發生，禁止修復成本極高的違規發生。事中發現和修復：在日常管控中需保留足夠的靈活度，所以并不是所有事情都能一開始被攔截禁止，那就需要在靈活管控的過程中及時發現不合規問題并快速響應修復。事后審計記錄：無論企業是否實現了事前限制和事中發現修復，事后審計都是最基本的手段，確保在問題暴露出來后有線索可排查和追溯。關于合規策略的設計將

84、在第 5 章運營治理中詳細闡述。合規策略的本質目的是實現長期的持續的風險控制，通過禁止違規操作、及時發現并修復非法配置來保證云上 IT 的配置始終符合運維團隊的預期要求，避免 IT配置失誤造成的數據泄露或業務中斷等。合規策略的制定需要充分考慮在企業不同的發展階段所面對的潛在風險，識別風險、量化風險、制定合規策略、建立流程確保合規策略的運轉，這是另一個龐大的方法體系。這對于企業在云上長期的安全穩定至關重要，更多信息請您參閱第 5 章運營治理。使用限制 管控策略（Control Policy）和阿里云配置審計（Cloud Config）服務目前僅支持部分核心產品，仍在持續更新中。了解權限策略 阿里

85、云配置審計（Cloud Config）服務中部分檢測規則不支持修正模板，仍在持續更新中。了解配置審計 3.3.基于 IaC 理念快速部署 Landing Zone 概述 當企業確認好 Landing Zone 的設計方案，接下來就是需要實施部署到云上了。實施的方案有多種，除了云上的服務之外，一些第三方的工具也可以協助您完成整個Landing Zone的搭建。這里，我們以Terraform為例，借助 IaC 的理念，提供了一個包含基礎設施構建（多賬號體系搭建、網絡規劃、訪問控制、安全合規），以及賬號工廠（新賬號初始化）的 Landing Zone 的搭建過程示例。云采用框架白皮書 文檔版本：1.

86、0 43 IaC 理念 IaC（Infrastructure as Code,基礎設施即代碼）是使用軟件開發原則和實踐的基礎設施自動化。簡而言之，就是把基礎架構像軟件一樣來對待，然后通過編寫、測試和執行代碼以定義、部署、更新和釋放基礎架構。通過編寫代碼來管理云上 Landing Zone 的部署和配置，可以更快地實現基礎設施的交付，降低手工配置的成本，監測配置偏移，以實現自動化、可維護的部署和實施過程。當需要更改 Landing Zone 的設計方案時，可以更改代碼，對其進行測試，然后將其應用于系統中。設計建議 我們在示例代碼中展示了一個完整的 Landing Zone 部署方案，但不同的企業

87、都會有不同的需求。您可以克隆我們的示例代碼，并自定義修改，以滿足您特定的需求。在設計和實施過程中，我們建議您考慮以下原則：獨立的 POC（Proof of Concept）驗證環境：創建單獨的云賬號，用于基礎設施等的驗證。一個 Landing Zone 的實施包含了很多方面的內容。一個獨立的 POC 環境有助于您發現代碼中的問題，并且方便后續方案修改。在應用到生產環境之前，也可以作為驗證階段，避免影響線上業務。選擇合適的地域：在部署網絡等資源之前，確保選定的地域有滿足您業務所需的資源類型。您可以參考對應云產品的官方文檔，來確認所需資源是否在您選定的地域提供服務。使用 Terraform bac

88、kend 保存部署狀態：通過使用 Alibaba Cloud Terraform provider 提供的backend 能力，將 Terraform 執行過程的狀態保存在云端，避免狀態保存在本地丟失導致后續難以變更，同時也便于多人協作。使用 Terraform workspace 來隔離不同云賬號的狀態：在賬號工廠新建云賬號過程中，我們建議您給每個新賬號都創建唯一的workspace，后續在該賬號中部署業務資源時，也可以復用該workspace。使用版本控制管理部署腳本：基于 IaC 理念將基礎設施代碼化后，即可加入到版本控制里。通過版本控制，可以實現基礎設施架構變更的追蹤、回滾等能力。使用

89、 CI/CD（Continuous Integration/Continuous Delivery）流程實現自動化部署：結合 CI/CD 流程，可以實現代碼變更后的評審、預檢查、自動化部署，規范化運維鏈路，保障實施過程的準確性。因為部署過程中需要用到的 AK 權限較大，使用自動化流程，可以避免 AK 存放在運維人員電腦上，降低 AK 泄露風險。同時，對于賬號工廠能力，也可以結合企業 ITSM 系統，實現業務方提交新賬號需求，審批通過后自動完成賬號創建，提升效率。Landing Zone 示例代碼介紹 您可以在我們的官網 Github 倉庫查看示例代碼。這里我們針對復雜企業、跨國企業樣板間案例進

90、行介紹。在示例腳本中，我們包含了兩大模塊：foundations：即基礎設施，在該模塊中，會完成云上 Landing Zone 基礎的搭建。如果后期Landing Zone 的設計方案沒有變化，該模塊只需要運行一次即可。具體包含以下內容：云采用框架白皮書 文檔版本：1.0 44 o 多賬號結構：初始化 Core、Applications 資源夾以及創建 SharedServices 賬號。o 身份管理和訪問控制：初始化安全策略，在 SharedServices 賬號中創建相應角色。o 網絡：基于 SharedVPC 方案，在 SharedServices 賬號中初始化網絡架構，會創建 DMZ

91、VPC、SharedServices VPC、生產 VPC 和非生產 VPC，并通過 NACL、云防火墻等實現網絡訪問控制。o 治理框架：創建多賬號統一的操作日志投遞和跟蹤，初始化基礎的配置審計規則。account-baseline：即賬號工廠，用于創建新的用于部署業務的云賬號。具體包含以下操作：o 賬號創建：通過資源目錄創建賬號并放入 Applications 資源夾內。o 訪問控制：初始化基礎的 RAM 角色。o 網絡：在 SharedServices 賬號中的生產 VPC 和非生產 VPC 內創建業務使用的 VSwitch，并通過資源共享能力，共享給該業務云賬號，同時配置適當的 NACL

92、 規則實現業務間的訪問控制。o 治理框架：這部分由于已經在 foundations 中配置過，所以在創建新的業務云賬號過程中，無需再次配置。在具體的實施過程中，賬號工廠需要在基礎設施初始化好之后才可以運行?；A設施運行完畢后，會打印出已經創建好的資源信息，賬號工廠創建新賬號的過程，會依賴這些信息。后續如果需要新的云賬號，可以再次運行賬號工廠模塊，提供一份新的配置，完成云賬號的創建和初始化步驟，以保障所有的業務云賬號，都能夠滿足企業 Landing Zone 的設計要求。部署 Landing Zone 接下來，我們通過示例代碼，介紹 Landing Zone 的部署過程。在開始之前，我們假設您已

93、經對 Terraform 的使用方式有了一定的了解。如果您還不熟悉 Terraform 的操作，請參考 Hashicorp 官方提供的文檔。在開始部署之前，請先在管理賬號下創建一個 RAM 用戶，并授予 AdministratorAccess 權限，生成一個AK，用于執行接下來的所有操作?；A設施初始化 首先將我們的示例代碼克隆到您的本地，然后進入到 example/03-complex-enterprise/foundations 這個文件夾。我們提供了豐富的配置項，您可以通過修改 settings.tfvars 中的配置項，來自定義您的 Landing Zone設置。在執行過程中，Terr

94、aform 會自動使用您修改后的配置項。在 foundations 的配置項中，主要包含基礎設置（basic_settings）和網絡設置（network_settings）兩個部分，我們首先看一下基礎設置部分。云采用框架白皮書 文檔版本：1.0 45 在該部分，先關注一下 shared_services_account_roles 這個配置項，該配置項定義了 SharedServices 賬號內置的角色，是個數組，可以根據需求進行修改和添加。比如需要新增一個查看監控的角色，則在最下面新增：role_name=EnterpriseIdP-MonitorViewer policies=Aliyu

95、nCloudMonitorReadOnlyAccess 接下來，治理項的配置 governance 也建議進行修改，因為審計日志投遞到的 OSS Bucket 以及審計跟蹤的名稱均需要全局唯一，不能和其它用戶的命名重復，建議修改為一個含有企業特定標示的名稱（假定這里公司名為 AlibabaCloud），如下：governance=bucket_enterprise_audit_logs=alibabacloud-landingzone-enterprise-audit-logs trail_enterprise_audit_logs=alibabacloud-enterprise-audit-

96、logs 在 network_settings 中，請關注每個 vpc_開頭的配置項里的 cidr_block，代表了該 VPC 的網段。請根據自身業務規模合理規劃網段，確保能夠容納所需資源數量，并且保證四個 VPC 的網段不重合，一旦設置并部署業務之后，后期難以修改。確保配置項正確后，通過 Terraform plan 預檢查配置，確認無誤后執行 apply 命令，耐心等待基礎架構初始化成功。初始化成功后，Terraform 會返回類似下方的輸出，請妥善保存該輸出，便于后續執行賬號工廠的步驟。foundations=cloudfirewall=cen_instance_id=cen-xxxx

97、xxxxxx vpc_dmz_cidr_block=10.34.11.0/24 .master_uid=1888888888888 rd_folder_application_id=fd-xxxxxxx 云采用框架白皮書 文檔版本：1.0 46 shared_services_uid=19999999999 云采用框架白皮書 文檔版本：1.0 47 4.應用上云 4.1.企業應用上云規劃 4.1.1.上云評估模型 隨著企業信息系統的持續建設，IT 與業務不斷的融合，企業應用類型及模板不斷發展，怎么從大量企業應用系統中，篩選需要上云的應用，確定應用上云的策略及優先級，是上云實施前需要做的事情。所

98、以，我們建議在企業進行上云遷移實施前，對企業總體應用進行上云規劃，以企業上云戰略及規劃為指導方向，梳理企業應用系統清單，調研應用上云兼容性等相關特征，制定應用的上云策略，以及應用上云遷移優先級。阿里云上云評估模型如下圖所示。云采用框架白皮書 文檔版本：1.0 48 4.1.2.業務調研 上云規劃階段調研的目的是制定應用的上云策略，以及上云優先級，所以，這一階段，我們調研的信息，主要包含上云兼容性，以及業務痛點及規劃、安全合規要求等。上云兼容相關特征 上云兼容性主要包含基礎設施相關兼容性以及應用架構兼容性特征 基礎設施兼容性特征 硬件依賴性：是否有特殊硬件要求，比如 USB 加密狗等 性能要求：

99、是否有特殊性能要求，比如運行環境 CPU、內存規格，IO 或網絡要求等，云上是否能滿足 操作系統要求：是否有特殊版本操作系統要求，云上是否能提供 應用架構兼容性特征 集中式/分布式架構：應用是否分布式架構，以及使用的分析式架構框架，是否有對對應的 PAAS 產品支持兼容 源代碼可控性：源代碼是否操作及維護，是可有能力支持上云遷移或改造 技術組件上云兼容性：包含數據庫、存儲、中間件等技術組件，是否有對應兼容的云產品 其他特征 業務/技術痛點或訴求：是否有業務或技術上的痛點或訴求，比如當前集中式架構迭代速度無法支持業務快速發展，需要做微服務改造 資源/數據增長需求：當前基礎設施環境，是否滿足業務預

100、期的資源或數據增長需求，以及數據增長要求對架構提供優化需求，比如數據庫容量未來無法業務未來數據增量，在上云同時，需要做水平拆分 安全合規要求：是否有行業特征的安全合規要求，云的安全合規等級是否滿足行業要求 容災要求：是否容災或數據災備要求，云產品能力是否支持 4.1.3.應用上云策略及決策流程 上云策略 上云規劃階段，需要確認應用的上云策略，是否平遷或改造上云，根據阿里云的以往項目實踐，我們建議的上云策略包含以下幾點。保持現狀 保留應用程序在當前的 IT 環境，作為非云基礎設施的一部分 云采用框架白皮書 文檔版本：1.0 49 平遷上云 應用比較容易移植到云環境上，使用云產品可替兼容替換技術組

101、件，少量修改應用配置后重新部署到新的云平臺。優化上云 通過使用云上 PaaS 產品及服務，對應用進行局部優化，提升性能或穩定性。重構上云 應用組件不適配云的架構，或者不符合成本效益，因此需要對應用進行重構，基于新的云平臺構建云原生架構的應用。決策流程 根據業務調研階段輸出的應用系統清單及應用特征數據，每個應用最終對應上云評估策略的中一個類別。其決策流程可以參考下圖。4.1.4.應用上云優先級及計劃 考慮到企業應用系統規模較大，各方面資源無法保障所有應用系統并行上云。所以，我們建議制定應用上云優先級，并明確遷移批次及計劃，使得所有資源能夠有效被利用，并降低上云風險。我們建議應用上云先級級的制定，

102、以“速贏”為原則，即優先遷移上云難度低且上云收益高的應用。根據應用的上云難度及上云價值收益，可以將應用上云優先級，劃分低中高三個象限，應用上云批次確認后，根據企業上云戰略及規劃，制定企業應用上云總體實施計劃，云采用框架白皮書 文檔版本：1.0 50 4.2.應用上云實施 4.2.1.應用上云實施流程 阿里云基于業界最佳實踐和大量上云項目的經驗累積，總結出以下遷云流程，這一過程建立在完成了企業應用上云規劃后，以應用為單位進行進一步的遷移計劃和實施。4.2.2.應用調研 在上云實施階段，應用調研的目標，是為了解應用的應用架構以及使用的技術組件，以制定云上目標詳細方案，包含云上應用架構設計，產品選型

103、及容量評估、遷移方案以及割接方案等，所以這一階段調研的信息比較詳細。應用架構及依賴 應用架構：應用模塊及模塊間關系，節點配置及數量；應用開發語言及框架。應用依賴：其他應用間的依賴關系，以及外部依賴，主要用于割接方案參考；技術組件 數據庫：數據庫類型，版本，數據量，性能要求等；中間件：中間件類型，版本，集群規模及容量【可選】，如消息隊列、緩存等；存儲：使用存儲設備的接口協議，及數據量；應用性能基線 應用的性能指標要求，用于測試驗證階段性能測試目標參考；調研工具 如果企業系統非常龐大，應用之間耦合多，各系統的負責部門不同，人工收集的方式難免會有疏漏，難以完整厘清所有應用系統以及系統間的復雜依賴關系

104、。我們建議使用阿里云提供針對企業應用上云場景提供應用發現服務（Application Discovery Service），滿足企業在遷云階段的評估、規劃、建設、遷移的需求評 云采用框架白皮書 文檔版本：1.0 51 估。采用無侵入式采集技術，不影響在線業務的性能前提下從主機和進程兩個維度構建架構拓撲，自動分析識別主機和進程信息、資源使用水位以及各應用和組件之間的依賴關系。更多詳情，請參見應用發現服務。4.2.3.應用上云方案設計 基于應用調研結果，針對平遷上云、優化上云、重構上云三類應用上云策略，結合我們以往項目實踐經驗，以下分別給出典型場景的示例上云方案。平遷上云方案 產品選型策略 針對傳

105、統應用平遷上云場景，常見產品對標選型策略如下圖所示。場景示例：單體應用遷移 云上重部署應用 針對平遷方式的應用上云場景，對于已有成熟 CI/CD 工具及流程的企業，我們建議優先使用現有 CI/CD 工具，在云上重新部署應用。對于還沒有構建 CI/CD 能力的企業，我們建議先使用云上 DevOps 產品構建企業的 CI/CD 自動化平臺，通過 CI/CD 流水線，在云上重新部署應用?；诎⒗镌圃菩Мa品構構建 CI/CD 流水線如下圖所示。云采用框架白皮書 文檔版本：1.0 52 鏡像遷移 對于普通單體應用，也可以使用阿里云自主研發的遷移平臺服務器遷移中心（Server Migration Cen

106、ter，簡稱 SMC），可將單臺或多臺遷移源遷移至阿里云。遷移源（或源服務器）概指企業待遷移 IDC 服務器、虛擬機、其他云平臺的云主機或其他類型的服務器。在應用服務遷移過程中，使用 SMC 服務將在 IDC 部署的業務應用服務自動、快速、一站式遷移到云上 ECS，同時提供工具支持將自建 Kubernetes 的應用遷移到云上。更多詳細信息，請參見 SMC 最佳實踐。優化上云方案 場景示例：應用容器化上云 以 Kubernetes 為代表的容器技術正成為云計算新界面。容器提供了應用分發和交付標準，將應用與底層運行環境進行解耦。Kubernetes 作為資源調度和編排的標準，屏蔽底層架構差異性，

107、幫助應用平滑運行在不同基礎設施上。應用容器化規范化改造 容器化的應用必須要規范化，我們不希望所完成的容器鏡像只能在生產環境中運行，也不希望該容器有著外部依賴，我們希望應用在容器化之前，最少滿足這三項要求：與操作系統解耦，能在各種系統中運行并有極大的可移植性 適合部署在現代的云平臺上，配置與代碼分離 開發與生產環境對等，能夠使用現代的包管理工具實施封裝打包 所以，對應用進行容器化前，必須對應用進行檢查并實施類似的改造，也就是進行應用規范化，規范化的過程根據已有應用的實際情況有較大的不同，一般來說，越是現代的、面向互聯網的應用越容易容器化。對容器化應用的規范化改造有以下內容：云采用框架白皮書 文檔

108、版本：1.0 53 準代碼：明確一份代碼，多分部署的原則，一個應用程序只能有且只有一個代碼庫或一個主庫，確保該代碼庫中能夠支持開發、測試、構建操作。依賴管理：大多數編程語言都會提供一個打包系統，用來為各個類庫提供打包服務，我們期望應用程序能夠顯示的表示自己的依賴，使用 pom.xml 或者 package.json 來描述自己的全部依賴，不要有隱式依賴。這樣能夠為開發者和流水線簡化配置流程，可以完成一句話構建。配置注入：數據庫地址、三方證書、API Key 等等這些在不同環境下有區別的配置應該能夠獨立注入，我們要求在不同環境下，容器一致，但配置不同?？梢允褂铆h境變量或 Config Servi

109、ce 方式進行管理，使用 Config Service 時也需要做到無依賴。服務配置化：后端依賴的服務比如數據庫 MySQL、PostgreSQL，緩存、隊列等都需要做到可配置化，將配置拿出，系統不應該區別對待這些服務。進程整理：應用程序盡量做到一個進程運行，如果使用多個進程比如 nginx+php 也可以接受，但一定要目的單一，易于管理。同時以也需要保證進程的無狀態特性，使用內存存儲 session 造成粘性是無法接受的，并且狀態應該持久化入數據庫。單一的、無狀態的進程也可以反映到并發上。易處理：表示可以瞬間開啟或停止，這有利于快速、彈性的伸縮應用，迅速部署變化的代碼 或 配置，穩健的部署應

110、用。當然也需要支持優雅的終止，即受到 SIGTERM 后會處理完任務，或者在服務中心注銷，再進行關閉。容器化上云流程 傳統應用容器化大致分為五個階段：應用現狀分析：梳理應用使用的資源、系統的邏輯架構拓樸、應用服務的所有數據依賴、應用上下游服務依賴關系、服務所依賴的進程、系統中需要保留的重要日志及數據、數據和文件權限等；方案規劃和設計：根據前期對應用系統現狀的調研和分析結容器平臺特性，應用系統產出新的系統架構圖和遷移的改造計劃，比如是直接容器化上云還是改造后再容器化上云，以及容器化后業務系統功能和性能測試方案、系統的割接方案等。編寫 Dockerfile：若要打包應用程序以供在 Docker 中

111、運行，需要編寫腳本文件 Dockerfile，用于自動執行所有應用程序部署時需要執行的步驟。這通常包括一些 Shell 配置命令，以及用于復制應用程序包、設置所有依賴項的指令，也可以解壓縮已壓縮的存檔或安裝包。Docker 鏡像是一個特殊的文件系統，除了提供容器運行時所需的程序、庫、資源、配置等文件外，還包含了一些為運行時準備的一些配置參數（如匿名卷、環境變量、用戶等）。在 Docker 鏡像使用中，我們最好把經常變化的內容和基本不會變化的內容要分開，把不怎么變化的內容放在下層，創建一個基礎鏡像供上層使用。云采用框架白皮書 文檔版本：1.0 54 生成鏡像：使用docker commit命令將

112、某個container的環境提交成為持久化的docker image。使用docker build命令基于dockerfile構建。這種構建方式的優勢在于可以通過docker history命令溯源鏡像的生成過程。并且消除了 docker commit 可能把一些不需要的東西誤提交的隱患。鏡像構建成功后，只要有 docker 環境就可以使用，通過利用 docker push 命令將鏡像推送到鏡像倉庫中去。應用部署：將 docker 鏡像部署到對應 Kubernetes 集群應用。在 Kubernetes 集群上需要用到的部署模板，在具體實施過程中，可以根據不同的模板來部署到對應不同的集群。重構

113、上云方案 傳統單體應用架構問題 單體應用復雜度高，應用迭代發布周期慢，無法支撐業務快速發展的需求；開發者需要關注架構的所有細節（限流、熔斷、降級等服務治理，數據訪問及消息通信）；運維需要負責底層基礎設施（包括數據庫、緩存、虛擬機等）的穩定性；云原生應用架構 云原生應用架構特點 應用代碼按業務域拆分解耦，降低復雜度；開發者只需關注業務邏輯，與業務不相關功能下沉到云基礎設施；技術體系走向開放和標準；運維無需關注基礎設施穩定性，更多精力專注于自動化；云原生應用架構建議 云原生應用架構示例，如下圖所示。云采用框架白皮書 文檔版本：1.0 55 微服務解決“應用架構復雜度”問題；服務治理解決“業務開發關

114、注與業務無關的限流、熔斷、降級能力”；容器解決應用“部署問題”問題；K8S 解決應用“編排和調度”問題；Service Mesh 解決“侵入性微服務改造”問題；專項上云方案 場景示例：阿里云 SAP 上云方案 SAP HANA 是一個軟硬件結合體，提供高性能的數據查詢功能，結合了大量交易與實時分析能力，顯著提升商業效率，助力企業數字化轉型。阿里云多個 ECS 企業級云服務器產品規格通過 SAP HANA 認證，企業用戶可以在阿里云上放心部署和運行基于 SAP HANA 數據庫的關鍵業務系統。SAP 在企業管理軟件領域有著豐富經驗，結合阿里云彈性和可擴展性、快速部署、高度穩定性、全球基礎設施等優

115、勢，可以幫助企業輕松應對業務變化，加速業務系統的部署。阿里云 SAP 上云及云上運維最佳實踐 云采用框架白皮書 文檔版本：1.0 56 針對企業用戶 SAP 上云的需求，阿里云提供了場景豐富的 SAP 云上部署及運維最佳實踐，詳情參見 SAP 解決方案 數據上云方案 數據上云架構設計 數據在同一業務庫中采用多租戶隔離機制；為數據服務層建立一套統一的管理規范，所有業務用戶賬號在完成相關審批流程后對相應的數據字段進行授權安全訪問，對數據只有讀的權限，不能對原始數據進行直接修改或刪除，做到數據不搬家，可用不可見；建立統一的數據資源視圖和數據血緣跟蹤能力，能夠對所有的數據的生命周期進行溯源查詢，用以甄

116、別數據變更過程中的真實性和準確性；根據不同業務場景結合流程節點和風險管控要求，對相關數據進行分析、建模、挖掘，提高數據服務支持。數據上云安全防護 在企業數據遷移上云的過程中,實施數據分層保護功能已成為一個關鍵優先事項。同時，數據保護控制必須輔之以強大的監控工具和訪問管理控制,以構建數據的整體視圖，對數據的全生命周期進行監控。重點考慮以下關鍵數據保護領域。數據分類：圍繞數據識別、清單、標簽和分類的功能和流程；靜態數據保護：有關加密/令牌化的解決方案和注意事項,包括密鑰管理；傳輸中數據保護：功能包括 TLS/SSL 層保護、數據丟失防護解決方案和安全數據傳輸；數據監控：通過操作中心(SOC)進行日

117、志記錄和監視功能；在云環境中,以數據為中心的保護需要在整個數據生命周期中進行。阿里云數據上云遷移最佳實踐 數據庫上云 包含關系數據庫及 NoSQL 數據庫上云等場景，以 Mysql 為例，主要考慮以下幾點：根據性能場景需求，選擇匹配的產品及實例規格，以最低成本達到業務需求 比如 RDS 和 PolarDB，RDS 主要是主備模式，讀寫 IO 在單機上執行，走主機總線，RT 相對較低，而PolarDB 是云原生的讀寫分離架構，讀寫 IO 會走網絡，RT 相對較高。從產品架構上分析，對于 RT要求比較高的場景，建議使用 RDS，其他情況，相同規格 PolarDB 實例一般比 RDS QPS 性能要

118、高。未來數據增長 未來三年內數據增長，如果超過單實例最高規格性能，建議 PolarDB-X，通過水平切分的方式，將數據分布在多個底層 mysql 庫，通過并行的分布式數據庫操作來實現性能的提升。云采用框架白皮書 文檔版本：1.0 57 遷移過程數據膨脹 全量數據遷移過程并發 INSERT 導致目標實例的表存在碎片，全量遷移完成后目標實例的表空間會比源實例大（遷移完成后可通過 optimize table 合并碎片，優化存儲空間），所以建議選擇實例規格時，預留一定的存儲空間以防存儲打滿；識別無主鍵表 無主鍵表不支持增量遷移，需要提前識別，對于無主鍵表單獨做全量遷移。阿里云數據庫上云遷移工具及最佳

119、實踐 數據傳輸(Data Transmission，簡稱 DTS)是阿里云提供的一種支持關系型數據庫、NoSQL、OLAP 等多種數據源之間數據交互的數據服務。DTS 的數據遷移功能支持同構或異構數據源之間的數據遷移，同時提供了庫表列三級映射、數據過濾等多種 ETL 特性，適用于多種數據庫遷移上云場景。詳情請參見在線遷移服務。存儲數據上云 主要指非結構化數據，常見于內容管理類型的應用系統，涉及大量文件對象的存儲和管理，傳統的解決方案包括：本地磁盤存儲，數據定期備份。但這種方案存儲存儲容量和性能的擴展性、存儲自身的高可用性等問題。采用 IP-SAN、NAS 等對數據做集中存儲，這種方案成本較高；

120、在數據庫中存儲文件。這種方案成本高，對數據庫的存儲資源消耗和性能影響都比較大。針對文件對象存儲，阿里云提供開放存儲服務（OSS），具備高可用、高擴展、高效性、低成本等特點，能有效解決內容管理類型應用的文件對象的存儲問題。應用系統需要基于 OSS 進行相關改造，主要包括：根據應用系統文件的存儲結構在 OSS 中規劃 Bucket，以及文件目錄結構；設置 Bucket 訪問權限（public-read-write/public-read/private），對于安全級別要求高的應用，可設置文件在 OSS 上以密文形式存儲；對程序代碼進行掃描，查找出涉及文件向存儲讀寫的代碼，將這些代碼改造為以 OSS

121、 SDK 接口的實現。這里需要注意，對于較小的文件（100M）推薦采用 SDK 提供的 Multipart Upload 接口對文件做分塊多線程上傳，以提升文件上傳效率。阿里云存儲數據上云遷移工具 云采用框架白皮書 文檔版本：1.0 58 阿里云在線遷移服務是阿里云提供的存儲產品數據通道。使用在線遷移服務，可以將第三方數據輕松遷移至阿里云對象存儲 OSS，詳情請參見在線遷移服務。4.2.4.上云遷移實施 建立上云遷移組織及保障機制 在上云遷移實施前，需要建議遷移組織及保障機制，明確各小組職責及成員，確定保障機制把握項目工作進度和工作質量。遷移組織架構 根據阿里云以往項目經驗，建議組織分為以下小

122、組，如下圖所示，各小組職責如下。項目管理辦公室：負責項目進度、風險及問題管理，以及內部宣貫。實施架構組：負責總組上云方案、割接方案設計，以及項目實施過程中技術風險把控。應用開發組：負責應用開發、部署及應用遷移實施工作；運維組：負責云上資源管理、數據組、中間件遷移實施及數據校驗工作；測試組：負責功能測試、聯調測試及性能測試工作。項目實施保障機制 建立項目管控機制，把握工作進度和工作質量，包含以下內容：內部定期溝通計劃 項目周報制度 問題和風險分析計劃 制定遷移實施計劃 云采用框架白皮書 文檔版本：1.0 59 由于上云遷移實施存在風險，所以，在應用上云實施執行前，我們建議制定詳細的實施計劃。這個

123、計劃表里面包含了上云遷移及割接過程的全部任務、時間段、各方人員等。項目實施過程按照這個計劃表跟蹤執行即可。4.2.5.測試與驗證 功能測試及聯調測試 在應用上云割接前，需要進行充分的功能測試與聯調測試，驗證云上環境應用運行情況。功能測試及聯調測試依賴企業自已的測試團隊及流程工作，不作過多描述，僅在此建議，對應用功能點進行分級，優先測試驗證核心功能點，對不同級別功能點測試問題，制定不同緊急程度的問題跟蹤。性能測試 1）性能測試流程 2）業務測試模型構建 業務測試模型構建主要是根據搜集到的性能測試需求和生產系統的相關信息完成性能模型的構建工作，并指導性能測試過程以及測試結果的生成。3）監控性能指標

124、 監控指標包含業務監控指標、操作系統監控指標、中間件監控指標、數據庫監控指標呢，旨在監控從各個維度描述壓測時性能表現。4）構建性能測試數據 測試數據主要包含兩類，基礎測試數據 基礎測試數據一般取自生產環境真實請求日志?；A測試數據非常適合真實業務模型，當然，也可以對基礎測試數據進行過濾處理，獲取單一業務場景測試數據。采用參數化測試數據 參數化測試數主要根據業務請求參數，按測試模型場景構建。參數化測試涉及的范圍很多，比如需要準備大量用戶名及相應密碼參數數據；模擬納稅人納稅申報，需要準備大量的納稅人識別號、納稅人內碼或納稅人系統內部識別號等參數數據，這類數據準備要求符合實際運行要求并且保證數據表之

125、間的關聯關系。云采用框架白皮書 文檔版本：1.0 60 5）測試場景 常見性能測試場景，主要包含以下幾種：基準測試：基準測試的目的是檢查業務本身是否存在性能缺陷。同時為將來的混合場景的性能測試性能分析提供參考依據。穩定性測試：主要側重系統在持續的壓力情況下，業務處理能力及系統可能存在的缺陷。業務突變測試：主要考察當業務進行突變以后，系統是否出現異常，資源在突變前后變化情況?？煽啃詼y試：主要是模擬各種故障（網絡中斷，服務異常、HA 切換）下，系統是否能正確切換，處理能力是否有明顯變化。6）測試實施及報告 基于測試工具，構建對應測試場景的腳本，通過測試結果，并根據觀測的性能指標，撰寫測試報告。7）

126、測試工具 阿里云性能測試 PTS（PerformanceTesting Service）產品是面向所有技術背景人員的云化測試工具。PTS是具備強大的分布式壓測能力的 SaaS 壓測平臺，可模擬海量用戶的真實業務場景，全方位驗證業務站點的性能、容量和穩定性。PTS 目標是將性能壓測本身的工作持續簡化，使您可以將更多的精力回歸到關注業務和性能問題本身。在PTS 平臺上，您可以用較低的人力和資源成本，構造出最接近真實業務場景的復雜交互式流量，快速衡量系統的業務性能狀況，為性能問題定位、容量最佳配比、全鏈路壓測的流量構造提供最好的幫助。進而提升用戶體驗，促進業務發展，最大程度實現企業的商業價值。詳情參

127、見 PTS 產品文檔。4.2.6.割接與上線 割接上線前的準備 應用的割接上線是整個應用上云遷移實施的最關鍵環節，這一環節出問題，可能會造成重大故障。針對割接上線的重要性，我們建議在實施應用割接前，制定詳細的割接前檢查清單,這個清單的嚴謹程度也許很大程度上決定了割接成功率。根據我們以往的經驗，對割接上線前的準備工作，以下給出幾點經驗：割接前需要嚴格確認是否所有需要預先準備的工具、遷移環境（客戶本地數據中心端、網絡、云端）等已經就緒。檢查和確認云環境 Landing Zone 已經就緒，并且確認云環境中的規模，安全，控制，網絡以及身份驗證與設計保持一致。割接上線時需多方人員參與，軟件廠商、集成商

128、、用戶方、云廠商等,確認這些相關人員是否已經就緒。支持的方式是現場、遠程還是電話。云采用框架白皮書 文檔版本：1.0 61 回滾預案是否就緒。割接過程好像在打一場大的戰役，很多的任務或子任務會分配半小時內計劃執行結束，整個過程可能會非常緊張。為降低壓力，即使因為某個主客觀原因導致遷移無法成功進行，如果有補救措施會讓整個遷移團隊降低很多壓力。這個補救措施之一就是回滾預案，也即是失敗后回滾到客戶的原數據中心恢復業務應用，需要在割接時預留回滾執行的時間?；貪L執行后，然后擁有充足的時間排查問題，以備下一個割接窗口期內再次割接。根據項目實際場景，設計一個檢查清單，這個清單需包含了遷移割接任務的全部前置條

129、件。制定詳細的割接實施方案 遷移項目是復雜的，大部分遷移割接的時候都會或多或少的遇到一些無法預料的問題。造成割接失敗，可能有主觀原因和客觀因素。主觀原因可能因為遷移調研問題、遷移方案設計缺陷、遷移驗證過程不夠全面等?？陀^因素通常是客戶 IDC、運營商網絡、云數據中心故障等。無論那種問題導致，都可能會對遷移割接造成失敗。根據以往的項目經驗，我們建議在割接前制定詳細的割接實施方案，以下是關于割接實施方案的一些建議。數據驗證，確認割接時與割接前數據保持一致。通?？蛻舻拇蟛糠址掌麋R像及數據會在割接前預先在云端復制完成。在割接窗口期開啟后需要確保云端復制的數據與客戶數據中心下線前保持嚴格一致。并非所有

130、問題都會導致遷移失敗。遇到問題的時候，首先評估問題的嚴重程度，如果不是關鍵業務應用的重要的問題，可以將割接流程繼續進行，同時該問題繼續解決。與客戶協商，該問題是否會會對業務有很大影響，如果客戶可以接受的話，可以先上線，然后盡快解決該問題。遷移時間拖延問題處理。如果割接時不夠順利，因為種種主客觀原因導致遷移割接時間長于計劃時間，可以與客戶協調，一起決定是否可以延遲一些時間上線。通常設計割接計劃時都會留出一些緩沖時間，如果需要延遲的時間過長是客戶無法接受的，那就只能執行回滾預案了。網絡切換問題處理。比如 IP,端口，網絡配置,DNS 等問題，在之前的調研和檢查中出現遺漏。這種問題在割接時經常會遇到

131、，出現這種問題緊急聯系相關負責方盡快解決，但并不一定會影響割接整體進行。遷移的不僅是服務器或數據。而是整個企業的 IT 應用及環境，客戶應用需要的身份管理、安全配置、數據及系統備份、高可用性架構配置，容災方案等都需要完成。嚴格按照遷移設計方案中指定的云服務型號匹配云上資源。拿 VM 舉例，通常云上會提供十幾個系列，數百種 VM 型號，使用錯誤的 VM 即使能夠將服務啟動起來，但會帶來性能、功能以及成本的問題。遷移過程確保安全合規。數據遷移嚴格使用加密數據傳輸，加密數據存儲。證書、密碼、權限按照合規的方式申請和使用，杜絕泄露隱患。避免因安全合規性問題帶給客戶嚴重損失。制定詳細的割接及回滾步驟，明

132、確每個步驟執行時間點，前置條件，相關責任人等。以下是割接及回滾步驟的示例模板，在具體的項目中可以根據項目需求來設計定制。割接后持續觀察驗證 云采用框架白皮書 文檔版本：1.0 62 割接后對遷移的應用云上運行情況持續觀察驗證，做好業務和數據做好監控，持續觀察業務的運行狀態，直到確認完全沒有問題，割接執行工作才算基本結束。云采用框架白皮書 文檔版本：1.0 63 5.運營治理 5.1.風險治理方法論 5.1.1.風險治理的方法論 企業需要進行風險治理 風險是指尚未發生但可能發生的問題，這些問題最終或多或少會造成業務的損失。此處所說的“風險”，特指因 IT 系統相關問題可能造成的業務損失。比如：I

133、T 系統中存放的業務數據被惡意盜取致使客戶個人隱私數據泄露，這將使企業面對客戶流失、輿論危機、法律責任和巨額罰款。IT 系統因無法承載突發的業務流量而癱瘓，又因缺乏基礎的災備恢復機制致使整個業務長時間中斷，這將使企業遭受巨大的業務損失和后續的客戶流失。經過第三方認證機構評定，IT 系統不符合行業基礎安全標準，商務合作伙伴認為該企業存在較大的潛在風險，決定終止商務合作。對于業務需重度依賴 IT 系統的企業，如游戲、在線教育、直播、電商等，IT 風險治理就更加重要，否則可能就要遭受企業收益和名譽的雙重損失，嚴重時甚至需要承擔法律責任。風險治理的工作思路 企業應配備專門的團隊（或人員）負責風險治理的

134、工作。風險治理團隊應站在管理者的角度考慮整個企業的風險治理決策，輸出清晰的風險定義、風險治理策略、治理策略的實施制度，并建立一定的監管流程來監督策略的實施，確保風險治理的可監督、可強制。云采用框架白皮書 文檔版本：1.0 64 風險治理團隊要充分采納一線業務團隊和運維團隊的風險提案，再從戰略上判斷是否要形成對應的風險決策、風險治理策略，從上而下地實施治理監管。實施過程中，應與一線業務團隊和運維團隊緊密合作，共同協定業務風險的評估機制、風險治理的實施辦法和效果 SLA（Service-level Agreement）。風險治理是在與一線業務團隊和運維團隊達成共識并充分協作的前提下不斷迭代升級，是

135、一項長期工作。風險治理的步驟 下圖是阿里云建議企業內負責風險治理的職位或團隊的工作路徑：風險識別&評估：充分考察企業在每個階段面對的潛在風險，并通過量化風險可能造成的損失來評定風險等級，針對不同的風險等級制定不同程度的治理決策。治理策略：將治理決策轉化為治理策略，治理策略是可被系統化實現的規則，在實際的工作中對于 IT管理行為能起到禁止或告警的作用。持續監督：成熟的企業會追求用技術手段落地管理決策，阿里云平臺也提供了相應的服務能力。云上系統化的治理可以分為如下兩部分：-事前攔截：可以通過啟用阿里云的安全防護產品主動防御惡意攻擊，還可以通過管控策略（Control Policy）默認禁止某些管控

136、行為和變更的發生。-事后發現：可以基于阿里云配置審計（Cloud Config）服務設置對資源配置的檢測條目，及時發現違規資源的出現并及時修正。云采用框架白皮書 文檔版本：1.0 65 5.1.2.風險治理的工作開展 合理地進行風險治理 在傳統 IT 治理中，有時會采用充分的前置防護。在業務正式上線之前，充分分析業務運營流程并評估潛在風險。將治理措施在中臺部署完成后，業務才上線運營。后續的業務管理流程只能使用事先經過治理審批的既定流程。而業務的迭代升級則需要進行新一輪的評估。這顯然不適用于當前的云計算環境，原因如下：企業上云是為了充分利用云的敏捷性和彈性，云上 IT 系統的運維變更是高頻且復雜

137、的。過度的治理會限制云上業務的敏捷發展，使風險治理團隊與業務團隊成為對立面。風險永遠存在，企業上云過程中的轉變其實會帶來更大的風險。但并非所有風險都需要被 100%規避，需要充分評估風險的實際影響，采取不同的應對方法。在上云的不同階段，或業務發展的不同階段，風險治理的要求是不同的。而在云上，各個階段的轉換很迅速，沒有風險治理團隊能一開始就探測到所有潛在風險，風險治理是需要跟隨業務的發展持續迭代的。所以，風險治理團隊需要在潛在風險控制、業務發展速度、IT 治理成本中找到平衡。在業務發展的不同階段，針對不同的風險采取不同的應對措施，持續迭代企業的風險治理策略。風險治理策略的起點 前序文章中說過，風

138、險是一直存在且不斷變化的，對于某個企業來說，在業務上云的不同階段、在云上發展的不同階段都會面臨不同于傳統 IT 的各種風險。那么，與之相應的風險治理也必將是一個迭代的過程。但萬事開頭難，在新項目中啟動風險治理比持續迭代一套風險治理策略更難。在沒有明確的業務邏輯前，很難有靶向地制定風險治理策略。此時，需要先定義一個無業務傾向性的起點治理基線。企業應根據初上云的業務實際情況來制定起點治理基線，需考慮初上云業務的業務性質、云上運維人員數量、需托管的云上 IT 規模等。以下提供較通用的基線策略，可以作為參考：限定云上可采購的資源白名單和規模上限。資源必須具備基礎標簽，如歸屬部門、歸屬計費單元、SLA

139、承諾、歸屬環境、歸屬 owner 等。限定可以創建資源的區域。限定可管控資源的白名單用戶和白名單角色列表。保障運維可行的情況下，保證最小人群具備采購和釋放的權限。最小權限管理原則，高危權限需嚴格審批。強制遵從強密碼策略。必須開啟基礎計算、存儲資源的刪除保護功能。云采用框架白皮書 文檔版本：1.0 66 必須關閉關鍵計算、存儲資源的公網訪問。風險治理策略的迭代 企業規劃上云時，最初可能會將一些內部平臺和運維系統搬遷上云，此時往往不涉及核心業務，所以不需要過多考慮數據防護、網絡防護、災備機制的問題，只需要通過起點治理基線避免過度采購、過度授權的風險。但隨著企業將核心業務搬遷上云，核心業務又在云上得

140、以大規模發展，在此過程中就需要逐步考慮更多潛在風險并基于起點治理基線不斷地升級風險治理策略。幾個主要的治理基線 身份權限治理基線 通用安全治理基線 數據安全治理基線 成本控制基線 業務連續性基線 小結 IT 風險治理的初衷是為了更好地支持業務發展而不是讓業務束手束腳，在企業發展過程中的每個環節采用充分且合理的管理策略尤為重要。當前，云上業務的發展迅速且多變，IT 風險治理也隨業務快速迭代。企業的IT 風險治理團隊只有與業務團隊、運維團隊緊密合作、充分溝通，才有可能保持對業務風險的充分判斷和合理規避。5.2.阿里云上的治理基線 5.2.1.身份權限基線 身份權限管理是為了縝密地識別、驗證和授權個

141、人、用戶組或角色，并為其授予云上 IT 的適當訪問權限。身份權限治理基線可以認為是云上 IT 風險治理的第一步，無論企業最先安排哪部分業務上云，企業對云上賬號、角色、權限的風險治理都需要率先制定章程。后續隨著業務的飛速擴張，云上的賬號體系也必將越來越復雜。且業務上云后，傳統 IT 中的中心化托管不再適用，中心運維團隊需要下放運維身份和權限給業務團隊，以支持更靈活的運維模式。在上云最初制定并實施治理基線，可避免在規模壯大后可能出現的人員冗雜、權限難以梳理、賬號無法清退的困境。避免因低效混亂的賬號管理遭受惡意訪問和攻擊。例如：某知名證券企業在上云之初時，僅在云上部署測試單元，共注冊了 3 個主賬號

142、分別用作測試賬號、生產賬號和審計賬號。在沒有具體業務上云的情況下，事先在云上實施了身份權限的風險治理。具體要求如下：云采用框架白皮書 文檔版本：1.0 67 僅允許白名單內的 RAM 用戶和 RAM 角色在云上進行管控操作。那么，即便 RAM 用戶和 RAM 角色被創建出來，也可以利用白名單約束其活動。根賬號和具備較高權限的 RAM 用戶必須開啟多因素認證（MFA）認證，強制高權限 RAM 用戶必須開啟多因素認證。必須采用強密碼策略。當認證協議和密碼策略發生變更時需收到告警，這是對身份權限管理策略的強監管。將所有賬號的操作事件統一歸集到權限隔離的審計賬號，并做安全分析。該企業在后續長期的運營中

143、，主賬號增長到 15 個，活躍的 RAM 用戶超過 70 個。中心運維團隊下放管控權限給業務團隊和第三方服務商。在企業內部建立了一套用戶身份變更管理流程，當發生人員離職、人員組織架構變動、人員變更歸屬項目時，分別對云上 RAM 用戶、權限以及所屬的用戶組進行變更，實現云上身份權限的縝密管理。應對的風險 不同的企業管理模式可能導致身份權限管理中面對不同的風險，常見的風險如下：高權限風險?；钴S的管控賬號直接為主賬號或具備管理員權限的 RAM 用戶，可能給運維人員的誤操作提供了更大的空間，對資源錯誤的變更、釋放、主機升級都可能造成業務中斷。較弱的認證機制和密碼策略。這可能增加賬號被盜用的可能性，進而

144、遭到惡意破壞和數據竊取。閑置的有效賬號。長期閑置的具備一定權限的賬號可能是離職員工的曾用賬號，閑置賬號不及時回收可能成為安全管理的盲區，被惡意利用。缺乏操作審計監管。企業不監控和收集云上的訪問事件，將無法及時發現訪問事件背后的惡意意圖，如高頻的登錄失敗、無權限訪問、異常訪問等。在真正發生惡意操作后也難以復盤和追責。隨著業務的發展壯大，云上的 IT 管理人員、IT 規模、業務復雜度都在成倍增長，企業應周期性審視身份權限管理的風險辨識，及時更新風險的定義并推進風險治理策略的升級實施。治理基線 企業應根據云上運維人員數量、運維人員的工作邊界、需托管的業務數量、需托管的云上 IT 規模、具體托管的業務

145、內容等實際情況來制定自己的身份權限治理基線，以下提供較通用的基線策略，可以作為參考：賬號基本安全 o 為主賬號的登錄行為開啟多因素認證（MFA）。o 避免在應用程序中使用主賬號訪問密鑰（AK），應禁止存在主賬號訪問密鑰（AK）。使用訪問控制 o 避免直接使用主賬號管控資源，應通過創建 RAM 用戶并合理授予最小必要權限來進行云上管控。云采用框架白皮書 文檔版本：1.0 68 o 為所有 RAM 用戶的登錄開啟多因素認證（MFA）。o 限定云上活躍的 RAM 用戶和 RAM 角色白名單。o 必須采用強密碼策略。密碼有效期不超過 90 天。密碼最小長度不小于 8。密碼中必須包含大小寫字母、數字、特

146、殊符號。禁止設置使用過的密碼。一小時內最多允許 5 次密碼輸入錯誤。o 應對用戶組授權，避免直接給 RAM 用戶授權，通過用戶組管理 RAM 用戶。o 僅為指定的有限人員設置管理員權限，并嚴格禁止企業內多人共享一個 RAM 用戶。充分審計 o 將所有操作事件統一歸集到獨立的審計賬號，由專職的審計人員管理，與運維人員權限隔離。o 基于操作事件實現持續的安全分析。o 當發現認證協議和密碼策略發生變更時需收到告警。o 當主賬號有操作行為時收到告警。o 定期對比 RAM 用戶實際發生的操作行為和已獲得的授權，避免過度授權。持續治理 o 使用云上具備持續監控和持續檢測能力的治理工具。o 開啟云平臺推薦的

147、治理基線，結合企業自身實際需求實現自定義策略。5.2.2.數據安全基線 識別數據泄露風險 企業遷移上云后，IT 系統對數據的存儲、傳輸、處理方式與云下有巨大的差別。數據使用模式的變更會使企業面臨潛在的數據泄露風險。如何防范數據泄露也是眾多企業在核心業務上云后最關心的問題之一。數據泄露可能迫使企業面對業務終止、輿論危機、財務損失、法律責任和巨額罰款。國家近年也在不斷完善個人信息保護的相關法律法規，強調企業在保護個人信息上的直接責任，對企業提出明確的綱領要求和系統技術要求。同時，也在建立制度對企業的數據安全水位進行監督測評，并明確對一些數據泄露情節的處罰制度，涉及到巨額罰款或業務終止。云采用框架白

148、皮書 文檔版本：1.0 69 可見，真實的數據泄露事故和任何疑似泄露的輿論新聞均會對企業造成實質損害。企業在評估數據泄露風險時應關注以下方面：國家法規和行業標準對企業 IT 系統的數據安全要求。來自企業外部的惡意攻擊和非法爬取。來自企業內部的誤操作或惡意操作導致的數據泄露。數據泄露風險的治理策略 風險治理策略的設計與企業采用的數據安全框架緊密相關。數據安全框架是指在數據管理的整個生命周期內采購合理的技術手段和平臺服務以構建安全能力，這是一種安全決策。而相應的數據風險治理是確保在長期運維過程中，IT 系統的配置和變更始終符合安全決策的要求。數據安全框架 企業想要實施有效的數據防護措施需要從管理制

149、度和技術策略兩個角度來考慮。云平臺會為數據管理生命周期的每個環節提供安全能力，但對于安全能力的正確采用、準確實施都需要依賴企業內部有對應的組織架構、安全制度、內建流程的支撐。在企業內部，應該有專職的安全團隊統籌整個企業的數據和應用安全，識別潛在的安全風險并制定安全決策。安全決策應該包括基本的安全規范、安全等級標準、安全防護 IT 采用方案、內部權限管理流程等。安全團隊還需要制定與業務團隊、運維團隊的交互流程和協作機制，確保安全決策在可見、可控、可監管的前提下得以實施。在技術方面，針對數據管理生命周期的各個環節要采取對應的防護措施，在數據的使用中做到及時掃描、完備防護、可審計、可檢測、及時響應、

150、可溯源。下圖為數據管理的生命周期及需要采取的技術手段。云采用框架白皮書 文檔版本：1.0 70 數據泄露風險治理框架 安全小組制定了安全決策后，安全決策一部分直接轉變為 IT 安全部署的指導策略，即企業 IT 系統的安全架構要求，比如采購防火墻、采購敏感數據保護服務。還有一部分會轉變為治理策略，即安全小組在長期的業務運營過程中用來監督安全架構被正確實施的監管框架，比如是否每個云賬號都開啟了防火墻。數據泄露風險的治理框架取決于數據安全框架。企業會根據真實情況在數據管理的生命周期內制定不同的防護方案。以下提供較通用的治理策略，企業可根據實際情況選用：對業務數據進行關鍵性分級分類，并隔離存儲。為存儲

151、核心重要數據的存儲服務實施敏感數據管理，包括敏感數據識別、敏感數據的脫敏引用等。開啟數據存儲服務的靜態數據加密。為存儲服務開啟備份策略，制定明確的數據恢復 RTO、RPO。禁止匿名的數據訪問。禁止公網數據讀寫。對數據的寫入權限和讀取權限管理遵循最小權限原則，并定期復查授權情況，避免冗余授權。確保完整收集所有數據訪問和寫入的日志。實時監控數據訪問行為，周期性復盤和分析數據訪問日志，及時發現可疑的數據訪問。企業內部定期復盤治理策略，確保滿足業務的數據泄露風險治理需求。企業應根據業務的發展不斷升級與加固 IT 安全框架，同時迭代相應的治理框架。云采用框架白皮書 文檔版本：1.0 71 5.2.3.通

152、用安全基線 安全是企業 IT 架構永恒的核心話題，企業的安全團隊應根據企業業務上云后可能面對的安全風險制定安全決策。安全決策將演變為云上的 IT 安全采購策略和安全架構，對企業云上的網絡、應用、主機、數據提供安全防護。而安全治理基線是企業需要在云上采用的一種持續監控和治理的手段，以保證安全策略被正確完整的實施。企業從云下的專有域遷移到公有云的互聯社區，使企業面對的安全環境變得更復雜。企業上云后將云下 IT系統搬遷上云，這種變化給企業帶來彈性伸縮的便利性，但同時也增加了企業對公網的資產暴露。企業上云過程中對數據的存儲、處理、傳輸方式均發生變化，這增加了數據泄露的風險。在上云最初制定明確的安全決策

153、和安全策略并實施安全治理基線，這可以企業保障安全策略的持續執行，使云上 IT 始終在云安全能力的縱深防御中，使企業擁有比云下更安全的防御深度。例如，某知名游戲公司將業務單元搬遷上云時就制定了較高的安全策略并啟動相應的治理基線。具體要求如下：所有資產按關鍵程度和存儲數據的敏感度進行標記。開啟數據存儲服務的靜態數據加密。包含重要數據的網絡應與其他子網隔離，并定期審視流量。所有公網端口，必須設置自動 DDoS 防護。為所有業務應用開啟防火墻功能。企業在后續飛速地業務擴張中，以治理基線約束每個業務應用的安全部署，確保主機、網絡、數據、應用始終處于安全防護中，實現安全上云的目標。應對的風險 企業應從網絡

154、、應用、主機、數據四個維度充分評估上云風險。網絡安全風險：虛擬化網絡的多層化使網絡架構的實施和網絡策略配置更復雜，外連的多樣性使組織內部網絡架構梳理變得困難。若配置不當會讓黑客更容易實施橫向攻擊，使業務大面積受損。且上云使企業被攻擊的可能性大幅增加。應用安全風險：應用上云后更容易受到惡意訪問，云上攻擊的成本和實施門檻均降低。云采用框架白皮書 文檔版本：1.0 72 主機安全風險：上云后主機會被更頻繁的變更，且大多數企業上云后會弱化前序的審批環節，這使變更本身潛藏復雜的風險。上云后增加了主機的暴露率，更容易被電子貨幣等業務攻擊和侵占。主機弱點及配置不當會帶來安全漏洞和資產損失。數據安全風險：數據

155、的采集、傳輸、存儲、處理的環境和方式均發生變化，使企業面對更大的數據泄露風險。企業必須對業務敏感數據、用戶隱私數據做充分識別和特殊保護，確保遵循國內國際的數據保護條例。治理基線 安全治理基線的設計與企業采用的安全決策和架構有緊密關系。安全決策決定了云上 IT 安全架構和采購策略，決定了云上啟用的安全技術手段和安全服務。而相應的安全治理基線是確保在長期持續的 IT 管理中需要采用的一種持續監控和治理的手段，以保證安全策略被正確完整地實施。假設下圖為企業通用的云安全采用框架：以下提供較通用的治理策略，企業可根據實際情況選用：為面向公網的 IP 啟用 DDoS 高防，清洗流量型和資源耗盡型 DDoS

156、 攻擊，隱藏被保護的源站服務器。為業務開啟云防火墻，管理互聯網到業務的訪問控制策略（南北向）和業務與業務之間的微隔離策略（東西向），進行流量監控、精準訪問控制、實時入侵防御。為應用開啟防火墻防護外部訪問風險，防御各類 OWASP 常見 Web 攻擊并過濾海量惡意 CC 攻擊，避免網站資產數據泄露。在云上建立安全中心或啟用安全中心，開啟主機內的安全基線監控，如威脅檢測、漏洞掃描、補丁升級、入侵檢測等，確保開啟了安全告警 網絡入網網段不能是全網段，且需限制 22 和 3389 等風險端口的開啟，設置最細粒度的入網控制策略 開啟網絡流量日志的記錄 隔離網絡之間的路由遵從最小夠用原則 云采用框架白皮書

157、 文檔版本：1.0 73 確保系統盤和數據盤啟用加密 5.2.4.業務連續性基線 業務連續性側重強調在長期的云上運營過程中保證業務不中斷。業務中斷是 IT 運維中較常見的事故，與數據泄露等風險不同，業務中斷并不存在僥幸。一旦發生業務中斷企業將即刻面臨實際的業務損失，業務恢復所耽誤的時間越長損失就會越大。且伴隨著停機造成的直接盈利損失，還有客戶信心流失、信譽損傷、名譽損傷，甚至影響更廣泛的商業合作的達成。企業應在重要業務上云之前優先制定能保障業務連續性的合規治理基線，確保重要業務上云之后不會因誤操作、防護不足、負載激增等導致業務中斷，同時也要確保真有中斷發生的時候能快速恢復，盡可能減少因業務中斷

158、所造成的損失。應對的風險 企業應考慮以下風險可能影響業務連續性：不連續的資源管理風險。無人為操作，因業務依賴的 IT 資源欠費導致的資源自動釋放，致使業務中斷。誤操作風險。運維人員錯誤的大量刪除 IT 資源，致使業務中斷。突增的負載。大多數互聯網業務普遍存在所謂“高峰期”，對高峰期預判不足，可能導致因負載過量而業務中斷。超長的恢復時間。當業務中斷真實發生時，如果沒有預設備份機制和快速的災后恢復機制，會導致業務中斷的時間數倍延長，這期間的業務損失是幾何倍的增長。治理基線 企業應根據實際業務性質決定采用的治理策略，尤其是對公網防護能力、備份恢復能力、彈性能力的選擇，這些將帶來較大的成本。以下提供較

159、通用的基線策略，可以作為參考：根據 IT 所承載的實際業務，對 IT 資源進行關鍵性分級，對于承載關鍵業務、會影響重要客戶或大量客戶、業務本身需要較高穩定性 SLA 的 IT 資源進行標記。并對不同關鍵性層級的 IT 資源區分采取不同的治理策略。對于關鍵性的 IT 資源應開啟自動續費并確保賬號中有足夠的余額，或設置資源到期提前提醒及時續費，避免因欠費而停機中斷。在全局保證最小人群具備刪除資源的權限，避免權限泛濫提升誤操作的概率。刪除資源等影響業務連續性的關鍵操作應要求必須開啟 MFA 認證，執行高危操作時增加多元認證確認。為關鍵性較高的計算、網絡、存儲、數據庫資源開啟釋放保護，避免來自自動腳本

160、的誤刪除。云采用框架白皮書 文檔版本：1.0 74 為面向公網的 IP 啟用 DDoS 高防，清洗流量型和資源耗盡型 DDoS 攻擊，隱藏被保護的源站服務器。為業務開啟云防火墻，管理互聯網到業務的訪問控制策略（南北向）和業務與業務之間的微隔離策略（東西向），進行流量監控、精準訪問控制、實時入侵防御。為應用開啟防火墻防護外部訪問風險，防御各類 OWASP 常見 Web 攻擊并過濾海量惡意 CC 攻擊，避免網站資產數據泄露。實時監控關鍵性 IT 資源的負載，計算、網絡等核心資源的負載應始終保持在 80%以下，避免因負載過重導致業務中斷。采用彈性擴容縮容的運維方案，在業務高峰期快速擴容確保穩定性。為

161、每個業務制定明確的 RTO 和 RPO，采取能滿足容災要求的備份機制和恢復機制。對核心業務的數據平臺制定高頻率備份和多區域復制 為關鍵性業務虛機啟用熱備份和高可用模式 企業應根據業務的發展不斷升級與加固穩定性防護和災備機制，同時迭代相應的治理框架。云采用框架白皮書 文檔版本：1.0 75 6.結束語 本云采用框架白皮書始終關注于企業在業務目標和云采用目標達成一致，在云采用的生命周期：上云戰略、上云準備、應用上云和運營治理四個階段為企業提供業務和技術策略指導，幫助企業從組織、人員和技術層面著手采取行動，確保云采用的價值最大化和風險最小化。本云采用框架白皮書是阿里云產品團隊、全球交付團隊服務眾多企

162、業客戶將業務落地在阿里云的設計和實施經驗總結，因此特別感謝這么多給予我們信任、幫助我們改進的客戶。由于時間緊迫和視野局限，第一版本的云采用框架白皮書在一些觀點和方法上還有紕漏和瑕疵，我們也非常歡迎您將意見和建議反饋到官網（https:/ 文檔版本：1.0 76 7.基本概念 概念 說明 訪問控制 訪問控制（RAM）是阿里云提供的管理用戶身份與資源訪問權限的服務 阿里云賬號（主賬號）開始使用阿里云服務前，首先需要注冊一個阿里云賬號，是阿里云資源歸屬、資源使用計量計費的基本主體 身份 訪問控制（RAM）中有三種身份：RAM 用戶、用戶組和 RAM 角色 RAM 用戶 RAM 用戶有確定的身份 ID

163、 和身份憑證，通常與某個確定人或應用程序一一對應 用戶組 用戶組是 RAM 的一種實體身份類型，用戶組可以對職責相同的 RAM 用戶進行分類并授權，從而更好的管理用戶及其權限 RAM 角色 RAM 角色是一種虛擬用戶，RAM 角色有確定的身份，可以被賦予一組權限策略，但沒有確定的登錄密碼或訪問密鑰 默認域名 阿里云為每個賬號分配了一個默認域名，格式為 賬號別名（企業別名）每個阿里云賬號可以在 RAM 中設置一個全局唯一的賬號別名。賬號別名主要用于 RAM 用戶登錄，登錄成功后可作為顯示名 域別名 如果您持有公網上可以解析的域名，那么您可以使用該域名替代您的默認域名，該域名稱為域別名。域別名就是

164、指默認域名的別名 訪問密鑰 訪問密鑰指的是訪問身份驗證中用到的 AccessKey ID 和 AccessKey Secret 多因素認證 多因素認證（MFA）是一種簡單有效的最佳安全實踐，在用戶名和密碼之 云采用框架白皮書 文檔版本：1.0 77 外再增加一層安全保護 服務提供商 指利用 IdP 的身份管理功能，為用戶提供具體服務的應用 身份提供商 是一個包含有關外部身份提供商元數據的 RAM 實體，它可以提供身份管理服務 安全斷言標記語言 安全斷言標記語言（SAML 2.0）是實現企業級用戶身份認證的標準協議，它是 SP 和 IdP 之間實現溝通的技術實現方式之一 單點登錄 阿里云支持基于

165、 SAML 2.0 的單點登錄，也稱為身份聯合登錄 元數據文檔 元數據文檔由企業 IdP 提供，一般為 XML 格式，包含 IdP 的登錄服務地址、用于驗證簽名的公鑰及斷言格式等信息 SAML 斷言 SAML 協議中用于描述認證請求和認證響應的核心元素。例如：用戶的具體屬性就包含在認證響應的斷言里 OAuth 應用 獲取用戶授權，并獲取代表用戶身份的令牌，從而可以訪問阿里云 OAuth 范圍 OAuth 2.0 服務通過 OAuth 范圍來限定應用扮演用戶登錄阿里云后可訪問范圍 權限策略 權限策略是用語法結構描述的一組權限的集合，可以精確地描述被授權的資源集、操作集以及授權條件。資源 云服務呈

166、現給用戶與之交互的對象實體的一種抽象，例如：ECS 實例等 限制條件 權限策略基本元素之一，表示授權生效的限制條件 操作 權限策略基本元素之一，表示對具體資源的操作。取值為：云服務所定義的 API 操作名稱 效力 權限策略基本元素之一，表示授權效力。取值為：允許或拒絕 云采用框架白皮書 文檔版本：1.0 78 被授權主體 指策略中定義的權限主體，被授權主體可以為 RAM 用戶、用戶組或 RAM角色 資源目錄 阿里云面向企業客戶提供的一套多級賬號和資源關系管理服務 標簽 標簽是云資源的標識，可以幫助您從不同維度對具有相同特征的云資源進行分類、搜索和聚合，讓資源管理變得更加輕松 資源共享 指多賬號

167、間通過共享的方式將一個賬號指定資源共享給一個或多個目標賬號使用 資源所有者 資源所有者是資源共享的發起方，也是共享資源的擁有者 共享的資源 共享的資源通常為某個云服務的某類資源。例如：專有網絡的交換機 資源使用者 資源使用者是資源共享的受益方，對共享的資源具有特定的操作權限 共享單元 共享單元是資源共享的實例。共享單元本身也是一種云資源，擁有獨立的ID 和 ARN 資源組 資源組在阿里云賬號下進行資源分組管理的一種機制 資源夾 資源夾是資源目錄內的組織單元，通常用于指代企業的分公司、業務線或產品 企業管理賬號 企業管理賬號是資源目錄的超級管理員，也是開通資源目錄的初始賬號 操作審計 操作審計幫

168、助您監控并記錄阿里云賬號的活動，包括通過阿里云控制臺、OpenAPI、開發者工具對云上產品和服務的訪問和使用行為 影子跟蹤 如果您創建跟蹤的同時追蹤了多個地域的操作事件，則操作審計會在相關地域創建相同配置的跟蹤來收集這些地域的操作事件，這種跟蹤叫做影子跟蹤 平臺事件跟蹤 平臺事件跟蹤是阿里云賬號創建的用于記錄平臺操作事件的跟蹤 云采用框架白皮書 文檔版本：1.0 79 跟蹤 通過設置跟蹤將操作事件保存到指定的 OSS 存儲空間和 SLS Logstore下，便于進一步分析和存儲 Home 地域 Home 地域是發起創建跟蹤操作的地域 全局事件 全局事件是全局服務的操作事件。在操作審計控制臺的事

169、件查詢頁面，選擇任意地域均可看到全量的全局事件 全局服務 全局服務是不區分地域的服務，例如：RAM。全局服務會產出全局事件 平臺操作事件 平臺操作事件是阿里云運維團隊針對用戶服務的維護操作所產生的事件。您可以通過平臺操作審計創建跟蹤，記錄此類事件 操作事件 操作事件是用戶通過阿里云控制臺、OpenAPI、開發者工具訪問和管控云上服務所產生的事件記錄 配置審計 一項資源審計服務，為您提供面向資源的配置歷史追蹤、配置合規審計等能力 等保預檢 等保 2.0 預檢為云上的合規檢測，為您動態且持續地檢測阿里云上資源的合規性，從而避免正式檢測時多次反復整改，幫助您快速通過等保檢測 合規時間線 規則評估在資

170、源配置變更發生時觸發，配置時間線會有一個對應的合規時間線，是每次合規評估結果的歷史記錄 規則 規則指用于判斷資源配置是否合規的規則函數。配置時間線 配置審計為您提供每個監控范圍內資源的配置時間線 資源配置詳情 配置審計通過云服務開放的資源查詢接口可獲取當前阿里云賬號下的所有資源 資源類型 資源類型是一組實體資源的歸類 云企業網 承載在阿里云提供的高性能、低延遲的私有全球網絡上的一張高可用網絡。云企業網可幫助您在不同地域 VPC 間，VPC 與本地數據中心間搭建 云采用框架白皮書 文檔版本：1.0 80 私網通信通道。轉發路由器 一個云企業網實例將在每個地域內創建一個轉發路由器作為您在每個地域內的網絡管理運維中心 專有網絡 VPC 用戶基于阿里云創建的自定義私有網絡，不同的專有網絡之間二層邏輯隔離，用戶可以在自己創建的專有網絡內創建和管理云產品實例 交換機 vSwitch 組成專有網絡的基礎網絡設備，用來連接不同的云資源實例 高速通道 EC 用于建立線下 IDC 和云上 CEN 間的私網通信通道，為客戶提供一條高靈活度、高質量和高安全性的跨網絡通信鏈路 智能接入網關 SAG 阿里云提供的一站式快速上云解決方案。企業可通過智能接入網關實現Internet 就近加密接入