如何使用tfsec对Terraform代码进行安全扫描？常用安全规则详解

用Terraform管理基础设施固然高效，但安全配置上的疏忽却常常被忽视。比如某个安全组的入站规则写成了0.0.0.0/0，或者某个S3存储桶忘了开启加密，这类问题在代码评审时很容易漏掉，一旦应用到生产环境就会成为攻击者的突破口。tfsec正是为解决这个问题而生的静态分析工具，它内置了数百条针对Terraform的安全规则，覆盖AWS、Azure、GCP等主流云平台，能够在几秒钟内扫描完整个代码仓库，把安全隐患扼杀在提交阶段。

tfsec的安装与基本用法

tfsec使用Go语言编写，官方提供了单一二进制文件的分发方式，安装非常简单。在macOS上可以通过Homebrew一键安装，Windows用户可以使用scoop或者chocolatey，Linux用户则建议直接下载GitHub Release中的二进制文件放到PATH目录下。

# macOS 安装
brew install tfsec

# Windows 安装
scoop install tfsec

# 使用 Go 安装（需要 Go 1.21 以上）
go install github.com/aquasecurity/tfsec/v3/cmd/tfsec@latest

安装完成后，进入Terraform项目目录直接执行tfsec命令即可开始扫描。工具会自动识别当前目录下的.tf文件并逐一检查，最后输出一份包含严重级别、规则编号、代码位置和修复建议的报告。默认情况下 tfsec 会返回非零退出码（只要存在问题），这个特性为后续接入CI流水线提供了便利。

如果只想扫描特定目录，或者需要将结果输出为JSON、CSV格式供其他系统消费，可以通过参数控制。常用的几个参数包括--format指定输出格式、--exclude排除某些规则、--minimum-severity过滤最低严重级别等。比如只想看到高危及以上问题，执行tfsec --minimum-severity HIGH即可过滤掉低级别的告警噪音。

高频安全规则解读：网络与加密类

tfsec的规则库中，网络配置和加密相关的规则触发频率最高，也是最容易导致真实安全事件的类别。先看网络安全组规则，以AWS为例，规则AWS006会检查安全组的入站规则是否对全网段开放。当你的代码中出现cidr_blocks = ["0.0.0.0/0"]并且端口范围覆盖了SSH、RDP这类管理端口时，tfsec会直接标记为CRITICAL级别。

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Web security group"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # tfsec会标记：SSH端口不应全网段开放
  }
}

修复方式很直接：将管理端口的来源限制为公司出口IP或VPN网段，例如cidr_blocks = ["10.0.0.0/8"]。如果确实需要对外提供服务，比如HTTP的80端口，tfsec只会在端口为22、3389等敏感端口时才报高危，80端口的开放会被降级为警告，这种分级设计避免了规则一刀切的误报问题。

加密类规则同样值得关注。针对AWS S3存储桶，规则AWS017要求服务端加密必须启用；针对EBS卷，规则AWS027检查是否使用了加密卷；针对RDS实例，规则AWS021则要求存储层开启加密。这些规则的共同思路是：云端数据默认未必加密，必须显式声明。下面是一份修复后的S3配置示例：

resource "aws_s3_bucket" "data" {
  bucket = "my-sensitive-data"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

权限与日志类规则

除了网络和加密，权限过度授予也是云安全的重灾区。规则AWS098会检查IAM策略中是否使用了通配符动作Action: "*"搭配通配符资源Resource: "*"，这种组合意味着主体拥有任意操作的权限，一旦凭证泄露，攻击者可以在账号内横行无阻。tfsec遇到这类配置会给出CRITICAL级别告警，修复建议是按最小权限原则拆分策略，只授予实际需要的动作和资源范围。

公开访问类规则同样重要。规则AWS0177检查S3存储桶的公开访问阻止配置，如果代码中没有显式声明aws_s3_bucket_public_access_block资源并开启全部四个开关，tfsec会提醒你可能意外暴露数据。类似的还有Lambda函数的权限检查（规则AWS061，禁止授予任意账号调用权限）以及Azure Storage账户的网络访问默认规则检查。

日志审计类规则虽然不会直接导致入侵，但会影响事后溯源。规则AWS079要求CloudTrail日志开启加密，规则AWS080检查EKS集群的控制平面日志是否启用。很多团队会认为日志类配置无关紧要而选择忽略，但从 incident response 的实际经验看，缺乏审计日志会让安全事件的定位时间成倍增加，建议将这类规则至少保持WARNING级别而非直接关闭。

在CI流水线中集成tfsec

手动扫描容易遗忘，把tfsec嵌入CI流水线才能形成持续防护。以GitHub Actions为例，可以直接使用aquasecurity官方提供的action，整个配置不到二十行。关键点在于利用tfsec的非零退出码特性：一旦扫描发现问题，流水线自动失败，阻止问题代码合入主干分支。

name: tfsec-scan
on: [pull_request]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tfsec
        uses: aquasecurity/tfsec-action@v1.0.3
        with:
          working_directory: ./infrastructure
          minimum_severity: MEDIUM

对于存量项目，一开始全量开启所有规则往往会产生大量历史告警，导致团队失去修复动力。比较务实的做法是分阶段推进：第一阶段只对新增代码强制执行CRITICAL级别规则，存量问题登记跟踪；第二阶段逐步收紧到HIGH和MEDIUM；同时利用.tfsec.yaml配置文件对确实不适用的规则做显式排除并注明原因，而不是在命令行里随手跳过，这样配置本身也能纳入代码评审。

需要注意的是，tfsec已经逐步演进为trivy的IaC扫描模块，新项目也可以直接使用trivy config命令获得同样的规则集和更统一的输出体验。无论选择哪种工具形态，核心思想不变：安全左移，让基础设施代码在部署之前就经过系统化的安全审查，这比在事故发生后补救的成本低得多。

tfsecTerraform安全基础设施即代码扫描修改时间：2026-09-12 18:34:35