[系统运维]网络安全等级保护测评高风险判定-安全计算环境-4

目录

1.网络设备、安全设备、主机设备、数据库等

1.1身份鉴别

1.1.1设备存在弱口令或相同口令

1.1.2设备鉴别信息无防窃听措施

1.1.3设备未实现双因素认证

1.2访问控制

1.2.1设备默认口令未修改

1.3安全审计

1.3.1设备无安全审计措施

1.4入侵防范

1.4.1设备开启高危服务端口

1.4.2未限制设备管理终端

1.4.3互联网设备未修补已知重大漏洞

1.4.4内部设备存在可被利用的漏洞

1.5恶意代码防范

1.5.1无恶意代码防范措施

2应用系统及数据

2.1身份鉴别

2.2.1应用系统口令策略缺失

2.1.2应用系统存在弱口令

2.1.3应用系统无登录失败处理机制

2.1.4互联网可访问系统鉴别信息明文传输

2.1.5互联网访问系统未实现双因素认证

2.2访问控制

2.2.1应用系统身份鉴别机制可被旁路

2.2.2应用系统默认口令未修改

2.2.3应用系统访问控制策略可被旁路

2.3安全审计

2.3.1应用系统完全审计措施

2.3.2应用系统审计记录不满足保护要求

2.4入侵防范

2.4.1应用系统有效校验功能存在缺陷

2.4.2应用系统存在可被利用的高危漏洞

2.5数据完整性

2.5.1数据传输无整性保护措施

2.6数据保密性

2.6.1重要数据明文传输

2.6.2重要数据无存储保密性保护

2.7数据备份恢复

2.7.1数据备份措施缺失

2.7.2异地备份措施缺失

2.7.3数据处理系统无冗余措施

2.8剩余信息保护

2.8.1鉴别信息释放措施失效

2.8.2敏感数据释放措施失效

2.9个人信息保护

2.9.1违规采集，存储个人信息

2.9.2非授权访问，使用个人信息

2.10数据完整性和保密性

2.10.1云服务客户数据，用户个人信息违规出境

1.网络设备、安全设备、主机设备、数据库等

1.1身份鉴别

1.1.1设备存在弱口令或相同口令

对应要求：应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换。

判例内容：网络设备、安全设备、操作系统、数据库等存在弱口令账户（包括空口令、无身份鉴别机制），并可通过该账户登录；或大量设备管理员账户口令相同，一台设备口令被破解将导致大量设备被控制，可判定为高风险。

补偿措施：由于业务场景需要，使用无法设置口令或口令强度达不到要求的专用设备，可从设备登录方式、物理访问控制、受限使用情况、其他防护措施、管理制度等角度对其进行综合风险分析，酌情判断风险等级。

整改建议：建议删除或修改账户口令重命名默认账户，制定相关管理制度，规范口令的最小长度、复杂度与生命周期，并根据管理制度要求，合理配置账户口令复杂度和定期更换策略；此外，建议为不同设备配备不同的口令，避免一台设备口令被破解影响所有设备安全。

1.1.2设备鉴别信息无防窃听措施

对应要求：当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听。

判例内容：通过不可控网络环境远程管理的网络设备、安全设备、操作系统、数据库等，鉴别信息明文传输，容易被监听，造成数据泄漏，可判定为高风险。

补偿措施：

1. 整个远程管理过程中，只能使用加密传输通道进行鉴别信息传输的，可视为等效措施；
2. 采用多因素身份认证、访问地址限定、仅允许内部可控网络进行访问的措施时，窃听到口令而无法直接进行远程登录的，可酌情降低风险等级；
3. 通过其他技术管控手段（如准入控制、桌面管理、行为管理等），降低数据窃听隐患的，可酌情降低风险等级；
4. 设备提供加密/非加密两种管理模式，其非加密通道无法关闭的情况下，若管控措施得当，且平时采用加密进行管理的，可根据实际管理情况，酌情判断风险等级；
5. 根据被测对象的作用以及重要程度，结合实际情况，酌情判断风险等级。

