Day22-01｜4.8.1 计算机信息系统安全保护等级：让安全投入与系统重要性相匹配

本文对应《系统架构设计师教程（第2版）》第4章“信息安全技术基础知识”4.8.1“计算机信息系统安全保护等级”。安全保护等级的核心思想，是根据系统受到破坏后对公民、法人、其他组织、社会秩序和公共利益可能造成的损害程度，确定相应的保护要求。对系统架构设计师而言，等级不是一张贴在机房门口的标签，而是影响安全目标、控制措施、资源投入、运维流程和验收证据的架构约束。

一、学习目标与考试定位

完成本节后，应能够解释等级保护的基本概念、保护对象和定级思路；理解不同等级在自主保护、指导保护、监督保护、强制保护和专控保护方面的差异；能够区分系统定级、建设整改、等级测评和监督检查；能够把等级要求映射到身份认证、访问控制、网络边界、审计、数据保护、备份恢复和安全管理；能够在案例题中指出“定级过低”“一套系统混合定级”“只做测评不做建设”等常见问题。

综合知识题通常考查等级保护的层次概念和关键术语，案例题则会给出政务、金融、医疗、工业控制或大型企业系统，要求分析定级、分区、技术措施和管理措施。高分答案要体现：先识别系统和业务，再评估破坏后果；先确定保护等级，再设计控制；同时建立技术、管理和持续运营闭环。

二、什么是计算机信息系统安全保护等级

计算机信息系统安全保护等级，是根据系统受到破坏后可能造成的损害程度，对系统安全保护能力提出分级要求的一种制度化方法。它解决的是“这个系统应该投入多少安全保护、采用多强控制、由谁监督”的问题。等级保护并不意味着等级越高越好，而是要使保护能力与业务重要性、风险和监管要求相匹配。

传统教材通常将保护等级划分为五级：第一级为用户自主保护级，第二级为系统审计保护级，第三级为安全标记保护级，第四级为结构化保护级，第五级为访问验证保护级。实际工作中还要结合现行法律法规、国家标准、行业监管要求和组织制度理解，考试作答应以题干和指定教材表述为准，不要把历史教材术语与现实制度机械混用。

可以用下面的逻辑理解定级：

业务重要性 → 受损对象 → 损害程度 → 保护等级 → 安全控制 → 测评与监督

如果系统保存普通公开信息，故障影响可能主要是短时服务中断；如果系统承载人口、支付、医疗或关键基础设施数据，破坏可能造成严重社会影响。两者不能使用同一套最低安全基线。

三、等级划分的基本思路

定级首先要明确系统遭受破坏的三类主要影响：对公民、法人和其他组织合法权益的损害；对社会秩序和公共利益的损害；对国家安全的损害。根据影响范围、严重程度和系统承担的业务职责，确定系统应达到的保护等级。

定级不能只看数据量，也不能只看服务器数量。一个数据量不大的核心控制系统，可能因为影响生产安全而需要较高保护；一个访问量很大的公开展示网站，若不涉及敏感业务，其保护重点可能不同。架构师应结合业务流程、数据流、控制流、依赖关系、用户范围和故障后果进行分析。

四、五级保护思想的理解

第一级强调用户自主保护，系统在一般环境中依靠用户和系统自身采取基本保护措施。第二级增加系统审计保护，要求能够记录和追踪重要安全事件，适用于需要一定安全责任和审计能力的系统。第三级强调安全标记保护，通常需要更严格的身份鉴别、访问控制、审计和边界保护，并接受相关监督。

第四级强调结构化保护，要求安全控制更加系统化、分区化和抗攻击，保护机制需要独立、完整和可验证。第五级强调访问验证保护，适用于极高安全要求的特殊系统，需要采用更严格的访问验证、可信机制和专门控制。等级提高意味着保护强度、控制粒度、审计深度、管理成熟度和测评要求提高，同时也会带来成本、性能、运维和兼容性压力。

在考试中不要只背等级名称，要把等级与控制能力联系起来。例如，系统审计保护级的关键不是“安装日志系统”这么简单，而是重要安全事件能被记录、保护、分析和追责；更高等级也不是增加更多设备，而是要求访问控制、隔离、可信验证和管理过程形成体系。

