本頁為便利而提供的譯本,以英文版本為準。 閱讀英文版

監管資訊

安全與誠信

我們金融交易的安全與誠信

本行等銀行機構使用專門的伺服器基礎設施處理不同的營運領域。根據架構要求及金融法規,主要伺服器類型包括:

1. 核心銀行系統伺服器

這些伺服器構成核心營運骨幹，負責管理客戶帳戶、交易及合規：

  • 交易處理伺服器:執行即時支付授權、欺詐檢查及結算(例如 SWIFT、SEPA)。
  • 帳戶管理伺服器:處理帳戶生命週期事件(開戶/銷戶)、利息計算及流動性監控。
  • 合規監管伺服器:自動執行 AML(反洗錢)檢查、稽核軌跡及報告(例如 IFRS、GDPR)。

2. 分類帳伺服器

負責維護不可更改的財務紀錄:

  • 總帳伺服器:記錄各帳戶的複式簿記,確保符合IFRS等會計準則。
  • 分散式帳本技術(DLT)伺服器:以區塊鏈為基礎的系統,用於跨境支付、KYC核實及防篡改的交易記錄。

3. 對外通訊伺服器
確保與外部實體之間的安全互動:

  • EBICS 伺服器:管理用於 SEPA 支付之電子銀行互聯網通訊標準,廣泛應用於德國、法國及瑞士。
  • 主機對主機(Host-to-Host,H2H)伺服器:為大批量企業交易(例如批量薪資處理)提供直接的 SFTP/FTPS 連線。
  • API 閘道伺服器:提供 RESTful 介面,用於即時發起付款及帳戶整合(以 OAuth2/mTLS 保障安全)。
  • Swift 介面伺服器:將銀行連接至 Swift 網絡,以進行銀行間報文傳送(SCORE 為 Swift 供企業接入使用的封閉用戶群,並非伺服器類型)。

4. 資料庫伺服器
結構化財務資料的中央儲存庫:

  • 客戶資料伺服器:儲存 KYC 文件、交易記錄及行為分析資料。
  • 產品目錄伺服器:管理貸款、按揭及存款利率等產品。

5. 安全與基礎設施伺服器
確保系統完整性及監管合規:

  • 硬件安全模組(HSM)伺服器:保護用於數碼簽署及 SSL/TLS 加密的加密金鑰。
  • 防火牆/VPN 伺服器:實施網絡分段,並為員工提供安全的遠端存取。
  • 災難復原伺服器:承載備份系統,以在系統中斷期間維持業務持續運作。

現代銀行往往採用混合架構,將內部部署的核心伺服器與雲端的 DLT 節點相結合,以提升擴展能力。例如,銀行可能會將 IBM 的內部部署核心銀行業務伺服器與託管於 AWS 的帳本伺服器並用,以實現即時對帳。此種模組化方式在合規、效能與創新之間取得平衡。

銀行須在伺服器整合以提升效率,與維持隔離以確保安全及合規之間取得平衡。以下根據技術限制及業界慣例,說明可合併與不可合併的伺服器:
可合併的伺服器
1. 網頁/應用伺服器

  • 組合方式:虛擬化(VMware、KVM)或容器化(Docker/Kubernetes)
  • 示例:在配備負載平衡的虛擬化管理程序集群上,同時運行多個銀行入口網站(零售、企業及手機)。

2. 資料庫伺服器

  • 組合方式:多租戶雲端資料庫(AWS RDS、Azure SQL)
  • 在混合雲架構下,Oracle/MS SQL 核心銀行資料庫可與 PostgreSQL/MongoDB 分析系統並存。

3. 對外通訊閘道

  • 組合方式:統一 API 閘道(Apigee、MuleSoft)
  • EBICS、SWIFT 及 SFTP 服務可運行於共用基礎設施之上,並配合按協議劃分的微服務。

4. 災難復原伺服器

  • 組合方式:主動—主動式地理冗餘
  • 核心銀行系統副本及備份帳簿伺服器可共用災難復原叢集。

5. 中介軟體伺服器

  • 組合方式:企業服務匯流排(ESB)
  • 支付路由、合規查核及貨幣兌換服務整合於 IBM Integration Bus/SAP PI 平台。

應保持隔離的伺服器
1. 核心交易處理伺服器

  • 原因:實體隔離或嚴格分段隔離可縮小 PCI DSS 及 SOC 2 控制措施的適用範圍
  • 例如:運行 CICS 交易監控程式的 IBM zSystems 不能與其他工作負載共用硬件。

2. 硬體安全模組(HSM)伺服器

  • 原因：FIPS 140-2/140-3 第三級要求採用專用的防篡改硬體
  • 實施方式:由 Thales/Gemalto 硬件安全模組(HSM)處理數碼簽章及加密密鑰。

