数据安全政策文件体系

这是一篇关于数据安全政策文件体系的思维导图，主要内容包括：数据安全技术规范，数据安全标准，数据安全政策总纲，数据安全文件体系。

数据安全政策文件体系

• 数据安全文件体系
  • 数据安全文件体系，即一系列管理、标准与规范、流程、指南、模板等文件的文档化记录。
  • 在企业规模尚小的时候，也许根本用不上建立政策文件，或者说虽然已经具有了一些政策文件但不是很完善。当企业开始规范化运作的时候，特别是需要通过外部的认证、测评的时候，文档化的文件体系就是必不可少的了，如等级保护三级认证。当需要通过相当于成熟度三级的有关认证时，相对完善的政策文件体系更是必不可少。
  • 四层文件体系架构简介
    • 通常我们在设计文件体系的时候，可按照四层文件体系来进行设计，如图所示。这四层文件体系为：
    • ■ 第一层：政策总纲/实践框架，属于该领域内的顶层文件，包括该领域工作的目标、范围、基本原则（或政策方针）、组织与职责等，授权各级组织按照设定的角色和职责，动用组织资源来为目标服务。顶层文件不引用下层文件。
    • ■ 第二层：管理规定和技术标准/规范。
    • ■ 第三层：操作指南/指引/流程。
    • ■ 第四层：交付件模板、Checklist（即若干检查项的清单或列表，可用来逐项检查是否符合，并打勾√）。
    • 其中，政策总纲/实践框架属于治理的范围，属于治理的三个元素之一（另外两个是战略和组织）。第二层到第四层属于合规管理的范围，其主要职责是：
      • ■ 构建一套符合法律法规、监管要求、合同义务、行业最佳实践以及业务发展需要的政策文件体系。
      • ■ 作为风险管理的输入和依据（风险管理即风险评估/识别、风险改进、风险度量、风险总结与残余风险的管理等）。
      • ■ 与时俱进，基于外部环境如法律法规的变化、外部审计、认证/测评、业务变化、各种反馈，优化调整政策文件体系。也就是说，这个“规”也不见得就完全是合理的，也需要持续改进。
  • 数据安全四层文件体系
    • 按照上述四层文件体系，适用到数据安全领域，则数据安全四层文件体系设计如图所示。
  • 外部法规转为内部文件
    • 外部的法律法规、监管要求、行业标准、实践参考多种多样，是无法直接在企业内部作为合规基线的。为了对内部安全进行规范化治理，我们就需要把各种各样的外部要求转化为内部文件，作为开展工作的依据。
    • 在制定数据安全相关文件的时候，往往很少有需要直接引用法律条款的情况，采用的方法大多是拿着外部法规、业界最佳实践、外部标准等，对着我们现有的文件查漏补缺，看看还差什么，“差什么就补什么”，来完善内部文件体系，如图所示。
