多雲環境的BaseOps

本文將介紹在多雲環境下實行BaseOps的方法論。主要是介紹主要雲端供應商(以下簡稱CSP)關於BaseOps的基本概念，我們將從如何管理與套用最佳實踐在Landing Zone。本文的重點有:

• 了解BaseOps的基礎概念
• 運用Well-Architected與雲端採用(Cloud Adoption )原則
• BaseOps架構模式
• 使用政策來管理Landing zone
• 雲端中的責任界線

了解BaseOps的基礎概念

BaseOps可以解釋為basic operation。但在雲端環境的維運中，更多的是指cloud operations。BaseOps 主要是通過優化利用主要CSP在不同面向提供的雲端服務，以最有效的方式運營雲環境，如網路、運算、存儲，以及 PaaS 和 SaaS。

BaseOps的主要目標是確保確保雲端系統可供企業使用，並且可以安全地用於執行以下操作：

• 監控網路的量能與其路由的正確性
• 監控運算資源的量能並能及時調整已符合業務需求
• 監控儲存資源的量能並能及時調整已符合業務需求
• 監控資源的可用性，包含備份的狀況與確保有問題時系統可以備回復
• 監控系統的周邊和內部安全，確保資料完整性
• 在雲端上的系統隨時維持在規定的服務等級並使用業務層面的KPI來量測系統
• 如果系統能盡可能自動化，BaseOps 的一部分也能夠監控和管理pipeline

我們可以看到，上述的這些都是關於服務質量的議題。而服務質量是需要被量化的，這一類的KPI與Servie Level指標是從企業的業務目標衍生出來的。要完成BaseOps這一方法論，企業必須要有清楚的流程，足夠技能的員工與正確的工具。也就是我們常聽到的 — People, Process and Technology。

使用雲端的理由，相信大家都已經聽到耳朵長繭 — 足夠的資源彈性、敏捷性與成本效益。而要達成這一切則需要兩種紀律: 標準化與自動化。所有重複性的工作要能自動化。識別並並監控這些自動化作業是否以正確的方式執行是 BaseOps 的一部分。 自動化過程本身就是開發，但企業一開始有 DevOps 團隊的一個主要原因是，可以執行開發人員編寫的任何代碼。 就此而言，兩個團隊都有相同的目標：根據最佳實踐保護和管理雲系統。

要完成這個目標，需要透過以下的作業與活動。Well-Architected Framework將是一個方法論來取得建立雲端環境的需求。

定義與實行Landing zone

Landing zone是BaseOps領域中最重要也最基本的一個作業。Landing zone是一個我們將系統(應用程式、資料)放在雲端環境中一個想達成的雲端平台。建立Landing zone一個重要起始原則是 — 一切都是用代碼來建立其系統需要的環境。Landing Zone包含了許多建構區塊(Building Block)，這是可以達成一致化雲端環境的關鍵。更多的建構區塊概念可參閱本部落格TOGAF的系列文章。

首先，我們來定義一下什麼是Landing zone。 著陸區是開始在公有雲中構建環境的地方。 既然叫Landing zone，哪麼機場就是最好的比喻：如果要讓飛機著陸，我們就需要一個機場。 但機場不僅僅是一條長長的跑道與停機坪。 還需要某種形式的治理，例如空中交通管制員引導飛機飛向著陸跑道，並決定飛機降落的順序以保證飛機的安全。

這個比喻就非常清楚了，企業的系統就是哪一架架的飛機。我們在其他文章提到過，主要CSP提供了CAF(Cloud Adoption Framework)與WAF(Well-Architected Framework)來協助建立適合企業的飛機(系統)能夠降落的機場(Landing zone)。這些都是雲端架構師需要負責的工作。

定義Landing zone的標準與範圍

不論地端機房或雲端，老實說不外乎三種元素構成IT環境 — 運算、儲存與網路。唯一不同的是，地端機房有實體，但在雲端中，這些組件都是代碼。

在我們完成網路連結與誰可以存取(IAM)雲端之後，哪接下來就需要定義標準與政策來建立雲端環境(以安全的方式)。但要做的事有非常多，那些要先做呢?Landing Zone的好處在於讓我們辨識那些作業要優先進行。

根據經驗法則，Landing zone包含了以下5種元素:

• 網路
• 運算節點
• 儲存節點
• 帳號(給人用與機器用)
• 資安

而WAF也能協助我們建立這些作業。

運用Well-Architected與雲端採用(Cloud Adoption )原則

