计算机安全总复习 Part1

发表于 分类于

评课社区叫我不要记这种笔记, 但是众所周知我记吃不记打.

绪论, 计算机安全基础, 身份识别与认证, 访问控制

绪论#

系统安全的方法论#

  • 以系统思维应对安全问题
  • 应对系统面临的安全问题

安全策略的精确表示 (形式化表示), 称为安全模型.

为使理论色彩比较浓厚的安全模型的作用能落实到实处, 需要为它设计出便于在信息系统中实现的形式, 这种形式称为安全机制.

必须在网络空间的系统中实现一定的安全机制, 网络空间的系统才有可能称为安全系统.

脆弱性: 系统的缺陷或漏洞, 可被利用来破坏资产.

攻击面: 由系统中可到达的和可被利用的脆弱点构成. 例如: 对外开放的端口, 对敏感信息有权限的员工等. 包括网络攻击面, 软件攻击面, 人为攻击面.

攻击树#

  • 树根: 一般类的攻击, 攻击目标
  • 树结点: 达成攻击所需的子目标
  • 叶子节点: 发起一个攻击的不同方式
  • 除了叶子结点外的每一个结点: 与节点 (AND-node) 或或结点 (OR-node)
  • 边: 赋权值, 估算攻击的成本, 发生的可能性, 成功的可能性

社会工程学: 暗黑心理学, 识人术, 人性的秘密, 后面忘了.

计算机安全基础#

CIA 三要素#

  • Confidentiality 保密性, 消息不会被非法泄露扩散. 实现方法: 加密保护阻止理解, 访问控制阻止获取
  • Integrity 完整性, 消息的来源, 去向, 内容真实无误, 未被篡改, 删除或以任何方式损坏. 包括数据完整性, 系统完整性
  • Availablility 可用性, 系统及时工作, 并向授权用户提供所需服务
  • Survivablity 可生存性, 遭受打击后系统仍能完成任务, 并能及时修复被损坏的服务
  • Accountability 可审计性 (问责性)
  • Non-repudiation 不可否认性, 可审计性的更强形式
  • Controllability 可控性, 对于信息安全风险的控制能力, 即通过一系列措施, 对信息系统安全风险进行事前识别, 预测, 并通过一定的手段来防范, 化解风险, 减少遭受的损失的可能性

4A 大作#

  • 认证 Authentication 提供认证方式
  • 授权 Authorization 可以对用户的资源访问权限进行集中管理
  • 审计 Auditing 将用户所有的操作日志集中记录管理和分析
  • 记账 Accounting 为用户提供统一集中的账号管理

计算机安全定义#

研究如何预防和检测计算机系统用户的非授权行为.

PDRR 模型#

  • Protect 保护, 保障信息的这个性那个性
  • Detect 检测, 检查系统存在的漏洞, 脆弱性, 攻击, 恶意代码等
  • React 响应, 对危及安全的事件, 行为做出及时处理
  • Restore 恢复, 系统遭到破坏, 尽快恢复系统功能, 尽早提供正常服务

有时简化为 PDR:

  • Prevention 预防
  • Detection 检测
  • Reaction 响应

别问我为什么检测完词性全变了, 我也不知道.

有时扩展为 PPDRR:

  • Policy 策略
  • Protection 防护
  • Detection 检测
  • Response 响应
  • Recovery 恢复

隐蔽信道和侧信道#

隐蔽信道: 一种违反系统安全策略, 不被安全机制控制的信息传递通道. 它并不使用正常的通信接口, 而是利用原本不是为通信设计的共享资源或通道, 通过特殊编码来偷偷传输数据.

侧信道攻击: 利用密码算法在软硬件实现中泄露出的各种信息进行攻击, 例如声音, 时间, 电磁辐射等.

