等保知识|测评高风险项详解:安全计算环境

2023-10-19 09:10

本文主要是介绍等保知识|测评高风险项详解:安全计算环境,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

等级保护2.0标准的“安全计算环境涉及网络设备、安全设备、主机设备、数据库、应用系统及数据等方面的安全要求。这些设备、应用系统正是黑客攻击的重点目标,经过分析大量安全事件及攻击手段后不难发现,等级保护2.0标准在身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范等控制点提出的相关安全功能及要求,正是抵御黑客攻击的重要手段。

因此,《高风险判定指引》在“安全计算环境”方面侧重于安全功能的实现,例如:口令策略设置、登录失败处理机制、访问控制措施都是较为基础的安全功能;对三级及以上系统,必须使用双因素身份认证技术的目的是:即使密码被破解的情况下,还有另一种身份鉴别机制提供双重保障,实现“纵深”防御。

此外,随着互联网时代的到来,每个人的信息都呈现“半透明”状态。个人隐私泄漏的背后是违法违规采集和使用个人信息的问题愈演愈烈。笔者在《高风险判定指引》中针对个人信息保护的要求,提出可判高风险的相关场景。

 

 

 

 

《网络安全等级保护测评高风险判定指引》——计算环境篇

 

 

安全计算环境

 

01

网络设备、安全设备、主机设备等

 

 

 

 

1.1   身份鉴别

1.1.1    设备弱口令

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

判例内容:网络设备、安全设备、操作系统、数据库等存在空口令或弱口令帐户,并可通过该弱口令帐户登录,可判定为高风险。

适用范围:所有系统。

满足条件(同时):

1、存在空口令或弱口令帐户;

2、可使用该弱口令帐户登录。

补偿措施:

1、如采用双因素认证等管控手段,恶意用户使用该空/弱口令帐号无法直接登录相关设备,可酌情降低风险等级。

2、如测评对象重要性较低,不会对整个信息系统安全性产生任何影响,可酌情降低风险等级。

整改建议:建议删除或重命名默认账户,制定相关管理制度,规范口令的最小长度、复杂度与生命周期,并根据管理制度要求,合理配置账户口令策略,提高口令质量。

1.1.2    远程管理防护

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

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

适用范围:所有系统。

满足条件(同时)

1、通过不可控网络环境远程进行管理;

2、管理帐户口令以明文方式传输;

3、使用截获的帐号可远程登录。

补偿措施:

1、如整个远程管理过程中,只能使用加密传输通道进行鉴别信息传输的,可视为等效措施,判符合。

2、如采用多因素身份认证、访问地址限定、仅允许内部可控网络进行访问的措施时,窃听到口令而无法直接进行远程登录的,可酌情降低风险等级。

3、如通过其他技术管控手段(如准入控制、桌面管理、行为管理等),降低数据窃听隐患的,可酌情降低风险等级。

4、在有管控措施的情况下,如果默认采用加密进行管理,但同时也开启非加密管理方式,可根据实际管理情况,酌情判断风险等级。

5、可根据被测对象的作用以及重要程度,可根据实际情况,酌情判断风险等级。

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

1.1.3    双因素认证

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

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

适用范围:三级及以上系统。

满足条件(同时):

1、级及以上系统;

2、重要核心设备、操作系统等通过不可控网络环境远程进行管理;

3、设备未启用两种或两种以上鉴别技术对用户身份进行鉴别;4级系统多种鉴别技术中未用到密码技术或生物技术。

补偿措施:

1、如设备通过本地登录方式(非网络方式)维护,本地物理环境可控,可酌情降低风险等级。

2、采用两重用户名/口令认证措施(两重口令不同),例如身份认证服务器、堡垒机等手段,可酌情降低风险等级。

3、如设备所在物理环境、网络环境安全可控,网络窃听、违规接入等隐患较小,口令策略和复杂度、长度符合要求的情况下,可酌情降低风险等级。

4、可根据被测对象的作用以及重要程度,根据实际情况,酌情判断风险等级。

