请设计一个针对铁路客票系统的数据安全架构，需考虑数据分类、访问控制、传输加密、存储加密及审计日志，并说明各组件如何协同工作。

1) 【一句话结论】
构建分层、协同的数据安全架构，通过数据分类、访问控制、传输加密、存储加密及审计日志的协同，从数据生命周期各阶段防护铁路客票系统，形成纵深防御体系，确保数据安全。

2) 【原理/概念讲解】
老师口吻解释各组件作用：

• 数据分类：按敏感度分公开（车次、站点）、内部（订单、历史记录）、敏感（支付信息、用户身份）、核心（系统配置、密钥），类比给数据贴不同颜色的标签，不同标签对应不同防护措施。
• 访问控制：采用RBAC（基于角色，如售票员、管理员、普通用户）与ABAC（基于属性，如用户角色+设备状态+时间）结合，类比门卫，不同角色的人进不同区域，动态调整权限。
• 传输加密：采用TLS 1.3（传输层安全），端到端加密，类比快递的密封包装，防止中途被窃取。
• 存储加密：数据库字段加密（如支付卡号）、文件系统加密（如历史数据文件），类比保险柜，数据在静态时也安全。
• 审计日志：记录所有关键操作（登录、查询、修改、删除），包含时间、用户ID、操作类型、IP地址，类比监控录像，用于追溯。

3) 【对比与适用场景】

组件	定义	特性	使用场景	注意点
RBAC	基于角色分配权限，角色对应一组权限	静态角色，权限集中管理	标准业务流程，角色明确（如售票员、管理员）	可能僵化，难以适应复杂业务
ABAC	基于用户属性（角色、设备、时间等）动态授权	动态属性，灵活授权	复杂场景，如临时权限、设备安全状态	属性定义复杂，计算开销大

4) 【示例】
伪代码示例（用户查询车票）：

• 请求（HTTPS，TLS加密）：

  GET /api/tickets?from=北京&to=上海&date=2024-05-20 HTTP/1.1
  Host: ticket.railway.com
  Authorization: Bearer user_token
  User-Agent: MobileApp/1.0
  

• 数据库查询（存储加密）：

  SELECT ticket_id, departure, arrival, price 
  FROM tickets 
  WHERE departure='北京' AND arrival='上海' AND date='2024-05-20' 
  AND encrypted_payment IS NULL -- 仅查询非支付信息，支付信息加密存储
  

• 审计日志记录：

  {
    "timestamp": "2024-05-20T10:30:00Z",
    "user_id": "user_123",
    "operation": "query",
    "resource": "/api/tickets",
    "parameters": {"from": "北京", "to": "上海", "date": "2024-05-20"},
    "ip_address": "192.168.1.100",
    "success": true
  }
  

5) 【面试口播版答案】
面试官您好，针对铁路客票系统的数据安全架构，我设计的是一个分层、协同的体系。首先数据分类，按敏感度分公开（如车次信息）、内部（用户订单）、敏感（支付信息）、核心（系统配置），不同级别采取不同防护。访问控制用基于角色的（RBAC）和基于属性的（ABAC）结合，比如售票员有“售票角色”，能访问订单数据，而普通用户只能查询。传输加密采用TLS 1.3，所有客户端与服务器通信都加密，比如用户登录时，密码和订单信息通过TLS传输。存储加密方面，数据库中的用户支付信息用AES-256加密，密钥由HSM管理，文件系统中的历史数据用文件级加密。审计日志记录所有关键操作，比如用户查询订单、修改密码，日志包含时间、用户ID、操作类型、IP地址，并存储在安全区域，定期审计。各组件协同：数据分类确定防护等级，访问控制决定谁能操作，传输加密保护传输过程，存储加密保护静态数据，审计日志追溯所有操作，形成闭环。这样从数据生命周期各阶段防护，确保数据安全。

6) 【追问清单】

• 问题1：数据分类的具体分级标准？
  回答要点：参考《等保2.0》，按敏感程度分为公开、内部、敏感、核心四类，敏感数据如支付信息属于最高级，需最严格防护。
• 问题2：访问控制中ABAC的属性如何定义？
  回答要点：属性包括用户角色（如售票员）、设备状态（是否为公司设备）、时间（工作时段），动态计算权限，例如周末临时权限。
• 问题3：传输加密是否考虑移动设备？
  回答要点：移动设备采用TLS 1.3与设备证书（PKI），确保移动端到服务器的通信安全，支持设备指纹验证。
• 问题4：存储加密的密钥管理？
  回答要点：密钥由HSM管理，轮换周期90天，解密密钥仅授权给授权的数据库实例。
• 问题5：审计日志的存储和保留期限？
  回答要点：存储在加密日志服务器，保留3年（符合等保要求），定期审计异常操作。

7) 【常见坑/雷区】

• 坑1：忽略数据分类的粒度，仅分公开和内部，遗漏敏感数据（如支付信息），导致防护不足。
• 坑2：访问控制仅用RBAC，忽略ABAC的动态属性，无法应对复杂业务场景。
• 坑3：传输加密仅考虑服务器端，忽略客户端到客户端的通信（如用户间分享订单），导致中间人攻击风险。
• 坑4：存储加密未考虑密钥管理，密钥存储在明文或弱加密中，导致密钥泄露。
• 坑5：审计日志未考虑隐私保护，记录用户敏感信息，违反《个人信息保护法》。