【入門編】 Infrastructure as Code (IaC) スキャンによる設定ミス防止 – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

こんにちは！インフラ構築やプログラミング、日々の開発お疲れ様です。
新しいシステムを作る時、画面のデザインを考えたり、動かすためのプログラムを書いたりするのはワクワクしますよね。でも、そのシステムを支える「インフラ（サーバーやネットワークの土台）」の設定、ちゃんと安全にできていますか？

「とりあえず動けばOK！」と、鍵の開いた玄関のような状態でクラウドにシステムを放り出してしまい、後から痛い目を見る……なんて話、実は現場では後を絶ちません。

今回は、そんなインフラの設定ミスを「デプロイ（本番公開）する前」にまるで自動の防犯チェックマンのように見つけてくれる、IaC（Infrastructure as Code）スキャンについて、身近な例えを交えながら優しく紐解いていきたいと思います。一歩ずつ、一緒に学んでいきましょうね！

—

1. 家の鍵に例える「インフラ設定ミス」の怖さ

皆さんがお住まいのお家を想像してみてください。
外出するとき、玄関の鍵をしっかり閉めて、窓にも鍵をかけますよね。ではもし、「夜も昼も玄関のドアが全開で、誰でも自由にリビングのテレビや通帳を持ち出せる状態」だったらどうでしょう？考えただけでもゾッとしますよね。

クラウドの世界（AWSやAzure、GCPなど）でも、これと全く同じことが起きるんです。

例えば、クラウド上のデータを保存する「バケット（物置のようなもの）」を作ったとします。その設定をちょっとうっかり間違えて、

「世界中の誰からでも中身が見放題・書き換え放題」 にしてしまったり、
「重要なパスワードが書かれたメモが、誰でも拾える落ち葉のように放置」 されていたり……。

攻撃者（泥棒）たちは、自動化されたプログラムを使って、世界中のクラウドを24時間いつでも「鍵の開いているお家」がないか探し回っています。人間の手で一つひとつ設定を確認するだけでは、どうしても「うっかりミス」や「見落とし」が出てしまうものなのです。

—

2. IaC（コードによるインフラ管理）ってなぁに？

昔は、サーバーの構築や設定を変えるとき、エンジニアが黒い画面（CUI）に向かってマウスをカチカチ動かしたり、コマンドを一つずつ打ち込んだりしていました。これだと、「あの時、誰がどんな設定にしたんだっけ？」と後から分からなくなったり、同じ環境をもう一度作るときに手順を間違えたりしてしまいます。

そこで登場したのが、IaC（Infrastructure as Code）です。
これは、「サーバーやネットワークの設定を、すべてプログラムのコードとして文字で書き残して管理しちゃおう！」という素晴らしい仕組みです。有名なツールには Terraform や CloudFormation などがあります。

コードとして管理できるようになると、こんな良いことがありますよね。

「こういうサーバーを作ります」という設計図が形として残る
何度でも全く同じ安全な環境を自動で作れる

そして何より最大のメリットは、「人間が公開する前に、機械に自動でセキュリティチェック（スキャン）をさせることができる」という点なんです！

—

3. IaCスキャンとは？出発前の「持ち物検査」

IaCスキャンとは、一言で言うと「クラウドの設計図（コード）を、本番の世の中に公開する前に、セキュリティの専門家みたいなロボットにチェックしてもらう仕組み」のことです。

開発者が Terraform などのコードを書いて、「よーし、この内容でサーバーを作るぞ！」とGitHubなどの仕組みにプッシュ（提出）した瞬間、自動的にスキャンツールが動き出します。

もし、コードの中に「あれ？ここの設定、鍵が空いてますよ！」という危ない記述を見つけると、スキャンツールは大きな声で、
> 「ストップ！このままでは一般公開されて泥棒に入られます！コードを直してください！」

と、デプロイ（本番公開）をガチャンと止めてくれるのです。これはまさに、飛行機に乗る前の「手荷物検査」のようなものですね。危ないものがカバンに入っていたら、搭乗口で止められるのと同じ安心感があります。

—

4. 実際にコードを見てみよう！危ない設定と安全な設定

百聞は一見にしかず。Terraform のコードを例に、実際の「危ない設定」と「安全な設定」を見比べてみましょう。

❌ 危ない設定例（鍵が空いているお家）

クラウド上にファイルを保存する「S3バケット」というストレージを作るコードです。

# 【危険】誰でも中身を見られてしまう設定の例
resource "aws_s3_bucket" "dangerous_bucket" {
  bucket = "my-company-secret-data"
}

resource "aws_s3_bucket_acl" "example" {
  bucket = aws_s3_bucket.dangerous_bucket.id
  acl    = "public-read" # ここが原因！世界中に中身が公開されてしまいます
}

*解説：* acl = "public-read" という設定が入っていると、URLを知っていれば世界中の誰でもこの中のファイルにアクセスできるようになってしまいます。これがIaCスキャンにかかると、「Public Access（外部公開）が許可されています！」と即座に検知されます。

—

⭕ 安全な設定例（しっかり施錠されたお家）

では、これを安全に直したコードを見てみましょう。

# 【安全】外部からのアクセスを完全にブロックする設定の例
resource "aws_s3_bucket" "safe_bucket" {
  bucket = "my-company-secret-data"
}

# パブリックアクセス（外部からの侵入）をすべてブロックする設定を追加
resource "aws_s3_bucket_public_access_block" "block" {
  bucket                  = aws_s3_bucket.safe_bucket.id
  block_public_acls       = true # 外部からのACL変更を禁止
  block_public_policy     = true # 外部公開用のポリシーを禁止
  ignore_public_acls      = true # 既存の公開設定も無視
  restrict_public_buckets = true # バケットの公開を制限
}

*解説：* パブリックアクセスブロックという「二重の鍵」をコードで明示的にかけることで、うっかりミスによる情報漏洩をシステム側でガッチリ予防しています。IaCスキャンは、このような「安全な記述ルール（ポリシー）」がコード内にきちんと含まれているかをチェックしてくれます。

—

5. 一歩ずつ、現場で取り組むためのステップ

「なるほど、IaCスキャンって便利そうだな。でも、自分のチームで導入するのは難しそう……」と思ったそこのあなた！
最初から完璧を目指す必要は全くありません。以下のステップで、少しずつ日常の業務に取り入れていきましょう。

1. まずはローカル環境でツールを動かしてみる

代表的なオープンソースのIaCスキャンツール（例えば TFLint や Checkov など）を自分のパソコンに入れて、書いたコードをチェックする癖をつけてみましょう。

2. CI/CD（自動化パイプライン）に組み込む

GitHub ActionsやGitLab CIなどを使って、「コードが修正されて保存されたら、自動でスキャンが走る」仕組みを小さく作ってみます。

3. ルールをチームで育てる

スキャンツールがエラーを出した時、「なぜこれがダメなのか」「どう直せばいいのか」をチームのメンバーで共有し、セキュリティの共通認識を少しずつ高めていきましょう。

セキュリティは、最初から完璧な人間なんていません。失敗したり、ツールに怒られたりしながら、「あ、ここはこう書いちゃいけないんだな」と体得していくものです。

一歩ずつ、安心して開発を楽しめる環境を一緒に作っていきましょうね！