*****有限公司

二〇二〇年四月

第一章 总 则

第一条为了加强公司客户信息安全管理，规范客户信息访问流程、用户访问权限以及承载客户信息的环境，降低客户信息被违法使用和传播的风险，根据国家《网络安全法》、《电信和互联网用户个人信息保护规定》(工业和信息化部令第24号)等法律法规及制度要求，对照集团公司《中国客户信息安全保护管理规定》（移信安通[2017]26号），特制定本实施细则。

第二条客户信息安全管理涵盖客户信息的收集、传输、存储、使用、共享、销毁等各个环节。客户信息的载体包括电子和纸质两种形式。

第三条客户信息的生命周期结束后，公司各级组织有义务和权力根据相关的法律、法规及合同约定，妥善的处理客户信息以及与客户信息相关的数据和载体。

第四条保护客户信息安全及其合法权益是中国应承担的企业社会责任，公司各级员工应严格遵守“五条禁令”的相关要求，保护客户信息安全，严禁泄露、交易和滥用客户信息，员工有权利和义务制止对于任何可能危害客户信息安全的行为，并向信息安全管理部门举报。

第五条客户信息安全保护管理遵循“责任明确、授权合理、流程规范、技管结合”的工作方针。

第六条客户信息安全面临的风险和威胁主要包括：因为权限管理与控制不当，导致客户信息被随意处置；因为流程设计与管理不当，导致客户信息被不当获取；因为安全管控措施落实不到位，导致客户信息被窃取等。

第七条省公司各相关部门、各地市分公司（以下简称各单位）应定期组织客户信息安全评估和审核，对发现的隐患及时整改。

第应当建立用户投诉处理机制，公布有效的联系方式，接受与客户信息保护有关的投诉，并自接到投诉之日起十五日内答复投诉人。

第九条各单位应当对工作人员进行客户信息保护相关知识、技能及安全责任培训。

第十条本细则是公司进行客户信息安全管理工作的基本依据。各单位可根据工作需要进一步制定各条线和专业工作细则，做好客户信息安全管理工作。

第十一条本细则适用于省公司各部门、各地市分公司，适用于与客户信息相关系统的使用人员、运维人员、开发测试人员、管理人员和安全审核人员等。

第十二条本规定的解释权属于中国通信集团浙江有限公司信息安全部。

第二章 客户信息保护原则

第十三条各单位对客户信息的管理应遵循如下原则：

（一）合法合规原则——不得收集提供服务所必需以外的客户信息或者将信息使用于其提供服务之外的目的；不得以欺骗、误导、强迫等方式或者违反法律、行规以及双方的约定收集、使用及保存信息。

（二）主体责任明确原则——按照“谁主管谁负责、谁运营谁负责、谁使用谁负责、谁接入谁负责”的原则，明确责任分工，各单位应对其持有的客户信息承担安全责任，无论这些信息通过何种途径获得。

（三）分类分级管控原则——对信息进行分类分级，根据敏感程度不同，采取适当的、与信息安全风险相适应的管理措施和技术手段，保障信息安全。

（四）敏感数据不出网原则——除非获得用户明确授权，未经脱敏处理的用户原始数据等敏感数据不可离开中国网络与计算环境。

（五）用户授权开放原则——除明确禁止对外共享的保密信息外，用户个人敏感数据开放给他人或第三方企业时，应取得用户个人的授权，未经被收集者同意，不得向他人提供个人信息。

（六）最少够用原则——在向内部单位、平台、 合作方共享开放信息时，在满足管理要求的前提下仅提供业务开展明确需要的信息属性、标签属性及规模。

（七）用户知情同意原则——收集客户信息前，应事先告知用户数据处理的目的、方式和范围，以及用户查询、更正、删除个人信息的机制，并明示征得用户的同意。 

（八）目的明确原则——应具有合法、正当、具体的客户信息处理目的，未获得用户的授权，不得改变客户信息的处理目的。

（九）质量保证原则——在处理客户信息的过程中，应基于管理与技术手段确保客户信息的准确性、真实性、时效性、可用性，不得篡改、损毁。

第三章 组织与职责

第十四条客户信息安全管理采取归口管理的方式，信息安全部是公司客户信息安全归口管理部门。

第十五条各部门应负责各自主管的业务系统的客户信息安全保护，明确各业务系统的客户信息安全责任人，按照本规定落实业务系统的安全管理要求。

第十六条客户信息安全归口管理部门的职责：

（一）负责客户信息安全的全面管理；

（二）组织制定统一的客户信息安全保护实施细则；

（三）组织制定客户信息安全保护的制度和策略；

（四）组织研究客户信息安全保护的技术手段；

（五）定期组织客户信息安全专项审计；

（六）负责收集、汇总客户信息泄密事件；

（七）牵头组织进行客户信息泄密事件的查处；

（八）负责客户信息安全事件的对外解释口径。

第十七条市场部、政企部、客服部等是涉及客户信息安全的业务部门，其职责为：

（一）负责规范访问客户信息的业务人员岗位角色及其职责；

（二）负责主管的业务系统的客户信息安全保护，建立落实管理制度和细则；

（三）监督业务人员落实“五条禁令”；

（四）负责业务层面客户信息安全的日常管理和审核工作；

（五）负责制定客户信息泄密投诉的解释口径与投诉处理流程；

（六）制订对业务合作伙伴的信息泄露的惩罚措施及具体实施；

（七）协助完成客户信息泄密现象的市场调查；

（八）协助进行客户信息泄密事件的查处。

第十信息技术部、网络部（及下属网管、网优、互客各中心）、市场部电子渠道中心等是涉及客户信息安全的运维支撑部门，其职责为: 

（一）负责所运维的涉及客户信息的系统和平台技术层面的客户信息安全保障和稽查工作；

（二）负责所主管系统的客户信息安全保护, 建立落实管理制度和细则；

（三）负责规范后台运行维护人员、开发测试人员、生产运行支撑人员的角色和职责；

（四）监督本部门人员落实“五条禁令”；

（五）做好对第三方的管理，包括组织签订保密协议，加强操作管理等；

（六）负责规范所属系统和平台客户信息安全技术标准和访问流程；

（七）协助主管部门查处客户信息泄密事件。

第十九条中国在线公司负责受理客户信息泄密事件的投诉、上报。

第二十条其他相关部门的职责：

（一）人力资源部：应组织有关员工签订保密承诺书，及时发布人员岗位变动、离职的信息给帐号管理部门，参与对客户信息泄密人员的查处；

（二）规划技术部：应在系统规划、方案设计阶段考虑并纳入客户信息安全“三同步”要求；

（三）工程建设部：应在工程建设各阶段涉及客户信息的环节严格做好客户信息安全保护监督；应在系统验收阶段，检查客户信息保护工作的落实情况，不达到要求的不予验收；

（四）采购物流部：应在协议和合同中纳入客户信息保密的相关条款；

（五）纪检监察室：负责“五条禁令”的监察、违规行为的调查审核、违规人员的处罚判决；

（六）内审部：负责开展客户信息风险的审计；

（七）综合部：负责客户信息安全的相关对外宣传。

