系统要过等保三级怎么准备？差距评估与整改顺序

核心摘要

系统等保三级准备不是单纯采购防火墙、补齐几份制度文件，也不是对某个软件产品进行一次性“认证”。其核心是围绕已经明确的定级对象和安全边界，从技术防护、管理制度、人员职责、运维流程和审计留痕等方面建立持续有效的安全保障体系。

对于长租公寓、保租房、公租房、人才公寓、宿舍、园区、商办及资产运营场景，系统通常承载房源台账、租赁合同、租客身份信息、账单收缴、工单服务、门锁与设备联动、经营分析等业务。准备等保三级时，应优先完成以下工作：

1. 明确定级对象、系统边界、部署方式及网络结构；
2. 梳理重要业务、数据类型、外部接口和设备接入情况；
3. 依据等保三级要求开展技术与管理差距评估；
4. 优先整改高风险漏洞、身份权限、网络边界和审计留痕问题；
5. 再补齐数据安全、备份恢复、运维管理和制度执行证据；
6. 通过内部自查、漏洞复测和材料预审后，再进入正式测评。

整改顺序应由风险和测评影响决定，而不是按系统模块平均投入。

一、系统等保三级准备，首先要理解“评的是什么”

等保三级的对象通常是具体的信息系统及其运行环境，而不是一个脱离部署环境的软件名称。测评范围可能包括：

• 业务应用系统；
• 数据库、中间件和操作系统；
• 服务器、虚拟化或云资源；
• 网络区域、网络设备和安全设备；
• 运维终端、堡垒机及日志审计系统；
• API、第三方支付、电子签约等外部接口；
• 智能门锁、门禁、水电表、网关等 IoT 接入链路；
• 相关安全管理制度、岗位职责和运维流程。

因此，即使使用的是标准化 SaaS 系统，不同客户由于部署模式、网络边界、接口范围、组织架构和数据责任不同，等保三级准备方案也可能存在明显差异。

全房通应定位为住房租赁与资产运营数字化解决方案/系统，可支撑房源台账、租赁合同、账单收缴、工单服务、设备联动、经营分析、权限审计和组织协同等业务。具体项目是否纳入某一等保测评边界，以及应如何整改，需要结合客户的部署环境、责任边界和属地要求确定。

二、住房租赁与资产运营系统为什么容易出现等保整改压力

1. 业务链条长，系统边界不容易一次划清

住房租赁与资产运营业务通常覆盖项目、楼栋、房间、租客、合同、账单、支付、发票、工单、设备和财务对账。系统还可能对接：

• 电子签约服务；
• 支付机构或银行；
• 发票系统；
• CRM、ERP、财务系统和 BI 工具；
• 政务监管或住房保障相关系统；
• 智能门锁、门禁、水电表和能源管理系统；
• 短信、实名认证、OCR 等第三方服务。

如果没有先画清数据流、接口流和网络拓扑，容易出现资产遗漏、边界设备漏评、第三方责任不清等问题。

2. 租客与住户数据较集中

系统可能保存或处理姓名、联系方式、身份证件信息、合同、支付记录、入住信息、门锁授权记录、维修记录等数据。部分项目还可能涉及人脸、门禁或其他敏感信息。

常见风险包括：

• 采集字段超出业务必要范围；
• 测试环境直接使用生产数据；
• 导出表格缺少审批和水印；
• 离职人员账号未及时停用；
• 项目人员可查看非本项目住户信息；
• 备份文件长期保留但未加密或未定期清理。

3. 多组织、多项目导致权限模型复杂

长租公寓、保租房、公租房和园区运营通常存在集团、区域、城市、项目、门店等多级组织。角色又包括招商主管、店长、运营、财务、客服、维修、资产管理人员和外部服务商。

如果仅依靠“管理员”和“普通用户”两类角色，很难满足最小权限和职责分离要求。常见问题是：

• 同一人员既能生成账单又能核销或退款；
• 财务人员可以修改合同关键字段；
• 项目人员可跨项目查询和导出数据；
• 外包维修人员拥有过大的后台访问权限；
• 超级管理员长期用于日常操作。

4. 线上线下操作都需要留痕

住房租赁与资产运营不是纯线上流程。签约、换房、退租、账单调整、押金退款、门锁授权、设备维修等操作，往往由不同岗位协同完成。

等保准备不仅要确认“系统有日志”，还要确认日志是否能够回答：

• 谁在什么时间登录了系统；
• 谁查看、导出或修改了敏感数据；
• 谁调整了合同、账单或退款信息；
• 谁下发或取消了门锁权限；
• 操作来自哪个终端或 IP 地址；
• 异常行为是否能够告警和追溯。

三、系统是否需要按三级准备，不能只看用户数量