3. 實時分類帳系統

  • 原因:複式簿記要求具備原子性
  • 示例:配備直連式 NVMe 儲存裝置的 Oracle Financial Services 帳務伺服器。

4. 監管報告伺服器

  • 理由:稽核日誌須受保護以防遭到更改,並須按 GDPR 及反洗錢法律規定的期限保存;實行分離有助於證明合規
  • 設置:為 MiFID II/FATCA 報告提供獨立的 SQL Server 實例。

5. 自動櫃員機／POS 授權系統

  • 原因:99.999% 的正常運行時間服務水平協議及網絡分段要求
  • 架構:採用配備冗餘光纖通道儲存區域網路(SAN)的 IBM Power Systems。

技術限制:

  • 高交易量核心銀行系統需要專用的高頻寬網絡連線
  • PCI DSS 要求將儲存的卡號(PAN)處理為不可讀取,並對持卡人資料環境實施分段隔離
  • SWIFT 客戶安全計劃(CSP)要求 SWIFT 基礎設施置於受保護的安全區域內

我們已成功整合 80% 的非關鍵伺服器（網站／應用程式／中介軟體），同時將核心／HSM／帳本系統完全隔離。

在雲端保障帳務伺服器的安全,須針對金融數據的敏感性採取多層次防護措施。以下依據 AWS 安全最佳實務及銀行業專屬的實施方式,提出結構化的做法:

1. 不可篡改的分類帳技術
採用專為此目的構建的分類帳資料庫,對每筆交易進行加密驗證:

  • 加密鏈式結構:每筆交易均經雜湊處理並與前一條記錄相連,形成不可篡改的審計軌跡。
  • 內建完整性檢驗:資料庫自動驗證其自身歷史紀錄,防止遭到竄改。
  • 類 SQL 查詢:在保持與現有金融系統相容的同時,加入類似區塊鏈的安全性。

2. 網絡隔離

  • VPC 架構:將帳本伺服器部署於私有子網路,不連接公共互聯網。
  • 安全群組:將入站流量限制於來自預先核准 IP 範圍的特定連接埠(例如 PostgreSQL/Aurora)。
  • VPC 端點:使用 AWS PrivateLink,使帳本伺服器與 S3/KMS 等服務之間的通訊保持安全,無須暴露於公共網絡。

3. 加密

  • 靜態數據:由AWS KMS管理的金鑰對存放於Amazon Aurora的帳簿數據進行加密,並自動輪換金鑰。
  • 傳輸中:所有客戶端與伺服器之間及服務之間的通訊,一律強制使用 TLS 1.3。
  • 客戶端加密：在儲存前先對敏感欄位（例如帳戶結餘）進行加密，可使用 AWS Encryption SDK。

4. 存取控制

  • IAM角色:分配精細的權限(例如僅可寫入的角色),以防止資料被意外或惡意刪除。
  • 臨時憑證:於維護期間使用 AWS STS 提供限時存取權限。
  • 強制多重身分驗證(MFA):root/管理員帳戶須使用硬體令牌(YubiKey)。

5. 監察及審計

  • 即時警示:配置 AWS CloudWatch,針對異常交易模式(例如逾 €1M 的轉帳)觸發警示。
  • 活動日誌:透過與 SIEM 工具整合的 AWS CloudTrail,追蹤所有分類帳的修改。
  • 自動化審計:每週運行 AWS Config 規則,以核實加密狀態及網絡政策。

6. 合規與治理

  • 分區隔離:利用 AWS Organizations 將 DEV/TEST/PROD 帳本環境分隔。
  • 自動化報告:透過 AWS Audit Manager 生成 PCI DSS/GDPR 合規報告。
  • 第三方審計:每年與 AWS 認可的合作夥伴安排滲透測試。

7. 災難復原

  • 跨區域複製:在 AWS 法蘭克福及斯德哥爾摩區域維持經加密的帳本副本。
  • 時間點還原:啟用持續備份,可將資料還原至保留期間內(最長 35 天)的任何一秒。
  • 實體隔離備份:將季度帳簿快照存放於 AWS Backup Vault,並保存七年。
安全與誠信 - 金融數據的分層保護

為防止惡意條目擴散至災難復原(DR)伺服器,銀行實施多層安全策略,對備份進行隔離、執行嚴格的存取控制並驗證資料完整性。以下為主要措施的技術說明:
1. 採用一次寫入多次讀取(WORM)配置的不可變備份

  • 目的:防止勒索軟件更改或加密備份資料。