第二十一条各地市分公司的客户信息安全由地市信息安全职能管理部门归口管理，对照省公司各部门、各专业条线职责明确地市相关部门的职责和工作。

第四章 客户信息的内容及等级划分

第一节 客户信息的内容

第二十二条客户信息包括用户身份和鉴权信息、用户数据及服务内容信息、用户服务相关信息等三大类。客户信息的详细内容见附录一。

第二十三条用户身份和鉴权信息包括但不限于：用户自然人身份及标识信息、用户虚拟身份、用户鉴权信息等。

第二十四条用户数据及服务内容信息包括但不限于：用户的服务内容信息、联系人信息、用户私有数据资料、私密社交内容等。

第二十五条用户服务相关信息包括但不限于：业务订购关系、服务记录和日志、消费信息和账单、位置数据、违规记录数据、终端设备信息等。

第二节 客户信息等级划分

第二十六条客户信息等级分类按照客户信息的敏感程度划分为极敏感级、敏感级、较敏感级和低敏感级四类，具体划分方法请参见附录二。

第三节 存储及处理客户信息的系统

第二十七条存储和处理客户信息的系统包括支撑系统、业务平台、通信系统等3大类，具体内容包括但不限于附录三。

第二十存储和处理客户信息的支撑系统包括但不限于：业务支撑侧的业务支撑系统（BOSS）、CRM、ESOP、VGOP、经营分析系统等；网络侧的网管系统（性能管理系统等）、集团公司不良信息集中治理平台省端子系统、上网日志留存系统、统一DPI系统等。

第二十九条存储和处理客户信息的业务平台包括但不限于：业务支撑侧的云平台、大数据平台；网络侧的短信中心、彩信中心(MMSC)、短信网关、彩信互通网关、企信通、LBS、彩铃平台、MISC(DSMP)、ADC、ADC位置类系统、ADC业务平台、能力开放平台等。

第三十条存储和处理客户信息的通信系统包括但不限于：MSC、HSS/HLR、WAP网关、端局、关口局等。

第三十一条各单位自建或合作运营的涉及客户信息的其他系统。

第五章 岗位角色与权限

第三十二条帐号的权限分配应当遵循“权限明确、职责分离、最小”的原则。原则上一个用户帐号对应一个用户，而一个用户帐号拥有的权限是由其被赋予的岗位角色所决定的，应按照角色或用户组进行授权，而不是将单个权限直接赋予一个用户帐号。

第三十三条各单位应对使用BOSS、CRM、经分、大数据、云平台及其他涉及客户信息的业务系统的岗位角色进行梳理，对权限相近的岗位角色进行合并，并对岗位角色的权限进行规范。在BOSS、CRM、经分等涉及客户信息的系统中，岗位角色应当根据企业、部门的组织结构和职责分配而设定；同时，应当根据岗位角色的需要对相关人员进行授权，不能根据人员需求或变更而设定岗位角色。不同的岗位角色拥有不同的权限。

第一节 业务部门岗位角色与权限

第三十四条业务部门经过授权的员工是客户信息的使用者。原则上，经授权的业务部门的员工可以访问BOSS、经分、大数据、云平台或其他业务平台系统的客户信息，但不得拥有批量导出客户信息的权限。

第三十五条业务部门的岗位角色主要包括：涉及市场部、政企部、客服部等部门的产品研发、市场与策划、业务运营、运营系统支撑、服务营销等5大类角色，具体岗位角色见附录四。

（一）角色1：产品研发

1.岗位包含举例：产品研发、产品经理、行业经理等细项岗位；

2.岗位说明：该类岗位角色主要指业务部门具体负责产品研发、推广的岗位。

3.权限要求：

●可以查看对应产品所涉及的客户信息；

●仅具有查询权限，不应授予增加、删除、修改、批量导入与导出、批量开通与取消、批量下载等针对客户信息的操作的权限。

（二）角色2：市场与策划

1.岗位包含举例：市场运营分析、服务营销策划、渠道管理、传播管理等细项岗位；

2.岗位说明：该类岗位角色主要指业务部门具体负责后台分析、营销及其他管理工作的岗位。

3.权限要求：

●该角色人员只可查询系统中的统计数据，不应授予查询、操作客户信息的权限，如因工作确需接触客户信息，请按照“数据提取”的相应规定进行；

（三）角色3：业务管理

1.岗位包含举例：业务管理、服务质量管理、合作管理、业务运营管理、业务运营支撑等细项岗位；

2.岗位说明：该类岗位角色主要指业务部门负责业务运营、支撑、服务质量等细项业务处理的岗位；

3.权限要求：

●根据具体岗位的不同，考虑具体工作的需要，可以查看相应权限所涉及的客户信息；

●仅具有查询权限，不应授予增加、删除、修改、批量导入与导出、批量开通与取消、批量下载等针对客户信息的操作权限。

（四）角色4：运营系统支撑

1.岗位包含举例：业务系统管理、系统运营支撑等细项岗位；

2.岗位说明：该类岗位角色主要指业务部门负责系统管理及支撑的岗位。

3.权限要求：

●该角色人员负责部门系统帐号、口令的管理，配合运维支撑部门进行相应系统的开发、运营和维护，可以查看相应权限所涉及的客户信息；

●仅具有查询权限，不应授予增加、删除、修改、批量导入与导出、批量开通与取消、批量下载等针对客户信息的操作权限。

（五）角色5：服务营销

1.岗位包含举例：客户服务营销、渠道服务营销、营业厅服务营销、电子渠道服务营销等细项岗位；

2.岗位说明：该类岗位角色主要是指业务部门的各项渠道中直接服务于客户的一线岗位。

3.权限要求：

●根据具体岗位的不同，考虑具体工作的需要，经过授权后查看相应权限所涉及的客户信息；

●直接为客户办理业务的岗位，应按最小授权原则，可授予增加、删除、修改、批量导入与导出、批量开通与取消、批量下载等针对客户信息操作的部分权限，但必须有严格的日志记录； 

●不直接面对客户的岗位，仅具有查询权限，不应授予增加、删除、修改、批量导入与导出、批量开通与取消、批量下载等针对客户信息的操作权限。

第三十六条业务人员的授权管理：

（一）按照《中国帐号口令管理办法》相关要求进行权限分配，提供给相关人员。

（二）角色5的岗位，可在严格审批流程后得到授权，在系统中根据需要对授权范围内的客户信息进行相应操作，但需有严格日志记录；

（三）若要对客户信息进行增、删、改、批量导入、导出、为客户批量开通、取消业务等操作，需经过严格的审批流程后方可实现；

（四）除角色5外的其他角色，可在严格审批流程后得到授权，查看所需要的、授权范围内的客户信息，但严禁对客户信息进行相应其他操作，具体操作包括：增、删、改、批量导入、批量导出、拷屏等；

（五）所有敏感数据的读取及修改操作的责任都能落实到人，根据信息泄漏途径的归属确定每项敏感数据在该途径的“责任人”；

（六）对由于业务人员造成的敏感信息安全问题承担相应责任。

第二节 运维支撑部门岗位角色与权限

第三十七条经过运维支撑部门授权的员工是涉及客户信息的BOSS、经分、大数据、云平台等系统的运维管理者，经授权的员工拥有查询、增加、删除、修改、批量导入导出、批量开通与取消、批量下载等操作客户信息的部分权限。

