云计算环境网络安全策略实施指南

云上安全不是选修课

公司刚把系统搬到阿里云，老板第一句话就是：‘数据别被人偷了。’这话听着简单，可真做起来，光靠一个防火墙根本挡不住那些绕过传统防线的攻击者。现在的应用跑在虚拟机、容器、Serverless 函数上，网络边界变得模糊，老办法不灵了。

比如某个电商团队，后端服务部署在 VPC 内，前端走 CDN。他们一开始觉得‘外网访问不了主机就安全’，结果 API 接口没做鉴权，爬虫直接打穿订单查询接口，用户信息批量泄露。问题不在基础设施，而在策略缺位。

身份与访问控制必须精细到动作

很多企业用云厂商默认的管理员账号操作一切，这是典型隐患。正确的做法是基于最小权限原则分配角色。以 AWS IAM 为例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::app-logs-bucket/*"
      ]
    }
  ]
}

这段策略只允许读取指定存储桶的对象，连删除和上传都禁止。开发人员拿到这个权限，就算密钥不小心暴露，影响也有限。

网络隔离不能只靠安全组

安全组像门卫，但不能解决内部串访问题。假设你有三个微服务：用户中心、支付网关、日志服务。它们都在同一个 VPC，如果只用安全组限制外部流量，一旦攻击者进入日志服务容器，就能横向扫描到其他两个服务。

更合理的做法是划分子网，并启用网络 ACL 和流日志。例如在阿里云上创建三个子网，分别对应前端、后端、数据层，再通过路由表控制流向。同时打开 VPC Flow Logs，记录所有 IP 通信，异常行为一查便知。

加密不只是存的时候才考虑

有人觉得‘数据库开了 TDE 就万事大吉’，其实数据在传输中同样危险。Kubernetes 集群里 Pod 之间的调用如果不启用 mTLS，中间节点就能嗅探明文请求。

Istio 提供了一种透明方式实现服务间加密。只要开启 sidecar 注入，配置如下规则：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT

之后所有服务通信自动加密，不需要改一行业务代码。这就像给小区每户人家装了对讲机，外人听不懂对话内容。

自动化检测比人工巡检更可靠

靠人定期检查配置容易遗漏。有个运维曾忘记关闭测试环境的公网 SSH 端口，三个月后被爆破成功，机器成了挖矿节点。后来他们上了 Cloud Custodian，写了个策略自动扫描：

policies:
  - name: disallow-public-ssh
    resource: aws.security-group
    filters:
      - type: ingress
        ip_protocol: tcp
        ports: [22]
        cidr: 0.0.0.0/0

这套工具每天跑一次，发现违规立即告警甚至自动修复。相当于请了个24小时值班的安全员，还不用发工资。

日志与响应要能联动起来

某次攻击发生时，SIEM 系统早就收到多条登录失败告警，但没人关联分析。直到第二天财务系统被锁勒索，才意识到前一晚的异常不是误报。