整改建议：建议尽可能避免通过不可控网络对网络设备、安全设备、操作系统、数据库等进行远程管理。如确有需要，则建议采取措施或使用加密机制（如VPN加密通道、开启SSH、HTTPS协议等），防止鉴别信息在网络传输过程中被窃听。

1.1.3设备未实现双因素认证

对应要求：应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。

判例内容：核心设备、操作系统等未采用两种或两种以上鉴别技术对用户身份进行鉴别。例如仅使用用户名/口令方式进行身份验证，削弱了管理员账户的安全性，无法避免账号的未授权窃取或违规使用，可判定为高风险。

补偿措施：

1. 设备通过本地登录方式（非网络方式）维护，本地物理环境可控，可酌情降低风险等级；
2. 采用两重用户名/口令认证措施（两重口令不同），例如身份认证服务器、堡垒机等手段，可酌情降低风险等级；
3. 设备所在物理环境、网络环境安全可控，网络窃听、违规接入等隐患较小，口令策略和复杂度、长度符合要求的情况下，可酌情降低风险等级；
4. 根据被测对象的作用以及重要程度，结合实际情况，酌情判断风险等级。

整改建议：建议核心设备、操作系统等增加除用户名/口令以外的身份鉴别技术，如密码/令牌、生物鉴别方式等，实现双因子身份鉴别，增强身份鉴别的安全力度；对于使用堡垒机或统一身份认证机制实现双因素认证的场景，建议通过绑定等技术措施，确保设备只能通过该机制进行身份认证，无旁路现象存在。

1.2访问控制

1.2.1设备默认口令未修改

对应要求：应重命名或删除默认账户，修改默认账户的默认口令。

判例内容：网络设备、安全设备、操作系统、数据库等默认账号的默认口令未修改，使用默认口令进行登录设备，可判定为高风险。

补偿措施：由于业务场景需要，无法修改专用设备（如部分工控集成设备）的默认口令，可从设备登录方式、物理访问控制、受限使用情况、其他防护措施、管理制度等角度对其进行综合风险分析，酌情判断风险等级。

整改建议：建议网络设备、安全设备、操作系统、数据库等重命名或删除默认管理员账户，修改默认密码，使其具备一定的强度，增强账户安全性。

1.3安全审计

1.3.1设备无安全审计措施

对应要求：应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计。

判例内容：关键网络设备、安全设备、操作系统、数据库、运维终端等未开启任何审计功能，且未采取其他辅助审计措施，无法对重要的用户行为和重要安全事件进行审计，并对事件进行溯源，可判定为高风险。

补偿措施：

1. 使用堡垒机或其他第三方审计工具进行日志审计（不少于六个月），能有效记录用户行为和重要安全事件，可根据所记录的日志情况、是否存在漏记/旁路等缺陷，综合分析判断风险等级；
2. 核查对象非核心设备，对整个信息系统影响有限的情况下，可酌情降低风险等级。

整改建议：建议在核心设备、安全设备、操作系统、数据库、运维终端性能允许的前提下，开启用户操作类和安全事件类审计策略或使用第三方日志审计工具，实现对相关设备操作与安全行为的全面审计记录，保证发生安全问题时能够及时溯源。

1.4入侵防范

1.4.1设备开启高危服务端口

对应要求：应关闭不需要的系统服务、默认共享和高危端口。

判例内容：网络设备、安全设备、操作系统等存在多余系统服务/默认共享/高危端口，且存在可被利用的高危漏洞或重大安全隐患，可判定为高风险。

补偿措施：

1. 通过其他技术手段能降低漏洞影响，可酌情降低风险等级；
2. 相关漏洞暴露在可控的网络环境，可根据网络防护程度、漏洞危害情况等，酌情判断风险等级。

