インフラは「書いた瞬間」に監査せよ。Terraformセキュリティシフトレフトの極意
こんにちは。クラウドインフラの世界へようこそ。
IaC（Infrastructure as Code）が当たり前になった今、私たちは「コードを書く速度」ではなく、「コードの安全性」を競うフェーズにいます。S3バケットを公開設定のままデプロイし、深夜にアラートで叩き起こされた経験はありますか？ あの悪夢を繰り返さないために、「インフラの静的解析」という最強の武器を装備しましょう。
今日は、Terraformの守護神である Checkov と tfsec を使い、コードの脆弱性を開発の「超初期段階」で叩き潰す方法を伝授します。これをマスターすれば、あなたのGitHubリポジトリは鉄壁の守りを手に入れます。
—
1. なぜ「静的解析」がインフラエンジニアの救世主なのか？
インフラ構成管理における「シフトレフト（左側へのシフト）」とは、セキュリティチェックを開発プロセスの極限まで左側（＝コーディング直後）へ移動させることを指します。
- tfsec: 開発者のDX（開発者体験）を最優先。高速で誤検知が少なく、設定なしですぐに使えます。
- Checkov: セキュリティの専門家向け。Terraformだけでなく、KubernetesやDockerファイルまで横断的にチェックできる「重戦車」です。
まずは、この2つを日常に組み込むことから始めましょう。
—
2. 実践：環境構築とHelloWorld（脆弱性検知）
まずは、あえて「脆弱性のあるコード」を書いて、それをツールがどう見抜くかを体験します。
インストール（MacOS/Linux）
以下のコマンドで、魔法のツールを召喚します。
tfsecのインストール
brew install tfsec
Checkovのインストール
pip install checkov
脆弱なコード（main.tf）を用意する
わざと「暗号化されていないS3バケット」を作ってみましょう。これがセキュリティホールです。
resource “aws_s3_bucket” “bad_bucket” {
bucket = “my-insecure-bucket”
# 暗号化設定がない、パブリックアクセスが許可されているという想定
}
—
3. ツールを動かす：インフラの「健康診断」
tfsecで瞬殺する
tfsecは、実行した瞬間に「何がダメか」を日本語（または英語）で教えてくれます。
tfsec .
実行すると、以下のようなレポートが出ます。
> [AWS002] Resource ‘aws_s3_bucket.bad_bucket’ should have encryption enabled
> Severity: HIGH
「なぜダメなのか」だけでなく「どう修正すべきか」まで提示されるため、ジュニアエンジニアでも即座に修正可能です。これがtfsecの真骨頂です。
Checkovで徹底的に追い込む
Checkovはさらに厳格です。
checkov -d .
Checkovは「業界標準（CISベンチマークなど）」に基づいた監査を行います。パスした項目と失敗した項目が可視化されるため、監査資料作成の手間がゼロになります。
—
4. CI/CDで「強制ブロック」を実現する
手動でチェックするだけでは甘いです。「脆弱なコードはマージさせない」というルールを自動化しましょう。GitHub Actionsのワークフローに組み込むのが現場の定石です。
`.github/workflows/security.yml` を作成します。
name: Security Scan
on: [push, pull_request]
jobs:
tf-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run tfsec
# 脆弱性があったらExit Code 1を返し、CIを失敗させる
run: tfsec . –soft-fail=false
- name: Run Checkov
uses: bridgecrewio/checkov-action@master
with:
directory: .
framework: terraform
これで、誰かが脆弱なコードをPushしようものなら、GitHubのプルリクエストが即座に「赤（失敗）」になります。人間が注意深くコードレビューする必要すらありません。 マシンに機械的なチェックを任せ、私たちは「より高度な設計」に集中できるのです。
—
5. 次のステップ：カスタムポリシーで「現場のルール」を作る
ツールを使いこなすと、次は「社内独自のルール」を強制したくなります（例：リソースには必ず `Project` タグを必須にする、など）。
Checkovでは、PythonやYAMLでカスタムポリシーを書くことができます。これにより、組織固有のコンプライアンス要件をIaCに埋め込むことが可能です。
- アドバイス: 最初から厳しくしすぎないこと。まずは「High（深刻）」な脆弱性だけをブロックし、徐々にルールを厳格化していくのが、チームの反発を買わずに普及させるコツです。
—
最後に：インフラを「自動で守る」文化を作ろう
ツールを入れることは、単なる作業ではありません。「コードが正しくあるべき」という文化をチームにインストールする作業です。
今日紹介したtfsecとCheckovを導入すれば、あなたは「コードを書く人」から「インフラの安全性という品質を設計する人」へと進化できます。毎日の作業が劇的に楽になり、深夜のトラブル対応からも解放されますよ。
さあ、まずは `tfsec .` から始めてみましょう。あなたのインフラは、もっと安全になれるはずです。