整改建议:建议重要核心设备、操作系统等增加除用户名/口令以外的身份鉴别技术,如密码/令牌、生物鉴别方式等,实现双因子身份鉴别,增强身份鉴别的安全力度。

 

 

1.2   访问控制

1.2.1    默认口令处理

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

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

适用范围:所有系统。

满足条件(同时):

1、未修改默认帐户的默认口令;

2、可使用该默认口令账号登录。

补偿措施:无。

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

 

 

1.3    安全审计

1.3.1    设备安全审计措施

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

判例内容:重要核心网络设备、安全设备、操作系统、数据库等未开启任何审计功能,无法对重要的用户行为和重要安全事件进行审计,也无法对事件进行溯源,可判定为高风险。

适用范围:级及以上系统。

满足条件(同时):

1、级及以上系统

2、重要核心网络设备、安全设备、操作系统、数据库等未开启任何审计功能,无法对重要的用户行为和重要安全事件进行审计;

3、无其他技术手段对重要的用户行为和重要安全事件进行溯源。

补偿措施:

1、如使用堡垒机或其他第三方审计工具进行日志审计,能有效记录用户行为和重要安全事件,可视为等效措施,判符合。

2、如通过其他技术或管理手段能对事件进行溯源的,可酌情降低风险等级。

3、如核查对象非重要核心设备,对整个信息系统影响有限的情况下,可酌情降低风险等级。

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

 

 

1.4    入侵防范

1.4.1    不必要服务处置

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

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

适用范围:所有系统。

满足条件(同时):操作系统上的多余系统服务/默认共享/高危端口存在可被利用的高风险漏洞或重大安全隐患。

补偿措施:如通过其他技术手段能降低漏洞影响,可酌情降低风险等级。

整改建议:建议网络设备、安全设备、操作系统等关闭不必要的服务和端口,减少后门等安全漏洞;根据自身应用需求,需要开启共享服务的,应合理设置相关配置,如设置账户权限等。

1.4.2    管理终端管控措施

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

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

适用范围:级及以上系统。

满足条件(同时):

1、级及以上系统;

2、可通过不可控网络环境远程进行管理;

3、未采取技术手段对管理终端进行管控(管控措施包括但不限于终端接入管控、网络地址范围限制、堡垒机等)。

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

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

1.4.3    已知重大漏洞修补

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

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

适用范围:所有系统。

满足条件(同时):

1、该设备可通过互联网访问;

2、该设备型号、版本存在外界披露的重大安全漏洞;

3、未及时采取修补或其他有效防范措施。

补偿措施:

1、如相关漏洞暴露在可控的网络环境,可酌情降低风险等级。

2、如某网络设备的WEB管理界面存在高风险漏洞,而该WEB管理界面只能通过特定IP或特定可控环境下才可访问,可酌情降低风险等级。

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

1.4.4    测试发现漏洞修补

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

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

适用范围:所有系统。

满足条件(同时):

1、存在可被利用的高风险漏洞;

2、通过验证测试或渗透测试确认该高风险漏洞可能对该设备造成重大安全隐患。

补偿措施:只有在相关设备所在的物理、网络、管理环境严格受控,发生攻击行为可能性较小的情况下,方可酌情降低风险等级;对于互联网可访问到的设备,原则上不宜降低其风险等级。

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

 

 

1.5    恶意代码防范

1.5.1    操作系统恶意代码防范

对应要求:应采用主动免疫可信验证机制及时识别入侵和病毒行为,并将其有效阻断。

判例内容:Windows操作系统未安装防恶意代码软件,并进行统一管理,无法防止来自外部的恶意攻击或系统漏洞带来的危害,可判定为高风险。

适用范围:所有系统。

满足条件(任意条件):

1、如一个月以上未更新,但有完备的补丁更新/测试计划,且有历史计划执行记录的,可根据服务器部署环境、行业或系统特性酌情降低风险等级。

2、可与网络安全部分中的入侵防范和访问控制措施相结合来综合评定风险,如网络层部署了恶意代码防范设备,可酌情降低风险等级。

