特权账号管理那些事

安全 数据安全
今天我们就来聊一聊特权账户管理方面的相关问题,包括什么是特权账户、特权账户存在哪些风险、特权账户有哪些特点、特权账户管理的难度在哪儿、特权账户如何管理等。

国际权威技术分析与咨询研究公司Gartner公司在2018年、2019年连续两年将“特权账号管理(PAM)”纳入一年一度的“年度十大安全项目回顾”中,而且都是排名第一。那么,到底什么才是特权账户管理呢?

今天我们就来聊一聊特权账户管理方面的相关问题,包括什么是特权账户、特权账户存在哪些风险、特权账户有哪些特点、特权账户管理的难度在哪儿、特权账户如何管理、特权账户管理的核心能力是什么、特权账户管理与其他相关管理系统的关系等。

[[343364]]

一、什么是特权账户

对于特权账户的理解,不同的人有不同看法。有些人认为特权账户就是操作系统中的root账户、数据库中的DBA账户;有些人认为特权账户不应该仅包括root、DBA等超级管理员账户,还应包括操作系统、数据库中的普通权限的账户;还有些人认为特权账户还应该包括其他系统设备中的管理账户,这里的其他系统包括网络设备、安全设备、集中管理控制平台(云管平台、自动化管理平台等)、Web管理后台(Weblogic管理后台、虚拟专用网设备Web管理后台等)等。

依笔者观点,特权账号就是在企业运营过程中,给相关业务运营、系统管理、系统运维等人员赋予的系统维护、权限增加、数据修改删除、导出等高级权限的系统账户。这些账户及其持有人掌握着企业的信息系统的生死大计,绝大部分时间这些账户都在为公司各项业务正常开展保驾护航。然而,道与魔,一念之间。恶念乍起,或者是“无意一指”,这些缺乏管控的特权账户可能就会给公司业务带来灭顶之灾。

判断一个账户是不是特权账户的简单方式就是“这个账号做了一件具有极端破坏性的操作(包括删除、增加权限等),会不会直接对他人、对第三方产生影响,导致他人或第三方无法工作、信息泄露等”,比如OA管理员删除了某个用户的OA账号或者把所有OA账号都删除了,其他用户都用不了OA系统了,你说OA管理员是不是特权账号?再比如某个网络管理员,登录单位防火墙、路由器、交换机把所有的访问策略、路由配置都删除了,你说这个网络管理员账号算不算特权账号?

有时候,特权账号和个人账号在表现形式上可能是一样的,比如都是OA账号、域账号、LDAP统一认证账号等,只是在不同的系统里,该账号被赋予了不同的权限。当作为系统管理员的时候,这个账号就具有某些特权,而成为特权账号。比如某员工是邮件系统管理员,当它通过邮件客户端登录自己邮箱时,他就是普通账号,但是,当他登录邮件系统的管理后台时,此时他就是特权账号。当然,目前有些系统(据我所知,这个“有些”是“很多”)的管理后台账号都是通过单独创建账号的方式,然后将“新账号”账号凭证告诉某位员工,让他成为系统管理员,这时候,该员工具有的特权账号就是这个“账号”,而不是他的OA账号、域账号等。

总的来说,笔者认为:特权账号可分为以下两类场景:一类是以Web业务系统为代表的业务系统及其管理后台的特权账号;另一类是以操作系统、数据库、网络设备等为代表的信息基础设施管理后台的特权账号。这两类账号有什么区别呢?第一类特权账号是可以和员工OA账号或员工号保持一致,而且应该尽量保持一致,员工离职、调岗等异动可以通过删除该员工的账号权限而取消授权;而第二类特权则不一定,这类特权账号以操作系统、数据库、网络设备运维视角设定账号,这类账号一旦设定,不能随意删除,因此,在员工离职、调岗等异动时不能通过删除账号来实现账号权限回收,此时可能的办法就是修改账户登录凭证、限制登录源IP地址等替代手段了。

针对第一类账号,即与员工OA账户一致的Web类应用系统特权账户可以采用与企业内部的SSO与LDAP用户数据库对接,通过LDAP对用户密码进行统一管理。这不属于本文的重点,本文主要关注第二类特权账号的管理问题,即那些LDAP无法管理的特权账号的管理问题。