整改建议：建议网络设备、安全设备、操作系统等关闭不必要的服务和端口，降低安全隐患；根据自身应用需求，需要开启共享服务的，应合理设置相关配置，如设置账户权限等。

1.4.2未限制设备管理终端

对应要求：应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制。

判例内容：通过不可控网络环境远程管理的网络设备、安全设备、操作系统、数据库等，未采取技术手段对管理终端进行限制，可判定为高风险。

补偿措施：管理终端部署在运维区、可控网络或采用多种身份鉴别方式等技术措施，降低终端管控不善所带来的安全风险，可酌情降低风险等级。

整改建议：建议通过技术手段，对管理终端进行限制。

1.4.3互联网设备未修补已知重大漏洞

对应要求：应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞。

判例内容：互联网可直接访问到的网络设备、安全设备、操作系统、数据库等，如存在外界披露的重大漏洞，未及时修补更新，无需考虑是否有POC攻击代码，可判定为高风险。

补偿措施：

1. 相关漏洞暴露在可控的网络环境，可酌情降低风险等级；
2. 网络设备的WEB管理界面存在高危漏洞，而该WEB管理界面只能通过特定IP或特定可控环境下才可访问，可酌情降低风险等级。

整改建议：建议订阅安全厂商漏洞推送或本地安装安全软件，及时了解漏洞动态，在充分测试评估的基础上，弥补严重安全漏洞。

1.4.4内部设备存在可被利用的漏洞

对应要求：应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞。

判例内容：通过验证测试或渗透测试能够确认并利用的，可对网络设备、安全设备、操作系统、数据库等造成重大安全隐患的漏洞（包括但不限于缓冲区溢出、提权漏洞、远程代码执行、严重逻辑缺陷、敏感数据泄露等），可判定为高风险。

补偿措施：

1. 只有在相关设备所在的物理、网络、管理环境严格受控，发生攻击行为可能性较小的情况下，可酌情降低风险等级；
2. 通过验证，现有防范措施已能对高危漏洞起到防护效果，可酌情降低风险等级。

整改建议：建议在充分测试的情况下，及时对设备进行补丁更新，修补已知的高风险安全漏洞；此外，还应定期对设备进行漏扫，及时处理发现的风险漏洞，提高设备稳定性与安全性。

1.5恶意代码防范

1.5.1无恶意代码防范措施

对应要求：

（2级）应安装防恶意代码软件或配置具有相应功能的软件，并定期进行升级和更新防恶意代码库。

（3级、4级）应采用主动免疫可信验证机制及时识别入侵和病毒行为，并将其有效阻断。

判例内容参见--安全区域边界-4.1

2应用系统及数据

2.1身份鉴别

2.2.1应用系统口令策略缺失

对应要求：应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换。

判例内容：应用系统无任何用户口令复杂度校验机制，校验机制包括口令的长度、复杂度等，可判定为高风险。

补偿措施：

1. 应用系统采用多种身份鉴别认证技术的，即使有口令也无法直接登录应用系统的，可酌情降低风险等级；
2. 应用系统为内部管理系统，仅内网访问，访问人员相对可控，且实际用户口令有一定的质量，不易被猜测，可酌情降低风险等级；
3. 应用系统口令校验机制不完善，如只有部分校验机制，可根据实际情况，酌情降低风险等级；
4. 特定应用场景中的口令（如PIN码、电话银行系统查询密码等）可根据相关要求和行业特点，酌情判断风险等级；
5. 针对部分专用软件（如PLC管理软件）、老旧系统等无法添加口令复杂度校验功能，在管理制度中明确口令复杂度及更换周期要求，并定期检查制度执行情况或采取登录地址限制等控制措施，可酌情降低风险等级

整改建议：建议应用系统对用户的账户口令长度、复杂度进行校验，如要求系统账户口令至少8位，由数字、字母或特殊字符中2种方式组成；对于如PIN码等特殊用途的口令，应设置弱口令库，通过对比方式，提高用户口令质量。