3、对与外网完全物理隔离的系统,其网络环境、USB介质等管控措施较好,可酌情降低风险等级。

整改建议:建议操作系统统一部署防病毒软件,或采用集成性质防病毒服务器或虚拟化底层防病毒措施,并及时更新病毒库,抵挡外部恶意代码攻击。

 

 

02

应用系统

 

 

 

2.1    身份鉴别

2.1.1    口令策略

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

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

适用范围:所有系统。

满足条件(同时):

1、应用系统无口令长度、复杂度校验机制;

2、可设置6位以下,单个数字或连续数字或相同数字等易猜测的口令。

补偿措施:

1、如应用系统采用多种身份鉴别认证技术的,即使有口令也无法直接登录应用系统的,可酌情降低风险等级。

2、如应用系统仅为内部管理系统,只能内网访问,且访问人员相对可控,可酌情降低风险等级。

3、如应用系统口令校验机制不完善,如只有部分校验机制,可根据实际情况,酌情降低风险等级。

4、特定应用场景中的口令(如PIN码)可根据相关要求,酌情判断风险等级。

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

2.1.2    应用系统弱口令

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

判例内容:网络设备、安全设备、操作系统、数据库等存在空口令或弱口令帐户,并可通过该弱口令帐户登录,可判定为高风险。

适用范围:所有系统。

满足条件(同时):

1、存在空口令或弱口令帐户;

2、可使用该弱口令帐户登录。

补偿措施:

1、如采用双因素认证等管控手段,恶意用户使用该空/弱口令帐号无法直接登录相关设备,可酌情降低风险等级。

2、如测评对象重要性较低,不会对整个信息系统安全性产生任何影响,可酌情降低风险等级。

整改建议:建议删除或修改账户口令,制定相关管理制度,规范口令的最小长度、复杂度与生命周期,并根据管理制度要求,合理配置账户口令策略,提高口令质量。

2.1.3    登录失败处理

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

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

适用范围:级及以上系统。

满足条件:

1、级及以上系统;

2、可通过互联网登录,且对帐号安全性要求较高,如帐户涉及金融、个人隐私信息、后台管理等;

3、对连续登录失败无任何处理措施;

4、攻击者可利用登录界面进行口令猜测。

补偿措施:

1、如应用系统采用多种身份鉴别认证技术的,可酌情降低风险等级。

2、仅通过内部网络访问的内部/后台管理系统,如访问人员相对可控,可酌情降低风险等级。

3、如登录页面采用图像验证码等技术可在一定程度上提高自动化手段进行口令暴力破解难度的,可酌情降低风险等级。

4、可根据登录帐户的重要程度、影响程度,可酌情判断风险等级。但如果登录帐户涉及到金融行业、个人隐私信息、信息发布、后台管理等,不宜降低风险等级。

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

2.1.4    双因素认证

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

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

适用范围:级及以上系统。

满足条件(同时):

1、级及以上系统;

2、通过互联网方式访问的系统,在进行涉及大额资金交易、核心业务等重要操作前未启用两种或两种以上鉴别技术对用户身份进行鉴别;4级系统多种鉴别技术中未用到密码技术或生物技术。

补偿措施:

1、采用两重用户名/口令认证措施,且两重口令不可相同等情况,可酌情降低风险等级。

2、如应用服务访问的网络环境安全可控,网络窃听、违规接入等隐患较小,口令策略和复杂度、长度符合要求的情况下,可酌情降低风险等级。

3、在完成重要操作前的不同阶段两次或两次以上使用不同的方式进行身份鉴别,可根据实际情况,酌情降低风险等级。

4、涉及到主管部门认可的业务形态,例如快捷支付、小额免密支付等,可酌情降低风险等级。

5、可根据被测对象中用户的作用以及重要程度,在口令策略和复杂度、长度符合要求的情况下,可根据实际情况,酌情判断风险等级。