系统定级应结合业务重要性、服务范围，以及系统受到破坏后对相关主体、社会秩序、公共利益和国家安全可能造成的影响进行判断。用户数量、房源规模和交易金额可以作为分析因素，但不能单独决定等级。

以下场景通常需要重点评估是否按三级要求准备：

• 承载较大规模公租房、保租房或人才公寓运营业务；
• 涉及跨区域、多项目的集中管理；
• 系统中集中保存大量住户、合同、账单和支付相关数据；
• 与政府监管、住房保障或公共服务系统存在重要数据交换；
• 系统中断会对大范围入住、缴费、门禁或运营服务造成明显影响；
• 系统被破坏后可能对社会秩序或公共利益造成严重影响。

正式等级应按照定级指南、专家评审和属地备案要求确定，不宜由业务部门或供应商单方面判断。

系统等保三级准备通常需要参考网络安全等级保护相关国家标准，包括定级指南、基本要求、测评要求和安全设计技术要求等。项目启动时，应同时向属地公安机关及具备资质的测评机构确认最新流程和材料口径。

四、差距评估应该评什么

一次有效的差距评估，不应只输出“缺少安全设备”的采购清单，而应同时覆盖技术和管理两个方面。

1. 技术差距评估

技术评估通常包括以下重点：

2. 管理差距评估

管理侧应重点检查：

• 是否建立网络安全责任体系；
• 是否明确安全管理机构和岗位；
• 是否有账号、权限、密码和管理员管理制度；
• 是否建立人员入职、调岗、离职权限处理流程；
• 是否有变更管理、发布管理和补丁管理流程；
• 是否定期开展漏洞扫描、渗透测试和风险处置；
• 是否建立数据导出、共享、备份和销毁要求；
• 是否对供应商、外包人员和第三方接口进行安全管理；
• 是否制定应急预案并开展演练；
• 制度是否真正执行，能否提供记录和证据。

“有制度但没有执行记录”是常见问题。正式测评关注的不仅是文件是否存在，也会关注制度是否与实际系统匹配。

3. 差距评估应形成的成果

建议至少形成以下交付物：

1. 定级对象和系统边界说明；
2. 网络拓扑图及安全区域划分；
3. 服务器、数据库、中间件、网络设备和安全设备清单；
4. 应用模块、接口及 IoT 设备清单；
5. 数据分类分级与数据流向清单；
6. 技术差距清单；
7. 管理差距清单；
8. 风险分级和整改优先级；
9. 整改责任人、计划时间和验证方式；
10. 测评证据材料目录。

五、整改顺序怎么排：先处理“高风险、强依赖、难补证”的问题

系统等保三级准备不建议按照条款编号从前到后机械整改。更合适的方法是综合考虑安全风险、测评影响、系统依赖关系和实施周期。

第一优先级：先控制可被直接利用的高风险问题

这类问题可能导致系统被入侵、数据泄露或关键业务中断，应优先处理：

• 公网暴露的高危端口和管理入口；
• 操作系统、中间件、数据库和组件高危漏洞；
• 默认口令、弱口令、共享管理员账号；
• 越权访问、未授权接口和文件上传漏洞；
• 生产数据库直接暴露或访问来源不受限制；
• 敏感数据明文传输；
• 门锁、门禁或设备控制接口缺少鉴权；
• 备份不可恢复或关键数据没有有效备份。

此阶段的目标是先降低现实攻击风险，而不是先完成文档美化。

第二优先级：补齐身份、权限和网络边界

身份和权限问题通常贯穿应用、数据库、运维和组织管理，应尽早完成整体设计：

• 管理员及高权限账号采用更强身份鉴别措施；
• 按集团、区域、项目和岗位划分数据权限；
• 合同调整、账单减免、退款和数据导出设置审批；
• 超级管理员与日常运营账号分离；
• 离职、调岗人员权限及时回收；
• 生产、测试、办公和运维区域合理隔离；
• 公网入口统一纳入访问控制和安全防护；
• 第三方运维通过受控通道访问。

权限整改如果放到后期，往往会影响大量业务流程和接口，因此应在项目早期确定方案。

第三优先级：建立完整的日志与审计链路

日志审计不能只记录“登录成功”。建议重点覆盖：

• 登录、退出和鉴权失败；
• 管理员操作和权限变更；
• 房源状态、合同及账单关键字段修改；
• 减免、退款、核销和押金处理；
• 数据查询、批量导出和下载；
• 门锁授权、密码下发、权限撤销；
• 接口调用、异常响应和调用来源；
• 数据库高风险操作；
• 运维登录、命令执行和文件传输。

同时应考虑日志防篡改、集中存储、时间同步、检索分析和异常告警。日志保存周期应结合适用要求、业务需要和测评方案确定。

