- 对本书的赞誉
- 序一
- 序二
- 序三
- 前言
- 第一部分 安全架构
- 第 1 章 企业信息安全建设简介
- 第 2 章 金融行业的信息安全
- 第 3 章 安全规划
- 第 4 章 内控合规管理
- 第 5 章 安全团队建设
- 第 6 章 安全培训
- 第 7 章 外包安全管理
- 第 8 章 安全考核
- 第 9 章 安全认证
- 第 10 章 安全预算、总结与汇报
- 第二部分 安全技术实战
- 第 11 章 互联网应用安全
- 第 12 章 移动应用安全
- 第 13 章 企业内网安全
- 第 14 章 数据安全
- 第 15 章 业务安全
- 第 16 章 邮件安全
- 第 17 章 活动目录安全
- 第 18 章 安全热点解决方案
- 第 19 章 安全检测
- 第 20 章 安全运营
- 第 21 章 安全运营中心
- 第 22 章 安全资产管理和矩阵式监控
- 第 23 章 应急响应
- 第 24 章 安全趋势和安全从业者的未来
- 附录
18.4 堡垒机管理
堡垒机的介绍与安全加固,已经在企业内网安全这一章(第 13 章)讲过了,本节主要针对企业实际管理过程中的一些问题进行阐述。
1.用户与权限管理
堡垒机的用户一般分为:系统管理员、业务或开发人员、外包人员,以及值班或应急公用账号。不同的用户,建议有不同的认证等级或启停控制,如表 18-1 所示。
表 18-1 堡垒机用户认证等级与启停控制
用户认证通过后,所能登录的设备以及登录设备的用户权限也需要进行统一规划和管理,建议示例如表 18-2 所示。
表 18-2 堡垒机用户登录设备与权限控制
以上过程中涉及账号启停的,最好实现一键化、自动化,即 ITIL 提单审批后,账号自动开启;系统管理员给外包人员开启账号时也是一键开启;给开发或业务人员授权的,也可以做成一键自动提权,否则太繁琐了不太容易执行。
最后,人员变动特别是员工离职,除了进行账号与权限清理外,还需要有自动化的对比机制,比如,账号每天自动与 HR 或 AD 等系统对比,若发现问题及时报警处置,防止因工作疏忽导致的离职员工账号未清理类审计问题。
2.机器纳管与口令变更
一台机器,需要经过哪些流程才允许上线?上线前扫描、被堡垒机纳管、采集安全日志等都是必要的。堡垒机纳管设备,除了登记 IP、机器名、所属业务系统、负责人等之外,一般还要求上收用户账号与口令。
口令上收后,可以实现自动登录,无须用户再输入账号密码了。堡垒机有了账号口令,便可以进行自动化的口令变更,按照一定的规则生成复杂密码,然后定期修改口令。实际运维过程中,如果有因口令变更失败而导致的纳管机器无法自动登录的情形,需要自动化的手段来发现以及重置,发现问题并不难,重置密码则需要与自动化运维平台对接。
为了防止堡垒机出问题而无法登录,或者因堡垒机变更密码导致系统无法登录,一般都会保留一个应急账号,密码保存在堡垒机里,当需要取出时提单申请打印密码信封即可。当有打印密码信封事件触发时,安全人员会审核是否正常。
最后,所有设备的账号密码都保存在堡垒机系统里,堡垒机本身是否安全,密钥是否硬编码,都需要考虑。有的产品为了安全性会引入加密机,那么加密机的管理也是一个需要关注的问题,我们将在 18.5 节中讨论。
3.高可用架构与设计
正常的运维登录都通过堡垒机之后,堡垒机的安全性和可用性要求就变得非常苛刻了。安全性已经在第 13 章中重点讲过了,这里讨论与可用性相关的内容。
一般堡垒机分为访问服务器和后台服务器,访问服务器主要负责将用户的登录请求转接到后台(比如 RDP 和 SSH),而后台服务器则保存用户权限、主机用户密码等相关信息。这两部分都需要做好高可用架构设计。数据库的高可用(如 Oracle 的 RAC,MySQL 的主从复制读写分离等)都有成熟的技术,访问服务器则可以借助类似 F5 或 LVS 的技术实现负载均衡,由于涉及会话连接等,需要注意会话保持相关的设置。有些做得好的应用,甚至会将一些后台权限、设备口令等信息通过加密缓存到访问服务器上,这样即使整个后台服务全挂了,也能让已有用户正常登录,只是新用户、新设备等无法管理。
4.应急通道与绕过发现
为了防止出现堡垒机彻底用不了的情况,企业一般都会保留应急通道,比如允许固定的机器访问固定的管理服务器等。这里需要注意应急通道的演练。平常大家都习惯了堡垒机的使用,往往就会忽视所谓的应急通道。建议的方法是,每月对一线员工进行不定期抽查,要求其模拟堡垒机无法使用的情况时该如何处置,并签字确认归档。抽查应急通道的目的是:一方面督促大家学习;另一方面备案备查。
有的管理员会尝试绕过堡垒机,比如将 RDP 或 SSH 端口监听放在别的端口,这样在网络防火墙会存在绕过的情况,绕过堡垒机就缺乏监管,管理员在目标机器上的操作也无法审计。针对这种情况,可以利用下一代防火墙基于应用协议做规则,也可以使用事后监测手段。在终端上监测远程桌面、SecureCRT 等进程的网络访问情况,也可以在网络上使用异常访问检测系统监测触发 RDP 和 SSH 协议的目标端口是否为正常端口,这些都是不错的思路。笔者在实际工作中就曾经发现一起外包人员私自将 RDP 端口修改为非 3389 端口,在 ECC 电脑上直接远程桌面维护的情况。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论