一文了解金融合规

欢迎来到啾啾的博客🐱。
记录学习点滴。分享工作思考和实用技巧，偶尔也分享一些杂谈💬。
有很多很多不足的地方，欢迎评论交流，感谢您的阅读和评论😄。

引言

零零碎碎跟着项目接触到过一些FinTech安全知识，现在不少岗位有要求有“金融合规”知识。

让我们系统地了解一下。

金融系统的特点是稳定性和安全性永远是第一位。
要重视系统稳定性、安全性，注重代码质量。
要遵守流程和规范，这是合规文化的核心。

AI使用声明：本文使用了AI进行资料查找，结构化整理。

• 资料推荐
  一文读懂什么是KYC
  Java 对金融业的影响：深入探讨金融机构为何偏爱 Java 用于关键任务系统
  为什么 Java 是开发金融软件的最佳选择？
  确保金融软件开发中的合规性

1 什么是金融合规？为什么要求合规？

首先，监管强制要求合规。
法律和监管要求金融行业有合规性，这确保了金融体系的完整性、确保每一款软件在交易、客户管理或风险评估等方面都符合法律规定。

其次，数据泄露、欺诈等安全性问题促进了合规发展。
合规性确保软件遵守既定的法律、标准和指南。这保护机构免受法律诉讼，并增进用户和投资者的信任。

2 金融合规术语速查表

作为开发人员，我们需要称为金融专家，但至少要了解一些核心术语。
如 KYC (了解你的客户)、AML (反洗钱)、风控、审计、数据脱敏、PCI DSS (支付卡行业数据安全标准) 等。

• 金融合规核心术语速查表 (Java工程师视角)

3 合规思维

金融合规要求应该直接转化为我们代码的健壮性、安全性和严谨性。

以下总结供参考：

1. 数据安全是第一要务：你知道哪些数据是敏感的，并懂得如何用技术手段（加密、脱敏）去保护它。
2. 操作必须可追溯：你写的每一个关键功能，都会考虑留下清晰的审计日志。
3. 权限校验无处不在：你写的每一个接口，都会在服务端严格校验用户的操作权限，而不是信任前端的任何请求。
4. 业务逻辑需精准：你明白金融业务（如计息、费用计算）的严肃性，代码实现必须与业务规则分毫不差。

4 金融合规要求

在开发金融业务系统（如银行、证券、保险、支付等）时，需要将合规要求融入到技术实现中。主要体现在以下几个方面：

4.1 KYC(know your customer)

了解你的客户，做用户和账户管理。

• 业务场景: 新用户注册、开户时，需要进行实名认证、身份信息核验，有时还需要人脸识别、绑定银行卡等。这都是为了防止匿名账户从事非法活动。

• 你的工作: 开发和实现这些认证流程的接口和逻辑，确保系统能准确、安全地收集和验证用户信息。你需要调用公安、银行等第三方服务接口，并处理好各种认证成功或失败的状态。

4.2 交易监控与反洗钱 (AML - Anti-Money Laundering)

• 业务场景: 系统需要识别和报告可疑交易，例如，短时间内频繁的大额资金分散转入、集中转出，或者与来自高风险地区的账户进行交易。

• 你的工作: 你可能需要开发一个规则引擎或风控系统。当交易发生时，系统会根据预设的合规规则（如单笔金额上限、日累计金额上限、交易频率等）进行实时判断。一旦触发规则，系统需要能自动拦截交易、发出警报或生成报告给合规部门。

4.3 数据安全与隐私保护

• 业务场景: 金融行业拥有大量用户的敏感数据（如身份证、银行卡号、手机号、交易记录）。法律法规（如《个人信息保护法》）对这些数据的存储、传输和使用有极其严格的规定。

  • 你的工作:
    • 数据加密: 确保敏感数据在数据库中是加密存储的，在网络传输过程中是加密的（HTTPS）。
    • 访问控制: 设计和实现严格的权限系统，确保只有授权的员工和系统才能访问敏感数据，并且所有访问行为都要被详细记录。
    • 数据脱敏: 在非生产环境（如测试、开发环境）或数据分析场景中，需要对真实数据进行脱敏处理，用“*”等符号替换部分信息。

一些数据安全选择决策参考：

• 需要可逆还原 -> 加密
  • 大量数据、性能要求高 -> AES
  • 密钥交换、数字签名 -> RSA
• 绝对不可逆 -> 哈希 / 脱敏
  • 存密码 -> BCrypt + Salt
  • 数据完整性校验 -> SHA-256
  • 给测试/开发/分析人员数据 -> 脱敏 (根据需要选择遮蔽、替换等技术)

