1.

個人特定の困難さ

複数のユーザーで同一のIDを共用するため、アクセスログから「誰がどの操作を行ったか」を特定できず、インシデント発生時の実態把握が極めて困難です。

2.

不正アクセスのリスク

退職者が共有IDのパスワードを把握したまま離職するケースや、定期的なパスワード変更が徹底されないことによる不正アクセスのリスクが常在しています。

3.

運用負荷の増大

ユーザーの異動や退職のたびにパスワードを変更し、利用する全ユーザーへ安全に周知しなければならず、管理コストが増大し続けます。

4.

認証強度の低さ

パスワード認証に依存している場合が多く、フィッシング攻撃やリスト型攻撃に対して脆弱です。

1.

現場端末の共用

工場・店舗・窓口などで複数人が1台を交代利用。個別ログインの手間が業務停滞を招くため、共有IDで常時ログインし効率を優先。短時間作業や即応性が重視される現場で残りやすい。

2.

外部委託・派遣の短期利用

派遣社員やベンダー要員が頻繁に入替わる環境では、個別IDの発行・削除・棚卸の運用負荷が高い。期間限定の共有IDでアクセス範囲を絞り、管理コストを抑えて対応している。

3.

レガシーシステムの制約

古い業務アプリや装置が個人IDやSSOに未対応。改修コストや影響が大きく、当面はアプリ共通IDで運用せざるを得ない。別途ログ取得などで利用者識別を補完している。

4.

緊急時・障害時の対応

障害対応や災害時に迅速なアクセスが必要な場面では、個別認証の手続きがボトルネックになる。事前に共有IDを用意し、即時対応を優先する運用となっている。

課題

共有IDとそのパスワードを複数人が知っており、退職に伴う変更・配布の手間や、個人が特定できないなどセキュリティリスクがある

制約

業務アプリケーション側の認証機能は改修できない、または改修コストを許容できない

ゴール

認証強化により個人を特定した上で、予め許可された共有IDによるアプリアクセスを実現し、既存アプリ改修なしでセキュリティ・利便性・運用効率を同時に向上させたい

1.

認証テーブル

個人ID [UID]、パスキー情報、ログイン日時などを管理します。

2.

共有ID権限マッピングテーブル

「個人ID、アプリID、共有IDリスト」の3つのカラムで構成されるテーブルです。このテーブルは、管理者がID管理システムを利用して、最新状態を維持します。

3.

カスタム認証プラグイン

個人ID [UID] とアクセス先のアプリIDをパラメータとして、後述するサーブレットへAPI問い合わせを行います。

4.

共有ID照会サーブレット

カスタム認証プラグインからの問合せを受けて共有ID権限マッピングテーブルを参照し、個人に許可された共有IDのリストを応答します。

共有IDが複数ある場合

利用可能なIDをリスト表示し、ユーザーに選択を促します。

共有IDが1つの場合

確認のため、その1つのIDを選択肢として表示する運用が可能です。

共有IDが存在しない場合

APIが「AppUserGuest（機能制限付きゲストID）」などの固定IDを返却することで、未登録ユーザーに対しても制限付きのアクセスを許可するなどの制御が可能です。

1.

アクセス要求

ユーザーがブラウザから、IceWall MFAプロキシ経由のWebアプリケーションのURLへアクセスを試みます。

2.

パスキー認証画面表示

未ログインのため、IceWall MFAはパスキー認証画面を表示します。

3.

生体認証

ユーザーは、Windows Helloなどの生体認証を用いたパスキー認証を行います。

4.

個人IDの特定

IceWall MFAは、正確なパスキー認証により、個人ID [UID] を特定します。

5.

共有IDリストの問合せ

IceWall MFAのカスタム認証プラグインは、認証DBとの間に位置する「アプリ共有ID権限参照サーブレット」に対してAPI要求を送信し、権限のある共有IDを照会します。

6.

共有IDの照会

共有ID照会サーブレットは共有ID権限マッピングテーブルを参照して、個人IDに対して、アプリ毎に権限付与された共有IDリストを取得、API要求に対して応答します。

7.

共有ID選択画面の表示

IceWall MFAは、カスタム認証プラグインが取得した共有IDリストをユーザーに提示し、ラジオボタン形式などで選択させます。

8.

共有IDの選択

ユーザーは、ログインしたい共有IDを選択します。

9.

キャッシュ更新とリクエスト中継

ユーザーが共有IDを選択すると、カスタム認証プラグインは、認証セッションに紐づくキャッシュ上のユーザー属性として、その共有ID情報(ID、PW等)を更新します。その後、MFAプロキシ経由でHTTP要求を中継、「HTTPヘッダ継承」または「自動フォーム認証（代行認証）」により、共有ID情報を用いてアプリケーションにログインします。

10.

コンテンツ表示

アプリケーションはログイン後画面を応答します。

1.

個人の特定が可能

パスキー認証で個人を特定した後に共有IDへ引き継ぐため、操作ログの追跡が可能となり、内部不正の抑止とインシデント対応力を強化できます。

2.

不正アクセスリスクを解消

ユーザーは最初から共有IDのパスワードを知らないため、退職者発生時など、不正アクセスのリスクを排除できます。

3.

運用負荷の軽減

ユーザーに共有IDのパスワードを教える必要がないため、パスワード変更や再周知といった運用コストを削減できます。更にIceWall MFAが認証を代行するため、既存アプリの認証画面改修も不要です。

4.

認証強度の高さ

フィッシング耐性に優れた安全性の高いパスキー認証により、パスワードの課題を解決します。