4. AI系统安全需求工程

安全需求工程的核心任务，是把“业务想做什么”翻译成“系统必须满足哪些可验证的安全约束”。在AI系统中，这一翻译过程比传统软件更复杂：模型行为具有概率性，训练数据与推理数据分离，模型本身既是资产又是攻击面，输出还可能被滥用。因此，不能简单套用“加密、鉴权、审计”三件套，而要从业务目标出发，逐层推导出机密性、完整性、可用性、隐私与滥用防护五类需求，并为每一类需求定义可观测、可测试的验收条件。

从业务目标到安全目标的映射

假设一个面向医院的AI辅助诊断系统，业务目标是“帮助放射科医生在5分钟内完成肺结节初筛，并保留可追溯的诊断依据”。这个目标隐含了多个安全前提：患者影像和病历不能泄露给无关人员（机密性）；模型输出不能被篡改或伪造（完整性）；医生在急诊时段必须能稳定调用（可用性）；训练数据中的患者身份信息不能反向还原（隐私）；系统不能被用来批量生成虚假诊断报告（滥用防护）。

映射时建议采用“业务目标→资产→威胁→安全目标→需求条目”的链路。资产包括模型权重、训练数据、推理接口、日志、API密钥、患者影像。威胁则来自外部攻击者、内部越权人员、模型自身缺陷以及第三方依赖。安全目标是对威胁的否定式陈述，例如“未授权用户不得通过推理接口获取训练数据成员信息”。需求条目则必须可验证，例如“对同一患者ID的推理请求，返回结果中不得包含该ID在训练集中的出现次数或置信度差异”。

五类需求的推导要点与可验证写法

机密性在AI系统中至少覆盖三个层面：模型权重、训练数据、推理交互。模型权重是核心知识产权，若被完整窃取，攻击者可离线复现服务；训练数据可能包含敏感样本；推理请求和响应则可能暴露患者信息。可验证写法应避免“加密存储”这类模糊表述，改为“模型权重文件在磁盘上以AES-256-GCM加密，密钥由KMS托管，未授权进程读取文件时只能获得密文”。验收测试可以尝试直接读取权重文件并计算熵值，若熵值接近随机分布则说明加密生效。

完整性关注的是“数据或模型没有被未授权修改”。在AI场景中，完整性威胁包括训练数据投毒、模型参数篡改、推理结果伪造。可验证需求应明确校验对象、算法和失败行为。例如“推理请求体和响应体均附加HMAC-SHA256签名，服务端在10ms内完成校验，校验失败返回401并记录请求指纹”。测试时修改请求体任意一个字节，观察是否100%被拒绝。

可用性对AI系统尤为关键，因为模型推理可能因GPU资源竞争、模型加载缓慢或第三方API限流而不可用。需求应包含量化指标和降级策略。例如“在100并发、持续10分钟的压测下，推理服务P99延迟不超过3秒，错误率低于0.5%；当模型推理超时超过2秒时，自动切换至基于规则的兜底逻辑，保证核心筛查流程不中断”。验收时使用压测工具模拟并发，观察监控面板上的P99和错误率曲线。

隐私需求不能停留在“数据脱敏”层面。AI模型可能通过成员推断攻击泄露训练集中是否包含某条记录，也可能通过模型反演还原训练样本。可验证需求应包含攻击抵抗指标。例如“训练数据在进入训练流程前完成去标识化，直接标识符全部移除，准标识符泛化至k-匿名k≥5；训练完成的模型在成员推断攻击下的AUC不超过0.55”。测试时使用影子模型攻击方法，计算攻击者区分成员与非成员的能力。

滥用防护针对的是“系统被用来做不该做的事”。在诊断系统中，滥用可能表现为批量生成虚假报告、绕过医生审核直接输出诊断、或利用接口进行模型蒸馏。可验证需求应包含速率限制、输出水印和异常检测。例如“单账号每分钟推理调用不超过30次，超出返回429并触发告警；所有诊断输出嵌入不可见水印，水印提取准确率不低于99%”。测试时模拟第31次调用，观察响应码和告警日志。

需求规格的验收条件与追溯

每条安全需求必须附带验收条件，否则无法在开发完成后判断是否达标。验收条件应包含：测试对象、测试方法、通过阈值、失败处理。例如“SR-INT-02：使用HMAC-SHA256对推理请求签名，测试方法为修改请求体1字节后发送，通过阈值为100%拒绝，失败处理为阻断发布并回滚模型版本”。

需求追溯矩阵是需求工程的收尾工具。它把业务目标、资产、威胁、安全需求、测试用例和验收状态关联起来。当业务目标变更时，可以快速定位哪些安全需求需要重新评估。例如业务目标从“5分钟初筛”扩展为“支持远程会诊”，则可用性需求中的延迟指标和机密性需求中的传输加密范围都需要更新。

最后需要强调，五类需求之间存在张力。提高隐私保护（如差分隐私噪声）可能降低模型精度，进而影响可用性；加强滥用防护（如严格限流）可能影响急诊场景下的响应速度。需求工程的任务不是消除张力，而是把张力显式化，让业务方、安全团队和开发团队在明确的量化指标下做出权衡决策。可验证的安全需求规格，正是这种权衡的书面契约。