本帖最后由 gllost 于 2023-8-12 21:28 编辑
7.2.7.3 数据处理冗余措施 对应要求:应提供重要数据处理系统的热冗余,保证系统的高可用性。 判例内容:对数据处理可用性要求较高系统(如金融行业系统、竞拍系统、大数据平台等),应采用热冗余技术提高系统的可用性,若核心处理节点(如服务器、DB等)存在单点故障,可判定为高风险。 适用范围:对数据处理可用性要求较高的3级及以上系统。 满足条件(同时): 1、3级及以上系统; 2、对数据处理可用性要求较高系统; 3、处理重要数据的设备(如服务器、DB等)未采用热冗余技术,发生故障可能导致系统停止运行。 补偿措施:如当前采取的恢复手段,能够确保被测单位评估的RTO在可接受范围内,可根据实际情况酌情降低风险等级。 整改建议:建议对重要数据处理系统采用热冗余技术,提高系统的可用性。 7.2.7.4 异地灾难备份中心 对应要求:应建立异地灾难备份中心,提供业务应用的实时切换。 判例内容:对容灾、可用性要求较高的系统,如金融行业系统,如未设立异地应用级容灾中心,或异地应用级容灾中心无法实现业务切换,可判定为高风险。 适用范围:对容灾、可用性要求较高的4级系统。 满足条件(同时): 1、4级系统; 2、对容灾、可用性要求较高的系统; 3、未设立异地应用级容灾中心,或异地应用级容灾中心无法实现业务切换。 补偿措施:如当前采取的恢复手段,能够确保被测单位评估的RTO在可接受范围内,可根据实际情况酌情降低风险等级。 整改建议:建议对重要数据处理系统采用热冗余技术,提高系统的可用性。 7.2.8 剩余信息保护 7.2.8.1 鉴别信息释放措施 对应要求:应保证鉴别信息所在的存储空间被释放或重新分配前得到完全清除。 判例内容:身份鉴别信息释放或清除机制存在缺陷,如在正常进行释放或清除身份鉴别信息操作后,仍可非授权访问系统资源或进行操作,可判定为高风险。 适用范围:所有系统。 满足条件(同时): 1、身份鉴别信息释放或清除机制存在缺陷; 2、利用剩余鉴别信息,可非授权访问系统资源或进行操作。 补偿措施:无。 整改建议:建议完善鉴别信息释放/清除机制,确保在执行释放/清除相关操作后,鉴别信息得到完全释放/清除。 7.2.8.2 敏感数据释放措施 对应要求:应保证存有敏感数据的存储空间被释放或重新分配前得到完全清除。 判例内容:身份鉴别信息释放或清除机制存在缺陷,如在正常进行释放或清除身份鉴别信息操作后,仍可非授权访问系统资源或进行操作,可判定为高风险。 适用范围:3级及以上系统。 满足条件(同时): 1、3级及以上系统; 2、敏感数据释放或清除机制存在缺陷; 3、利用剩余信息,可非授权获得相关敏感数据。 补偿措施:如因特殊业务需要,需要在存储空间保留敏感数据,相关敏感数据进行了有效加密/脱敏处理的,且有必要的提示信息,可根据实际情况,酌情降低风险等级。 整改建议:建议完善敏感数据释放/清除机制,确保在执行释放/清除相关操作后,敏感数据得到完全释放/清除。 7.2.9 个人信息保护 7.2.9.1 个人信息采集、存储 对应要求:应仅采集和保存业务必需的用户个人信息。 判例内容:在采集和保存用户个人信息时,应通过正式渠道获得用户同意、授权,如在未授权情况下,采取、存储用户个人隐私信息,可判定为高风险。 适用范围:所有系统。 满足条件(任意条件): 1、在未授权情况下,采取、存储用户个人隐私信息,无论该信息是否是业务需要。 2、采集、保存法律法规、主管部门严令禁止采集、保存的用户隐私信息。 补偿措施:如在用户同意、授权的情况下,采集和保存业务非必需的用户个人信息,可根据实际情况,酌情提高/降低风险等级。 整改建议:建议通过官方正式渠道向用户表明采集信息的内容、用途以及相关的安全责任,并在用户同意、授权的情况下采集、保存业务必需的用户个人信息。 7.2.9.2 个人信息访问、使用 对应要求:应禁止未授权访问和非法使用用户个人信息。 判例内容:未授权访问和非法使用个人信息,如在未授权情况下将用户信息提交给第三方处理,未脱敏的情况下用于其他业务用途,未严格控制个人信息查询以及导出权限,非法买卖、泄露用户个人信息等,可判定为高风险。 适用范围:所有系统。 满足条件(任意条件): 1、在未授权情况下将用户个人信息共享给其他公司、机构、个人(国家、法律规定的公安、司法机构除外)。 2、未脱敏的情况下用于其他非核心业务系统或测试环境等。 3、未严格控制个人信息查询以及导出权限。 4、非法买卖、泄露用户个人信息。 补偿措施:如互联网系统在收集用户的个人敏感信息前,数据收集方明确数据的用途,可能涉及使用数据的单位、机构,权责清晰,并根据各自职责与用户签订个人信息保密协议和个人信息收集声明许可协议的,可根据实际情况酌情提降低风险等级。 整改建议:建议通过官方正式渠道向用户表明采集信息的内容、用途以及相关的安全责任,并在用户同意、授权的情况下采集、保存业务必需的用户个人信息,通过技术和管理手段,防止未授权访问和非法使用 8 安全区域边界 8.1 集中管控 8.1.1 运行监控措施 对应要求:应对网络链路、安全设备、网络设备和服务器等的运行状况进行集中监测。 判例内容:对可用性要求较高的系统,若没有任何监测措施,发生故障时难以及时对故障进行定位和处理,可判定为高风险。 适用范围:可用性要求较高的3级及以上系统。 满足条件(同时): 1、3级及以上系统; 2、对可用性要求较高的系统; 3、无任何监控措施,发生故障也无法及时对故障进行定位和处理。 补偿措施:无。 整改建议:建议对网络链路、安全设备、网络设备和服务器等的运行状况进行集中监测。 8.1.2 日志集中收集存储 对应要求:应对分散在各个设备上的审计数据进行收集汇总和集中分析,并保证审计记录的留存时间符合法律法规要求。 判例内容:《网络安全法》要求“采取监测、记录网络运行状态、网络安全事件的技术措施,并按照规定留存相关的网络日志不少于六个月”;因此,如相关设备日志留存不满足法律法规相关要求,可判定为高风险。 适用范围: 3级及以上系统。 满足条件(同时): 1、3级及以上系统; 2、对网络运行状态、网络安全事件等日志的留存不满足法律法规规定的相关要求(不少于六个月)。 补偿措施:对于一些特殊行业或日志时效性短于6个月的,可根据实际情况,可酌情降低风险等级。 整改建议:建议部署日志服务器,统一收集各设备的审计数据,进行集中分析,并根据法律法规的要求留存日志。 8.1.3 安全事件发现处置措施 对应要求:应能对网络中发生的各类安全事件进行识别、报警和分析。 判例内容:未部署相关安全设备,识别网络中发生的安全事件,并对重要安全事件进行报警的,可判定为高风险。 适用范围: 3级及以上系统。 满足条件(同时): 1、3级及以上系统; 2、无法对网络中发生的安全事件(包括但不限于网络攻击事件、恶意代码传播事件等)进行识别、告警和分析。 补偿措施:无。 整改建议:建议部署相关专业防护设备,对网络中发生的各类安全事件进行识别、报警和分析,确保相关安全事件得到及时发现,及时处置。 9 安全管理制度 9.1管理制度 9.1.1 管理制度建设 对应要求:应对安全管理活动中的各类管理内容建立安全管理制度。 判例内容:未建立任何与安全管理活动相关的管理制度或相关管理制度无法适用于当前被测系统的,可判定为高风险。 适用范围:所有系统。 满足条件(任意条件): 1、未建立任何与安全管理活动相关的管理制度。 2、相关管理制度无法适用于当前被测系统。 补偿措施:无。 整改建议:建议按照等级保护的相关要求,建立包括总体方针、安全策略在内的各类与安全管理活动相关的管理制度。 10 安全管理机构 10.1 岗位设置 10.1.1 网络安全领导小组建立 对应要求:应成立指导和管理网络安全工作的委员会或领导小组,其最高领导由单位主管领导担任或授权。 判例内容:未成立指导和管理信息安全工作的委员会或领导小组,或其最高领导不是由单位主管领导委任或授权,可判定为高风险。 适用范围:3级及以上系统。 满足条件(同时): 1、3级及以上系统; 2、未成立指导和管理信息安全工作的委员会或领导小组,或领导小组最高领导不是由单位主管领导委任或授权。 补偿措施:无。 整改建议:建议成立指导和管理网络安全工作的委员会或领导小组,其最高领导由单位主管领导担任或授权。 11 安全建设管理 11.1 产品采购和使用 11.1.1 网络安全产品采购和使用 对应要求:应确保网络安全产品采购和使用符合国家的有关规定。 判例内容:网络关键设备和网络安全专用产品的使用违反国家有关规定,可判定为高风险。 适用范围:所有系统。 满足条件:网络关键设备和网络安全专用产品的使用违反国家有关规定。 补偿措施:无。 整改建议:建议依据国家有关规定,采购和使用网络关键设备和网络安全专用产品。(《网络安全法》第二十三条规定网络关键设备和网络安全专用产品应当按照相关国家标准的强制性要求,由具备资格的机构安全认证合格或者安全检测符合要求后,方可销售或者提供。国家网信部门会同国务院有关部门制定、公布网络关键设备和网络安全专用产品目录,并推动安全认证和安全检测结果互认,避免重复认证、检测。) 11.1.2 密码产品与服务采购和使用 对应要求:应确保密码产品与服务的采购和使用符合国家密码管理主管部门的要求。 判例内容:密码产品与服务的使用违反国家密码管理主管部门的要求,可判定为高风险。 适用范围:所有系统。 满足条件:密码产品与服务的使用违反国家密码管理主管部门的要求。 补偿措施:无。 整改建议:建议依据国家密码管理主管部门的要求,使用密码产品与服务。(如《商用密码产品使用管理规定》等) 11.2 外包软件开发 11.2.1 外包开发代码审计 对应要求:应保证开发单位提供软件源代码,并审查软件中可能存在的后门和隐蔽信道。 判例内容:对于涉及金融、民生、基础设施等重要行业的业务核心系统由外包公司开发,上线前未对外包公司开发的系统进行源代码审查,外包商也无法提供相关安全检测证明,可判定为高风险。 适用范围:涉及金融、民生、基础设施等重要核心领域的3级及以上系统。 满足条件(同时): 1、3级及以上系统; 2、涉及金融、民生、基础设施等重要行业的业务核心系统; 3、被测单位为对外包公司开发的系统进行源代码安全审查; 4、外包公司也无法提供第三方安全检测证明。 补偿措施: 1、开发公司可提供国家认可的第三方机构出具的源代码安全审查报告/证明,可视为等效措施,判符合。 2、可根据系统的用途以及外包开发公司的开发功能的重要性,根据实际情况,酌情提高/减低风险等级。 3、如第三方可提供软件安全性测试证明(非源码审核),可视实际情况,酌情减低风险等级。 4、如被测方通过合同等方式与外包开发公司明确安全责任或采取相关技术手段进行防控的,可视实际情况,酌情降低风险等级。 5、如被测系统建成时间较长,但定期对系统进行安全检测,当前管理制度中明确规定外包开发代码审计的,可根据实际情况,酌情减低风险等级。 整改建议:建议对外包公司开发的核心系统进行源代码审查,检查是否存在后门和隐蔽信道。如没有技术手段进行源码审查的,可聘请第三方专业机构对相关代码进行安全检测。 |