第26章合规与安全

第26章：合规与安全：API密钥管理、IP白名单、交易限额、审计日志

做市系统跑起来之后，很多人第一反应是「赶紧赚钱」。但我得说句实话——安全合规才是做市系统的生命线。你策略再牛，API密钥被人偷了，一夜之间账户归零，这种事我见过不止一次。

今天咱们聊聊四个核心安全模块：API密钥管理、IP白名单、交易限额、审计日志。这四个东西，说白了就是给你的系统上四把锁。

26.1 API密钥管理——你的数字钥匙

API密钥是什么？就是交易所识别你身份的凭证。丢了它，等于把钱包密码贴在大街上。

我个人的习惯是：永远不要把API密钥硬编码在代码里。你想想看，代码要提交到Git仓库，万一仓库是公开的，或者内部权限没设好，密钥就全暴露了。

⚠️ 我曾经见过一个团队，把主网API密钥写在配置文件中，还上传到了GitHub公共仓库。结果半小时内，账户里的100个ETH被洗劫一空。嗯，血的教训。

正确的做法是什么？用环境变量，或者专门的密钥管理服务。

# 错误示范：硬编码
api_key = "abc123def456"
api_secret = "secret_key_here"

# 正确做法：环境变量
import os
api_key = os.getenv("EXCHANGE_API_KEY")
api_secret = os.getenv("EXCHANGE_API_SECRET")

另外，权限最小化原则一定要遵守。交易所创建API密钥时，通常有权限选项：只读、交易、提现。做市系统只需要「交易」权限就够了，千万别勾「提现」。为什么？因为就算密钥泄露，黑客也只能交易，不能把钱转走。

权限类型	做市系统是否需要	风险等级
只读（查看余额、订单）	是	低
交易（下单、撤单）	是	中
提现（转出资产）	否	高

26.2 IP白名单——只让「自己人」进门

API密钥是「你是谁」的证明，IP白名单是「你在哪」的限制。两者结合，安全系数翻倍。

大部分交易所都支持IP白名单功能。你设置好之后，只有白名单里的IP地址才能用这个API密钥发起请求。其他人就算拿到了密钥，IP不对，照样被拒。

我建议：如果你的做市服务器是云服务器，把服务器的公网IP加到白名单里。如果是多台服务器，每台都加。千万别偷懒只加一台。

💡 小技巧：有些交易所支持多个IP白名单条目。你可以把办公室的IP也加上，方便本地调试。但调试完记得删掉，或者用测试网的API密钥。

这里有个坑——动态IP。有些云服务商的公网IP不是固定的，重启实例后IP会变。我曾经遇到过，半夜服务器自动重启，IP变了，结果API全部失效，做市系统停摆了一整夜。嗯，从那以后我学乖了：要么买弹性公网IP，要么用域名+动态DNS。

26.3 交易限额——给系统上「保险丝」

做市系统跑着跑着，突然出现bug，开始疯狂下单——这种事在量化圈并不罕见。交易限额就是你的保险丝，防止系统失控。

交易限额分几个维度：

单笔限额：每笔订单的最大金额。比如单笔不超过1个BTC。
日累计限额：一天内所有交易的总金额上限。比如一天最多交易100个ETH。
频率限额：每秒/每分钟最多发多少笔订单。防止API被交易所封禁。

# 一个简单的交易限额检查示例
class TradeLimiter:
    def __init__(self):
        self.daily_total = 0
        self.max_daily = 100  # 日累计限额 100 ETH
        self.max_per_order = 1  # 单笔限额 1 ETH
        
    def check_order(self, amount):
        if amount > self.max_per_order:
            return False, "单笔超限"
        if self.daily_total + amount > self.max_daily:
            return False, "日累计超限"
        return True, "通过"
    
    def record_trade(self, amount):
        self.daily_total += amount

我个人经验是：交易限额不要只写在代码里，最好在数据库或配置中心也存一份。为什么？因为代码可能被热更新覆盖，或者部署时忘记同步。多一层保障，多一分安心。

26.4 审计日志——出了事有据可查

审计日志，说白了就是「黑匣子」。系统出了任何问题，你都能从日志里找到线索。

做市系统的审计日志应该记录什么？

每一次API调用（时间、端点、参数、返回结果）
每一次订单操作（下单、撤单、成交）
每一次配置变更（谁、什么时候、改了啥）
每一次异常事件（连接断开、超时、错误响应）

日志格式要结构化，方便后续分析。我推荐用JSON格式，而不是纯文本。

{
  "timestamp": "2024-01-15T10:30:00.123Z",
  "event_type": "order_placed",
  "user": "system",
  "details": {
    "symbol": "BTC/USDT",
    "side": "buy",
    "price": 42000.50,
    "quantity": 0.5,
    "order_id": "abc123"
  },
  "result": "success"
}

🔑 关键点：审计日志不能篡改。我建议使用「追加写入」模式，日志文件只增不减。如果条件允许，可以加上哈希链，确保日志完整性。

另外，日志要定期归档和清理。别等到磁盘满了才发现——我有个朋友，日志把磁盘撑爆了，系统直接崩溃，那叫一个惨。

知识体系总览

下面这张图，把本章四个核心模块的关系画清楚了：

这四个模块，每一个单独拿出来都不复杂。但组合在一起，就能构建一个相对安全的做市系统。记住一句话：安全不是功能，是习惯。每次部署新策略、新服务器，都要把这几步走一遍。

好了，今天就聊到这儿。下一章咱们会深入一个具体的安全实践——如何设计一个防篡改的审计日志系统。到时候见。

📚 课程目录