這一節，我們將檢視主要CSP(AWS, Azure與GCP)它們WAF與CAF來協助企業建立其Landing zone。更多三大雲的CFA可參閱本部落格"CAF雲端採用框架比較 — Part 1"一文及其系列文章。

Azure Landing Zone

微軟把Landing zone稱為管道(Plumbing)。從Azure的CAF來看，一個Landing zone應該會有"可擴充性、治理、安全、網路與身分管理"的最佳實踐。2020年，微軟出了一個企業等級的Landing zone，這是一個範本。這個範本是遵從"架構(八個領域)的角度與設計原則"，所以它能交付一個ready-to-go的Landing zone，微軟也稱它為Landing zone加速器(accelerator)。這個範本的架構8領域如下:

• Enterprise Agreement (EA) enrollment and Azure Active Directory tenants
• Identity and access management
• Management group and subscription organization
• Network topology and connectivity
• Management and monitoring
• Business continuity and disaster recovery
• Security, Governance, and Compliance
• Platform automation

這些架構中包含標準化的Azure 產品和服務，如PIM, WAF(web application firewall)與 Virtual WAN。這一個範本會有好幾個subscriptions來執行不同的任務:

• Identity subscription with Azure Key Vault
• Management subscription for monitoring and logging
• Connectivity subscription with Virtual WAN, and hub-and-spoke models
• Sandbox subscription for testing applications and services
• Landing zone subscription for production workloads with applications

這些sunscriptions都會在root management group與subscription organization的管控之下。以下為一個企業等級Landing zone示意圖:

AWS Landing zone

AWS使用它們自家的服務 — AWS Control Tower來建立Landing zone。Control Tower採用的是多帳號策略來管理AWS眾多的服務(這跟Azure是一樣的)。它使用AWS Organizations與AWS Service Catalog來建立Landing zone。

當我們佈署AWS Control Tower時，它會在AWS Organizations下建立兩個OU。一個是Shared service account，另一個是member account用來管理使用者帳號。AWS control Tower可以讓企業動態並能擴展且達成一致化的來建立與管理企業在雲端上的Landing zone。

GCP Landing zone

GCP提出有四種主要元素必需在Landing zone中:

• Identity provision
• Resource hierarchy
• Network
• Security controls

另外根據企業所在的產業或業務內容不同，也會有其他的元素加入，例如監控與日誌、備分與復原、合規、成本效益與控制、API管理還有Cluster Management。以下為一個IaaS需求的Landing Zone範例圖。

BaseOps架構模式

為企業的業務定義參考架構的一種方法是由外而內思考。 用下圖中所示的圓圈來思考架構。 Intrinsic security zone的下一層是business zone，所有業務需求和原則都聚集在這裡。 這些驅動下一個內圈：solutions zone。 這是我們定義解決方案組合的區域。

例如，如果企業需要分析大量資料（業務需求），那麼Data Lake可能是一個很好的解決方案。 Solutions zone介於Business zone和Paltform zone之間。 例如，如果我們將 AWS作為我們定義的平台，那麼我們可以將 AWS S3作為資料湖解決方案的一部分。 原則是從這些平台，也可以是第三方 PaaS 和 SaaS 平台，將解決方案對應到業務需求。 通過這樣做，我們建立了解決方案組合，其中包含構成每個解決方案的特定建構區塊(Building Blocks)。 這個模型的核心最內圈: Integration Zone，我們會從那裡管理其他外圈的整個生態系統。 安全性應該包含在每個圈中。 因此，整個模型的邊界由Intrinsic security zone設定：

上面這一張思考圖將定義架構的模式，從外到內工作。接下來，我們可以開始設置雲端環境中的各項基礎設施，從

• 網路 — VPC, vNets, subnets, internet-facing public zone, private zone, routing, NAT, NAC, ACL, LB, Network peering, Gateway, dedicated connection, DNS, network monitoring
• 運算 — VM, K8s, patch management, backup, monitor, logging等等
• 儲存 — Disk, object storage,DB等等

支援維運

當我們完成所有Lnading zone應該有的設置與相對應的機制之後，接下來就要進入維運階段了。我們需要搞清楚誰將執行所有這些任務（也就是員工的R&R）。 我們需要具備適當技能的人員來管理企業的多雲環境。 正如我們之前說過的，真正的 T 型工程師或管理員是不存在的。 大多數企業最終都會擁有一組開發人員和維運人員，他們都擁有通用和更特定的技能。