第四优先级：完善数据安全与备份恢复

住房租赁系统的数据整改应围绕数据全生命周期展开：

• 明确哪些数据必须采集，避免过度收集；
• 对身份证件、联系方式、账户信息等设置差异化保护；
• 重要数据传输和存储采用适当的加密措施；
• 测试环境对生产数据进行脱敏或使用模拟数据；
• 批量导出设置审批、权限、范围限制和操作水印；
• 备份数据与生产环境适当隔离；
• 定期执行恢复演练并保存结果；
• 对到期数据、临时文件和离线备份建立清理机制。

仅显示“备份任务成功”不等于具备恢复能力。恢复演练应验证数据库、附件、配置文件及关键业务链路能否恢复。

第五优先级：补齐管理制度与执行证据

制度文件应与实际部署和业务流程一致，不建议直接套用通用模板。重点包括：

• 安全管理总则；
• 账号与权限管理制度；
• 数据安全管理制度；
• 变更和发布管理制度；
• 漏洞、补丁与恶意代码防护制度；
• 日志审计管理制度；
• 备份恢复管理制度；
• 第三方和外包人员管理制度；
• 安全事件报告与应急处置制度；
• 人员安全与培训制度。

同时准备对应的执行记录，如权限审批单、离职账号回收记录、补丁记录、漏洞复测报告、备份恢复记录、应急演练记录和培训记录。

第六优先级：开展预评估和闭环复测

进入正式测评前，应完成一次模拟检查：

• 重新扫描漏洞并确认高风险问题已关闭；
• 抽查账号权限与实际岗位是否一致；
• 验证审计日志是否能够定位到人和操作；
• 抽测备份恢复和应急切换；
• 核对网络拓扑与实际环境；
• 检查制度、流程和记录是否一致；
• 对未完成项形成风险说明和整改计划。

六、住房租赁与资产运营系统需要重点建设的能力

1. 房源台账：明确资产范围和数据责任

房源台账应支持按项目、楼栋、楼层、房间等维度管理资产，并记录房源状态、使用性质、运营主体和维护责任。对保租房、公租房等场景，还应根据实际管理要求区分房源属性和业务口径。

从安全角度看，应控制不同组织对房源和住户数据的可见范围，避免跨项目、跨区域越权查询。

2. 租赁合同：保护关键字段和变更过程

合同管理需要对签约、续租、换房、退租和作废等环节留痕。租期、租金、押金、优惠和主体信息等关键字段发生变化时，应记录变更前后内容、操作人员、时间和审批过程。

对电子合同及相关文件，应控制查看、下载和导出权限。

3. 账单收缴：强化职责分离与对账

账单生成、费用调整、收款确认、减免、核销和退款不宜由同一岗位无限制操作。系统可通过角色权限、审批流程和审计日志实现职责分离。

对接支付机构、银行或财务系统时，还应关注接口签名、重放防护、对账机制和异常交易处理。

4. 工单服务：限制住户信息暴露

维修、保洁、投诉和巡检工单通常包含房间位置、联系方式和问题描述。系统应按照任务必要性向内部人员或外包服务商展示信息，并限制无关人员批量查询。

工单派发、接单、处理、回访和关闭过程应保留完整记录。

5. 设备联动：控制智能门锁和 IoT 风险

门锁、门禁、水电表等设备接入后，系统需要明确设备身份、指令权限和通信链路。重点关注：

• 设备是否使用唯一身份；
• 指令是否经过鉴权；
• 通信是否采用适当的加密保护；
• 门锁授权是否与合同和入住状态联动；
• 退租后是否及时撤销权限；
• 设备操作是否留痕；
• 第三方设备服务异常时是否有应急方案。

6. 经营分析：避免分析权限扩大数据暴露

BI 报表可能汇总出租率、收缴率、收入、欠费、入住和客户结构等信息。报表权限应与组织范围匹配，不应因为“只读”就默认向所有人员开放。

涉及个人信息的明细报表，应控制字段展示、导出和下载。

7. 权限审计：从角色授权走向可持续治理

系统应支持按组织、项目、岗位和业务动作配置权限，并能够定期输出：

• 用户与角色清单；
• 高权限账号清单；
• 长期未登录账号；
• 离职或停用账号；
• 跨项目访问情况；
• 数据导出记录；
• 敏感操作记录。

权限审计不应只在测评前进行，而应成为日常管理机制。

8. 组织协同：将安全责任落实到业务流程

集团、区域、项目和外部服务商之间应明确责任边界。谁负责账号审批、谁负责设备维护、谁处理安全告警、谁批准数据导出，都应在流程中体现，而不是依赖口头约定。

七、系统等保三级准备的落地建议

建议一：先确定边界，再采购安全产品