2.1.2应用系统存在弱口令

对应要求：应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换。

判例内容：应用系统存在易被猜测的常用/弱口令账户（包括空口令或无身份鉴别机制），可判定为高风险。

补偿措施：

1. 该空口令、弱口令帐号为前台注册用户自行修改，被猜测登录后仅影响单个用户，而不会对整个应用系统造成安全影响的，可酌情降低风险等级；
2. 由于业务场景需要，使用无身份鉴别功能或口令强度达不到要求的专用软件（如部分工控PLC管理软件），可从软件登录方式、物理访问控制、受限使用情况、其他防护措施、管理制度等角度对其进行综合风险分析，酌情判断风险等级。

整改建议：建议应用系统通过口令长度、复杂度校验、常用/弱口令库比对等方式，提高应用系统口令质量。

2.1.3应用系统无登录失败处理机制

对应要求：应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施。

判例内容：可通过互联网登录的应用系统未提供任何登录失败处理措施，攻击者可进行口令猜测，可判定为高风险。

补偿措施：

1. 应用系统采用多种身份鉴别认证技术，可酌情降低风险等级；
2. 登录页面采用图像验证码等技术可在一定程度上提高自动化手段进行口令暴力破解难度，且该技术手段无法被绕过，可视图像验证码的强度，酌情降低风险等级；
3. 根据登录账户的重要程度、影响程度，可酌情判断风险等级。若登录账户涉及到金融行业、个人隐私信息、信息发布、后台管理等，不宜降低风险等级；
4. 针对部分专用软件（如PLC管理软件）、老旧系统等无法添加登录失败处理功能，若采取登录地址限制等技术措施，能够限制或降低暴力破解行为，可酌情降低风险等级。

整改建议：建议应用系统提供登录失败处理功能（如账户锁定、多重认证等），防止攻击者进行口令暴力破解。

2.1.4互联网可访问系统鉴别信息明文传输

对应要求：当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听。

判例内容：通过互联网可访问的应用系统，用户鉴别信息明文传输，可判定为高风险。

补偿措施：

1. 采用多因素身份认证、访问地址限定、仅允许内部可控网络进行访问的措施时，窃听到口令而无法直接进行远程登录的，可酌情降低风险等级；
2. 结合安全通信网络-通信传输中数据传输保密性的相关核查结果，综合判断风险等级。

整改建议：互联网可访问的应用系统，建议用户身份鉴别信息采用加密方式传输，防止鉴别信息在网络传输过程中被窃听。

2.1.5互联网访问系统未实现双因素认证

对应要求：应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。

判例内容：通过互联网方式访问，且涉及大额资金交易、核心业务等操作的系统，在进行重要操作前应采用两种或两种以上方式进行身份鉴别，如只采用一种验证方式进行鉴别，可判定为高风险。

补偿措施：

1. 采用两重用户名/口令认证措施，且两重口令不可相同等情况，可酌情降低风险等级；
2. 在完成重要操作前的不同阶段两次或两次以上使用不同的方式进行身份鉴别，可根据实际情况，酌情降低风险等级；
3. 涉及主管部门认可的业务形态，例如快捷支付、小额免密支付等，可酌情降低风险等级；
4. 根据被测对象中用户的作用以及重要程度，在口令策略和复杂度、长度符合要求的情况下，可根据实际情况，酌情判断风险等级；
5. 系统用户群体为互联网用户，且冒名登录、操作不会对系统或个人造成重大恶劣影响或经济损失的，可酌情判断风险等级。

整改建议：建议应用系统增加除用户名/口令以外的身份鉴别技术，如密码/令牌、生物鉴别方式等，实现双因子身份鉴别，增强身份鉴别的安全力度。

2.2访问控制

2.2.1应用系统身份鉴别机制可被旁路

