【ITニュース解説】Why Ephemeral Resources in Terraform Matter: How MyCoCo Eliminated Secrets from State Files

現代のITシステムにおいて、インフラストラクチャをコードで管理する「Infrastructure as Code (IaC)」はもはや標準的な手法となっている。その中心的なツールの一つがTerraformであり、クラウド上のサーバーやデータベース、ネットワークなどの設定をコードで記述し、自動的に構築・管理できる。このIaCの利点は計り知れないが、一方で重大なセキュリティ上の課題を抱えることがあった。それは、機密情報が意図せずファイルに残ってしまうという問題である。

多くの組織がクラウドインフラをコードで管理する際、データベースのパスワード、APIアクセスキー、SSL証明書の秘密鍵といった非常にデリケートな情報が、Terraformが生成する「ステートファイル」と呼ばれるファイルに保存されてしまうことがあった。ステートファイルは、Terraformが実際にクラウド上にどのようなリソースがあるかを把握し、コードとの差分を管理するために非常に重要なファイルだ。通常、このファイルは暗号化されたストレージに保存されたり、アクセスが厳しく制限されたりする。しかし、ファイル自体が暗号化されていても、その中身の機密情報が平文（暗号化されていない状態）で記述されていれば、ステートファイルにアクセスできる人は誰でもその機密情報を見ることができてしまうという大きなセキュリティリスクが生じるのだ。

MyCoCoという企業もこの問題に直面した。彼らは成長するスタートアップ企業として、少数のエンジニアでTerraformを使い始め、インフラ・アズ・コードの恩恵を享受していた。ステートファイルは安全に暗号化されたクラウドストレージに保管されていると信じていた。しかし、あるとき、情報セキュリティに関する重要な監査であるSOC 2コンプライアンスの準備を進める中で、セキュリティコンサルタントから衝撃的な事実を告げられた。彼らのTerraformステートファイルには、PostgreSQLやRedisのデータベースパスワード、認証用のJWT署名キー、SSL証明書の秘密鍵、サードパーティのAPIトークン、さらにはサーバーへのアクセスに必要なSSHキーまで、あらゆる機密情報が平文で含まれていたのだ。MyCoCoのチームは、ステートファイルを暗号化することやアクセス制限をすることには注力していたが、その「中身」にまで意識が及んでいなかったのである。

この問題は、単にステートファイルが保管されている場所のセキュリティだけでなく、システムの運用全体に波及する。例えば、災害復旧のためにステートファイルを別の地域にコピーする際や、継続的インテグレーション・継続的デリバリー（CI/CD）という開発プロセスの中で自動的にデプロイを行う際、CI/CDの実行環境（ランナー）にステートファイルが一時的にダウンロードされる場合にも、これらの機密情報がコピーされたり、露出したりするリスクがあった。既存の対策としては、Terraformのコマンド出力から機密情報を隠すsensitive引数などがあったが、これはCLI（コマンドラインインターフェース）での表示を隠すだけで、ステートファイルへの書き込みは防げなかった。また、外部のシークレット管理ツールを導入するアプローチも検討されたが、既存のワークフローに複雑に組み込む必要があり、監査の期限が迫る中で迅速な解決策にはなりえなかった。

このような状況を解決するために登場したのが、Terraform v1.10で導入された「エフェメラルリソース」という新しい概念である。エフェメラル（Ephemeral）とは「一時的な」「はかない」という意味で、その名の通り、これらのリソースはTerraformの実行中にのみ存在し、処理が終わるとすぐに消滅する。最も重要な点は、エフェメラルリソースの値はステートファイルにも、デプロイ計画を記述するプランファイルにも「決して書き込まれない」ことだ。まるで必要な時にだけ扉が開いて機密情報を取り出し、使い終わったらすぐに扉を閉じてしまうようなイメージで、その情報はどこにも痕跡を残さない。

MyCoCoはこのエフェメラルリソースを次のように活用した。以前は、random_passwordというリソースでパスワードを生成し、それを直接データベースリソースのパスワード引数に指定していたため、生成されたパスワードはステートファイルに保存されてしまっていた。しかし、新しいアプローチでは、まずephemeral "random_password"を使って一時的にパスワードを生成する。このパスワードは一時的なものなので、ステートファイルには保存されない。次に、この一時的なパスワードを、AWSが提供するシークレット管理サービスであるSecrets Managerに安全に保存する。ここで重要なのがsecret_string_woという引数だ。これは「write-only（書き込み専用）」を意味し、この引数にエフェメラルな値を渡すと、その値はSecrets Managerには書き込まれるが、Terraformのステートファイルには「一切保存されない」仕組みになっている。これにより、生成されたパスワードは直接ステートファイルに入ることなく、安全なSecrets Managerへと送られることになる。

では、データベースに接続する際にそのパスワードはどうやって使うのだろうか。ここでもエフェメラルリソースが活躍する。Terraformの実行中に、ephemeral "aws_secretsmanager_secret_version"という形で、AWS Secrets Managerから必要なシークレットを一時的に取得する。この取得したシークレットも一時的な値として扱われ、ステートファイルには残らない。取得したシークレットは、例えばJSON形式で保存されている場合、jsondecode関数で必要な情報を抽出し、PostgreSQLプロバイダーの設定などに渡してデータベースへの接続を確立する。この一連の流れの中で、機密情報はTerraformの実行プロセス内に一時的に存在するだけで、ステートファイルなどの永続的なストレージには一切書き込まれない。

このエフェメラルリソースの実装により、MyCoCoは目覚ましい成果を上げた。まず、ステートファイルから数十もの機密情報を完全に排除することに成功した。これにより、セキュリティ監査の焦点は、データが露出していないかではなく、適切なアクセス制御が行われているかに移った。SOC 2コンプライアンスの達成も容易になり、インフラ関連の成果物（ステートファイルなど）に機密情報が永続的に残っていないことを明確に証明できるようになった。運用面でも大きな改善が見られた。災害復旧のためのステートファイルバックアップや、ベンダーとの情報共有といった作業が、セキュリティ上の懸念なしに安心して行えるようになった。また、開発者にとっても利便性が向上し、デバッグのためにステートファイルを確認する際にも、本番環境の機密情報が露出する心配がなくなった。

この新しいアプローチを導入する上で理解すべき重要な点は、エフェメラルリソースが「データを永続化できない」という制約を持っていることだ。一見すると制限のように思えるが、実はこの制約こそがセキュリティ上の最大のメリットであり、機密情報が不用意に保存されることを防ぐ本質的な仕組みなのである。

組織がTerraformを使ってインフラを管理し、まだステートファイルに機密情報が保存されているのであれば、エフェメラルリソースはもはや選択肢ではなく、企業レベルのセキュリティを確保するための必須の機能であると言える。まずはデータベースパスワードやAPIキー、SSL証明書といった最もリスクの高い機密情報から、このエフェメラルリソースを用いた管理に移行することが推奨される。write-only引数のような特定の機能を理解し、クラウドプロバイダーごとのシークレット管理サービスとの連携方法を習得することが、安全なインフラ管理を実現する鍵となる。実装後は、terraform showコマンドでステートファイルを確認し、機密情報が本当に消えているかを検証することも大切だ。エフェメラルリソースは、インフラ・アズ・コードにおける「セキュリティ・バイ・デザイン」、つまり設計段階からセキュリティを組み込むという考え方を体現している。機密データをコード内で利用しながらも、永続的なセキュリティリスクを生み出さないという根本的な問題を解決するものであり、あらゆる組織にとって標準的な実践となるべき技術だ。