软件安全与漏洞--实验 软件安全需求分析

实验任务

假定为学校开发一个在线学习系统，请给出该系统的安全需求分析。

角色用例图

作用：展示"谁（角色）"在系统里"能做什么（功能）"。

第一步：确定角色

根据案例描述，系统主要有三个角色：

• 学生：系统的主要使用者，学习资源，提交作业。
• 教师：资源提供者，布置作业，批改成绩。
• 管理员：系统的维护者，管理用户账号，维护系统运行。

第二步：确定用例

根据教材案例中的业务描述（图6-3左侧的模块），我们可以提取出核心功能：

• 学生：登录、浏览课程、在线观看视频、提交作业、查看成绩、个人中心管理。
• 教师：登录、发布课程资源、布置作业、批改作业/录入成绩、查看学生互动。
• 管理员：登录、用户管理（增删改查）、课程审核、系统日志查看、数据备份。

第三步：画图

你可以使用 Visio 、StarUML 、ProcessOn 或 Draw.io 等工具。

图形结构参考：

1. 画一个大方框，代表**"在线学习系统"边界**。
2. 在方框左边画一个小人，标记为**"学生"**。
3. 在方框右边画一个小人，标记为**"教师"**。
4. 在方框下方（或上方）画一个小人，标记为**"管理员"**。
5. 在方框内部画椭圆，代表功能（用例）。
6. 用直线把小人和对应的椭圆连起来。

连线逻辑示例：

• 学生 ------> (登录)、(浏览课程)、(提交作业)、(查看成绩)
• 教师 ------> (登录)、(发布资源)、(批改作业)、(录入成绩)
• 管理员 ------> (登录)、(用户管理)、(系统维护)

注意：教材图6-3其实已经暗示了这些功能模块（左侧的"课程资源"、"作业管理"、"个人中心"等），你只需要把它们转化为标准的UML用例图即可。

系统业务流程图

作用：展示数据和控制流是如何在系统各模块之间流动的，特别是体现"交互"的过程。

根据教材图6-3（在线学习系统业务流程图），这是一个非常典型的数据流图风格的业务流程图。你可以直接模仿它的结构来画。

核心流程梳理（根据图6-3）

这个系统主要围绕三个核心交互：

1. 资源交互（教师传资源 -> 学生看资源）
2. 作业交互（教师发布作业 -> 学生交作业 -> 教师改作业 -> 学生看成绩）
3. 管理交互（管理员维护系统）

绘图步骤（模仿图6-3）

工具：Visio、ProcessOn等。

主要节点（方框/圆柱体）：

1. 数据库/存储 （通常用圆柱体表示）：
   • 课程资源库
   • 作业题库
   • 试卷/成绩库
2. 功能模块 （通常用圆角矩形或普通矩形）：
   • 课程资源管理
   • 作业管理
   • 个人中心
   • 好友互动（或讨论区）
   • 通信管理
   • 管理员后台
3. 外部实体（用户） （通常用小方框或小人）：
   • 学生
   • 教师
   • 管理员

连线与流向（箭头）：

你可以按照以下逻辑画箭头，这就构成了完整的业务流程：

1. 课程流程：

   • 教师 -> (发布) -> [课程资源管理] -> (存入) -> {课程资源库}
   • {课程资源库} -> (读取) -> [课程资源管理] -> (展示) -> 学生

2. 作业流程：

   • 教师 -> (布置) -> [作业管理] -> (存入) -> {作业题库}
   • {作业题库} -> (读取) -> [作业管理] -> (展示) -> 学生
   • 学生 -> (提交答案) -> [作业管理] -> (暂存) -> {作业题库}
   • 教师 -> (批改) -> [作业管理] -> (存入成绩) -> {试卷/成绩库}
   • 学生 -> (查看) -> [作业管理] -> (读取) -> {试卷/成绩库}

3. 互动流程：

• 学生 <-> (提问/回答) <-> [好友互动/讨论区]