二、特权账户有哪些特点

分布散。一是特权账号散落分布在业务系统、应用程序、数据库、网络设备、各类应用系统、操作系统中,只要你在企业内能看到的任何一个信息系统都至少有一个特权账号。目之所及,耳之所闻,还有你看不到听不到的系统都包含有特权账号。二是特权账号的持有人分布散,他可能是在数据中心科技运维人员,也可能是企业总部业务、后勤、人力等任何一个部门的人员,还有可能是偏远子分公司的业务运营人员等等。但总的来说,总部科技部门和业务部门应该占有绝大多数。

数量多。企业有多少个信息系统资产(软件、硬件等)就至少有多个少个特权账号,但是,通常情况下,一个信息系统是不可能只有一个人、一个账户进行管理的,因此,一个系统可能会创建多个特权账号。据估算,特权账号的数量可能达到企业信息系统(主机操作系统、数据库、业务系统、管理系统等)数量的5-10倍,甚至更多。

权限大。既然叫特权账号,肯定是具有一定特殊权限,比如增加用户、批量下载数据、执行高权限操作、删除核心数据等。另外,根据业务系统的重要程度,特权账号的所具有特权的风险越大。

三、特权账户存在哪些风险

特权账号保管不善,导致登录凭证泄露、丢失,被恶意攻击者、别有用心者获取,然后被攻击者利用该登录凭证非授权访问业务系统,进而可能导致系统数据被删除、恶意增加管理员权限、非法下载大量数据等。特权账户从创建、使用、保存、注销等全过程更是面临较大泄露风险,比如有些特权账户需要进行多次流转(从超级管理员到普通管理员传递),目前普遍采用邮件、微信的方式的进行传递,有些安全意识较高的可能还进行加密处理,有些安全意识差的或者应急场景,密码明文传输更是比比皆是。攻击者若获取部分的账户、密码可能会对企业进行大范围的横向扩展攻击,导致系统遭受大面积入侵。

特权账号持有者恶意破坏,对自身运维的信息系统进行恶意破坏,比如删库、格式化等操作,比如前一段时间发生的微盟员工恶意删库事件。2020年2月25日,微盟发布公告称:“公司自2月23日19点起发现服务出现故障,大面积服务集群无法响应,生产环境及数据遭受严重破坏。经查,本次故障是由微盟核心运维人员因“个人精神、生活原因”的恶意破坏导致。微盟预计,老用户数据将在2月28日晚上24点前方可完成数据修复。”究其原因,拥有特权账户权限的核心运维人员恶意破坏导致。

特权账号持有者监守自盗,利用自身具有的特权账号非法下载大量数据、查看他人敏感信息等。

特权账号持有者失误操作,人总是会犯错误,特别是在非常疲惫的情况下更容易操作,因特权账号具有较高的维护权限,所作出的操作破坏性更大。比如操作系统运维人员在清理磁盘数据时,没有看清操作路径,使用了rm -rf *.*删除了数据库目录下的所有数据文件等。

四、特权账户管理难点在哪儿

难以掌控企业特权账户的全貌。企业内存在什么特权账户,分布在哪儿,谁在使用这些账户,目前都是一笔糊涂账,缺少长期持续自动发现、持续跟踪的。

难以对特权账号凭证(密码、密钥等)进行动态管理,如定期变更。特权账户数量太多,每个运维人员都需要掌握数个、数十个、甚至数百个特权账户,还有定期密码更替,密码强度等管理要求,对于管理员来说,简直是一个灾难,这就导致通用密码、固定密码等问题无法规避。

缺乏有效的账户凭证传递手段。A系统的特权账户可能不仅一个管理员在运维,还有其他四五个管理员要运维,还可能有其他下游系统的要使用这个账户。如果凭证变更之后不能有效的进行传递,则可能导致下游应用无法进行同步,而导致出现生产故障。

对特权账户凭证集中自动化管理的信心不足。特权账户集中管理之后,特权账户管理员自身可能就不能确定性的掌握账户的密码,这种不确定性导致管理员对特权账户集中管理的信心严重不足,担心集中管理平台自身的风险导致信息系统整体的不可控、不可维护,引发严重的安全事故。

五、特权账户如何管理

