中国移动规范学习——4A技术要求(综述)

4A:账号管理、认证、授权、审计

这个安全管理框架包括用户的账号(Account)管理、认证(Authentication)管理、授权

(Authorization)管理和安全审计(Audit),简称4A框架。

账号管理是将自然人与其拥有的所有系统账号关联,集中进行管理,包括按照密码策略自动更改密码,不同系统间的账号同步等。

身份认证是信息安全的第一道防线,用以实现支撑系统对操作者身份的合法性检查。对信息统中的各种服务和应用来说,身份认证是一个基本的安全考虑。身份认证的方式可以有多种,包括静态口令方式、动态口令方式、基于公钥证书的认证方式以及基于各种生物特征的认证方式。

授权是指对用户使用支撑系统资源的具体情况进行合理分配的技术,实现不同用户对系统不同部分资源的访问。

审计是指收集、记录用户对支撑系统资源的使用情况,以便于统计用户对网络资源的访问情况,并且在出现安全事故时,可以追踪原因,追究相关人员的责任,以减少由于内部计算机用户滥用网络资源造成的安全危害。

本文在对中国移动各支撑系统的主机、网络设备和应用系统自身的账号管理、认证、授权、审计现状分析的基础上,制定4A框架技术要求,其目的是:

1. 阐述4A基本技术,规定4A框架下各部分的基本需求,为4A框架下的产品采购提供依据。

2. 规定4A框架下各部分的连接界面,为4A框架下的产品开发提供依据。

3. 规定将应用系统纳入4A框架的方案,便于在现有基础上实施4A框架。

4. 提出4A框架实施的具体建议。

通过实施4A框架,可以达到以下目的:

1. 实现集中化的账号管理。管理员在一点上即可对不同系统中的账号进行管理,由系统自动同步不同系统下的账号;账号创建、分配过程均留下电子记录,便于审计。

2. 实现集中化的身份认证。管理员不仅可以根据需要选择不同的身份认证方式,而且在不更改或只对应用进行有限更改的情况下,即可在原来只有弱身份认证手段的应用上,增加强身份认证手段,提高系统安全性。

3. 实现集中访问授权。对企业资产进行有效保护,防止私自授权或权限未及时收回对企业信息资产造成的安全损害;对应用实现基于角色的授权管理,在人员离职、岗位变动时,只需要在一处进行更改,即可在所有纳入4A框架的应用中改变权限;可以为授权增加特定的限制,如只有在规定的时间段、来自特定地域的人员才能访问指定的资源。

4. 实现集中安全审计管理。不仅能够对人员的登录过程、登录后进行的操作进行审计,而且能够将多个主机、设备、应用日志进行对比分析,从中发现问题。

实现单点登录,方便管理员和普通用户登录不同的系统。

账号口令管理现状与面临的困难

1、中国移动的支撑系统中有大量的网络设备、主机系统和应用系统,分别属于不同的部门和不同的业务系统。目前各应用系统都有一套独立的认证、授权和审计系统,并且由相应的系统管理员负责维护和管理。当维护人员同时对多个系统进行维护时,工作复杂度会成倍增加。例如,集团公司网管中心有20多套网管系统,其中主机、网络设备超过100台;管理着CMNet网络中200多套路由器、交换机等网络设备。

2、各系统分别管理所属的系统资源,为本系统的用户分配权限,缺乏集中统一的资源授权管理平台,无法严格按照最小权限原则分配权限。另外,随着用户数量的增加,权限管理任务越来越重,系统的安全性无法得到充分保证。

3、有些账号多人共用,不仅在发生安全事故,难于确定账号的实际使用者,而且在平时难于对账号的扩散范围进行控制,容易造成安全漏洞。

4、支撑系统的增多,使用户经常需要在各个系统之间切换,每次从一个系统切换到另一支撑系统时,都需要输入用户名和口令进行登录。给用户的工作带来不便,影响了工作效率。用户为便于记忆口令会采用较简单的口令或将多个支撑系统的口令设置成相同的,危害到系统的安全性。

5、由于各支撑系统独立运行、维护和管理,所以各系统的审计也是相互独立的,不但各个系统单独审计,即使同一系统中的每个网络设备,每个主机系统,每个业务系统及每个数据库系统都要分别进行审计,缺乏集中统一的系统访问审计。无法对支撑系统进行综合分析,不能及时发现入侵行为。

总之,随着业务系统和支撑系统的发展及内部用户的增加,一方面系统维护和管理人员的工作负担增加,工作效率无法提高;另一方面无法对各业务系统实现统一的安全策略,从而在实质上降低了业务系统的安全性。因此需要根据中国移动的现状,研究集中统一的安全管理技术和平台,使得系统和安全管理人员可以对支撑系统的用户和各种资源进行集中管理、集中权限分配、集中审计,从技术上保证支撑系统安全策略的实施。

【中国移动4A框架】

4A框架结构如图所示。

clip_image001

4A用例描述】

 

管理员工作过程】

在4A框架下,集中化的用户账号管理主要包括如下部分:

1、角色定义