6、系统用户群体为互联网用户,且冒名登录、操作不会对系统或个人造成重大恶劣影响或经济损失的,可酌情判断风险等级。

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

 

 

2.2    访问控制

2.2.1    登录模块权限控制

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

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

适用范围:所有系统。

满足条件:可通过直接访问URL等方式,在不登录系统的情况下,非授权访问系统重要功能模块。

补偿措施:

1、如应用系统部署在可控网络,有其他防护措施能限制、监控用户行为的,可酌情降低风险等级。

2、可根据非授权访问模块的重要程度、越权访问的难度,酌情提高/减低风险等级。

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

2.2.2    默认口令处理

对应要求:应重命名或删除默认账户,修改默认账户的默认口令。
判例内容:应用系统默认账号的默认口令未修改,可利用该默认口令登录系统,可判定为高风险。

适用范围:所有系统。

满足条件(同时):

1、未修改默认帐户的默认口令;

2、可使用该默认口令账号登录。

补偿措施:无。

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

2.2.3    访问控制策略

对应要求:应由授权主体配置访问控制策略,访问控制策略规定主体对客体的访问规则。

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

适用范围:所有系统。

满足条件:系统访问控制策略存在缺陷,可越权访问系统功能模块或查看、操作其他用户的数据。如存在平行权限漏洞,低权限用户越权访问高权限功能模块等。

补偿措施:

1、如应用系统部署在可控网络,有其他防护措施能限制、监控用户行为的,可酌情降低风险等级。

2、可根据非授权访问模块的重要程度、越权访问的难度,酌情提高/减低风险等级。

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

 

 

2.3    安全审计

2.3.1    安全审计措施

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

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

适用范围:级及以上系统。

满足条件(同时):

1、级及以上系统

2、应用系统无任何日志审计功能,无法对用户的重要行为进行审计;

3、无其他技术手段对重要的用户行为和重要安全事件进行溯源。

补偿措施:

1、如有其他技术手段对重要的用户行为进行审计、溯源,可酌情降低风险等级。

2、如审计记录不全或审计记录有记录,但无直观展示,可根据实际情况,酌情降低风险等级。

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

 

 

2.4    入侵防范

2.4.1    数据有效性检验功能

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

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

适用范围:所有系统。

满足条件:

1、应用系统存在如SQL注入、跨站脚本、上传漏洞等可能导致敏感数据泄露、网页篡改、服务器被入侵等安全事件的发生,造成严重后果的高风险漏洞;

2、无其他技术手段对该漏洞进行防范。

补偿措施:

1、如应用系统存在SQL注入、跨站脚本等高风险漏洞,但是系统部署了WAF、云盾等应用防护产品,在防护体系下无法成功利用,可酌情降低风险等级。

2、不与互联网交互的内网系统,可根据系统重要程度、漏洞危害情况等,酌情判断风险等级。

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

2.4.2    已知重大漏洞修补

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

判例内容:应用系统所使用的环境、框架、组件等存在可被利用的高风险漏洞,导致敏感数据泄露、网页篡改、服务器被入侵等安全事件的发生,可能造成严重后果的,可判定为高风险。

适用范围:所有系统。

满足条件(同时):

1、应用系统所使用的环境、框架、组件等存在可被利用的,可能导致敏感数据泄露、网页篡改、服务器被入侵等安全事件的发生,造成严重后果的高风险漏洞;

2、无其他有效技术手段对该漏洞进行防范。

补偿措施:

1、如应用系统使用的环境、框架、组件等存在高风险漏洞,但是系统部署了WAF、云盾等应用防护产品,在防护体系下无法成功利用,可酌情降低风险等级。

2、不与互联网交互的内网系统,可通过分析内网环境对相关漏洞的影响、危害以及利用难度,酌情提高/降低风险等级。

整改建议:建议定期对应用系统进行漏洞扫描,对可能存在的已知漏洞,在重复测试评估后及时进行修补,降低安全隐患。

2.4.3    测试发现漏洞修补

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

