通过缩小应用和计算资源的规模与范围,可以提升应用开发基础设施的安全性。实现这一目标的一种方法是将工作负载容器化。Windows Server 以及 Microsoft Hyper-V 容器可让你将工作负载彼此以及与操作系统 (OS) 分隔开来。即使攻击者攻破了某个容器,攻击者要访问宿主操作系统也会变得很困难。容器还为开发、测试和生产团队提供了标准化的环境。
下载免费指南:
容器
容器为应用程序提供隔离且可移植的运行环境。从应用程序的角度来看,容器似乎是一个完整且隔离的 Windows OS,拥有自己的文件系统、设备和配置。因此,在很多方面,容器就像虚拟机(VM):它们运行操作系统,支持文件系统,并且可以像任何其他物理机器或 VM 一样通过网络访问。
容器是虚拟环境,它们共享宿主操作系统的内核,但提供用户空间隔离。因此,它们为应用程序运行提供了理想的环境:应用程序可以在不影响操作系统其余用户模式组件的情况下运行,同时也不会被其他用户模式组件影响。使用容器,开发人员可以在隔离环境中快速创建和测试应用程序,同时只需消耗少量操作系统资源。这意味着,容器不需要虚拟机(VM)中的操作系统可能会使用到的所有进程和服务。
Windows Server 2016 支持两种类型的容器:
- Windows Server 容器。 这些容器通过进程和命名空间隔离技术实现应用隔离。Windows Server 容器会与容器宿主机以及在宿主机上运行的所有其他容器共享操作系统内核。
- Hyper-V 容器。 这些容器通过在高度优化的虚拟机(VM)中运行每个容器,在 Windows Server 容器提供的隔离能力基础上进一步增强隔离。
使用容器有多种好处。操作系统体积减小意味着需要维护的操作系统组件更少,从而带来更少的潜在安全风险。操作系统体积减小还能帮助提升可扩展性。
精选相关内容:
Docker
要在容器中运行应用工作负载,您必须使用 Docker。Docker 是一组开源工具和云端服务,它们提供了一种用于将应用代码进行打包(容器化)并以标准化单元形式交付给软件开发的通用模型。这个标准化单元,或称为 Docker 容器,是一种将完整文件系统封装在内的软件。该文件系统包含运行所需的一切,包括代码、运行时、系统工具、系统库,以及您可以在服务器上安装的任何其他内容。您必须单独下载 Docker;它不包含在 Windows Server 2016 的安装介质中。
Nano Server
Microsoft Nano Server 是 Windows Server 2016 的一种相对较新的安装选项。它是一种轻量级操作系统,专为与虚拟化的容器实例配合使用而设计。它没有用户界面;您必须使用 PowerShell 远程管理 Nano Server,但该 PowerShell 不同于标准版本。自 Windows Server 版本 1803 起,Nano Server 仅以基于容器的操作系统镜像形式提供,并且您必须在诸如 Docker 之类的容器宿主中将其作为容器运行。您可以使用 Docker 对这些新的 Nano 容器进行故障排除,并在 IoT Core 中运行它们。
Nano Server 实例不能作为 Active Directory 域 控制器运行。特别是,它不支持以下功能:
- 组策略
- 网络接口卡绑定(Teaming)
- 虚拟主机总线适配器
- 代理服务器对互联网的访问
- System Center Configuration Manager
- System Center Data Protection Manager
Nano Server 支持以下角色:
- 文件服务
- Hyper-V
- IIS
- DNS 服务器
常见问题(FAQ)
如何保护 Windows Server 2016 容器免受权限提升(privilege escalation)攻击?
保护 Windows 容器始于身份(identity)——因为 data security 以身份为起点意味着在容器级别控制谁可以访问什么。Windows Server 2016 容器默认使用进程隔离(process isolation)运行,能够提供一定的保护,但你需要分层的安全控制来防止 权限提升(privilege escalation) 攻击。
首先,在尽可能的情况下使用非管理员用户帐户来运行容器,从而实施最小权限原则。使用 Dockerfile 中的 USER 指令指定低权限账户,并且除非绝对必要,否则不要以 Local System 或 Administrator 身份运行容器。配置容器资源限制,以防止可能导致权限提升(privilege escalation)的资源耗尽攻击。
为需要进行域身份验证的容器实施组托管服务帐户(group-managed service accounts,gMSAs)——这会提供自动密码管理,并减少凭据暴露。设置 Windows Defender Application Control 策略,限制哪些应用程序可以在容器内运行,从而在恶意代码执行方面再增加一道防线。
为获得更强的隔离性,在处理敏感数据时使用 Hyper-V 容器,而不是 Windows Server 容器。Hyper-V 容器提供硬件级隔离,使攻击者进行横向移动(lateral movement)要困难得多。请持续监控容器的访问与认证事件——你无法管理看不见的内容,而要在风险行为演变为数据泄露之前识别出来,就需要对容器活动进行实时可视化。
启用 Windows Event Forwarding,将容器安全日志集中管理,并配置 Security Event Log 监控,以监测容器内的认证失败、权限提升尝试以及可疑进程创建。部署前对容器镜像进行定期安全扫描,有助于防止已知漏洞进入生产环境。
Windows 容器在身份管理方面会带来哪些影响?
Windows 容器会继承宿主机的安全上下文,从而带来独特的身份管理挑战,并直接影响你的数据安全态势。与传统虚拟机(VM)不同,容器共享宿主机的操作系统内核,因此一旦容器凭据被泄露,可能会影响整个宿主机系统。
容器进程在特定的 Windows 用户帐户下运行,而这些身份决定每个容器可以访问哪些数据和系统资源。当你大规模部署容器时,本质上是在成倍增加你的身份攻击面——每个容器都可能成为凭据窃取或横向移动(lateral movement)攻击的潜在入口点。
实际影响在于,你的容器身份策略需要与更广泛的 identity governance 程序整合。对于需要域身份验证的容器进程,请使用 group-managed service accounts (gMSAs) — gMSA 提供自动密码管理,并消除将凭据存储在容器镜像中的需求。实施基于身份的访问控制,将容器身份视为环境中的任何其他特权账户,并配套进行适当的轮换、监控以及最小权限强制。
请考虑特定于容器的身份挑战,例如在容器重启过程中凭据的持续性、用于安全注入凭据的方法,以及在动态容器环境中管理服务账户生命周期。你的 identity management 解决方案应提供可见性:哪些容器正在使用哪些身份,以及它们正在访问哪些资源。
如何审计 Windows 容器的访问与权限?
有效的容器审计需要同时具备主机级和容器级活动的可视性 — 因为攻击者进行的不只是“破门而入”,而是会登录。Windows 容器会通过标准的 Windows 事件日志系统生成安全事件,但你需要配置额外的日志来捕获与容器相关的特定活动。
启用容器运行时日志,以跟踪容器的创建、修改和删除事件。配置 Windows 事件日志,捕获容器内的认证事件、特权提升尝试以及资源访问模式。重点监控异常访问模式,例如容器访问其预期数据卷之外的文件,或建立了意料之外的网络连接。
关键在于将容器活动与您更广泛的安全监控策略关联起来。容器访问事件应与传统的用户账户监控一起,纳入您的 Identity and access governance 项目中。为高风险的容器行为设置自动告警,例如尝试访问敏感数据仓库,或将权限提升到超出容器预期范围的行为。采取这种主动方式,有助于在风险行为演变为安全事件之前及时发现。
为容器不应访问的敏感目录启用文件系统审计,并监控容器内的进程创建事件,以检测未经授权的可执行文件启动。使用 PowerShell 日志来捕获容器中的管理活动,尤其是运行自动化脚本或管理工具的容器。
Windows 容器安全监控应该遵循哪些最佳实践?
容器安全监控需要与传统服务器监控不同的方法,因为容器是短暂存在(ephemeral)的,并会创建动态的攻击面。首先对容器生命周期事件进行基线监控——包括创建、启动、停止和删除——以建立正常的运行模式。
在主机和容器两个层面监控网络流量,以检测可能表明横向移动或数据外传尝试的不寻常通信模式。跟踪资源消耗指标(如 CPU、内存和磁盘使用情况),以识别容器内部潜在的拒绝服务攻击或加密挖矿活动。
对容器文件系统的变更实施实时监控,尤其是那些不应向磁盘写入的容器。使用 Windows Performance Toolkit 以及针对容器的专用监控工具,追踪容器内的进程执行情况,重点关注未经授权的进程或意外的权限提升尝试。目标是增强可视性与控制能力——你需要清楚了解容器环境中正在发生的事情,才能采取有效的安全行动。
为容器特定的安全事件配置监控,例如从未授权的注册表拉取镜像、以过高权限运行的容器,或尝试访问宿主系统资源的容器。对那些偏离其预期行为模式的容器设置告警,例如与异常目的地建立网络连接,或消耗超出正常基线的资源。
如何排查 Windows 容器的身份验证问题?
容器身份验证问题通常源于服务帐户配置错误,或主机与容器环境之间的凭据管理不当。首先确认你的容器正在使用正确的 Windows 身份——使用 Process Monitor 或 Windows Event Viewer 等工具,检查容器进程在何种安全上下文下运行。
当由于凭据委派(credential delegation)问题,容器无法访问域资源时,常见的认证失败就会发生。若你的容器需要对 Active Directory 或其他域服务进行身份验证,请确保使用的是组托管服务帐户(gMSAs),而不是传统的服务帐户。gMSAs 提供自动密码管理,并且专门为容器场景设计。
请在容器主机和域控制器上检查 Windows 事件日志中的与身份验证相关的错误。查找与登录失败、Kerberos 认证问题或 NTLM 认证故障相关的事件 ID。使用 Network Monitor 或 Wireshark 等工具捕获身份验证流量,并确定认证链条在哪一步中断。请记住,容器的身份验证问题往往意味着更广泛的 Identity Management 问题,这可能会影响你的整体安全态势。
确认你的容器主机已正确加入域,并已安装所需的 Windows 功能(例如 PowerShell 的 Active Directory 模块)。检查容器内的 DNS 解析情况,确保它们能够访问域控制器。如果使用凭据委派(credential delegation),请确认容器主机帐户在 Active Directory 中具有所需的委派权限。
分享到
了解更多
关于作者
Dirk Schrader
安全研究高级副总裁(VP)
Dirk Schrader 是 Netwrix 的常驻 CISO(EMEA)以及安全研究高级副总裁(VP)。他拥有 CISSP(ISC²)和 CISM(ISACA)等资质,是一位在 IT 安全领域拥有 25 年经验的老兵。Dirk 致力于以现代化的方式应对网络威胁,从而推动网络韧性的发展。Dirk 曾参与全球范围内的网络安全项目:职业初期从技术与支持岗位做起,随后在大型跨国公司和小型初创企业中分别担任销售、市场与产品管理等职务。他已发表大量文章,强调为实现网络韧性,需要重视变更管理与漏洞管理。