近年のITインフラの発展により、ノートPCが1台あれば会社の席にいなくてもどこからでも会社のネットワークに接続して仕事ができる環境が整いつつあります。
そして、ITを取り巻く環境が便利になったと同時に不正アクセスに対するセキュリティ対策への関心も高くなりました。 |
 |
 |
例えば、街角の喫茶店から会社のネットワークに繋ぐ時、セキュリティのためにユーザ認証が実施され、その後社内ネットワークに繋がります。会社の各サービスを利用する際にも再度、ユーザ認証を伴うのが一般的です。
ユーザを認証する際に、その人が確かに本人だと確認することは重要です。その為には高度な認証が望ましいですが、実際にはコストの問題等でユーザ名とパスワードの組み合わせでその人だと認証することが多くなっています。この時に用いるユーザ名とパスワードの組み合わせは、サービス毎にばらばらでしたが、ユーザにとって不便であるが故に次第に統合されるようになり、1つの組み合わせで済むようになってきました。
また、1度どこかのサービスを利用する際には、認証されれば他のサービスへのアクセスは自動認証される仕組みも導入されつつあります。このような仕組みを作り上げる上で、ユーザのアカウントはディレクトリーサーバなどで一元管理されるようになり、ユーザから見れば1つのユーザIDと1つのパスワードを覚えればよいとう利便性が提供されるようになりました。
しかし、そのパスワードが不正ユーザに知られれば全てのサービスにアクセスできてしまうという危険性もあります。そのため、セキュリティ・レベルを維持するために、パスワードに複雑なポリシーを課す流れが出てきました。例えば、英数字以外にも記号を含ませないと駄目、辞書にある単語は使っては駄目といったものです。その結果、ユーザにとってパスワードは1つ覚えればよいのですが、そのパスワードは類推されにくい複雑なもので、そして月に一度は変更しなければならない、といった厳しさが求められるようになりました。
ただ、パスワードが難しくなっても悪意ある不正ユーザにパスワードを盗まれる可能性はあります。そのために怪しいユーザはサービス側で遮断する機能、例えばアカウントロック機能が求められるようになりました。アカウントロック機能は例えば、パスワードの入力を何回か間違えた場合はそのユーザは不正ユーザとみなし、一定期間(例えば一日など)はそのアカウントを使えなくする、というものです。
パスワードの設定に複雑さが求めつつ、間違えるとアカウントをロックするという仕組みはセキユリティを高めると同時に、うっかりパスワードを間違えてしまった正規ユーザも不便を被ることになります。アカウント管理を一元管理している場合には全てのサービスが使えなくなるという困った状況にもなります。そんな正規ユーザを救済するために、ヘルプデスクに電話するとアカウントロックを解除するというプロセス上の仕組みなどが導入されました。
アメリカの調査会社 Meta Group によると、ヘルプデスク業務でのパスワードリセットの占める割合は45%にも及んでいるという話があります。次に示す図は、弊社製品であるHP OpenView Service Desk を使っている実際のお客様の例ですが、パスワードリセットに関するコールが多いのがわかります。(図1参照)
ここで問題になってくるのがパスワードリセット依頼に対し、ヘルプデスクのオペレータが手動でロックされたアカウントを解除している場合です。ヘルプデスクの貴重なリソースがロックされたアカウントの解除作業に追われるのではなく、もっと他の作業に割り当ることができれば仕事の効率が向上することは言うまでもありません。
前置きが長くなりましたが、今回ご紹介するのは、ヘルプデスク業務を逼迫しているパスワードリセット作業工数をいかに少なくするかといった話です。

図1
≫拡大画像(新規Window)
|