【DBS客座文章】6國跨雲15000套系統組態管理如何自動化？星展大公開

本文為【星展銀行授權轉載文章】
譯註：文中所稱之「我們」、「DBS」、「星展銀行」或「星展」皆係指新加坡星展銀行，所提及之金融服務亦為新加坡國內之服務。
作者：Edwin Caliwag 資料科學及資料分析主管／新加坡星展銀行資訊暨營運處 / 中文校閱：周鈺軒
原文出處：Automating Configuration Management at Scale

星展銀行的安全性組態管理涉及許多合規 / 法令遵循面的檢查和準則，這些都是國際組織為了加強整體安全性而制定。我們將這些安全性組態定義轉換成一項自動化能力，可以掃描銀行內部伺服器，以發現不符合規範的情況並進行改正。流程如圖 1 所示。

圖 1 安全性組態管理流程

本文將探討如何透過自動化克服安全性組態管理的挑戰。我們開發出一套內部安全系統 SecureSys，可以實現端到端安全的一致性。我們將特別著重於以下兩點：

a) 實現自動化並讓我們可以擴充此組態管理的架構。

b) 詳細說明治理組態管理的流程，以及如何在整個流程中套用自動化，從政策管理、實施（自動修復）、報告與偏差處理。

星展銀行安全性組態管理的簡要歷史

2018 年以前，安全性組態管理是手動流程，包括定期產生報告、審核報告以及後續在循環週期之間修復安全性組態。此一端到端之間的工作由大約 13 人的團隊來維護。隨著我們使用的伺服器數量逐年增加，這種冗長的掃描和報告流程所耗費的時間也隨之增加，導致我們必須尋找和開發新的解決方案，才能更有效率地管理流程。

圖 2 SecureSys 框架

SecureSys 是支撐自動化的整體框架，是高度客製化的安全性組態管理方法。圖 2 說明 SecureSys 中的 5 個元件，每個元件彼此緊密結合。

1.入口網站是閘道，讓使用者存取三個引擎所提供的自助服務功能。

2.政策引擎（Policy Engine）處理節點對政策的訂閱和後續實施。

3.報告引擎提供掃描報告的收集和檢視。

4.偏差引擎管理與處理例外和偏差相關的工作流程。

5 .Puppet作為自動化協調器引擎以及所有其他元件的後端支援。

此自動化功能被套用在大約 18,000 個作業系統 (OS) 和 15,000 個子系統（即資料庫和中介軟體），包括星展銀行在 6 個國家的分行與子行內部部署資料中心和公用雲端環境。(註: 台灣未使用此系統)

 

圖 3 需要安全性組態檢查的系統和子系統的複雜性

自動化協調 (Puppet)

我們發現，為了適應內部流程，需要大量的客製化以將安全性組態管理自動化。經過多輪評估後，我們將選擇範圍縮小到一個特定工具 — Puppet。Puppet 提供管理政策實施和回復至基準安全性組態的能力，同時也能處理偏差。

圖 4 Enterprise Puppet 架構

圖 4 說明為了支援區域架構而建立的整體 Enterprise Puppet 架構；既簡單又具有高擴充性。Puppet 共分成 3 層：

a) 最上層是 Master of Masters (MOM)，此元件有 2 個執行個體以提供高可用性（主動被動）。MOM 的角色是協調和管理編譯主控端、用於管理代理程式註冊和通訊的憑證授權單位、執行協調服務以及管理 Puppet 資料庫。

b) 第二層的編譯主控端用以執行 Puppet 程式碼建構並將程式碼編譯成目錄。它處理代理程式必須在端點上執行的任務編譯。目錄執行的結果和目錄在這些編譯主控端之間同步。這些編譯主控端位於負載平衡器之後，負載平衡器允許水平擴充基礎架構，以支援更多代理程式來處理目錄要求。如果必須擴大 Puppet 基礎架構的涵蓋範圍，只需增加新的編譯主控端即可。

c) 第三層由在各個伺服器上執行的端點中的代理程式組成。代理程式透過內部憑證機制完成驗證並執行兩個服務：Puppet服務，它是主要的代理程式精靈，以及 PXP 服務，它能夠在遠端節點上執行操作。

利用這種 3 層方法，我們可以在公用雲端建置架構時輕鬆擴充架構。透過公用雲端自動擴充十分容易，因為只需使用 AMI 和映像本身上的應用程序，就能啟動和關閉編譯主機（AMI 本身的建構是透過自動化 AMI 管道來完成）。

內部部署擴充能力屬於半自動，透過容量管理加以處理。就我們的檢查數量而言，具有 4 個 CPU 和 16GB RAM 配置的編譯主控端可支援 1000–1500 個節點。

政策引擎

回顧圖 2，有3 個不同的引擎位於 Puppet 自動化協調器上，其中第一個是政策引擎。代理程式允許伺服器根據透過 Puppet 來訂閱群組定義的政策、針對伺服器執行這些政策、報告其狀態並自動實施標準。設定策略後，我們預設將 Puppet 封裝為屬於伺服器標準組建一部分的分層產物。所有 OS 平台都配備代理程式並設為自動註冊至 MOM 並取得指派至其設定檔的政策。