實施方式:採用 AWS S3 Object Lock 或 Azure Blob Immutable Storage,於設定的保存期間內防止刪除或修改。對備份檔案套用加密雜湊(SHA-256);任何竄改均會使雜湊值失效,並觸發警示。
2. 實體隔離及離線複寫

  • 網絡隔離:將災難復原(DR)伺服器存放於獨立的 VPC/VLAN,並禁止任何來自互聯網的入站連線。透過 AWS Storage Gateway 或 Azure Site Recovery 等工具進行單向複製(主系統 → DR),阻止反向同步。
  • 實體隔離(Air-Gapping):對於關鍵系統,應保留磁帶備份或離線儲存,僅於預定的複製時段內連接。

3. 零信任存取控制

  • 身分驗證:對所有災難復原管理介面(例如 AWS SSO、Azure AD 條件式存取)強制實施多重要素驗證(MFA)。以最小權限原則指派 IAM 角色(例如僅授予 `s3:GetObject`)。
  • 網絡安全:將複製流量限制於 IPsec VPN 隧道或 AWS Direct Connect/Azure ExpressRoute。部署 Snort 或 Suricata 等入侵偵測系統(IDS),以監控複製通道。

4. 數據完整性驗證

  • 複製前檢查:複製前使用 ClamAV 或 CrowdStrike Falcon 等工具掃描源數據是否含有惡意軟件。比對傳輸前後的校驗和,以偵測任何篡改。
  • 複製後審計:使用 AWS Config 或 Azure Policy 對災難復原伺服器實施加密及存取政策。透過腳本(例如 `sha256sum` 驗證)安排每日完整性檢查。

5. 邏輯隔離環境

6. 自動故障切換測試

  • 模擬攻擊:使用 Chaos Monkey 等工具模擬勒索軟件感染,以驗證災難復原(DR)伺服器的韌性。於演練期間衡量復原時間目標(RTO)及復原點目標(RPO)。
  • 鑑識分析:保留 90 天的 VPC Flow Logs 及 CloudTrail 事件,以追查複製異常情況。

實施不可變備份對於保護資料免受勒索軟體、意外刪除及違反合規規定的影響至關重要。依據行業標準以及 AWS、Veeam 和 Azure 等工具,最佳做法如下:
1. 在儲存層強制實施不可變性

  • 透過物件儲存採用 WORM(一次寫入、多次讀取)配置,例如具備 S3 Object Lock 的 AWS、Azure Immutable Blob Storage 或 Veeam Hardened Repositories。
  • 啟用保留鎖定,即使管理員亦無法過早刪除或修改資料。

2. 採用 3-2-1-1 備份策略

  • 3 份資料副本(主資料加兩份備份)
  • 2 種儲存媒體類型(例如磁碟加雲端)
  • 1 份異地副本(地理上相互隔離)
  • 1 份不可更改的副本(物理隔離或啟用 WORM 功能)。

3. 實施嚴格的存取控制

  • 基於角色的存取控制(RBAC):透過 IAM 角色限制權限(例如 AWS Backup Vault 存取政策)。
  • 多重因素驗證(MFA):對備份管理介面強制實施(例如 Azure AD 條件式存取)。
  • 網絡隔離:將備份存放於私有子網/VPC 中,不接入公共互聯網。

4. 端對端加密資料

  • 靜態數據:使用 AES-256 或由 KMS 管理的密鑰(AWS、Azure)。
  • 傳輸中:複製通道採用 TLS 1.3。
  • 客戶端加密:於備份前先對敏感欄位加密(例如 Veeam 搭配用戶自行管理密鑰的 AES-256)。

5. 自動化保存與驗證

  • 保留政策:界定 RPO/RTO 並自動執行生命週期規則(例如 AWS Backup Vault 的 7 年保留期)。
  • 校驗和驗證:核實複製前後的完整性(例如 SHA-256 雜湊)。
  • 定期審計:使用AWS Config或Veeam SureBackup等工具測試還原。

6. 為混合環境建立多層安全防護

7. 確保合規及不可撤回性

  • 測試完成後鎖定不可變性設定(例如 Azure 的「已啟用並鎖定」狀態)。
  • 符合法規要求：藉助 AWS Audit Manager 等工具，遵循 GDPR、HIPAA 或 SOX 的規定。
  • 第三方審計:安排每年進行滲透測試(例如委託 AWS 認可的合作夥伴)。

AWS 與 Veeam 的工作流程示例
1. 主要備份:使用 Veeam Backup & Replication 備份至啟用 Object Lock 的 S3 儲存桶。
2. 複製:透過 AWS DataSync 複製至次要區域(法蘭克福 → 斯德哥爾摩)。
3. 驗證:每日 CloudTrail 日誌 + 每季還原演練。
4. 保留:90 日不可變更期,並以 KMS 加密。

結合不可變更特性、存取控制及混合冗餘機制,機構可建立具備抵禦勒索軟件能力的備份,同時滿足合規要求。