鍵管理
このページで解決すること
Section titled “このページで解決すること”保存する機微データは階層化したエンベロープ暗号化で守ります。データはデータ鍵で暗号化し、データ鍵はマスター鍵で包みます。 このページでは、マスター鍵をどこに置くか、台帳をどう読むか、鍵を替えるときどの手順を通るかを説明します。 入れ替えはすべて手動です。システムが自分で鍵を替えることはありません。
マスター鍵とデータ鍵がどう守るか1 / 5
- パスワードはデータ鍵（DEK）で暗号文になります。ディスク上に平文はありません。
- データ鍵そのものをマスター鍵（KEK）が包みます。これが二層の封筒です。
- マスター鍵はデータベースに書きません。開封ページ、環境ファイル、またはクラウドの鍵サービスに置きます。
- パスワードを使うとき、バックエンドはまずマスター鍵で外層を開き、それからデータ鍵に届きます。
- マスター鍵を替えるときは外層だけ包み直します。中の暗号文は書き直しません。
接続のときパスワードがどこを通るかは SSH ターミナル
委託の資格情報は、封印解除のときに渡します4 / 4
- 委託モードのサービスは起動時に封印の状態で、管理者が封印解除の流れを終えるのを待ちます。
- 管理者はまず資格情報を検証し、保管者の宛先を照合します。
- 管理者は封印解除の手順で保管者の資格情報を入れます。システムは今回の封印解除世代のメモリでそれを持ちます。
- 封印解除が終わると業務の機能を出します。委託の資格情報は配備ファイルにもディスクにも書きません。封印すると消し、再起動後に改めて渡します。
マスター鍵の三つのモード
Section titled “マスター鍵の三つのモード”モードは .env の KEK_PROVIDER で決まります。
env：材料を環境設定ファイルに置く
Section titled “env：材料を環境設定ファイルに置く”ENCRYPTION_KEY に 32 バイトの鍵を入れます。書き方は三つ受け付けます。英数字 32 文字、16 進 64 文字、
またはデコードするとちょうど 32 バイトになる base64 です。生成はどちらかで行います。
openssl rand -hex 32openssl rand -base64 32ui：材料はメモリにだけ置く（出荷時の既定）
Section titled “ui：材料はメモリにだけ置く（出荷時の既定）”起動するとシステムは封印の状態にあり、ヘルスチェックと封印のエンドポイント以外の経路は 503 を返します。 封印解除の画面で材料を入れると動き始めます。材料はブラウザのローカルで作り、ディスクには落ちません。 どのモードでも、封印解除ページは先にローカル管理者の資格情報を検証し、通ってから材料欄または保管者の資格情報欄が出ます。 続けて失敗すると間隔を広げ、冷却の時間が明ければ次の試行を受け付けます。再起動は要りません。 初期化が時間切れになったときは、最初に入れたのと同じ鍵で試し直します。新しい鍵に替えないでください。
SEAL_UNSEAL_BIND_ADDR で封印解除のエンドポイントを独立した待ち受けにし、
SEAL_UNSEAL_ALLOWED_CIDRS で封印解除できる送信元のネットワークを絞ることを勧めます。
kms：クラウドの鍵サービスに預ける
Section titled “kms：クラウドの鍵サービスに預ける”.env に残すのは KEK_PROVIDER=kms と KEK_KMS_PROVIDER（aws、vault、または gcp）だけです。
保管先のアドレス、Transit の鍵名、ロールの識別子、リージョン、鍵の参照は、鍵管理ページと包み直しウィザードからデータベースへ書き込みます。
もう効かない古い環境変数の名前は、初回起動で一度データベースへ書き、ログにも残します（値は残しません）。
委託の資格情報（クラウド鍵サービスのアクセス秘密、サービスアカウントの鍵の内容、Vault の secret または token）は封印解除ページでのみ入れ、
その封印解除のあいだだけ生き、封印すると消し、配備ファイルにもディスクにも入りません。
委託モードは再起動または封印のあと封印解除ページで止まり、管理者がトポロジを照合してからその場で保管者の資格情報を渡します。
データ鍵の包みと開きは保管先が行い、データと資産のパスワードは送りません。Vault は AppRole または token を使い （封印していないあいだは更新します）。鍵の版は保管先で回り、鍵の入れ替えとローカル↔委託は包み直しウィザードを通ります。 マルチリージョンの鍵の主と副は二つの鍵として扱い、副へ切り替えるのは鍵の入れ替えなので、先に包み直します。
新規の導入では、サービスを始める前に委託の初期化を通れます。封印解除ページの四手順で管理者、トポロジ、保管者の資格情報をそろえ、それから鍵を包んで保存します。
管理側の「鍵管理」のページに、すべての鍵とそのフィンガープリントが並びます。フィンガープリントの計算は共通なので、自分でも照合できます。
echo -n <JWT_SECRET> | sha256sum # 先頭 16 文字の 16 進を取ります環境変数側の鍵は、フィンガープリントと管理する側だけを示します。預ける方式では、材料のフィンガープリントの代わりに正規化した外部の鍵の参照を示します。
ui のモードでは封印の状態も示します。ポリシーキー「鍵の使用期限のお知らせ日数」を 0 より大きくすると、
年数の経った鍵に台帳でお知らせが出ます。
稼働中の封印
Section titled “稼働中の封印”管理者は鍵管理から、動いているシステムを封印できます。新しい鍵の使用を止め、持っている側の処理を終え、キャッシュを消します。
封印は、まだ鍵を使っている接続を切ります。戻る道はモードによります。ui は材料を入れ直し、env は配備の環境を読み、
委託モードは封印解除ページでトポロジを照合し、保管者の資格情報を渡します。
データ鍵はメモリにどれくらい残るか
Section titled “データ鍵はメモリにどれくらい残るか”ポリシーキー「データ鍵キャッシュの生存秒数」は鍵管理ポリシーにあります。空はどのモードでも出荷時の値で、封印または再起動まで残す、という意味です。
0 は保管先からその都度取り、残さない、という意味です。正の整数は封印解除が通ってからの固定秒数で、再利用しても延びません。
監査の署名鍵と署名の秘密鍵はこの項目の対象ではありません。封印するとキャッシュはすぐに消えます。計測は保持期間、削除、観測です。
鍵の替えかた
Section titled “鍵の替えかた”マスター鍵の包み直し
Section titled “マスター鍵の包み直し”鍵管理のページで包み直しのウィザードを開き、データ鍵を新しいマスター鍵で包み直します。退役はソフトな退役で、 古い材料は明示的に片づけるまで残ります。片づけが材料を消す唯一の地点です。
切り替えの仕上げはモードによって違います。
env：新しい値を.envのENCRYPTION_KEYに書いて再起動します。ui：再起動したあと封印解除の画面で新しいマスター鍵を入れます。.envには書きません。kms：包み直しウィザードで保管者（AWS KMS、Vault Transit、または Google Cloud KMS）を選び、トポロジを書きます。 台帳の管理する側は kms、鍵の参照はその保管先の正規の名前（ARN、Transit の鍵名、または CryptoKey のリソース名）です。 保管者の秘密は封印解除ページでのみ渡します。
ローカルの材料から委託の保管先へ移すときは、包み直しウィザードで対象の保管者を選んでトポロジを書き、KEK_PROVIDER=kms に変え、
ローカルの材料を消してから再起動します。再起動後は封印解除ページで止まり、トポロジを照合し、保管者の資格情報を渡し、それから台帳を確かめます。同じ鍵版の遠隔の入れ替えは、保管先の管理者が行います。
データ鍵と監査の署名鍵
Section titled “データ鍵と監査の署名鍵”鍵管理のページで対象を選んで入れ替えます。すぐに効き、再起動も要らず、いまある接続も切れません。 古い暗号文は対応するバージョンの鍵で開き、バージョンの連なりは残ります。 鍵の操作が進行中のとき、切り替えの済んでいない包み直しがあるとき、プロセス内の鍵のキャッシュが古いときは、システムがこの操作を止めます。
JWT の鍵
Section titled “JWT の鍵”.env の JWT_SECRET を替えて再起動します。長さは 32 バイト以上です。替えたあとは全員がログインし直します。
二つの署名鍵
Section titled “二つの署名鍵”エクスポート署名鍵は証拠パッケージ全体の署名に、チェックポイント署名鍵は監査チェーンに使います。二つは意図して分けてあります。 公開鍵は鍵管理のページで複製もダウンロードもでき、外部の検証者が取得できるエンドポイントもそれぞれあります。 エクスポート署名鍵を替えたら、新しい公開鍵を外部の検証者へ自分から渡してください。
通知チャネルの鍵
Section titled “通知チャネルの鍵”アラートのページの通知チャネルでそのチャネルを編集し、新しい鍵を入れて保存します。受け取る側の検証の鍵も同時に更新し、 もう一度「テスト送信」を押して、受け取る側に届き、署名の検証も通ることを確かめます。すぐに効き、再起動は要りません。
入れ替えたあとの共通の確認
Section titled “入れ替えたあとの共通の確認”- フィンガープリントが思ったとおりに変わったこと。自分の記録も更新します。
- 有効な通知チャネルごとにテスト送信を一度押し、受け取る側に本当に届くことを確かめます。
- 監査からこの入れ替えを引けること。
- 環境変数側の鍵については、再起動後の起動ログに起動を拒否するメッセージが無いこと。
監査で見えること
Section titled “監査で見えること”- 鍵の作成、入れ替え、包み直し、退役した材料の片づけは記録に残ります。片づけには片づけた件数と各バージョンのフィンガープリントも入ります。
- 台帳そのものが制御の証拠です。どの鍵があり、誰が管理し、フィンガープリントは何で、前回の入れ替えはいつか。
- マスター鍵のモードが
uiのとき、台帳は封印の状態を示すので、保護されていない材料でサービスが動いているのではないことを示せます。 - 保管先トポロジの変更は前後の値を残し、セキュリティのアラートを出します。封印解除ページの管理者検証と委託資格情報の入力は跡を残します。