共用方式為

增強營運復原能力並降低金融服務中的集中風險

  • 發行項

本文是以 2023 年 7 月 部落格文章為基礎，提供如何強化營運復原能力，以及管理金融服務機構中集中風險的實用指引， (FPI) 。

為了確保與現有和即將推出的法規一致性，我們已納入 FSI 的主要法規指引中，包括作業復原能力主題的持續挑戰。

包括：

我們的方法與列出的發行集一致，並會隨著時間更新。 我們的目標是協助客戶根據現有和未來的 FSI 法規，以負責且符合規範的方式成長和創新。

概觀

在 FSI 中使用雲端技術時，作業復原能力和集中風險會相互關聯，因為在各種法規中強化作業恢復能力會解決此問題。 兩者都與一組廣泛的措施有關，包括識別和監視重要的第三方關係、強化風險治理和管理的需求，以及商務持續性和結束規劃的指引。

我們的目標是協助 FPI 解決並強化其作業恢復能力，以符合法規指導方針的方式，協助他們管理企業層級的集中風險。 請務必全面處理本主題，並考慮所有第三方關聯性。 必須在內部部署軟體產品上使用雲端服務和相依性，並保持安全。 此外，法規指引中通常也會處理與重要函式相關的轉包。

在 2023 年 6 月 22 日的 FSB 諮詢中，重要服務已定義為服務，其失敗或中斷可能會大幅降低金融機構的可行性、重要作業，或符合重要法律和法規義務的能力。 在管理集中風險時，主要著重於這些服務。

集中必須從集中風險中辨別。 目前，在許多重要的 FSI 服務中，第三方相依性的集中性很常見，因此可能無法加以消除。 例如，如果您考慮廣泛使用財務資訊網路， (例如，在Ibm和 Oracle 等) 或軟體廠商中，完整替代將會是一項挑戰。 用戶可以設計特定第三方服務的結束計劃，但難以停止大型金融機構的所有第三方解決方案使用。 因此，重點應放在降低專注風險，使其保持在組織的風險承受能力內。

雖然其中一些範例已經在系統上很重要，但通常不會被視為具有較高的集中風險層級，因為它們分散在分散於地理位置的多個位置。 因此，大部分的失敗只會有有限的 (非全域) 影響。 它們也透過最先進的設計提供最高層級的復原能力，例如安全且復原的作業、自動化的使用，以及零信任的實作。 這些設計已由多個獨立的第三方透過各種認證程式來確認。 這組整體的量值已降低整體風險配置檔，即使在公司層級上，集中程度仍為就地。

FSI 必須著重於強化作業復原能力，而且必須以符合法規和指導方針的方式來完成。 請務必注意，法規不會強制 FPI 部署混合式或多重雲端解決方案，而是採用以風險為基礎且技術無關的原則方法來解決集中風險。 這些風險也可能存在於內部部署環境中。

除了營運層面之外，法規也會強調與外包相關的非營運風險，特別是財務解決風險和解決方法。 非操作性風險無法透過技術措施來管理，而是在合約階段和叫用結束策略時，改為使用法律措施來解決。

在金融服務中管理營運風險的 6 步驟方法

在選擇如何管理作業風險之前，必須先考慮幾個元素，這就是為什麼我們引進了六個步驟的方法來解決集中風險和強化作業復原能力：

管理金融服務中的營運復原能力

步驟 1 - 更新雲端風險治理

現今金融服務法規中的雲端技術主要受限於在此內容中特別套用的第三方外包指導方針，以及套用至內部部署ICT環境的不同法規集。 如簡介中所參考的較新摩擦，在 強化操作恢復能力方面採取全面性的方法。 例如，DORA 和 DORA ICT RMF 等法規草稿不只適用於內部部署，也會考慮使用 ICT 第三方服務提供者作為其架構中不可或缺的一部分。

此外，如 2023 年 6 月 22 日 FSB 諮詢中所述， 主要焦點在於重要服務。 我們也會在 DORA 等其他法規中看到這點。 必須將焦點放在重要服務上，否則要評估的服務範圍會隨著技術服務的互連日益增加而變得過於廣泛。

因此，建議公司重新流覽內部風險治理架構，並全面地納入這些新的作業復原措施，並著重於重要服務，並納入第三方或雲端外包的各種指導方針，以確保合規性。

要在此內容中詢問的一些適當問題包括：

  1. 是否已定義明確的組織風險承受能力？
  2. 哪些服務是業務關鍵？
  3. 實際威脅案例可能會對這些情況造成什麼影響？
  4. 我公司的整體風險偏好為何？

風險治理架構也必須每年更新一次，以確保在快速演進的法規環境中持續符合規範。

簡介中的法規和指導方針與這些問題一致，作為強化作業風險的起點。 為了跨管轄區考慮這些需求，Microsoft已建立一組廣泛的 金融服務合規性檢查清單 ，以協助客戶在使用雲端技術時，自行評估不同國家/地區的法規。 這些檢查清單具有法規對應功能，並指向評估雲端技術的使用Microsoft相關信息。

