用户帐号和口令管理条例.docx
- 文档编号:25317244
- 上传时间:2023-06-07
- 格式:DOCX
- 页数:11
- 大小:21.04KB
用户帐号和口令管理条例.docx
《用户帐号和口令管理条例.docx》由会员分享,可在线阅读,更多相关《用户帐号和口令管理条例.docx(11页珍藏版)》请在冰豆网上搜索。
用户帐号和口令管理条例
用户帐号和口令管理条例
1.概述
第1条随着DXCIP网络建设的发展,内部员工大量使用基于操作系统的账号、基于数据库的账号和基于应用系统的账号,大量账号和口令的使用导致管理极大的复杂化,为了保证各个系统的账号和口令管理保持在一个一致的水平上,特制定本标准。
本标准规定了账号和口令管理的相关职责定义、管理流程。
第2条本条例为DXC各网络系统的用户帐号及口令的使用、维护及处罚的依据。
2.适用范围
第3条本规定适用DXC范围内的各网络系统,包括但不限于各种操作系统,路由器,交换机,数据库,计费、营业和客服等业务应用系统等。
第4条本规定适用DXC范围内的各系统的用户,包括但不限于数据库系统管理员、业务系统管理员、网络管理员、业务系统使用人员、个人计算机使用者、合作软件开发商、系统集成商等。
同样适用于DXC公司范围内所有使用个人计算机及网络的员工。
第5条本部分是符合《DXC信息安全方针》相关规定制定。
主要适用原则为责权一致原则。
3.术语解释
第6条授权用户:
●DXC内部人员:
指与DXC签定“员工聘用协议书”,属于DXC的正式员工。
●使用DXC网络资源的非DXC人员:
指临时到DXC工作不与DXC签定“员工聘用协议书”的人员,包括但不限于开发商、集成商、供应商、顾问、合作人员、实习生、临时工、DXC外包业务人员等,这类人员不是正式员工,不进入DXC的人力资源管理系统。
第7条帐号
●帐号∶指在系统内设定的可以访问本系统内部资源的ID或其他许可形式。
●管理员帐号:
指在系统中具有较大的权限,对网络的运行和安全具有巨大影响的帐号,典型用户为系统管理员。
●超级管理员帐号:
指对系统具有超级权限的帐号,包含但不限于UNIX的ROOT,WINNT的administrators组成员,数据库的DBA等用户。
●公用帐号:
指供一组人使用的帐号,其合法使用人限于一个组内。
●匿名帐号:
只供不确定人员使用的帐号,多用于通过INTERNET的访问。
第8条口令
●口令:
指系统为了鉴别帐号使用人的身份而要求使用人提供的证据,如在数据库系统的口令,NOTES系统的帐号文件及帐号口令。
●健壮口令:
具有足够的长度和复杂度,难于被猜测的口令;强壮的口令具备以下特征:
✓同时具备大写和小写字符
✓同时具备字母、数字和特殊符号,特殊符号举例如下!
@#$%^&*()_+|~-=\`{}[]:
";'<>?
./)
✓8个字符或者以上
✓不是字典上的单词或者汉语拼音
✓不基于个人信息、名字和家庭信息
✓口令不应该记在非经特别保护的纸面上,不能未经加密存储在电子介质中。
口令不应该太难记忆。
●弱口令:
仅由字母、单词、数字或其简单的组合,易于猜测的口令;弱口令有以下特征:
✓口令长度少于8个字符;
✓口令是可以在字典中直接发现的单词;
✓口令比较常见,例如:
o家人名字、朋友名字、同事名字等等
o计算机名字、术语、公司名字、地名、硬件或软件名称
o生日、个人信息、家庭地址、电话
o某种模式的,例如aaabbb、asdfgh、123456、123321等等
o任何上面一种方式倒过来写
o任何上面一种方式带了一个数字
4.帐号设立
第9条系统要求
●DXC所使用的操作系统、业务系统、数据库、网络设备等均需要支持基于帐号的访问控制功能;
●所有需要使用口令的应用软件、业务软件都需要对口令文件提供妥善的保护。
第10条帐号申请原则
●只有授权用户才可以申请系统帐号;
●任何系统的帐号设立必须按照第六节规定的相应流程规定进行;
●员工申请帐号前应该接受适当的培训,以确保能够正常的操作,避免对系统安全造成隐患;
●帐号相应的权限应该以满足用户需要为原则,不得有与用户职责无关的权限;
●对于确因工作需要而必须申请系统帐号的DXC外部人员,则必须经部门主管批准,且有DXC正式员工作为安全责任人,如果需要接触DXC秘密信息,必须通过安全中心审批并且签署保密协议;
●任何系统的帐号必须是可以区分责任人,责任人必须细化到个人,不得以部门或个人组作为责任人;
第11条公用帐号
●系统应当严格限制开设公用帐号,一般情况下公用帐号不得具有访问保密信息和对系统写的权限;
●公用帐号应该设立责任人,负责帐号的正常使用及维护;
第12条匿名帐号
●匿名帐号只被允许访问系统中可公开的且对DXC有益的资源,不得访问任何内部公开及以上秘密等级的资源;
●对匿名用户对系统的访问必须有详细的记录;
5.口令设立
第13条口令的生成
●系统帐号分配时必须同时生成相应的口令,并且与帐号一起传送给用户;
●用户在接受到帐号和口令后,必须马上修改口令,任何时间都不得存在没有口令的帐号,除非该帐号已经失效;
●对于系统的帐号验证只有口令作为证据的系统,如果帐号名由确定的且公开的规则产生的,则口令不应当为公开的口令;
●管理员在传递帐号和口令时,应当采取加密或其他安全的传输途径,以保证口令不会被中途截取。
第14条口令设立的原则
●帐号口令必须是具有足够的长度和复杂度,使口令难于被猜测;
●帐号口令必须是在必要时间或次数内不循环使用;
●帐号的各个口令之间应当是没有直接联系的,以保证不可有以前的口令推知现在的口令;
●帐号的前后两个口令之间的相同部分应当尽量减少,减低由前一个口令分析出后一个口令的机会;
●帐号的口令不应当取有意义的词语或其他符号,如使用者的姓名,生日或其它易于猜测的信息。
第15条口令要求
●普通用户口令长度不得低于6位,最近3个口令不可重复,口令中必须包含字母和数字;
●管理员和超级管理员帐号口令长度不得低于8位,最近6个口令不可重复,口令中必须包含字母和数字,口令中同一个符号出现不得多于2次,各个口令中相同位置的字符相同的不得多于3个,口令不得为有意义的单词或短语;
●所有系统管理员级别的口令(例如root、enable、NTadministrator、DBA等)必需每三个月更换一次,并依照规定进行存档备份。
●所有用户级别的口令(例如email、计费系统用户、notes用户)应每六个月变更一次。
建议4个月变更一次。
●用户所使用的任何具备系统超级用户权限(包括并不限于系统管理员账号和有su权限账号)账号口令必需和这个用户其他账号的口令均不相同。
●当使用SNMP时,communicationstring不允许使用缺省的Public、Private、system和secret等,并且该communicationstring不应该和系统的其他口令相同,应该尽量使用SNMPv2以上的版本。
●重要的系统口令应尽可能采用一次性口令或者双要素口令认证。
6.口令保护
第16条工作中的账号口令不要和个人其他账号口令相同。
尽量做到不同用途使用不同口令,例如:
Unix系统口令和NT系统口令最好不同。
第17条不要把自己口令共享给他人。
第18条这是一个禁止的行为的清单
∙不要在email中写口令
∙不要给你上司口令(特权账号口令备份是个例外)
∙在别人面前谈论的时候,不要提到口令
∙不要暗示自己口令的格式
∙不要在调查中给出口令
∙不要告诉家人口令
∙休假时不要把自己口令告诉他人
第19条如果有任何人需要口令,参照本文档,或者经过部门负责人的特别授权。
第20条不要使用非DXC授权和许可的口令记忆软件。
第21条如果口令可能被破解了,应立即报告部门负责人和上级部门,并且更改所有口令。
第22条口令的更改必须指定两位专人负责,由这两人根据要求定期进行更改。
责任人必须保证口令更改的及时性、有效性,同时必须在“重要口令更改记录表”中进行详细记录,并保证在网设备的口令与记录上的口令保持一致。
第23条“重要口令更改记录表”必须锁放在机房的安全位置,钥匙由两位责任人掌握。
第24条用户账号授权应该满足最小授权和必需知道的原则。
必需知道原则指应该让用户有权限访问他工作中需要用到的信息;最小授权原则指仅让用户能够访问他工作需要的信息,其他信息则不能被该用户访问。
第25条安全专员将不定期进行口令猜测尝试,如果口令被猜出,则用户必需立即更换。
7.变更与取消
第26条帐号的使用
●任何帐号的使用人只限于申请帐号过程中声明的使用人使用,禁止其他人使用此帐号;
●帐号系统正式使用前,必须更改原来系统中的缺省帐号的所有口令,以保证正式环境的安全;
●帐号使用人在使用的过程中,不得使用帐号访问与自己工作无关的资源;
第27条帐号的权限变更
●帐号使用人在工作职责发生转变,造成现有职责与现有的在系统中的职责不同时,应当申请权限的修改;管理员发现用户具有工作不需要的权限,可以直接停止多余的权限;
●帐号使用人在工作职责发生转变,而不再需要使用系统资源的情况下,应当申请关闭帐号;对不能关闭的帐号则需要转移帐号的责任人;
第28条口令的修改
●帐号的使用人应当定期修改帐号口令,修改口令的间隔应小于本标准的相关规定,对于本标准没有规定的用户,其间隔应当小于6个月;
●帐号用户必须在管理员要求更改口令时进行更改口令;如果用户拒绝配合,管理员可以在通知用户及其主管后,关闭用户的帐号,以保证系统的安全;
●帐号用户丢失或遗忘口令,必须通过规定的流程向管理员申请初试化口令,用户在接到回执后,应马上更改口令;
●帐号用户要求口令修改的方式必须是可以确保用户身份的,且管理员必须有记录;
●管理员不可在没有用户申请的时候私自更改用户帐号的口令,除非DXC安全中心需要;
●系统的超级管理员帐号的口令属于系统最高机密,应该严格限定使用范围;其他人员确因工作需要而使用超级管理员帐号和口令的,应当向超级管理员帐号和口令的责任人申请口令,并在完成操作后,由责任人更改口令。
第29条帐号的取消
●用户如果因职责变动而离岗,不再需要系统权限且无须将帐号移交给其他责任人,其原岗位主管应当申请帐号的销户,由管理员取消其权限;
●遇有员工离职,在各系统中撤销相应用户应该是离职手续的一部分。
部门负责人应尽早直接以书面或E-mail的形式(Email形式需要数字签名)要求各系统和网络管理员撤销某员工的口令,管理员执行完后以书面或E-mail的形式向部门负责人和安全专员通报结果。
●用户离职后,管理员应当关闭用户在系统中的所有权限。
8.维护
第30条用户的责任与义务:
●所有用户有义务确保自己的口令的安全,系统帐号与口令不泄漏给他人,同时避免使用弱口令;
●对于使用便携式计算机的用户,应确保设置开机BIOS口令;
●使用远程登陆的用户,确保不将口令保留在计算机上;
●不将系统中使用的帐号和口令用于其他个人应用;
●任何人不得公开其本人或他人口令的全部或部分,除非这种行为不会影响系统帐号的安全性;
●严禁任何人通过任何手段非法取得他人帐号和口令进入系统,对违反者应当进行严厉制裁,直至追究法律责任;
●任何人不得将其帐号的口令告之无权使用此帐号的人,如果用户此种行为导致其他人用此帐号造成对DXC和系统的影响,帐号持有人和造成影响的行为的实施人负有相同的责任;
●严禁任何人利用系统安全漏洞访问其权限之外的资源,一经发现,立即严惩。
第31条在遵守前面规定的情况下,系统管理员的责任与义务:
●确保除匿名帐号外,所有系统用户都必须有口令;
●定期审计,检查系统用户的数量和权限;
●确保系统和网络设备无默认帐号和口令;
●确保关键应用服务器启用口令强制策略;
●对用户进行口令安全培训;
●建议同一个管理员在不同主机上使用不同的帐号和口令。
9.流程
第32条信息系统帐号的开户和权限的变更:
DXC内部人员的信息系统帐号的开户/权限变更按照以下流程进行:
●首先由用户提出书面申请,详细列出所需权限,由其部门主管审批其申请的权限是因为工作需要;
●如果用户申请系统规定的需要高级主管或其他部门主管审批的权限则需要其他部门或高级主管审批;
●如果有必要,由系统中业务部门的负责人员进行用户的要求是否合理的审批;
●然后由安全负责人员审核其安全性,相应负责人员进行开户操作,在以上各审批人的审批环节中,如任何一个审批人不同意该申请,则退回用户的申请。
第33条非DXC人员的信息系统中的开户,除非安全中心有其他规定,否则均按照以下流程进行:
●由接口部门的责任人代替非DXC人员申请,并明确指明责任;
●由非DXC人员的接口部门或以上部门主管进行审批;
●如需要,由其他部门主管审批;
●安全管理人员进行审批、备案;
●业务负责人审批申请的合理性;
●相应负责人员进行开户。
●在以上各审批人的审批环节中,如任意一个审批人不同意用户的申请,则退回用户的申请。
如有明文规定的非DXC人员的开户,按照具体规定执行。
第34条用户因职责变动,而不需要使用信息系统的资源,应当立即销户,DXC内部人员的帐号的销户流程如下:
●用户主管提出申请
●安全控制人员审批并执行(离职人员的帐号由安全控制办人员直接处理)。
第35条非DXC人员的帐号停止使用后,责任人应当负责提出销户,销户流程如下:
●帐号的责任人提出申请
●接口部门的主管审批
●安全中心审批并备案
●安全管理人员操作
第36条例外情况
●安全控制人员在因系统安全原因或紧急情况下,在得到主管部门允许的情况下,不经过以上流程而执行帐号操作;
●因系统升级或迁移等情况下,可以在得到安全中心和相应部门认同的情况下,直接操作而不经过本流程。
第37条对于违反上述规定者的处罚参考相关行政规定。
员工计算机软件安装申请表
编号:
申请部门
申请人
部门负责人
审批
审批日期
软件名称
及版本
软件使用授权证明
信息部
审批结果
安装过程
记录
安装结果
安装人签字
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 用户 帐号 口令 管理条例
![提示](https://static.bdocx.com/images/bang_tan.gif)