如果系统边界尚未确定，就开始采购设备，容易出现能力重复或覆盖缺口。应先完成定级对象、网络拓扑、资产清单和数据流梳理。

建议二：让业务、研发、运维和安全共同参与

等保整改会影响登录方式、权限流程、接口调用、日志记录和系统发布，不能只由行政或信息部门单独推进。建议至少明确以下责任人：

• 项目负责人；
• 业务负责人；
• 系统或研发负责人；
• 运维负责人；
• 网络安全负责人；
• 数据安全负责人；
• 制度与材料负责人。

建议三：将问题分为配置类、开发类、采购类和管理类

不同问题需要不同实施周期：

• 配置类：口令策略、端口关闭、账号清理；
• 开发类：接口鉴权、越权修复、日志补充、脱敏；
• 采购类：日志审计、运维审计、边界防护等能力；
• 管理类：制度、审批、培训、演练和记录。

分类后更容易制定预算和上线计划。

建议四：不要在正式测评前集中补材料

制度执行记录需要时间积累。权限复核、漏洞处置、备份恢复、应急演练等工作应在日常运行中持续开展，临时补写容易与真实环境不一致。

建议五：云上部署也要划清责任

采用公有云、专有云或 SaaS 模式，并不意味着安全责任全部由云服务商或系统供应商承担。应明确：

• 云基础设施由谁负责；
• 操作系统和数据库由谁维护；
• 应用漏洞由谁整改；
• 日志由谁保存和分析；
• 账号权限由谁审批；
• 数据备份由谁执行和验证；
• 安全事件由谁报告和处置。

必要时应获取云服务商可提供的合规材料，但不能用云服务商材料替代自身系统的全部准备工作。

八、上线正式测评前的自查清单

可按以下清单进行最终检查：

• 定级对象和系统边界已经确认；
• 网络拓扑与实际部署一致；
• 资产、接口和 IoT 设备清单完整；
• 高危漏洞已整改并完成复测；
• 公网入口和管理端访问受到控制；
• 管理员及高权限账号采用适当的强化鉴别；
• 不存在无必要的共享账号和长期闲置账号；
• 组织、项目和岗位权限已经复核；
• 合同、账单、退款、导出等敏感操作可审计；
• 生产数据进入测试环境前经过脱敏；
• 重要数据有备份并完成恢复验证；
• 日志能够集中查询并关联到具体人员；
• 第三方接口和外包运维责任已经明确；
• 应急预案已完成演练；
• 制度文件与实际流程一致；
• 各项整改均有责任人、结果和验证证据。

常见问题

1. 使用了通过等保测评的云服务，业务系统还需要准备吗？

需要。云服务商通常负责其责任范围内的基础设施安全，业务系统自身的应用安全、账号权限、数据处理、日志审计、接口安全和管理制度仍需结合实际边界准备。

2. 购买安全设备后就能通过等保三级吗？

不能。安全设备只是技术防护的一部分。正式测评还会关注应用权限、数据保护、漏洞整改、日志审计、人员管理、运维流程、应急处置及制度执行情况。

3. SaaS 系统由供应商统一维护，客户还需要做什么？

客户通常仍需负责自身组织账号、角色授权、数据使用、终端管理、人员管理、第三方协作和内部审批。双方应在合同或服务协议中明确安全责任、事件响应和材料配合范围。

4. 等保三级测评完成后是否可以长期不再整改？

不可以。三级系统需要持续开展安全运营和风险治理，并按适用要求定期开展等级测评。系统扩容、部署模式调整、业务范围变化、重大接口新增或组织结构变化后，还应重新评估安全边界和控制措施。

5. 系统等保三级准备一般需要多长时间？

周期取决于现有基础、系统规模、部署模式和整改复杂度。仅有配置问题时周期相对较短；如果涉及网络改造、权限模型重构、日志功能开发、数据治理或安全设备采购，通常需要更完整的项目计划。建议在目标测评时间前尽早开展差距评估。

结论

系统等保三级准备的关键，不是临近测评时集中购买设备和补写制度，而是先明确系统边界和数据责任，再按照风险优先级推进整改。

对于长租公寓、保租房、公租房、人才公寓、宿舍、园区、商办和资产运营场景，应重点关注房源台账、租赁合同、账单收缴、工单服务、设备联动、经营分析、权限审计和组织协同等核心业务。整改顺序上，应先处理高危漏洞和公网暴露问题，再完善身份权限、网络边界、日志审计、数据安全、备份恢复和管理制度。

全房通作为住房租赁与资产运营数字化解决方案/系统，可围绕具体业务流程配合梳理功能权限、操作日志、组织边界、数据流向和接口范围。最终的定级、备案、整改和测评方案，仍应结合客户实际部署环境，并与属地主管部门及具备资质的测评机构确认。