工場でクラウドツールの二段階認証を始めるなら、設定する人だけでなく、入れなくなった際に助ける人も先に決めましょう。共用端末、交替勤務、スマホを持ち込めない工程では、同じ方法を全員へ当てはめると業務が止まる場合があるためです。対象ツール、利用者、端末、通常使う認証、予備手段、復旧担当を台帳へ記し、管理者から少人数で試します。この記事では、登録から紛失・交換・退職時の処置までを説明します。
| 状況 | 判断 | 最初の対応 | 続けて調べること |
|---|---|---|---|
| 管理者が未設定 | 最優先で対象にする | 管理者用と日常作業用を分ける | 予備認証と復旧担当の登録 |
| 現場で共用PCを使う | 端末ではなく個人ごとに認証する | 利用者別ログインを用意する | 交替時のログアウトと保存情報 |
| スマホを工程へ持ち込めない | 別の認証方法を選ぶ | 利用中ツールと端末に対応する方式を調べる | 予備手段と保管責任者 |
| 紛失・故障でログインできない | コード共有で回避しない | 決めた連絡先へ復旧を依頼する | 申告者の照合、旧手段の保護・失効、再登録 |
管理者と停止時の影響が大きいツールから調べる
導入順は、利用人数よりも、不正利用やログイン停止の影響で決めます。二段階認証は認証を段階に分ける呼び方で、パスワードに認証アプリなどを加える方式が一例です。一方、多要素認証は、知っている情報、所持している物、生体情報という異なる種類を組み合わせます。同じ種類の情報を重ねるだけでは同じ保護にならないため、名称だけで選ばず、実際の方式と復旧の条件を調べます。
まずメール、ファイル共有、受発注、図面、設備点検、現場入力のツールを一覧にします。管理権限、社外からのアクセス、扱う情報、止まる業務を記し、下の第1〜第3段階を導入順の目安にしましょう。これは現場用を後回しにしてよい区分ではありません。漏えいなどの疑いがあるものは優先して管理者へ渡し、通常の展開計画とは別に保護します。
- 第1段階：利用者追加、権限変更、データ削除ができる管理者アカウント
- 第2段階：図面、顧客情報、受発注情報など漏えい時の影響が大きい個人アカウント
- 第3段階：現場入力、設備点検記録など工程で使う個人アカウント
- 並行して調べる対象：共有アカウント、退職者・異動者のアカウント、長期間使われていないアカウント
台帳では利用者ごとのID、共有ID、使っていないIDを区別します。共有IDを誰かのスマホで認証している場合、認証した人と実際に操作した人が違うことがあるためです。認証端末の登録だけを進めず、共有状態も見直しましょう。退職者や異動前の権限、長く使っていないIDは利用資格と依存する処理を調べ、管理者が停止や引継ぎを判断します。
現場の利用条件に合わせて主認証と予備認証を決める
方式を選ぶ際は、ツールが対応する認証アプリ、セキュリティキー、パスキー、SMSなどと、予備手段の登録条件を提供元の案内で読みます。工程への持込み、通信、手袋などの利用条件も照らしましょう。端末の画面ロックを開いただけでは、クラウド側の認証設定を終えたことにはなりません。パスキーなどで端末の認証を使う場合も、対象サービスへ正しく登録した構成かを試します。
対応するサービスでは、偽サイトへ認証情報を渡しにくいFIDO対応のキーやパスキーも候補にします。認証アプリの一時コードと、こうした方式は同じ特性ではありません。NISTも一時コードの方式とフィッシングへの耐性を区別しています（https://pages.nist.gov/800-63-4/sp800-63b/authenticators/）。対応状況と運用負担を比べ、通常の方法と予備が同じ端末の紛失で同時に使えなくならない構成を選びましょう。
- 利用者ごとに通常の方法を1つ、予備を1つの目安で用意し、同時に失わない管理を決める
- 私物スマホを使う場合は、本人の合意、紛失時の連絡先、退職時の削除方法を先に決める
- セキュリティキーは、貸与先、保管場所、返却を点検する人を台帳へ記録する
- 自分で開始していないログインの認証通知は承認せず、管理者へ連絡する
通知が届いても、「誰かが仕事で困っているのだろう」と承認しません。自分が開いた正規のサービスのログインと対応するかを読み、開始していない通知は拒否して管理者へ知らせます。自分で操作した直後でも、相手に誘導された偽サイトではないかに注意します。認証が通らないときは何度も承認や入力を繰り返さず、表示内容と時刻を残して定めた復旧先へ連絡しましょう。
共用端末でも共有アカウントを使わず個人ログインにする
共用PCやタブレットでも、ツールへのログインは利用者別にする方法を選びます。ID、パスワード、コードを使い回すと、本人の停止や権限変更、操作の追跡を分けにくくなるためです。設備側の制約で個別化できない場合は、提供元の対応方式と社内の例外承認へ戻します。認証コードを順番に受け渡すことを、個別認証の代わりにはしません。
交替時には、終える人のログアウトと、次の人が自分のIDで入ったことを点検します。結果は端末管理表や日報の指定欄へ残しましょう。共用ブラウザの保存済み認証、自動入力、同期された情報も含めて扱いを決めます。パスワードやバックアップコードを端末脇の紙や共用メモへ置くと、認証を分けた意味が失われるため、利用者が限定された指定の保管方法を使います。
- 利用を終える人がクラウドツールからログアウトする
- 次の利用者が前の人のログイン状態を引き継がず、自分のIDで入る
- 端末管理担当が保存済み認証、自動入力、同期設定を所定の周期と端末変更時に点検する
個別ログインにすると操作とIDを対応させやすくなりますが、全操作の履歴が残るとは限りません。記録される範囲と保管期間はサービスで調べます。スプレッドシートの変更履歴を追跡する運用も参考に、業務記録と履歴を照らしましょう。共用利用を残す場合は、利用者、用途、責任者、見直しと終了予定を台帳へ記し、追えない操作の扱いも決めます。
管理者用は、日常の入力や閲覧と役割を分け、管理操作を行うときに使います。通常業務のIDに問題が起きた際、同じ状態で管理権限まで使われる範囲を狭めるためです。サービスが許す範囲でアカウントや役割を分け、別の管理者や復旧経路も用意しましょう。ただし、管理用を別にしただけで端末の侵害まで防げるわけではなく、端末管理も続けます。
少人数の試行で登録手順と連絡先を固める
全体へ広げる前に、管理者と利用条件の違う現場担当で試します。支給スマホ、共用端末、交替勤務などを含めると、登録できても工程では使えない条件を見つけやすくなります。繁忙時や交替直前を避け、復旧担当が対応できる時間を選びましょう。試験中の代替業務と、進められないときに戻す条件も決めてから登録します。
- 登録前：本人のアカウント、主端末、予備手段、会社の連絡先、復旧担当を照合する
- 登録時：主認証と予備認証を登録し、登録完了日を台帳へ記録する
- 登録後：通常と予備の各方式で実際に認証を求める条件を作り、再ログインを試す
- 試行終了時：つまずいた画面、認証が届かない条件、登録と復旧にかかった時間を記録する
試験結果は、登録できたかだけでなく、通常の認証、予備、ログアウト、次の人への交替、復旧先への連絡を記します。以前のログイン状態や認証を省略する設定が残ると、認証を試さずに入れる場合があるため、提供元の方法で認証が実際に求められる条件を試しましょう。ノーコードで現場入力アプリを試作する進め方と同じく、試せた範囲と未試験の範囲を分けて展開します。
ログイン不能時は申告者を照合し、原因別に復旧する
ログインできないときは、申告した人を所定の手順で照合し、原因を分けて復旧します。急いで認証を外したり、新しい認証先を登録したりすると、なりすましに利用されるおそれがあるためです。復旧先は1人に任せきりにせず、主担当と代行、夜勤や休日の連絡方法を決めます。対応者が不在でも、他人のIDを借りるのではなく、承認された代替業務へ切り替えます。
復旧の申告は、本人が名乗った所属や、相手から渡された電話番号だけで判断しません。社内に登録された連絡先への折り返し、既知の上長や対面など、定めた経路を組み合わせます。求める手続は管理権限や扱う情報に合わせて決めましょう。現場向けチャットチャンネル設計も参考に、ログインできないサービスの中だけに連絡先を置かないようにします。
バックアップコードは、通常の端末を失ったときにも取り出せ、他人には使われない場所に保管します。台帳や問い合わせ文へコード自体を貼らず、利用日時と再発行の有無だけを記録します。使い切りや再発行時の旧コード無効化はサービスの仕様に従い、予備を試した後も残る手段を点検しましょう。たとえばGoogleの公式案内では、使用済みコードと再発行前のセットの扱いを説明しています（https://support.google.com/accounts/answer/1187538?hl=ja）。
異動・退職・端末交換の処置を完了まで追う
退職、異動、紛失、端末交換では、連絡を受けた事実と処置を終えた事実を分けます。利用資格を失う時点に合わせてアカウントや権限を止め、引継ぎ未了を理由に元の利用者のアクセスを延ばしません。紛失や不正利用の疑いは定期点検を待たず保護します。一方、手元にある端末の計画交換は、新しい認証と予備を使える状態にしてから旧手段を外す手順を用意します。
- 異動・退職：利用資格に合わせ、IDと権限、認証手段、残るセッションの処置を記録する
- 端末交換・返却：認証アプリ、ブラウザのログイン状態、保存済み認証、貸与キーを点検する
- 復旧後：旧手段を失効させた根拠と、新しい認証・予備の動作を照合する
- 定例点検：利用者、管理権限、通常と予備の認証、休眠ID、台帳の最終見直し日を照合する
月1回などの定期点検は、処置漏れや古い復旧先を拾うために行います。退職や紛失を月次まで待たせるものではありません。対象、実施日、担当、未了項目を台帳へ残し、通常の認証手段だけでなく予備と代行先も点検します。停止済みと書いたIDが利用できないか、サービス側の状態と残るログイン経路も照らしましょう。
二段階認証運用台帳と復旧フローの記入例
下の表は、業務ごとの端末と認証、復旧担当、停止時点を対応させる記入例です。実績や、その組合せが全サービスで使えることを示すものではありません。通常の手段が使えない際にも予備へ進めるか、復旧担当が勤務時間帯をカバーできるかを読みます。ツール名と担当を埋めるだけでなく、利用資格を失う時点や返却前の処置を自社の手順へ合わせましょう。
| ツール名・業務 | 利用者区分・端末 | 主認証・予備認証 | 復旧担当・停止期限 | 最終見直し日 |
|---|---|---|---|---|
| メール 社外連絡・添付資料 | 管理者 個人PC・会社支給スマホ | 認証アプリ 予備の認証方法 | 主担当・代行担当 退職等で利用資格を失う時点 | YYYY年MM月DD日 |
| 図面共有 図面・仕様書 | 設計担当 個人PC | セキュリティキー 認証アプリ | 主担当・代行担当 異動で権限が変わる時点 | YYYY年MM月DD日 |
| 現場点検記録 設備点検の入力記録 | 現場担当 共用タブレット | 個人別の認証方法 定めた復旧手段 | 工程責任者・管理者 端末返却日まで | YYYY年MM月DD日 |
台帳には登録を終えた日、試験結果、紛失や機種変更の連絡先、予備の管理者を加えます。コードや認証用の秘密情報は入れません。Googleフォームで設備点検を記録し一覧化する方法のように点検記録を扱う場合も、入力者の認証だけでなく、回答や写真を見る権限、管理者の復旧先を一緒に調べます。
ログイン不能の連絡は、下の流れで申告者と状況を照合します。紛失・盗難の疑いと、手元の端末でコードが通らない問題は同じ順番で処理しません。対応後は発生時刻、申告者を照合した方法、判断者、実施した操作、旧手段を失効させた時点を残します。新端末で入れたことだけを復旧完了とせず、元の端末から使える経路が残らないかも追います。
- 自分が正規のサービスで始めたログインかを照合する。不審な通知は承認せず管理者へ連絡する
- スマホが手元にある場合は、対象アカウント、コードの期限、端末時刻、通信や方式を切り分け、予備を試す
- 紛失や盗難は申告者と状況を照合し、先に保護措置を判断する。故障や持参忘れも所定の予備・復旧手順へ進む
- 申告者を照合できなければ認証の再設定を保留する。不審な端末や利用資格喪失の疑いは管理者が利用制限を判断する
- 復旧後は旧端末で使える手段とセッションを失効させ、新端末と予備で動作を試す
他人の通常の認証コードを借りる方法では復旧しません。本人と対応付ける根拠が足りない場合は認証の再設定を保留し、管理者が状況を調べます。管理者が発行できる正式な復旧手段がある場合も、提供元の手順と社内承認に従い、相手を照合してから扱います。不明な申告だけで勝手に全員の認証を解除することも避け、保護措置の対象を判断します。
導入初日は、下の項目を管理者が実際に点検し、結果、担当、日付を残します。管理者の登録と現場試行の準備ができたことを、全員の運用完了とは分けて記録しましょう。予備の手段が未試験、代行先が不在、使えない工程がある場合は、対象を広げる前に担当と期限を割り当てます。
- 管理者アカウントに主認証と予備認証が登録されている
- 復旧担当と代行担当の氏名、連絡先、対応可能な時間帯が台帳にある
- 共有アカウント、退職者アカウント、休眠アカウントを区別している
- 現場試行の対象者、日時、端末条件が決まっている
- 試行後の問い合わせと復旧記録を保管する場所が決まっている
点検後は、未登録、試験未了、保留の理由を利用者ごとに追います。設定画面の完了表示だけでは、夜勤の復旧や端末交替まで成立したか分からないためです。試行した条件と問い合わせ先を手順書へ反映し、工程単位で展開します。つまずきが出た場合も一律に認証を弱めず、使えなかった方式と条件を調べて代替を選びます。
よくある質問
認証方法と復旧の役割は、端末の持込み条件や勤務時間で変わります。以下の疑問を、自社の台帳と試行項目を決める材料にしてください。登録方法だけでなく、手段を失ったときに誰が利用を守り、どの業務を代替するかまで決めておきましょう。
私物スマホを認証に使いたくない従業員がいる場合、どう決めればよいですか？
私物スマホを使う前提にせず、支給端末や対応するセキュリティキーなどを候補にします。サービスと端末の対応、工程への持込み、紛失時の保護、契約費用も比べましょう。私物を使う場合は本人の合意と業務情報の管理範囲を決め、退職や返却で個人のデータまで一律に消す手順にはしません。採用した方法と予備は利用者ごとに記録します。
夜勤中に認証端末を紛失した場合、誰がどこまで復旧対応しますか？
夜勤の責任者が連絡を受け、定めた復旧担当または代行が申告者を照合し、アカウントと端末の保護を判断します。紛失した端末の認証やログイン状態の失効は、翌営業日まで一律に待たせません。提供元の手順で使える保護措置を進め、実施できない処置と残るリスクを記録します。新しい端末の準備と業務の代替は、保護の初動と分けて進めます。
認証アプリを入れたスマホを機種変更した時、古い端末の登録はいつ削除しますか？
手元で管理できている端末の計画交換なら、新端末と予備で認証できることを試してから、旧端末で使える手段を外します。紛失や盗難時はこの順番を待たず保護を優先します。認証アプリの同期があると、旧端末でコードを削った操作が新端末にも反映される場合があるため、端末の登録解除とコード削除を混同しないでください。提供元の移行手順を使い、旧手段の失効と新手段の動作を記録します。
共用タブレットしかない工程で、個人アカウントによる二段階認証をどう回しますか？
端末は共用でも、ログインする利用者と認証手段を対応させます。交替時は前の人の状態を残さず、次の人のIDと権限で入るところまで試しましょう。毎回どの認証が求められるか、一定時間の維持や画面ロックをどう設定するかは、サービスと端末の条件で決めます。手間を省くために他人のセッションを使う運用へ戻さず、利用頻度に合う対応方式を選びます。
まとめ
まず管理者と業務停止の影響が大きいツールを選び、利用者、端末、通常の認証、予備、復旧先を台帳へ記しましょう。次に、条件の違う少人数で登録から再ログイン、交替、予備、紛失時の連絡までを試します。試した条件と結果を工程の手順へ移し、未了が残る対象を分けてから広げます。
運用後は、ログイン不能の内容、復旧で迷った点、共有IDと休眠ID、古い認証先を定期的に点検します。それとは別に、異動、退職、紛失、端末交換の時点で処置を行い、実施した人と結果を残してください。二段階認証を設定したことだけで安全とせず、利用者が変わっても認証と復旧を維持できる手順へ更新しましょう。
