Google Cloud 虚拟机创建后应该做哪些安全配置，从 SSH 到防火墙逐步处理

在Google Cloud创建一台Compute Engine虚拟机，并不意味着服务器已经完成安全配置。云平台负责的是基础设施安全，而操作系统、SSH账户、网络访问规则、软件漏洞以及应用程序本身，仍然需要管理员负责。对于一台准备长期运行网站、数据库或者其他服务的Linux虚拟机来说，创建实例之后最重要的工作不是马上安装应用，而是先建立一个最基本的安全边界。

第一步应该确认登录方式，而不是急着修改SSH端口。现代Google Cloud环境中，更值得优先考虑的是使用OS Login、SSH密钥或者Google Cloud提供的身份管理机制，尽量避免长期使用简单的Linux密码登录。如果服务器允许密码认证，就可能成为暴力破解的目标。因此，在确认密钥登录或OS Login已经能够正常工作以后，可以关闭SSH密码认证。

Linux服务器中的SSH配置通常位于 `/etc/ssh/sshd_config`，但不同发行版以及Google Cloud镜像的默认配置可能存在差异。修改SSH配置之前，必须确保当前SSH会话不会因为配置错误而被锁死。实际操作时，最好保持一个已经建立的管理连接，再开启另一个终端测试新的登录方式，确认密钥认证正常以后再关闭密码认证。

root账户也不应该作为日常远程管理入口。更合理的方式是使用普通管理员账户，通过sudo执行需要提升权限的操作。这样即使账户凭据出现问题，也可以降低直接获得完整root权限的风险。

至于把SSH从22端口改成2222或者其他端口，不能把它当成核心安全措施。更换端口最多可以减少部分自动化扫描产生的噪声，却不能阻止针对服务器的有针对性扫描。真正重要的是限制谁可以访问SSH端口。例如管理员拥有固定公网IP时，可以在Google Cloud防火墙中只允许这个IP访问SSH，而不是对整个互联网开放。

网络防火墙是Google Cloud虚拟机安全配置的核心之一。Google Cloud的VPC防火墙规则可以根据方向、协议、端口、来源范围以及网络标签等条件控制流量。对于一台普通Web服务器，通常只需要对外提供HTTP和HTTPS服务；SSH则应该尽可能限制来源地址。

如果网站只提供HTTPS，那么公网通常只需要开放443端口。80端口可以用于HTTP到HTTPS的跳转，也可以根据实际架构决定是否开放。数据库、Redis以及其他内部服务则不应该因为方便管理而直接开放给互联网。更合理的设计是让这些服务只接受来自应用服务器或者指定内部网络的连接。

这里需要特别注意 `0.0.0.0/0`。它代表所有IPv4来源地址。如果将SSH等管理端口开放给 `0.0.0.0/0`，意味着整个互联网都可以尝试连接。因此，对于管理接口，应尽可能使用明确的来源IP范围。如果确实需要从动态IP环境管理服务器，则应该考虑更安全的访问方式，例如Google Cloud的Identity-Aware Proxy，而不是简单地把SSH端口完全暴露在公网。

VPC防火墙并不是Linux服务器内部防火墙的替代品。两者处在不同层次。Google Cloud防火墙控制VPC层面的网络访问，而Linux自身还可以使用nftables、iptables、ufw等机制进行进一步限制。在配置多层防火墙时，需要避免规则相互冲突，同时明确到底是哪一层拒绝了连接。

服务器创建完成后，还应该立即进行系统更新。以Debian或Ubuntu为例，可以先执行软件包列表更新，然后安装系统提供的安全更新。具体命令取决于操作系统版本，不应该直接把某一套命令复制到所有发行版上。长期运行的服务器则需要建立持续的补丁机制，而不是创建实例时更新一次以后就不再维护。

对于生产环境，还应该关注虚拟机所使用的操作系统镜像是否仍然得到官方支持。已经停止安全维护的Linux版本，即使防火墙配置得非常严格，也不能算是一台安全的服务器。软件包、Web服务器、PHP、数据库以及第三方组件都可能成为攻击入口。

磁盘和数据保护同样不能忽视。Google Cloud的持久磁盘默认提供静态数据加密，但如果应用对密钥生命周期、访问控制或者合规要求有更高要求，可以进一步使用Cloud KMS等服务管理加密密钥。这里需要区分“数据已经加密”和“谁有权使用密钥”两个问题，后者属于权限管理范畴。

IAM权限应该遵循最小权限原则。不要为了让某个用户“方便操作”就直接赋予过大的项目级角色。Compute Engine相关权限、项目管理权限和服务器内部sudo权限是三个不同层次的问题，应当分别控制。一个开发人员是否能够查看实例，并不意味着他就应该拥有修改整个项目网络配置的权限。

对于SSH管理，也可以考虑使用OS Login，把Google Cloud身份与Linux登录权限联系起来。这样管理员不必在每台服务器上长期维护大量个人SSH公钥。当人员离开项目或者权限发生变化时，可以从统一的身份权限体系中进行管理，而不是逐台删除密钥。

日志和监控则是服务器上线以后必须持续进行的工作。Google Cloud提供Cloud Logging和Cloud Monitoring，可以收集系统以及云平台相关日志，并针对异常事件建立告警。对于SSH登录失败、异常资源消耗、磁盘空间不足以及服务异常等情况，都可以建立相应监控。

VPC Flow Logs则适合观察网络流量层面的情况。它并不是一个万能的入侵检测系统，但在排查网络连接、异常流量以及安全策略效果时非常有价值。对于要求更高的环境，还可以根据实际需求使用Security Command Center等Google Cloud安全服务。

公网IP也应该谨慎使用。如果一台服务器只需要被内部服务访问，就没有必要给它配置公网IP。应用服务器、数据库服务器和管理节点可以根据架构使用私有IP进行通信，将真正需要对互联网提供服务的组件放在公网边界。这样可以明显减少暴露面。

如果服务器需要访问Google Cloud内部服务，也应该根据具体架构考虑Private Google Access等功能，减少不必要的公网通信。跨网络、跨区域或者企业数据中心连接，则需要根据带宽、延迟、安全和成本选择合适的网络方案，并不是所有场景都需要使用Interconnect。

对于网站服务器，还需要把“服务器安全”和“应用安全”分开处理。即使SSH和VPC防火墙配置正确，如果WordPress、PHP程序、插件或者Web应用本身存在漏洞，攻击者仍然可能通过443端口进入应用层。因此，PHP版本、Web服务器、CMS、插件和第三方库同样必须持续更新。

最后应该建立备份和恢复机制。安全不仅意味着防止攻击，也意味着服务器出现误删、软件故障、配置错误甚至遭到入侵之后能够恢复。重要数据不能只依赖服务器上的一份磁盘副本，应根据业务需求制定快照、备份、异地保存以及恢复测试策略。

一台Google Cloud虚拟机真正可靠的安全结构，并不是简单地修改SSH端口、关闭几个服务或者安装一个扫描工具，而是从身份认证、IAM权限、VPC防火墙、操作系统、应用程序、日志监控和数据备份多个层面建立防护。对于普通网站服务器来说，可以把原则概括为：管理入口尽量不暴露给整个互联网，公网只开放真正需要提供的服务，内部服务使用私有网络，账户采用最小权限，系统和应用持续更新，并且确保发生故障之后能够恢复。

这样的安全配置才是真正意义上的“纵深防御”。它不是依靠某一个开关解决所有问题，而是让攻击者即使突破其中一层，也无法轻易直接获得整台服务器和整个云项目的控制权。