第三十运维支撑部门的岗位角色主要包括运行维护、开发测试、生产运营3大类角色。

（一）角色1：运行维护

1.岗位包含举例：主机管理员、网络管理员、数据库管理员、应用管理员、配置管理、服务监控、安全管理、安全审计。

2.岗位说明：该类岗位主要包括负责涉及客户信息的系统的维护管理和服务监控的人员。

3.权限要求：

●网络管理员原则上不允许查询客户信息，主机管理员、数据库管理员、配置管理员、应用管理员、安全管理员、安全审计员可以有查询权限；

●主机管理员、数据库管理员、配置管理员、应用管理员按照最小授权原则授权，可授予增加、删除、修改、批量导入与导出、批量开通与取消、批量下载等针对客户信息操作的部分权限，但必须有严格的日志记录；

●具有批量操作权限的人员应指定专人，人员范围应尽量小。

（二）角色2：开发测试

1.岗位包含举例：架构管理、系统设计、应用开发、应用测试、项目建设管理等；

2.岗位说明：该类岗位主要包括负责涉及客户信息的系统的设计、研发、测试以及项目建设管理人员。

3.权限要求：

●开发测试人员原则上不能接触生产系统数据；

●开发测试人员仅具有测试系统的操作权限，开发测试系统需要涉及到客户敏感数据信息的内容，原则上使用过期数据或是模糊化处理之后的数据。模糊化的方法见附录八。

（三）角色3：生产运营

1.岗位包含举例：投诉管理、运营分析、出帐管理、数据质量支撑、安全审核等；

2.岗位说明：该类岗位主要包括负责业务支撑系统的投诉管理、运营分析等生产运营相关人员。

3.权限要求：

●若涉及投诉处理、批量业务操作的需要，按照最小授权原则，可授予查询，修改，批量导入导出的权限，授权人员范围应尽量小。

第六章  帐号与授权管理

第三十九条业务帐号管理:

