利用者認証=本人認証+権限認証

ネット・サービスでは、それが正当な利用者によって操作されていることを確認すること、いわゆる利用者認証が必要である。
利用者認証は、本人認証(確認)権限(正当性)認証という、2つの異なる機能に区分できる。すなわち
本人認証:端末を操作している人がシステム利用者として登録されているその本人であることを確認すること
権限認証:操作者がその人であることを前提に、その人に操作権限があるかどうかを確認すること

identify.png本人認証では、本人しか持たない情報を予め登録し、サービス利用時にそれを照合する。
本人しか持たない情報とは、本人の身体的特徴(指紋、網膜、静脈、顔、声紋など、いわゆるバイオ認証)、本人しか所持しないもの(操作用のカード、スマートフォン、電子証明書など)、本人しか知り得ない情報(パスワード)などのこと。このようにさまざまな手法があり、セキュリティ商品としてパッケージされているものも多い。

権限認証は、利用者の諸属性を登録しておき、その人にどういう権限で、どういうサービス利用を認めるかをチェックするものであり、セキュリティ技術ではなく、アプリケーションの仕様上の問題である。

多くのBtoCサービスは、家庭に特別な本人認証デバイス等を前提することができないため、普通はID/パスワード認証が使われる。通常これは利用者登録と表現され、IDの発行、パスワードの指定とともに、取引上必要な属性情報(決済方法、住所、メールアドレスなど)を登録する。IDとパスワードが本人認証にあたり、その他の情報はサービスを提供する場合の属性情報(決済方法によって手数料が違うとか、住所によって送料が違うなどという使い方もなされる)であり権限認証に利用される。

組織内システム(組織内ネットワーク接続、メール、勤態管理、出張届、その他組織内手続)では、利用者はその組織の構成員で、通常、所属部署や職階という属性によって利用できるサービスが異なる。このそれぞれのサービスが独立し、それぞれが認証システムを持っていては、利用者に煩雑なので、シングル・サインオンが望ましいとされる。

ところが、シングル・サインオンを標榜した統合システムはあまりうまくいっていない、という話を聞いたことがある。その原因の一つは、本人認証と権限認証を区別せずに考えたことにあるのではないだろうか。
システムを設計する人々の間でも、意外にこの区別が自覚されていないように思う。

この2つを分けずに考えると、認証用の情報には対象サービスすべてに使えるだけの個人属性データベースを用意することになるが、この組み合わせは新しいサービスができるたびに見直しが必要になるかもしれない。また、実装上は、ネットワークへのログオンを基本に考えることになるが、そのためのディレクトリは利用しているOSに依存するから、他の業務で使えるようにするには無理が生じるだろう。一方、業務アプリケーションはパッケージで提供される例が多く、その場合、パッケージが持つ利用者認証システムを使うのが自然で、これに多くの機能を付加することは現実的でない。

そもそもシングル・サインオンのねらいは、サービスを切り替える毎にID/パスワードを入れ直さなくて良いということでしかない。そのために認証システムを統合する必要などはない。Chromeなどのブラウザがやっているように、各サイト用のID/パスワードを記憶しているだけで十分である(一般家庭でもこれによりシングル・サインオンが実現されている)。
そこまで手を抜かなくても良いが、要は本人認証を各サービスの本人認証へリンクさせることができれば事足りる。各業務アプリケーションはそれぞれが想定する利用秩序に応じて、それぞれが権限認証について考えれば良いだろう。

繰り返しになるが、本人認証と権限認証の違いを認識し、自覚的に設計することがシステム屋の責任だと思う。
関連記事
スポンサーサイト

コメントの投稿

非公開コメント

Gallery
検索フォーム

⇒記事一覧

プロフィール

六二郎。六二郎。


定年退職
苦しい家計の足しに再就職
=いつクビになってもええねん
 言うたもん勝ちや!のブログ
リンク
最新記事
最新コメント
最新トラックバック
アーカイブ
カテゴリ
タグ

ITガジェット 書評 マイナンバー Audio/Visual 

リンク
現在の閲覧者数
聞いたもん