Hello 我是方才,15人研发leader、4年团队管理&架构经验。 文末,方才送你一份25年最新的系分架构师备考资料(附备考交流群),记得领取哟!
信息安全是软考系分和架构必须掌握的内容,同时也是每个架构师必须掌握、且能熟练应用于项目中的重要技术。
本文是方才和极特共创,极简理论+企业级架构图,带你系统掌握信息安全体系。
极特架构笔记
极特,前独角兽技术合伙人,深耕垂直技术领域15年。 先后任职于500强外企、大厂及创业公司,有幸主导过几个亿级用户项目, 具备多次从0到1搭建技术团队经验。擅长技术架构优化、团队管理与AI产品创新, 持续探索技术赋能的新边界。
44篇原创内容
公众号
先跟着方才一起来看看整体的架构图,有个整体概念:
信息安全防护体系是一个多层防护的立体架构:
防护层级 | 作用说明 | 核心技术 | 生活中的例子 |
---|---|---|---|
网络安全防护 | 阻挡外部攻击,过滤恶意流量 | 防火墙、IDS/IPS、WAF | 小区的门禁系统和保安 |
访问控制 | 确保只有授权人员能接触系统 | 身份认证、权限管理、零信任 | 银行金库的多重身份验证 |
数据安全 | 保护数据存储和传输安全 | 数据加密、脱敏、备份 | 用密码本写的机密文件 |
安全管理 | 制定策略和应急响应机制 | 安全策略、风险评估、应急响应 | 银行的安全制度和流程 |
这四个层级相互配合,形成了一个立体防护网络。
数据安全是整个防护体系的核心。简单理解:数据安全就是通过各种技术手段,让你的信息即使被别人拿到,也看不懂内容。
加密是一种数据保护技术,通过特定算法将原始信息转换成无法直接理解的代码。只有掌握正确"密钥"的人才能将其还原成原始信息。
常见的算法类型、特征和场景等,需要掌握:
算法类型 | 特征 | 常见算法名称 | 适用场景 |
---|---|---|---|
散列函数算法 | 将任意长度数据映射为固定长度散列值,单向不可逆,存在极小碰撞可能(不同输入得到相同散列值) | MD5(已发现较多安全漏洞,逐渐被弃用)、SHA - 1(存在安全风险,使用受限)、SHA - 2(包含SHA - 224、SHA - 256、SHA - 384、SHA - 512等变体,应用广泛)、SHA - 3、SM3(我国自主设计的密码杂凑算法) | 密码存储(存储散列值防止明文泄露)、数据完整性校验(如接口交互时验证数据是否被篡改)、数据索引 |
对称加密算法 | 加密和解密使用同一密钥,密钥管理要求高,算法简单,加解密速度快 | DES(密钥长度较短,安全性有限)、3DES(对DES的改进,增强了安全性)、AES(高级加密标准,应用广泛,支持多种密钥长度)、RC4(常用于SSL/TLS协议早期版本)、SM4(我国自主设计的分组密码算法) | 大量数据加密场景,如文件加密、数据库加密、HTTPS通信中数据加密 |
非对称加密算法 | 使用公钥和私钥,公钥加密私钥解密,私钥签名公钥验签;算法复杂,加密解密速度慢,但安全性高,可用于身份验证 | RSA(应用广泛,基于大整数分解难题)、ECC(椭圆曲线加密算法,同等安全强度下密钥长度更短,计算效率更高)、DSA(数字签名算法)、SM2(我国自主设计的椭圆曲线公钥密码算法) | 数字签名(确认数据来源和完整性)、身份认证(如SSL/TLS协议保障网络通信安全)、密钥交换(在不安全网络中安全交换对称加密密钥) |
常用的国密算法-了解即可:
算法名称 | 算法类别 | 应用领域 | 特点 |
---|---|---|---|
SM1 | 对称(分组)加密算法 | 芯片 | 分组长度、密钥长度均为 128 比特,对标 AES-128 |
SM2 | 非对称(基于椭圆曲线 ECC)加密算法 | 数据加密,数字签名 | ECC 椭圆曲线密码机制 256 位,相比 RSA 处理速度快,消耗更少 |
SM3 | 散列(hash)函数算法 | 完整性校验 | 安全性及效率与 SHA-256 相当,压缩函数更复杂,用于替代MD5/SHA-1/SHA-2等国际算法 |
SM4 | 对称(分组)加密算法 | 数据加密和局域网产品 | 分组长度、密钥长度均为 128 比特,计算轮数多,对标 AES-128(计算轮数和结构不同)) |
SM7 | 对称(分组)加密算法 | 非接触式 IC 卡 | 分组长度、密钥长度均为 128 比特 |
SM9 | 标识加密算法(IBE) | 端对端离线安全通讯 | 加密强度等同于 3072 位密钥的 RSA 加密算法 |
ZUC | 对称(序列)加密算法 | 移动通信 4G 网络 | 流密码 |
除了加密之外,还有多种数据保护技术来确保数据的安全性、完整性和可用性。
数据脱敏,一种数据保护技术,通过替换、遮盖等方式处理敏感信息,在保持数据可用性的同时降低隐私泄露风险。
5种数据脱敏技术总结表(这个在23年的系分案例真题考过):
技术类型 | 核心原理 | 典型应用场景 | 优点 | 缺点 |
---|---|---|---|---|
静态脱敏 | 离线对原始数据批量替换/变形(如将身份证号110xxxx替换为****),生成脱敏副本。 | 数据开发、测试环境;数据共享(如外发报表)。 | 不影响生产数据,可长期留存脱敏数据。 | 需额外存储脱敏数据,更新滞后(依赖定时同步)。 |
动态脱敏 | 实时拦截数据访问请求,对敏感字段按需变形(如用户查询时,手机号138xxxx变138****)。 | 生产环境(如数据库直接访问);实时API接口,web应用比较常用的。 | 无需预存脱敏数据,灵活控制权限。 | 依赖实时计算,高并发下可能影响系统性能。 |
可逆脱敏 | 用加密算法(如AES)或映射表隐藏数据,需密钥/映射关系还原(如138xxxx→加密值,密钥可解密)。 | 数据外发需可逆场景(如金融临时数据共享)。 | 支持数据还原,满足合规追溯需求。 | 密钥/映射表需严格保密,否则脱敏失效。 |
伪脱敏(格式保留) | 保留数据格式但替换内容(如姓名张三→张四,手机号138开头不变,后四位随机)。 | 测试环境(需模拟真实格式);演示数据。 | 保持数据结构一致性,适配程序兼容性。 | 极端场景下可能被逆向推导(如仅改后四位的手机号)。 |
匿名化脱敏 | 彻底移除/替换身份关联信息(如删除订单表中用户姓名、身份证号,仅保留订单ID)。 | 大数据分析(如医疗数据、用户行为分析)。 | 完全切断敏感关联,符合高合规要求(如GDPR)。 | 数据无法还原,不适用于需关联原始身份的场景。 |
常见脱敏规则表,作为了解:
数据类型 | 原始数据 | 脱敏后 | 脱敏规则 | 保留特征 |
---|---|---|---|---|
手机号 | 13912345678 | 139****5678 | 中间4位替换为* | 运营商+尾号 |
身份证 | 110101199001011234 | 110101********1234 | 中间8位替换为* | 地区+年份+尾号 |
银行卡 | 6217001234567890 | 6217****7890 | 中间8-12位替换 | 银行标识+尾号 |
邮箱 | zhangsan@qq.com | zhan***@qq.com | 用户名部分替换 | 邮箱服务商 |
姓名 | 张三丰 | 张** | 保留姓氏 | 姓氏统计可用 |
地址 | 北京市朝阳区xxx小区 | 北京市朝阳区*** | 保留到区级 | 地理分布分析 |
数据备份,将重要数据复制到多个存储位置的安全策略,用于防止数据丢失和确保业务连续性。
备份策略全览:
备份类型 | 备份内容 | 恢复速度 | 存储需求 | 适用场景 |
---|---|---|---|---|
全量备份 | 所有数据 | 最快 | 最大 | 周末、月末备份 |
增量备份 | 自上次备份后的变化 | 最慢(需多步恢复) | 最小 | 每日备份 |
差异备份 | 自上次全量备份的变化 | 中等 | 中等 | 每周备份 |
备份频率设计表:
数据重要程度 | 全量备份 | 增量备份 | 校验频率 | 保留期限 |
---|---|---|---|---|
极重要 (银行交易) | 每日 | 每小时 | 每日自动校验 | 永久保存 |
重要 (客户资料) | 每周 | 每4小时 | 每周校验 | 7年 |
一般 (日志文件) | 每月 | 每日 | 每月校验 | 1年 |
业界公认的最佳备份策略,"3-2-1"黄金备份法则:
3份数据:保存1份原始数据 + 2份备份,多重保险降低丢失风险
2种介质:使用硬盘 + 云存储等不同存储介质,防止单一介质故障
1份异地:至少1份备份存放在异地机房,防止自然灾害影响
数据分类是根据数据的敏感程度和业务价值进行分级管理的过程。通过分类可以实施针对性的保护措施。
数据敏感级别分类:
敏感级别 | 定义 | 举例 | 泄露后果 | 保护措施 |
---|---|---|---|---|
公开数据 | 可对外公开的信息 | 公司简介、产品介绍 | 无重大影响 | 基础防护即可 |
内部数据 | 仅限内部使用 | 内部通知、会议纪要 | 影响内部管理 | 访问权限控制 |
敏感数据 | 需要特殊保护 | 客户信息、财务报表 | 经济损失、法律风险 | 加密+访问审计 |
机密数据 | 高度机密信息 | 核心算法、商业秘密 | 严重商业损失 | 最高级别防护 |
数据生命周期管理:
生命阶段 | 主要任务 | 安全要求 | 实际操作 |
---|---|---|---|
创建阶段 | 数据产生 | 自动标记分类级别 | 系统自动识别并打标签 |
使用阶段 | 日常访问处理 | 根据级别控制权限 | 不同角色看到不同内容 |
传输阶段 | 数据传递 | 高敏感数据强制加密 | 网络传输时自动加密 |
存储阶段 | 长期保存 | 分级存储和加密 | 重要数据存放在更安全的地方 |
销毁阶段 | 安全删除 | 确保无法恢复 | 物理销毁+多次覆盖 |
网络安全负责保护数据在传输过程中的安全,确保信息在网络中传递时不被窃取、篡改或伪造。
在保证计算机网络系统的安全方面,教材提到了4个协议,需要了解下:
协议名称 | 基本信息 | 主要功能与特点 |
---|---|---|
SSL | 传输层安全协议,含握手、记录、警报协议 | 用于在Internet上传送机密文件,提供身份认证、加密与完整性保护,用40位RC4算法,分6阶段,可用于安全邮件 |
HTTPS | HTTP安全版,应用SSL于应用层,用特定端口 | 建安全通道,确网站真实,防窃听、中间人攻击,支持X.509认证 |
PGP | 基于RSA的邮件加密软件 | 邮件及文件加密、签名,防非授权访问,认发件人,独特流程,兼容两种证书 |
IPSec | 工业标准协议,针对IPv4/6 | 为IP网络提供透明安全服务,保护数据、御攻击,端对端模式,支持IP级流量加密认证 |
网络传输是数据泄露的高风险环节,传输层安全技术确保数据在网络中传输时不被窃取或篡改。
HTTPS是我们日常上网最常接触的安全协议。当你看到浏览器地址栏显示小锁图标时,就说明网站启用了HTTPS加密。HTTPS的工作过程可以分为5个主要步骤:
TLS版本对比:
TLS版本 | 发布时间 | 安全状态 | 性能 | 使用建议 | 主要特点 |
---|---|---|---|---|---|
TLS 1.0 | 1999年 | 已淘汰 | 较慢 | 禁止使用 | 存在严重安全漏洞 |
TLS 1.1 | 2006年 | 已淘汰 | 较慢 | 禁止使用 | 主流浏览器已停止支持 |
TLS 1.2 | 2008年 | 安全 | 良好 | 推荐使用 | 目前主流版本,兼容性好 |
TLS 1.3 | 2018年 | 最安全 | 最快 | 强烈推荐 | 最新版本,连接更快更安全 |
数字证书相当于网站的"身份证",由权威机构(CA)颁发,用来证明网站身份的真实性。证书主要分为三种类型:
证书类型 | 验证内容 | 价格水平 | 适用场景 | 安全等级 |
---|---|---|---|---|
DV证书(域名验证) | 只验证域名所有权 | 便宜,甚至免费 | 个人网站、博客 | 基础 |
OV证书(组织验证) | 验证域名和企业信息 | 价格适中 | 企业官网 | 中等 |
EV证书(扩展验证) | 严格的企业身份验证 | 价格较高 | 银行、电商等高安全场景 | 最高 |
应用层是用户直接接触的界面,也是攻击者的主要目标。应用层防护通过多种技术手段保护Web应用和API接口的安全。
WAF,部署在网站前端的安全设备,专门防护Web应用攻击。可以理解为网站的"保安",检查每个访问请求是否安全。主要防护的攻击类型:
攻击类型 | 攻击原理 | 危害程度 | WAF防护方式 | 防护效果 |
---|---|---|---|---|
SQL注入 | 插入恶意SQL代码获取数据库信息 | ⭐⭐⭐⭐⭐ | 语法分析+规则匹配 | 优秀 |
XSS跨站脚本 | 注入恶意脚本窃取用户信息 | ⭐⭐⭐⭐ | 检测脚本标签 | 良好 |
CSRF跨站请求伪造 | 伪造用户请求执行恶意操作 | ⭐⭐⭐ | Token验证 | 良好 |
文件上传漏洞 | 上传恶意文件获得服务器控制权 | ⭐⭐⭐⭐⭐ | 文件类型检查+病毒扫描 | 优秀 |
DDoS攻击通过大量虚假请求让网站瘫痪,防护需要多层策略配合。DDoS防护方法对比:
防护类型 | 防护原理 | 响应速度 | 精准度 | 成本 | 适用场景 |
---|---|---|---|---|---|
网络层防护 | IP黑名单、流量限制 | 最快 | 较低 | 最低 | 基础防护 |
应用层防护 | 行为分析、验证码 | 较慢 | 最高 | 中等 | 精准识别 |
CDN加速防护 | 分散流量、就近响应 | 快 | 中等 | 较高 | 全球业务 |
云端专业防护 | 专业DDoS清洗服务 | 快 | 高 | 中等 | 大规模攻击 |
现代应用大量使用API接口,需要专门的安全管控措施。API安全的五个关键要素:
其中身份认证、访问控制和加密传输是必须要做的,流量限制和数据验证也很重要。
访问控制,确保"正确的人在正确的时间访问正确资源"的核心机制。
要素 | 定义 | 涵盖范围 |
---|---|---|
主体 | 对其他实体施加动作的主动实体,比如系统使用者 | 用户/组织、终端、应用程序/进程 |
客体 | 接受访问的被动实体,比如系统功能菜单 | 信息、资源、对象(含硬件) |
控制策略 | 主体操作客体的约束规则集,比如张三只能访问首页 | 定义主客体交互与权限,体现授权 |
身份认证是确认用户身份真实性的过程,是访问控制的第一道防线。只有通过认证的用户才能获得系统访问权限。
密码仍然是最常用的认证方式,但需要建立强密码策略,密码安全措施对比:
安全措施 | 具体要求 | 安全效果 | 用户体验 | 实施成本 | 推荐等级 |
---|---|---|---|---|---|
复杂度要求 | 8位以上+大小写+数字+特殊字符 | ⭐⭐⭐⭐ | 一般 | 低 | 必须 |
定期更换 | 3-6个月更换一次 | ⭐⭐⭐ | 较差 | 低 | 推荐 |
存储加密 | 不存储明文,使用散列+盐值 | ⭐⭐⭐⭐⭐ | 无影响 | 低 | 必须 |
防暴力破解 | 连续错误锁定+验证码 | ⭐⭐⭐⭐ | 一般 | 低 | 必须 |
异常监控 | 监控异常登录行为 | ⭐⭐⭐⭐ | 无影响 | 中等 | 推荐 |
多因子认证通过组合多种验证方式来提升安全性:
因子类型 | 验证方式 | 安全等级 | 用户体验 | 成本 | 适用场景 |
---|---|---|---|---|---|
知识因子(你知道什么) | 密码、PIN码、安全问题 | ⭐⭐⭐ | 方便 | 最低 | 基础认证 |
持有因子(你有什么) | 手机、硬件令牌、智能卡 | ⭐⭐⭐⭐ | 一般 | 中等 | 企业级应用 |
生物因子(你是什么) | 指纹、虹膜、面部识别 | ⭐⭐⭐⭐⭐ | 最便捷 | 较高 | 高安全要求 |
组合验证 | 多种因子组合 | ⭐⭐⭐⭐⭐ | 稍复杂 | 最高 | 关键系统 |
多因子认证的安全性远高于单一密码,即使密码泄露,攻击者仍需要其他验证因子才能登录。
单点登录(Single Sign-On,SSO)让用户一次登录就能访问多个应用系统,既提升了用户体验,也便于统一管理。SSO协议主要类型:
协议名称 | 技术特点 | 适用场景 | 优势 | 缺点 |
---|---|---|---|---|
SAML | 基于XML的标准 | 企业级应用、传统系统 | 标准成熟安全性高 | 配置复杂学习成本高 |
OAuth 2.0 | 授权框架 | 第三方登录、API授权 | 简单易用广泛支持 | 只做授权不做认证 |
OpenID Connect | 基于OAuth 2.0 | 现代Web应用 | 功能完整标准化好 | 相对较新 |
JWT Token | 无状态认证 | 微服务、移动应用 | 无需存储跨域友好 | 无法主动失效 |
访问控制一般都是基于安全策略和安全模型的。典型安全模型如下(作为了解):
模型名称 | 核心原理 | 安全规则 |
---|---|---|
状态机模型 | 从安全状态启动,迁移中保持安全,主体按安全策略访问资源 | 只允许主体以和安全策略相一致的安全方式访问资源 |
Bell - LaPadula模型(BLP模型) | 依据机密性划分安全级,按安全级别控制访问 | 简单规则:低级别主体读取高级别客体受限星形规则:高级别主体写入低级别客体受限自主规则:自定义访问控制矩阵 |
Biba模型 | 防止数据从低完整性级别流向高完整性级别 | 星完整性规则:低完整性主体不能向高完整性客体写数据简单完整性规则:高完整性主体不能从低完整性客体读取数据调用属性规则:低完整性主体不能从高级别客体调用程序或服务 |
Clark - Wilson模型(CWM模型) | 将完整性目标、策略和机制融合,提出职责分离目标,应用完整性验证过程 | 主体只能通过程序访问客体权限分离原则,防止未授权修改具有审计能力 |
Chinese Wall模型 | 混合策略模型,通过自主和强制访问控制防止多安全域冲突 | 墙内客体可读取不同利益冲突组客体可读取访问其他公司客体和其他利益冲突组客体后,主体对客体写入受限 |
访问控制决定了经过认证的用户能够访问哪些资源、执行哪些操作。
访问控制类型 | 基本思想 | 实现示例 | 特点 | 适用场景 |
---|---|---|---|---|
自主访问控制(DAC) | 主体按身份/所属组,自主指定资源访问规则 | 在 Linux 系统中,用户通过 chmod 命令,如 chmod 750 file.txt,自主设置文件所有者、所属组、其他用户对文件的读、写、执行权限 | 用户/组分配权限,主体可自主授权;但需求变化时,重新授权操作繁琐 | 多用户共享资源的通用环境,如普通办公网文件共享 |
强制访问控制(MAC) | 主体和客体有既定安全属性,访问受 BLP 模型( Bell - LaPadula 模型 )等特性约束 | 在 SELinux(安全增强型 Linux )中,系统预先为进程、文件等定义安全级别(如机密、秘密 ),进程访问文件时,依据两者安全级别及 BLP 规则(不上读、不下写 )判定是否允许。高等级可访问低等级的。 | 基于安全属性和严格模型分配权限,安全性高;但管理员配置、维护工作量大,易因复杂设置出漏洞 | 军事、政务等高安全性要求系统,如涉密信息系统 |
基于角色的访问控制(RBAC) | 用户关联角色,角色关联访问许可权 | 企业 OA 系统中,定义“经理”“普通员工”角色,“经理”角色关联“审批请假”“查看部门报表”权限,“普通员工”角色关联“提交请假”“查看个人信息”权限,用户按岗位被分配对应角色 | 有多种模型,灵活适配组织架构;通过角色批量管理权限,方便调整 | 大型系统权限管理,如企业 ERP、大型 DBMS(数据库管理系统 )权限配置 |
基于任务的访问控制(TBAC) | 权限随任务上下文动态变化,是动态安全模型 | 电商订单处理系统中,“订单审核”任务执行时,仅审核人员在任务执行时段内,能访问待审核订单数据;任务完成(订单审核通过 ),该权限收回,后续仅可由“订单发货”任务相关人员访问 | 依托工作流等驱动,支持最小特权、最小泄露原则;动态管理权限,贴合业务流程 | 工作流驱动、分布式处理的系统,如电商订单处理、项目流程管理系统 |
基于对象的访问控制(OBAC) | 通过 ACL(访问控制列表 )关联受控对象及属性,支持策略复用、继承、派生 | 云存储系统中,为“企业文档”对象设置 ACL,规定部门经理可“读写”,普通员工“只读”;当创建“部门文档”派生对象时,继承“企业文档”部分访问控制设置 | 可精准控制对象及属性,派生对象继承权限设置,减轻权限管理工作量 | 信息量大、对象多且变化频繁的管理系统,如大型云存储平台、复杂文档管理系统 |
会话管理负责维护用户登录状态,确保用户在访问系统期间的身份一致性和安全性。
服务端会话管理是传统的做法:
会话生命周期 | 会话存储方式 | 会话安全措施 |
---|---|---|
1. 用户登录成功后,服务器生成唯一的Session ID2. Session ID通过Cookie发送给浏览器3. 用户后续请求都携带这个Session ID4. 服务器根据Session ID查找用户信息5. 会话超时或用户登出时销毁Session | - 内存存储:速度快但服务器重启会丢失- 数据库存储:持久化但性能稍差- Redis存储:兼顾性能和持久化,是主流选择 | - 设置合理的超时时间- 登录成功后重新生成Session ID- 使用HTTPS传输防止Session劫持- 异常情况下强制下线 |
JWT(JSON Web Token)是一种开放标准(RFC 7519),可实现无状态认证,服务器不需要存储会话信息:
JWT结构 | JWT优势 | JWT注意事项 |
---|---|---|
- Header:用于指定签名算法(如HS256、RS256)和Token类型(通常为JWT)- Payload:包含用户信息(如用户ID、用户名)和权限声明(如角色、权限范围)等数据- Signature:通过Header中指定的算法对Header和Payload进行签名,用于防止Token内容被篡改- 它们之间用点(.)分隔,格式为 xxx.yyy.zzz | - 无状态性:无需在服务端存储Token信息,便于分布式系统部署,减轻服务端存储压力- 跨域友好:可通过HTTP请求头(如Authorization)或URL参数传递,适合微服务架构下的跨服务认证- 信息自包含:Payload中携带完整用户信息,每次请求无需频繁查询数据库,提升接口响应效率 | - 不可主动失效:Token一旦签发,在过期前无法通过服务端主动撤销,需依赖客户端主动销毁(如登出时清除Token)或设置较短的过期时间- 安全风险:Token泄露可能导致身份伪造,需配合HTTPS传输、Token加密存储等措施;同时需防范XSS(跨站脚本攻击)和CSRF(跨站请求伪造)等攻击手段- 负载限制:Base64编码后的Token包含Header和Payload,数据量较大,不适合在频繁请求(如每秒多次调用)的场景中使用,可能增加网络传输开销 |
以下内容仅作为了解。
技术手段是基础,完善的安全管理体系才是长久之道。