安全管理是高校信息化日常管理中的重点任务，运维管理与安全管理是一个相互叠加交织的动态管理过程，涉及校内、校外的参与方众多，运维对象类型各异，且在主观因素上，运维人员技术素养的悬殊差别也可能导致各类问题。因此，通过一套运维堡垒机来贯穿日常的技术运维显得尤为重要。

基本功能定位

　　运维保障工作面临的主要挑战集中在资产账号管理与共享、授权分配与身份识别及操作过程监督三个方面，堡垒机核心能力的定位也围绕集中授权管理，操作过程约束与规范，审核安全行为这三个方面展开。

　　运维对象

　　受管运维对象普遍被堡垒机命名为资产，按照运维方式，可以分为命令行字符、桌面图形、指定客户端应用三个大类。

　　以命令行字符方式进行运维的设备类型较为广泛，网络设备的交换机、路由器，服务器中的Linux、UNIX都可以通过ssh进行远程运维。

　　在这类受管资产的功能规划中，需注意x11 forwarding(xdmcp)、本地端口转发及sftp支持的完备性，这些特性在实际运维过程中虽然不是必备，但能为运维过程管理增添更多可塑性，并且对受管设备的文件传输，Web页面功能普遍不能做到文件夹下载和多文件上传、下载，相应功能有赖sftp客户端的支持来补足。除此之外，telnet会作为各个堡垒机的标配协议，但因为telnet的安全性较弱一般不推荐使用。

　　桌面图形以Windows的RDP和Linux的VNC两个大类为主开展运维。RDP协议的考察重点在网络级身份验证的支持，这一加密特性对运维会话的安全性起到保护作用，而VNC则需注意Linux桌面默认启用了屏保，若堡垒机代管了VNC密码则需取消相应设置以避免第二次进入VNC时无法代填密码。

　　指定的客户端，如navicat、plsql、Toad等数据库客户端、浏览器，以及定制开发的C/S应用客户端，这类应用的分散性是日常运维监管中的痛点。

　　在堡垒机上的实现方式主要是虚拟应用发布，该方式以屏幕变化量显示在Windows运行的客户端程序窗口界面，从而实现客户端应用的远程管理，运维用户仅需堡垒机的插件，无须安装C/S应用的客户端，根据堡垒机厂家的研发能力，还能进一步实现客户端账号的代填与账号管控。

　　权限

　　对运维工作而言，基于角色的访问控制无疑是对运维用户最佳的权限管控模式，超级管理员、配置管理员、审计管理员、操作员等每种角色都可以按层级、按部门或按人员类别实现分组授权与权限继承，该功能的重点在权限配置灵活性满足了运维的各种场景。

　　资产的访问权限，是堡垒机与其他基础设施设备的突出区别，每个运维对象可以使用的登录账号及密码由堡垒机集中管理，每个运维用户针对每个资产允许使用的登录账号须一对一可配置，才能从权限分配的角度实现管控的精细化。

　　审计

　　作为安全设备，审计功能是核心能力，图形界面的录屏，命令行的指令与文本编辑，数据库SQL语句等每一个操作细节，都需要完整记录，可追溯，可查询，可持久保存，相应的日志和保存的记录应可同步到其他存储空间，在此基础上，可自定义高危操作命令以实现阻断或操作复核。

　　需要注意的是，录屏所选取的编码压缩方案对细节的丢失，录屏对切片间隔与基于起止时间搜索的优化，以及图形界面剪切板操作记录便于回溯信息泄漏。

技术架构探讨

　　运维关系到生产环境的稳定性、规范性和安全性，等保2.0也对运维过程提出了“事前预防、事中控制、事后审计”的明确要求。基于此，我们在评测与选择堡垒机时，对其自身技术架构的安全性、合理性，以及从宏观设计到微观功能落地方式都有了更多考量，下图所示为堡垒机技术架构示意图。

普通运维堡垒机技术架构示意图

　　基础设施服务是堡垒机自身运行不可或缺的支撑服务，如NTP用于校准时间并精确记录日志，邮件服务发送各类交互信息，DNS服务解析B/S应用，LDAP/AD对接运维用户身份认证等，它们是堡垒机技术架构运行依赖的服务。

　　面向运维用户，堡垒机仅开放有限的端口，包括SSH客户端、RDP客户端、Web入口界面等运维对象的连接操作都以堡垒机的IP作为入口。

　　暴露的端口越少，屏蔽运维对象的信息越多，对安全的帮助越大，该入口可根据设备的健壮性和运维环境的要求，发布在互联网或通过VPN进行连接。

　　当运维用户发起的运维对象是RDP和SSH时，堡垒机作为代理转发请求到真实的运维对象相应的端口，这些运维对象仅需向堡垒机开放端口。

