第1章票务系统安全概述

1、票务系统安全概述

大家好，我是这次课程的主讲人。在轨道交通行业摸爬滚打了十几年，我见过太多因为安全问题翻车的案例了。今天咱们就来聊聊票务系统安全这个事儿。

说实话，很多人觉得票务系统嘛，不就是刷刷卡、扣扣钱？哪有那么复杂。但你想想看，每天几百万甚至上千万的乘客数据在系统里流转，一旦出事，那可不是闹着玩的。

我先把最常见的三种威胁摆出来。这些都是我在实际项目中踩过的坑，或者亲眼见过的教训。

说白了，就是不该看的人看到了不该看的数据。乘客的姓名、身份证号、银行卡信息、出行轨迹……这些一旦泄露，后果不堪设想。

我记得有一次，某城市的地铁票务系统被爆出用户数据在暗网售卖。后来一查，问题出在数据库的访问权限配置上——一个实习生把测试库的权限设成了公开。嗯，这种低级错误，其实挺常见的。

这个更可怕。攻击者修改了票务数据，比如把一张普通票改成月票，或者把余额从10块改成1000块。你想想，如果这种攻击成功了，地铁公司得亏多少钱？

我曾经参与过一个项目的安全审计，发现他们的交易记录居然没有做完整性校验。攻击者只要截获一个数据包，改几个字节，就能免费坐车。我当时就跟他们说了：这漏洞不补，迟早出事。

这个技术名词听着高大上，其实原理很简单。攻击者把乘客刷卡时的数据包复制一份，然后自己再发一遍。系统以为是正常交易，就放行了。

为什么会这样？因为很多早期的票务系统，压根没考虑过数据包的时效性。我见过一个案例，攻击者用一台笔记本在闸机旁边蹲了三天，收集了上千个刷卡数据包，然后批量重放。结果呢？闸机全开了，地铁公司损失惨重。

⚠️ 避坑指南： 我曾经接手过一个项目，客户说他们的系统很安全，因为用了AES加密。我当场就笑了——加密只能防数据泄露，防不了重放攻击。后来我给他们加了个时间戳+随机数的方案，才把这个问题解决。

聊完威胁，咱们说说安全目标。信息安全领域有个经典的「CIA三元组」，在票务系统里同样适用。

安全目标	英文	通俗解释	票务场景举例
机密性	Confidentiality	数据只有授权的人能看	乘客的支付信息不能被第三方窃取
完整性	Integrity	数据在传输和存储中不被篡改	交易金额、余额不能被恶意修改
可用性	Availability	系统在需要时能正常使用	早晚高峰闸机不能宕机

我个人习惯把这三个目标记成「该保密的保密、该完整的完整、该能用的能用」。听起来像废话，但真正做到的系统，说实话不多。

  💡 我的经验：
  这三个目标其实是互相制约的。比如你为了机密性，把数据加密得死死的，结果解密太慢，闸机响应时间从0.3秒变成了3秒——可用性就完蛋了。所以做安全设计，本质上是在找平衡点。

好，咱们这门课一共30章，我简单给你捋一捋。

前5章是基础篇。讲清楚票务系统的架构、数据流、以及最核心的加密算法。我建议你认真看，因为后面所有的内容都建立在这些基础上。

第6到15章是传输安全篇。这部分我会重点讲数据在传输过程中怎么保护。包括TLS协议、数字签名、密钥管理这些。嗯，这里有个坑我要提前说——很多人以为用了HTTPS就万事大吉了，其实不是的。具体为什么，咱们后面细聊。

第16到25章是存储安全篇。数据到了服务器端怎么存？数据库加密怎么做？日志怎么保护？这些我都会结合实际案例来讲。

最后5章是实战篇。我会带着你做一个完整的票务系统安全方案设计。从需求分析到方案落地，每一步我都会告诉你：我当年是怎么做的，踩过哪些坑，最后怎么解决的。

📌 学习建议： 我建议你每学完一章，都去想想：如果我是攻击者，我会怎么攻击这个环节？这种「攻防思维」能帮你更快地理解安全设计的本质。

好了，第一章就到这里。下一章咱们聊聊票务系统的整体架构，以及数据到底是怎么流转的。到时候我会拿一个真实项目的架构图出来，咱们一起拆解。

记住一句话：安全不是功能，是属性。它不是装上去的，而是设计出来的。