config.jsonに残っていたパスワードを、全8サーバー分移し替えた話

今回の登場人物

Ringo（リンゴ）

AI パートナー / WebManagements（WM）担当

解析・運用支援・RINGO API管理を担う。ツクルンの各プロジェクトを裏側から支える社内向けツール群の開発者。

「動いているから安全」と「動いているが、置き場所が危険」は、見た目が同じで中身がまったく違う。今回リンゴが向き合ったのは、まさにこの境界線の話だ。

課題：デプロイパッケージの中にパスワードが眠っていた

WM（WebManagements）は、リンゴが開発・運用しているAPI・ツール群だ。各クライアント向けにデプロイされる設定ファイル client/*/config.json の中に、データベースへ接続するためのrootパスワードが平文のまま残存していた。

動作そのものには何の問題もない。DBには正常につながるし、APIも普通に応答する。だが「正常に動いている」ことと「安全に置かれている」ことは別の話だ。config.json はデプロイのたびに各クライアント環境へコピーされて配布されるファイルであり、配布先が増えるほど、平文パスワードが目に触れる場所も増えていく。全8クライアントぶんの config.json それぞれに、同じ種類のリスクが埋め込まれていた計算になる。

実装：読み込み優先順位を使って、置き場所そのものを変える

リンゴの対応は、パスワードの値を変えることではなく、パスワードの置き場所を変えることだった。

まず、全8クライアントの client/*/config.json にある database.remote.password をすべて空文字（""）に書き換えた。これで、デプロイパッケージ自体からパスワードが完全に除外される。デプロイのたびに配布されるファイルの中に、機密情報が一切含まれない状態になったということだ。

次に、移行用スクリプトを用意し、全8クライアントサーバーそれぞれの site-settings.json（サーバー個別に管理される設定ファイル）へパスワードを移行した。移行が完了した後、この移行用スクリプトは削除している。

この実装の核心は、WMのConfigLoader（設定読み込みの仕組み）がもともと持っていた「site-settings.json を最優先で読む」という読み込み順序を、そのまま活用した点にある。新しい仕組みを作り込む必要はなかった。既存の優先順位ロジックに合わせてパスワードの置き場所を移すだけで、デプロイパッケージの中身と、サーバーに固有の機密情報とを、構造的に分離できた。

// ConfigLoader の読み込み優先順位（イメージ）
// 1. site-settings.json（サーバーごとに個別管理・デプロイされない）
// 2. client/config.json（デプロイパッケージに含まれ、各クライアントへ配布される）
//
// database.remote.password は
//   client/config.json 側 → "" （空文字化）
//   site-settings.json 側 → 実際の値（移行済み）
// ConfigLoader が 1 を優先して読むため、動作は変わらない

結果：全8サーバー一括対応、デプロイ後も正常動作

この対応は全8クライアントサーバーに対して一括で実施された。移行後、デプロイを行ってもDBは site-settings.json に置かれたパスワードで正常に接続できることが確認されている。動作を止めずに、リスクだけを取り除いた形だ。

リンゴからの報告は簡潔だった。「デプロイをお願いします。デプロイ後もDBは site-settings.json のパスワードで正常動作します」。淡々とした一言だが、これは「気づいてから直すまで」を一人で完結させた仕事の報告でもある。

数字で見る対応規模

今回の対応範囲を数字で整理する。全8クライアントサーバー、それぞれに1つずつ `config.json` があるため、対応前は最大8箇所に同じ種類の平文パスワードが存在していた計算になる。デプロイのたびにこのファイルがコピーされるため、デプロイ回数を重ねるほど、パスワードが記録されたファイルのコピーが増えていくリスクもあった。今回はこの8サーバーすべてに対して一括で移行スクリプトを実行し、対応漏れなく完了させている。rootパスワードは通常のアプリケーション用アカウントと異なり、データベースに対して全権限を持つため、1箇所からの漏洩でも影響範囲は「そのDBの全データ」に及ぶ。8箇所という数はサーバー台数としては大きくないが、rootパスワードという性質上、リスクの重みは台数以上に大きかったと言える。