计算机安全设计原则#

  • 保护机制集中在数据, 操作还是用户上? 传统上为数据, 现代则多为用户行为
  • 一个安全机制应该被放置在计算机系统的哪一个层次上?
  • 与富有特色的安全环境相比, 你是否偏爱简单性和更高的保证?
  • 定义和实施安全的任务是应该交给一个中央实体, 还是应该托付给系统中的各个成员?
  • 如何防止攻击者访问位于保护机制下面的层?

计算机安全防护原则#

  • 整体性原则, 整体构思和设计系统
  • 分层性原则, 设置多个防护层次, 单点失效不出现严重影响
  • 最小授权原则, 权限分割, 互相制约, 最小化原则
  • 简单性原则, 使过程尽量简洁, 安全工具便于使用和管理
  • 等级性原则, 安全层次和安全级别, 良好的信息安全系统必然是分为不同级别的

身份识别与认证#

标识 (Identification), 用户标识符

鉴别 (Authentication), 将用户标识符与用户物理身份联系的过程

认证系统#

  • 鉴别信息的集合 A: 实体用来证明其身份的特定信息的集合. 如 Unix 的明文口令的集合
  • 辅助信息的集合 C: 系统存储并且用来证实鉴别信息的集合信息集合. 如 Unix 的密文口令的集合
  • 辅助函数的集合 F: 由鉴别信息产生辅助信息的函数的集合. 即 f ∈ F, f: A → C. 如 Unix 的 Hash 函数的集合
  • 鉴别函数的集合 L: 验证身份的函数的集合. 即对于 l ∈ L, l: A × C → {true, false}
  • 选择函数的集合 S: 允许实体创建或改变鉴别信息和辅助信息. 如创建, 修改口令, 选择加密算法等

可供选择的认证方法:

  • 所知信息
  • 所拥有物品
  • 生理特征
  • 行为特征
  • 位置信息

双因素认证: 选两个混用

口令#

加盐口令

口令空间

口令猜测

我已经不认识呤了

口令认证机制的安全性 (猜测, 欺骗, 文件泄露, 遗忘)

访问控制#

是在身份认证基础上, 依据授权对提出的资源访问请求加以控制, 限制已授权的实体访问本系统中资源的过程.

  • 主体/主角 (Subject/Principal): 访问的发起者
  • 客体/对象/目标 (Object): 供访问的软硬件资源
  • 访问 (Access): 读写, 执行, 删除, 创建, 搜索等

即 SOA 模型.

访问权限#

读, 写, 添加/盲写 (append), 执行 (execute)

DAC 与 MAC#

  • 自主访问控制 DAC, Discretionary Access Control, 为每个资源定义一个所有者, 让所有者规定谁可以访问
  • 强制访问控制 MAC, MandatoryAccess Control, 系统策略规定谁可以访问

访问控制结构#

访问控制矩阵#

访问控制矩阵 M=(Mso)s∈S,o∈OM = (M_{so})_{s \in S, o \in O} , 其中 Mso⊆AM_{so} \subseteq A .

S (行) 是主体集合, O (列) 是客体集合, A 是访问操作集合.

不适用于直接实现, 不方便安全管理.

是稀疏矩阵, 每行称作访问能力表 (CL), 每列称作访问控制列表 (ACL).

ACL 与 CL#

  • 保存位置不同, ACL 在客体上, CL 在主体上
  • 需要鉴别的实体不同, ACL 鉴别客体, CL 鉴别主体
  • 浏览访问权限 (查看某个文件谁可以读写): ACL 容易, CL 困难
  • 访问权限传递 (分享对某个文件的权限): ACL 困难, CL 容易
  • 访问权限回收 (某个文件不再开放): ACL 容易, CL 困难
  • ALC->CL 困难, CL->ACL 容易
  • 原因: 主体少, 客体多

对于数量众多的主体和客体或者主体和客体的集合频繁改变时, 这种结构管理起来很不方便, 而采用中间控制层是较为可取的.

中间控制#

在主体和客体之间加一层组.

可插入的层包括: 角色, 过程, 数据类型.

偏序#

自反传递反对称

哈斯图, 有向图

访问控制策略#

仅当客体的 ability 是主体的 ability 的一个前缀时允许访问.

