1. 设备和主机层1.1. 身份认证与账号安全最典型的场景是SSH登录安全1.2. 授权与访问控制谁有权可以登录、登录来源限制、端口开放限制1.3. 主机资产保护防止恶意软件破坏主机计算环境1.4. 主机运维审计与入侵检测1.5. 主机层的基础设施1.5.1. 主机统一认证管理1.5.2. 跳板机、运维平台、数据传输平台1.5.3. 操作系统母盘镜像1.5.4. Docker容器基础镜像1.5.5. 补丁管理保障主机操作系统及组件完整性1.5.6. 防病毒管理防止病毒、木马、Web-Shell等有害程序危害安全1.5.7. HIDS基于主机的入侵检测系统​监测主机入侵行为并触发告警及应急响应2. 身份认证与账号安全2.1. 对于linux服务器来说一般是指SSH登录2.2. 对Windows服务器是远程桌面2.3. 对网络设备来说除了SSH一些旧设备还支持传统的TELNET2.4. 主要风险2.4.1. 操作系统默认使用非实名账号和静态口令2.4.1.1. 使用的非实名账号如root、administrator在运维审计时难以定位到具体的人员且黑客也可以使用这些账号登录2.4.1.2. 冗余的账号这些多出来的账号有可能是黑客留下的或者虽然是员工创建的但有可能被黑客利用2.4.1.3. 通用口令即多台服务器使用同一个口令2.4.1.4. 弱口令口令强度太低很容易被猜出的口令2.4.1.5. 历史上已经泄露的口令2.4.2. 由于非实名账号黑客也可以登录无法关联到具体的使用人员给事件定位、追溯带来麻烦2.4.3. 通用口令和弱口令很容易导致服务器口令被黑客获取从而给业务带来风险2.5. 动态口令2.5.1. 静态口令容易被黑客利用不安全所以安全的做法就是对SSH启用实名关联和动态口令2.5.2. Linux下面有一个PAM模块Pluggable Authentication Modules身份认证插件​可用于替换系统默认的静态口令认证机制2.5.3. Google Authenticator、TOTPTime-based One-Time Password2.6. 一次一密认证方案2.6.1. 如果没有动态口令机制在安全性要求不是很高的场景也可以考虑一次一密机制配合口令管理系统使用2.6.2. 一次一密指的是每一次登录服务器的时候都使用不同的服务器口令2.6.3. 在运维工具方面还需要执行相应的权限校验和运维审计2.7. 私有协议后台认证方案2.7.1. 如果能够在业务服务器上部署一个Agent代理程序​采用私有协议向其下发指令由Agent代理执行运维指令则可以规避口令泄露的风险2.7.2. 私有协议是相对于通用协议而言的2.7.2.1. 私有协议是指采用自定义协议格式且不公开该格式仅在自身业务专门使用的协议通过后台认证机制以及对协议格式的保密提高攻击者的研究门槛可采用RPC远程过程调用机制以二进制的方式加密通信2.7.3. 通用协议就是广泛使用的格式公开的协议如HTTP、SMTP、SFTP2.7.4. RPC可以让程序员像访问本地的函数库一样编程实现访问远程服务的目的程序员不用了解底层网络传输的细节2.7.4.1. RPC可以走二进制协议也可以走HTTP/HTTPS协议2.7.5. 即使采用了私有协议也不代表通信过程就是安全的仍需要身份认证机制3. 授权与访问控制3.1. 主机授权与账号的访问控制3.1.1. 对主机的授权就是决定谁能够登录这台主机3.1.2. CMDBConf iguration Management Database配置管理数据库中每一台服务器主机都有一个运维责任人字段也许还有一个备份责任人字段3.1.3. 基于ABAC基于属性的访问控制原则只允许主机的两个责任人登录而拒绝其他账号的登录尝试3.1.4. 从安全上看应当避免不同的业务复用服务器因为这可能影响当前业务的可用性3.1.5. 从成本上看这又难以避免只能在安全和效率上加以权衡让高密级的业务不要跟其他业务复用服务器资源3.2. 主机服务监听地址3.2.1. 运维端口属于内部运维专用如果对外网开放且使用了静态口令机制则很有可能被黑客从外网直接登录给业务带来损失3.2.2. 业务服务器默认只配置内网IP, Web业务可通过统一接入网关接入反向代理到内网业务降低犯错的可能性3.3. 跳板机与登录来源控制3.3.1. 登录服务器的操作属于敏感操作所以一般大中型企业都为运维操作建立了专用的跳板机或称之为堡垒机、运维通道等​以及自动化运维平台或系统3.3.2. 登录的开源IP地址可限制在跳板机或运维平台而不能是其他来源3.3.3. 最简单的历史最悠久的安全运维基础设施就要数跳板机了3.3.3.1. 跳板机属于主机层访问控制手段对来源进行限制3.3.3.2. 对于Linux服务器通常开放SSH协议登录3.3.3.3. 对于Windows服务器通常为RDP远程桌面​3.3.4. 如果登录目标服务器采用的是静态口令机制可能会因为人为的原因泄露3.3.5. 误操作3.3.6. 当需要运维的服务器达到成千上万的量级通过人工登录的方式也变得不可行了3.3.6.1. 不推荐使用跳板机作为日常例行的运维通道而应将日常例行的操作封装起来通过自动化的运维平台管理起来尽量避免频繁地交互式登录3.3.6.2. 只有当运维平台解决不了问题的时候才使用跳板机作为最后的一个选择3.4. 自动化运维3.4.1. 登录服务器本身属于高风险行为很可能由于员工误操作等原因造成配置错误、数据丢失等巨大损失3.4.2. 在能力许可的情况下应尽可能地实施自动化运维将日常例行的运维操作放到自动化运维平台减少日常登录服务器的操作3.4.3. 根据业务特点将常规的例行的操作封装为应用或者封装为自动化运维平台上的例行任务不再经常登录到服务器这比之前经常登录到目标服务器操作要更安全3.4.4. 通过Web化的平台来执行日常运维操作例如文件管理、文件编辑、脚本发布、任务发布、内容发布等甚至也可以直接提供基于Web的实时命令窗口3.4.5. 使用Web化界面方便、效率高、体验好3.4.6. 可屏蔽高危操作如rm -rf /​避免误操作3.4.7. 方便跟SSO集成用于员工实名认证3.4.8. 方便执行权限管控、运维审计3.4.9. 自动化运维平台的一个最简单的实现就是通过SSO认证后在有权限登录的目标服务器旁边放置一个按钮点击之后可触发一个基于Web的命令行Console控制台界面3.4.9.1. 可以通过开源的GateOne来构建相关的功能3.4.10. Web Console是受控的而Web Shell是经常被黑客利用需要从规则上禁止使用的高风险功能3.4.11. 可以作为自动化运维平台建设的起步然后开始将日常例行工作应用化打造真正的自动化运维将文件发布、脚本发布与批量执行、内容发布、上传下载等常见功能整合到自动化运维平台并逐步减少Web Console的使用直至几乎不用3.5. 云端运维3.5.1. 可以理解为所有操作都在远端所涉及的数据只能看但拿不下来可用于需要防止数据泄露的场景3.5.2. 通常配合虚拟化应用发布或者桌面云技术来实现3.6. 数据传输3.6.1. 一种常见的运维需求3.6.2. 文件跨区传输也可借鉴应用网关统一接入的方案扩展应用网关的功能将其升级为统一的访问代理执行受控的TCP端口转发3.6.3. 访问代理不仅可以支持Web类业务也可以支持非Web类业务的接入3.6.4. 当使用非Web业务时可以在转发前要求员工通过SSO认证3.6.5. 位于访问代理后端的数据存储服务器可使用SFTP服务器且SFTP不使用SSH通道而是使用虚拟账号和自定义端口3.6.6. 数据传输属于运维类基本需求建议统一建设和管控部署专用的SFTP软件而不是直接使用SSHD提供的数据传输功能以非root账号运行并设置成仅允许SFTP方式使用3.7. 设备的访问控制3.7.1. 不正确的开放范围运维端口或后台管理端口可以从业务网访问甚至外网也能访问到如果再存在弱口令很容易被黑客所利用3.7.1.1. 管理网跟业务网分离让两张网路由不通这样网络设备的管理端口就无法从正常的业务网络访问到3.7.2. 不安全的协议如只能使用Telnet的老旧设备3.7.2.1. 淘汰那些只能使用Telnet的老旧设备消除Telnet协议的使用3.7.3. 固件漏洞3.7.3.1. 固件即写入设备内部的可擦写可编程只读存储器的程序3.7.3.2. 及时升级存在漏洞的固件避免存在漏洞的老旧版本固件引入风险