1. 管理流程：

• 管理员 -> (操作) -> [管理员后台] -> (管理) -> 所有数据库和模块

核心安全需求

• 保密性需求

  • 参考图1下方的文字：
  • 用户密码保护：系统必须对学习者、教师和管理员的登录密码进行哈希加盐存储，严禁明文存储。
  • 数据传输加密：用户登录时的账号密码、支付信息（如果有）、个人隐私（如手机号、身份证号）在传输过程中必须使用TLS/SSL协议加密，防止中间人攻击。
  • 隐私保护：学生只能查看自己的成绩和学习记录，教师只能查看自己课程的学生名单，严禁越权查看他人隐私数据。
  • 日志脱敏：系统日志中不能包含用户的明文密码或敏感个人信息。

• 完整性需求

  • 防篡改：教师上传的课件、视频以及录入的成绩，必须防止被未授权人员（如黑客或其他学生）篡改。
  • 数据校验：在数据传输过程中（例如提交作业），需校验数据完整性，防止数据包在传输中被截获修改。

• 可用性需求

  • 抗攻击：系统应具备防御DDoS攻击的能力，保证在选课高峰期或考试期间，合法用户能正常访问系统。
  • 容错：当某个模块（如视频播放）崩溃时，不应导致整个系统（如登录功能）不可用。

• 可认证性需求

  • 身份验证：所有用户（学习者、教师、管理员）在访问系统前必须通过身份验证。
  • 多因素认证：对于管理员后台，建议采用双因素认证（如密码+验证码）以增强安全性。

• 授权需求

  • 角色权限控制 ：基于角色的访问控制。
    • 学习者：仅拥有"观看视频"、"提交作业"、"查看个人中心"的权限。
    • 教师：拥有"上传课程"、"批改作业"、"管理班级"的权限。
    • 管理员：拥有"审核教师身份"、"设置系统参数"的权限。

• 可审计性需求

  • 操作留痕：系统需记录关键操作日志，例如"管理员修改了用户权限"、"教师修改了学生成绩"、"用户登录失败"等，以便事后追溯。

通用需求

这部分主要关注系统的基础架构和通用组件的安全，是保障整个系统稳定运行的基石。

• 安全架构需求

  • 参考内容：图片3（页码155）提到，安全架构需考虑系统自身的可靠、兼容、经济性，以及与现有IT设施的集成。
  • 实验报告填充建议 ：
    • 系统应采用分层架构（如MVC），确保业务逻辑层与数据访问层分离，降低单点故障风险。
    • 系统需具备与学校现有的统一身份认证系统（如LDAP或CAS）集成的能力，实现单点登录。
    • 系统架构设计应具备高可用性和可扩展性，以应对未来用户量增长的需求。

• 会话管理需求

  • 参考内容：图片3（页码155）指出，会话管理需保证会话在安全状态下有效执行。
  • 实验报告填充建议 ：
    • 用户登录后，系统应生成一个唯一且随机的会话ID（Session ID）。
    • 会话ID必须在传输过程中通过HTTPS加密，防止会话劫持。
    • 系统需设置会话超时机制，例如用户连续15分钟无操作后，自动退出登录。
    • 用户主动点击"退出登录"时，服务器端必须立即销毁该会话。

• 错误和例外管理需求

  • 参考内容：图片3（页码155）强调，需明确错误信息处理和记录的方式。
  • 实验报告填充建议 ：
    • 系统发生错误时，向用户展示的应是友好的通用错误提示（如"系统繁忙，请稍后再试"），而不能暴露详细的系统错误信息（如数据库结构、代码堆栈），防止信息泄露。
    • 所有系统错误和异常都必须被详细记录到服务器端的错误日志中，供开发人员排查问题。