4.4 业务逻辑的合规性

• 业务场景: 产品的利率、手续费、计息方式、还款流程等都必须严格遵守金融监管部门的规定。

• 你的工作: 在代码层面精确实现这些业务逻辑。例如，利息计算的精度、小数点舍入方式都不能出错。你需要确保你的代码逻辑与产品和合规部门确认的业务规则完全一致。

4.5 可审计性与日志记录

• 业务场景: 当监管部门或公司内部进行审计时，必须能够追溯每一笔操作。谁在什么时间、通过哪个IP地址、做了什么操作、操作前后的数据是怎样的，都需要有据可查。

• 你的工作: 开发完善的日志系统。这不只是记录代码异常（Exception），更重要的是记录关键的业务操作日志。这些日志需要完整、不可篡改，并能被方便地查询和分析。

5 OWASP Top 10 2021

要强化安全开发意识。参考一下OWASP组织的发布的10大Web应用安全漏洞。

5.1 A01:2021 - 失效的访问控制 (Broken Access Control)

核心问题：未能对已认证的用户实施恰当的权限限制，导致用户可以访问其无权访问的数据或功能。

核心防御流程伪代码：

Function handleRequest(userID, resourceID):
    // 步骤 1: 获取当前登录用户的角色或权限
    userRoles = getUserRoles(userID)

    // 步骤 2: 获取请求的资源所需要的权限
    requiredPermission = getRequiredPermission(resourceID)

    // 步骤 3: 在服务端强制校验用户是否拥有所需权限
    if userHasPermission(userRoles, requiredPermission):
        // 校验通过，执行操作
        return getResource(resourceID)
    else:
        // 校验失败，拒绝访问
        logSecurityEvent("Access Denied for user " + userID + " to resource " + resourceID)
        return Error(403, "Forbidden")
    endif
End Function

5.2 A02:2021 - 加密失败 (Cryptographic Failures)

核心问题：对敏感数据（如密码、个人信息）在传输或存储时未使用加密或使用了弱加密。

核心防御流程伪代码：

// 存储密码时
Function registerUser(username, password):
    // 步骤 1: 生成一个随机的盐值(salt)
    salt = generateSalt()
    // 步骤 2: 使用业界推荐的强哈希算法（如 Argon2, bcrypt）进行处理
    hashedPassword = strongHash(password + salt)
    // 步骤 3: 将哈希后的密码和盐值存入数据库
    database.save(username, hashedPassword, salt)
End Function

// 传输数据时
// 伪代码: 这是一个配置项，而非流程代码
// 确保全站强制启用 TLS (HTTPS)
// 禁用不安全的协议版本 (如 SSLv3, TLSv1.0)

5.3 A03:2021 - 注入 (Injection)

核心问题：将不可信的用户输入拼接成命令或查询语句，导致恶意代码被执行。

核心防御流程伪代码 (以SQL注入为例)：

Function searchProducts(userInput):
    // 错误做法: 字符串拼接
    // query = "SELECT * FROM products WHERE name = '" + userInput + "';"

    // 正确做法: 使用参数化查询 (Prepared Statements)
    // 步骤 1: 定义带有占位符的SQL模板
    queryTemplate = "SELECT * FROM products WHERE name = ?"

    // 步骤 2: 准备查询语句
    preparedStatement = database.prepare(queryTemplate)

    // 步骤 3: 将用户输入作为参数绑定到占位符
    preparedStatement.bind(1, userInput)

    // 步骤 4: 执行安全的查询，用户输入被当作纯数据处理
    results = preparedStatement.execute()
    return results
End Function

5.4 A04:2021 - 不安全的设计 (Insecure Design)

核心问题：在设计阶段就缺少或忽略了安全控制，导致无法通过后期实现来修复的根本性缺陷。

核心防御流程伪代码 (以防止越权修改订单为例)：

Function updateOrder(userID, orderID, newStatus):
    // 设计原则: 业务操作前，必须在服务端校验业务逻辑的合理性

    // 步骤 1: 从数据库中获取订单的真实信息
    order = database.findOrder(orderID)

    // 步骤 2: 校验订单是否存在
    if order is NULL:
        return Error(404, "Order not found")
    endif

    // 步骤 3: 校验当前用户是否是该订单的所有者（核心设计点）
    if order.ownerUserID != userID:
        logSecurityEvent("User " + userID + " attempted to modify order " + orderID + " without permission")
        return Error(403, "Forbidden")
    endif

    // 步骤 4: 校验通过后，才执行更新操作
    order.status = newStatus
    database.save(order)
    return Success("Order updated")
