本页面为方便阅读而提供的译文,以英文版本为准。 阅读英文版

监管信息

安全与诚信

我们金融交易的安全与诚信

与本行类似的银行使用专门的服务器基础设施来处理不同的业务领域。根据架构要求和金融监管规定,主要的服务器类型包括:

1. 核心银行服务器

这些服务器构成核心运营骨干,负责管理客户账户、交易与合规:

  • 交易处理服务器:执行实时支付授权、欺诈检查及结算(例如SWIFT、SEPA)。
  • 账户管理服务器:处理账户生命周期事件(开立/销户)、利息计算及流动性监控。
  • 监管合规服务器:自动执行AML(反洗钱)核查、审计留痕及报告(例如IFRS、GDPR)。

2. 账本服务器

负责维护不可篡改的财务记录:

  • 总账服务器:追踪各账户间的复式记账,确保符合国际财务报告准则(IFRS)等会计准则。
  • 分布式账本技术(DLT)服务器:用于跨境支付、KYC核验及防篡改交易日志的区块链系统。

3. 对外通信服务器
支持与外部实体的安全交互:

  • EBICS服务器:管理用于SEPA支付的电子银行互联网通信标准(EBICS),在德国、法国和瑞士广泛使用。
  • 主机对主机(H2H)服务器:通过SFTP/FTPS直接连接,处理大批量公司交易(例如批量代发工资)。
  • API网关服务器:提供RESTful接口,用于实时发起付款和账户聚合(通过OAuth2/mTLS保障安全)。
  • Swift接口服务器:将银行连接至Swift网络,用于银行间报文传送(SCORE是Swift为企业接入设立的封闭用户组,并非服务器类型)。

4. 数据库服务器
结构化金融数据的中央存储库:

  • 客户数据服务器:存储KYC文件、交易记录和行为分析数据。
  • 产品目录服务器:管理贷款、抵押贷款和存款利率等产品。

5. 安全与基础设施服务器
确保系统完整性及合规遵循:

  • 硬件安全模块(HSM)服务器:保护用于数字签名及SSL/TLS加密的加密密钥。
  • 防火墙/VPN服务器:实施网络分段,并为员工提供安全的远程访问。
  • 灾难恢复服务器:托管备份系统,以便在发生中断时保障业务连续性。

现代银行常采用混合架构,将本地部署的核心服务器与基于云的DLT节点相结合,以实现可扩展性。例如,银行可将IBM本地部署的核心银行服务器与部署在AWS上的账本服务器配合使用,以实现实时对账。这种模块化方式兼顾了合规、性能与创新。

银行必须在以提高效率为目的的服务器整合与为保障安全和合规而维持隔离之间取得平衡。以下根据技术限制和行业实践,说明可合并与不可合并的服务器:
可合并的服务器
1. Web/应用服务器

  • 组合方式：虚拟化（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. ATM/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):根账户及管理员账户须使用硬件令牌(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，保留期为7年。
安全与诚信——金融数据的分层保护

为防止恶意条目扩散至灾难恢复(DR)服务器,银行实施分层安全策略,对备份进行隔离、执行严格的访问控制并验证数据完整性。以下为主要措施的技术说明:
1. 采用一次写入多次读取(WORM)配置的不可变备份

  • 目的:防止勒索软件篡改或加密备份数据。

实施方式:使用 AWS S3 Object Lock 或 Azure Blob Immutable Storage,在设定的保留期内防止删除或修改。对备份文件应用加密哈希(SHA-256);任何篡改都会使哈希失效,并触发警报。
2. 物理隔离与离线复制

  • 网络隔离:将灾备(DR)服务器部署在独立的VPC/VLAN中,不设入站互联网访问。通过AWS Storage Gateway或Azure Site Recovery等工具采用单向复制(主站点 → 灾备站点),阻断反向同步。
  • 物理隔离:对于关键系统,应保留仅在预定复制时段连接的磁带备份或离线存储。

3. 零信任访问控制

  • 身份验证:对所有灾难恢复(DR)管理界面强制实施多重身份验证(MFA)(例如AWS SSO、Azure AD条件访问)。按最小权限原则分配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等工具模拟勒索软件感染,验证灾备服务器的恢复能力。在演练期间衡量恢复时间目标(RTO)和恢复点目标(RPO)。
  • 取证分析:保留90天的VPC Flow Logs和CloudTrail事件,以追溯复制异常。

实施不可篡改备份对于保护数据免受勒索软件、误删除及违反合规要求的影响至关重要。根据行业标准以及AWS、Veeam和Azure等工具,最佳实践如下:
1. 在存储层强制实施不可篡改性

  • 通过对象存储采用WORM(一次写入、多次读取)配置,可使用S3 Object Lock(AWS)、Azure不可变Blob存储或Veeam加固存储库。
  • 启用保留锁定功能，即使是管理员也无法提前删除或修改。

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加密。

通过结合不可篡改特性、访问控制和混合冗余,机构可以实现抵御勒索软件的备份,同时满足合规要求。