对应要求：应对登录的用户分配账户和权限。

判例内容：应用系统访问控制功能存在缺失，无法按照设计策略控制用户对系统功能、数据的访问；可通过直接访问URL等方式，在不登录系统的情况下，非授权访问系统功能模块，可判定为高风险。

补偿措施：

1. 应用系统部署在可控网络，有其他防护措施能限制、监控用户行为，可酌情降低风险等级；
2. 根据非授权访问模块的重要程度、越权访问的难度，酌情判断风险等级。

整改建议：建议完善访问控制措施，对系统重要页面、功能模块进行访问控制，确保应用系统不存在访问控制失效情况。

2.2.2应用系统默认口令未修改

对应要求：应重命名或删除默认账户，修改默认账户的默认口令。

判例内容：应用系统默认账号的默认口令未修改，可利用该默认口令登录系统，可判定为高风险。

补偿措施：由于业务场景需要，无法修改专用软件（如部分工控软件）的默认口令，可从设备登录方式、物理访问控制、受限使用情况、其他防护措施、管理制度等角度对其进行综合风险分析，酌情判断风险等级。

整改建议：建议应用系统重命名或删除默认管理员账户，修改默认密码，使其具备一定的强度，增强账户安全性。

2.2.3应用系统访问控制策略可被旁路

对应要求：

（2级）应对登录的用户分配账户和权限。

（3级、4级）应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则。

判例内容：应用系统访问控制策略存在缺陷，可越权访问系统功能模块或查看、操作其他用户的数据。如存在平行权限漏洞，低权限用户越权访问高权限功能模块等，可判定为高风险。

补偿措施：

1. 应用系统部署在可控网络，有其他防护措施能限制、监控用户行为的，可酌情降低风险等级；
2. 根据非授权访问模块的重要程度、越权访问的难度，酌情判断风险等级。

整改建议：建议完善访问控制措施，对系统重要页面、功能模块进行重新进行身份、权限鉴别，确保应用系统不存在访问控制失效情况。

2.3安全审计

2.3.1应用系统完全审计措施

对应要求：应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计。

判例内容：应用系统（包括前端系统和后台管理系统）无任何日志审计功能，无法对用户的重要行为进行审计，也无法对事件进行溯源，可判定为高风险。

补偿措施：

1. 采取其他技术手段对重要的用户行为进行审计、溯源，可根据所记录的日志情况、是否存在漏记/旁路等缺陷，综合分析判断风险等级；
2. 审计记录不全或审计记录有记录，但无直观展示，可根据实际情况，酌情降低风险等级。

整改建议：建议应用系统完善审计模块，对重要用户操作、行为进行日志审计，审计范围不仅针对前端用户的操作、行为，也包括后台管理员的重要操作。

2.3.2应用系统审计记录不满足保护要求

对应要求：应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等。

判例内容：对应用系统的重要业务操作日志、重要安全类日志等保护措施不满足要求，相关日志可被恶意删除、修改或覆盖等情况，日志保存时间不满足法律法规相关要求的，可判定为高风险。

补偿措施：

1. 删除功能只能删除历史日志（超过追溯时效和意义），可根据业务场景及日志信息内容进行综合分析，酌情判断风险等级；
2. 被测系统未上线使用或上线时间不足六个月，应从日志备份策略、日志存储容量等角度进行综合分析当前措施是否能满足日志保存至少六个月的要求，酌情判断风险等级。

整改建议：建议对应用系统重要操作类、安全类等日志进行妥善保存，避免受到未预期的删除、修改或覆盖等，留存时间不少于六个月，符合法律法规的相关要求。

2.4入侵防范

2.4.1应用系统有效校验功能存在缺陷

对应要求：应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求。

判例内容：由于校验机制缺失导致的应用系统存在如SQL注入、跨站脚本、上传漏洞等高危漏洞，可判定为高风险。

补偿措施：

