【テクニカル・上級編】Terraformでコンプライアンス自動監査：Checkovとtfsecを活用したIaCセキュリティシフトレフトの実践 – インフラ構成管理（IaC）活用バイブル

IaCの深淵：Checkovとtfsecによるセキュリティの静的防御と、CI/CDパイプラインを「要塞」に変える極致

インフラをコード化する（IaC）ことの真の価値は、単なる手作業の自動化ではない。それは「インフラの仕様を決定論的（Deterministic）かつ可観測な状態に閉じ込めること」にある。

しかし、多くの現場では「コード化しただけで満足」し、セキュリティを後付けのパッチワークにしている。これは、設計図の段階で爆弾を仕込んでいるのと同じだ。本稿では、Terraformの静的解析における二大巨頭、Checkovとtfsecの深層を解剖し、CI/CDで「検閲」を行うための極限的な自動化アーキテクチャを提示する。

—

1. ツール選定の深層：Checkov vs tfsec

両者とも素晴らしいツールだが、その設計思想は対照的だ。

• Checkov (Bridgecrew/Prisma Cloud):
• 哲学: 「マルチプラットフォーム・ポリシー」の体現。グラフベースの解析を得意とし、TerraformだけでなくKubernetes, Helm, ARM, Bicepまでを横断する。
• 強み: 独自ポリシー作成（Python/YAML）の柔軟性が圧倒的。複雑な依存関係のトレースに長けている。
• tfsec (Aquasecurity):
• 哲学: 「圧倒的な高速性」。Goで書かれており、コンパイル言語ゆえの解析速度が凄まじい。
• 強み: 低レイテンシ。数千のリソース定義があっても一瞬でスキャンが完了する。

結論: 大規模なマイクロサービス環境で、複雑なリソース依存関係を追いたいなら Checkov。高速なフィードバックループを回し、開発者のCLI上でのUXを優先するなら tfsec である。私は、「ローカルとCIのパイプラインで両者を併用する」という多層防御を推奨する。

—

2. 現場で震える「究極のパイプライン」構築

単にスキャンしてログを出すだけでは不十分だ。「マージを物理的にブロックする」強制力がなければ、セキュリティはただの「推奨事項」に成り下がる。

以下は、GitHub Actionsにおけるマージブロックの実装例だ。

.github/workflows/security-scan.yaml
name: IaC Security Shield

on: [pull_request]

jobs:
static-analysis:
runs-on: ubuntu-latest
steps:

• uses: actions/checkout@v4

# tfsec: 高速スキャンで即時フィードバック

• name: Run tfsec

uses: aquasecurity/tfsec-action@v1
with:
# 重大な脆弱性（Critical/High）のみをfail対象にする（ノイズを減らす）
soft_fail: false
args: –minimum-severity CRITICAL

# Checkov: 詳細なポリシーチェック

• name: Run Checkov

uses: bridgecrewio/checkov-action@master
with:
directory: terraform/
framework: terraform
# 自作ポリシーを外部からロードして適用
external_checks_dirs: .checkov/custom_policies/
soft_fail: false

—

3. カスタムポリシーの深淵：ビジネスロジックをコードに焼き付ける

汎用的なポリシーは、往々にして現場のニーズとズレる。SREが書くべきは、「自社のセキュリティポリシーを強制するカスタムポリシー」だ。

例えば、「全てのS3バケットは特定のタグ付けを必須とし、かつ暗号化されていない場合は即時遮断する」というポリシーをCheckovで書く場合、以下のようになる。

.checkov/custom_policies/S3BucketMustHaveOrgTag.py
from checkov.terraform.checks.resource.base_resource_check import BaseResourceCheck
from checkov.common.models.enums import CheckCategories, CheckResult

class S3BucketMustHaveOrgTag(BaseResourceCheck):
def __init__(self):
# どのリソースを対象にするか
name = “Ensure S3 bucket has ‘Owner’ tag”
id = “CKV_ORG_001”
supported_resources = (‘aws_s3_bucket’,)
categories = (CheckCategories.TAGGING,)
super().__init__(name=name, id=id, categories=categories, supported_resources=supported_resources)

def scan_resource_conf(self, conf):
# Terraformの設定値をDeep解析
if ‘tags’ in conf:
if ‘Owner’ in conf[‘tags’][0]:
return CheckResult.PASSED
return CheckResult.FAILED

このコードをCIに組み込むことで、「タグがないバケットは、プルリクの段階で絶対にマージできない」というインフラの秩序が完成する。

—

4. エキスパートのための最適化ハック

メモリ消費とパフォーマンスの極致

数万行のTerraformコードを解析する場合、メモリ消費がボトルネックになる。

• プランファイルの解析: ソースコードを直接スキャンするのではなく、`terraform plan -out=tfplan` を実行し、生成されたバイナリをスキャンさせよ。これにより、Terraformが解決した後の依存関係や変数値を含めた「実態」をスキャンできる。精度が飛躍的に向上する。
• Goの並列処理: tfsecはGo製であり、並列処理が得意だ。CIのコンテナメモリを適切に割り当てれば、解析時間を秒単位で短縮できる。

CLIによる自動監査の自動化

CIの結果を待たず、プレコミットフックで開発者のPC上でフィルタリングを行うのがベストプラクティスだ。

.pre-commit-config.yaml
repos:

• repo: https://github.com/aquasecurity/tfsec

rev: v1.28.1
hooks:

• id: tfsec
• repo: https://github.com/bridgecrewio/checkov

rev: 2.4.0
hooks:

• id: checkov

args: [–quiet, –compact]

—

最後に：IaCの魂

ツールを導入しただけでは、インフラは強固にならない。本当の強さは、「インフラに変更を加えるたびに、組織のセキュリティ要件が自動的に検証される」という文化そのものにある。

ツールは所詮道具に過ぎない。しかし、その道具を骨の髄まで掌握し、パイプラインの深部を設計しきったエンジニアだけが、クラウドという広大な戦場で「圧倒的な安定」という報酬を得られるのだ。

さあ、あなたのコードを今すぐスキャンせよ。そこに潜む脆弱性が、あなたのインフラの本当の姿である。