在企业范围内定义、维护角色。

2、角色授权

对角色赋予相应权限,权限包括允许访问的对象,及对对象的访问方式。

3、用户创建

建立用户,用户信息与实际人员对应。

4、分配角色

根据用户的工作部门和岗位,为用户分配相应的角色。

5、策略制定

包括口令策略制定、访问策略制定等。

6、账号管理

包括账号收集(发现)、账号同步、账号增加、账号删除等。

7、安全审计

根据安全记录,及时发现各种入侵行为,或可能对系统造成危害的操作;在发生事故后,能够及时、准确定位事故原因及责任。

 

普通用户工作过程】

在4A框架下,用户获取、行使访问权限的过程可以分为以下几步:

1、用户创建

通过管理员或用户自助注册系统建立用户,用户信息与实际人员的身份识别标志对应。

2、获得授权

由管理员分配角色,基于角色,用户获得访问支撑系统相关资源的权限。

3、登录系统访问资源

用户登录到支撑系统,根据身份认证结果及为其分配的角色,与支撑系统交互。如果采用SSO,则用户只需要在系统启动后,用SSO主账号登录到SSO服务器,以后再登录其它主机、网络设备、应用系统时,其登录过程由系统自动完成,用户不再需要记忆多个密码、进行多次登录。

 

4A框架的价值】

4A框架的作用主要体现在系统管理员方面、普通用户方面、系统安全性、系统管理费用等方面。

【企业角度】

对于企业来说,由于企业内部账号、授权管理的混乱,造成私设账号、账号失效后未及时收回、某些账号的扩散范围难于控制,从而给企业造成的安全损失是很严重的。

在4A框架下,账号、授权管理将纳入统一、可控的框架和过程,账号设置、分配均有详细记录,可以审计;账号撤消、更改后的同步工作(包括从集中账号管理系统向各主机、设备、系统下发账号,及集中账号管理系统从各主机、设备、系统收集账号)均由系统自动完成,避免手工同步;对账号的有效期可以用时间、地域等附加因素进行限制,防止滥用;在多人共用账号的情况下,审计也可以精确到实际使用账号的个人;针对高价值资产、高权限账号,通过灵活支持动态口令、PKI、生物认证等强认证技术,提高信息资产的安全性,并实现不同权限等级账号的不同安全策略。

这些措施无疑将给企业信息资产的安全防护提供强有力的手段,避免安全损失,同时通过保障企业内主机、设备、应用系统的顺畅运行,给企业增加效益。

【管理员角度】

采用4A框架,方便了系统中包括从系统用户聘用到辞职的整个生命周期的管理。如账号创建、授权、权限更改、个人信息更改、口令更改、账号删除等,均可在一个平台上进行管理,使用户与其账号的对应关系符合实际情况,保证用户拥有的权限是完成其工作所需的最小权限。

通过4A框架,系统管理员可以方便高效地对支撑系统进行审计,及时发现未授权的信息资源访问,权限滥用,入侵企图等等。

4A框架还为安全策略的强制统一执行提供技术保证,如监测用户口令的强度,口令更改周期等等。

减少由于用户忘记密码产生的维护成本。

这些都使管理员对信息资源管理的效率大大提高。

【普通用户的角度】

通过4A框架,可以保证用户权限的分配符合安全策略要求,拥有完成任务所需要的最小权限。

用户可以通过4A框架提供的自助管理接口,可以方便地更改自己的口令和个人基本信息,减轻了系统管理员的工作负担,也提高了用户的工作效率。

通过4A框架提供的单点登录系统,用户一次登录即可方便地访问被授权的所有系统,省去了记忆多个账号名和口令的麻烦,提高了工作效率。

【系统安全角度】

4A框架可以使用户的工作变动情况及时在支撑系统中得到体现,通过集中平台,一个指令,即可以干净、彻底的清除与每个用户相关的所有账号,防止出现用户已经离职但账号还存在的情况。

另外4A框架为安全策略的强制执行提供了技术手段,如单点登录系统可以为用户在不同应用系统中自动设置足够强的口令,并且可以自动定期修改口令。这种设置和修改对用户是透明的,用户只需记住登录到单点登录系统的口令即可,提高了用户的效率,防止弱口令的存在。

通过方便高效的审计手段,可以及时发现系统中存在的安全问题和各种入侵企图,为安全管理员采取相应的措施提供及时准确的信息,增强系统的安全性。

【系统管理成本角度】

用户自我服务使用户可以维护自己的信息,单点登录减少了用户忘记口令的情况,这都使得系统的管理成本,尤其是在用户数目巨大的情况下大幅度降低。


