各利用者に対して個別に、適切なサービスを提供する必要のあるシステムでは、アカウントの発行を行うのが一般的です。 しかし、このアカウントを「正しく」運用していない (できていない) ために、管理上の問題やセキュリティ・プライバシィ上の脆弱性が発生しているケースが少なくありません。

特に多く見られるのが、複数の人間が同一のアカウントを「共有」している状態です。 例えば、「営業」関連のデータにアクセスするときはユーザ "sales" で、「人事」関連のデータにアクセスする場合はユーザ "personnel" でログインする、といった運用がこれに該当するでしょう。 販売部に所属している人は、ユーザ "sales" のパスワードを知らされており、人事部に所属している人は、ユーザ "personnel" のパスワードを知らされているという運用。 そして、社長はすべてのユーザのパスワードを知っているというような具合です。 (下図参照)

さすがに部署のデータをこの例のように杜撰に管理している会社は少ないだろうと思いますが、例えば、ウェブコンテンツなどのファイルをセクションごとにこのように分けているところは結構あるんじゃないかと。 このようなアカウント運用は、大きく分けて三つのデメリットを抱えています。 では、それらについて、詳しく考察していきましょう。

先の図では、「利用者」と「アカウント」の間に破線が引かれていますが、これはシステムが「認識」できる領域の境界を表現したものです。 コンピュータ・システムは、現在の作業が「どのアカウント」によって行われているのかは識別できても、それが「どの利用者」であるかは知りえません。

従って、ある「営業」のデータに記録されているある受注レコードが西根, 二階堂, あるいは漆原社長のいずれによって登録 (または変更) されたものであるかを区別することはできないわけです。 このような場合、受注レコードには「担当者」などのフィールドがあったりしますが、こうしたアカウント運用においては、あくまでもユーザの自己申告に基づくものなので、いくらでも偽装ができてしまう、ということに注意してください。 また仮に、全員が正直者で嘘をついたりしない、という前提をおいたとしても、登録のたびに毎回「担当者」フィールドに自分の名前を入力するのは結構な手間だったり。

これがもし、一人に一つのアカウントを割り当てる方法であれば、例えば、営業マン (西根と二階堂) は自分が担当する受注レコードのみ編集できる、といった制限を設けることもできますし、レコードの担当者はシステムによって自動的に記録されるので、これを手動で選択する必要はなくなります。 また、必要に応じて、「誰が」、いつ、どのような操作をしたのかの操作履歴を取ることも可能になるでしょう。

ネットワークシステムでは、ログインのセッションをアカウントごとに一つに制限しているものも珍しくありません。 そのようなシステムでは、端末Aからユーザ hoge でログインした後、ログアウトせずに別の端末Bからさらにユーザ hoge でログインした場合、端末Aとの間のセッションが切断され、端末Bからのみサービスを受けることができるようになる、といった設計になっています。

このような状況では、アカウントを共有しているユーザは同時に作業を行うことができなくなってしまいます。 図の例でいうと、西根が自席のPCで営業データの入力・編集作業を行っている間は、二階堂の席のPCでは営業データにアクセス (閲覧も含めて) することができません。 それどころか、もし二階堂のPCからログイン操作を行ってしまうと、西根のPCに割り当てられたセッションがいきなり切断されてしまい、作業中のデータがすべて失われてしまうハメになります。 こんな状況では、二人が取っ組み合いの喧嘩を始めるのも時間の問題でしょう。

この問題には色々な派生形があります。 例えば、ウェブブラウザの cookie を使ったセッション管理をしている場合などは、さらに不便なものに。 この場合、クライアント側で複数のアカウントのログイン状態を保持することができないので、漆原社長は営業関連データと人事関連データを相互に参照する場合、ログインとログアウトを繰り返す必要が出てきます。 営業成績をもとに昇給幅を決定する、といった作業は、考えただけでもストレスフル & トラブルサムであることこの上ありません。

ある日、二階堂に別部署への移動辞令が出されました。 そんなわけで彼は営業部を後にしたわけですが、異動後も彼が営業データにアクセスできるようでは困ります。 そこで、アカウント sales のパスワードは変更され、西根と漆原社長にのみ伝えられました。 さて、二階堂の異動に伴って、二人が新しくパスワードを覚え直さなければならなくなったわけですが、これは何かおかしくないでしょうか。

その翌月、今度は菱沼が退職することになりました。 このシステムは、社外からも閲覧可能な仕様になっていたため、アカウント personnel のパスワードも変更しなければなりません。 漆原社長はあまりにパスワードの変更が頻繁なので、これを付箋に書き留めて、モニタの枠の部分に貼り付けるようになってしまいました。 これではセキュリティもへったくれもあったものではないですね。

これらのエピソードから分かる通り、この運用では、一人の利用者が情報へのアクセス権限を失うたびに、パスワードを変更し、これを該当するすべての利用者に周知する必要があります。 営業部に西根と二階堂以外にも多くの営業マンがいる場合には、管理のための手間はさらに大きくなるでしょう。 それを毎回暗記するのだって大変ですから、漆原社長の付箋利用を責めるのも気の毒というもの。

これも、一人に一つのアカウントを割り当てる方法を採っていれば防げた事態です。 異動・退職者が出たら、その利用者に割り当てられたアカウントの権限を変更するなり、アカウントを停止すればよいのですから。

こうした厄介な問題があるにも関わらず、なぜこのようなアカウントを共有する運用がなされてしまうのでしょうか。 もちろん、システムそのものが複数アカウントに対応していないとか、あるいはアカウント数によって課金されるため節約のために、という事情によるケースも少なからずあるかもしれません。 (個人的には、そんなタコなシステムとはさっさと手を切るのが懸命な措置だと思いますが。) けれども多くの場合、それはアナログな鍵のイメージを、半ば無意識のうちに取り入れてしまっているのからではないか、と推測しています。

しかしながら、現在ではその「鍵」でさえも、IDカードや生体認証などの技術によって「個人化」されつつあります。 まして、コンピュータシステムにおいては、アカウントを分けることについての障害などは何もないわけですから、その利点を活かす運用が「常識」として定着することを願ってやみません。 利用者認証の方式については、他に考えるべきこと・議論すべきことがいくらでもあるので、こうした基本的な認識についてはさっさと統一しておきたいところですね。