こんにちは！インフラやクラウドの世界へようこそ。
システム開発の現場では、サーバーやネットワークの設定をプログラムのようにコードで書いて管理する「IaC（Infrastructure as Code：アイ・エー・シー）」という方法がすっかり主流になりましたよね。TerraformやCloudFormationといったツールを使って、ボタンをポチポチ押す代わりにコードでインフラをサクッと作れるのは、本当に便利で気持ちがいいものです。
でも、ちょっと待ってください。
「コードで書ける」ということは、セキュリティの設定ミスまで一瞬で大量生産できてしまうという裏返しでもあります。
今回は、新人のIT担当者や「セキュリティってなんだか難しそう……」と感じている開発者の方向けに、TerraformなどのIaCコードに潜むセキュリティの落とし穴と、それを自動で防ぐ「ポリシー・アズ・コード（Policy as Code）」の仕組みについて、身近な例えを交えながら優しく紐解いていきたいと思います。一歩ずつ、一緒に学んでいきましょう！
—
1. 家の鍵の例えで理解する「IaCのセキュリティミス」
突然ですが、あなたが新しい一戸建ての家を建てたと想像してください。
玄関のドア、窓、勝手口……たくさんの出入り口がありますよね。
建築士さん（開発者）が設計図（Terraformのコード）を描いて家を建てますが、もしその設計図の段階で、以下のような「うっかりミス」があったらどうでしょう？
- 「風通しを良くしよう」と、リビングの窓に鍵をつけ忘れた。
- 「荷物の搬入が楽だから」と、勝手口の鍵を「0000」という誰でも開けられる暗証番号にしておいた。
これ、現実の家なら大問題ですよね。泥棒（サイバー攻撃者）からすれば、「どうぞお入りください」とウェルカム状態です。
クラウドの世界でも全く同じことが起きます。
例えば、AWSなどのクラウド上にサーバーを置くネットワーク設定（セキュリティグループ）を書くとき、うっかり「世界中のどこからでも誰でもアクセスOK（0.0.0.0/0）」という設定を書いてしまうミスが後を絶ちません。人間は誰しも疲れているときや焦っているときに、こうしたうっかりミスをしてしまう生き物なのです。
—
2. 人間の目でのチェックには限界がある
「じゃあ、コードを公開する前に、チームの先輩や同僚にしっかり見てもらえば（レビュー）いいんじゃない？」と思いますよね。もちろん、コードレビューは非常に大切な防犯対策です。
しかし、人間は完璧ではありません。
何百行もある複雑なネットワーク設定のコードの中から、小さな設定ミスを見つけ出すのは、広大な干し草の山から一本の針を探すようなものです。
「あれ、この設定って本当に安全だっけ……？」と不安になりながら夜も眠れなくなるのは避けたいですよね。
だからこそ、「機械（コンピュータ）の力を借りて、自動で徹底的にチェックする仕組み」が必要になるのです。これが今回テーマにする静的解析ツールとポリシー・アズ・コードの世界です。
—
3. 自動チェックツール（静的解析）で「うっかり」を防ぐ
私たちの代わりに、コードのなかに「泥棒の侵入経路（セキュリティの穴）」がないかを自動で探し出してくれる番犬のようなツールが、IaC向けの静的解析ツール（例：tflintやCheckovなど）です。
これらは、人間がコードを実際にクラウドへ反映（デプロイ）する前の段階、つまり「CI/CDパイプライン」と呼ばれる自動ビルドの仕組みの中で、コードをパッとひと目見て、危険な設定がないかを一瞬で判定してくれます。
例えば、以下のようなTerraformのコードがあったとします。
# 【危ない設定例】世界中どこからでもSSH（リモートログイン）を許可している
resource "aws_security_group" "bad_example" {
name v = "allow_all_ssh"
description = "Danger! Do not use this."
ingress {
from_port = 22 # SSHのポート番号
to_port = 22
protocol = "tcp"
# 危険な設定：世界中のあらゆるIPアドレスからのアクセスを許可している
cidr_blocks = ["0.0.0.0/0"]
}
}このコードをそのままCI/CDパイプラインに通すと、静的解析ツールが「ちょっと待った！ 0.0.0.0/0 からのポート22番（SSH）の開放はセキュリティ上、非常に危険です！」とエラーを検知し、自動的にデプロイをストップさせてくれます。家の鍵を開け忘れたまま建築が進むのを、ロボットがガッチリ止めてくれるイメージですね。
—
4. ポリシー・アズ・コードで「我が家のルール」を明文化する
静的解析ツールは強力ですが、標準のルールだけでは「私たちの会社やプロジェクト独自の決まり」まではチェックできません。
そこで登場するのが「ポリシー・アズ・コード（Policy as Code）」です。
これは、簡単に言うと「セキュリティのルールを、人間が読むマニュアルではなく、プログラム（コード）として書いちゃおう」というアプローチです。
例えば、「社内のサーバーへのアクセスは、特定のオフィス（特定のIPアドレス）からだけに制限したい」というルールがあったとします。これをルール用のコード（例：Opa / Rego言語など）として定義しておきます。
# 【ポリシーのコード例（概念的なイメージ）】
# サーバーのセキュリティグループにおいて、全公開（0.0.0.0/0）を禁止するルール
deny {
# 受信許可ルール（ingress）をチェック
ingress := input.resource.aws_security_group[_].ingress[_]
# もし接続元が "0.0.0.0/0" だったら……
ingress.cidr_blocks[_] == "0.0.0.0/0"
# エラーメッセージを出す！
msg := "セキュリティエラー: 誰でもアクセスできる全公開（0.0.0.0/0）の設定は禁止されています。"
}このように、「私たちのチームではこういう設定は絶対にNG！」というルールをコード化してCI/CDパイプラインに組み込んでおけば、開発者がどんなにうっかりミスをしても、システムが自動で「ダメ！」と弾いてくれます。
—
一歩ずつ、安全なインフラ作りを楽しもう
セキュリティというと、「難解な専門用語がいっぱいで、ルールに縛られて息苦しいもの」と感じてしまうかもしれません。でも、本質はとてもシンプルです。
- 「人間のうっかりミスは必ず起きるもの」と前提を置く。
- 危ない設定になっていないかを、自動化ツールにチェックしてもらう仕組みを作る。
これらを少しずつ取り入れるだけで、あなたの作るインフラストラクチャは劇的に安全になります。まずは手元のTerraformやCloudFormationのコードを、安全な設定になっているか見直すところから始めてみませんか？
一歩ずつ、確実にセキュリティのスキルを身につけていきましょう！応援しています！
コメント