「設定変更は深夜の魔物」：IaCドリフトが招く脆弱性と、自動修復で守る鉄壁のクラウド環境
現場で戦うエンジニア諸君、お疲れ様。
「ちょっとだけ本番環境の設定を確認しよう」「緊急対応で一時的にIAM権限を広げた」――その“ちょっとした手動修正”が、数ヶ月後に致命的なセキュリティインシデントの引き金になる。これを我々の業界では「ドリフト（Drift）」と呼ぶ。
コード（IaC）で定義した理想の状態と、現場の「生きた」環境が乖離した瞬間、そこにはセキュリティの盲点が生まれる。今日は、このドリフトをどう検知し、どう自動修復して「コードこそが唯一の真実」という世界を作り上げるか、その泥臭い実装術を伝授しよう。
—
1. なぜ「ドリフト」が攻撃者の入り口になるのか
攻撃者は、完璧に守られたシステムを直接叩くことはしない。彼らが狙うのは、「管理者が忘れた頃に残された、意図しない設定の穴」だ。
例えば、開発者がトラブルシューティングのためにSecurity Groupのポート80を一時的に「0.0.0.0/0」へ開放し、そのまま戻し忘れたとしよう。IaCツール（Terraform等）の管理外で手動変更されたこのポートは、コード上は「制限されている」ように見えるため、監査ツールも開発者の目も欺く。
これがドリフトの恐怖だ。攻撃者は「コード上の防御策」と「実環境の脆弱な穴」の隙間を正確に突いてくる。
—
2. 実践：Terraform Drift検知と自動修復の設計
ドリフトを放置するのは、鍵のかかっていない玄関を放置するのと同じだ。我々は、これをCI/CDパイプラインに組み込み、機械的に矯正させる必要がある。
思考のプロセス
1. 検知: 定期的に `terraform plan` を実行し、差分があれば通知（Slack/Teamsへ）。
2. 修復: 意図しない変更であれば、TerraformのApplyを自動実行して「コードの状態」に強制的に戻す。
実装サンプル：GitHub Actionsによるドリフト検知パイプライン
以下のYAMLは、毎日深夜や定期的に実行し、ドリフトがあれば即座に検知するパイプラインの雛形だ。
.github/workflows/drift-detection.yml
name: “Terraform Drift Detection”
on:
schedule:
# 毎日午前3時に実行し、夜中の勝手な変更を検知する
- cron: ‘0 3 ‘
workflow_dispatch:
jobs:
drift-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Terraform Init
run: terraform init
- name: Terraform Plan
# -detailed-exitcode: 差分がある場合に終了コード2を返す
run: terraform plan -detailed-exitcode -out=tfplan
continue-on-error: true
id: plan
- name: Notify & Auto-Remediate
if: steps.plan.outcome == ‘failure’
run: |
echo “ドリフトを検知！自動修復を開始します…”
# ここでSlack通知を飛ばすフックを入れるのが定石
terraform apply -auto-approve tfplan
—
3. なぜ「手動修正」を許してはいけないのか（IAMによる封じ込め）
どんなにパイプラインを組んでも、現場のエンジニアがコンソールから手動でポチポチ変更できてしまっては意味がない。「権限の最小化」こそが最大の防御だ。
AWSであれば、サービスコントロールポリシー（SCP）やIAMポリシーで、手動変更を物理的に防ぐ設計を導入しよう。
推奨：特定のIAMロール以外からの「変更」を拒否するポリシー例
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “DenyManualChanges”,
“Effect”: “Deny”,
“Action”: [
“ec2:AuthorizeSecurityGroupIngress”,
“iam:PutRolePolicy”,
“s3:PutBucketPolicy”
],
“Resource”: “”,
“Condition”: {
“StringNotLike”: {
“aws:PrincipalArn”: [
“arn:aws:iam::123456789012:role/TerraformExecutionRole”
]
}
}
}
]
}
このポリシーを適用すれば、Terraform専用の実行ロール以外がセキュリティグループを弄ろうとした瞬間に、AWS側でアクセス拒否が発生する。これで「手動の魔物」を物理的に締め出せる。
—
4. セキュリティチーフからの提言：泥臭い運用こそが最強
多くのエンジニアが「ツールを入れれば安心」と錯覚するが、それは大きな罠だ。
1. ドリフトを「悪」と決めつけない: 時には緊急対応で手動修正が必要なケースもある。その場合は、「手動で直したら、必ずその日のうちにIaCのコードを修正し、Terraformを流して『状態を同期』させる」という文化を根付かせること。
2. 可視化を怠るな: ドリフトが発生したこと自体を隠してはいけない。Slackの監視チャネルに流し、「なぜドリフトしたのか」をチームで振り返る文化こそが、真のセキュリティレベルを向上させる。
セキュリティとは、完璧なシステムを作ることではない。「異常が発生したときに、それを即座に検知し、あるべき姿へ戻すサイクルを止めないこと」だ。
さあ、明日からの運用で、あなたのクラウド環境の「ドリフト」を徹底的に排除してくれ。現場からは以上だ。何かあればまた聞きに来なさい。
コメント