一些廠商將其稱為CCoE（雲端卓越中心），並將其標記為該企業的雲之旅或雲端採用過程中的重要一步。 此階段的一部分是確定此 CCoE 應扮演的角色，並讓 CCoE 的成員參與其中。 團隊需要能夠構建和管理環境，但他們也將在推廣新的雲原生解決方案方面發揮重要作用。PS:這大部分是大企業負擔的起的，中小企業更多靠的是SI來協助這一塊。

使用政策來管理Landing zone

在雲端中所有的一切都是由軟體和代碼定義的。 這使得雲端基礎設施可以很敏捷，但這也意味著我們需要一些嚴格的指導方針來管理代碼，從定義我們的Landing zone或基礎環境的代碼開始。 與 IT 領域的所有事情一樣，它也需要維護。 在傳統的資料中心和系統中，我們有維護的時間區間，可以更新和升級系統。 在雲端中，事情的運作方式有一些一樣。

首先，CSP會在需要時對其底層設備與軟體進行維護。 他們不可能與全球成千上萬的客戶就維護時段達成一致。 他們只是做一切需要做的事情來保持平台的健康並為改進和發布新功能做好準備。 而企業不希望受到這些維護活動的影響，因此他們必須確保其代碼始終安全。

我們需要考慮的下一件事是企業在部署在雲端平台上的自家系統。 這些資源也需要維護。 如果我們正在運行VM，我們將需要時不時地給它們上patch。 在這種情況下，我們正在修補代碼。 我們希望確保，通過這些活動，管理員不會意外地蓋掉某些安全設置，或者更糟糕的是，刪除資源實現的特定功能所需的Disk或任何重要代碼。 這是我們在設置Landing zone時必須從一開始就考慮的防呆措施。 從那時起，我們必須開始管理它們。 為此，我們需要政策和管理工具來進行管理。

Azure的基本維運管理

在Azure，我們使用一種稱作TDD(Test-Driven Development)方法。這是一種利用敏捷實踐增進代碼開發品質的方法，我們用這種方法用來發展Landing zone。如同我們之前講的，Azure 中的Landing zone通過重構(refactor)流程進行擴展，重構是一種建構Landing zone的迭代方式。Azure提供了以下數個工具來支援這種TDD方法:

• Azure Policy —
  這會根據我們所設定的規則驗證"即將"在 Azure 中部署的資源。規則可能是關於成本閥值、安全參數等，來檢查資源安全強化或一致性檢查。所以這可以預防一些重要的商業規則不能更改或佈署在雲端中，有防呆的作用。
• Azure Blueprint —
  這可以將要分配的角色與政策、ARM 模板與resource group組合成一個package。這個package就可以被重複使用用在多個Landing zone，我們可以看到Blueprints可以是企業在建立Landing zone的基本政策的實行。
• Azure Graph —
  剛剛提到，Azure用TDD的方式來建立與管理Landing zone。哪麼，我們就要去測試在流程的交互過程中是否成功的實行，資源是否用正確的方式被佈署與雲端環境是否有互操作性(Interoperability)。而Azure Graph能建立測試集來驗證Landing zone的配置。
• Azure Quickstart Templates —
  假如我們真的要再快一點Landing zone佈署(預設的設定)，哪這個工具可以協助我們在Landing zone佈署相關的資源。
• Azure Bicep —
  這是DSL(Domain-specific Language)，一種宣告式語法來進行資源佈署。也是Azure的IaC工具，用的是JSON代碼並驅動ARM(Azure Resource Manager)來佈署資源。

AWS的基本維運管理

AWS使用CloudFormation作為它們的IaC，也可以說是一種護欄，讓我們的雲端環境定在一個範圍內。AWS提了Policy Generator來產生這個護欄(JSON格式)，這個policy帶有四種原則功能，分別是policy type, conditions, meaning(當policy需要套用)。以下是可以使用的政策:

• Termination protection —
  這裡AWS指的是stack或是nested stacks的保護。這個功能可以保護資源被不小心或有意的刪除(不過預設關閉的)。
• Deletion policies —
  Termination protection保護的是整個stack，而Deletion policies保護的是特定的資源，不過它也有保留該資源的參數，或是對其做快照後再刪除等動作。要啟用它需要在Cloudformation中設定"DeletionPolicy"參數。