　　应用服务在安装堡垒机专有插件后，作为堡垒机能力的扩展，以虚拟应用的形式向运维用户提供应用程序的窗口界面，这里的应用程序指Windows上运行的B/S和C/S应用程序，如浏览器，数据库客户端，定制开发的应用系统等，这些应用都安装并运行在应用服务这个角色中。

　　该角色本身部署了终端服务的Windows服务器，用户一端接收和操作的只是窗口的屏幕变化量，不用安装对应的B/S和C/S客户端，所有真实的连接发生在应用服务和运维对象之间，运维对象仅需向堡垒机或应用服务开放端口，同时堡垒机配置和约束B/S、C/S允许运维用户访问的URL、IP、账号等资产信息。

　　B/S应用最典型的莫过于各种设备带外管理和系统的后台管理等Web界面，这些Web界面在防火墙防护策略中很难精准对应到运维人员，而堡垒机则解决了这一痛点。

　　自身健壮性

　　堡垒机实现了众多运维管理的手段，既是对运维操作行为的约束，也给运维活动带来了较大依赖。

　　一方面是其自身的安全性，众多资产对象的信息、托管的密码都集中在一个“篮子”中，牵一发而动全身；

　　另一方面是在较大的运维压力和潜在攻击下，其自身容易成为单点故障点，因其失效导致不可控的运维事故。

　　基于此，堡垒机要能经得起各种攻击手段的渗透和流量压力，也要具备扩展为高可用的多机集群能力，对托管的账号密码采用恰当的加密技术，特别是对堡垒机进行配置备份或配置迁移时，有完备的机制进行保护。

　　在验证方式上，还应具备usbkey、短信、令牌、x.5O9证书等认证模式，可设置条件的多因子认证方式，满足复杂场景下的混合认证需求。

　　端口与连接

　　运维对象的端口开放都限定在堡垒机和应用服务角色，极大缩小了受攻击面，但安全管理员须保持开放端口的警惕性，对于不同的网络环境，应用服务、堡垒机和运维对象所处的网络位置可能直接相连通，也可能存在各种设备被阻断。

　　假设数据库端口可以直接被应用服务连接，则以虚拟应用打开的数据库客户端可自行填入连接信息，绕开堡垒机的管控，继而造成安全“真空”地带。

　　对于无须录屏审计的B/S操作，堡垒机应具备到Web运维对象的代理访问能力，类似于WebVPN的使用效果，在堡垒机的权限控制体系下实现更加灵活的运维配置模式。

　　应用服务器

　　应用服务基于Windows部署，一方面是因为Windows的短板带来潜在的威胁，另一方面是习惯各异的运维用户基于Windows的能力做出随意的操作，对应用服务器的技术限制和常态化管理应引起重视。

　　首先是Windows的补丁、组策略等安全基线的加固；

　　其次是所部署的应用软件加固，包括浏览器、数据库客户端等软件周期性更新和默认配置检查，避免别有用心的运维用户利用应用软件的漏洞；

　　再次是浏览器作为B/S应用的客户端，应注意由运维用户手动安装的浏览器扩展，部分浏览器扩展插件可能使运维用户获得更大的权限和更多的操作空间，继而越权，甚至演变为肉鸡；

　　最后是B/S和C/S普遍具有的打开对话框，运维用户可能在服务器磁盘和运维主机本地磁盘存在混淆，通过应用软件产生的导入、导出文件对于应用服务器就是垃圾文件，还可能导致信息在不同运维用户间泄漏，一般推荐隐藏应用服务器的本地磁盘，将运维用户的本地磁盘映射到虚拟应用中实现文件的交互。

　　基于上述技术架构分析，堡垒机作为IT设施和系统的看门人，日常管理的规范性和使用习惯需要“强迫症”式的对待：

　　1.登录账号一对一配置，不管运维用户来自哪里，均按人开设运维账号，避免多用户共用账号；

　　2.将运维权限按资产的账号精细化配置给运维用户，这会增加权限管理的策略条目，但对操作监管和行为审计更有效，避免越权操作；

　　3.充分利用多因子认证的能力，避免运维账号被记录在小本本、运维人员离职等导致的泄漏；

　　4.设置运维账号默认有效期期限，密码默认强制复杂性规则；

　　5.设置指令操作的黑名单，主动阻断高危命令；

　　6.尽量使用密码代填替代用户自行输入密码，能使用密钥验证则不使用密码，尽量不使用从堡垒机上修改主机密码的功能；

　　7.周期性抽检运维审计日志，周期性备份堡垒机的审计日志和主机日志。

　　毫无疑问，做到上述细节不仅需要极大的管理魄力，更离不开对所辖资产的准确梳理。在实践中可以基于受管资产的规范程度和重要程度，逐步完成到堡垒机的运维迁移，最终实现所有运维行为的应管尽管。

　　除此之外，还要兼顾考虑受管设备或网络出现严重故障时无法通过堡垒机处置的应急手段，继而在制度上、措施上，与技术手段、技术工具构成运维工作的有机体。