新しい業務システムのログインはどう決める？普段の確認と端末を失ったときの復帰

認証・権限・SSO・多要素認証を、仕事との関係で分ける

認証：そのアカウントを使う本人かを確かめる

登録された確認手段を利用者が使えることなどから、アカウントの利用者を確かめる仕組みです。ログイン時の認証と、最初に誰のアカウントとして登録するかという身元の確認は、同じ手続きとは限りません。

権限：入った後で、何を見たり変更したりできるかを決める

ログインできても、担当外の作業記録を見てよいとは限りません。この記事では、必要な作業記録へ進めたかを認証後の別の確認として扱います。会社全体の細かな権限モデルの作り方は、今回の方式判断と分けます。

認証元：利用者を確かめるサービス

社員のアカウントと確認手段を管理し、利用者の認証を行う側です。一般にIdPと呼ばれるサービスを使う場合があります。社員情報を保管する場所と、実際にログインを確かめるサービスが同じかどうかも、管理担当へ確認します。

SSO：共通の認証元を使って、複数のアプリへ入る仕組み

シングルサインオンの略です。認証元で確かめた結果を接続先アプリが受け取り、確認して利用につなぎます。社員IDがあるだけで、すべてのアプリへ自動的につながるものではありません。

多要素認証：異なる種類の確認を組み合わせる

MFAとも呼ばれます。知っていること、持っているもの、本人の身体的な特徴など、異なる要素を組み合わせます。画面が二回出ることや、パスワードを二回入力することだけで、多要素になったとは判断しません。

SSOと多要素認証は、別の問いに答える仕組みです。どの認証元を複数のアプリで使うかと、利用者を何で確かめるかを分けます。SSOにしただけで多要素認証が必要な経路へ適用されたとも、各アプリの権限が正しいとも言えません。

米国NISTのSP 800-63B-4は、認証手段とその管理、回復を扱う技術ガイドラインです。別冊のSP 800-63C-4は、認証元と接続先が認証結果を受け渡す連携を扱います。ここでは用語と設計上の区別を参考にし、日本の民間企業すべてに特定の保証水準や方式が義務付けられるとは扱いません。NIST SP 800-63B-4の公表情報・SP 800-63C-4の連携の説明

一人の現場担当が、何をするために入るかから始める

まず、現場担当が作業記録を確認する一つの場面を、業務担当と開発先へ説明します。「社外でも使えるように」だけでは、利用する端末、必要な情報、接続できないときの影響を判断できません。次の内容を同じ場面についてそろえます。

1. 必要な仕事と情報。どの現場の何の作業記録を見るか、閲覧だけか更新も必要か、ほかの人の情報を含むかを確認します。この架空例では「作業記録の確認」までで、個々の記録や更新権限は与えられていません。
2. 利用する場所と端末。外出先のどんな状況で、会社支給か個人所有か、共用か専用か、どのアプリやブラウザーを使うかを聞きます。「外出先」から、通信がない場所でも使えるという条件を補いません。
3. 既存の社員IDと管理担当。どこで発行・変更・停止しているか、今回の利用者が対象か、認証元として使えるサービスがあるかを確認します。IDの記録が存在することと、現在そのIDで利用できることは別です。
4. 入れない場合の影響。作業を待てる範囲、連絡できる時間帯、現場で使える別の承認済みの方法を確認します。安全な例外手順が未定のまま、「困ったら確認を外す」と決めません。

この場面から、本人確認に必要な強さと、現場が使える手段を検討します。IPAのガイドライン第4.0版も、システムや情報の重要度に応じて認証の強度と実装方法を決める観点を示しています。本稿の架空例から、製品や設定の安全性を認定するものではありません。IPAガイドライン・本文32ページ

既存の社員IDを、どのアプリにつなげられるか確かめる

IT発注担当は、社員IDを管理する担当と、作業記録アプリの開発先の両方へ接続条件を聞きます。一方が「SSO対応」と答えたことだけで、今回の組合せが使えるとは決めません。対象のアプリ、利用者、利用方法について対応を確かめます。

既存の認証元と、アプリの連携方法が合う場合

既存の認証元を使う構成を候補にします。どの利用者のどの情報をアプリへ渡し、アプリがどのアカウントとして扱うかを確認します。登録・異動・退職の変更がどこまで反映され、誰が未反映を確認するかも取り決めます。

古いアプリなどで、そのまま接続できない場合

アプリ側の改修、対応する仲介方法、対象を分けた移行などを開発先と比べます。代替方式を採るなら、多要素認証、記録、変更・停止、障害時の扱いも確認します。接続できないアプリがあるという理由だけで、全社員へ新しいパスワードを増やす結論にしません。

認証元や接続可否がまだ分からない場合

対象アプリを一つに絞って調べる作業を、方式の確定や全社展開と分けます。調査する担当、確かめる環境、回答に必要な資料を決め、未回答の接続を「できる前提」の見積もりへ入れないようにします。

共通の認証元へ集約すると管理をそろえやすい一方、その側の障害や設定変更が複数のアプリへ影響する可能性があります。アプリごとの認証を残す場合にも、複数の登録・停止・復帰を管理する仕事が残ります。方式の利点と、その方式で増える運用責任を一緒に比較することが必要です。

