2.1.1 口令策略
对应要求：应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换。
判例内容：应用系统无任何用户口令复杂度校验机制，校验机制包括口令的长度、复杂度等，可判定为高风险。
适用范围：所有系统。
满足条件（同时）：
1、应用系统无口令长度、复杂度校验机制；
2、可设置6位以下，单个数字或连续数字或相同数字等易猜测的口令。
补偿措施：
1、如应用系统采用多种身份鉴别认证技术的，即使有口令也无法直接登录应用系统的，可酌情降低风险等级。
2、如应用系统仅为内部管理系统，只能内网访问，且访问人员相对可控，可酌情降低风险等级。
3、如应用系统口令校验机制不完善，如只有部分校验机制，可根据实际情况，酌情降低风险等级。
4、特定应用场景中的口令（如PIN码）可根据相关要求，酌情判断风险等级。
整改建议：建议应用系统对用户的账户口令长度、复杂度进行校验，如要求系统账户口令至少8位，由数字、字母或特殊字符中2种方式组成；对于如PIN码等特殊用途的口令，应设置弱口令库，通过对比方式，提高用户口令质量。
2.1.2 应用系统弱口令
对应要求：应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换。
判例内容：网络设备、安全设备、操作系统、数据库等存在空口令或弱口令帐户，并可通过该弱口令帐户登录，可判定为高风险。
适用范围：所有系统。
满足条件（同时）：
1、存在空口令或弱口令帐户；
2、可使用该弱口令帐户登录。
补偿措施：
1、如采用双因素认证等管控手段，恶意用户使用该空/弱口令账号无法直接登录相关设备，可酌情降低风险等级。
2、如测评对象重要性较低，不会对整个信息系统安全性产生任何影响，可酌情降低风险等级。
整改建议：建议删除或修改账户口令，制定相关管理制度，规范口令的最小长度、复杂度与生命周期，并根据管理制度要求，合理配置账户口令策略，提高口令质量。
2.1.3 登录失败处理
对应要求：应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施。
判例内容：可通过互联网登录的应用系统未提供任何登录失败处理措施，攻击者可进行口令猜测，可判定为高风险。
适用范围：3级及以上系统。
满足条件：
1、3级及以上系统；
2、可通过互联网登录，且对账号安全性要求较高，如帐户涉及金融、个人隐私信息、后台管理等；
3、对连续登录失败无任何处理措施；
4、攻击者可利用登录界面进行口令猜测。
补偿措施：
1、如应用系统采用多种身份鉴别认证技术的，可酌情降低风险等级。
2、仅通过内部网络访问的内部/后台管理系统，如访问人员相对可控，可酌情降低风险等级。
3、如登录页面采用图像验证码等技术可在一定程度上提高自动化手段进行口令暴力破解难度的，可酌情降低风险等级。
4、可根据登录帐户的重要程度、影响程度，可酌情判断风险等级。但如果登录帐户涉及到金融行业、个人隐私信息、信息发布、后台管理等，不宜降低风险等级。
整改建议：建议应用系统提供登录失败处理功能（如帐户锁定、多重认证等），防止攻击者进行口令暴力破解。
2.1.4 双因素认证
对应要求：应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。
判例内容：通过互联网方式访问，且涉及大额资金交易、核心业务等操作的系统，在进行重要操作前应采用两种或两种以上方式进行身份鉴别，如只采用一种验证方式进行鉴别，可判定为高风险。
适用范围：3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、通过互联网方式访问的系统，在进行涉及大额资金交易、核心业务等重要操作前未启用两种或两种以上鉴别技术对用户身份进行鉴别；4级系统多种鉴别技术中未用到密码技术或生物技术。
补偿措施：
1、采用两重用户名/口令认证措施，且两重口令不可相同等情况，可酌情降低风险等级。
2、如应用服务访问的网络环境安全可控，网络窃听、违规接入等隐患较小，口令策略和复杂度、长度符合要求的情况下，可酌情降低风险等级。
3、在完成重要操作前的不同阶段两次或两次以上使用不同的方式进行身份鉴别，可根据实际情况，酌情降低风险等级。
4、涉及到主管部门认可的业务形态，例如快捷支付、小额免密支付等，可酌情降低风险等级。
5、可根据被测对象中用户的作用以及重要程度，在口令策略和复杂度、长度符合要求的情况下，可根据实际情况，酌情判断风险等级。
6、系统用户群体为互联网用户，且冒名登录、操作不会对系统或个人造成重大恶劣影响或经济损失的，可酌情判断风险等级。
整改建议：建议应用系统增加除用户名/口令以外的身份鉴别技术，如密码/令牌、生物鉴别方式等，实现双因子身份鉴别，增强身份鉴别的安全力度。
2.2.1 登录模块权限控制
对应要求：应对登录的用户分配账户和权限。
判例内容：应用系统访问控制功能存在缺失，无法按照设计策略控制用户对系统功能、数据的访问；可通过直接访问URL等方式，在不登录系统的情况下，非授权访问系统功能模块，可判定为高风险。
适用范围：所有系统。
满足条件：可通过直接访问URL等方式，在不登录系统的情况下，非授权访问系统重要功能模块。
补偿措施：
1、如应用系统部署在可控网络，有其他防护措施能限制、监控用户行为的，可酌情降低风险等级。
2、可根据非授权访问模块的重要程度、越权访问的难度，酌情提高/减低风险等级。
整改建议：建议完善访问控制措施，对系统重要页面、功能模块进行访问控制，确保应用系统不存在访问控制失效情况。
2.2.2 默认口令处理
对应要求：应重命名或删除默认账户，修改默认账户的默认口令。
判例内容：应用系统默认账号的默认口令未修改，可利用该默认口令登录系统，可判定为高风险。
适用范围：所有系统。
满足条件（同时）：
1、未修改默认帐户的默认口令；
2、可使用该默认口令账号登录。
补偿措施：无。
整改建议：建议应用系统重命名或删除默认管理员账户，修改默认密码，使其具备一定的强度，增强账户安全性。
2.2.3 访问控制策略
对应要求：应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则。
判例内容：应用系统访问控制策略存在缺陷，可越权访问系统功能模块或查看、操作其他用户的数据。如存在平行权限漏洞，低权限用户越权访问高权限功能模块等，可判定为高风险。
适用范围：所有系统。
满足条件：系统访问控制策略存在缺陷，可越权访问系统功能模块或查看、操作其他用户的数据。如存在平行权限漏洞，低权限用户越权访问高权限功能模块等。
补偿措施：
1、如应用系统部署在可控网络，有其他防护措施能限制、监控用户行为的，可酌情降低风险等级。
2、可根据非授权访问模块的重要程度、越权访问的难度，酌情提高/减低风险等级。
整改建议：建议完善访问控制措施，对系统重要页面、功能模块进行重新进行身份、权限鉴别，确保应用系统不存在访问控制失效情况。
2.3.1 安全审计措施
对应要求：应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计。
判例内容：应用系统（包括前端系统和后台管理系统）无任何日志审计功能，无法对用户的重要行为进行审计，也无法对事件进行溯源，可判定为高风险。
适用范围：3级及以上系统。
满足条件（同时）：
1、3级及以上系统
2、应用系统无任何日志审计功能，无法对用户的重要行为进行审计；
3、无其他技术手段对重要的用户行为和重要安全事件进行溯源。
补偿措施：
1、如有其他技术手段对重要的用户行为进行审计、溯源，可酌情降低风险等级。
2、如审计记录不全或审计记录有记录，但无直观展示，可根据实际情况，酌情降低风险等级。
整改建议：建议应用系统完善审计模块，对重要用户操作、行为进行日志审计，审计范围不仅针对前端用户的操作、行为，也包括后台管理员的重要操作。
2.4.1 数据有效性检验功能
对应要求：应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求。
判例内容：由于校验机制缺失导致的应用系统存在如SQL注入、跨站脚本、上传漏洞等高风险漏洞，可判定为高风险。
适用范围：所有系统。
满足条件：
1、应用系统存在如SQL注入、跨站脚本、上传漏洞等可能导致敏感数据泄露、网页篡改、服务器被入侵等安全事件的发生，造成严重后果的高风险漏洞；
2、无其他技术手段对该漏洞进行防范。
补偿措施：
1、如应用系统存在SQL注入、跨站脚本等高风险漏洞，但是系统部署了WAF、云盾等应用防护产品，在防护体系下无法成功利用，可酌情降低风险等级。
2、不与互联网交互的内网系统，可根据系统重要程度、漏洞危害情况等，酌情判断风险等级。
整改建议：建议通过修改代码的方式，对数据有效性进行校验，提交应用系统的安全性，防止相关漏洞的出现。
2.4.2 已知重大漏洞修补
对应要求：应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞。
判例内容：应用系统所使用的环境、框架、组件等存在可被利用的高风险漏洞，导致敏感数据泄露、网页篡改、服务器被入侵等安全事件的发生，可能造成严重后果的，可判定为高风险。
适用范围：所有系统。
满足条件（同时）：
1、应用系统所使用的环境、框架、组件等存在可被利用的，可能导致敏感数据泄露、网页篡改、服务器被入侵等安全事件的发生，造成严重后果的高风险漏洞；
2、无其他有效技术手段对该漏洞进行防范。
补偿措施：
1、如应用系统使用的环境、框架、组件等存在高风险漏洞，但是系统部署了WAF、云盾等应用防护产品，在防护体系下无法成功利用，可酌情降低风险等级。
2、不与互联网交互的内网系统，可通过分析内网环境对相关漏洞的影响、危害以及利用难度，酌情提高/降低风险等级。
整改建议：建议定期对应用系统进行漏洞扫描，对可能存在的已知漏洞，在重复测试评估后及时进行修补，降低安全隐患。
2.4.3 测试发现漏洞修补
对应要求：应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞。
判例内容：如应用系统的业务功能（如密码找回功能等）存在高风险安全漏洞或严重逻辑缺陷，可能导致修改任意用户密码、绕过安全验证机制非授权访问等情况，可判定为高风险。
适用范围：所有系统。
满足条件：通过测试，发现应用系统的业务功能（如密码找回功能等）存在高风险安全漏洞或严重逻辑缺陷，可能导致修改任意用户密码、绕过安全验证机制非授权访问等情况。
补偿措施：无。
整改建议：建议通过修改应用程序的方式对发现的高风险/严重逻辑缺陷进行修补，避免出现安全隐患。
2.5.1 传输完整性保护
对应要求：应采用密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等。
判例内容：对传输完整性要求较高的系统，如未采取任何措施保障重要数据传输完整性，重要数据在传输过程中被篡改可能造成严重后果的，可判定为高风险。
适用范围：对数据传输完整性要求较高的3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、未对传输的重要数据进行完整性保护；
3、通过中间人劫持等攻击技术修改传输数据，可能对系统造成重大安全影响。
补偿措施：
1、如通过技术手段确保无法对传输数据进行修改，可酌情降低风险等级。
2、可根据传输数据的重要程度、传输数据篡改的难度、篡改后造成的影响等情况，酌情提高/降低风险等级。
整改建议：建议在应用层通过密码技术确保传输数据的完整性，并在服务器端对数据有效性进行校验，确保只处理未经修改的数据。
2.6.1 传输保密性保护
对应要求：应采用密码技术保证重要数据在传输过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等。
判例内容：用户鉴别信息、公民敏感信息数据或重要业务数据等以明文方式在不可控网络中传输，可判定为高风险。
适用范围：3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、用户身份认证信息、个人敏感信息数据或重要业务数据等以明文方式在不可控网络中传输。
补偿措施：
1、如使用网络加密的技术确保数据在加密通道中传输，可根据实际情况，视为等效措施，判为符合。
2、如敏感信息在可控网络中传输，网络窃听等风险较低，可酌情降低风险等级。
整改建议：建议采用密码技术确保重要数据在传输过程中的保密性。
2.6.2 存储保密性保护
对应要求：应采用密码技术保证重要数据在存储过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等。
判例内容：用户身份认证信息、个人敏感信息数据、重要业务数据、行业主管部门定义的非明文存储类数据等以明文方式存储，且无其他有效保护措施，可判定为高风险。
适用范围：所有系统。
满足条件（同时）：
1、用户身份认证信息、个人敏感信息数据、重要业务数据、行业主管部门定义的非明文存储类数据等以明文方式存储；
2、无其他有效数据保护措施。
补偿措施：如采取区域隔离、部署数据库安全审计等安全防护措施的，可通过分析造成信息泄露的难度和影响程度，酌情降低风险等级。
整改建议：采用密码技术保证重要数据在存储过程中的保密性。
2.7.1 数据备份措施
对应要求：应提供重要数据的本地数据备份与恢复功能。
判例内容：应用系统未提供任何数据备份措施，一旦遭受数据破坏，无法进行数据恢复的，可判定为高风险。
适用范围：所有系统。
满足条件：应用系统未提供任何数据备份措施，一旦遭受数据破坏，无法进行数据恢复。
补偿措施：无。
整改建议：建议建立备份恢复机制，定期对重要数据进行备份以及恢复测试，确保在出现数据破坏时，可利用备份数据进行恢复。
2.7.2 异地备份措施
对应要求：应提供异地实时备份功能，利用通信网络将重要数据实时备份至备份场地。
判例内容：对系统、数据容灾要求较高的系统，如金融、医疗卫生、社会保障等行业系统，如无异地数据灾备措施，或异地备份机制无法满足业务需要，可判定为高风险。
适用范围：对系统、数据容灾要求较高的3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、对容灾要求较高的系统；
3、系统无异地数据备份措施，或异地备份机制无法满足业务需要。
补偿措施：
1、一般来说同城异地机房直接距离不低于为30公里，跨省市异地机房直线距离不低于100公里，如距离上不达标，可酌情降低风险等级。
2、系统数据备份机制存在一定时间差，若被测单位评估可接受时间差内数据丢失，可酌情降低风险等级。
3、可根据系统容灾要求及行业主管部门相关要求，根据实际情况酌情提高/减低风险等级。
整改建议：建议设置异地灾备机房，并利用通信网络将重要数据实时备份至备份场地。
2.7.3 数据处理冗余措施
对应要求：应提供重要数据处理系统的热冗余，保证系统的高可用性。
判例内容：对数据处理可用性要求较高系统（如金融行业系统、竞拍系统、大数据平台等），应采用热冗余技术提高系统的可用性，若核心处理节点（如服务器、DB等）存在单点故障，可判定为高风险。
适用范围：对数据处理可用性要求较高的3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、对数据处理可用性要求较高系统；
3、处理重要数据的设备（如服务器、DB等）未采用热冗余技术，发生故障可能导致系统停止运行。
补偿措施：如当前采取的恢复手段，能够确保被测单位评估的RTO在可接受范围内，可根据实际情况酌情降低风险等级。
整改建议：建议对重要数据处理系统采用热冗余技术，提高系统的可用性。
2.7.4 异地灾难备份中心
对应要求：应建立异地灾难备份中心，提供业务应用的实时切换。
判例内容：对容灾、可用性要求较高的系统，如金融行业系统，如未设立异地应用级容灾中心，或异地应用级容灾中心无法实现业务切换，可判定为高风险。
适用范围：对容灾、可用性要求较高的4级系统。
满足条件（同时）：
1、4级系统；
2、对容灾、可用性要求较高的系统；
3、未设立异地应用级容灾中心，或异地应用级容灾中心无法实现业务切换。
补偿措施：如当前采取的恢复手段，能够确保被测单位评估的RTO在可接受范围内，可根据实际情况酌情降低风险等级。
整改建议：建议对重要数据处理系统采用热冗余技术，提高系统的可用性。
2.8.1 鉴别信息释放措施
对应要求：应保证鉴别信息所在的存储空间被释放或重新分配前得到完全清除。
判例内容：身份鉴别信息释放或清除机制存在缺陷，如在正常进行释放或清除身份鉴别信息操作后，仍可非授权访问系统资源或进行操作，可判定为高风险。
适用范围：所有系统。
满足条件（同时）：
1、身份鉴别信息释放或清除机制存在缺陷；
2、利用剩余鉴别信息，可非授权访问系统资源或进行操作。
补偿措施：无。
整改建议：建议完善鉴别信息释放/清除机制，确保在执行释放/清除相关操作后，鉴别信息得到完全释放/清除。
2.8.2 敏感数据释放措施
对应要求：应保证存有敏感数据的存储空间被释放或重新分配前得到完全清除。
判例内容：身份鉴别信息释放或清除机制存在缺陷，如在正常进行释放或清除身份鉴别信息操作后，仍可非授权访问系统资源或进行操作，可判定为高风险。
适用范围：3级及以上系统。
满足条件（同时）：
1、3级及以上系统；
2、敏感数据释放或清除机制存在缺陷；
3、利用剩余信息，可非授权获得相关敏感数据。
补偿措施：如因特殊业务需要，需要在存储空间保留敏感数据，相关敏感数据进行了有效加密/脱敏处理的，且有必要的提示信息，可根据实际情况，酌情降低风险等级。
整改建议：建议完善敏感数据释放/清除机制，确保在执行释放/清除相关操作后，敏感数据得到完全释放/清除。
2.9.1 个人信息采集、存储
对应要求：应仅采集和保存业务必需的用户个人信息。
判例内容：在采集和保存用户个人信息时，应通过正式渠道获得用户同意、授权，如在未授权情况下，采取、存储用户个人隐私信息，可判定为高风险。
适用范围：所有系统。
满足条件（任意条件）：
1、在未授权情况下，采取、存储用户个人隐私信息，无论该信息是否是业务需要。
2、采集、保存法律法规、主管部门严令禁止采集、保存的用户隐私信息。
补偿措施：如在用户同意、授权的情况下，采集和保存业务非必需的用户个人信息，可根据实际情况，酌情提高/降低风险等级。
整改建议：建议通过官方正式渠道向用户表明采集信息的内容、用途以及相关的安全责任，并在用户同意、授权的情况下采集、保存业务必需的用户个人信息。
2.9.2 个人信息访问、使用
对应要求：应禁止未授权访问和非法使用用户个人信息。
判例内容：未授权访问和非法使用个人信息，如在未授权情况下将用户信息提交给第三方处理，未脱敏的情况下用于其他业务用途，未严格控制个人信息查询以及导出权限，非法买卖、泄露用户个人信息等，可判定为高风险。
适用范围：所有系统。
满足条件（任意条件）：
1、在未授权情况下将用户个人信息共享给其他公司、机构、个人（国家、法律规定的公安、司法机构除外）。
2、未脱敏的情况下用于其他非核心业务系统或测试环境等。
3、未严格控制个人信息查询以及导出权限。
4、非法买卖、泄露用户个人信息。
补偿措施：如互联网系统在收集用户的个人敏感信息前，数据收集方明确数据的用途，可能涉及使用数据的单位、机构，权责清晰，并根据各自职责与用户签订个人信息保密协议和个人信息收集声明许可协议的，可根据实际情况酌情降低风险等级。
整改建议：建议通过官方正式渠道向用户表明采集信息的内容、用途以及相关的安全责任，并在用户同意、授权的情况下采集、保存业务必需的用户个人信息，通过技术和管理手段，防止未授权访问和非法使用。
设为首页