对于一个企业安全管理者,在了解了上文关于特权账户的相关内容后,下一步就要关注如何进行管理?有哪些解决方案?按惯例,我们先看成熟的特权账户解决方案有哪些?Gartner在2018、2020年分别发布了一版特权账户管理魔力象限图,图中处于领导者象限的几个企业包括Cyberark、BeyondTrust、Centrify等,可惜的是,一,这些企业在国内有大量业务开展的只有第一个,其他几个还没有什么代理机构,二,这张图中没有国内企业上榜。另外还有IBM、Oracle等企业也有自己特权账户产品。


在此说一个题外八卦,在进行特权账户管理解决方案调研、研究以及测试过程中,国内有几家堡垒机厂商开始宣称自己具有特权账户解决方案。这里就有一个特权账户厂商“鄙视链”。

  • 国外厂商说:国内只有我们是特权账户解决方案,其他都是堡垒机,国内厂商所说的特权账户解决方案都是假的。
  • 国内某厂商:我们是国内唯一特权账户解决方案厂商,其他都是堡垒机,不是真正的特权账户解决方案。
  • 国内其他厂商:我们不光是堡垒机,我们也有特权账户解决方案。

这些都是八卦之谈,那么什么才是特权账户管理应该的姿势呢?在半年多来的学习、测试以及实施过程中,笔者认为特权账号管理的整体方案应该包括账户集中管理、密码管理、账户自动发现、访问管理、提供密码调用服务、流程控制、日常监控、日常审计等。


(1) 账户集中管理:高度分散的特权账户对于安全管控是不可行的,所以笔者认为,特权账户管理的技术防控措施主要思路是“先集中,再施加控制措施”。特权账户只有集中起来才能进行一些有效管理,比如实施统一的安全策略、方便审计等。账户散布各系统,如果不能采用某种手段对特权账户集中托管,显然不适合管理。这是特权账户管理的第一步,需要建立一个统一平台,能够满足多样化系统的密码托管能力。这个平台必须具有良好的平台兼容能力,要不然操作系统一套平台、数据库一套平台,对于特权账户管理来说,仍然存在较大的运维和使用难度。

(2) 密码口令管理:特权账户管理的核心是密码管理,要能通过自动化手段定期对密码进行修改、设置密码安全策略等,使得密码口令满足高复杂度、一机一密、定期修改等要求;

(3) 账户自动发现:不管任何系统,从系统建立到销毁过程的全生命周期中,可能会持续数年,这期间因测试需要、人员变动等原因,系统中可能建立了很多长期未使用的账户。这些账户长期缺乏维护,风险很大。因此,特权账户管理需要具有能够发现一些僵尸账户、多余账户的能力;

(4) 访问管理:这里有几个原因要提供访问管理功能,一是账户密码被托管之后,管理员无法掌握密码之后,集中管理系统得提供一个特权账户的访问通道要不然无法对目标系统进行管理;二是管理员在对目标系统进行管理时,要能提供高危行为阻拦、二次验证等功能。三是统一访问控制通道后不允许再开其他网络访问策略,因此,业务系统管理人员需要主动来联系对接特权账户集中平台,一定程度上避免了“业务系统先上线、安全人员后被动跟进”的困境。访问控制也是国内堡垒机厂商具有核心能力,但是,最近听到国内某传统堡垒机厂商的讲解特权账户解决方案时,竟然把这一块给省略了、弱化了,只是说可以和自家堡垒机联动,把堡垒机和特权账户管理平行起来。笔者认为,堡垒机功能是特权账号解决方案的一个子集,必须纳入特权账号解决方案的整体进行考虑,而不仅仅是联动。

(5) 提供密码调用服务:密码口令托管之后,如果不能提供有效的API接口供下游系统调用,那么,特权账户管理平台要对密码进行定期修改的功能就不能实现。因此,特权账户管理要能为第三方系统提供API调用服务。笔者认为,这是国内堡垒机厂商被排除在PAM厂商之外的主要原因,国内堡垒机很早就具有了账户管理功能,能够托管一些账户密码,但是他们不具有提供API调用能力,导致他们只能修改一些不会被其他人使用的账户密码,需要被其他系统使用的密码只能保持固定不变。