1. 应用系统存在SQL注入、跨站脚本等高危漏洞，但系统部署了WAF、云盾等应用防护产品，在防护体系下无法成功利用，可酌情降低风险等级；
2. 不与互联网交互的内网系统，可根据系统重要程度、漏洞危害情况、内部网络的防护措施等情况，酌情判断风险等级。

整改建议：建议通过修改代码的方式，对数据有效性进行校验，提交应用系统的安全性，防止相关漏洞的出现。

2.4.2应用系统存在可被利用的高危漏洞

对应要求：应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞。

判例内容：应用系统所使用的环境、框架、组件或业务功能等存在可被利用的高危漏洞或严重逻辑缺陷，导致敏感数据泄露、网页篡改、服务器被入侵、绕过安全验证机制非授权访问等安全事件的发生，可能造成严重后果的，可判定为高风险。

补偿措施：不与互联网交互的内网系统，可从内网环境管控、访问控制措施、漏洞影响程度、漏洞利用难度、利用可能性等角度进行综合风险分析，酌情判断风险等级。

整改建议：建议定期对应用系统进行漏洞扫描、渗透测试等技术检测，对可能存在的已知漏洞、逻辑漏洞，在重复测试评估后及时进行修补，降低安全隐患。

2.5数据完整性

2.5.1数据传输无整性保护措施

对应要求：应采用校验技术或密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等。

判例内容参见安全通信网络-通信传输

2.6数据保密性

2.6.1重要数据明文传输

对应要求：应采用密码技术保证重要数据在传输过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等。

2.6.2重要数据无存储保密性保护

对应要求：应采用密码技术保证重要数据在存储过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等。

判例内容：鉴别信息、个人敏感信息、行业主管部门定义的非明文存储类信息等以明文方式存储，且未采取其他有效保护措施，可判定为高风险。

补偿措施：对存储的敏感信息采取严格的访问限制措施、部署数据库防火墙、数据防泄露产品等安全防护措施的，可通过分析造成信息泄露的难度和影响程度，酌情判断风险等级。

整改建议：采用密码技术保证重要数据在存储过程中的保密性，且相关密码技术符合国家密码管理主管部门的规定。

2.7数据备份恢复

2.7.1数据备份措施缺失

对应要求：应提供重要数据的本地数据备份与恢复功能。

判例内容：应用系统未提供任何重要数据备份措施，一旦遭受数据破坏，无法进行数据恢复，可判定为高风险。

整改建议：建议建立备份恢复机制，定期对重要数据进行备份以及恢复测试，确保在出现数据破坏时，可利用备份数据进行恢复。

2.7.2异地备份措施缺失

对应要求：应提供异地实时备份功能，利用通信网络将重要数据实时备份至备份场地。

判例内容：对系统、数据容灾要求较高的系统，如金融、医疗卫生、社会保障等行业系统，如无异地数据灾备措施，或异地备份机制无法满足业务需要，可判定为高风险。

补偿措施：

1. 系统数据备份机制存在一定时间差，若被测单位评估可接受时间差内数据丢失，可酌情降低风险等级；
2. 可根据系统容灾要求及行业主管部门相关要求，根据实际情况酌情判断风险等级。

整改建议：建议设置异地灾备机房，并利用通信网络将重要数据实时备份至备份场地；灾备机房的距离应满足行业主管部门的相关要求（例如金融行业应符合JR/T 0071的相关要求）。

2.7.3数据处理系统无冗余措施

对应要求：应提供重要数据处理系统的热冗余，保证系统的高可用性。

判例内容：对数据处理可用性要求较高系统（如金融行业系统、竞拍系统、大数据平台等），应采用热冗余技术提高系统的可用性，若核心处理节点（如服务器、数据库等）存在单点故障，可判定为高风险。

补偿措施：当前采取的恢复手段，能确保被测单位评估的RTO在可接受范围内，可根据实际情况酌情降低风险等级。