End Function

5.5 A05:2021 - 安全配置错误 (Security Misconfiguration)

核心问题：系统、框架、服务器等存在不安全的默认配置，或配置不当（如暴露了错误详情）。

核心防御流程伪代码 (以错误处理为例)：

try:
    // ... 执行一些可能会出错的业务逻辑 ...
    riskyOperation()
except Exception as e:
    // 步骤 1: 在服务端记录详细的错误日志，用于排查问题
    logDetailedError(e.stackTrace)

    // 步骤 2: 返回给用户的必须是通用的、不含技术细节的错误信息
    return UserFacingError("An unexpected error occurred. Please try again later.")
end try

5.6 A06:2021 - 易受攻击和过时的组件 (Vulnerable and Outdated Components)

核心问题：使用了存在已知安全漏洞的第三方库、框架或依赖。

核心防御流程伪代码 (这是一个开发流程，而非运行时代码)：

// 开发与部署流程
// 步骤 1: 使用自动化工具 (如 OWASP Dependency-Check, Snyk) 集成到CI/CD流水线
scanDependencies()

// 步骤 2: 扫描发现高危漏洞则中断构建
if hasHighSeverityVulnerabilities():
    failBuild("Found critical vulnerabilities in dependencies")
else:
    // 步骤 3: 构建成功，部署应用
    deployApplication()
endif

// 步骤 4: 定期审查和更新所有项目依赖库
// (例如: 每周执行 `npm audit fix` 或 `mvn versions:display-dependency-updates`)

5.7 A07:2021 - 身份识别和认证失败 (Identification and Authentication Failures)

核心问题：身份验证和会话管理功能实现不当，让攻击者可以冒充他人。

核心防御流程伪代码 (以登录和会话管理为例)：

Function handleLogin(username, password):
    // 步骤 1: 检查账户是否因多次失败而被锁定
    if isAccountLocked(username):
        return Error("Account is temporarily locked")
    endif

    user = database.findUser(username)
    // 步骤 2: 使用安全的比较函数验证哈希后的密码
    if user and secureCompare(password, user.hashedPassword):
        // 步骤 3: 登录成功后，立即生成一个全新的、随机的会话ID
        newSessionID = generateSecureSessionID()
        sessionStore.associate(newSessionID, user.id)
        resetFailedLoginAttempts(username)
        return setCookie("session_id", newSessionID)
    else:
        // 步骤 4: 登录失败，增加失败计数并返回通用错误
        incrementFailedLoginAttempts(username)
        return Error("Invalid credentials")
    endif
End Function

5.8 A08:2021 - 软件和数据完整性故障 (Software and Data Integrity Failures)

核心问题：未能验证软件更新、关键数据和CI/CD管道的完整性，导致可被植入恶意代码或恶意数据。

核心防御流程伪代码 (以反序列化为例)：

Function processSerializedObject(dataStream):
    // 错误做法: 使用通用的反序列化函数
    // object = genericDeserializer.deserialize(dataStream)

    // 正确做法: 严格限制反序列化的类型
    // 步骤 1: 确保数据来源可信 (例如，检查数字签名)
    if not verifySignature(dataStream):
        return Error("Data integrity check failed")
    endif

    // 步骤 2: 使用仅允许特定已知类的安全反序列化库
    try:
        // 只允许将数据还原为 MyExpectedClass 这个类型
        safeObject = safeDeserializer.deserialize(dataStream, MyExpectedClass.class)
        return process(safeObject)
    except DeserializationException:
        // 步骤 3: 如果数据不是预期类型，则拒绝并记录日志
        logSecurityEvent("Untrusted deserialization attempt detected")
        return Error("Invalid data format")
    end try
End Function

5.9 A09:2021 - 安全日志和监控失败 (Security Logging and Monitoring Failures)

核心问题：缺乏足够的日志记录、监控和告警，导致无法及时发现和响应攻击行为。

核心防御流程伪代码：

Function criticalOperation(user, data):
    // 步骤 1: 尝试执行关键操作
    result = performAction(data)

    // 步骤 2: 无论成功或失败，都记录结构化的审计日志
    logAuditEvent({
        "timestamp": now(),
        "userID": user.id,
        "sourceIP": user.ipAddress,
        "event": "PASSWORD_CHANGE",
        "outcome": result.status // "SUCCESS" or "FAILURE"
    })

    // 步骤 3: 对于可疑事件（如多次失败），触发实时告警
    if result.status == "FAILURE":
        failedAttempts = getFailedAttempts(user.id, "PASSWORD_CHANGE")
        if failedAttempts > 5:
            triggerAlert("Multiple failed password change attempts for user " + user.id)
        endif
    endif