判例内容:如应用系统的业务功能(如密码找回功能等)存在高风险安全漏洞或严重逻辑缺陷,可能导致修改任意用户密码、绕过安全验证机制非授权访问等情况,可判定为高风险。

适用范围:所有系统。

满足条件:通过测试,发现应用系统的业务功能(如密码找回功能等)存在高风险安全漏洞或严重逻辑缺陷,可能导致修改任意用户密码、绕过安全验证机制非授权访问等情况。

补偿措施:无。

整改建议:建议通过修改应用程序的方式对发现的高风险/严重逻辑缺陷进行修补,避免出现安全隐患。

 

 

2.5    数据完整性

2.5.1    传输完整性保护

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

判例内容:对传输完整性要求较高的系统,如未采取任何措施保障重要数据传输完整性,重要数据在传输过程中被篡改可能造成严重后果的,可判定为高风险。

适用范围:对数据传输完整性要求较高的3级及以上系统。

满足条件(同时):

1、级及以上系统;

2、未对传输的重要数据进行完整性保护;

3、通过中间人劫持等攻击技术修改传输数据,可能对系统造成重大安全影响。

补偿措施:

1、如通过技术手段确保无法对传输数据进行修改,可酌情降低风险等级。

2、可根据传输数据的重要程度、传输数据篡改的难度、篡改后造成的影响等情况,酌情提高/降低风险等级。

整改建议:建议在应用层通过密码技术确保传输数据的完整性,并在服务器端对数据有效性进行校验,确保只处理未经修改的数据。

 

 

2.6    数据保密性

2.6.1    传输保密性保护

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

判例内容:用户鉴别信息、公民敏感信息数据或重要业务数据等以明文方式在不可控网络中传输,可判定为高风险。

适用范围:级及以上系统。

满足条件(同时):

1、3级及以上系统;

2、用户身份认证信息、个人敏感信息数据或重要业务数据等以明文方式在不可控网络中传输。

补偿措施:

1、如使用网络加密的技术确保数据在加密通道中传输,可根据实际情况,视为等效措施,判为符合。

2、如敏感信息在可控网络中传输,网络窃听等风险较低,可酌情降低风险等级。

整改建议:建议采用密码技术确保重要数据在传输过程中的保密性。

2.6.2    存储保密性保护

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

判例内容:用户身份认证信息、个人敏感信息数据、重要业务数据、行业主管部门定义的非明文存储类数据等以明文方式存储,且无其他有效保护措施,可判定为高风险。

适用范围:所有系统。

满足条件(同时):

1、用户身份认证信息、个人敏感信息数据、重要业务数据、行业主管部门定义的非明文存储类数据等以明文方式存储;

2、无其他有效数据保护措施。

补偿措施:如采取区域隔离、部署数据库安全审计等安全防护措施的,可通过分析造成信息泄露的难度和影响程度,酌情降低风险等级。

整改建议:采用密码技术保证重要数据在存储过程中的保密性。

 

 

2.7    数据备份恢复

2.7.1    数据备份措施

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

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

适用范围:所有系统。

满足条件:应用系统未提供任何数据备份措施,一旦遭受数据破坏,无法进行数据恢复。

补偿措施:无。

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

2.7.2    异地备份措施

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

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

适用范围:对系统、数据容灾要求较高的级及以上系统。

满足条件(同时):

1、级及以上系统;

2、对容灾要求较高的系统;

3、系统无异地数据备份措施,或异地备份机制无法满足业务需要。

补偿措施:

1、一般来说同城异地机房直接距离不低于为30公里,跨省市异地机房直线距离不低于100公里,如距离上不达标,可酌情降低风险等级。

2、系统数据备份机制存在一定时间差,若被测单位评估可接受时间差内数据丢失,可酌情降低风险等级。

3、可根据系统容灾要求及行业主管部门相关要求,根据实际情况酌情提高/减低风险等级。

整改建议:建议设置异地灾备机房,并利用通信网络将重要数据实时备份至备份场地。

2.7.3    数据处理冗余措施

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

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