此外， 適用於 Microsoft 雲 端的合規性計劃已設計為協助所有三條防禦線的風險和合規性功能遵守這些法規，以及解決與使用雲端相關的整體風險。 此計劃同時提供主動式和回應式功能，為風險項目關係人提供進階支援通道。

步驟 2 - 識別專注力

使用單一第三方提供者之服務的集中程度越高，如果發生錯誤，就可能產生更高的負面影響，這稱為集中風險。 此風險是組織必須清楚瞭解商務程式、ICT 平臺、軟體和第三方關係之間所有相依性的原因。

對應這些相依性通常會在 BIA) (業務影響分析中執行。 一旦識別所有第三方關聯性，並將其對應至重要的使用案例之後，就可以使用單一第三方提供者來識別重要服務的集中程度。 此檢視可讓公司識別管理集中風險時必須專注的位置。

針對Microsoft雲端服務，您可以藉由檢 閱 Azure 入口網站中的訂用帳戶和租使用者標識碼，來識別重要工作負載的潛在集中度。 公司也可以 檢視和篩選 Azure 資源資訊 ，以協助您深入了解組織中使用的服務。 這項資訊是可導出的，而且可以與內部 BIA 資訊相互關聯，以協助即時識別重要的相依性。 針對 Microsoft 365，公司也可以在系統管理中心 產生有關 所購買授權和活動的報告。

步驟 3 – 評估替代專案

一旦公司瞭解其相依性及其與重大使用案例的關聯性之後，下一個步驟就是解決相關聯的集中風險。 首先，找出可進一步深入調查的可行替代專案簡短清單。 您可能想要解決的問題包括：

  • 內部部署、混合式、多重來源和完整雲端有哪些實用的替代方案？
  • 每個缺點和優點有哪些？
  • 其風險配置檔如何彼此比較？ 每個替代方案的復原能力為何？
  • 哪些最適合組織的風險偏好和雲端策略？
  • 規劃結束時，是否可能且需要完整的廠商結束？ 可以考慮哪些替代方案？

集中風險是一個彙總詞彙，指出不良事件對一或多個重要服務的影響較高。 評估這類風險時，必須評估每個基礎威脅案例，進而產生細微的檢視，其中包含與集中服務相關聯的優點和缺點。 要考慮的威脅因素包括數據中心災害、硬體故障、網路中斷、網路攻擊、錯誤變更和升級、人為錯誤等等。針對這些適當的緩和措施，都應該仔細考慮。 在考慮解決集中風險的優先解決方案時，公司也必須考慮降低成本、複雜度和內部技能的可用性。

有可能，而且在某些情況下，甚至需要維持專注力，讓公司可以最大化恢復能力。 公司應該藉由解決與集中風險相關聯的基礎威脅案例，而不是嘗試完全移除第三方相依性，例如：區域數據中心災害事件 () 。 (i) 降低發生威脅事件的機率，並 (ii) 藉由降低集中度來限制其影響，通常可以輕鬆地解決這些案例並減少缺點：

  1. 降低機率 是藉由強化解決方案設計中的復原能力來達成。 一組健全的風險管理程式可以增強操作恢復能力，儘管單一第三方提供者會集中重要功能。 量值可能包括在最先進的基礎結構上執行、執行零信任安全性模型、使用最新的更新修補系統、確保商務持續性措施已設定並證明可運作、部署模組化和開放原始碼技術，例如 (：容器) 等。這其中每一個都有助於取得最大復原性環境。

  2. 藉由設計您的服務在作用中/主動組態中跨多個可用性區域運作，藉以降低較低層級的集中度來限制影響;藉由確保實例備份) 已備妥足夠的備援和復原機制，並利用異地備援設計來 (。 這類設定不僅可提高復原能力和更好的 SLA，還能協助降低威脅，例如因為單一數據中心或甚至整個區域的分散式本質而遺失。 威脅的影響可以降低，因此也可降低集中風險，在某些情況下甚至超越內部部署或混合式案例中的可行專案。

總而言 之，如果完整雲端拓撲提供比替代專案更高的復原能力，雖然集中程度本身不會降低，但集中風險也會有效降低。 這個結果可以是可接受的結果，甚至是需要的結果。

建議您將此作業模型併入公司雲端原則中，因為這會提供指引給商務和ICT小組，瞭解組織偏好的拓撲為何，以及要考慮哪些元素作為其解決方案設計的一部分。 另一個考慮這個問題的原因是，通常會與一或多個雲端提供者建立策略性聯盟，以傳遞ICT第三方服務，以及管理相關聯風險的方法通常會在較高層級進行管理。

步驟 4 – 針對復原能力進行設計

在這個階段，您的ICT技術、安全性和作業小組會開始深入探討解決方案設計，方法是將先前的結論和需求建置到個別的使用者案例。

ICT Teams 必須確保其設定及設計應用程式預設安全且具有復原性。 這表示確保解決方案可靠、安全、不受單一失敗點影響，而且可能會利用可用性區域來建立復原時間目標， (RTO) 、恢復點目標 (RPO) ，以及服務層級 (業務) 所需的 SLA。 必要時實作備份、更新商務持續性和結束計劃也是程式的一部分。

嘗試使用Microsoft雲端技術將端對端 SLA 最大化時，請考慮檢閱 我們適用於 Microsoft Online Services 的 SLA。 您會發現 SLA 會依服務而有所不同，且取決於客戶的設計選擇，而跨多個可用性區域部署的 SLA 較高。 藉由選擇正確的設計，客戶可以在雲端中達到每月 99.999% 的可用性 SLA。

確保強式且預設安全的設計並非簡單的工作，而且ICT小組可能會在實作期間留下弱點或發生錯誤。 此挑戰是為什麼我們在Microsoft雲端上部署時提供最佳做法的指引。 雖然對於 Microsoft 365 和 Dynamics 等 SaaS 供應專案而言較不複雜，但是當解決方案建置在 Azure (IaaS) 上時，可能會變得複雜。 因此， Microsoft建立Microsoft Azure Well-Architected Framework ，以提供如何設計可靠性和安全性的額外指引。 Microsoft提供資源來協助公司實作高復原能力案例，包括 Azure 可靠性概觀、 Azure 安全性概觀 ，以及檢閱 Azure 可用性區域的概念。 其他要考慮的層面包括建立 卓越的營運 ，以及將成本和效能優化的程度較小。

因此，必須特別注意整體安全性，特別是在金融服務中。 建議您 在適用於 Azure 的 Microsoft 雲端採用架構中評估我們的安全性，該架構提供核心原則和實用指引，以瞭解如何以最有效的方式解決現今雲端上的網路安全性威脅。 它也包含不同使用案例的參考架構和安全性基準連結。

最後，ICT Teams 應該以符合所有法規和內部原則需求的方式部署雲端資源。 Azure 治理會對 Azure 雲端資源強制執行這類原則，以協助公司實作這些法規和內部控制需求。 此外，公司可能會檢閱我們的 Azure 混合式和多重雲端簡介，這有助於支援混合式和多重雲端部署。

步驟 5 – 測試商務持續性計劃

商務持續性規劃和測試的程式已在受規範的 FPI 中妥善建立。 此步驟的重點在於評估可能會造成第三方外包中斷的影響， (在此程式上使用Microsoft雲端) 。 如需良好的測試範例，請參閱 DORA 草稿 RTS 的 ICT 商務持續性計劃測試 文章 26 中的 ICT 風險管理工具方法程式和原則。

有一個共同責任層面，我們的 Microsoft復原和持續性概觀 可協助客戶為災害案例做好準備。 它提供每個Microsoft雲端服務的特定指引，包括Microsoft如何處理每個服務的商務持續性，以及客戶如何利用Microsoft雲端服務來準備災害事件的指引。

在使用 Microsoft Cloud 時，財務公司應該定期測試商務持續性，因為責任遵循 共同責任模型。 針對 SaaS 解決方案，例如 Microsoft 365 和某些 Azure 服務，Microsoft負責定期執行這些測試。 如需深入解析，客戶可以檢閱Microsoft 的每季商務持續性和災害復原計劃驗證報告 ，Microsoft在其 服務信任 入口網站的 [商務持續性和災害復原] 區段下發佈，以深入瞭解特定Microsoft雲端服務的執行方式。

步驟 6 – 準備結束計劃

某些威脅案例無法使用商務持續性計劃或技術復原措施來管理，例如第三方提供者的風險或解決風險。 結束計劃有處理這類災難性案例的好處，而且應該視為經由測試的商務持續性計劃所補充。

這就是為什麼每個組織都應該針對其重大使用案例擁有整體結束策略和個別的退出計劃，因為這以數個法規和未來的指導方針為根據。

6 月 23 日 FSB 諮詢的第 3.7 節 提供實用的指引，指出退出策略和退出計劃的元素 ，例如 (i) 在合約上同意轉換期間，以將中斷的風險降到最低; (ii) 確保以符合成本效益且及時的方式傳回包括數據和應用程式在內的邏輯和實體資產， ( iii) 適當地擁有記錄的擁有權、維護、保留和長期可用性的相關合約條款。

DORA 文章 28 (8) 也要求公司針對支援重要或重要功能的 ICT 服務開發退出策略。 同樣地， 2021 年 3 月關於外包和第三方風險管理的 UK PRA 監督聲明 SS2/21 在第 10 節中有關於結束規劃需求的廣泛描述，並介紹強調退出的概念。 這些管轄區中的金融公司必須評估這些指導方針，並備妥適當的合約安排，以支援這裡的執行，例如，要求在ICT第三方服務提供者繼續提供相關服務的必要轉換期間期間 (範例：DORA文章 30.3.f 會參考強制適當轉換期間的合約建立) 。

歐洲銀行同盟在 2020 年 6 月撰寫的技術文件說明一些符合 EBA 指導方針的金融機構達成退出計劃測試的方式。