不能采用主体的 ability 是客体的 ability 的前缀的策略, 否则未赋值的空串能访问所有.

失效保护的行为要求拒绝访问.

格#

对任意两个元素存在最小上界和最大下界.

a≤b 称为 a 被 b 支配, b 支配 a.

最低: 系统低, 最高: 系统高. 集合有限则存在, 存在则唯一.

多级安全策略#

Multi-Level Security

无向上读, 无向下写

各种访问控制#

  • 自主访问控制 DAC, Discretionary Access Control
    系统完全基于请求者的身份以及预先设定的访问规则 (授权列表) 来决定是否放行, 所有者拥有最大权限
  • 强制访问控制 MAC, Mandatory Access Control
    系统通过比对实体的安全许可和资源的安全标签控制访问
  • 基于角色的访问控制 RBAC, Role-Based Access Control
    系统不再将权限直接赋予具体的用户, 而是将权限赋予特定的角色, 再根据用户所在的岗位为其分配对应的角色

基于角色的访问控制 (RBAC)#

将访问权限分配给角色, 用户通过被指派为角色从而获得角色所拥有的访问权限

  • RBAC0, 基础模型
    一个用户可以拥有多个角色, 一个角色可以包含多个用户 (多对多)
    一个角色可以拥有多个权限, 一个权限可以被分配给多个角色 (多对多)
  • RBAC1, 层次模型 (角色继承)
    高级角色自动继承低级角色的所有权限
    简化了权限管理, 减少冗余的权限分配
  • RBAC2, 约束模型
    某些角色不能被分配给同一个用户 (静态职责分离)
    一个用户可以同时拥有两个互斥角色, 但一次登录会话只能激活一个 (动态职责分离)
    限制角色被分配的用户数量, 或者一个用户能拥有的角色数量 (基数约束)
    用户只有拥有角色 A 才能拥有角色 B (先决条件约束)
  • RBAC3, 统一模型, 即 RBAC1+RBAC2

RBAC 的优点:

  • 支持最小权限原则, 责任分离原则
  • 支持数据抽象原则和继承概念
  • 模型中概念与实际系统紧密对应

缺点:

  • 没有提供信息流控制机制
  • 没有提供操作顺序控制机制
  • 其他问题

基于任务的访问控制 (TBAC)#

动态授权, 只有当业务流程走到某个具体任务, 并且该任务被激活时, 执行该任务的用户才会在这一瞬间获得所需的权限; 一旦任务完成或挂起, 权限立刻被系统收回.

构成:

  • 工作流 Wf, 底盘搭建 →\rightarrow 引擎安装 →\rightarrow 喷漆出厂, 完整的流程体系
  • 授权结构体 Au, 封装任务及其相关授权信息的逻辑容器
  • 授权步, 权限验证的最小细粒度操作, 例如在安装引擎这个大任务中, 拿起扳手是一个授权步, 拧螺丝是另一个授权步
  • 受托人集 T, 有资格, 被指派去执行某个任务, 并因此在任务激活时获得权限的主体集合
  • 许可集 P, 在某个特定的授权步中, 允许执行的具体操作集合及其对应的客体, <操作, 资源>, 例如允许你用 10 号扳手拧 10 号螺丝
  • 任务
  • 依赖, 任务与任务之间, 授权步与授权步之间的逻辑和时序约束条件, 必须打开盖子再喝水

授权用五元组 (S, O, P, L, AS) 表示

  • Subject 主体
  • Object 客体
  • Permission 许可
  • Lifecycle 生命周期, 权限的存活时限
  • Authorization Step 授权步, 在哪一步, 业务流转到了哪个具体的检查点或任务环节

动态授权, 授权步的五种状态

  • 睡眠, 授权步未生成
  • 激活, 授权步已经生成
  • 有效, 授权步开始执行
  • 挂起
  • 无效, 授权步可以删除

授权步的生命期, 许可的次数限制和授权步的自我动态管理, 三者形成了 TBAC 的动态授权.

