电子社会保障卡.docx
- 文档编号:27061438
- 上传时间:2023-06-26
- 格式:DOCX
- 页数:25
- 大小:30.58KB
电子社会保障卡.docx
《电子社会保障卡.docx》由会员分享,可在线阅读,更多相关《电子社会保障卡.docx(25页珍藏版)》请在冰豆网上搜索。
电子社会保障卡
电子社会保障卡
服务渠道接入安全技术规范
(vl.O)
人力资源和社会保障部信息中心
2020年11月
1范围2
2规范性引用文件2
3术语和定义2
4基本功能安全要求4
5服务渠道安全5
6身份认证安全7
7数据安全8
8通信安全9
9密码算法安全10
10接口安全11
11密钥管理12
12业务处理环境管理13
13服务渠道管理14
本规范由人力资源和社会保障部信息中心提岀。
本规范由人力资源和社会保障部信息中心归口。
本规范起草单位:
人力资源和社会保障部信息中心、金保信社保卡科技有限公司、北京银联金卡科技有限公司。
本规范主要起草人:
李晨星、赵刚、唐淑静、韩晓颖、吕丽娟、景玺、李娜、于斌、潘永成、王思锐、谷梦林、王欣欣、渠韶光、张炼、余沁、张跃、马哲、张永稣、袁晓媛。
电子社会保障卡服务渠道接入安全技术规范
1范围
本规范规泄了电子社会保障卡(以下简称电子社保卡)服务渠道接入的安全技术要求,适用于电子社保卡服务渠道开发、集成、维护、运营过程,可作为电子社保卡服务渠道以及检测机构的技术要求。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。
凡是注日期的引用文件,仅注日期的版本适用于本文件。
凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GBAT22239-2019信息安全技术网络安全等级保护基本要求
3术语和定义
3.1社会保障卡SociaISecurityCard
中华人民共和国社会保障卡,简称社保卡,是由人力资源社会保障部统一规划,各级人力资源社会保障部门联合商业银行而向社会公众发行,主要应用于人力资源社会保障领域社会管理和公共服务的集成电路(IC)卡,并可扩展应用至其他公共服务领域。
3.2全国社保卡服务平台NationalSociaISecurityCardServicePlatform
全国社保卡服务平台为全国社会保障卡身份认iiE与支付结算服务平台的简称。
3.3电子社会保障卡ElectronicSocialSecurityCard
电子社会保障卡,简称电子社保卡,是社保卡线上应用的有效电子凭证,与实体社保卡一一对应,由全国社保卡服务平台统一签发,人力资源社会保障部统一管理。
3.4电子社保卡服务渠道ElectronicSociaISecurityCardServiceChanneI
电子社保卡服务渠道指申请接入全国社保卡服务平台、对外提供电子社保卡签发和应用服务的载体,具体形式有APP、公众号、生活号、小程序等,以下简称服务渠道。
3.5代码混淆CodeObfuscation
指将计算机程序的代码转换成一种功能上等价,但是难于阅读和理解的形式的行为。
3.6加壳Packing
利用压缩、加密等技术保护文件的手段。
3.7逆向工程ReversingEngineering
是一种分析目标系统的过程,其目的是识別岀系统的各个组件以及它们之间的关系,并以其他的形式或在较髙的抽象层次上,重建系统的表征。
3.8动态口令OneTimePassword(OTP)
根据专门的算法生成的不可预测的随机字符组合。
3.9多因素验证Multi-FactorAuthentication
采用两种或两种以上方法组合完成身份认证的方法。
3・10拒绝服务攻击DenialOfService(DoS)
一种使目标机器停止提供服务的攻击手段。
3・11跨站脚本攻击CrossSiteScripting(XSS)
一种网站应用程序的安全漏洞攻击。
3.12SQL注入SQLInjection
利用程序漏洞攻击数据库服务器的方法。
3・13非对称密钥密码算法AsymmetricKeyCryptosystemArithmetic
加密和解密使用不同密钥的密码算法。
3.*14对称密钥SymmetricKey
对称密钥密码算法中使用的密钥。
3・*15非对称密钥AsymmetricKey
非对称密钥密码算法中使用的密钥对。
3.16公钥PublicKey
在菲对称密钥密码算法的加解密变换中所使用的可以公开的密钥。
3.17私钥PrivateKey
在非对称密钥密码算法的加解密变换中所使用的不应公开的密钥。
3・18证书Certificate
连接主体名称和公钥的签名信息。
3・19数字签名DigitalSignature
用以确认电子数拯来源及其完整性的技术。
3・20密钥名称KeyName
电子社保卡服务渠道接入用户斜AccessKey,简称AK。
电子社保卡服务渠逍接入密钥SecurityKey,简称SK。
电子社保卡服务渠道数据密钥DigitalKey,简称DK。
3・21敏感数据SensitiveData
应防止被非法泄谿、修改或破坏的数据,包括:
姓夕八社会保障号码(公民身份号码)、手机号码、地址、银行卡号、电子社保卡卡号、电子社保卡密码、签发号、生物识別信息(人脸相片等)、征信信息、交易信息等。
4基本功能安全要求
4.1注册和身份鉴别功能
服务渠道在注册环节应提供有效的用户注册机制,采用安全的用户注册方式,实现用户实劣制。
服务渠道可以针对不同应用的安全要求,建立多层次的身份认证机制。
使用电子社保卡服务前,服务渠道原则上应对用户身份至少完成不同认证服务方的两种方式认证,具体如下表。
如果未完成,须在用户进入电子社保卡时由全国社保卡服务平台进行不同认证服务方的身份认证。
表1电子社保卡接入前的用户身份认证方式
序号
认证服务方
身份认证方式
1
渠道方
实需认证:
通过了渠道方后台比对姓名、公民身份号码、卡号等一致性的实划认证
2
渠道方
短信验证:
通过了渠道方自建的预留手机号短信验证(不能单独使用)
3
渠道方
实人认证:
通过了渠道方自建的人脸识别实人认证
4
全国社保卡服务平台
实人认证:
通过了渠道方调用全国社保卡服务平台的人脸识别实人认证
3
第三方
(运营商)
运营商手机实名认证:
通过了手机号、运营商登记的公民身份号码两要素一致性匹配的实名认证
6
第三方
(银行)
银行账号四要素认证:
通过了姓需、公民身份号码、银行卡号、银行卡预留手机号(短信验证)的四要素实名认证
4.2登录功能
服务渠道完成用户身份鉴别后,在使用电子社保卡服务前,不建议单独使用手机号加短信验证码方式进行登录,可使用登录密码、人脸识别(手机设备)、指纹密码(手机设备)、电子社保卡授权登录、手势密码等方式登录。
其中,人脸识别(手机设备)、指纹密码(手机设备)、手势密码应由用户主动开通,不应默认开启。
4.3信息展示
服务渠道客户端应提供安全输入控件供个人进行敏感数据的填写。
登录密码、电子社保卡密码、跳转相关第三方的支付密码等,在填写操作时应做屏蔽处理,并禁止截屏、录屏。
姓名、社会保障号码、社保卡卡号、银行卡号、手机号码、地址等敏感数据在查询操作时,应做屏蔽处理,对部分字符进行掩码显示。
如需展示完整信息,应通过额外的身份认证后方可展示。
在宣传演示等录屏操作时,应在视频中对这类信息做全部字符的模糊处理。
4.4身份验证
用户在服务渠逍中通过SDK、API或H5方式使用电子社保卡功能时,如涉及敏感数据操作,或者业务申办操作,应重新调用电子社保卡相关验签接口,不应使用客户端缓存或嵌入服务渠道自己的验证方式进行身份验证。
服务渠道应禁止在虚拟模拟器上运行。
活体检测、人脸相片比对是人脸识别技术必备的两个环肖,在客户端远程服务场景下(即无而对而人工检査),不得绕过活体检测直接进行相片比对。
基于人脸识别技术的活体检测功能应通过摄像头对人脸信息进行采集,应采用有效的技术手段防止摄像头在采集信息时被禁用、绕过或替换。
服务渠道应确保视频、音频的输入来自实时采集的设备终端,不应是提前录制好的视频、音频。
如使用静态人脸相片、提前录制的人脸视频进行客户端的活体检测,不应被通过。
人脸比对用相片应从活体检测视频流中随机取帧比对,不应使用提前存储的相片。
4.5用户退出
服务渠道应确保用户只有在成功登录服务渠道后,方可进入"电子社保卡”进行相关功能操作。
如果用户主动退出服务渠道,或服务渠道认为当前用户登录不再有效,服务渠道应拒绝用户进入“电子社保卡”进行相关功能操作。
5服务渠道安全
5.1系统安全
服务渠道应根据《GB/T22239-2019信息安全技术网络安全等级保护基本要求》,进行整体系统(包括客户端和后台服务端)的等级保护左级、备案和测评。
5.2第三方组件安全(客户端)
服务渠道客户端应避免使用存在已知漏洞的系统组件、第三方组件。
服务渠道客户端在使用第三方组件时,应禁止第三方组件XX收集客户端信息和个人信息。
5.3SDK版本安全(客户端)
服务渠道调用的电子社保卡SDK版本应及时升级,确保为最新版本。
对影响安全的重要版本升级,服务渠道还应在用户使用时做到明确提示和引导升级。
5.4H5页面安全(客户端)
服务渠道客户端在使用电子社保卡H5页而方式实现部分功能时,不应篡改H5页面。
服务渠道服务端的H5页而服务应具有有效的防篡改机制。
5.5会话有效期(客户端)
服务渠道应禁止登录状态长期有效,超过一泄期限(如最长72小时)应强制用户重新登录。
5.6抗攻击能力(客户端)
服务渠道客户端应具备基本的抗攻击能力,包括但不限于抵御静态分析、动态调试等操作。
应对服务渠道客户端代码进行安全保护,包括但不限于代码加壳、代码混淆、检测调试器等手段。
服务渠道客户端安装、启动、更新时应对自身的完整性和真实性进行校验,具备抵御篡改、替换或劫持的能力。
服务渠道客户端使用的安全输入控件应具备抵御一左程度攻击的能力,应具备检测自身是否正在被调试的能力,并采取适当的风控措施,如给予用户风险提示。
5.7抗攻击能力(服务端)
服务渠道服务端的存储和运行环境应为专用的机房,机房应具有电子门禁,控制、鉴别和记录进入的人员。
机房应具有防盗报警系统,或设置有人值守的无死角监控系统。
服务渠道服务端应具有逻辑边界,应采用有效的技术手段对跨越边界的访问进行控制、鉴别和记录。
应采用有效的技术手段校验流入边界的数据的完整性、真实性与合法性,确保流岀边界的数据的完整性和机密性。
服务渠道服务端应探测、阻止并记录XX的访问,包括内部用户和外部用户。
服务渠道服务端安装、启动、更新时应对自身的完整性和貞•实性进行校验,具备抵御篡改、替换或劫持的能力。
应采取技术措施对网络行为进行分析,实现对网络攻击特别是新型网络攻击行为的分析。
当检测到攻击行为时应进行记录、阻止和报警等行为。
5.8环境校验(客户端)
服务渠道客户端启动时应执行自检程序,检查客户端运行时所必须的条件,确保客户端自身和所处运行环境的安全性,在用户知情的情况下能向服务端反馈设备信息等情况。
检查范围包括但不限于:
—一系统未在root环境下运行;
——客户端运行环境可信,包括但不限于系统未越狱、运行环境为非模拟器等:
——设备的网络环境情况未见异常:
——设备的地理位置信息未见异常。
服务渠道应具备采集、存储及向全国社保卡服务平台上送运行环境物理信息(设备型号、MAC.系统版本号、设备的唯一标识、手机运行环境)、地理位置信息的功能,向个人明示并在个人授权同意后实现,以支持电子社保卡的动态风险防控。
5.9下载更新安全(客户端)
当需要远程下载应用时,服务渠逍应采用以下安全防护措施:
——采取有效手段保证客户端传输过程的机密性和客户端的完整性:
——应确保客户端版本有更新时及时提示用户进行升级;
——如果服务渠道有新版本,不应未经用戸允许自动安装新版本;
——使用签名信息嵌入客户端保证安装包的合法性;
——服务渠逍客户端安装过程中,应拥有独立的安装目录,唯一的应用标识符,明确的版本序号,不应篡改、覆盖、删除系统文件和其他软件。
5.10用户个人信息保护
服务渠道在收集、使用用户信息之前,应明示收集、使用信息的目的、方式和范围,公开其收集、使用规则,并取得用戸的授权同意。
服务渠道应根据最小权限原则申请客户端系统权限,并取得用户的授权同意。
在采集用户个人敏感数据前应对采集的用途和必要性进行提醒。
服务渠道对可能发生的信息泄需、损毁、丢失的情况,应明示将承担的法律责任,并能够及时告知受影响的用户和采取补救措施。
未经用户同意,也未做匿夕I化处理,服务渠道不应直接向第三方提供个人信息,包括通过客户端嵌入的第三方代码、插件等方式向第三方提供个人信息。
5.11审计安全
服务渠道应记录一泄时期内(如3个月)所有用户访问日志,以便于进行适当的审计、监控和问题排查。
在完成安装时应开始记录所有用户的访问,并且能将每次活动情况追踪至相应的个人。
服务渠道的日志记录功能应自动启动,也可由用户自行启用。
服务渠道可在安装时或相关指导性文档中告知用户将记录的审计信息,并在客户端卸载时由用户选择淸除或自动淸除该信息。
服务渠道应提供记录日志以重建以下事件,包括但不限于:
——所有用户通过服务渠道存取敏感数据的情况:
——具备管理权限的用户针对服务渠道的所有操作;
——对于审计日志的访问情况;
—一对于审计功能的启停:
——无效的逻辑存取尝试;
——身份识别认证机制的使用情况:
——创建和删除系统级对象的情况;
——签发场景、用户请求签发电子社保卡记录与签发成功失败结果记录;
——电子社保卡独立服务使用记录,如二维码、待遇资格认证、社保查询等服务;
——移动支付应用时的场景、交易时间、交易金额、商户订单号、请求流水号、商户信息(商户号、商户名称)、交易状态、付款方用户信息。
记录内容应包括但不限于:
用户标识符、日期时间、事件类型、成功或失败的指示、事件描述、事件来源,受影响数据、系统组件或资源的身份识别或名称等。
服务渠道应集中管理日志,例如将日志文件定向到统一的服务器,以便于审计。
应通过行业标准日志文件格式存储记录。
注:
如通用日志文件系统(CLFS),Syslog等。
6身份认证安全
6.1基本要求
具有访问权限的使用者应具备唯一的标识,保证对于服务渠道的操作能够被追溯到用户。
服务渠道应使用唯一的标识来鉴别用户,通过后方可允许用户访问应用组件。
6.2生物特征识别
若采用生物特征识别作为验i正要素,应当符合国家相关信息安全管理要求,防I匕非法存储、复制和重放。
6.3图形验证码
若采用图形验证码作为验证的辅助要素,图形验证码应具有使用时间限制并仅能使用一次。
图形验证码应由服务器生成,客户端源文件中不应包含图形验证码文本内容。
图形验证码不应作为独立的身份验证要素。
6.4短信验证码
若采用短信验证码作为验证要素,短信验证码应仅可使用一次,应仅限于在规左时间内使用,短信验证码应具备长度和随机性的要求。
短信验证码所在的短信内容中,应告知用户短信验证码的用途。
对于采用短信验证码的服务渠道,应建立手机号码的谨慎变更机制,不得随意在网上自由多次变更手机号码,可以通过大厅柜台变更,或是网上变更时进行额外的身份认证操作,并进行一泄次数限制(如72小时内最多一次通过网上变更手机号码)。
6.5手势密码
若采用手势密码作为验证要素,手势密码应至少设宜连续不间断的4个点。
若手势密码存储在客户端本地,应加密存储。
6.6双因素认证
除业务规则有特殊规左外,服务渠道应在新设备登录、敏感数据修改、支付交易、密码修改或重置时,提供双因素认证机制,并应确保采用的身份认证要素相互独立,即部分要素的损坏或者泄露不应导致其他要素损坏或者泄露。
6.7密码安全
6.7.1密码复杂度
服务渠道应提供密码复杂度校验功能,保证用户设置的密码达到一左的强度,避免采用简单密码(如:
123456、111111)或与用户个人信息相似度过高的密码(如:
生日信息、公民身份号码或卡号的某段信息)。
6.7.2重置密码
服务渠道应在重置密码之前,通过双因素认证机制进行额外的身份认证操作以确认用户身份。
如果服务渠逍为每位新用户设泄了初始密码,则应确保在首次登录后立即进行变更。
6.8失败处理
服务渠道应对密码验i正、生物特征识别、短信验证、手势密码等用户无效验证次数进行限制,合理设泄一天内失败次数上限(如24小时内不得超过6次)和累计失败次数上限。
采取合理措施对超限账号进行控制,例如:
采取账号锁左等措施,并设定有效的锁左时长,或直到管理员启用该账号为止。
同时宜注意评估由此带来的拒绝服务风险,并采取适当的措施进行避免。
7数据安全
7.1信息输入安全(客户端)
服务渠道应禁止在身份认证结束后存储敏感数据,防止敏感数据的泄露。
服务渠道客户端运行日志中不应记录电子社保卡卡号、银行卡号、社会保障号码等敏感数据,不应记录完整的敏感数据原文。
采集用户敏感信息的安全输入控件应具有但不限于以下安全防护措施:
——替换输入框原文;
——逐字符加密、字符串加密:
——防范键盘窃听:
——采用自定义软键盘。
7.2信息传输安全
服务渠道客户端与服务端间的交易报文,应采用数字证书全报文或关键数据域签划和验签,保证报文的真实性和不可抵赖性。
服务渠道应确保敏感数据传输时不应仅依赖协议层加密,应在应用层加密后才可进行传输。
应具备账户和交易信息的鉴别机制,防范信息被篡改。
应采用随机数或序列号等机制防止重放。
7.3信息使用安全
服务渠道中的信息仅供必要的业务操作使用。
应确保敏感数据加密后,才可由服务渠道输出。
7.4信息存储安全(客户端)
应慎用服务渠道客户端本地的数据信息存储,对本地储存信息的内容、数量、存储时间进行限制。
服务渠道客户端不应留存从全国社保卡服务平台获取的敏感数据。
7.5敏感数据保护(服务端)
服务渠道XX不应在服务端留存从全国社保卡服务平台获取的敏感数据,包括数据库形式、计算机文件、纸质文件等各类存储方式,数据使用完成后应立即淸除。
7.6数据删除安全(客户端)
内存中和临时文件(包括但不限于Cookies.本地临时文件等)中如存在完整的电子社保卡卡号、银行卡号、社会保障号码等敏感数据,应及时淸除,即在采集敏感数据的界而退出后或敏感数据使用完成后,由服务渠道客户端主动淸除。
上述淸除实现不应依赖于操作系统或虚拟机提供的垃圾回收机制。
信息在使用完成后应进行有效销毁。
服务渠道应确保已被逻借删除或释放的信息,包括仍在系统中、并可以被恢复、但用户不可访问的信息,不可被英他应用程序或英自身再次使用。
8通信安全
8.1安全通道和协议
服务渠道的服务端与客户端、或服务端与全国社保卡服务平台、或客户端与全国社保卡服务平台通信时,应遵循包括但不限于以下要求:
应使用专线或强壮的安全协议(如https),例如使用安全套接字层或传输层安全协议、互联网安全协议等。
在使用SSUTLS协议时,应符合全国社保卡服务平台支持的最低版本,应使用安全的版本,不得使用存在安全隐患版本以及弱加密套件。
对于互联网协议,宜采用IPv6,可采用IPv4。
8.2双向认证
服务渠道客户端与服务端应具备介法性认证机制,通过签名验签等密码技术手段进行双向认证,确保合法性。
9密码算法安全
9.1密码算法
密码算法的选择和使用宜符合国家密码管理部门的要求及电子社保卡的设计要求。
9.2加密算法安全
应使用对称加密算法、非对称加密算法对认证信息和敏感数据进行加密保护。
对于使用对称加密算法的单次应用或交易,为避免攻击者通过获取明文密文组对密钥进行字典攻击,应使用密钥变换的方法生成一次性密钥,以对设备或客户端主密钥进行保护。
应泄时重新协商会话密钥。
宜使用以下算法和参数:
——SM4;
一一SM2,使用256位长度的私钥。
如无法使用推荐的算法和参数,则可选择使用以下过渡的算法和参数,并逐步升级至规定算法:
一一3-DES,使用128位或192位的密钥长度;
一一AES,使用128位、192位或256位的密钥长度;
一一RSA,使用高于1024位的密钥长度:
——ECC,可使用NISTP-256/P-384/P-521曲线。
以下算法和参数不得使用:
一一DES,使用64位的密钥长度;
——RSA,使用等于或低于1024位的密钥长度。
在分组密码计算时,宜选择使用分组链接模式(CBC)、密码反馈模式(CFB)、输出反馈模式(OFB)、计数器模式(CTR)等工作模式,不宜使用电码本模式(ECB)。
9.3密钥加密或解密
可使用对称加密算法、非对称加密算法用于不安全信道的密钥分发。
几种常见的加密情况:
——用对称密码给对称密钥加密;
——用非对称密码给对称密钥加密;
——用对称密码给非对称密钥加密。
宜使用以下算法和参数:
——SM4;
——SM2,可使用256位长度的私钥。
如无法使用推荐的算法和参数,则可选择使用以下过渡的算法和参数,并逐步升级至规定算法:
—一3-DES,使用128位或192位长度的密钥;
—一AES,使用128位、192位或256位长度的密钥;
一一RSA,属非对称密钥算法,使用髙于1024位长度的密钥;
——ECC,可使用NISTP-256/P-384/P-521曲线。
以下算法和参数不得使用:
一一DES,使用64位长度的密钥;
——RSA,使用等于或低于1024位长度的密钥。
9.4安全散列(消息摘要)
宜使用SM3算法进行消息摘要。
如无法使用推荐的算法,则可使用以下过渡的哈希算法进行消息摘要,并逐步升级至规定算法:
——SHA-256:
——SHA-384:
——SHA-512O
以下算法和参数不得使用:
——SHA-1;
——MD5U
9.5数字签名
应使用适当的哈希算法配合非对称签名算法进行数字签名计算。
宜使用非对称数字签轻技术对用户身份或关键数据进行认证。
应正确使用密钥管理规则以确保私钥的机密性和私钥、公钥的完整性及真实性。
宜使用256位长度私钥的SM算法。
如无法使用推荐的算法,则可使用以下过渡的非对称签名算法,并逐步升级至规左算法:
——RSA,使用高于1024位长度的密钥;
——ECC,可使用NISTP-256/P-384/P-521曲线。
以下算法和参数不得使用:
——RSA,使用等于或低于1024位长度的密钥。
10接口安全
10.1接口文件保护
服务渠道应通过全国社保卡服务平台分配的渠道账户访问电子社保卡文档库,获取SDK、H5及API接口文件。
服务渠道应将获取的接口文件保存在内部网络,进行访问权限控制,遵循"最小权限”和“按需访问”原则,防止接口文件泄露。
10.2运行环境物理信息和地理位置信息授权
服务渠道应提示用户授权服务渠逍及全国社保卡服务平台获取运行环境物理信息、地理位巻信息。
服务渠道应允许全国社保卡服务平台获取经用户授权的运行环境物理信息、地理位置信息。
10.3二维码验码接口(服务端)
为确保调用安全,服务渠逍服务端调用二维码验码接口时,应按照全国社保卡服务平台接口文档要求,上传二维码动态码、业务类型和经用户授权的地理位垃信息、经用户授权的运行环境物理信息等参数。
10.4二
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 电子 社会保障