• 配置参数管理需求

  • 参考内容：图片3（页码155）提到，软件配置需被保护以防恶意攻击。
  • 实验报告填充建议 ：
    • 数据库连接字符串、管理员账户、加密密钥等敏感配置信息，必须加密存储，不能以明文形式写在配置文件中。
    • 应限制对系统配置文件的访问权限，仅允许授权的运维人员进行修改。

运维安全需求

这部分关注系统部署上线后的日常维护和安全保障工作。

• 环境部署需求

  • 参考内容：图片3（页码155）提出，需考虑系统运行在何种网络环境，以及是否驻留在非军事区（DMZ）。
  • 实验报告填充建议 ：
    • 系统应部署在经过安全加固的服务器操作系统上，并关闭所有不必要的服务和端口。
    • 应用服务器和数据库服务器应部署在内网，通过防火墙进行隔离，仅开放必要的通信端口。
    • 部署过程应有标准化的脚本和流程，确保环境的一致性，避免人为配置错误。

• 归档需求

  • 参考内容：图片3（页码155）讨论了数据归档的必要性，包括归档内容、位置和保存年限。
  • 实验报告填充建议 ：
    • 系统需定期（如每学期末）对历史课程数据、学生作业和成绩进行归档。
    • 归档数据应存储在独立、安全的存储介质或离线服务器上，与在线业务系统分离。
    • 根据教育部门规定，学生成绩等关键数据的归档保存时间应不少于学生毕业后5年。

• 反盗版需求

  • 参考内容：图片3（页码155）提到，利用加密和防篡改措施保护版权。
  • 实验报告填充建议 ：
    • 教师上传的教学视频、课件等版权资料，应采用数字水印技术进行标记。
    • 视频流应采用加密传输和播放，防止被轻易下载和传播。
    • 系统应具备检测异常下载行为的能力（如单个账号短时间内大量下载），并进行告警或限制。

其他安全需求

这部分涵盖了一些特定场景或高级的安全考量。

• 顺序和时间需求

  • 参考内容：图片4（页码157）解释了检查-时间/使用-时间（TOCTOU）攻击，强调了操作的原子性。
  • 实验报告填充建议 ：
    • 在"选课"功能中，必须确保"检查课程余量"和"占用一个名额"这两个操作是原子性的（即在数据库事务中完成），防止多个学生同时选课时出现超卖问题。
    • 文件上传功能需确保在检查文件类型安全后，到文件被最终保存的整个过程中，文件不会被替换。

• 国际化需求

  • 参考内容：图片4（页码157）提到，应用需遵守不同国家的法律法规。
  • 实验报告填充建议 ：
    • 如果系统面向国际学生，需确保用户个人信息的收集、存储和处理符合欧盟的《通用数据保护条例》（GDPR）等相关隐私法规。
    • 系统界面应支持多语言切换，且在不同语言环境下，所有安全提示信息都能清晰、准确地传达。

• 软件采购需求

  • 参考内容：图片4（页码157）指出，即使是购买软件，也需评估其安全需求。
  • 实验报告填充建议 ：
    • 如果系统使用了第三方的视频播放器或在线文档预览组件，必须要求供应商提供该组件的安全评估报告，确保其没有已知的严重漏洞。
    • 采购合同中应明确，供应商需在发现其软件存在安全漏洞时，及时提供补丁和更新支持。

实验结论

通过本次针对"行知学院在线学习系统"的安全需求分析，我掌握了如何从身份认证、访问控制、数据加密等维度挖掘软件的安全需求。我认识到，安全需求分析是软件开发的基石，如果在需求阶段忽略了安全性（如未考虑输入验证），后期将留下巨大的安全隐患（如被黑客注入攻击）。

实验体会

在实验过程中，我意识到安全不仅仅是技术问题，更是逻辑问题。比如，在画用例图时，我需要站在攻击者的角度思考：如果我是学生，我能否通过修改URL参数查看别人的作业？这种"白帽子"思维的训练让我受益匪浅。同时，我也明白了运维安全的重要性，系统上线后的补丁更新和日志审计同样关键。