ABC 模型#

基本元素: 主体, 客体, 权限 Right

授权相关元素: 授权规则 Authorization, 义务 oBligation, 条件 Condition

扩展元素: ATT (S), ATT (O), 主体属性和客体属性

授权规则是主体使用客体权限必须满足的规则集, 义务是获得权利前或过程中必须完成的操作, 条件是获得权利前或过程中必须满足的强制约束条件

授权规则是针对主体和客体的内部属性, 条件是外部环境 (时间地点, 网络状态, CPU 负载等)

新特性:

  • 连续性: 授权决策在资源的使用过程中对访问请求进行不间断的或重复的判断
  • 可变性: 属性需随着主体行为而被改变

UCON 的 16 个基本模型#

维度一: 时间阶段

  • pre (事前): ** 在访问发生前**做决定.
  • on (事中/持续): ** 在访问过程中**持续做决定.

维度二: 控制要素

  • **A (Authorization): ** 授权规则.
  • **B (Obligation): ** 义务.
  • **C (Condition): ** 环境条件.

维度三: 属性更新策略

  • **0 (无更新): ** 属性不变 (Immutable).
  • **1 (事前更新): ** 在访问开始前更新 (Pre-update), 比如进门前先扣除门票积分.
  • **2 (事中持续更新): ** 在访问过程中随着使用状态持续更新 (Ongoing-update), 比如按分钟扣费的云服务器.
  • **3 (事后更新): ** 在访问结束后统一结算更新 (Post-update), 比如看完电影后增加账号的观影时长.

PRE 一定不会有 2, C 一定只有 0, 3+4=7, 7+7+2=16 种

UCON 描述 DAC (自主访问控制)#

DAC 的核心是「看脸 (身份) 放行」.

  • **定义主体属性 (Subject Attributes): ** 主体的唯一标识符 (例如: S.ID = "张三").
  • **定义客体属性 (Object Attributes): ** 绑在资源上的访问控制列表 (例如: O.ACL = {"张三":读写, "李四":只读}).
  • **UCON 授权规则 (A) 判定逻辑: ** 系统在事前 (pre) 触发规则: 检查主体的 S.ID 是否存在于客体的 O.ACL 字典中. 如果存在, 并且对应的值包含当前请求的操作 (如「读」), 则返回 True, 允许访问.

UCON 描述 MAC (强制访问控制)#

MAC 的核心是「阶级森严的大小比较」.

  • **定义主体属性 (Subject Attributes): ** 主体的安全许可级别 (例如: S.Clearance = 3, 代表机密级).
  • **定义客体属性 (Object Attributes): ** 资源的安全敏感度标签 (例如: O.Classification = 2, 代表秘密级).
  • **UCON 授权规则 (A) 判定逻辑: ** 以经典的 Bell-LaPadula 模型 (向下读, 向上写) 为例, 系统在事前 (pre) 触发两条数学公式:
    • 如果是读请求: 判断 S.Clearance >= O.Classification 是否成立.
    • 如果是写请求: 判断 S.Clearance <= O.Classification 是否成立. 成立则放行, 否则拒绝.

UCON 描述 RBAC (基于角色的访问控制)#

RBAC 的核心是「拿角色当中间商」. 在 UCON 的视角里, 角色不再是单独的实体, 而是变成了主体的一种状态属性.

  • **定义主体属性 (Subject Attributes): ** 用户在当前会话中已经激活的角色集合 (例如: S.ActiveRoles = {"财务", "内审"}).
  • **定义客体属性/权限要求 (Object Attributes): ** 执行该操作所必需的角色集合 (例如: O.RequiredRoles = {"财务", "出纳"}).
  • **UCON 授权规则 (A) 判定逻辑: ** 系统在事前 (pre) 触发集合交叉运算: 计算 S.ActiveRoles 和 O.RequiredRoles 的交集. 如果交集不为空 (即至少匹配上了一个角色), 则返回 True, 允许访问.

怎么后面还有这么多.