整改建议：建议对重要数据处理系统采用热冗余技术，提高系统的可用性。

2.7.4未建立异地灾难备份中心

对应要求：应建立异地灾难备份中心，提供业务应用的实时切换。

判例内容：对容灾、可用性要求较高的系统，未设立异地应用级容灾中心，或异地应用级容灾中心无法实现业务切换，可判定为高风险。

补偿措施：当前采取的恢复手段，能确保被测单位评估的RTO在可接受范围内，可根据实际情况酌情降低风险等级。

整改建议：建议建立异地灾备中心，通过技术手段实现业务应用的实时切换，提高系统的可用性。

2.8剩余信息保护

2.8.1鉴别信息释放措施失效

对应要求：应保证鉴别信息所在的存储空间被释放或重新分配前得到完全清除。

判例内容：身份鉴别信息释放或清除机制存在缺陷，如在正常进行释放或清除身份鉴别信息操作后，仍可非授权访问系统资源或进行操作，可判定为高风险。

补偿措施：系统采取技术手段，能消除或降低非授权访问系统资源或进行操作所带来的影响，可根据实际情况，酌情判断风险等级。

整改建议：建议完善鉴别信息释放/清除机制，确保在执行释放/清除相关操作后，鉴别信息得到完全释放/清除。

2.8.2敏感数据释放措施失效

对应要求：应保证存有敏感数据的存储空间被释放或重新分配前得到完全清除。

判例内容：敏感数据（如个人敏感信息、业务敏感信息等）释放或清除机制存在缺陷，如在正常进行释放或清除操作后，仍可非授权访问这些敏感数据，且可能造成敏感数据泄露的，可判定为高风险。

补偿措施：因特殊业务需要，需要在存储空间保留敏感数据，相关敏感数据进行了有效加密/脱敏处理，且有必要的提示信息，可根据实际情况，酌情降低风险等级。

整改建议：建议完善敏感数据释放/清除机制，确保在执行释放/清除相关操作后，敏感数据得到完全释放/清除。

2.9个人信息保护

2.9.1违规采集，存储个人信息

对应要求：应仅采集和保存业务必需的用户个人信息。

判例内容：在采集和保存用户个人信息时，应通过正式渠道获得用户同意、授权，如在未授权情况下，采取、存储用户个人隐私信息，可判定为高风险。

补偿措施：在用户同意、授权的情况下，采集和保存与业务有关但非必需的用户个人信息，且用户可根据需要关闭或停止授权的，可根据实际情况，酌情判断风险等级。

整改建议：建议根据国家、行业主管部门以及标准的相关规定（如《信息安全技术 个人信息安全规范》），明确向用户表明采集信息的内容、用途以及相关的安全责任，并在用户同意、授权的情况下采集、保存业务必需的用户个人信息。

2.9.2非授权访问，使用个人信息

对应要求：应禁止未授权访问和非法使用用户个人信息。

判例内容：个人信息可非授权访问或未按国家、行业主管部门以及标准的相关规定使用个人信息，例如在未授权情况下将用户信息提交给第三方处理，未脱敏的情况下用于其他业务用途，未严格控制个人信息查询以及导出权限，非法买卖、泄露用户个人信息等，可判定为高风险。

整改建议：建议根据国家、行业主管部门以及标准的相关规定（如《信息安全技术 个人信息安全规范》），通过技术和管理手段，防止未授权访问和非法使用用户个人信息。

2.10数据完整性和保密性

2.10.1云服务客户数据，用户个人信息违规出境

对应要求：应确保云服务客户数据、用户个人信息等存储于中国境内，如需出境应遵循国家相关规定。

判例内容：云服务客户数据、用户个人信息等境外存储，且未遵循国家相关规定，可判定为高风险。

整改建议：建议云服务客户数据、用户个人信息等存储于中国境内，如需出境应遵循国家相关规定[1]。