• 数据安全政策总纲
  • 数据安全政策总纲，即数据安全领域的顶层文件，可以将其看成是一个在管理层达成共识的授权令，授权各级组织按照设定的角色和职责，动用组织资源来为数据安全目标服务。
  • 政策总纲通常需要包括：
    • ■ 数据安全的目标。
    • ■ 数据安全的范围。
    • ■ 强调对数据分级与分类管理（具体分级分类在管理政策部分）。
    • ■ 数据安全组织与职责。
    • ■ 授权原则。
    • ■ 数据保护原则。
    • ■ 数据安全外部合规要求。
    • ■ 对人为原因导致的数据安全事件的问责要求。
  • 数据安全的目标和范围
    • 数据安全要保护的范围：
      • ■ 各种结构化数据，包括存放于数据库、缓存系统中的数据。
      • ■ 非结构化数据，是指数据结构不规则，没有预定义的数据模型，不便用二维表来表现的数据；主要包括各类文件如办公文档、文本、图片、音频、视频等。
      • ■ 资源：网络资源、计算资源、存储资源、进程、产品功能、网络服务、系统文件等。
  • 数据安全组织与职责
    • 从制定数据安全政策，到最终实施，需要组织推动、各方协调和配合，才能逐步落地。数据安全组织，就是数据安全政策从制定到落地，并持续优化改进的组织保障；简单地说，就是我们要推行数据安全政策，需要哪些组织单元（在企业里面通常为部门、工作组等）协同工作，各自的分工是什么样的，各自承担什么样的职责
  • 授权原则
    • 这里的授权，是指对角色或人员的授权。通常来说，授权的原则有如下几点可供参考：
      • ■ 仅授予相关角色或人员以完成业务工作所需的最小权限。
      • ■ 在涉及敏感数据的权限时，需考虑权限分离（SOD, Separation of Duty）；在一人承担多个重要角色时，往往可能导致授权漏洞的发生，最典型的场景是，会计和出纳如果由一人担任，会出现贪腐现象；开发人员和运维人员分离，可在一定程度上防止随意变更、数据无意中泄露的情况；操作系统管理员、数据库管理员、业务后台管理员由不同的员工担任，可防止其中某一个人窃取数据的风险。
      • ■ 授权与行权分离，负责审批权限的人不能执行，即不能审批自己提交的权限或业务单据。
  • 数据保护原则
    • ■ 明确责任人：应确定每个业务领域的数据安全责任人。
    • ■ 基于身份的信任原则：默认不信任企业内部和外部的任何人/设备/系统，需基于身份认证和授权，执行以身份为中心的访问控制和资产保护。
    • ■ 数据流转原则：数据流转，包括但不限于数据共享给其他业务、数据流出当前安全域等，应经过责任人审批。
    • ■ 加密传输原则：外网Web业务应采取全站HTTPS加密，内网对重要的敏感数据加密传输。
    • ■ 加密存储原则：对敏感的个人信息、个人隐私、UGC数据、身份鉴别数据，采取加密存储措施。
    • ■ 脱敏展示原则：当展示个人信息时，应采取脱敏措施。
    • ■ 业务连续性：建立备份和恢复机制。
  • 数据安全外部合规要求
    • ■ 法律法规：包括但不限于《网络安全法》《个人信息安全规范》、规划中的《数据安全法》，以及开展国际业务所涉及的数据保护法规，如GDPR等；其中《个人信息安全规范》虽然暂未强制执行，但其内容预计会在接下来的立法规划中转化为法律，如个人信息保护法。
    • ■ 认证/测评要求：如等级保护测评，适用于CII（关键信息资产）。
    • ■ 审计要求：如适用于美国上市公司的SOX审计。
    • ■ 监管要求：来自特定行业（金融、支付、证券、保险等）的监管要求。
    • 具体需要对标哪些合规要求，需根据业务实际需求来判断。
  • 数据安全管理政策
    • 数据安全管理政策文件包括数据分级和分类、风险评估指南、风险管理要求、事件管理要求、人员管理要求、业务连续性管理等。
  • 数据分级与分类
    • 数据分级通常是按照数据的价值、敏感程度、泄露之后的影响等因素进行分级；通常分级一旦设定，基本不再变化。
    • 数据分类通常是按照数据的用途、内容、业务领域等因素进行分类；数据分类可随着业务变化而动态变化。每一个数据分级可对应多个数据分类。
    • 数据该怎么分级，业界并没有统一的标准，企业可根据实际需要进行分级。一般可以分为二到五级，例如：
      • ■ 甲公司可能使用“公开”“内部使用”“秘密”“机密”“绝密”五级。
      • ■ 乙公司使用“公开”“内部使用”“敏感”三级。
      • ■ 丙公司使用“普通”“敏感”二级。
  • 风险评估与定级指南
    • 风险评估与定级有很多种方法，ISO 27001、ISO 13335、信息安全评估指南等均包含风险评估的内容。
    • 这些评估方法基于资产价值、漏洞、威胁等因素，可以概括为：
      • ■ 弱点（漏洞等）等级越高，发生风险的概率越高，从而风险越高。
      • ■ 威胁（黑客、内部人员等）等级越高，发生风险的概率越高，风险越高。
      • ■ 防护措施（安全加固、防御措施等）越弱，发生风险的概率越高，风险越高。
      • ■ 资产价值越高，发生风险后造成的影响越大，从而风险越高。
  • 风险管理要求
    • 1．风险Owner
      • 风险Owner（风险所有者）这一角色的确定，对风险管理非常重要，因为无人认领的风险就意味着风险可能会持续存在。
      • 风险Owner是有责任、有义务管理业务安全风险的业务管理者。由管理者担任，由上级委派给下级解决，也符合安全工作自上而下推动的原则。
    • 2．风险指标
      • 风险指标是按不同的组织单元进行分解后的量化指标，包括：
        • ■ 各种风险等级、各种风险类型的风险数量。
        • ■ 风险收敛的比例和速度。
      • 这些量化指标可用于直观展示各业务的风险现状，提升业务重视程度，更有利于在不同的业务团队间形成比较或竞争心理。这些量化指标，还可以用于考核各业务安全团队的绩效。例如表16-4中几个不同的团队在选取的若干指标上形成对比。
    • 3．风险处置与闭环
      • 如果发现风险未能得到及时处理，则风险可能酿成安全事件。
      • 发现风险，首先应考虑降低风险的措施，如修复漏洞、启用安全防御策略等，并对风险收敛的时限加以管控，针对不同等级的风险，采取不同的管理要求，比如高风险需要在24小时内解决，而中风险可以放宽时限，低风险可以在基层决策是否接受。
  • 事件管理要求
    • 在处置安全事件时，一个基本的原则是“以快速恢复业务，降低影响为主要目的”，而不是立即找到事件发生的根本原因。
    • 在入侵事件发生后，应启动应急响应，包括：
      • ■ 应急团队：统筹协调，联系业务，事件定级并视严重程度及时同步到相关人员（如业务侧管理层、公关、法务、社交媒体官方账号运营责任人等）。
      • ■ 入侵检测与防御团队：提取关键日志，定位受损业务，实施拦截策略。
      • ■ 业务团队：采取应急措施，中断入侵行为。
    • 事件定级可决定该事件应该上升到哪一层级，确定卷入的人员、团队范围，以决定是否采取更多的措施，例如当数据泄露开始在社交媒体传播造成影响时，可及时在官方社交网络账号上同步处置情况，安抚用户，有效防止谣言的产生。
    • 事件按照其影响，从高到低，可分为多个级别，简单起见，我们以三级为例，如表所示。
  • 人员管理要求
    • 人员包括员工、访客、合作伙伴等，需要遵循、配合相应的安全管理政策、流程。人员有意识或无意识的各种行为，可能给业务带来风险，因此需要加以规范。
    • 这里也借用安全架构的5A方法论，来分析人员与行为管理上应当覆盖的场景。
  • 配置和运维管理
    • 1．配置管理
      • 这里所说的配置管理，不是指该如何设定业务系统的各种配置文件或加固措施，而是在CMDB（配置管理数据库）中登记与维护更新，维护CMDB的及时性和准确性，并将CMDB作为安全监测的数据源。
      • 在小型企业，配置管理可能并不是刚需，总共才那么几台服务器，上面装了什么东西，基本上大家都心中有数；但是对于大中型企业来说，CMDB就必不可少了，试想如果有几十万台服务器，有谁能够记住每台服务器的情况呢。
      • CMDB不仅记录了企业有多少设备，更重要的是，它记录了我们开展安全工作所必需的数据，如：
        • ■ IP地址，可以作为主机层安全扫描的数据源输入，可以作为该地址是否存在敏感数据的标记。
        • ■ 使用的域名，可以在发生安全事件后第一时间根据域名找到相应的业务团队。
        • ■ 操作系统、容器类型及版本，可以在第一时间基于威胁情报，统计出哪些设备需要紧急打上系统安全补丁，防止漏洞被外部利用。
        • ■ 服务端口，没有登记的端口将被视为可疑的行为（可能来自黑客、木马等）。
        • 可以说，CMDB记录的数据不完整或不及时更新，也将在很大程度上影响企业的安全防御能力。
    • 2．运维管理
      • 运维管理，即规范运维操作，如使用自动化运维管理平台或跳板机、只从内部源部署开源组件、执行安全加固等。这一领域，应该将自动化运维能力的提升作为改进的方向，即：
        • ■ 建立自动化运维的基础设施，让日常的例行运维操作都通过自动化运维平台来实现，如批量脚本发布、文件发布、内容发布等。
        • ■ 建立通用的服务基础设施，如统一接入、数据服务，让业务不再单独部署自己的Web服务器或数据库服务器等通用服务。
        • ■ 引导业务尽可能地将日常操作纳入自动化运维平台。
      • 只有在自动化运维能力覆盖不到的场景下，才使用第二选择：通过跳板机进行运维，以及执行运维审计。除了这两种选择之外，不应该再有其他选择，比如用户直接登录到目标服务器而不经过跳板机进行运维是不可接受的。
      • 此外，运维管理还应包括：
        • ■ 运维人员资质要求，如仅限正式员工运维。
        • ■ 流程上的要求，如经过安全扫描或代码审计，无高危漏洞才能发布；域名管理与登记，特别是企业存在多个顶级域名的情况下，需要对域名用途进行限定。
        • ■ 部署区域要求，企业一般存在多个网络安全域，该如何部署（如是否强制要求通过HTTPS网关统一接入），应有规范约定。
        • ■ 对使用开源组件的要求，例如只能从内部源下载。
        • ■ 按照已发布的安全配置规范进行加固，包括补丁以及病毒防护要求。
        • ■ 是否启用WAF、HIDS等安全防御设施。
  • 业务连续性管理
    • 业务连续性管理（BCM, Business Continuity Management）是为了应对各种天灾人祸等异常情况而采取的预防性管理与技术措施。
    • 这些异常情况包括：
      • ■ 自然灾害：地震、台风、海啸、洪水、火灾等。
      • ■ 人为灾害：黑客入侵、网络DDoS攻击、内部破坏或泄露数据等。
      • ■ 其他如供电中断、硬件故障、软件故障等导致的服务中止。
    • 企业应遵循业界最佳实践（目前已有BCM国际标准ISO 22301），采用系统化的方法来测试业务、执行数据备份与恢复演练。
