帐号口令及权限管理制度Word下载.docx
《帐号口令及权限管理制度Word下载.docx》由会员分享，可在线阅读，更多相关《帐号口令及权限管理制度Word下载.docx（19页珍藏版）》请在冰豆网上搜索。
●本规范制定了适合西藏电信的基本准则和级别划分规则，全公司应该遵照第二章的级别划分要求对所有主机、数据和应用系统进行评估和级别划分，并针对每一级别，遵循第三、四、五章的要求，明确哪些适合于哪些系统。
●评估报告的内容应该包括：
⏹所有主机资产列表
⏹每台主机/服务器/数据库/应用系统需要的帐号、口令和权限保障级别和原因，主要评估方法是根据第二章中每一级别的特征逐条比较，选择最为接近的级别
⏹根据第三、四五章的要求，明确每一级别需要遵守的规范细节
●评估过程和方法应该透明，评估报告随评估结果和相关策略一并提交网络与信息安全办公室。
第2章
帐号、口令和权限管理的级别
2.1关于级别
为了实现西藏电信所有IT信息系统的正常安全运行，我们在这里定义四个口令、帐号和权限管理的保障级别，这些级别确认不同系统对帐号管理的不同需要，不同级别的系统和设备需要不同级别的口令、帐号和权限管理的技术、管理制度和管理流程。
通常来说，价值较低的系统被定义为需要较低的保障级别，价值较高的系统被定义为需要较高的保障级别。
2.2如何确定级别
第一步：
对各系统进行一次风险评估，风险评估的结果能够确定系统需要口令、帐号管理权限的保障级别并揭示由于不恰当的口令、帐号和权限管理给西藏电信和我们的客户所带来的危害和后果。
由于不恰当的口令、帐号和权限管理给西藏电信和我们的客户所带来的危害和后果越严重，需要的安全措施越高，相应地需要的保障级别也越高。
风险评估还应遵照本规范揭示相应的应用系统需要采取何种帐号、口令和权限措施，这些措施应该包括技术措施和管理措施。
第二步：
匹配风险评估揭示的风险和口令、帐号和权限需要的保障级别。
风险评估的结果应该被总结并得出结论，最终结论与下一节定义的各种级别进行比较，选择最为接近的级别作为该资产或者系统需要的口令、帐号和权限保障级别。
当进行确认的时候，应当按照系统没有任何安全措施的情况来进行评估和比较，而不应当在假设某个系统已经使用了某个保障技术的情况下进行比较。
另外对于一个系统的保障应该按照该系统可能受到的所有危害的最高级别来匹配保障级别。
第三步：
确定使用何种口令、帐号和权限管理、技术措施，具体的结论应该以规范制度的形式加以规定。
请注意，由于某些技术本身可能带来一些额外风险，应该确认该技术是否真的达到应用系统对应等级的需求，评估残余风险。
2.3口令、帐号和权限管理级别的定义
本节定义口令、帐号和权限管理需求的四个级别，我们将给出每个级别的特征和相关的例子，级别分成1～4，数字越大表示需要的帐号、口令和权限管理保障信心等级越高。
2.3.1等级1–最低保障
描述
在第一等级保障的情况下，只有基本的甚至没有保障措施用于电子系统的帐号，等级一的情况下，错误的口令、帐号和权限管理可能导致：
●给电信、客户或者第三方带来最小的不便
●不会给电信、客户或者第三方带来直接的经济损失
●不会给电信、客户或者第三方带来不快
●不会给电信、客户或者第三方带来名誉或者地位的损失
●不会破坏电信、客户或者第三方需要执行的商业措施或者交易
●不会导致民事或者刑事犯罪
●不会向XX的组织或个人暴露个人、电信、政府、商业的敏感信息
举例：
●一个公司的内部交流论坛，不用于任何工作目标，可以自行注册帐号并发言，尽管帐号的泄漏会带来一些不便和伪冒，但是由于不用于工作目的，因此不会造成大的损失。
●未验收和未投入使用的系统，工程过程中的系统（假设没有涉及知识产权，例如软件代码泄密的问题的情况下）
2.3.2等级2－低保障级别
通过常用的措施即可保护系统的可信认证，必须充分考虑代价和认证安全性的平衡。
这种等级的认证被误用或者破坏可能导致：
●给电信、客户或者第三方带来较小的不便
●给电信、客户或者第三方带来较小直接的经济损失或者没有直接经济损失
●会给电信、客户或者第三方带来较小的不快
●会给电信、客户或者第三方带来较小名誉或者地位的损失
●存在一定的风险，可能破坏电信、客户或者第三方需要执行的商业措施或者交易
●存在一定风险，可能少量向XX的组织或个人暴露个人、电信、政府、商业的敏感信息
●一台常用办公电脑，该电脑上没有存储任何机密文件，他的帐号被窃取可能导致公司常用信息例如通讯录被泄漏。
●一个有查询系统的帐号，用户可以通过Internet注册来查询自己的帐单。
该帐号失窃可能导致用户信息的泄漏。
2.3.3等级3–坚固保障级别
通常等级三意味着正式的业务流程使用的帐号，通常需要较高信心来保证身份的认证和正确的授权，这种等级的认证被误用或者破坏可能导致：
●给电信、客户或者第三方带来较大的不便
●给电信、客户或者第三方带来较大直接的经济损失或者没有直接经济损失
●会给电信、客户或者第三方带来较大的不快
●会给电信、客户或者第三方带来较大名誉或者地位的损失
●存在较大的风险，会破坏电信、客户或者第三方需要执行的商业措施或者交易
●会导致民事或者刑事犯罪
●存在较大风险，可能大量向XX的组织或个人暴露个人、电信、政府、商业的敏感信息
●一般的主机操作系统、数据库、和路由器的高权限帐号，例如root、administrator、dba等。
●业务系统的关键管理帐号，可以读写重要的用户信息、业务信息和帐单信息。
2.3.4等级4–最高保障等级
等级四的保障通常对应需要非常大的信心保障的系统这种等级的认证被误用或者破坏可能导致：
●给所有电信、客户或者第三方带来巨大的不便
●给电信、客户或者第三方带来极大直接的经济损失或者没有直接经济损失
●会给电信、客户或者第三方带来极大的不快
●会给电信、客户或者第三方带来巨大名誉或者地位的损失
●破坏电信、客户或者第三方需要执行的商业措施或者交易
●大量向XX的组织或个人暴露个人、电信、政府、商业的敏感信息
●关键系统，例如计费系统数据库主机的操作系统和数据库。
●用于存储公司最高商业机密或密级为绝密的系统的认证。
第3章
帐号管理
3.1职责定义
●员工所在班组：
负责发起员工帐号的创建、变更和撤消申请；
●员工所在部门系统管理员：
负责维护和管理业务系统，对业务系统负全责，具体负责帐号的具体生成、变更和删除，并进行定期审计；
●员工所在部门安全管理人员：
负责审批、登记备案用户权限。
3.2口令应该以用户角色定义
电信的帐号应基于统一的角色进行管理。
帐号的角色可以从电信业务角度分或从IT管理角度分。
如果从IT管理角度可以分为以下部分。
3.2.1系统管理员/超级用户
系统管理员和超级用户是有权限对系统的配置、系统最核心信息进行变更帐号的角色，通常每个系统至少具有一个或者一组该类帐号，该类帐号的管理应该最为严格，因为这些帐号可以对系统产生重大影响。
超级用户和系统管理员帐号又可以分为以下二种：
◆系统自带超级用户：
例如unix的root，windows的administrator，数据库的dba，这类用户由于系统缺省使用，通常是口令攻击者的攻击目标，因此必须妥善加以保护。
◆手工定义的超级用户：
基本上所有系统都可以定义基本与系统缺省超级用户等同权限的用户（一般在权限方面略又差别）。
3.2.2普通帐号
普通用户是用户用于访问业务系统，实现日常业务操作的用户，是最为常见的用户类型，例如email帐号、BOSS系统帐号、操作系统普通用户等。
该类用户主要包括以下二类：
◆系统缺省普通帐号，例如unix中的lp、nobody等，这些帐号是系统为了提供服务存在的特殊帐号，常常成为黑客的攻击目标，因此必须进行特别的安全设置和审计。
◆普通帐号：
用于实现业务操作和访问的帐号。
3.2.3第三方用户帐号
第三方帐号通常指由于某种特殊情况，系统允许电信以外的人员和组织访问的帐号。
这类帐号通常包括代维用户帐号、临时故障登录帐号、客户登录帐号。
这些帐号必须进行严格的权限管理和定期审计。
其中客户登录帐号（例如网上营业厅）应给予特别保护。
3.2.4安全审计员帐号
在核心系统中，应该设置安全审计员帐号，该帐号可以对系统安全设置和日志信息进行专门的审计。
3.2.5对于各类帐号的要求
对于我们的四级保障体系，每一级别存在的不同用户类型和需求如下：
系统管理员帐号
普通帐号
第三方帐号
安全审计帐号
第一级别
采用比较复杂的口令，定期修改
无要求
不需要存在
第二级别
第三级别
建议采用增强口令认证
必须存在
第四级别
不允许存在
3.3帐号管理基本要求
3.3.1保障等级一需要遵守的规范
●设备或者应用系统由系统维护部门的系统管理员自行管理和划分权限。
●系统的帐号管理应该支持用户名和口令的机制，口令的存储尽量采用加密的方式；
●系统管理员自行审计和处理帐号的存在和启用是否合理。
3.3.2保障等级二需要遵守的规范
●本级别的需求应至少包括并高于其下等级的所有规范要求；
●非经部门系统管理员授权，不允许匿名账号的存在；
●口令应该以加密方式存储；
●不允许共享账号和口令，除非由部门经理授权，不允许将个人使用的口令告诉他人；
●系统必须打开安全日志，并保存1个月以上的安全日志。
3.3.3保障等级三需要遵守的规范
●要求必须在帐号相关备注字段或者一个集中的数据库中明确帐号的详细信息，至少包括名字、联系电话、email；
●由于系统存在缺省帐号例如root、administrator帐号可能给口令猜测和系统漏洞利用提供方便，因此在可能的情况下可以不使用该类帐号。
在条件许可的情况下，开发并使用一些工具（routine），避免向用户授予超级权限；
●超级用户口令应尽可能采用一次性口令或者双要素口令认证。
超级用户口令要求每个月不定期变更两次以上，普通用户口令要求每个月变更一次；
对于3个月没有使用的帐号应该评估是否删除；
●用户账号授权应该满足最小授权和必需知道的原则。
必需知道原则指应该让用户有权限访问他工作中需要用到的信息；
最小授权原则指仅让用户能够访问他工作需要的信息，其他信息则不能被该用户访问；
●系统必须有严格的安全日志机制并打开安全日志，该安全日志应该收集到部门的专门日志集中管理主机上，日志应该能至少保存过去6个月的日志。
3.3.4保障等级四需要遵守的规范
●每3个月审计用户账号的最后一次使用时间、最后一次变更时间，对于3个月没有使用的账号应进行评估是否删除；
●该级别系统不允许代维或者第三方帐号的存在。
如涉及故障排查，必须增加临时帐号，该帐号必须登记在案，并且排查过程中，电信维护人员全程陪同，排查结束后立即删除临时帐号；
●系统必须打开所有日志，其中包括安全日志。
日志存储在部门的专用日志主机上。
日志应能够保存半年。
3.4帐号管理流程
3.4.1创建用户帐号
●本流程适合需要二级以上保障的系统，一级系统由系统管理员自行和需要帐号的人员协商创建帐号，或者由管理员自行规定创建流程；
●新员工应仔细阅读本规范，了解本规范的要求和流程；
●新到员工的班组确定该员工需要的帐号和权限，通常包括：
email帐号、内部工单系统帐号、该员工参与或者负责的业务系统帐号等，应明确填写需要的帐号及权限，班长填写附表一所示的员工帐号申请表，并由系统管理员签字；
●如果是第三方人员需要申请帐号，必须额外附上该第三方人员获得帐号的相关依据（例如合同、协议以及单独签署的保密协议）。
●系统管理员将申请表提交到部门安全管理人员，部门安全管理人员审计其帐号设置是否符合本规范的要求，并给出具体在系统中开户方式的建议，同时根据需要帐号的级别（关键帐号和非关键帐号）分不同流程进行后续审批；
●关键帐号主要包括二、三级系统的系统管理员帐号和四级系统的所有帐号。
非关键帐号主要包括二、三级系统的非系统管理员帐号；
●对于非关键帐号，部门安全管理人员审批后将申请单交由系统管理员开户即可；
●对于关键帐号，应该由部门安全管理人员提交部门经理进行审批；
●当审批流程均结束后，应该进行帐号的创建，帐号的创建应该由系统管理员完成。
●开户完成后进入通知和备份流程。
系统管理员应该在开户完成后立即通知申请开户的班组。
在开户完成后不允许使用固定的缺省口令，建议由系统使用一个随机口令或者系统管理员为用户设置一个专用口令。
关键系统帐号和口令不允许使用未经加密的邮件发送。
需要开户的员工接收到帐号后应立即修改口令，请选择本规范许可的口令。
用户创建的流程示意图如下：
系统管理员创建帐号
接收帐号，修改密码
部门经理审批
申请不合理
部门安全管理员审批
关键用户申请
非关键
用户申请
流程结束
员工所在班组确定员工需要的帐号、权限，班长填写帐号申请表
系统管理员审批
申请合理
3.4.2变更用户
●本流程适合需要二级以上保障的系统，一级系统由系统管理员自行和确认帐号的变更；
●当员工的岗位发生变化或者其他原因需要变更帐号（此处创建新帐号），因此该员工所在班组应该牵头帐号的变更工作；
●需要变更员工的班组确定变更是否合理，班长填写附表二所示变更表，并提交系统管理员签字确认；
●系统管理员将申请表提交到部门安全管理员，部门安全管理员审计其帐号设置是否符合本规范的要求，并给出具体在系统中变更帐号方式的建议。
同时根据需要变更帐号的级别（关键帐号和非非关键帐号）分不同流程进行后续审批；
●非关键性变更是指修改帐号的名字、帐号的联系方式等非关键信息。
关键性变更主要指权限的变更；
●对于非关键性变更，部门安全管理员审批后将申请单交由系统管理员变更即可；
●对于关键性变更，应该由部门安全管理员提交部门经理进行审批；
●当审批流程均结束后，应该进行帐号的变更；
系统管理员应该在开户完成后立即通知申请需要变更的班组。
用户变更的流程示意图如下：
3.4.3撤销用户
●遇有员工离职，在系统中删除相应的帐号应该是离职手续的一部分；
●员工所在班组应尽早直接以书面方式（见附表3）发出帐号撤消通知书到系统管理员，系统管理员签字确认后提交到部门安全管理员，部门安全管理员根据记录给出该员工目前拥有的帐号，并发送给系统管理员。
●系统管理员接到通知后应该立即暂停该用户权限，并对员工所使用的帐号进行安全审计，审计的主要内容包括该帐号的实际权限是否符合记录、该帐号近期行为（日志）是否符合规范等，同时做好相关备份和交接工作后，删除帐号；
●员工所在班组应该做好部门内部交接工作。
用户撤消的流程示意图如下：
3.4.4定期复审
●网络与信息安全小组必须每半年组织一次对现有用户的复审。
审查是否有下列情况发生：
◆员工实际已经离职，但仍在用户列表上。
◆员工虽然仍在电信工作，但不应该授予他使用某个业务系统的权利。
◆用户情况是否和部门安全管理员备案的用户帐号权限情况一致。
◆是否存在非法帐号或者长期未使用帐号
◆是否存在弱口令帐号
●复审由网络与信息安全办公室汇总打印出用户列表，然后由安全小组进行审查，审查后得出各方签字的报告结论，并由部门的系统管理员进行相关的账号整理、删除工作，部门安全管理员负责帐号的变更情况备案。
第4章
口令管理
4.1通用策略
●所有系统管理员级别的口令（例如root、enable、NTadministrator、DBA等）在没有使用增强口令的情况下，必需按照较短周期进行变更，例如每个月至少变更两次以上。
应该注意关键性帐号信息的定期行备份。
●所有用户级别的口令（例如email、BOSS用户、notes用户）必需定期变更，例如每个月变更一次。
●用户所使用的任何具备系统超级用户权限（包括并不限于系统管理员账号和有sodu权限账号）账号口令必需和这个用户其他账号的口令均不相同。
●如果有双要素认证机制，则以上的要求和下面关于强口令选择的要求可以不考虑。
●口令不能在电子邮件或者其他电子方式下以明文方式传输。
●当使用SNMP时，communicationstring不允许使用缺省的Public、Private和system等，并且该communicationstring不应该和系统的其他口令相同，应该尽量使用SNMPv2以上的版本。
4.2口令指南
口令的设置按照系统需要的不同保障级别需要遵照不同的指南：
●一级保障系统可以不参考本口令指南
●二级保障系统和三级保障系统的普通用户应该参考本指南
●三级保障系统的管理员用户和四级保障系统的所有用户应该严格执行本指南
以上的要求作为一个基本原则，在评估各系统的时候，应该明确各系统中的各类用户实际应该遵守的口令级别的例外情况。
4.2.1口令生成指南
●对于不使用一次性口令牌的账号，用户应该有意识地选择强壮的口令（即难以破解和猜测的口令），弱口令有以下特征：
⏹口令长度少于8个字符；
⏹口令是可以在英文字典中直接发现的英文单词；
⏹口令比较常见，例如：
◆家人名字、朋友名字、同事名字等等
◆计算机名字、术语、公司名字、地名、硬件或软件名称
◆生日、个人信息、家庭地址、电话
◆某种模式的，例如aaabbb、asdfgh、123456、123321等等
◆任何上面一种方式倒过来写
◆任何上面一种方式带了一个数字
●强壮的口令具备以下特征：
⏹同时具备大写和小写字符
⏹同时具备字母、数字和特殊符号，特殊符号举例如下!
@#$%^&
*（）_+|~-=\`{}[]:
"
;
'
<
>
?
./）
⏹8个字符或者以上
⏹不是字典上的单词或者汉语拼音
⏹不基于个人信息、名字和家庭信息
⏹口令不应该记在非经特别保护的纸面上，不能未经加密存储在电子介质中。
口令不应该太难记忆。
4.2.2口令保护指南
●工作中的账号口令不要和个人其他账号口令相同。
尽量做到不同用途使用不同口令，例如：
Unix系统口令和NT系统口令最好不同。
●不要把自己口令共享给他人。
●这是一个禁止的行为的清单
⏹不要在email中写口令
⏹不要给你上司口令（特权账号口令备份是个例外）
⏹在别人面前谈论的时候，不要提到口令
⏹不要暗示自己口令的格式
⏹不要在调查中给出口令
⏹不要告诉家人口令
⏹休假时不要把自己口令告诉他人
●如果有任何人需要口令，请他参照本文档。
●不要使用非电信公司授权和许可的口令记忆软件。
●如果口令可能被破解了，应立即报告网络与信息安全办公室，并且变更所有口令。
●网络与信息安全小组将不定期进行口令猜测尝试，如果口令被猜出，则用户必需立即更换。
第5章
权限管理
5.1概述
电信的帐号和口令管理包括基于帐号的操作或访问控制权限的管理。
帐号是作为访问的主体。
而基于帐号进行操作的目标就是访问的客体。
通常这个客体被称为资源。
对资源的访问控制权限的设定依不同的系统而不同。
从电信帐号管理的角度，可以进行基于角色的访问控制权限的设定。
即对资源的访问控制权限是以角色或组为单位进行授予。
5.2根据工作需要确定最小权限
对帐号的授权，应以其能进行系统管理、操作的最小权限进行授权。
比如这个帐号作为系统帐号只能进行数据备份的操作，那就只授权其可以进行数据备份操作的命令。
别的诸如进行系统网络状态监控的命令则不授权其可以进行。
对于授权，应该支持一定的授权粒度控制，从而控制用户的访问对象和访问行为，保证用户的最小授权。
5.3建立基于角色的权限体系
各系统应该尽力建立基于以下角色模型的授权体系，如由于系统本身的功能限制不能建立模型，则应该尽力向本模型靠拢：
每个应用的操作、命令和数据都可以进行针对角色的分别授权，我们先根据这些操作、命令和数据划分出一些最基本的细分角色，例如对于系统管理员可以细分为数据管理员、备份管理员、用户和角色管理员、开/关机管理员、日常操作维护管理员、灾难恢复管理员等等，然后根据实际的工作岗位建立集成的高级角色，用户可以被赋予一个或者多个高级角色。
具体规范和原则如下：
⏹细分角色根据应用的特性和功能长期存在，基本不随人员和管理岗位的变更而变更
⏹角色对应部门岗位，不对应人员，人员的更换不对角色产生影响，岗位变化
升级会员 