(一）业务系统的应用帐号应该由该系统的业务主管部门管理，业务主管部门必须制定岗位角色和权限的匹配规范，提供岗位角色和权限对应的矩阵列表,确保职责不相容。

(二）业务主管部门需指定专人（业务管理员）负责所管辖业务系统的帐号权限分配，明确所管辖业务系统的帐号权限申请审批流程。

(三）业务管理员应将所管辖业务系统的岗位角色权限矩阵变更申请及应用层帐号权限变更申请提交主管领导审批，严格系统关键功能和超级帐号的授权。

(四）业务管理员需要定期组织业务系统帐号使用情况的审核，确认业务系统中用户身份的有效性、帐号创建的合法性、权限的合理性，对存在的问题提出整改要求。

第四十条运维帐号管理：

（一）运维支撑部门应指定专人(系统帐号管理员)负责运维帐号和权限的管理工作，制定岗位角色和权限的匹配规范，提供岗位角色和权限对应的矩阵列表,确保职责不相容；

（二）运维人员应向上一级主管提出帐号权限申请，系统帐号管理员应按照权限最小化原则分配运维人员的帐号权限。

（三）系统帐号管理人员要定期对系统帐号使用情况、权限、口令等进行审核，确认帐号、权限的有效性，并对存在的问题进行整改。

第四十一条 第三方帐号管理：

（一）对于外部人员需使用BOSS等涉敏感信息系统帐号的情况，应和第三方厂商签订相关的安全保密协议，以保证第三方厂商能够遵守中国的安全管理要求。

（二）除运维支撑部门分管领导授权外，原则上第三方人员不允许掌握系统管理员权限，第三方人员创建系统帐号的权限、查询涉及客户信息、控制网元的权限应严格控制在工作职责范围之内。

（三）特殊情况下，第三方人员若需要获得系统管理员权限，应临时授权,工作完成后及时收回权限。

（四）应参照运维人员帐号管理要求，定期对第三方帐号、权限、口令进行严格审核。

（五）第三方人员访问涉及客户信息的平台及相关应用必须使用本人实名制4A账号，必须采用强认证。

（六）各单位应对第三方帐号申请、回收、授权、有效期等环节进行严格管理，并制定管理办法，确保第三方人员发生离职或岗位变动时能及时清理其帐号。

第四十二条其它的帐号、权限和口令管理具体要求请参见附录六和《中国帐号口令管理办法》。

第七章  客户信息全生命周期管理

第一节客户信息的收集

第四十三条收集客户信息时，应具备合法、正当的目的，并清晰、准确地予以描述。

第四十四条应根据已确定的目的，确定收集最少的客户信息，以及存放地域、存储期限、收集频率等处理规则。

第四十五条应当在经营或者服务场所、网站等公布客户信息收集、使用规则，明确告知用户收集、使用信息的目的、方式和范围，留存信息的期限，查询、更正、删除信息及注销账户的渠道以及拒绝提供信息的后果等事项。

第四十六条在用户通过营业厅或线上渠道登记使用服务时,应在取得用户同意后方可收集客户信息，法律法规另有规定的除外。

第四十七条针对违反双方约定收集、使用其个人信息的，或收集、存储其个人信息有错误的，用户可提出删除或更正要求，各单位应采取措施予以满足。

第四十委托他人代理市场销售和技术服务等直接面向用户的服务性工作，涉及收集、使用客户信息的，应当对代理人的客户信息保护工作进行监督和管理，不得委托不能满足客户信息保护要求的代理人代办相关服务。

第二节客户信息的传输

第四十九条应根据业务流程、职责界面等情况，合理划分安全域，并在安全边界上配置相应的访问控制策略及部署安全措施。针对跨安全域传输等存在潜在安全风险的环境，应对敏感信息的传输进行加密保护，并根据数据敏感级别采用相应的加密手段。 

第五十条应强化传输接口安全管控，实施系统间接口的设备鉴权、并通过MAC地址、IP地址或端口号绑定等方式违规设备接入，实施数据流程控制、关键操作日志管理机制。

第五十一条敏感信息传输至其它系统前，应依据“谁使用谁负责”的原则明确双方安全责任，同时，应保障在传输过程中的安全保密。

第五十二条采用密钥加密时，应对密钥的生成、分发、验证、更新、存储、备份、有效期、销毁进行管理，严格实施密钥存储介质管理，确保密钥的安全。同时，应采用公认安全的、标准化公开的加密算法和安全协议。

第三节客户信息的存储

第五十三条应制定管理规定对存放客户信息的电子文件或纸介质进行有效管理，规定其保存、传输、销毁等流程，明确存有客户信息的物理介质（磁阵、硬盘和磁带等）的维护、更换、升级和报废等操作要求，防止客户信息泄漏。

第五十四条应加强对存储客户信息的物理区域（如机房、维护处室／中心）的管理，采用相应的访问权限分配策略及门禁卡等控制手段，同时对进出的人员、目的、操作进行详细记录，外来人员进入该区域应由本公司对口的维护人员全程陪同。

第五十五条对于要离开系统的物理介质，必须采用有效的手段由专人彻底删除客户信息后，才可离开其所在的安全区域。如果要将存有客户信息的介质交给第三方，必须得到主管领导的审批。

第五十六条应采取有效的技术、管理手段加强对涉及客户信息的系统使用存储介质的管控。应记录介质输出客户信息和文件的详细信息，并定期审核。

第五十七条应按照数据敏感程度做好数据分类管理，对不同安全级别的数据采用差异化安全存储，包括差异化脱敏存储、加密存储、访问控制等。并做好加密算法、脱敏方法的安全性保密。

第五十应建立针对多租户数据共享存储的安全管理策略，提供多租户数据安全管控机制,实现多租户之间的资源及应用隔离。详见《中国大数据安全防护技术实施指南》。

第五十九条各单位应建立完备的数据容灾备份和恢复机制，提供基本的完整性校验机制，保障数据的可用性和完整性。做好数据容灾应急预案，一旦发生数据丢失或破坏，可及时检测及来恢复数据，保障数据资产安全、用户权益及业务连续性。各单位应留有备份日志，以供审核使用；能够及时正确对备份异常（失败、受损）进行告警。

第六十条在境内运营中收集和产生的客户信息和重要数据应当在境内存储。

第四节客户信息的使用

第六十一条在使用客户信息时，应遵循以下要求：

（一）因业务需要，确需改变客户信息处理目的或改变客户信息处理规则时，应再次征得用户明示同意；并针对目的变更后的情况，进行客户信息安全风险评估，重新调整安全措施。

（二）基于客户信息所产生的衍生信息能够单独或与其他信息结合识别自然人身份时，应视为客户信息，对其使用应遵循原先的客户信息处理目的。

（三）应采取访问控制措施，确保员工只能访问职责所需的最少够用的客户信息。

（四）向用户提供多种参与对其客户信息处理的方法，包括访问、更正、删除、撤回同意、注销账户、获取自身客户信息等。

（五）委托第三方处理客户信息时，应确保第三方具有足够的客户信息安全能力，签订书面合同，明确第三方的安全责任，并监督第三方严格按照约定处理客户信息。

第六十二条业务人员对客户信息进行操作时，应遵循以下要求：

（一）对客户信息操作的人员包括业务人员、运维支撑人员、开发人员等，这些人员经授权后可以获得客户信息，但应遵循相应的管理要求。

（二）业务人员的范围参见第五章第一节规定；

（三）涉及客户信息的批量操作（批量查询、批量导入导出、批量为客户开通、取消或变更业务等），必须遵循相应的审批流程，通过业务管理部门审核，具体流程参见附录五；

（四）业务人员因业务受理、投诉处理等情况下需要查询或获取客户信息时，应遵循如下要求：

1.涉及客户普通资料的查询，服务营销人员要获得客户的同意，并且按照正常的鉴权流程通过身份认证。鉴权一般采取有效证件或服务密码验证，并保留业务受理单据。

2.涉及客户通话详单、集团客户详细资料等客户信息的查询，服务营销人员只能在响应客户请求时，并且客户自身按照正常流程通过身份鉴权的情况下，协助客户查询；禁止服务营销人员擅自进行查询；查询需保留业务受理单据。

3.除服务营销外的业务人员，因投诉处理、营销策划、经营分析等工作需要查询和提取客户信息的，业务管理部门应建立明确的操作审批流程，定期进行严密的事后审核。

第六十三条运维支撑人员对客户信息进行操作时，应遵循以下要求：

（一）运维支撑人员的范围参见第五章第二节规定。

（二）运维支撑部门需制定并维护业务系统的系统层角色权限矩阵，明确生产运营、运行维护、开发测试等岗位对客户信息的访问权限，明确未经授权的运维支撑人员不允许有客户信息的访问权限。

（三）运维支撑人员对业务系统的应用层的访问权限必须经过该系统的业务管理部门审批，对系统层访问权限必须经过本部门领导审批。

（四）运维支撑人员因统计取数、批量业务操作需求对客户信息查询、变更操作时必须有业务管理部门的相关公文或工单，并经过部门领导审批。

（五）运维支撑人员因业务投诉、统计取数、批量业务操作、批量数据修复等进行的客户信息查询、变更必须提交操作申请，按照要求进行操作，不得扩大操作范围，在工单中保留操作原因和来源的工单（公文）编号，并由专人负责审核。

（六）运维支撑人员因应用优化、业务验证测试需要查询、修改客户信息数据，只能利用测试号码进行各项测试，不得使用客户号码。

（七）运维支撑人员因系统维护进行客户信息的数据迁移（数据导入、导出、备份）必须填写操作申请，并经过部门主管审批。

（八）严禁运维支撑人员向开发测试环境导出未经模糊化处理过的客户信息，对需导出的信息必须经过申请审批，并进行模糊化处理。

第六十四条进行数据提取时，应遵循以下要求：

（一）因生产分析、市场策划等活动需要，存在从业务支撑系统中批量取数的需求。批量取数存在较大的安全隐患，应从管理和技术上加强管控，防止客户信息泄密事件发生。

（二）数据需求部门应由指定人员担任数据分析员，负责数据提取需求；由该部门或上级业务管理部门负责数据提取需求的审核；支撑部门需指定专人担任数据管理员，负责数据提取需求的复核及提取；如发生人员变动，应及时更新并重新通知。

（三）为确保数据安全，数据管理员不得将取数结果交付给非需求人员。非数据管理员不接收取数申请，也不得将提取数据直接发给相关需求人员。

（四）数据分析员应对所提需求所涉及的客户信息进行审核并对需求内容作详细描述，数据管理员有责任进行复核并尽量减少客户信息的提取。原则上数据管理员应该只接受统计、分析类取数需求，不应该接受批量客户信息的取数需求，如遇到特殊情况（如客户关怀、二次营销等情况），必须遵循相应的审批流程。

（五）业务部门按照相应流程将数据提取需求发给取数部门，数据提取部门不得将数据提取结果直接发给需求人员，数据提取结果必须为受控文档，并在指定平台上进行编辑和处理，不得存放在指定平台外的任何主机上。

（六）受控文档是指采用加密、授权、数字水印、数字签名等技术手段对文档进行安全保护后的文档，具体方法参见第九章。受控文档脱离中国的办公环境后，应无法打开。

（七）数据提取的审核必须由专人负责，审核人员应每月对日常数据提取情况进行审核，审核内容包括：数据提取需求审核分析的规范性、数据提取需求执行的规范性、数据提取复核的规范性和资料归档的及时性、完整性。安全人员应记录审核结果，并进行汇总分析，总结存在的问题。

第六十五条应严格规范大数据开发行为，确保开发应用安全，遵循以下要求：

（一）对涉及客户信息的网络数据进行关联分析应仅限于提供服务的目的，严禁针对特定个人进行非法查询及关联分析。

（二）采用匿名化等脱敏技术保障用户隐私，建立脱敏技术应用安全评估机制，对脱敏后的数据进行可恢复性安全评估，防止脱敏数据关联到特定个人。未经评估的脱敏数据不得提供给第三方。

（三）未脱敏的客户信息不得用于业务系统的开发测试。

（四）脱敏后仍可恢复的信息视为客户信息。

第六十六条应建立数据开放机制。数据开放合作前应签订安全协议，明确规定合作各方数据保护责任，确立合作过程中的数据保护制度和安全措施。保障开放数据的安全，要求数据合作方对开放数据的保护水平不低于原有数据保护水平。加强开放数据传输操作权限管理，并建立审计机制。

第六十七条数据开放涉及客户信息时，应获得用户同意，或进行脱敏处理，确保脱敏处理后的信息不会被复原且不会追溯到用户。开放规则具体参见附录九。

第六十除非获得用户明确授权，未经脱敏处理的客户原始数据等敏感数据不可离开中国网络与计算环境。

第六十九条应建立数据泄露通知、报告和调查机制。应在网站或应用的明显位置提供数据泄露举报投诉链接，及时处理和反馈用户举报投诉。

第五节客户信息的共享

第七十条针对中国内部各单位之间的数据共享场景，应实施内部审批及操作审计，通过保密协议等方式明确数据共享双方应承担的安全责任，应具备的数据保护手段、数据使用范围和场景等，详见《中国大数据安全运营要求》。

第七十一条针对中国内部系统平台之间（包括同一内部单位、不同内部单位平台系统之间）的数据共享场景，应遵循服务最小化原则，仅向对端平台系统提供业务上必要的共享数据，并根据业务需求做好脱敏处理。

第七十二条应加强数据线下交互的过程管控，建立数据线下交互审批机制及操作流程，对线下交互数据采取加密、脱敏或物理保密封装等防护手段，防止数据被违规复制、传播、破坏等。 

第七十三条应加强数据共享接口安全管控，落实加密传输、访问控制、MAC地址或IP地址绑定等手段。对于下线或退网的业务平台系统，需要及时通知对端关闭数据共享接口，避免接口被非法利用。 

第七十四条数据共享过程应进行详细记录，支持事后合规审计，确保共享操作行为的可追溯及责任问题定位。

第六节客户信息的销毁

第七十五条应建立针对数据业务下线、用户退出服务、节点失效、过多备份、数据试用结束、超出数据保存期限等情况下的数据销毁管理制度、办法和机制，详见《中国大数据安全运营要求》。

第七十六条应落实安全销毁措施，敏感客户信息需要进行销毁时，必须使用有效的数据销毁方法进行处理，对于已删除敏感信息，应采用可靠技术手段保证信息不可被还原，并做好效果验证。 

第七十七条针对逻辑销毁操作，需要为不同数据的存储方式制定相异的逻辑销毁方法，并确保数据的多个副本被相同处理；针对物理销毁操作，应对销毁后的U盘、磁带、硬盘、光盘、闪存、固态硬盘等存储介质进行登记、审批、交接。严禁非法挪用存储介质，避免数据被违规留存或还原。

第七十数据销毁过程应进行日志记录，包括执行时间、参与人员、处理方式等。对于由合作方现场实施敏感数据销毁的场景，应安排内部工作人员进行现场监督。

第八章  第三方管理

第七十九条第三方公司是指与中国在业务上具有合作关系，或是向中国提供服务（包括推广渠道商、业务服务商、软件开发机构、平台建设厂家、运维支撑厂家等）的公司；在双方发生合作或服务关系的时候，有可能接触到中国客户信息的公司。

第八十条第三方系统是指为中国服务或合作运营的系统，这些系统可能不在中国机房内，但能通过接口与中国的系统发生数据交互从而获得客户信息。

第八十一条第三方人员是指为中国提供业务营销、开发、测试、运维等服务或参与合作运营系统管理的人员，可能接触到客户信息。

第八十二条应对第三方进行背景调查和安全资质审查。重点做好第三方股权关系、境内外合作关系、既往合作情况、运营历史背景等的调查；同时综合评估合作方的信息安全保障能力，设立黑名单机制，确保其具备相应的保密及运营资质，确保合作方是合格授权者，能切实保护敏感数据。

第八十三条应与第三方公司签订保密协议，在协议中明确第三方公司及其参与项目的员工的保密责任以及违约罚则。

第八十四条原则上还应要求第三方公司与我公司签订信息安全承诺书，严禁发生如下行为：

（一）窃取、泄露、滥用客户信息；

（二）利用系统漏洞损害中国或中国用户的利益；

（三）修改业务信息、强制或伪造订购业务等；

（四）在已上线使用的系统中留存后门和无法删除的超级帐户及密码。

第八十五条应建立第三方考核细则，在与其合同协议中明确数据安全保护的义务，明确考核内容、考核要求及惩处措施；并定期检查其在数据使用、管理等方面的安全制度和执行情况，对检查过程中发现的问题责成其在规定时限内整改。

第八十六条第三方人员进入中国生产区域或者登录中国系统操作时，应遵循中国的全部安全管理制度和规范。

第八十七条第三方人员工作区域应与中国的生产、内部办公、维护区域分离，并应采用更严格的访问控制策略和管控手段（如：4A）。

第八十第三方人员使用的测试数据不应当反映现网客户的真实信息，必须是经过模糊化处理的数据。

第八十九条第三方的人员进入可能接触到客户信息的生产或维护区域，应当有相应的审批制度。

第九十条第三方工作区域的终端接入中国的内部网络应有严格的接入认证，并严格U盘等外设拷贝，对WLAN、3G、4G等无线上网的使用，要求统一安装防病毒软件。

第九十一条应定期对现场服务的第三方终端进行涉敏感信息审核。

第九十二条第三方人员转岗或离岗前，第三方公司需要提交第三方人员转岗或离岗申请书，主管部门根据本规定，完成第三方人员的帐号回收、审核、网络调整等工作，并签署转岗或离岗审批意见，方可转岗或离岗。

第九十三条应规范合作营业厅、第三方服务渠道安全管理，明确敏感数据收集、存储、归档、销毁机制，完善敏感数据模糊化查询机制，避免敏感数据违规留存。

第九十四条应规范第三方数据代分析挖掘管理，禁止挖掘算法对原始数据进行增加、修改、删除等操作，保证代分析挖掘数据的可用性和完整性。

第九十五条第三方系统接入的要求：

（一）第三方系统需接入访问中国的系统时，应到我公司业务主管部门申请备案；

（二）第三方系统若需要保存部分客户敏感资料，应经过业务主管部门审批，原则上第三方系统不能保存极敏感级和敏感级的客户信息；

（三）第三方系统的安全配置和防护，应达到中国的相关安全要求；

（四）第三方系统退出服务时，业务主管部门应及时通知支撑部门关闭相应接口。

（五）各业务主管部门应定期对第三方系统进行安全审核。

第九章 客户信息系统的技术管控

第一节系统安全防护

第九十六条对客户信息相关系统，应采取必要的安全技术手段，重点防护：

（一）系统应位于核心安全域，安全域边界采用防火墙、IDS等防护手段；

（二）必须严格管理和涉及客户信息的系统与其他系统的互联互通的能力和范围；

（三）安全边界的网络设备、安全设备应定期进行安全评估和审核，及时修补漏洞，杜绝弱口令。

第九十七条加强系统自身安全：

（一）系统在设计阶段，应当根据接口和流程涉及到客户信息的类型和操作类型（查询、修改、增删），来定义安全需求；

（二）建立“安全准入制度”，在系统交付阶段分别对系统的接口与流程的安全性进行评估。未达到安全要求的系统原则上不允许上线。

（三）做好上线前的安全评估、基线审核，封堵和修补系统、数据库、中间件、应用层的漏洞，升级安全补丁，防止系统被攻击和入侵。

（四）针对云计算、大数据等新型数据业务系统，参照《中国大数据安全防护通用技术要求》、《中国大数据平台安全基线要求》、《云计算安全防护技术要求及实施指南》等要求做好系统安全防护。

第九十客户信息相关系统的变更必须经过相关主管的审批，并详细记录变更过程与变更结果。

第九十九条做好日常安全运维：

（一）做好客户信息相关系统的日常安全监控，完善告警分析与应急响应流程。

（二）定期审核客户信息相关系统的安全性（重大变更与系统升级后也需进行），及时修补发现的安全漏洞以及配置不符合项。

第二节集中4A管控要求

第一百条为了从技术上非授权用户接触客户信息，原则上，涉及客户信息的支撑系统、业务平台、通信系统等应纳入4A系统的集中管控。

第一百零一条4A系统是运维人员访问敏感信息系统后台资源（包括主机、数据库等）的唯一入口，运维人员应先登录4A系统，进行强认证后，才能访问后台系统。

第一百零二条应通过4A系统集中控制合法用户能访问敏感信息的权限，同时通过4A实现对用户访问客户信息操作日志的审核。

第一百零三条4A系统应实现基于主帐号的集中强身份认证，应保存用户的完整操作日志，并能对用户的异常操作行为以及高敏感数据的访问行为进行预警。

第三节金库模式管控

第一百零四条“金库模式”也称为“双人操作”或“多人操作”模式，指对于涉及到敏感信息的高风险操作，强制要求必须由两人或以上有相应权限的员工共同协作完成操作的客户信息保护方式。

第一百零五条为加强对关键系统高风险操作（批量查询、导出、变更、删除）的管控，涉及各类敏感客户信息的通信网及网管支撑系统、业务支撑系统、业务平台（包括云计算、大数据等新型业务平台）等均应纳入金库模式管控。详见《“金库模式”实施指导意见》、《“金库模式”优化及扩展实施要求》、《关于深化“金库模式”应用的指导意见》。

第一百零六条金库模式的实施应遵循如下基本原则： 

（一）聚焦关键系统、聚焦高风险操作、聚焦高价值信息；

（二）敏感操作，多人完成，分权制衡；

（三）授权不操作，操作不授权。

第一百零七条 应加强对合作伙伴的金库管控，防止合作方获取并泄露敏感客户信息。

第四节远程接入管控

第一百零原则上，远程接入帐号只能授予内部员工；如第三方因特殊情况需要通过远程登录访问系统，可根据系统主管授权，开通短时远程登录功能，最长授权时间不超过一年，并对远程登录操作进行监控（或事后及时审阅相应的操作日志记录）。

第一百零九条远程登录必须通过4A系统进行集中认证、授权和审核，应遵循权限最小化原则，开放用户能访问的系统及权限。

第一百一十条应对远程接入用户的登陆过程、操作行为进行记录（包括但不限于以下信息：用户名、操作内容、登陆方式、登入时间、登出时间）。

第一百一十一条通过远程接入方式进入公司网络的用户，应严格其接触客户信息。

第五节客户信息泄密防护

第一百一十二条因工作需要从支撑系统、业务平台或通信系统中提取的以文件形式存在客户信息时，应从技术手段上防止其被泄密。可以采用防泄密技术手段包括文档安全管理、终端安全管理、敏感信息监控、关键客户信息模糊化等。

第一百一十三条文档安全管理应实现如下功能：

（一）透明的文档加密解密；

（二）基于用户角色或主机的文档授权，被授权的特定用户或终端才能打开受控文档，未被授权的人或终端无法打开文档；

（三）实现文档权限控制(阅读、编辑、复制、拖放、打印、保存、另存为、阅读时间、打印次数及文档有效期等)。

第一百一十四条对能处理客户信息的终端，应有终端安全管理措施：

（一）应统一安装防病毒软件，存储介质的使用，无线网络的使用；

（二）应有统一的接入控制，执行统一的安全策略；

（三）定期扫描终端漏洞，及时升级补丁；

（四）定期扫描或审核终端上是否存在涉及客户信息的文件；

（五）防止通过硬盘、U盘、光驱、软驱等外设途径泄密；

（六）防止通过网络打印、本地打印等途径泄密；

（七）防止通过截屏、录像等途径泄密。

第一百一十五条对在业务支撑网和OA网内传输的客户信息，可在网络或终端侧进行敏感信息监控：

（一）对通过QQ、微信、飞信、电子邮件、HTTP等网络途径泄密客户信息进行监控；

（二）对监控到的批量传输客户信息的行为进行预警。

第一百一十六条应根据实际需要采用综合的技术管控手段，防止涉客户信息的文件泄密。

第一百一十七条应对可能泄密的途径进行深入分析，及时发现可能存在的漏洞，从技术手段上进行，防患于未然。

第六节系统间接口管理

第一百一十 被访问的敏感信息系统应具备安全可靠的接入鉴权机制。只有通过鉴权后才能访问接口，对于非法的访问能够进行告警并有完整的日志记录。

第一百一十九条提供完善的数据传输保护机制，包括数据加密、完整性校验等手段。对于跨越互联网或不同等级安全域之间的数据传输，必须进行加密，以实现数据传输的安全。

第一百二十条要敏感数据直传，做好对外接口安全隔离或能力，禁止将敏感数据通过系统接口传送至业务合作方平台，尤其是境外公司。

第一百二十一条对接口的所有请求和响应都要进行详细的日志记录，便于后期的故障分析和审核。

第七节数据脱敏

第一百二十二条基于“信息最少够用”和“服务最小化”的原则，对于客户界面显示、开发测试等场景，应根据用户个人隐私保护和商业秘密保护的要求，采取不同程度的模糊化或标签化处理机制。详见《客户界面信息模糊化业务规范》及附录八。

第一百二十三条对外合作、数据开放时使用到的数据形式包括原始数据、脱敏数据、标签数据、群体数据四种，应依据不同的使用场景使用不同的数据类型，具体的规则参见附录九。

第一百二十四条应建立数据脱敏的技术手段，根据业务场景的需要采用安全有效的数据脱敏方式，防止客户敏感信息的泄露。

第一百二十五条应在数据脱敏的各个阶段加入安全审计机制，严格、详细记录数据处理过程中的相关信息，形成完整数据处理记录，用于后续问题排查与数据追踪分析。

第一百二十六条数据脱敏、标签化方法应严格保密，防止因方法泄露造成数据被恶意恢复。

第十章 客户信息安全审核

第一百二十七条安全审核主要分为操作日志审核、合规性审核、日常例行安全审核与风险评估。

第一百二十各单位的业务部门和运维支撑部门负责开展日常的安全审核，客户信息安全归口管理部门进行专项安全审核、抽查。

第一百二十九条客户信息安全归口管理部门负责审核情况汇总，梳理存在问题，通报结果；如发现的重大安全隐患或违规行为，应向公司管理层汇报。

第一百三十条客户信息安全归口管理部门针对安全审核过程中发现的突出问题，牵头协调提出改进方案，并要求相关单位落实解决，同时对改进措施落实情况进行跟踪审核。

第一节 操作日志审核

第一百三十一条日志审核是对操作日志与工单等原始凭证进行比对，分析查找违规行为。

第一百三十二条日志审核的基本要求：

（一）应根据“职责不相容”原则设置的安全员，安全员应与系统管理员、业务操作人员分开，安全员应定期开展安全审核。

（二）涉及客户信息的各系统应全面记录帐号与授权管理、系统访问、业务操作、客户信息操作等行为，确保日志信息的完整、准确，对不符合要求的应由主管部门牵头落实系统的整改。

（三）各系统用于安全审核的原始日志记录内容应至少包括：操作帐号、时间、登录IP地址、详细操作内容和操作是否成功等。日志不应明文记录帐号的口令、通信内容等系统敏感信息和客户信息。

（四）各系统主管部门应加强系统原始日志访问管理，除日志日常维护涉及数据迁移外，任何人不得对日志信息进行更改、删除。

（五）用于客户信息安全审核的原始日志必须单独保存，各系统主管部门要制定数据存储备份管理制度，定期对原始日志进行备份归档，所有客户信息操作原始日志在线至少保留3个月，离线至少保留1年。

（六）各使用部门应保留所有客户信息操作的凭据，确保真实有效，凭据至少保留1年。 

第一百三十三条日志审核的策略：

（一）各单位客户信息安全归口管理部门牵头制定客户信息安全操作日志审核策略，相关部门配合完成所辖业务系统审核策略的制定。安全审核策略需明确审核对象、审核频度、审核方法。对于策略变更必须明确管理流程，详细记录变更起始、终止状态以及变更内容。

（二）在日志审核频度与抽样比例上，建议极敏感和敏感客户信息访问要求至少每周进行全量审核，较敏感客户信息访问至少按周审核，日志抽样比率不低于5%，低敏感客户信息访问至少按月审核，日志抽样比率不低于2%。

第一百三十四条日志审核人员对所有日志按关键命令、关键帐号、关键参数，进行抽样审核。及时发现异常时间登录、异常IP登录、异常的帐号增加和权限变更、客户信息增删改查等敏感操作。

第一百三十五条应对可能发生的异常操作行为进行重点审核，异常行为审核规则可参考附录七。

第二节 合规性审核

第一百三十六条合规性审核重点是依据《客户信息安全控制矩阵》等要求进行审核。

第一百三十七条应明确客户信息安全审核工作任务，包括审核目标、范围、参与人员、任务分工及相应流程。

第一百三十各单位相关部门根据制定的审核任务安排专人或采取交叉方式进行客户信息安全合规性审核，对审核结果进行归档，编写审核报告。

第一百三十九条每半年应对存有客户信息的系统进行至少1次合规性审核。

第三节 日常例行安全审核与风险评估

第一百四十条日常例行安全审核是指运维支撑部门对所负责维护的系统进行的常规性安全审核，包括日志审核、漏洞扫描、基线审核等。

第一百四十一条日常例行安全审核属于日常维护审核的范畴，应制定每日、周、月、季度日常检查报表，并按相应频次进行检查。

第一百四十二条风险评估是对系统面临的威胁、存在的弱点、造成的影响，以及三者综合作用带来风险的可能性进行评估。

第一百四十三条客户信息系统的风险评估频次原则上为每半年一次。但在重大活动或敏感时期，应根据上级单位要求开展专项风险评估。风险评估侧重通过白客渗透测试技术，发现深层次安全问题，如缓冲区溢出等编程漏洞、业务流程漏洞、通信协议中存在的漏洞和弱口令等等。风险评估以各系统的运维支撑部门自评估为主、信息安全管理责任部门抽查相结合的方式进行。

第一百四十四条应建立网上监测巡查机制，对于非法传播、交易我公司客户信息的行为进行及时监测和处置。

第十一章 安全事件应急响应

第一百四十五条应健全完善数据泄露等突发数据安全事件应急响应机制和应急预案。制定应急响应计划，做好应急预案，并定期演练，确保在紧急情况下重要信息资源的可用性。

第一百四十六条在发生或者可能发生个人信息泄露、毁损、丢失的情况时，应立即启动应急响应并快速处置、采取补救措施，按照规定及时告知用户并向有关主管部门和集团报告。

第一百四十七条对于通信主管部门通报或社会披露的与本单位相关的数据安全风险信息，在获悉后应当立即组织自查，排查安全隐患，消除安全风险；对于不实信息，及时回应用户关切，向社会澄清。

第十二章 重要问题的省市职责界面划分

第一百四十对于由省公司运维支撑的且面向全省使用的涉及客户信息的系统（如CRM、ESOP、大数据平台、地市数据分析中心等）。省公司业务部门负责制定业务系统帐号权限管控策略、金库管理策略、敏感数据分级分类管控策略、安全审计策略，负责明确相关业务场景是否纳入安全管控和审计，负责数据资产导出、共享给其他单位和业务系统的审批审核，对管理措施不当引发的安全问题负责；省公司运维支撑部门根据业务部门需求对业务系统部署安全管控措施、提供审计运营支撑、开展安全风险评估加固，对系统支撑出现的漏洞和问题负责；省、市两级公司业务部门分别负责所辖员工及合作伙伴的帐号权限、金库操作和敏感数据导出审核，负责所辖员工及合作伙伴的安全审计，对所辖人员出现的安全问题负责。

第一百四十九条对于因生产运营或业务管理需要由地市分公司自建的涉及客户信息的支撑系统和业务系统，由地市分公司承担安全管理职责，地市分公司业务部门和运维支撑部门分别负责客户信息安全策略管理和技术管控。自建系统应遵循集团公司、省公司业务管理和安全管控的相关要求，必须接入省公司网管或业支4A平台实现强身份认证和访问控制、将关键及高风险操作纳入金库管理、对客户敏感信息访问进行模糊化处理、实现客户敏感信息访问的完整日志记录，开展自建系统的安全风险自评估加固和日常安全审计。省公司信息安全部定期组织对地市自建系统客户信息保护执行情况进行抽查审计。

第一百五十条在“大数据”环境下，信息安全部作为客户信息安全归口管理部门，负责制定整体保护策略，组织开展大数据平台和大数据业务安全防护技术手段研究，定期组织开展新业务新技术评估和专项审计检查；根据“谁主管、谁负责，谁运营、谁负责”的原则，信息技术部大数据中心负责大数据业务规划、开发测试和业务运营的客户信息安全管理和安全防护，负责大数据业务的安全审计和合规管理，并承担公司“大数据”资源租用的审批职责，审批应遵循《中国大数据安全管控分类分级实施指南》的要求；信息技术部云计算中心对“大数据”平台基础设施工程建设、运行维护、生产运行涉及的客户信息安全负责；根据“谁使用、谁负责，谁接入、谁负责”的原则，业务单位（指省公司业务部门、地市分公司）应对本单位自身租用资源，或者引入的合作方租用资源涉及的客户信息安全负责，并定期向信息技术部大数据中心全量报备使用租用资源而建立的各类应用、产品和平台。

第十三章 事后问责

第一百五十一条公司有权利根据国家的法律、法规和企业规章制度，对于发现的任何侵害客户信息安全的内部机构或个人采取相应的处罚措施。

第一百五十二条对与中国有合作关系的组织或个人，若发生泄密事件，应根据合同和相关要求进行处罚,涉嫌犯罪的，依法移交司法机关处理。

第一百五十三条若公司内部发生客户信息泄露等信息安全事件，应根据事件涉及的范围和造成的影响，由省公司或地市分公司客户信息安全归口管理部门牵头进行查处，理清事件发生原委，明确各责任主体，执行事后问责。其中，对于由地市分公司查处的事件应及时向省公司信息安全部和相关部门进行过程和结果报备。

第一百五十四条若中国内部员工发生泄密事件，应根据信息安全事件造成的影响及相关责任主体的态度，作出如下处理：

（一）批评教育：包括责令责任主体检查、诫勉谈话等；

（二）书面检查：责令责任主体向上级主管部门作出书面检查；

（三）通报批评：在公司范围内对责任主体发文通报；

（四）绩效处分：降低或扣除责任主体绩效，纳入月度或年度考核；

（五）行政处分：追究信息安全事件发生负有领导责任的负责人的管理责任，对相关责任人予以行政处分，直至开除。

（六）法律责任：如涉嫌犯罪的，则移交司法机关处理。

以上方式可以单独适用，也可以同时适用。

第一百五十五条发生客户信息泄密事件，由客户信息安全归口管理部门组织有关部门联合进行责任认定，按照各单位具体处罚办法对相关直接责任人和负有领导责任的人进行处罚。

第一百五十六条针对由于客户信息泄露导致通讯信息诈骗事件的情况，将依据《中国防范打击通讯信息诈骗工作问责办法》对相关人员进行严肃追责。

附录一：客户信息分类表

附录六：帐号口令管理细则

一、帐号管理遵循的原则：

1.帐号管理贯穿帐号创建、授权、权限变更及帐号撤销或者冻结全过程；

2.帐号设置应与岗位职责相容；

3.坚持最小授权原则，岗位角色和权限对应的矩阵列表，避免超出工作职责的过度授权；

4.应制定严格的审批和授权流程，规范帐号申请、修改、删除等工作，授权审批记录应编号、留档；

5.帐号创建、调整和删除申请审批通过后，应及时更新系统中的帐号状态，确保与审批结论保持一致；

6.原则上，除低权限的查询帐号外，各系统不允许存在其它共享帐号，必须明确每个帐号责任人，不得以部门或用户组作为最终责任人。

7.在完成特定任务后，系统管理员应立即收回临时帐号。

二、帐号创建、变更、删除审批流程

1.超级帐号由主管领导以授权的方式授予具体的系统管理员，授权书至少应包括系统名称、超级帐号名、授予人姓名、职责描述、有效期等；

2.所有帐号，包括系统管理员帐号、普通帐号、程序帐号的责任人，应按规定的申请表格式要求提出申请，申请表至少包含申请人姓名、联系方式、申请人职责描述、申请时间、申请目的、申请帐号所属系统名称、帐号类型、创建或者变更或者删除操作类型、帐号权限描述、主管领导审批意见、系统管理员变更操作记录及签字确认、权责描述备注栏目等；

3.主管领导进行审批，重点审核所申请权限与申请人职责的一致性；

4.系统管理员负责创建、变更或者删除帐号，保留审批表格、并备案。

三、如因系统能力或者管理原因无法按用户创建帐号时，应采取如下管理措施：

1.明确共享帐号责任人，责任人负责按照上述流程要求提出共享帐号审批表，并在审批表中注明该共享帐号的所有用户名单；

2.共享帐号的使用人数，建立相关管理制度保证系统的每项操作均可以对应到执行操作的具体人员；

3.限定使用范围和使用环境；

4.建立完善的操作记录制度，如交记录、重要操作记录表等等；

5.定期更新共享帐号密码。

四、对于程序运行或者程序自身由于管理需要访问其它系统所使用的专用帐号，应符合如下要求：

1.只允许系统和设备之间通信使用，不得作为用户登录帐号使用；

2.将此类帐号的维护管理权限统一授权给该系统的系统管理员，由后者归口管理；

3.该系统的管理员负责建立该类帐号列表，并进行变更维护。

五、口令管理原则：

1.口令至少由8位及以上大小写字母、数字及特殊符号等混合、随机组成，尽量不要以姓名、电话号码以及出生日期等作为口令或者口令的组成部分。

2.应以HASH或者加密技术保存口令，不得以明文方式保存或者传输；

3.口令至少每90天更换一次。修改口令时，须保留口令修改记录，包含帐号、修改时间、修改原因等，以备审核；

4.5次以内不得设置相同的口令；

5.由于员工离职等原因，原帐号不能删除或者需要重新赋予另一个人时，应修改相应帐号的口令。

六、口令管理要求

1.如系统能力支持，应开启并设置自动拒绝不符合上述口令管理规则帐号和口令的参数；对于无法建立口令规则强制检查的系统，帐号用户应在每次口令修改后留有记录。

2.帐号口令输入尝试次数要做，防止口令的暴力破解。

3.对于无法进行定期修改口令的帐号，如内置帐号、程序帐号等，应在系统升级或重启时落实口令修改工作。

4.如发生口令遗忘的情况，帐号使用人应提出口令重置申请，由系统管理员进行密码重置；重置完毕后，使用者应马上更改重置后的密码。

5.当程序内的帐号密码需要保存在配置文件里时，应只使用适当权限的帐号，采用经过验证的算法对帐号口令进行加密，并做好帐号口令和加密密钥的保护工作。

6.当发生下述情况时，应立即撤销帐号或更改帐号口令，并做好记录：

帐号使用者由于岗位职责变动、离职等原因，不再需要原有访问权限时；

临时性或阶段性使用的帐号，在工作结束后；

帐号使用者违反了有关口令管理规定；

有迹象表明口令可能已经泄露等。

七、帐号审核的要求

1.帐号与权限的审核必须依据岗位角色和权限对应的矩阵列表；

2.定期对系统帐号权限进行职责不相兼容审核；

3.定期对帐号申请审批、权限变更等执行情况进行审核，避免非法创建帐号、无主帐号和权限与职责不相容帐号的出现；

4.定期对帐号口令修改执行情况进行审核，避免口令过期、不符合复杂度要求等问题。

附录七：异常行为审核规则

1)严禁输出：指禁止以任何形式将数据提供给业务合作方。

2)数据验真：指在获得用户授权、通过本单位业务管理部门和信息安全管理部门审核的情况下， 为业务合作方提供用户身份信息比对服务， 输出校验结果。

3)数据开放：指在获得授权（包括第三方授权） 、通过本单位业务管理部门和信息安全管理部门审核的情况下，为业务合作方提供相关用户数据和企业运营数据。

4)可以开放：指在符合脱敏要求的情况下将相关数据提供给业务合作方，遵守“信息最少够用” 原则和“服务最小化” 原则，并严格控制开放数据数量。下载本文