【入門編】 Infrastructure as Code (IaC) の静的解析による設定ミス検知 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは！セキュリティバイブルの主筆、そして日々サイバー空間の最前線で「デジタルな鍵」を研ぎ澄ませている最高セキュリティ責任者です。

これからクラウドやインフラの構築に携わる皆さん、ようこそ！新しい技術を学ぶのは、新しい街に家を建てるようなワクワク感がありますよね。でも、せっかく建てた素敵なマイホームが「実は最初から玄関に鍵がついていなかった」なんてことになったら……想像するだけでゾッとします。

今日は、そんな悲劇を未然に防ぐための「魔法の設計図チェック」、IaC（Infrastructure as Code）の静的解析について、優しく丁寧にお話ししていこうと思います。

—

1. そもそも「IaC」って何だろう？

最近のインフラ構築では、画面をポチポチ操作する代わりに、TerraformやCloudFormationといった「コード（文字）」で構成を書き込むのが主流です。これを IaC（Infrastructure as Code） と呼びます。

例えるなら、IaCは「家の設計図」です。
「ここに柱を立てて、ここにドアを設置して、窓にはこの種類の鍵をつけてください」という指示書をコンピュータに渡すと、その通りに自動で家（サーバーやデータベース）を建ててくれる便利な仕組みです。

なぜ「設計図」が狙われるのか？

泥棒（攻撃者）は、完成した家を一つひとつ回って窓を割るよりも、「設計図そのもののミス」を探すほうが効率が良いことを知っています。

もし設計図に「玄関ドアは常に全開にしておくこと」と書かれていたらどうでしょう？その設計図をコピーして100軒の家を建てれば、100軒とも泥棒が入り放題になってしまいます。これが、クラウド設定ミスの恐ろしさなんです。

—

2. 攻撃者が狙う「開いたままの窓」とは？

私たちがよく目にするインシデント（事故）の多くは、実は高度なハッキング技術ではなく、「単純な書き間違い」から始まります。

S3バケットの全公開： 「世界中の誰でも中身を見ていいよ」という設定。会社の機密情報やお客様の個人情報が入った金庫を、駅のホームに置きっぱなしにするようなものです。
セキュリティグループの「0.0.0.0/0」開放： 本来は特定の担当者しか入れないはずの管理用ドア（SSHやRDP）を、世界中の誰でもガチャガチャと触れる状態にしている設定です。

「後で直そう」と思って忘れてしまった、あるいは「テスト中だから」と開けっぱなしにしたその一瞬を、攻撃者のプログラムは24時間365日、休まず探し続けています。

—

3. 「デプロイ前」に間違いを見つける「静的解析」

そこで登場するのが、今回の主役「静的解析（Static Analysis）」です。
これは、家を実際に建てる前に、「設計図に防犯上の欠陥がないか、AIやツールが自動で検閲してくれる仕組み」のことです。

「この設計図、3階の窓に鍵がついていませんよ！」と、デプロイ（構築）ボタンを押す前に教えてくれる心強い味方なんです。

代表的なツール

tfsec / Trivy: Terraformのコードをスキャンする、非常に有名なツールです。
Checkov: Terraform、CloudFormation、Kubernetesなど幅広く対応しています。

—

4. 実践！ダメな設計図を直してみよう

では、具体的に「危ないコード」がどういうものか、Terraformの例で見てみましょう。

🚨 危険な設計図（例：S3バケットが丸見え）

このコードをそのまま実行すると、世界中から中身が見えるバケットが作られてしまいます。

# 危険な設定例：S3バケット
resource "aws_s3_bucket" "my_data" {
  bucket = "my-secret-company-data"
}

# これが「全公開」の犯人！
# 誰でも（public）読み取り可能（read）に設定してしまっています
resource "aws_s3_bucket_acl" "bad_acl" {
  bucket = aws_s3_bucket.my_data.id
  acl    = "public-read" 
}

✨ 安全な設計図（静的解析で合格する設定）

静的解析ツールを使うと、「public-read はダメだよ！」と怒られます。そこで、以下のように「プライベート（自分専用）」に修正します。

# 安全な設定例：S3バケット
resource "aws_s3_bucket" "my_data" {
  bucket = "my-secret-company-data"
}

# 鍵をしっかりかけました（private）
resource "aws_s3_bucket_acl" "good_acl" {
  bucket = aws_s3_bucket.my_data.id
  acl    = "private" 
}

# さらに「パブリックアクセスブロック」という二重の鍵をかけます
resource "aws_s3_bucket_public_access_block" "secure_lock" {
  bucket = aws_s3_bucket.my_data.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

—

5. セキュリティグループの「全開放」もチェック！

もう一つ、よくあるミスが「門番（ファイアウォール）」の設定です。

🚨 危険な設定（誰でもサーバーに入れる）

resource "aws_security_group" "bad_sg" {
  name = "allow_ssh"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    # 「0.0.0.0/0」は、世界中のすべてのIPアドレスを意味します
    # つまり、地球上の全員に「どうぞノックしてください」と言っている状態です
    cidr_blocks = ["0.0.0.0/0"] 
  }
}

✨ 安全な設定（特定の仲間だけ入れる）

resource "aws_security_group" "good_sg" {
  name = "allow_ssh_from_office"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    # 会社のオフィスなど、信頼できる特定の場所（IPアドレス）だけを許可します
    cidr_blocks = ["203.0.113.50/32"] 
  }
}

—

6. 一歩ずつ、対策を学んでいきましょう！

「こんなにたくさん覚えることがあるの？」と不安になるかもしれません。でも、大丈夫です。

静的解析ツールを導入すれば、あなたがすべてのルールを暗記していなくても、ツールが「ここが危ないですよ！」とガイドしてくれます。それはまるで、ベテランの警備員さんが横についていてくれるようなものです。

まずは、自分の書いたコードに対して tfsec などのコマンドを実行してみることから始めてみませんか？

現場からのアドバイス

私たちプロの現場では、これらのチェックを「CI/CD（シーアイ・シーディー）」という自動化の仕組みに組み込んでいます。
開発者がコードを保存した瞬間に、裏側でロボットがシュババッとスキャンして、「合格！」とならなければ本番環境に反映されないようにしているんです。

これなら、うっかりミスで夜中に叩き起こされる心配もありませんね。

—

最後に

セキュリティは「100点満点を目指して完璧にするもの」というより、「日々の小さな隙間を、みんなで少しずつ埋めていくもの」です。

今日、IaCのスキャンという概念を知ったあなたは、昨日よりも確実に「安全な家を建てる力」が身についています。焦らず、一歩ずつ、楽しみながらセキュアなインフラを作っていきましょう！

もし分からないことがあれば、いつでも設計図を読み返しに来てくださいね。応援しています！