1 概述 7 1.1 范围 7 1.2 规范性引用文件 7 1.3 术语、定义和缩略语 7 2 综述 8 2.1 背景和现状分析 8 2.2 4A平台建设目标 9 2.3 4A平台管理范围 10 3 4A管理平台总体框架 11 4 4A管理平台功能要求 14 4.1 帐号管理 14 4.1.1 帐号管理的范围 14 4.1.2 帐号管理的内容 14 4.1.3 主帐号管理 14 4.1.4 从帐号管理 15 4.1.5 密码策略管理 15 4.2 认证管理 15 4.2.1 认证管理的范围 16 4.2.2 认证管理的内容 16 4.2.3 认证服务的管理 16 4.2.4 认证枢纽的管理 16 4.2.5 SSO的管理 17 4.2.6 认证手段 17 4.2.7 提供多种手段的组合使用 17 4.3 授权管理 17 4.3.1 授权管理的范围 17 4.3.2 授权管理的内容 18 4.3.3 资源管理 18 4.3.4 角色管理 18 4.3.5 资源授权 19 4.4 审计管理 20 4.4.1 审计管理范围 20 4.4.2 审计信息收集与标准化 21 4.4.3 审计分析 21 4.4.4 审计预警 22 4.5 4A管理平台的自管理 23 4.5.1 管理员管理 23 4.5.2 权限管理 23 4.5.3 组件管理 23 4.5.4 运行管理 23 4.5.5 备份管理 23 4.6 4A管理平台接口管理 24 4.6.1 帐号管理接口 24 4.6.2 认证接口 24 4.6.3 审计接口 24 4.6.4 外部管理接口 25 5 4A管理平台技术要求 25 5.1 总体技术框架 25 5.2 PORTAL层技术要求 27 5.3 应用层技术要求 27 5.3.1 前台应用层技术要求 27 5.3.2 核心数据库技术要求 28 5.3.3 后台服务层技术要求 30 5.3.4 单点登录技术要求 32 5.3.5 安全审计技术要求 33 5.4 接口层技术要求 35 5.5 非功能性技术要求 35 5.5.1 业务连续性要求 35 5.5.2 开放性和可扩展性要求 38 5.5.3 性能要求 38 5.5.4 安全性要求 38 6 4A管理平台接口规范 40 6.1 应用接口技术规范 40 6.1.1 总体描述 40 6.1.2 登录类接口(①) 41 6.1.3 认证类接口 42 6.1.4 帐号/角色接口(④) 43 6.1.5 审计类接口 48 6.2 系统接口技术规范 51 6.2.1 总体描述 51 6.2.2 登录类接口(①) 52 6.2.3 认证类接口 53 6.2.4 帐号接口(⑤) 55 6.2.5 审计类接口 59 6.3 外部管理接口技术规范 61 7 BOSS系统3.0的改造要求 62 7.1 BOSS应用安全建设目标 62 7.2 BOSS系统配合4A改造要求 62 7.2.1 总体改造总体要求 62 7.2.2 帐号管理要求 64 7.2.3 授权管理要求 66 7.2.4 认证管理要求 67 7.2.5 审计管理要求 69 7.3 BOSS应用的安全要求 70 7.3.1 BOSS应用帐号管理 71 7.3.2 BOSS应用授权管理 73 7.3.3 BOSS应用认证管理 75 7.3.4 BOSS应用审计要求 76 7.3.5 BOSS数据安全要求 77 8 经营分析系统2.0改造要求 79 8.1 经营分析系统应用安全建设目标 79 8.2 经营分析系统配合4A改造要求 79 8.2.1 总体改造要求 79 8.2.2 帐号管理改造要求 81 8.2.3 授权管理改造要求 83 8.2.4 认证管理改造要求 84 8.2.5 审计管理改造要求 86 8.3 经营分析系统应用安全要求 87 8.3.1 经营分析系统用户管理 88 8.3.2 经营分析系统权限管理 92 8.3.3 经营分析系统认证管理 93 8.3.4 经营分析系统日志记录 95 8.3.5 经营分析系统数据安全要求 95 8.3.6 系统平台安全要求 97 9 运营管理系统2.0改造要求 99 9.1 运营管理系统应用安全建设目标 99 9.2 运营管理系统配合4A改造要求 99 9.2.1 总体改造要求 99 9.2.2 帐号管理改造要求 101 9.2.3 授权管理改造要求 103 9.2.4 认证管理改造要求 104 9.2.5 审计管理改造要求 106 9.3 运营管理系统应用安全要求 107 9.3.1 运营管理系统用户管理 108 9.3.2 运营管理系统权限管理 111 9.3.3 运营管理系统认证管理 112 9.3.4 运营管理系统日志记录 113 9.3.5 运营管理系统数据安全要求 114 10 4A平台建设指导意见 116 10.1 总体指导原则 116 10.2 4A平台建设步骤 116 10.2.1 前期调研和准备阶段 116 10.2.2 平台建设和实施阶段 117 10.2.3 后期管理和维护阶段 118 10.3 4A平台应急方案 119 10.3.1 应急方案流程梳理 119 10.3.2 应用功能改造实现 119 11 编制历史 120 附录A 4A管理平台管理流程 121 (1)用户入职流程 122 (2)用户变更管理流程 123 (3)离职管理流程 124 (4)新项目纳入管理流程 125 附录B 业务支撑系统敏感数据 125 (1)BOSS系统中的敏感数据 125 (2)经营分析系统中的敏感数据 126 (3)需要关注的操作日志 127
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值