普段のログインは、追加確認と業務開始までつなげる

最初の登録と、毎回のログインを分ける

確認端末を持っていても、アカウントへ正しく登録されているか、その端末で必要な確認ができるかは別です。初めて確認手段を登録する手順、登録する人を確かめる方法、普段の利用方法を、認証元の担当と開発先へ確認します。登録の完了を、実際のログイン成功の代わりにしません。

追加確認の条件と、使える手段を決める

どのアプリ・利用状況で追加確認を行うか、利用者が用意できる手段、端末や通信の制約、利用できない人への対応を整理します。方法によって、なりすましへの耐性や利用条件が異なります。「MFA」という名称だけで同じ安全性・運用負担とは扱わず、対象の情報と会社の要件を担当者と照合します。

認証を代行するサービスとアプリ側の両方に設定がある場合は、どちらがどの条件を判断するかを確認します。アプリへ別の入口が残っているなら、その入口も含めて必要な確認が適用されるかを調べます。普段の経路が一つ動いたという理由だけで、すべての入口の確認を済ませたことにしません。

認証が終わった後、必要な作業記録へ進めるか確かめる

認証元で成功した表示、アプリへログインできた状態、必要な作業記録を閲覧できた状態を別々に確かめます。対象の社員と試験条件をそろえ、担当外の記録まで見える状態を合格へ含めないようにします。ログイン後の権限が未確認なら、認証の成功だけで業務利用の受入を終えません。

また、しばらく使っていないときや、作業を終えてログアウトしたときの扱いも確認します。ログイン後に利用を続ける状態は、一般にセッションと呼ばれます。再び確認を求める条件、共用端末に状態を残さない扱いなどを、会社の情報と利用環境に合わせて決めます。一律の時間値を、この架空例から設定することはできません。

確認端末を使えないときは、残る手段と復帰の責任を確かめる

端末が使えないことと、すべての確認手段を失ったことは別

紛失の案では、想定した確認端末を使えないという条件があります。しかし、別の登録済み手段が使えるか、予備の手段があるかは分かりません。まず認証元の運用担当へ、利用者に残っている手段と、そのサービスが認める経路を確認します。

ほかの有効な登録済み手段で認証できる場合は、それを使って新しい確認手段を登録できる可能性があります。必要な手段をすべて使えない場合には、アカウントを回復するための別の手続きが必要になります。端末一つの紛失を、すべてのサービスで同じ復帰手順になると決め付けません。

NIST SP 800-63B-4は、新しい手段の登録とアカウント回復を区別し、紛失や不正利用のおそれがある手段の扱いも説明しています。本稿ではその区別を確認の観点として使い、特定の回復手段や手続きの省略を一律に指示しません。NISTのアカウント回復の説明

申告を受ける人と、復帰を認める人を決める

利用者は、端末が使えないときに、どの窓口へ連絡するかを知る必要があります。窓口が申告を受けることと、本人を確かめて再登録を認めることは別の役割です。会社の管理者、認証サービスの運用担当、アプリの開発先のうち、誰が何を確認し、どの権限で処理するかをそろえます。

申告した人の説明だけで確認を解除するような例外にしないため、サービスの正式な回復方法、会社が定める確認手順、判断の記録と通知を決めます。担当が不在の時間帯や、本人確認に必要な情報が足りない場合の連絡先と保留条件も合わせます。実際の秘密値を、相談用の資料や別のAIへ転記する必要はありません。

古い手段の停止、新しい手段の登録、再開の確認を分ける

新しい端末や確認手段を登録しても、古い手段が使えなくなったとは限りません。古い登録をどこで停止・無効化し、何を見て完了とするかを担当へ確認します。紛失した機器そのものの管理や、すでに入っているアプリのセッションの扱いは、認証手段の登録とは別に確認が必要です。

新しい手段の登録後は、許可された試験で認証が行えるか、作業記録アプリへ入れるか、必要な記録へ進めるかを確かめます。登録済みの一覧へ表示されたことだけで、業務へ戻れたとは扱いません。この架空例では、古い手段の無効化、新しい登録、ログインと記録閲覧の結果はいずれも未確認です。

図で、普段入る道と、端末を使えないときの確認先を読む

図を原寸で開く

二つの条件は、端末の違いと共通の未確認をまとめて読む

普段の案には確認端末があり、別の紛失案ではその端末を使えません。社員IDと作業の目的は共通ですが、接続、追加確認、復帰の担当、ログインや記録閲覧の結果は、どちらも未確認です。二つは仮定の条件で、実際の試験や改善前後ではありません。

確認端末を使えないことを、社員IDがない、すべての手段を失った、閲覧権限がない、という別の状態へ読み替えません。担当の回答と確認結果を得てから、該当する条件を更新します。

回答によって、発注する範囲と保留する条件を変える

問い合わせの返事を受け取るだけで終えず、どの仕様や担当を更新するかまで決めます。次の問いを、社員IDの管理担当、業務担当、認証元の運用担当、アプリの開発先で読み合わせます。