End Function

5.10 A10:2021 - 服务器端请求伪造 (SSRF)

核心问题：攻击者可以诱使服务器向其指定的任意URL发起请求，常用于探测和攻击内网。

核心防御流程伪代码：

Function fetchUrlContent(userProvidedUrl):
    // 步骤 1: 解析URL，确保协议是允许的 (如 http, https)
    parsedUrl = parse(userProvidedUrl)
    if parsedUrl.protocol not in ["http", "https"]:
        return Error("Invalid protocol")
    endif

    // 步骤 2: 建立一个安全的、受信任的目标域名“白名单”
    allowedDomains = ["example.com", "api.partner.com"]
    if parsedUrl.hostname not in allowedDomains:
        logSecurityEvent("SSRF attempt to " + parsedUrl.hostname)
        return Error("Host is not allowed")
    endif

    // 步骤 3: (可选但更安全) 将域名解析为IP，并检查IP是否在内网地址范围
    ipAddress = resolveDns(parsedUrl.hostname)
    if isInternalIp(ipAddress):
        return Error("Cannot connect to internal resources")
    endif

    // 步骤 4: 所有检查通过后，才代表服务器发起请求
    return httpRequest(parsedUrl)
End Function

6 面试题模拟

6.1 场景：数据安全

Q：“假设我们要设计一个用户开户系统，需要收集用户的姓名、身份证号和手机号。从数据库设计到后端API实现，你会如何处理这些敏感数据以确保合规？”

• 考察重点:
  • 数据存储安全：是否知道不能明文存储。
  • 数据传输安全：是否提及HTTPS。
  • 数据使用安全：是否考虑到日志脱敏和访问控制。

A：

• "首先，在数据库设计层面，我会将身份证号、手机号这些字段类型设计为VARCHAR，但不会直接存储明文。我会使用AES这类对称加密算法对这些字段进行加密后入库，密钥会通过专门的密钥管理系统（KMS）来管理，确保密钥本身的安全。

• 其次，在后端API实现层面：

  • 数据传输：所有API接口必须强制使用HTTPS，防止数据在传输过程中被窃听。
  • 数据加解密：在代码中，我会封装一个加解密服务，在数据写入数据库前自动加密，在需要使用（且有权限使用）时再进行解密。
  • 日志处理：在打印日志时，我会对这些敏感字段进行脱敏处理，例如，身份证号只显示前四位和后四位，中间用*号代替，避免在日志中泄露完整信息。
  • 访问控制：对提供这些敏感数据的API，会使用Spring Security等框架进行严格的权限校验，确保只有授权的角色才能访问。"

6.2 场景：交易反洗钱监控

Q：“我们需要设计一个简单的交易反洗钱（AML）监控功能。比如，规则是：‘单用户24小时内累计向多个不同账户转账超过5万元人民币，则触发警报’。你会如何技术选型和设计这个功能？”

• 考察重点:
  • 你是否能想到实时计算和离线计算两种方案。
  • 你是否了解实现这类需求的技术栈（如消息队列、流处理、定时任务）。
  • 你是否考虑到系统的性能和可扩展性。

A：

• "我会采用实时计算和异步处理的方案来设计。

• 技术选型：我会使用Kafka作为消息队列，Flink或Kafka Streams作为流处理引擎，Redis用于存储用户的实时交易计数和金额。

• 处理流程：

  1. 当一笔转账交易完成后，交易系统会发送一条包含用户ID、金额、对方账户等信息的消息到Kafka。

  2. Flink作业消费这条消息，并实时从Redis中读取该用户24小时内的累计转账金额和转账次数。

  3. 更新Redis中的数据，并根据’累计金额 > 5万’的规则进行判断。

  4. 如果触发规则，Flink作业会产生一条警报消息，发送到另一个告警处理的Kafka Topic。

  5. 下游的告警服务消费这条消息，执行具体的告警操作，比如发送邮件、短信或将记录插入到待办工单系统，交由合规人员处理。

• 这样做的好处是：将风控逻辑与主交易流程解耦，不影响交易性能；同时，使用流处理框架可以方便地扩展更复杂的风控规则，并且有很好的横向扩展能力。"