GCP日本账号 谷歌云VM白名单设置教程

导言与目标

在公有云时代，服务器的安全屏障先于门面。若不对外部访问进行管控，未经授权的尝试也许就会像早晨的闷热咖啡一样爬上来。本文以谷歌云 VM 白名单的设置为主线，系统介绍防火墙的原理、如何在 GCP 的 VPC 中通过自定义防火墙规则实现 IP 白名单、以及如何将规则正确地应用到目标实例上。文章既有操作步骤，也有思路方法，帮助运维同学在不影响业务的前提下提升安全性。

理解白名单的工作原理

所谓白名单，指的是仅允许列入清单的来源进行访问。与之相对的是黑名单，后者是把常见的恶意来源列入禁止清单。谷歌云的 VPC 防火墙规则分为入口（INGRESS）与出口（EGRESS），你可以通过规则的优先级来确定谁先说了算。要点在于：目标实例要被规则影响，通常需要把实例打上标签（target tags），或者把整个网络设为目标。规则的来源可以是具体的 IP 段、单个 IP，甚至是某些服务的来源范围。通过这种方式，SSH、RDP 等端口就可以只对你信任的地址开放，而对其他人则保持关闭。

在谷歌云中实现白名单的两条主线

实现白名单，最常见的还是通过 VPC 防火墙规则来控制入口流量。另一条思路是配合堡垒机、VPN 或云端 NAT，将外部访问引导到受控入口点，但这往往需要更复杂的网络拓扑和成本。本文以直接的 VPC 防火墙规则为核心，辅之以实例标签的管理方法，帮助你快速落地。下面的步骤既有控制台操作，也有命令行示例，方便不同熟练度的运维同学参考。

准备工作

确立白名单的范围与口岸

在动手前，最好把允许访问的 IP 地址、端口以及访问对象范围统一成一个清单。比如：办公网段 203.0.113.0/24 的服务器端口 22、端口 22 以外的服务端口等。若你的公司使用固定公网 IP，请确保该 IP 不会频繁变动，必要时为其申请静态外部 IP。若经常变动，建议采用 VPN 连接或云端堡垒机，将外部访问集中到一个固定的入口点。

理解端口与协议的影响

常见的访问场景包括 SSH 的 TCP 端口 22、Windows 远程桌面端口 3389，以及自定义应用的若干端口。为了安全起见，优先只开启必要的端口，尽量把允许的源地址限制在最小必要范围。对于多端口场景，可以在同一规则中指定多条规则，例如 --rules=tcp:22,tcp:3389，或者通过多条规则分开管理。

通过 VPC 防火墙规则实现白名单

控制台创建规则的步骤

在浏览器中打开 Google Cloud Console，选择你项目中的 VPC 网络，进入防火墙规则页面，点击创建防火墙规则。接下来填入关键信息：名称、网络、方向、来源过滤、目标标签、允许的端口与协议。一个简短的示例：只让来源为办公网段的请求访问 SSH。

名称：allow-ssh-office
网络：default
方向：INGRESS
优先级：1000
动作：ALLOW
规则：tcp:22
来源范围：203.0.113.0/24
目标标签：ssh-enabled

保存后，下一步是让目标实例落标签。这一步是必须的，因为没有标签的实例不会被该规则命中。你可以在控制台的实例详情页为目标 VM 增加标签，或者批量为多台实例打标签。

实例打标签的可选路径

在控制台里选择一台或多台虚拟机，点击编辑，新增标签，如 ssh-enabled。或者使用命令行在一台实例上执行：gcloud compute instances add-tags my-vm --tags=ssh-enabled。这样，规则就能把你指定的实例作为命中对象。

通过命令行创建规则与打标签的组合

用 gcloud 创建规则的标准写法

gcloud compute firewall-rules create allow-ssh-office
  --direction=INGRESS
  --priority=1000
  --network=default
  --action=ALLOW
  --rules=tcp:22
  --source-ranges=203.0.113.0/24
  --target-tags=ssh-enabled

把目标 VM 打上标签的命令

gcloud compute instances add-tags my-vm --tags=ssh-enabled

