「IaCは聖域か？」―ドリフトが招く死角と、修復のその先にあるアーキテクチャの真実
現場でIaC（Infrastructure as Code）を導入しているチームの多くが、ある「幻想」を抱いている。「TerraformやCloudFormationで構成管理しているから、我々のクラウド環境は堅牢だ」と。
だが、現実はどうか。深夜の緊急障害対応中、焦ったエンジニアがマネジメントコンソールから直接セキュリティグループの穴を開け、そのまま修正を忘れて帰宅する。あるいは、意図せぬ権限昇格を狙う攻撃者が、コンソールから一時的にポリシーをアタッチしてバックドアを作る。この「コードと実環境の乖離」、すなわちドリフト（Drift）こそが、高度な標的型攻撃における格好の侵入口となる。
本稿では、単なる「ドリフト検知」の枠を超え、セキュリティアーキテクトが如何にこの不整合を制し、脆弱性の種を根絶すべきか、その深淵を紐解く。
—
1. ドリフト検知を「設定監査」と誤解してはならない
多くのエンジニアは、ドリフト検知を「構成の整合性確認」程度に捉えている。しかし、攻撃者の視点から見れば、ドリフトはパッチ適用漏れや設定ミスを突くための「動的な脆弱性」だ。
例えば、CI/CDパイプラインを迂回して直接変更されたS3バケットの公開設定や、IAMロールの`AssumeRole`ポリシーの拡張。これらは静的なコード監査では決して検知できない。我々が構築すべきは、単なる「差分通知」ではなく、「望ましくない状態（Desired State）への強制復旧」と「変更の因果関係追跡」を統合した防御層である。
2. 自動修復の設計：冪等性の維持と競合の回避
ドリフトの自動修復を実装する際、最大の懸念は「修復ループ（修復がさらなるドリフトを誘発し、システムが不安定になる）」だ。これを防ぐには、Terraformの`plan`結果を解析し、破壊的な変更を伴う場合には修復を拒否するガードレイルが必要になる。
以下は、AWS Lambdaを用いたドリフト検知・修復のアーキテクチャにおける、思考の断片だ。
概念コード: AWS Config + EventBridgeを活用したドリフト修正のフック
import boto3
def lambda_handler(event, context):
# 実際にはConfig Ruleの非準拠イベントを受け取る
resource_id = event[‘detail’][‘resourceId’]
# 1. 自動修復のガードレイル:
# 本番環境で「破壊的変更（例: DBの削除）」を伴う場合は自動修復を停止し、
# 熟練エンジニアの承認を待つロジックを挟む
if is_destructive_change(resource_id):
notify_security_team(“緊急対応が必要: 破壊的設定ドリフト検知”)
return
# 2. Terraform/OpenTofuの実行をトリガー
# 冪等性を担保するため、特定のワークスペースのみを対象とする
execute_terraform_apply(resource_id)
# 3. ログのメタデータに「誰が、いつ、何を」ではなく、
# 「どのパイプラインIDが修正したか」を明記する
log_remediation_audit(resource_id)
3. 生成AI時代の「プロンプト・ドリフト」への備え
近年の懸念は、IaCコード自体が生成AIによって生成される際、そのプロンプトの不備により「脆弱な構成」がコード化されることだ。ドリフト検知システムは、単に「手動変更」を監視するだけでなく、「IaCコード自体のセキュリティ要件（ガードレイル）との乖離」もチェックしなければならない。
- ガードレイルのコード化: OPA (Open Policy Agent) を活用し、Terraformの計画段階（Plan Phase）で、メモリ保護や暗号化設定が組織のポリシーに合致しているか強制する。
- 耐量子暗号への布石: 今後、インフラ設定の暗号化パラメーターが更新される際、従来のアルゴリズムから耐量子アルゴリズムへ移行する設定変更が「ドリフト」として誤検知されるリスクがある。これを防ぐには、タグベースでの「例外管理」と「バージョン管理」の厳格な分離が求められる。
4. チーフホワイトハッカーとしての提言：泥臭い現場の哲学
ツールを導入すれば解決する、という思想は捨てろ。ドリフト検知の真の目的は、「なぜ手動変更が発生したのか」という運用のボトルネックを特定することにある。
1. コンソールアクセスの制限: そもそも、IAMの`ReadOnly`権限以外を人間に与える必要はあるか？（エンジニアの特権IDは、JIT（Just-In-Time）アクセスで数時間のみ付与するのが現代の解だ）
2. 監査ログの相関分析: CloudTrail、VPC Flow Logs、そしてIaCの実行ログをSIEM（SplunkやDatadog等）で相関付け、ドリフトの発生から修復までのMTTR（平均修復時間）をKPIとして追跡せよ。
3. ドリフトを「攻撃の予兆」とみなす: 突然のドリフトは、多くの場合、攻撃者が足場を固めるための偵察行動である。修復するだけでなく、その直前の数分間のネットワークトラフィックをパケットレベルで解析する余力を持て。
結びに代えて
IaCにおけるドリフト検知は、単なる運用の自動化ではない。それは、クラウドという「流動的で攻撃者に有利な戦場」を、我々のコードという「静的で定義可能な防衛ライン」に引き戻すための、最も泥臭く、そして最も高尚なエンジニアリングだ。
システムをコードで記述した瞬間から、コンソールは「管理者用」ではなく「監視用」へと格下げされるべきだ。この規律を貫く者だけが、複雑化するクラウドセキュリティの荒波を制御下に置くことができる。
さあ、次は貴方の環境の「非同期な変更」を、コードの力で完全に封じ込める番だ。
コメント