雖然我們已建立許多政策參考，但我們來檢視與組態管理相關的政策脈絡。凡是在生產環境中發佈的軟體，都必須檢查以確保符合企業的安全標準。

這些安全標準仿照其他組織的做法成功經驗或國際公認的安全標準，例如新加坡的國防資訊系統局 (DISA) 的安全技術實施指南 (STIG)。STIG是將安全協定標準化以提高安全性的準則。這些準則也被轉譯成適用於星展銀行 脈絡的作法，尤其是用在軟體組建上設定的組態和設定。如此可確保所有部署的組態設定一致。政策數量從 5 個到 200個不等，視平台的複雜性而定。大多數的政策每 30 分鐘執行和實施一次，但此參數的配置取決於您可以承受的風險容許程度。

範例：

為了實際了解，我們看看根據結果 V-72301 並且被視為「高」嚴重性的 STIG 準則之一，指出「如果作業支援不需要，則 Red Hat Enterprise Linux 作業系統不得安裝簡易檔案傳輸協定 (TFTP) 伺服器套件」

上述結果的解析有 2 個層次：

1.不得在伺服器上安裝套件 — 由於所有伺服器組建都是標準並且自動化的，因此，已從映像本身中移除 TFTP 套件。

2.為了多增加一層安全性，我們必須確保即使安裝套件，系統也不得允許啟用服務。實際上的方式則是確保在 /etc/services 檔案中停用（註解）服務。

我們檢查圖 5 中的程式碼，程式碼一般分成 3 個主要區段。

A.第一個區段（第 14–17 行）是Keys Section，在其中稱為 hiera 的全域組態檔中定義常數值。在 hiera 檔案中設定的值用以比較與系統的執行階段值與標準組態值。

B.下一個區段用來檢查此檢查所需的操作模式。定義 2 個模式，「noop」是 no operation 的縮寫，通常在 Puppet 中執行「notify」操作，允許擷取用於報告的實際組態值。「fix」模式執行「auto-healing」。在此模式下，將修正組態與基準或核准偏差值的任何偏離。這些模式可讓我們明確控制必須自動修復哪些檢查。

C.最後一個區段處理要為「noop」和「auto-healing」模式執行的實際操作。請注意，在自動修復子句中，呼叫名稱為 replace_matching_line_with_backup 的副程式，在此例中，該副程式備份 /etc/services 檔案並註解排除 TFTP 服務的 TCP 和 UDP 行。

圖 5 TFTP 服務停用程式碼

我們已熟悉程式碼的結構，下一個挑戰是跨不同的平台為 1,000 多個組態檢查編寫程式碼（用於 noop 和 auto-healing 操作）。為了協助此流程，開發和部署遵循 CI/CD 框架。開發人員和 SME 使用根據平台細分的內部 bitbucket 儲存庫來儲存 Puppet 程式碼。有多個分支以支援跨不同環境的針對性部署。所有原始碼合併都會經過審核，一旦獲得核准（合併程式碼），就會觸發 web 勾點將程式碼部署至 MOM 以便稍後複製到編譯主控端，將部署流程自動化。此功能可加快新政策或強化政策的上市時間並允許平行部署。

報告引擎

管理主控台是 Enterprise Puppet 的功能之一。它是用於管理整個基礎架構的網頁應用程式，包括憑證授權和資料庫。我們先向組織中的使用者宣布，此主控台會導入複雜的角色存取控制。僅使用預設權限，是無法做到控制使用者可檢視和執行的內容。然而，我們對使用者主控台的目標是，讓使用者能夠在系統上檢視他所管理的安全性報告，允許他們啟動自動修復功能（對於仍處於 noop 的伺服器）並管理偏差。因此，我們的團隊開發出主控台的衍生版本，我們稱之為 SecureSys（安全系統）。SecureSys 入口網站主要處理報告和偏差管理功能，並以 Puppet 資料庫為基礎。入口網站中定義多個使用者角色，從執行管理階層到稽核員、資訊安全人員、風險管理者、系統管理員、技術支援和應用程式團隊。這讓我們能夠根據位置和業務單位提供自訂主控台檢視。入口網站提供各個端點的報告和需要修復（如果需要）的單一檢視。

圖 6 SecureSys 中的報告表格

上表是顯示每個節點的合規性狀態的摘要報告。請注意，就強制性政策而言，偏差數為 0，因為在這些機器中啟用並實施自動修復。目前，強制性（高風險檢查）檢查設為自動還原，最佳實務檢查則採用 noop 模式。到今年(2021年)年底，所有 OS 相關最佳實務檢查都將重新歸類為強制性檢查，因此，也將對這些檢查實施自動修復。
範例報告如圖 7 所示。

圖 7 範例 SecureSys 報告

這份報告顯示政策描述、被檢查的組態以及在伺服器中掃描的實際值。如果基準與和實際值相符，則將組態報告視為合規。

