读数据安全架构设计与实践12设备和主机层(上)

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，一些旧设备还支持传统的TELNET

2.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、TOTP（Time-based One-Time Password）

2.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、SFTP

• 2.7.4. RPC可以让程序员像访问本地的函数库一样编程，实现访问远程服务的目的，程序员不用了解底层网络传输的细节

• 2.7.4.1. RPC可以走二进制协议，也可以走HTTP/HTTPS协议

• 2.7.5. 即使采用了私有协议，也不代表通信过程就是安全的，仍需要身份认证机制

3. 授权与访问控制

3.1. 主机授权与账号的访问控制

• 3.1.1. 对主机的授权，就是决定谁能够登录这台主机

• 3.1.2. CMDB（Conf 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. 及时升级存在漏洞的固件，避免存在漏洞的老旧版本固件引入风险