多要素認証の導入を検討する際、多くのサービスはインターネット接続を前提としています。しかし実際の現場には、ネットワークに繋がっていないPCが残っていることが少なくありません。工場の制御系端末、外部接続を許可していない閉域網のPC、単独で稼働しているスタンドアロン機などです。この記事では、こうした環境でOSログインの認証を強化する場合に、どの方式なら成立し得るのか、そして導入前に確認すべき前提条件を整理します。
クラウド前提の認証が使えない環境は実際にある
認証強化の話題では多要素認証の基本のとおりクラウドサービスとの連携が前提になりがちですが、次のような環境では同じ前提が使えません。
- 工場の制御系端末 — 生産設備の操作や監視を担うPCで、外部接続を意図的に遮断している場合
- 閉域網に置かれた業務端末 — 社内ネットワークのみに接続し、インターネットへは出られない構成
- スタンドアロンPC — 特定の用途のために単独で設置され、ネットワークに接続していない端末
- 災害時・障害時 — 平常時は接続できていても、回線やクラウド側の障害でネットワークが使えなくなる状況
最後の項目は見落とされやすい論点です。普段はオンラインで運用している端末でも、いざネットワークが落ちたときにログインできなくなるのであれば、それは業務停止のリスクになります。
外部と繋がっていないから安全、とは言い切れない
こうした環境の認証は、「インターネットに繋がっていないのだから外部からは侵入されない」という理由で後回しにされがちです。この前提は完全に誤りではありませんが、侵入経路は外部からの直接アクセスだけではありません。
たとえば、作業者が持ち込んだノートPCやUSBメモリを介した経路、保守作業のために一時的に外部接続を行う場面、社内ネットワーク側で侵害された端末を経由して閉域側に到達する経路などが残ります。また、そもそも物理的にその端末の前に立てる人が、パスワードだけでログインできてしまう状態そのものが課題です。閉域網であっても、誰がその端末を操作したのかを本人に紐づけて確認できる状態にしておく意味は変わりません。特権的な権限を持つ端末についてはサーバーの特権アカウント管理の観点も併せて確認してください。
オフラインでも成立する認証方式の考え方
判断の軸はシンプルで、認証の照合が通信を伴わずPC本体側で完結するかどうかです。認証のたびに外部のサーバーへ問い合わせる設計であれば、ネットワークがない環境では動きません。逆に、PCに接続した物理デバイスの情報や本体の生体認証センサーの情報を、PC側で保持している登録情報と照合して完結する方式であれば、ネットワークの有無に依存しない構成になり得ます。
具体的にどのようなデバイスを使う方式があるかはハードウェアセキュリティキーの解説で扱っています。また、スマートフォンを配布していない現場での選択肢はスマートフォンなしで多要素認証を行う方法を参照してください。制御系の端末では業務用のスマートフォンを持ち込めない、あるいは支給していないケースも多いため、この観点は実務上重要になります。
オフラインでは成立しにくい方式
一方で、次のような方式は閉域網やオフライン環境では前提が崩れます。導入検討の初期段階で除外しておくと、検証の手戻りを避けられます。
- 認証のたびに外部サーバーへ問い合わせる方式 — クラウド側の認証基盤に到達できなければ照合が成立しません
- メールやSMSでコードを受け取る方式 — 受信そのものにネットワークや通信回線が必要になります
- 時刻の同期を外部に依存する方式 — ワンタイムパスワードのように時刻を基準とする仕組みでは、端末側の時刻がずれると照合が失敗する可能性があります
導入前に確認すべき前提条件
オフライン環境への導入では、認証方式そのものより運用が回るかどうかで成否が分かれます。次の点を、製品比較を始める前に確認しておくことをおすすめします。
- 認証がPC単体で完結するか — ログイン時にサーバーやクラウドへの通信が必要か、初回設定時のみ必要かを切り分けます
- 登録と解除をどこで行うか — 利用者の登録、デバイスの追加・失効といった管理操作を、その端末の手元で実施できるのか、管理サーバー側でしか行えないのかを確認します
- ネットワーク断のときに管理操作ができるか — 障害時にデバイスを紛失した利用者が出た場合の対応可否です
- 保守ベンダーのアクセス手順 — 設備の保守担当者がその端末にログインする必要がある場合、誰のアカウントでどのように認証するのかを事前に決めておきます
- 復旧手段 — デバイスの故障や紛失でログインできなくなったときに、業務を止めずに復旧できる代替手段が用意されているか
端末が社内ドメインに参加しているか、単独で管理されているかによって前提が変わります。この違いについてはローカルアカウント・ドメイン・Entra IDの違いで整理しています。
ネットワーク断でも業務を止めないための備え
オフライン環境の検討で最も大切なのは、認証基盤が使えない状況でログインできなくなる設計になっていないかという点です。認証強化は本来、業務を守るための対策です。それが原因で復旧作業に着手できないという事態は避けなければなりません。
そのためには、平常時の運用手順だけでなく、ネットワークやクラウドが使えないときの手順を書面として残しておくことが有効です。誰が復旧を判断し、どの手段で認証を通すのかを決めておけば、実際に障害が起きたときの混乱を抑えられます。Windows環境全体での具体的な導入手順についてはWindows OSログインの2要素認証で解説しています。
まずは自社の状況を確認する
閉域網やオフラインの端末がどれだけあり、それぞれがどのように認証されているかは、社内でも把握が分かれやすい領域です。applippliの無料診断では、約3分の質問に回答するだけで、自社の認証・アカウント管理の対応状況を確認できます。まずは現状の棚卸しから始めてみてください。