圖 8 是與 /var/log/secure 檔案權限相關的最佳實務 (noop) 檢查的違規設定範例。政策要求針對此檔案將權限設為「600」，但當 Puppet 掃描執行階段值，確定權限設為「644」。這觸發違規通知並在資料庫項目中加上旗標。

圖 8 違規結果

建議的行動方案是移除多餘的權限（供群組和他人讀取），或者如果應用程式需要該設定才能運作，則申請偏差。也可以透過入口網站提出偏差，下一節將說明詳細資訊。

偏差引擎

我們知道並非所有應用程式都能完全符合現有的組態設定，尤其在應用程式是現成產品的情況下。幾乎總是有一或多個必須與基準值不同的設定，應用程式才能運作。在星展銀行內部，如果有一項安全性團隊提出的明確申請案，獲得部門負責人的對應授權來承擔風險，則可允許這些偏差、不符原有基準組態的特異作法（獲得授權的例外組態）。從找出偏差（代理程式處於「noop」模式時）到提出偏差要求、傳遞至核准和實際實施的整個過程都是透過 SecureSys 入口網站來完成。

特別注意，若要找出並允許差異，代理程式不得執行基準值自動修復，否則這些值將在每個 Puppet 循環後還原為原始值。您可能很好奇，我們如何保留新值作為例行自動修復檢查的一部分，而不影響使用相同政策的其餘節點？答案在於 Puppet 管理資料來源階層的方式。此階層是在 hiera.yaml 檔案中維護，可根據您整理和分類節點的方式而結構化。

圖 9 Hiera 檔案項目

在上圖中，會看到 Puppet 在階層中查詢 6 個不同的來源。Puppet 將遵循來源的編寫順序，即「by hosts」值優先於「by OS」，且數值取自具有最高優先順序的來源。

下圖中的程式碼片段描述對 /etc/securetty 中定義的值進行檢查。

圖 10 政策檢查的程式碼片段

假設在「Per OS」yaml（在此例中為 Linux.yml 檔案）中定義所有基準值設定，且 compliance_linux::2_1_2::x_2_01_02_02_comp 的基準值設為「console,tty」，如圖 11 所示：

圖 11 /etc/securetty 檢查的 Hiera 值

假設應用程式無法在這些終端機類型上運作，僅可在 pseudotty (pty) 上運作。挑戰在於防止組態在下一個 Puppet 循環之後自動修復並還原為原始設定。此外，將產生並報告「刻意變更」警報。更新 hiera 中的值定義（在平台層級上）是可能的解決方案之一，然而，對檔案所做的任何變更都將影響所有訂閱該組態的節點。

為了解決此問題，我們必須利用資料來源的階層定義取得值的位置。再次查看圖 9 中 hiera.yaml 檔案中的定義，請注意，第一個項目被描述為「Per Node」。此定義具有最高優先順序，因此，在此處定義的所有設定取代其下檔案的所有定義。同樣值得注意的是，組態檔的檔案名稱被設為憑證名稱（即端點的主機名稱），使得在檔案中指定的所有組態僅適用於檔案名稱與憑證名稱相同的節點。實際上，我們現在可以如下所示設定主機 yaml 檔案：

圖 12 host.yaml 檔案中的新值作為偏差的一部分

確定偏差策略後，即可在 SecureSys 中整合工作流程以將此過程自動化，並透過 Puppet 任務進行後端執行。要求在入口網站中獲核准後，將自動呼叫 API，隨後執行下列任務：

1.擷取關於偏差的資訊（主機名稱、機碼、值）

2.在 MOM 檔案中建立 <host>.yaml 並附加機碼值組

3.觸發檔案同步以將檔案複製到所有編譯主控端

變更將在下次執行之後生效，所有向前移動的執行將先參照 <host>.yaml 檔案以取得用於自動修復的值，進而允許偏差。

我們的 SecureSys 框架已明顯進步，從整體手動組態管理方法轉變成如今的自動化可擴充解決方案。實施此方法後帶來可觀的效益，原本需要 13 人的工作可縮減成 3 人。且強制性組態中的所有偏離都會被自動修復，減輕基礎架構和應用程式團隊的負擔，他們再也不必互相協調以進行修復。此外，報告負擔也減輕，可幾乎即時產生報告，並每 30 分鐘執行一次掃描。雖仍有改進空間，但有了這些框架，相信我們可以隨著組織不斷成長而滿足不斷變化的需求。

免責聲明和重要通知

本文章（英文）係由DBS LTD提供並經星展銀行（台灣）（下稱｢本行｣）翻譯為中文，僅供參考，本行及DBS LTD不對使用本文章所引起之任何損失或損害負任何責任。如您有任何疑問或欲參考本文章而為行事之依據，本行建議您諮詢您的專業顧問之意見，以保障您的權益。非經本行之事前書面同意，任何人不得對本文章為複製、轉載、引用、抄襲、修改、散佈或為任何其他方式之使用