以上两步并列使用时，任何来自办公网段的对端口 22 的访问请求，若来自的源地址落在 203.0.113.0/24，并且目标 VM 有 ssh-enabled 标签，就会被放行。若来自其他 IP 或未命中标签的请求，将被防火墙按规则拒绝。

实战演练：典型场景

场景一：办公网段访问 SSH

这是最常见的场景。你只需要将办公网段放在来源范围中，端口设为 22，目标为打了 ssh-enabled 标签的实例即可。实际操作中，可能还需要把默认网络的内部通信保持正常，因此建议将防火墙规则的优先级设置较高（数值较小的优先级越高）。

场景二：远程工作者固定公网 IP 访问

如果家里或手机热点的公网 IP 是固定的，同样适用上述做法。你需要把该 IP 加入源范围，例如 --source-ranges=198.51.100.42/32，然后确保目标实例具备相应的标签和端口开放。

场景三：多端口与多源场景

对于多端口，可以用多条规则，或者在同一规则中列出多个端口，例如 tcp:22,tcp:3389，用来控制不同服务的访问入口。对于多源场景，可以将不同的来源地址映射到不同的目标标签，形成组合策略。通过这种分层规则，管理员可以更细粒度地控制谁能访问什么。

维护与安全要点

定期审计防火墙规则

定期检查规则的有效性，确认没有多余的开放端口或错误的源地址。版本控制思路也很实用：将防火墙规则的名称、来源、端口、目标标签记录在变更日志中，方便未来回溯。

最小权限原则

仅为需要开放的端口提供白名单，禁用一切不必要的入口。若某个端口短期需要开放，完成任务后尽快移除或禁用规则，以降低潜在风险。

GCP日本账号 监控、验证与故障排除

GCP日本账号 现场验证方法

在允许名单配置好后，尝试从受信源和非受信源两个角度访问目标端口，观察是否按预期放行或阻断。你可以利用外部网络检查工具或从同网段的设备发起测试，确保不可追溯的访问已被有效拦截。

日志与告警

在 Cloud Audit Logs 中可以看到防火墙规则的命中记录。结合监控告警，可以在规则被非授权访问触发时及时报警，避免安全事件拖延出现。

附录与注意事项

静态 IP 与动态 IP 的区别

静态 IP 的稳定性非常利于白名单维护，因为只要 IP 不变，规则就持久有效。动态 IP 则可能需要频繁更新，甚至引入 VPN 作为稳定入口来减少频繁修改。

高可用与自动化更新策略

对于较大规模的部署，建议将白名单管理与基础设施即代码（IaC）结合。通过 Terraform、Deployment Manager 或 Cloud Functions 自动化更新白名单，可以降低人工错误并提升运维效率。

常见错误与快速排查

错误一：规则未命中目标实例

原因常见于目标标签未正确应用、规则中的目标标签与实例标签不匹配、或实例处于错误的网络中。排查要点包括确认实例确实具备目标标签、确认规则作用于正确的网络、以及检查来源范围和端口是否设置正确。

错误二：源地址变动导致访问失效

若外部来源为动态 IP，白名单会因 IP 变化而失效。解决思路包括为外部访问使用固定出口点，如 VPN、堡垒机，或为来源地址设置较大但可控的范围，必要时引入多条规则以覆盖动态范围。

错误三：防火墙规则冲突或覆盖

当存在多条入口规则时，优先级高的规则会先执行。若之前已有默认允许规则，新增的白名单可能依然无法生效。排查时要检查优先级、规则顺序，以及是否有互相抵消的规则存在。

版本控制、备份与回滚

将规则、标签和变更日志进行版本控制，建议采用 IaC 工具来记录变更。遇到问题时，可以快速回滚到某个稳定版本，避免手动逐条删除规则的繁琐与不确定性。

成本与性能注意事项

防火墙规则本身几乎没有直接的计费成本，但过多的规则可能导致管理复杂度和审计成本上升。设计时应遵循最小权限原则，避免为不同需求创建大量冗余规则。对大规模部署，可以采用标签组合和分层策略，确保规则数量与实例数量的增长保持对称且可维护。

最后，安全不是一日之功，而是一场持续的演练。通过清晰的规则、稳定的入口与定期的自查，你的谷歌云 VM 白名单将像一支训练有素的安保队伍，时刻准备护航你的应用与数据。