管理画面のパスワードを変えると全員がログアウトするとき｜「本人確認用の値」と「ログイン維持の署名鍵」を分けて持つ設計

自社で使っている管理画面のパスワードを変えたら、スタッフ全員が一斉にログアウトして、店舗から「入れません」と連絡が来る。あるいは変更したのに古いパスワードで入れてしまう。どちらも設定ミスではなく、その管理画面が認証情報を1つの値で兼用していることが原因です。

結論から書きます。管理画面の認証情報は、①本人を確かめるための値（パスワード）と、②ログイン状態を保つための署名鍵（トークン・シークレット）の2つに分けて持つのが正しい設計です。そして日常的に変更してよいのは①だけ。②を変えると、その鍵で発行済みのログイン情報すべてが無効になり、全端末が即ログアウトします。

この記事は、24店舗の美容サロンFC（社名は伏せます）向けに自社開発した口コミ運用システムで、実際にこの2つを切り分けて運用している内容をもとにしています。WordPressのような既製CMSでも、外注で作った業務システムでも、確認すべきところは同じです。

まず「変えていい値」と「触ってはいけない値」を分ける

ログインの仕組みは、ざっくり2段階に分かれています。

段階	役割	保存のされ方	変更したとき
①パスワード	入るときに本人かどうか判定する	ハッシュ化して保存（元の値は復元できない）	既存のログイン状態は維持される
②署名鍵	「ログイン済み」の証明書に署名する	サーバーの環境変数に平文で持つことが多い	発行済みの証明書が全部無効＝全端末ログアウト

②はブラウザのCookieに入っている「ログイン済みの札」が偽造されていないかを検証するための鍵です。長期ログイン（たとえば有効期限180日のCookie）を許可しているシステムでは、この鍵を変えた瞬間に、社内・店舗・自分のスマホを含めて全員が入口に戻されます。

やってしまいがちなのは、環境変数の一覧を見て「ADMIN_TOKEN という名前だから、これが管理者パスワードだろう」と判断して書き換えてしまうことです。名前にトークンやキーと付いている値は、パスワードではなく②の側である可能性が高いと考えてください。パスワードを変えたいときに探すのは、PASSWORD_HASH のように「ハッシュ」が付いた項目です。

変更前に確認する3点

1. その値がCookieやセッションの署名に使われていないか。ソースを検索して、ログイン処理（セッションを作る関数）にその値が渡されていないかを見る。渡されていれば触ってはいけない側です
2. パスワードの変更手段が別に用意されているか。まともに作られているシステムなら、ハッシュを生成して環境変数に書き込む専用スクリプトが同梱されています。無ければ、そこを先に作るほうが安全です
3. 変更後の反映に再起動が必要か。環境変数ファイルから読む構成なら、ファイルを書き換えただけでは反映されません。プロセスの再起動までが1セットです

手元の値とサーバーの値が違うとき、値を画面に出さずに照合する

「パスワードを控えてあるのに入れない」という状況は、手元のメモとサーバーの実際の値がずれているときに起きます。ここで両方をターミナルに表示して見比べたくなりますが、画面やチャット、記録用のメモに認証情報の本体を出してしまうと、そこから漏れる経路が増えるだけです。

正しいやり方は、両方をハッシュ化して、その先頭数文字だけを比べることです。

# 値そのものは出さず、指紋だけを突き合わせる
shasum -a 256 手元の値のファイル | cut -c1-12
# サーバー側も同じ処理をして、12文字が一致するかを見る

一致すれば同じ値、違えば別物だと確定できます。実際にこの方法で、手元に保存していた値（44文字）とサーバーの値（45文字）が別物だったことを、値を一度も表示せずに判定できました。文字数が1つ違うだけなので、目視では気づけません。

同じ理由で、新しいパスワードをスタッフに渡すときはクリップボード経由（pbcopy など）にして、チャット本文や作業記録には残さない運用にしておきます。値の保管先は自分のPCの権限600のファイル1か所に限定し、「どこに置いたか」だけを記録します。

変更した後は「入れること」と「弾かれること」の両方を試す

パスワードを変えたあと、新しいパスワードで入れたことだけを確認して終わるケースが多いのですが、それでは半分しか検証できていません。古いパスワードで弾かれることまで確認して初めて、変更が実際に効いたと言えます。

• 新しい値 → ログイン成功（200が返る）
• わざと間違えた値 → 拒否される（401が返る）

この2つが揃わないと、「新しい値も通るが古い値も通る」状態、つまり変更が反映されていない可能性を消せません。ログイン画面から手で試してもいいですし、ログインのAPIに直接投げて応答コードを見る形でも構いません。

「再発行」は思っている範囲より広く波及する

パスワードだけでなく、ログイン不要の秘密リンク（URLに長いトークンを含めて、その人だけに渡す方式）を使っている場合も、再発行の波及範囲を先に洗い出しておきます。