五、定级对象与边界划分

定级对象可以是一个独立的信息系统，也可以是相互关联、共同支撑某项业务的一组系统。边界划分必须真实反映业务和技术关系。把所有应用、数据库、办公系统和互联网平台粗暴地放进一个大系统，可能导致等级判断模糊、控制要求互相牵制；把一个完整业务拆得过细，又可能遗漏跨系统的数据流和共享风险。

确定边界时要查看组织职责、业务功能、网络区域、数据流向、用户和管理员、部署环境、外部依赖、灾备系统以及云平台责任边界。微服务、容器和云服务并不会自动改变定级对象，关键要看它们是否共同支撑同一业务以及安全责任如何划分。

如果同一平台承载多个业务，应识别核心业务和普通业务的差异，采用分区、分域、独立账号、独立密钥、独立审计和不同保护策略。对于无法物理分离的共享组件，应通过逻辑隔离、租户隔离、访问控制和责任边界降低相互影响，并在测评时提供明确证据。

六、等级保护对架构设计的影响

1. 身份鉴别与访问控制

根据系统等级和业务敏感度，设计多因素认证、强口令、证书认证、统一身份管理、最小权限、职责分离和特权账号管理。不能只保证“能登录”，还要保证登录主体、设备、会话和授权范围可验证。管理员和普通用户、开发与生产、运维与审计应避免权限混用。

2. 网络与通信保护

按照业务、数据、管理和外部接入划分网络区域，使用边界防护、访问控制、入侵检测、堡垒机、加密通信和安全审计。数据库、密钥服务和管理平面不应直接暴露在公网。跨区域数据交换需要确认身份、保护传输机密性和完整性，并记录访问证据。

3. 主机、应用与数据保护

操作系统、中间件和数据库应配置安全基线、补丁管理、恶意代码防护和日志保护。应用要防范注入、越权、会话窃取、重放和敏感信息泄露。数据按敏感性分类，采用加密、脱敏、备份、访问审计、完整性校验和生命周期管理。等级保护要求不能只落实在网络设备上。

4. 备份恢复与业务连续性

保护等级提高后，服务中断和数据损坏的影响通常更大，架构应设计备份、灾备、冗余、故障切换、恢复演练和应急预案。备份本身也要加密、隔离和审计，避免生产被攻破后备份一起被删除或加密。恢复目标应通过 RTO、RPO 和演练结果验证，而不是停留在文档中。

5. 安全管理体系

技术措施必须由安全组织、人员管理、制度流程、建设管理、运维管理和应急管理支撑。开发人员不应直接拥有生产特权，变更应审批和留痕，外包人员应受合同和权限约束，安全事件应有发现、报告、处置、恢复和复盘机制。高级架构师需要把这些管理要求转化为系统能力，例如工单审批、权限到期、配置基线、审计报表和自动化检查。

七、定级、建设整改、测评和监督的区别

定级是确定系统保护等级和对象边界；建设整改是依据等级要求补齐技术和管理措施；等级测评是按照标准检查系统是否达到相应要求；监督检查是有关机构或组织对保护工作的持续监督。四者不是同一个动作，也不是测评通过后就永久安全。

常见错误是先购买设备、后补做定级；或者把测评报告当成安全建设的终点。合理流程应是：系统规划时识别业务和数据，建设阶段落实安全同步规划、同步建设、同步运行，运行阶段持续监控、检查、整改和复测。系统发生业务范围、部署环境、网络边界或数据类型重大变化时，应重新评估定级和控制措施。

八、案例分析：市民服务平台定级与架构改造

某市民服务平台整合社保、户籍、医疗和公共缴费服务。平台包括互联网门户、移动端接口、业务中台、数据交换平台、核心数据库和灾备中心。初期团队准备将整个系统定为最低等级，并认为只要部署防火墙和杀毒软件即可满足要求。

