IaC (Infrastructure as Code)
約 4 分で読めます
最終更新: 2026-03-05
IaC (Infrastructure as Code) とは
IaC (Infrastructure as Code) とは、サーバー、ネットワーク、ストレージなどのインフラ構成をコードとして定義・管理する手法です。手動での GUI 操作やコマンド実行ではなく、宣言的なコードでインフラの「あるべき状態」を記述し、ツールが自動的にその状態を実現します。
セキュリティの観点で IaC が重要な理由は、インフラ構成の再現性と監査可能性にあります。コードとして Git で管理することで、誰が・いつ・何を変更したかの履歴が残り、意図しない設定変更を検知できます。手動設定で発生しがちな「設定ドリフト」(本番環境と定義の乖離) を防ぎ、脆弱性管理の基盤となるインフラの一貫性を確保します。
IaC のセキュリティ上の利点
- 構成の標準化: セキュリティグループ、IAM ポリシー、暗号化設定などをテンプレート化し、全環境で統一的に適用できる。新規環境の構築時にセキュリティ設定の漏れが発生しない
- コードレビューによるガバナンス: インフラ変更がプルリクエストとして可視化されるため、セキュリティチームが変更内容を事前にレビューできる。S3 バケットのパブリックアクセス許可のような危険な変更を本番適用前に検知できる
- ドリフト検知: IaC ツールが定義と実態の差分を検出し、手動で加えられた未承認の変更を発見できる。Terraform の plan、AWS CloudFormation のドリフト検出が該当する
- 迅速な復旧: インシデント発生時にインフラをコードから再構築できるため、復旧時間を大幅に短縮できる。クリーンな状態からの再構築は、侵害されたシステムの残存リスクも排除する
ポリシーアズコードによるガードレール
IaC のセキュリティをさらに強化するのが、ポリシーアズコード (Policy as Code) です。インフラ構成が組織のセキュリティポリシーに準拠しているかを、コードで自動検証します。
代表的なツールとして、Open Policy Agent (OPA)、Checkov、tfsec、AWS CloudFormation Guard があります。これらを CI/CD パイプラインに組み込むことで、ポリシー違反のインフラ変更を自動的にブロックできます。
検証すべきポリシーの例:
- ストレージの暗号化が有効になっているか
- セキュリティグループで 0.0.0.0/0 からの SSH (ポート 22) を許可していないか
- ログ記録が有効になっているか
- シークレットがコード内にハードコードされていないか
コンテナのイメージビルドやサーバーレス関数のデプロイにも同じポリシーチェックを適用し、インフラ全体で一貫したセキュリティ基準を維持しましょう。
主要な IaC ツールの比較
IaC ツールは大きく分けて、宣言的な DSL (ドメイン固有言語) で記述するタイプと、汎用プログラミング言語で記述するタイプがあります。組織の技術スタックと運用要件に応じて選定します。
セキュリティの観点では、どのツールを選んでも「コードレビュー → 自動テスト → 承認 → デプロイ」のパイプラインを構築することが重要です。ツール固有のセキュリティスキャナー (tfsec for Terraform、cfn-nag for CloudFormation) を CI に組み込み、危険な設定がマージされる前に検知する体制を整えましょう。
IaC のセキュリティベストプラクティス
IaC を安全に運用するための実践的なベストプラクティスを紹介します。
シークレット管理の分離は最も重要な原則です。データベースのパスワード、API キー、証明書などの機密情報を IaC コードに直接記述してはいけません。AWS Secrets Manager、HashiCorp Vault、AWS Systems Manager Parameter Store などの専用サービスに格納し、IaC コードからは参照のみ行います。Git の履歴にシークレットが残ると、リポジトリにアクセスできる全員に漏洩するため、git-secrets や gitleaks などのプリコミットフックで誤コミットを防止します。
ドリフト検知の自動化も欠かせません。IaC で定義した状態と実際のインフラが乖離する「設定ドリフト」は、手動での緊急変更やコンソール操作で発生します。Terraform の terraform plan を定期実行して差分を検出したり、AWS Config ルールで設定変更を監視したりする仕組みを構築します。ドリフトを検知したら、IaC コードに反映するか、手動変更を元に戻すかを判断し、コードと実態の一致を維持します。
最小権限の原則を IaC のデプロイパイプラインにも適用します。CI/CD パイプラインが使用する IAM ロールには、デプロイに必要な最小限の権限のみを付与します。本番環境へのデプロイは承認フローを経由させ、開発者が直接本番の IaC を適用できない仕組みにします。
モジュール化と再利用により、セキュリティ設定の一貫性を保ちます。セキュリティグループ、暗号化設定、ログ設定などを共通モジュールとして定義し、全プロジェクトで再利用します。モジュールのバージョン管理を行い、セキュリティパッチを一箇所で修正すれば全環境に反映される体制を作ります。
よくある誤解
- IaC を導入すればインフラのセキュリティは自動的に向上する
- IaC はセキュリティを向上させる基盤ですが、コード自体に脆弱な設定が含まれていれば、その脆弱性が全環境に一貫して展開されます。ポリシーアズコードによる自動検証と、コードレビューのプロセスを組み合わせて初めて効果を発揮します。
- IaC のコードは機密情報を含まないので公開リポジトリに置いても問題ない
- IaC コードにはアカウント ID、内部ネットワーク構成、セキュリティグループのルールなど、攻撃者にとって有用な情報が含まれます。また、誤ってシークレットがコミットされるリスクもあるため、プライベートリポジトリで管理し、シークレットスキャンを有効にすべきです。