适用范围:对数据处理可用性要求较高的级及以上系统。

满足条件(同时):

1、级及以上系统;

2、对数据处理可用性要求较高系统;

3、处理重要数据的设备(如服务器、DB等)未采用热冗余技术,发生故障可能导致系统停止运行。

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

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

2.7.4    异地灾难备份中心

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

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

适用范围:对容灾、可用性要求较高的四级系统。

满足条件(同时):

1、四级系统;

2、对容灾、可用性要求较高的系统;

3、未设立异地应用级容灾中心,或异地应用级容灾中心无法实现业务切换。

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

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

 

 

2.8    剩余信息保护

2.8.1    鉴别信息释放措施

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

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

适用范围:所有系统。

满足条件(同时):

1、身份鉴别信息释放或清除机制存在缺陷;

2、利用剩余鉴别信息,可非授权访问系统资源或进行操作。

补偿措施:无。

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

2.8.2    敏感数据释放措施

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

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

适用范围:级及以上系统。

满足条件(同时):

1、级及以上系统;

2、敏感数据释放或清除机制存在缺陷;

3、利用剩余信息,可非授权获得相关敏感数据。

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

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

 

 

2.9    个人信息保护

2.9.1    个人信息采集、存储

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

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

适用范围:所有系统。

满足条件(任意条件):

1、在未授权情况下,采取、存储用户个人隐私信息,无论该信息是否是业务需要。

2、采集、保存法律法规、主管部门严令禁止采集、保存的用户隐私信息。

补偿措施:如在用户同意、授权的情况下,采集和保存业务非必需的用户个人信息,可根据实际情况,酌情提高/降低风险等级。

整改建议:建议通过官方正式渠道向用户表明采集信息的内容、用途以及相关的安全责任,并在用户同意、授权的情况下采集、保存业务必需的用户个人信息。

2.9.2    个人信息访问、使用

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

判例内容:未授权访问和非法使用个人信息,如在未授权情况下将用户信息提交给第三方处理,未脱敏的情况下用于其他业务用途,未严格控制个人信息查询以及导出权限,非法买卖、泄露用户个人信息等,可判定为高风险。

适用范围:所有系统。

满足条件(任意条件):

1、在未授权情况下将用户个人信息共享给其他公司、机构、个人(国家、法律规定的公安、司法机构除外)。

2、未脱敏的情况下用于其他非核心业务系统或测试环境等。

3、未严格控制个人信息查询以及导出权限。

4、非法买卖、泄露用户个人信息。

补偿措施:如互联网系统在收集用户的个人敏感信息前,数据收集方明确数据的用途,可能涉及使用数据的单位、机构,权责清晰,并根据各自职责与用户签订个人信息保密协议和个人信息收集声明许可协议的,可根据实际情况酌情降低风险等级。

整改建议:建议通过官方正式渠道向用户表明采集信息的内容、用途以及相关的安全责任,并在用户同意、授权的情况下采集、保存业务必需的用户个人信息,通过技术和管理手段,防止未授权访问和非法使用。

这篇关于等保知识|测评高风险项详解:安全计算环境的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/238811

相关文章

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

Java架构师知识体认识

源码分析 常用设计模式 Proxy代理模式Factory工厂模式Singleton单例模式Delegate委派模式Strategy策略模式Prototype原型模式Template模板模式 Spring5 beans 接口实例化代理Bean操作 Context Ioc容器设计原理及高级特性Aop设计原理Factorybean与Beanfactory Transaction 声明式事物

OpenHarmony鸿蒙开发( Beta5.0)无感配网详解

1、简介 无感配网是指在设备联网过程中无需输入热点相关账号信息,即可快速实现设备配网,是一种兼顾高效性、可靠性和安全性的配网方式。 2、配网原理 2.1 通信原理 手机和智能设备之间的信息传递,利用特有的NAN协议实现。利用手机和智能设备之间的WiFi 感知订阅、发布能力,实现了数字管家应用和设备之间的发现。在完成设备间的认证和响应后,即可发送相关配网数据。同时还支持与常规Sof