6、流程控制:流程控制最重要的就是在审批流程和特权账号使用流程进行关联,在特权账号的使用流程中设置关键控制点,如在特权账号密码代填方面,必须要经过审批流程批准后才能进行密码下发和填入操作。比如特权账号的危险操作行为,如rm -rf *.*、DROP Database等,必须要经过第二个人的复核或者增加一步验证确认环节。在特权账号的操作流程中增加审批和确认流程,以减少特权账号的误操作和恶意操作风险。

7、日常监控:通过集中的特权账号管理平台,不用监控分析和审计人员再去一一对接海量的业务系统,对用户的操作行为进行识别,阻断高危操作,如rm -rf *.*等,对用户进行UEBA的分析,比如目标系统登录日志出现了非统一访问控制通道发起登录操作,操作日志中短时间出现了大量的新建、删除、修改、批量导出等高危操作,即可判定为异常,从而发出告警,让管理人员进行进行应急响应。

8、日常审计:在风险管理领域,有著名的“三道防线”论,即建设、风险管理和审计。在特权账户管控方面,制度建设、流程建设和技术管控手段都算一道防线,运营监控应该算二道防线。定期事后审计评估安全措施是否落实到位并整改,是安全管控措施的最后一道防线。无论多么好的制度、流程、技术或运营手段,缺少适当的审计措施,都可能存在“制度落实不到位、流程流于形式,技术管控失效”等问题。

六、企业在特权账户管理实施过程中应该关心什么

1. 对多种平台、系统的兼容能力

如果一个平台虽然具有一些特权账号管理能力,但是,只能支持一两种平台和系统的账号管理,那么,它可能不能被称为真正的特权账号管理平台。这也是国内堡垒机厂商被国外厂商诟病主要原因之一吧。目前,典型的特权账号管理平台方案支持的平台和系统类型已经包含以下内容:

  • 操作系统:支持Windows系列(本地及AD域账号)、IBM AS 系列、Linux系列、Unix系列、Aix等
  • 数据库:支持ORACLE、SQL SERVER、SYBASE、MySQL等
  • 网络及安全设备:支持思科、华三、华为、绿盟、360、山石等厂商的交换机、路由器、IDS、网闸、防火墙、带外管理等网络安全设备
  • 支持阿里云、腾讯云等云管理员账号、AccessKey等特权账号托管,并支持对这类账号密码自动更改。
  • 支持通过底层账号自动扫描阿里云、腾讯云已有和新增实例并安全托管账号、自动更改账号密码。

在具备兼容以上已知系统能力的同时,还应具备强大的定制扩展能力,能够快速适应飞速发展的计算机终端、操作系统、数据库等市场。

2. 账户凭证(密码)自动改密的可靠性

一个号称具有自动改密功能的特权账号管理平台,如果在改密过程中老是出错,在实验室环境下,即便改密正确性达到99%也不行,10000个账户改一次错100个,更别说复杂的数据中心环境了,对于系统管理员来说,是不可忍受的。但是,很不幸,目前没有一个权威测评机构进行相应测试验证,所有的可靠性都是厂商自家说辞,没有大面积的应用是很难验证出来的。在这儿,笔者认为可以多与其他甲方进行调研,问问别人用什么,有没有什么坑,然后选口碑好的、应用时间长的。

3. 特权账号平台自身的安全性和鲁棒性

平台自身的安全性和鲁棒性主要关心该方案有没有充分考虑备份、灾备切换、灾难恢复、信息安全等措施。在甲方实施时,有没有典型的部署、实施以及实践经验。

4. 密码调用接口的稳定性和安全性

一方面,随着特权账户管理平台纳管的目标数量越来越多,未来,将会有越来越多的系统需要调用该系统的密码获取接口,这个接口的稳定性至关重要,不能发生严重的服务不可用问题。另一方面,密码调用接口本身要具有访问控制、密码安全传输、接口认证、防批量拉取等能力,否则的话,该平台将可能会变成一个集中的密码泄露通道。还要能支持不同应用的密码获取,比如支持应用系统源码、配置文件(包括txt、ini等)、API接口账号、服务账号、计划任务、中间件数据源密码等

5. 横向扩展能力

企业信息化过程中是个逐步深入的过程,随着时间的推移,企业的信息系统数量、数据中心数量将会不断增加,因此,一个优秀的特权账户管理平台必须要具备强大的横向扩展能力,满足企业快速信息化过程中的特权账户管控要求。