• Stack policies —
  這些策略被設置為定義整個stack或resource group的操作。 Stack policies是一種access control policy，這主要在通過防止update來保護關鍵基礎設施資源。 Stack policies應用在 AWS CloudFormation stack，這些stack是定義是基礎設施資源的模板。 例如，我們可能會使用stack policies來防止生產環境中組件（如DB or LB）配置的更改。

另外我們要再次提到Control Tower，這對我們在Landing zone一致性維運有著很大的幫助。它提供了一種儀表版讓我們知道維運Landing zone的狀況。

GCP的基本維運管理

GCP Landing zone的政策管理使用以下工具來進行基本維運：

• Organizations —
  這類似於Azure Policy的功能。例如，預設情況中GCP的VM沒有針對限制不能login到OS。但是我們可以用gcloud command: constraints/compute.requireOsLogin設置為True來限制login。
• Resource Policies —
  這也類似於Azure policy的功能。Cloud IAM policies以 JSON 或 YAML 格式對所有 GCP resource的access control。 每個policy都由bindings、audit配置和metadata來定義。Binding包含的是由member（就是identity）、role與condition組合而成的。member是一種identity：user、service account、資源或一組資源。 member綁定到定義member有那些權限的角色。 最後，我們必須確定member在什麼條件下可以執行其角色以及哪些限制是有效的。

然而，binding只是policy的一部分。 我們還有一個 AuditConfig 來記錄policy和metadata。 metadata中最重要的field是 etag。 etag 用於保證在GCP project中的各種資源中以一致的方式運用policy。 如果在一個系統上更改了policy，etag 可確保policy保持一致。 不一致的policy將導致資源部署失敗。

雲端中的責任界線

使用過雲端運算的人都知道甚麼是shared responsibility model，一種企業與CSP的責任界線。但是，我們需要在多雲環境中使用更細化的模型。 本文中一直在提到Policy，所以我們應該得出結論，在涉及到我們的多雲環境中的責任時，劃清界線並不容易。 即使在 SaaS 中，也可能存在解決方案需要遵守的某些安全和(或)合規策略。 甚至OS之類的東西也可能已經在資安強化方面引起一些問題，如，可以用第三方的監控方案在雲端平台中嗎？ 如果可以使用，哪會不會導致系統的overhead過大？ 簡而言之，多雲世界並不是非黑即白。 相反，多雲具有很多的方案可以使用。

那麼，我們如何取得適合我們企業的劃分模型呢？這就是架構面要做的事了。 首先，我們的多雲環境不需要全域管理員。 這是多雲的一個主要陷阱。 通常都有這樣的情況：DB admin需要全域管理權限才能執行某些操作，或者更糟糕的是，解決方案需要具有此類角色的service account。 而這通常都是IT人員只想圖方便不想遵守最小權限原則所開的後門。

所以我們才需要Policy， 我們可以使用PoLP(Policy of Least Privilege)。 這表明每個身份(Identity)都被授予執行分配給該身份的作業所需的最小訪問權限。 身份不一定是人類：它可以是雲端環境中的任何資源。

當我們講到User(指人類)時，我們可以用LPUA(Least-Privileged User Account)。 PoLP 是來保護資料，因為只有當User或身份被明確授予存取該資料的權限時才能存取。 它還有助於保持系統是良好的，因為它可以最大限度地減少系統中的風險或故障。 這些故障可能是無意的，也可能是惡意行為的結果。 我們應該始終遵循最小特權規則。

關於這個最重要的原則，現階段還需要考量更多因素。 "考量因素"轉化為"控制項"，並轉化為 BaseOps 一部分的可交付成果，因為它們絕對是多雲基本原則的一部分。 下面列出這些控制項和可交付成果：

控制項/交付成果 — 1

政策文件是存在與可用的，這份文件需要描述一般帳號與特權帳號在整個生週期中是怎麼產生的、維護的與廢棄或刪除的。這裡交付是政策與批准。

控制項/交付成果 — 2

RBAC 授權矩陣可用於描述資料或系統所有者的存取授權。這裡交付的是 授權矩陣。

控制項/交付成果 — 3

使用者帳號的產生是依據LPUA所設立的批准程序產生的。這裡交付的是使用者帳號清單。

控制項/交付成果 — 4

定期檢查帳號能持續地確保帳號的有效性(如是不是還作用中)與正確性(如是不是正確的角色權限)。這裡交付的是檢查清單。

控制項/交付成果 — 5

未經授權或嘗試的系統或資源的存取會被記錄下來，並且整理成報告定期回報給CISO或資安主管。這裡交付的是這些未經授權的存取報告。