今回はクライアントアプリ等のシステムから YubiKey を使ったログイン認証の組み込みや運用のことを考えてみましょう。
考察だけで、架空のシステムに対する詳細設計や実装などはしません。今回は、スタンドアローンのクライアントなり、クラサバなりのシステムに対するログイン認証の一般的な設計を理解している前提で話を進めます。
さて、ログイン認証の際、ユーザが何を入力する必要があるのか?これが YubiKey を使ったシステムでのポイントになりそうです。
大きくは以下の3パターンで考えてみましょう。
1. 1要素認証:YubiKey のみ(ユーザからの明示的入力を用いない)
2. 2要素認証:ユーザパスワード + YubiKey
3. その他:ユーザID と上記の組み合わせ
ユーザID+YubiKey とか ユーザID+ユーザパスワード+ YubiKey
Challenge-Response を使う場合、どのユーザの秘密鍵を使うべきかが特定できなければ、検証そのものができません。3 の場合は、ユーザID から特定できるため、特に問題なく設計できると思います。1 や 2 の場合、ユーザID そのものが無いため、ユーザを特定する補助な処理が必要になるでしょう。YubiKey を使ったクライアントアプリでの認証の場合、幸いなことに直接 YubiKey のユニークなシリアル番号を取ることが可能であるため、事前にシステムに対して、必要なセット情報(ユーザID, YubiKey シリアル番号, 秘密鍵)を登録しておき、シリアル番号からユーザや秘密鍵を特定する方法が取れます。これはクライアント上で YubiKey を使う場合においては、無難な方法の一つと言えるでしょう。
1要素認証は利用者にとって楽ではありますが、YubiKey が盗まれた場合に何の障害も無くログインできるようになるため、そういったデメリットを考慮した上で採用すべきでしょう。クライアントアプリの場合、インストールされた端末上で動かすという物理的な障壁があるため、利用環境次第ではデメリットがそれほど無い場合もあります。
ただし、少しでも不安があるならば2要素認証が手堅い方法なのではないでしょうか?
更に実際の運用を考えた場合、YubiKey の紛失や故障時の考慮も必須となるでしょう。該当する YubiKey 経由でのログインを停止した上で、速やかに代替のログイン手段を提供する必要があります。
特に業務システムにおいては、業務を遂行できない状況が物理的損失ですから、この時間は限りなく抑えられるようにすべきです。代替のログイン手段としては、YubiKey を使わずシステムにログインできる経路を作っておくような『システム側で対処する方法』と、予備の YubiKey を常備する『運用側で対処する方法』が具体的な策として挙げられるでしょう。
この辺りの内容がクリアにできれば、現実的な運用が可能な設計~実装ができるのではないでしょうか?
クライアントベースの既存システムに YubiKey を導入する場合のことを考えてみると、YubiKey関連(ユーザと YubiKey のセット情報)の管理登録機能と、ログイン認証周りの改修が主な内容になるでしょうか?管理側の機能には YubiKey 紛失時の停止機能を入れておくべきです。
システムごとに大きな違いがあるとすれば、一人のユーザに複数の YubiKey を割り当てられるようにするかどうか?などがあるかもしれません。これは設計思想や運用の考え方によって、変わるでしょう。
次回はウェブサイトでの2要素認証を考えてみようと思います。
0 件のコメント:
コメントを投稿