用語の整理：config.json と site-settings.json は何が違うのか

config.json（デプロイ設定ファイル）

アプリケーションのソースコードやビルド成果物と一緒にパッケージ化され、デプロイのたびに各クライアント環境へコピーされるファイル。バージョン管理の対象になりやすく、複数人・複数環境で共有される前提の設定を書く場所

site-settings.json（サーバーローカル設定ファイル）

デプロイパッケージには含まれず、各サーバー上に個別に配置・管理されるファイル。そのサーバーだけが必要とする値（DB接続情報、APIキーなど）を置く場所

ConfigLoader

アプリケーション起動時に複数の設定ソースを読み込み、優先順位に従って1つの設定値にマージする仕組み。WMでは「site-settings.jsonを最優先」というルールで実装されている

置き場所の選択肢を比較する

代替手段：他にどんな選択肢があったか

今回リンゴが選んだ「site-settings.jsonへの分離」は、既存のConfigLoaderの仕組みをそのまま使える点で最小コストの対応だった。一方で、より大規模なシステムでは以下のような選択肢もある。

• 環境変数（`.env`ファイル + dotenv系ライブラリ）: Node.js/PHP/Pythonなど多くの言語エコシステムで標準的。サーバーごとに個別設定できる点はsite-settings.jsonと同じ発想
• HashiCorp Vault / AWS Secrets Manager / Google Secret Manager: 専用のシークレット管理サービス。アクセス権限の細かい制御、シークレットのローテーション（定期的な自動更新）、監査ログなど、より高度な機能を持つ。ただし新たなサービスの学習・運用コストが発生する
• Kubernetesを使っている場合のSecretリソース: ConfigMap（非機密設定）とSecret（機密情報）をKubernetes標準機能で分離できる。コンテナ化されたインフラではこちらが自然な選択肢になる

WMは8台のサーバーという規模感と、既存のConfigLoaderという資産があったため、「最小の変更で最大の効果を得る」方式として site-settings.json 分離を選んだ。プロジェクトの規模やインフラ形態が変われば、最適な選択肢も変わる。

【技術コラム】あなたのconfig.jsonは、大丈夫か

今回の話は、WM固有の事情に見えて、実はどんなプロジェクトにも当てはまる一般的な設計パターンの話でもある。ポイントは「デプロイされるファイル」と「サーバーローカルにしか存在しないファイル」を分けて考えることだ。

• デプロイされるファイル（リポジトリに入る、CI/CDでコピーされる、複数環境に配布される）には、機密情報を置かない
• サーバーローカルの設定ファイル（環境変数、そのサーバーだけに存在する設定ファイル、シークレットマネージャー）に機密情報を寄せる
• アプリ側の設定読み込みロジックが「ローカル設定を優先して読む」構造になっていれば、コードの改修なしに置き場所だけ移せる

これは .env と .env.example を分ける発想や、Kubernetesの Secret とConfigMap を分ける発想と、根っこは同じだ。「動いているかどうか」だけを見ていると、この分離の甘さには気づきにくい。

読者の皆さんも、自分のプロジェクトの設定ファイルを一度チェックしてみてほしい。例えばこんなコマンドで、簡易的に洗い出せる。

grep -rn "password\|secret\|pwd" config/ --include="*.json"

このコマンドは、config/ ディレクトリ以下のJSONファイルから、パスワードやシークレットらしきキーを含む行を再帰的に検索する。同様に .env ファイルが対象なら grep -rn "PASSWORD\|SECRET\|KEY" --include=".env*" のような形でも確認できる。ヒットした行の値が、リポジトリにコミットされていたり、複数環境へ配布されるファイルの中に実値のまま入っていたりしたら、それは今回のWMと同じ状態だ。

「動いているから安全」ではなく、「動いていて、かつ、正しい場所に置かれているから安全」。この一文を、設定ファイルを触るたびに思い出したい。