4. 网络安全组与防火墙：虚拟网络隔离、安全组规则、私有端点
聊到 Lakehouse 的网络安全，我脑子里第一个蹦出来的场景，是几年前帮一家金融客户做数据平台迁移。他们把所有组件都塞在一个大网段里，觉得内网就安全了。结果一次误操作，一个开发环境的 Spark 任务直接扫到了生产环境的 Hive Metastore……嗯，那天晚上我们都在加班。
说白了，Lakehouse 不是一台机器，是一堆服务拼起来的。计算、存储、元数据、调度，每个组件都可能成为攻击面。网络隔离就是第一道防线。今天咱们就聊聊这道防线怎么搭。
4.1 虚拟网络隔离：把湖切成几个池子
我个人习惯，不管用哪个云，先画一张网络拓扑图。把 Lakehouse 拆成三个逻辑区域：
- 管理面：Airflow、调度器、Web UI。对外暴露最少端口。
- 计算面：Spark、Presto、Flink 集群。弹性伸缩，无固定 IP。
- 存储面：对象存储、Hive Metastore、Catalog。原则上不暴露公网。
这三个区域用虚拟网络（VPC / VNet）隔开。区域之间只开必要的通信端口。举个例子：
核心原则：存储面只接受计算面发起的连接，管理面只能通过跳板机或 API 网关访问计算面。
我在项目中遇到过一种情况：客户把 Spark 集群和对象存储放在同一个子网，觉得这样性能好。结果安全审计时发现，任何能访问 Spark 的容器，都能直接读写存储桶里的所有数据。后来我们改成跨子网通信，存储面只开放 HTTPS 443 端口，并且绑定服务身份，才算过关。
4.2 安全组规则：别只开 0.0.0.0/0
安全组，说白了就是虚拟防火墙。每个云厂商的叫法不同——AWS 叫 Security Group，Azure 叫 NSG，GCP 叫 Firewall Rules——但逻辑都一样：允许谁、从哪来、到哪去、用什么协议。
我见过最典型的错误，是图省事直接写 0.0.0.0/0。你想想看，一个 Spark UI 端口暴露在公网上，等于把集群的监控面板送给全世界。攻击者不需要破解密码，光看日志就能摸清你的数据分布。
正确的做法是：
- 最小化入站规则：只允许特定源 IP 或源安全组访问。
- 出站规则也要管：默认允许所有出站是常见配置，但生产环境应该限制出站到特定服务。
- 用安全组引用代替 IP：比如计算面安全组允许来自管理面安全组的 SSH 访问，而不是写死 IP 段。
小技巧：我习惯把安全组规则写成表格贴在 Wiki 上，每次变更都走审批。规则多了以后，人脑记不住，表格最靠谱。
下面是一个典型的安全组规则示例：
| 方向 | 源/目标 | 协议 | 端口 | 说明 |
|---|---|---|---|---|
| 入站 | 管理面安全组 | TCP | 22 | SSH 跳板机 |
| 入站 | 计算面安全组 | TCP | 443 | Spark Thrift Server |
| 入站 | 内部监控网段 | TCP | 9090 | Prometheus 抓取 |
| 出站 | 存储面安全组 | TCP | 443 | 对象存储 API |
| 出站 | 元数据服务 | TCP | 3306 | Hive Metastore |
4.3 私有端点：让流量走内网
私有端点（Private Endpoint / PrivateLink / VPC Endpoint）是 Lakehouse 安全里我最喜欢的一个功能。为什么？因为它让公网彻底消失了。
以前访问云上的对象存储，要么走公网 IP，要么配 NAT 网关。公网有延迟、有带宽限制、还有被嗅探的风险。私有端点直接在虚拟网络里给 PaaS 服务分配一个内网 IP，流量全程不走公网。
我曾经帮一个游戏公司做架构，他们的实时数仓需要高频写入对象存储。走公网时，晚高峰经常丢包。改成私有端点后，延迟从 15ms 降到 2ms，而且安全审计直接少了一页风险项。
注意：私有端点不是开了就完事。你需要确保 DNS 解析正确——很多坑都出在客户端仍然解析到公网 IP。我习惯在 VPC 内配私有 DNS Zone，强制所有服务名解析到内网地址。
私有端点的典型部署模式：
- 对象存储：每个存储桶配一个私有端点，只允许 VPC 内访问。
- 元数据服务：Hive Metastore、Unity Catalog 等，通过私有端点暴露给计算面。
- 消息队列：Kafka、EventHub 的私有端点，确保数据摄入链路不经过公网。
4.4 整体架构图
下面这张图展示了 Lakehouse 环境里网络隔离的核心逻辑。我把它画成三层结构，方便你理解流量怎么走。
4.5 避坑指南
讲了这么多，最后分享几个我踩过的坑：
- 安全组规则顺序：有些云的安全组是顺序评估的，默认 deny 放最后。我曾经加了一条允许所有流量的规则在前面，后面的限制全废了。现在我的习惯是：先写 deny，再写 allow。
- 私有端点 DNS 缓存：客户端 DNS 缓存不刷新，导致流量仍然走公网。我建议在部署脚本里加一步：强制刷新 DNS 缓存，或者直接配 hosts 文件做测试。
- 跨区域通信：Lakehouse 跨 Region 部署时，私有端点不支持跨区域。这时候要么用对等连接，要么用云厂商的跨区域专线。别想着靠公网加密传输——延迟和稳定性都是问题。
我的习惯：每次网络变更后，我都会用 tcpdump 或云厂商的流量日志抓一次包，确认流量确实走了预期的路径。别信配置，信证据。
网络隔离这件事，做起来不难，难的是坚持。很多团队一开始搭得很严，后来为了省事慢慢放开了规则。嗯，安全这东西，松一次就容易松第二次。保持敬畏心，比任何技术方案都重要。