こんにちは！インフラ構築やクラウドの世界へようこそ。最近は、TerraformやCloudFormationといった「IaC（Infrastructure as Code：コードによるインフラ構築）」を使って、AWSやAzureなどのサーバー環境をコードでサクッと作るのが当たり前になってきましたよね。
画面をポチポチクリックして設定していた昔に比べて、何度でも同じ環境を正確に再現できる魔法のような技術ですが、実はここに「うっかりミス」による大きな落とし穴が潜んでいるんです。
今回は、新人のIT担当者や開発者の皆さんが、今日からすぐに自分の書いたコードを守れるようになる「IaCの脆弱性スキャン」について、身近な例えを交えながら優しく紐解いていきましょう！
—
1. 家の設計図に「鍵のかからない窓」があったら？
突然ですが、あなたが新しくマイホームを建てることになったと想像してみてください。
建築士さんが誇らしげに持ってきてくれた「家の設計図」。これこそが、クラウドの世界におけるTerraformやCloudFormationのコード（IaC）にそっくりそのまま当てはまります。
もし、その設計図の隅っこにこんな記述があったらどうでしょう？
- 「1階の大きなリビングの窓は、鍵をつけません」
- 「玄関の合鍵を、誰でも自由に拾える郵便受けに入れておきます」
……そんな家、怖くて住めたもんじゃないですよね！どれだけ頑丈な外壁を作っても、窓の鍵が空いていれば、泥棒は簡単に侵入できてしまいます。
クラウドの世界でも全く同じことが起こります。
「誰もがアクセスできる設定（公開設定）になっているのに、うっかりパスワードを書き忘れたデータベース」や、「世界中から丸見えのファイル置き場（S3バケット）」などをコードで作ってしまい、そのままクラウドへデプロイ（反映）してしまう事故が後を絶ちません。
人間の目は疲れますし、うっかりミスもします。だからこそ、「人間がコードを書いたあとに、ロボット（セキュリティツール）に設計図を厳しくチェックしてもらう仕組み」が必要になるんです。それが今回解説する「IaCの脆弱性スキャン」です。
—
2. 脆弱性スキャンツール「tfsec」や「Checkov」ってなに？
設計図（IaCコード）のミスを人間のかわりに厳しく、かつ一瞬でチェックしてくれる頼もしい相棒が、tfsec や Checkov といった静的解析ツール（セキュリティスキャナー）です。
彼らは、コードを実行する前にテキストのまま読み込み、
「おいおい、ここの設定だと世界中に金庫の中身がばら撒かれるぞ！」
「この暗号化の鍵、古すぎて簡単に破られちゃうよ！」
といった危険な箇所をピンポイントで見つけ出して、赤信号を出してくれます。
ちょっとコードを見てみましょう（悪い例）
例えば、以下のようなTerraformのコードがあったとします。これは「大切なファイルをしまっておくAWSのS3バケット」を作るコードですが、セキュリティの観点から見ると大問題があります。
# 【危ないコードの例】誰でも中身が見られてしまう設定のS3バケット
resource "aws_s3_bucket" "dangerous_bucket" {
bucket = "my-super-secret-data-bucket"
# アクセス権限を「public-read（世界中に公開）」にしてしまっている！
acl = "public-read"
}このコードを tfsec などのスキャンツールに読ませると、即座に次のような警告（エラー）を出して教えてくれます。
> *[AWS002] Critical: Resource ‘aws_s3_bucket.dangerous_bucket’ has a public read ACL defined. (S3バケットが一般公開されています)*
「おっと危ない！」と気づくことができますよね。これが静的解析の強みです。実際にクラウドへ反映してしまう前に、手元のパソコンや自動化の仕組みの中で防ぐことができるのです。
—
3. 優しいセキュリティ対策：安全なコードに直してみよう
先ほどの危ないコードを、しっかりと鍵をかけた安全な状態に修正してみましょう。
# 【安全なコードの例】プライベートに設定し、さらに暗号化をかけたS3バケット
resource "aws_s3_bucket" "safe_bucket" {
bucket = "my-super-secret-data-bucket"
# アクセス権限を「private（関係者以外立ち入り禁止）」に設定
acl = "private"
# 万が一データを盗まれても中身が読まれないように暗号化を有効化
server_side_encryption_configuration {
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256"
}
}
}
}このように、コードを少し書き換えるだけで、泥棒の侵入経路をしっかりと塞ぐことができます。一歩ずつ、こうして安全な書き方を覚えていけば大丈夫ですよ！
—
4. CI/CDパイプラインにスキャンを自動組み込みしよう
「でも、毎回手動でスキャンツールを実行するのって忘れそう……」と思いましたか？
さすが鋭いですね！人間の記憶や手作業に頼ると、どうしても「忙しいから今回はスキャンをパスしちゃおう」というスキが生まれてしまいます。
そこで、開発チームで使っている「GitHub Actions」などのCI/CDパイプライン（コードを保存・反映する自動化の仕組み）に、スキャンを強制的に組み込んでしまいましょう。
以下は、GitHub Actionsを使って「コードがプッシュ（保存）されたら、自動で tfsec が厳しくチェックする」設定ファイルのサンプルです。
# .github/workflows/security-scan.yml
name: IaC Security Scan
# GitHub上のリポジトリにコードがプッシュされたり、プルリクエストが作られた時に動く
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
tfsec:
name: tfsec vulnerability scanner
runs-on: ubuntu-latest
steps:
# 1. リポジトリのコードをチェックイン環境にダウンロードする
- name: Checkout code
uses: actions/checkout@v4
# 2. 信頼性の高いセキュリティスキャンツール「tfsec」を動かす
- name: Run tfsec
uses: aquasecurity/tfsec-action@v1
with:
# もし重大な脆弱性が見つかったら、ビルド（反映）をストップさせる設定
github_token: ${{ secrets.GITHUB_TOKEN }}この設定をプロジェクトに入れておくだけで、開発者がうっかりセキュリティの甘いコードを書いてGitHubにアップロードしようものなら、自動ロボットが「待った！」とストップをかけてくれます。
本番環境が汚される前に自動でブロックできるため、セキュリティ担当者も開発者も、安心して夜眠れるようになります。
—
まとめ：一歩ずつ、安全なインフラ構築を目指そう！
今回は、IaCの静的解析による脆弱性スキャンについて解説しました。
- 設計図（IaC）の段階でミスに気づくことが何よりも大切
tfsecやCheckovなどのツールは、あなたの代わりに泥棒の侵入経路を探してくれる頼もしい相棒- CI/CDパイプライン（GitHub Actionsなど）に組み込んで、自動でブロックする仕組みを作ろう
最初は覚えることが多くて大変に感じるかもしれませんが、セキュリティは「最初から完璧を目指す」のではなく、「仕組みの力でうっかりミスを防ぎ続ける」ことが一番の近道です。
一歩ずつ、安全で堅牢なインフラストラクチャを一緒に作っていきましょう！
コメント