「この社員IDは、今回のアプリの認証に使えますか」

接続する認証元、対応方法、対象の利用者、必要な改修、利用条件を聞きます。接続可能という回答なら、誰のどの情報をアプリへ渡すかを具体化します。非対応や調査中なら、調査・代替案・対象を分ける範囲を更新し、接続済みを前提とした切替を保留します。

「追加確認は、どの入口で、何を使って行いますか」

実際のアプリの入口と適用する条件、現場が利用できる手段、登録と変更の責任を聞きます。利用できない端末や未対応の入口があれば、例外の管理と検証を仕様に加えます。SSOやMFAという名前だけを受入条件にしません。

「確認端末を使えない人に、残っている手段と正式な復帰経路はありますか」

別の登録済み手段が使えるか、その場合の新規登録と、アカウント回復が必要な場合を分けます。サービスが用意する方法と会社の確認手順が合うかを担当へ聞きます。担当が不明なまま、利用者任せの再登録や確認の解除を標準にしません。

「誰が申告を受け、誰が何を確認して処理を認めますか」

受付、本人の確認、再登録を認める判断、古い手段の無効化、結果の記録と通知を、実際の権限に対応させます。同じ担当が複数の役割を持つ場合も、それぞれ何を終えたかを区別します。会社の承認者とサービスの処理担当の両方が必要なら、受渡しを仕様へ含めます。

「古い手段と、すでにログインしている状態はどう扱いますか」

認証元の登録、対象アプリのセッション、必要な機器管理のうち、今回どこまでが対象かを決めます。新しい登録をしただけで旧端末や古い状態が無効になったとは判断せず、各管理担当の確認方法を合わせます。

「ログインの後、どの作業記録まで確認できれば業務を再開したと言えますか」

業務担当が必要な記録と操作を示し、開発先が試験で確認する方法を決めます。ログインできたが必要な記録へ進めない場合と、担当外まで見えてしまう場合を区別します。権限を広げることで認証の問題を解決したことにしません。

回答は、対象アプリと利用者、接続先、普段と例外の手順、各役割の担当、期待結果へ反映します。方式が決まっていても、利用できない人の経路や復帰の責任が未回答なら、その条件を未完として残します。調査が済んだ部分だけを、合意した範囲の設計・検証へ進めます。

普段の利用と復帰を、許可された環境で別々に確かめる

図が描けたことと、実際に利用できることは別です。権限のある担当者と、試験環境・試験用アカウント・使える端末・変更してよい範囲・戻す方法を先に決めます。ここで実際の社員の端末を紛失状態へ変更したり、必要な認証を外したりする操作を指示しているわけではありません。

1. 期待する状態をそろえる。対象の社員に相当する試験条件で、どこが認証し、追加確認がいつ行われ、どのアプリと作業記録へ進めるかを決めます。確認する担当と、結果を見分ける記録・画面も合わせます。
2. 普段の経路を通して確かめる。確認手段の登録、認証元での確認、アプリへのログイン、必要な作業記録の閲覧を分けて記録します。必要に応じてログアウトや再度の確認も試し、画面の一部が表示されたことだけで全経路を合格にしません。
3. 端末を使えない条件は、別の試験として用意する。サービスが認める代替手段や回復方法で、申告・確認・判断・必要な停止・登録を、決めた担当が行えるかを確かめます。残る有効な手段がある場合と、別の回復が必要な場合を区別し、未実施の経路を試験済みにしません。
4. 業務への復帰と、古い手段の扱いをそれぞれ確かめる。新しい手段でログインできたか、必要な作業記録へ進めるか、古い登録は予定どおり扱われたかを別々に確認します。セッションや機器管理も対象にした場合は、その結果を対応する担当が確かめます。
5. 期待との差を、同じ利用条件で返す。どの経路のどの段階で違いがあったかを示し、原因と変更後の結果を調べてから更新します。入力欄へ文字を入れられたことと、認証が完了したことも混ぜません。入力の使いやすさを詳しく調べる場合は、パスワードと確認コードの貼り付けを確かめる方法で別に扱っています。

運用へ渡す際は、現場担当が知る連絡先と、管理担当が使う確認・記録・回復の手順をそろえます。利用者の登録・異動・退職、確認手段の変更や停止、担当不在時の扱いが更新されたら、関連する説明と試験条件を見直します。この記事の架空例では、実際の認証や復帰、安全性、法令・保険条件への適合を検証していません。

まとめ：方式名より先に、入る条件と戻る担当をそろえる

新しい業務システムのログインを発注するときは、一人の社員が何の仕事へ入るかから考えます。既存の社員ID、認証元、対象アプリの接続を確かめ、普段の確認と、端末を使えない場合の代替・復帰を分けます。SSOや多要素認証の名称だけで、全入口への適用、復帰の可能性、作業記録への権限まで確認したことにはなりません。

端末を失った場合も、残る手段、新しい登録、古い手段の停止、申告・確認・判断する担当、業務再開の証拠を合わせます。未回答の条件は保留し、回答で仕様を具体化してから、許可された試験で普段と例外の期待・実結果を別々に確かめます。