本番導入

このページで解決すること

試用の構成を、引き渡せる本番構成に変えます。埋めるべき設定値、既定で効くセキュリティの下限、 公開前に済ませるチェック、そして一行ずつ実行できる検証コマンドをまとめます。 既定の docker-compose.yml が作るのは本番版です。フロントエンドはビルド済みの静的ファイルを nginx が配信し、 バックエンドは絞り込んだバイナリイメージで、データベースとグラフィックプロキシは外にポートを開きません。

必要なもの

• Docker と Docker Compose を動かせる Linux x86_64 または aarch64 ホスト一台と、DATA_PATH に割り当てるストレージ。
• 外向きのホスト名ひとつと、証明書の出どころの方針。システムは既定で自己署名して https を提供します。組織の証明書に替える場合や自社の ingress に任せる場合は TLS と証明書を参照してください。
• オフサイトの syslog 収集先。設定はログ転送と通知にあります。
• ターゲットホストへのソフトウェア導入は要りません。制御は接続が通るゲートウェイの上で起きます。

パッケージ導入では Release の SHA-256 一覧と Sigstore 情報を検証し、custodexa.sh install を実行します。イメージは対応アーキテクチャのオフライン配布物、またはローカル、GHCR、Docker Hub から順に取得して検証できます。ソースビルドも選べます。詳しくはリリースパッケージとオフライン導入を参照してください。

設定のしかた

1. 必須の環境変数

変数	説明
JWT_SECRET	本番版はテンプレートの既定値のままか長さが足りない場合、起動を拒否します。32 バイト以上
KEK_PROVIDER	マスター鍵のモード。出荷時は ui、ほかに env と kms
ENCRYPTION_KEY	KEK_PROVIDER=env のときだけ記入します
DB_PASSWORD	本番版に既定値はありません。必須です
ADMIN_INITIAL_PASSWORD	新規導入では必須。12 バイト以上で空白を含みません
DATA_PATH	専用のフォルダまたはディスクを推奨。本番では絶対パスにします
DB_SSLMODE	データベースが別ホストにあるときは require または verify-full
CORS_ALLOWED_ORIGINS	別オリジンで配信するときに記入。空なら同一オリジンのみ
TLS_DOMAIN	外向きのホスト名。証明書とプロキシの設定に入ります
TLS_MODE	証明書の出どころ。出荷時は selfsigned、自前の証明書なら provided
TRUSTED_PROXIES	自社の ingress の後ろに置くときに記入。監査記録の送信元アドレスとレート制限の基準になります
PUBLIC_BASE_URL	外部から見た https の URL。TLS_DOMAIN と同じホスト名にします。OIDC のコールバックアドレスはこの値から組み立てます

サービス構成の定数（ポート、データベースのホスト、データの置き場所）は compose が渡すので、自分で書く必要はありません。

2. 出荷時から効くセキュリティの下限

次の動作は導入の流れに組み込まれていて、切るスイッチはありません。

• 外向きの接続は既定で https です。内蔵プロキシが TLS 1.2 以上、HSTS、WebSocket の転送を提供し、平文のリクエストは https へ転送します。
• 公開された初期資格情報はありません。初期管理者パスワードは導入者が決め、初回ログインで変更を強制します。
• 本番版は JWT の鍵がテンプレートの既定値のままか長さが足りない場合、起動を拒否します。
• 保存する機微データは階層化したエンベロープ暗号化で守り、鍵の台帳と入れ替えの手順を備えます。
• 本番版のイメージから常設のシェル入口を外し、データベースとグラフィックプロキシは外にポートを開きません。
• データベースのスキーマは単一の基準から定義し、見覚えのない既存バージョンに当たったときは無理に走らず起動を拒否します。

3. 引き渡し前のチェック

1. いま効いているポリシーグループを適用します。セキュリティポリシーのページとアクセス制御のページで、ページ先頭から組を選び、プレビューを見てから確定します。すでに厳しいキーはそのまま、組どうしの衝突は管理者に残します。保存を押して初めて効きます。
2. syslog のオフサイト収集先を設定し、テストメッセージが本当に届くことを確認します。
3. DATA_PATH のディレクトリ権限を確認します。0750 かそれより厳しく、所有者はコンテナを動かすユーザーにします。
4. テンプレートの既定の秘密値をすべて入れ替えます。データベースの初期化が終わったら ADMIN_INITIAL_PASSWORD を .env から消します。
5. バックアップの手順を用意し、鍵台帳にある四つのフィンガープリントを記録します。
6. ログイン告示を設定します。内容は組織で決めます。
7. シングルサインオンを有効にする前に、ローカルパスワードでログインできる管理者アカウントを最低ひとつ残し、強いパスワードと多要素認証を設定します。
8. 組織または公開 CA の証明書を入れるか、システムが署名した認証局を接続元のマシンへ配ります。

4. 導入検証の五手順

docker compose ps
docker compose exec backend wget -qO- http://localhost:8080/health
curl -skI https://localhost/ | head -1
curl -sk -X POST https://localhost/api/v1/auth/login -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"<ADMIN_INITIAL_PASSWORD>"}'
docker compose logs backend | tail -30

新規導入のログイン応答には password_change_required が入ります。パスワード変更の強制が効いている証拠です。 開発機で本番版を検証するときは、必ず -f docker-compose.yml を付けて本番の設定を指してください。

監査で見えること

• セキュリティポリシーの変更は一件ずつ記録され、変更者、ポリシーキー、変更の前後の値が残ります。
• ログインイベントにはアカウント、送信元アドレス、結果が残ります。送信元アドレスが実際の接続元になるのは TRUSTED_PROXIES を設定してからです。
• 構成の形、バックアップの範囲、アップグレードの手順は運用側の証拠です。バックアップと復元とアップグレードとロールバックを参照してください。