分析时首先要明确系统承载公共服务和敏感个人信息，多个部门和大量公众依赖平台，数据泄露、篡改或长时间中断都会造成较大影响，不能简单按普通网站处理。其次要合理划分定级对象和安全边界，互联网接入、业务处理、数据存储、管理运维和灾备区域应分区，跨部门交换应明确责任与接口保护。

架构改造包括统一身份认证和多因素保护、按角色和业务办理范围授权、管理入口经堡垒机访问、接口双向认证和请求审计、敏感数据加密与脱敏、数据库访问控制和审计、主机与中间件基线、漏洞扫描、备份隔离、灾备演练和应急响应。对共享基础设施要落实租户隔离、密钥隔离和日志分域，避免一个部门的账号或漏洞影响全平台。

验收不能只检查设备是否在线，还要检查高风险账号、数据访问、异常接口、备份恢复、策略变更、告警处置和应急切换是否有记录并可复现。

九、常见误区

第一，等级越高越安全、越低越省事。等级应与业务后果和监管要求匹配，过低会留下风险，过高则可能造成不必要成本和复杂度。第二，买了安全设备就完成等级保护。等级保护还包括身份、应用、数据、管理和持续运营。第三，定级只由技术部门决定。业务负责人、数据负责人、安全人员和管理层都应参与。第四，测评通过就不用再改。系统会演化，威胁和漏洞也会变化。第五，云上系统不需要定级。云环境仍需明确业务系统边界、云平台责任和租户控制。

十、课后练习

练习一：单项选择

关于等级保护，下列说法正确的是（ ）。

A. 定级越高越好，不需考虑业务成本；B. 只要部署防火墙就完成等级保护；C. 定级应结合系统受破坏后的影响程度、业务职责和数据价值；D. 通过一次测评后永久不需要复评。

答案：C。等级保护是与业务影响和安全要求匹配的持续治理过程，不是单一设备、一次测评或等级越高越好的简单结论。

练习二：简答题

请说明定级对象边界划分时至少应考虑哪些因素。

参考答案：应考虑业务功能和组织职责、网络和部署区域、数据流向、用户与管理员、应用及基础设施依赖、外部接口、灾备系统、云平台责任边界和共享组件。边界既不能把不同安全责任和业务影响完全混在一起，也不能拆分到遗漏跨系统数据流和共同风险的程度。

练习三：案例分析

某金融平台已通过等级测评，但上线新移动端、接入第三方支付并迁移到云平台后，仍沿用原有边界和安全控制。请分析风险并给出措施。

参考答案：业务入口、数据流、外部依赖、部署边界和责任关系已经变化，原定级对象、风险分析和控制措施可能不再适用；移动端可能引入新的认证和会话风险，第三方支付增加接口和供应链风险，云迁移改变网络、主机和运维责任。应重新开展变更影响分析，核对是否需要调整定级对象和边界；补充移动端、API、第三方和云环境的身份、加密、访问控制、审计和配置基线；明确云服务商与使用方责任；进行漏洞扫描、渗透验证、灾备和恢复演练；整改后重新测评或复核，并建立重大变更触发的持续评估机制。

十一、论文素材

论文可写：在项目启动阶段，我首先依据业务职责、数据敏感程度、用户范围和系统受破坏后的影响确定保护等级，明确互联网接入、业务处理、数据存储、管理运维和灾备边界。随后将等级要求映射为统一身份认证、最小权限、网络分区、边界控制、主机与应用基线、数据加密、审计、备份恢复和应急响应等架构措施。对于云平台和第三方接口，我进一步明确责任边界和证据要求，通过持续扫描、配置核查、权限复审、恢复演练和定期测评验证控制有效性。

写作时要补充真实的系统影响、定级依据、架构分区、关键控制和测评整改结果。不要只写“通过了等保”，应说明为什么需要这些控制、它们解决了哪些风险，以及如何用指标和证据验证。

十二、今日复盘

安全保护等级的本质是让保护能力与业务后果匹配。定级要看业务、数据、用户、依赖和破坏影响；对象边界要覆盖真实的系统和责任关系；建设要同时覆盖技术和管理；测评、监督、整改和复评构成持续闭环。下一篇进入 4.8.2 安全风险管理，学习如何识别、分析、处置和持续跟踪安全风险。