【入門編】IaCにおけるドリフト検知と自動修復の仕組み – アプリケーションセキュリティ & 安全な開発防御ガイド

こんにちは！セキュリティの最前線で戦っているエンジニアの皆さん、そしてこれからインフラ構築に挑戦する新人エンジニアの皆さん。

今日は、システム開発の現場で最近よく耳にする「IaC（Infrastructure as Code）」と、その裏で静かに忍び寄る「ドリフト」という脅威についてお話しします。

セキュリティと言われても、なんだか難しそう……と感じるかもしれませんね。でも大丈夫。まずは身近な「家の防犯」に例えて、一緒に考えていきましょう。

—

皆さんが家を建てる時、しっかりとした「設計図」を作りますよね。この設計図こそが、今のクラウド開発における「IaC（コード化されたインフラ）」です。

「この窓は二重ロックにする」「玄関の鍵はスマートロックにする」といった防犯設備（セキュリティ設定）を、設計図という名の「コード」に書き込んでおくんです。一度ルールを決めてしまえば、自動で強固な家が建つ。これがIaCの素晴らしいところです。

ところが、現実はそう甘くありません。

—

ある日、あなたは急なトラブル対応で慌てていて、設計図を無視して手動で「玄関の鍵を一時的に開けっ放し」にしてしまったとします。あるいは、別の担当者が良かれと思って「窓の防犯センサーをオフ」にしたとします。

この「設計図（コード）と実際の状態（クラウドの設定）とのズレ」のこと、これを専門用語で「ドリフト（Drift）」と呼びます。

攻撃者はこの「ズレ」を血眼になって探しています。彼らにとって、手動で変更されたセキュリティの穴は、まさに「鍵のかかっていない勝手口」そのものなんです。ドリフトを放置することは、せっかく築いた防犯網に自ら隙間を作っているのと同じことなんですよ。

—

では、どうすればいいのでしょうか？答えはシンプル。「設計図と違う状態になったら、即座に設計図の状態へ戻す」という自動化です。

これを実現するために、多くの現場では「Terraform」のようなツールを使って、定期的にクラウドの状態をチェックする仕組みを組み込みます。

（※実際の運用ではTerraform CloudやGitHub Actionsを組み合わせて行います）

セキュリティグループ（防犯センサー）の設定例
resource “aws_security_group” “web_server” {
name = “web-server-sg”
description = “Webサーバーを守るための防犯センサー”

# 80番ポート（玄関）は開けるけど、それ以外は閉じる！
ingress {
from_port = 80
to_port = 80
protocol = “tcp”
cidr_blocks = [“0.0.0.0/0”]
}
}

もし、誰かが管理画面からポチポチと設定を変えて「全ポート開放」なんてしてしまったら、Terraformはこう反応します。

1. 検知（Drift Detection）: 「あれ？設計図には80番しか開いてないのに、22番（管理用ポート）も開いてるぞ！」
2. 修復（Auto-Remediation）: 「設計図（コード）が正義。余計なポートは即座に閉鎖！」

—

「手動で変えたほうが早いし、トラブルの時は便利だよ」という声が聞こえてきそうですね。でも、その「便利」が、将来的な「大規模な情報漏洩」に繋がるリスクを孕んでいます。

新人の皆さんにぜひ覚えておいてほしいのは、以下の3ステップです。

「手動変更」を禁止する: クラウドの管理画面（コンソール）を直接いじるのは、原則ナシにしましょう。すべてはGitリポジトリ上のコードから！
定期的な監視: 「設計図と現実が合っているか」をチェックするパイプラインを毎日回しましょう。
自動修復の検討: 重要なインフラであれば、検知した瞬間に自動で元に戻す設定（Terraform Cloudの Drift Detection など）を導入しましょう。

最初は難しく感じるかもしれませんが、まずは「自分が書いたインフラのコードが、今どうなっているか」を確認する癖をつけることから始めてみてください。

セキュリティは一度やって終わりではなく、日々の小さな積み重ねです。設計図と現実を同期させ続けること。これこそが、泥棒（攻撃者）を寄せ付けない、最強の「守り」になるはずです。

もし分からないことがあれば、いつでもコードを見直して、設計図を書き直せばいい。そうやって一つずつ安全な場所を増やしていきましょうね！