sqlite3 相关知识

WAL 模式 VS 回滚模式 特性WAL 模式回滚模式(Rollback Journal)定义使用写前日志来记录变更。使用回滚日志来记录事务的所有修改。特点更高的并发性和性能;支持多读者和单写者。支持安全的事务回滚,但并发性较低。性能写入性能更好,尤其是读多写少的场景。写操作会造成较大的性能开销,尤其是在事务开始时。写入流程数据首先写入 WAL 文件,然后才从 WAL 刷新到主数据库。数据在开始

客户案例:安全海外中继助力知名家电企业化解海外通邮困境

1、客户背景 广东格兰仕集团有限公司(以下简称“格兰仕”),成立于1978年,是中国家电行业的领军企业之一。作为全球最大的微波炉生产基地,格兰仕拥有多项国际领先的家电制造技术,连续多年位列中国家电出口前列。格兰仕不仅注重业务的全球拓展,更重视业务流程的高效与顺畅,以确保在国际舞台上的竞争力。 2、需求痛点 随着格兰仕全球化战略的深入实施,其海外业务快速增长,电子邮件成为了关键的沟通工具。

安全管理体系化的智慧油站开源了。

AI视频监控平台简介 AI视频监控平台是一款功能强大且简单易用的实时算法视频监控系统。它的愿景是最底层打通各大芯片厂商相互间的壁垒,省去繁琐重复的适配流程,实现芯片、算法、应用的全流程组合,从而大大减少企业级应用约95%的开发成本。用户只需在界面上进行简单的操作,就可以实现全视频的接入及布控。摄像头管理模块用于多种终端设备、智能设备的接入及管理。平台支持包括摄像头等终端感知设备接入,为整个平台提

6.1.数据结构-c/c++堆详解下篇(堆排序,TopK问题)

上篇:6.1.数据结构-c/c++模拟实现堆上篇(向下,上调整算法,建堆,增删数据)-CSDN博客 本章重点 1.使用堆来完成堆排序 2.使用堆解决TopK问题 目录 一.堆排序 1.1 思路 1.2 代码 1.3 简单测试 二.TopK问题 2.1 思路(求最小): 2.2 C语言代码(手写堆) 2.3 C++代码(使用优先级队列 priority_queue)

系统架构师考试学习笔记第三篇——架构设计高级知识(20)通信系统架构设计理论与实践

本章知识考点:         第20课时主要学习通信系统架构设计的理论和工作中的实践。根据新版考试大纲,本课时知识点会涉及案例分析题(25分),而在历年考试中,案例题对该部分内容的考查并不多,虽在综合知识选择题目中经常考查,但分值也不高。本课时内容侧重于对知识点的记忆和理解,按照以往的出题规律,通信系统架构设计基础知识点多来源于教材内的基础网络设备、网络架构和教材外最新时事热点技术。本课时知识

2024网安周今日开幕,亚信安全亮相30城

2024年国家网络安全宣传周今天在广州拉开帷幕。今年网安周继续以“网络安全为人民,网络安全靠人民”为主题。2024年国家网络安全宣传周涵盖了1场开幕式、1场高峰论坛、5个重要活动、15场分论坛/座谈会/闭门会、6个主题日活动和网络安全“六进”活动。亚信安全出席2024年国家网络安全宣传周开幕式和主论坛,并将通过线下宣讲、创意科普、成果展示等多种形式,让广大民众看得懂、记得住安全知识,同时还

K8S(Kubernetes)开源的容器编排平台安装步骤详解

K8S(Kubernetes)是一个开源的容器编排平台,用于自动化部署、扩展和管理容器化应用程序。以下是K8S容器编排平台的安装步骤、使用方式及特点的概述: 安装步骤: 安装Docker:K8S需要基于Docker来运行容器化应用程序。首先要在所有节点上安装Docker引擎。 安装Kubernetes Master:在集群中选择一台主机作为Master节点,安装K8S的控制平面组件,如AP