• 数据安全标准
  • 算法与协议标准
    • 1．对称加密算法
      • 关于对称加密算法，需注意以下几点：
        • ■ 除非法律法规或监管层面有单独的规定（例如国内金融行业有使用SM示例加密算法的要求），推荐默认选用AES（Advanced Encryption Standard）加密算法。
        • ■ AES支持的三种密钥长度目前均是安全的，推荐首选256位。
        • ■ 除非清楚地知道各种模式的区别，否则推荐选用GCM模式（Galois/Counter Mode）
        • 即默认情况下，推荐首选AES-GCM-256加密算法。
      • 对称加密的典型使用场景：
        • ■ 数据存储加密。
        • ■ 后台节点间、客户端到服务器之间的认证加密（同时实现身份认证、传输加密）。
        • SSO系统的身份认证通过之后，用户可以在会话有效期内不再执行身份认证，与SSO系统不同，认证加密机制对每一次交互都执行身份认证。
    • 2. 非对称加密算法
      • 在当前阶段，非对称加密算法推荐：
        • ■ 如果选用RSA，首选RSA 2048。
        • ■ 如果选用ECC，首选ECC 224。
      • 典型适用场景：
        • ■ 协商/交换对称加密密钥。
        • ■ 身份认证。
        • ■ 数字签名（即使用私钥加密待传输的内容）。
        • 由于非对称加密算法的效率不高，不适用于对大量内容进行加密，因此真正对大量数据进行加密的部分还是需要对称加密算法来完成，非对称加密算法仅用于安全地传递对称加密密钥。
    • 3．单向散列
      • 单向单列可分为两类：
        • ■ 常规的单向散列，如SHA256、SHA384、SHA512、SHA-3等，首选SHA256。
        • ■ 慢速散列，如bcrypt、scrypt、PBKDF2等，如果选用PBKDF2，推荐配合HMAC-SHA256使用。
      • 用于口令存储时，推荐的做法是：
        • ■ 用户侧不传递原始口令，在用户侧使用任何一种慢速加盐散列处理后再发送给服务器侧。
        • ■ 服务器侧收到用户侧发送过来的慢速加盐散列结果，推荐选用SHA256加盐散列继续处理。
        • ■ 无论使用哪一种散列算法，都需要加盐。
        • MD5、SHA-1是过去常用的常规单向散列算法，但由于已经发现了碰撞实例，不再推荐使用。
    • 4．消息认证
      • 推荐使用HMAC-SHA256。
      • 为了便于理解，我们把HMAC的作用总结为一句话：带着HMAC消息来，我就相信你。相信是你说的，相信内容完整无误（未经篡改）！
      • HMAC的用途包括：
        • ■ 身份认证：确定消息是谁发的（对约定的消息进行运算，比如请求的参数以及当前时间戳）。
        • ■ 完整性保障：确定消息没有被修改（HMAC运算结果不包含消息内容，通常和明文消息一起发送，不能保障消息的保密性）。
    • 5．密码学安全的伪随机数生成器
      • 在生活中，有很多需要随机数的场景，例如生成随机样本、生成密钥、抽奖等。如果涉及利益，往往出现意想不到的情况，如2016年某公司年会抽奖现场CTO审核代码。
      • 在无外部输入的情况下，计算机本身无法产生真正随机的随机数，最多只能产生密码学安全的伪随机数，即CSPRNG（Cryptographically Secure Pseudo-Random Number Generator，密码学安全的伪随机数生成器）。而我们的目的也正是如此，希望得到的随机数是密码学上安全的。
    • 6．传输协议
      • 关于传输协议，有以下几点注意事项：
        • ■ 推荐首选TLS 1.2及以上版本，新业务推荐直接使用TLS 1.3或以上版本。
        • ■ 完全不要使用SSL 1.0、SSL 2.0、SSL 3.0等版本。
        • ■ TLS 1.0也不安全（已被发现漏洞），不推荐使用；使用TLS 1.0的网站也不符合PCI-DSS（支付卡行业数据安全标准）要求，支付类网站需要禁用。
        • ■ TLS 1.1虽未发现明显漏洞，但各方面已被TLS 1.2超越，不推荐使用，PCI-DSS也强烈建议弃用TLS1.1。
  • 口令标准
    • 1．服务侧静态口令标准
      • 能够与SSO集成的场景，均应使用SSO身份认证，并配合动态口令或双因子认证，验证员工的身份。
      • 不得不使用静态口令的场景（如数据库口令、没有与SSO集成的主机口令），应满足静态口令标准，以下几点可供参考：
        • ■ 不得使用默认初始口令。
        • ■ 不得使用通用口令（即一个口令在多处使用）。
        • ■ 口令长度不小于14位。
        • ■ 口令应包含大写字母、小写字母、数字、符号。
    • 2．员工口令标准
      • 参考标准：首选使用SSO。
      • 如果业务无法与SSO集成，则：
        • ■ 口令长度不小于10位。
        • ■ 口令应包含大写字母、小写字母、数字、符号中的三种。
    • 3．用户口令标准
      • 参考标准如下：
        • ■ 口令长度不小于8位。
        • ■ 口令应包含大写字母、小写字母、数字、符号中的三种。
        • ■ 建议不上传用户的原始口令，先在用户侧执行慢速加盐散列处理后再上传（基于安全上的“默认员工也不能信任”的思维，这种先在客户端执行预处理的做法可以防止员工在服务器侧收集用户口令）。
      • 用户口令可通过检测并展示口令强度、提示的方式，告知用户风险，因为涉及用户体验的问题，是否采用强制策略需要权衡。
  • 产品与组件标准
    • 提到产品与组件标准，为什么产品、组件也需要标准呢？
    • 让我们先来看几个场景：
      • ■ A业务使用Windows Server 2012、IIS 8、SQL Server 2012
      • ■ B业务使用CentOS 7、Nginx 1.8、MariaDB 10.3
      • ■ C业务使用Debian 9、Apache 2.4、PostgreSQL 9.3
      • ■ D业务使用Ubuntu 16、NodeJS 10.15、Oracle 11
    • 这几个场景选取了操作系统、Web服务器、数据库这几个常用系统或组件的组合，假设我们不加任何约束，其中每一类组件可选的产品大约10个左右，那么生产环境中存在的组合大概就可能有1000种（10×10×10）之多，这还不包括其他的组件。至于为什么要考虑组合的种类，主要是因为不同的组合会影响安装、配置的方式，体现在技术支持上，那么技术文档以及支持能力就需要考虑各种场景。
    • 推荐给业务选用，尽量不要使用清单之外的其他组件，这样做的好处有：
      • ■ 可以提供更好的技术支持。
      • ■ 可以更好地跟企业内部的安全产品适配，获得安全防御或告警的能力。
      • 如果业务不遵循这个约定，用了约定之外的组件，会怎样呢？
      • ■ 首先，因为使用量少，企业内部的专业技术支持力量不会专门为其提供技术支持。
      • ■ 安全检测能力可能覆盖不到，在发生入侵事件时不能发出告警，最终损害的还是业务自身的利益。
    • 1．操作系统标准
      • 选用什么样的操作系统，业界并没有标准答案，也就是说并不存在选用某种操作系统是正确的而选择其他的操作系统是错误的说法，需要结合业务实际进行约定。
      • ■ 服务器侧：推荐选一到两种操作系统并确定主版本，如CentOS 7，并将安全防御或检测能力植入系统，如安全加固配置、HIDS安全组件等。
      • ■ 用户侧：推荐选用大家都比较熟悉的系统并确定主版本，如Windows 10，并实施安全政策相关的配置，如入域或将原身份认证模块替换为SSO认证模块、组策略、网络准入控制等。
      • 任何产品都有其生命周期，操作系统也有更新换代的时候，当新一代操作系统开始普及，也要积极拥抱变化，主动适配，及时刷新产品标准，而存量的业务如果没有面临重大风险的话，可继续使用原来的标准直至退役。
    • 2．Web服务器标准
      • 推荐约定使用少量几种Web服务器组件并确定主版本，如Nginx 1.10、NodeJS 10等。
    • 3．数据库标准
      • 推荐约定使用少量几种数据库组件并确定主版本，如MariaDB 10等。
    • 4．容器基础镜像
      • 目前用得最多的容器是Docker，与虚拟机相比，Docker性能更好，在同样的硬件环境下，可运行的容器数量远远多于可运行的虚拟机的数量，支持快速批量部署，但隔离性要弱于虚拟机。
      • 容器的基础镜像，可以理解为容器内的操作系统，是容器内应用赖以运行的环境。如果各业务都采用自己的基础镜像，那么安全解决方案就无法统一适配，最终无法达到预期的安全效果。对容器的基础镜像进行约定，可以统一开展运维、安全检测等工作。
    • 5．用户侧标准
      • 用户侧电脑终端：
      • ■ 使用指定的防病毒软件。
      • ■ 配置指定的补丁更新地址。
      • ■ 入域或将原身份认证模块替换为SSO身份认证模块。
      • ■ 安装/使用指定的网络准入控制与策略检查客户端软件。
      • 员工电脑是大家的生产力工具，使用得最多，也最容易出现各种问题。使用统一的环境，将有助于IT技术支持人员快速定位及解决问题。
    • 6．限制使用的服务
      • 有些服务已经过时，存在较多安全问题，应限制尽量不要使用，最好是禁止使用。例如FTP、Telnet，存在明文传输等风险。FTP的使用还会给防火墙管理带来麻烦，因为涉及多个端口的开放，而能够真正弄明白FTP各种模式（主动模式和被动模式）以及所需要开放的端口的人员不多，带来的沟通和管理成本也很高，强烈建议禁用。
      • 文件共享服务，因为涉及多端口及潜在的入侵风险，也应严格限制，在业务中尽量避免使用。
      • FTP主动模式下，客户端先和服务器TCP 21端口建立连接，并通过PORT指令指定客户端开放的数据端口，服务器侧使用TCP 20主动连接客户端指定的数据端口；被动模式下，服务器打开一个临时端口（1025～65535）用于数据传输，客户端访问该临时端口传输数据。无论是哪一种，均涉及多端口的使用，很容易造成防火墙开放大端口范围的策略，建议禁用。
    • 7．例外场景
      • 约定范围内的产品有时无法满足业务需要，这就需要有一个例外的处理机制，如：
      • ■ 在登记备案系统中登记。
      • ■ 安全团队介入，提供专业的风险评估与加固意见，实施加固措施。
      • ■ 更新产品标准，与时俱进。
  • 数据脱敏标准
    • 数据脱敏，即按照一定的规则对数据进行变形、隐藏或部分隐藏处理，让处理后的数据不会泄露原始的敏感数据，实现对敏感数据的保护。
    • 一般需要在界面展示、日志记录等场景对可以直接定位到自然人的个人数据进行脱敏处理。下表是一些典型的脱敏标准。
  • 漏洞定级标准
    • 在收到外部报告的漏洞，或者内部安全系统发现漏洞之后，通常需要对漏洞进行定级，以便在不同的团队间达成共识，减少分歧，因为定级决定了是否需要处置或处置的方式，可以让安全应急团队将重心放在处置高危漏洞上面。
    • 对不同的漏洞按照定级进行排序，可以决定处置的优先级。此外，漏洞定级还可以用于向漏洞报告者发放不同的奖励。
    • 关于漏洞分级，业界经常采用的方法有：
      • ■ 五级：严重、高危、中危、低危、可接受。
      • ■ 三级：高危、中危、低危。
    • 1．高危漏洞
    • 2．中危漏洞
    • 3．低危漏洞
• 数据安全技术规范