七、其他可能关心的问题

1. 特权账户管理系统与堡垒机的关系

每一个第一次接触特权账户管理的人,听了特权账户管理的相关功能之后,都会有一个疑问,他和堡垒机是什么关系?在此有几个观点分享给读者:一是特权账户管理本身就有堡垒机功能,就像前文说的,堡垒机功能是特权账户管理的子集,从某种意义上讲,特权账户管理解决方案可以完全替代堡垒机方案。二是如果非要在他们之间找出什么不同,那么,我认为堡垒机核心功能是对目标主机访问管道的控制,而特权账户管理核心功能是对目标主机账户口令的管理。三是国内堡垒机厂商在过去的解决方案中,过多的关注了访问控制,对密码管理、密码API接口服务支持能力不足,的确也不能称为特权账户解决方案。四是随着时间的发展,我觉得特权账户解决方案的已经基本成型,就像汽车一样,一个发动机,一副车架,四个车轱辘,一百年没变,未来国内堡垒机厂商肯定也会朝着这个方向发展。

2. 特权账户管理系统与LDAP/IAM系统的关系

谈到账户,另一个比较疑惑的问题就是特权账户管理系统与LDAP/IAM系统的关系,特权账户管理系统管理的账户是机器上的账户;而LDAP/IAM系统管理的账户是人的账户,其关系如下图所示(图中的特权账户root、dba只是示例,实际情况比这范围大很多)。用户使用LDAP账户经过双因素认证之后登录特权账户系统,特权账户管理系统对目标系统的特权账户进行纳管。然后,将托管的账户授权给相应的LDAP账户管理员进行管理。


3. 特权账户管理系统在网络攻防中的价值

有安全圈朋友说过,弱口令,各种弱口令,系统弱口令、应用弱口令、用户弱口令,如果解决好了口令的问题,我认为可以解决企业至少50%的安全问题。攻击者在进行渗透攻击时,除了用漏洞打的,很多攻击落脚点还是用户账号,通过弱密码、通用密码进行单点突破、横向移动。如果有个平台能够实现账户密码都是强密码,而且真正是一机一密,一个账户一个密码,那么,内网横向攻击估计就没那么简单了吗?

八、结束语

从技术上看,现在市场上“特权账号管理”的相关解决方案的确是一种比较好的特权账号管理解决方案;但是,从甲方企业视角看特权账号管理,他们的解决方案只是企业特权账号管理整体解决方案的一个点或几个点。做个类比,如果把企业安全建设看作是一个“战略”,企业特权账号管理一个“战术行动”,以上公司提供的解决方案最多只能算“一场战役或几个战役”。

不过这几场战役可能是特权账号管理中的“重点战役”、“核心战役”,但是如果没有其他“战役”做支持,单靠这几个战役是很难达成“战术目的”。甲方企业的特权账号管理必须要从制度建设、流程控制、技术管控与监控审计等多个方面拿出整体解决方案,才能在特权账号管理领域形成较为有效的安全管控能力,建设特权账户管理平台只是一个开始。

 

责任编辑:赵宁宁 来源: FreeBuf
相关推荐

2015-11-16 23:49:39

2013-06-05 16:44:33

Linux系统用户账号管理

2013-10-14 09:28:52

网络管理网络优化

2012-05-01 08:06:49

手机

2011-05-19 16:47:50

软件测试

2024-02-04 17:03:30

2017-05-15 21:50:54

Linux引号

2011-08-22 16:42:43

SqliteiPad

2014-06-06 16:08:17

初志科技

2021-10-19 21:39:51

Unsafe构造器内存

2015-05-28 14:02:09

JavaJava日志性

2011-12-02 10:32:23

Java

2012-01-02 19:30:22

iPad

2011-09-19 15:40:35

2011-07-04 15:30:24

Qt 布局 GridLayout

2015-09-14 09:16:17

iOS统计打点

2009-07-29 10:36:04

北电收购

2020-07-29 08:14:59

云计算云迁移IT

2011-06-30 14:34:17

QT Tablewidge QTableWidg

2010-07-26 11:02:19

Perl模式匹配
点赞
收藏

51CTO技术栈公众号