たとえば同じFC向けに運用しているオーナー向け書類ポータルでは、オーナーごとの秘密リンクと、倉庫スタッフ用のアップロード専用リンクを発行しています。ここで注意が必要なのは、短いURLから本来のリンクへ転送する設定をサーバー側に持たせている場合、リンクを再発行したら転送先も書き換えないと、短いURLが死ぬという点です。管理画面の「再発行」ボタンはアプリ内の値しか更新しないので、外側の設定は自動では追従しません。

再発行する前に、次のリストを作っておくと事故を防げます。

• そのリンク・パスワードをどこに配ったか（印刷物、QR、LINEの配信文、手順書PDF、ブックマーク）
• サーバー側の転送設定に埋め込まれていないか
• 期限付きならいつ切れるか（有効期限7日のリンクを手順書に刷ってしまうと、刷った時点で寿命が決まります）

紙やPDFに刷ったものは回収できません。手順書には長いトークン付きURLを直接書かず、短縮URLとQRだけを載せて、実体は後から差し替えられるようにしておくのが安全です。

似たシステムを複数持っていると、混同そのものが事故になる

店舗ビジネスでシステムを増やしていくと、「管理画面のパスワード」が何本も並ぶことになります。口コミ運用システム、通知ツール、書類ポータル、予約関連。記録を見返したとき、どのパスワードがどのシステムのものか判別できないと、関係ないシステムの値を書き換えてしまうという一番痛い事故につながります。

対策は地味ですが確実です。

1. 保管ファイル名にシステム名を必ず入れる（〇〇-admin-password のように用途が読める名前にする）
2. 記録側には「値」ではなく「どのシステムの、何用の値が、どこにあるか」だけを書く
3. 別システムのパスワードが紛れ込みやすい記録（サーバー情報をまとめたメモなど）には、どのシステムのものかを明記する注記を添える

サーバー情報をまとめたメモに別ツールの管理パスワードが混在していると、同じ画面を触っている担当者ほど「これだろう」と読み違えます。値を消してしまうと今度は必要なときに探せなくなるので、消すのではなく「これは〇〇用・別システム」と1行添えておくのが実用的です。

よくある疑問

Q. パスワードを変えたのに、スタッフのスマホはログインしたままです。これは危険ではないですか。

A. 危険かどうかは目的によります。パスワード変更の目的が「値が漏れたかもしれないので入口を閉じる」なら、既存のログインが残っているのは不十分です。その場合は署名鍵の側も入れ替えて、全端末を強制的に入口へ戻す必要があります。逆に「定期的な棚卸しとして変えるだけ」なら、既存のログインを切らずに済むほうが店舗に迷惑をかけません。漏洩対応と定期変更は別の作業だと分けて考えてください。

Q. 退職者が1人出ました。全員のログインを切るしかないですか。

A. 管理画面が「全員で1つの共通パスワード」を使っている構成だと、切るには全員に影響が出ます。人が入れ替わる前提の運用なら、ログインを個人単位（ユーザーごとのアカウント）にしておくほうが後で楽です。ただし店舗数が増える途中の段階では、共通パスワード＋本部のみ利用に絞っておき、店舗スタッフには秘密リンクなど別の入口を渡す構成でも十分回ります。最初から個人アカウントを作り込むより、誰が入るのかを先に確定させるほうが早いです。

Q. 変更作業はどのくらいの時間を見ておけばいいですか。

A. 値の生成と書き換え自体は数分です。時間がかかるのは前後の確認で、変更前の波及範囲の洗い出しと、変更後の「入れる・弾かれる」の実測を含めて30分程度を見ておくと安全です。再起動が必要な構成では、店舗が管理画面を使っていない時間帯にやるのが基本になります。

引き継ぎ時に確認しておく項目

制作会社や前任者からシステムを引き継ぐとき、認証まわりで聞いておくべきことは3つだけです。

1. パスワードを変更する正式な手順（管理画面から変えられるのか、サーバー側の操作が必要なのか）
2. 変更してはいけない値があるか（あるなら、その名前と理由）
3. 秘密リンク・共有URLを配っている先の一覧

3つめは引き継ぎ資料から抜けやすい項目です。リンクを配った相手が資料に残っていないと、再発行のたびに「どこかで誰かが使えなくなる」状態を引き当てることになります。引き継ぎの時点でリストが無ければ、その場で作ってもらうほうが早く終わります。

まとめ：変更前に決めておくこと

• 管理画面の認証情報はパスワードと署名鍵の2本立て。変えていいのはパスワード側だけ
• 環境変数名に「トークン」「キー」と付いた値は、ログイン維持の署名鍵かどうかを先に確認する。署名鍵を変えると全端末が即ログアウトする
• 手元とサーバーの値が違うか調べるときは、ハッシュの先頭数文字だけを比べる。値そのものを画面に出さない
• 変更後は「新しい値で入れる」と「古い値で弾かれる」の両方を実測する
• 再発行は配布先・サーバー側の転送設定・有効期限まで波及する。先に配布先リストを作る

外注で作ったシステムを引き継いだ場合は、納品時に「パスワードを変更する手順」と「変更しても既存のログインが切れないこと」を確認しておくのがおすすめです。ここが用意されていないシステムは、担当者が変わったタイミングで必ず詰まります。