システム権限委譲の考え方

システムの権限配分について、管理者と一般ユーザ間の線引き、つまり一般ユーザにどこまでの権限を与えるかしばしば議論の的となります。代表的な例は、メーリングリストやユーザーグループのメンバ管理です。

なお、この議論では、権限移譲だけでなく自動化や外注も検討されうると思いますが、そちらは別記事で議論しているため、この記事では管理者が行うか、一般ユーザに権限移譲を行うか、という2択を検討する際に絞ります。

システム権限移譲の判断軸

権限移譲は、権限制御の難易度と運用負荷の2軸で考えるのが良いと考えます。

権限制御の難易度

一つ目の軸は、そのシステムにおける権限制御の難易度です。

システムによってどこまで細かく権限を制御できるかが異なります。例えば、グループのメンバ変更は一般ユーザにも許可してよいかもしれないが、グループの乱立を防ぐために、グループの新規作成は管理者のみとしたくても、システムによってはグループの作成・削除・メンバの追加・削除が1つの権限になっている場合もあります。

また、仮に権限制御が可能であっても、それがマウスポチポチの簡単な設定でできるのか、何かしらの改修・アドオンが必要なのか、という論点もあります。

運用負荷

二つ目の軸は、権限移譲を行う業務の運用負荷です。

まず考えるべきなのが、権限移譲を行うことで削減できる工数です。こちらはシンプルに頻度×1回あたりの工数で計算すればよいでしょう。

次に考えるのが、権限移譲を行った場合に追加になる工数です。次のような工数が考えられます。

• ユーザ向けマニュアル作成・保守工数　…　一般ユーザが操作を行うためのマニュアルを作成したり、それを保守する工数

• サポート工数　…　マニュアルに関する質問や、一般ユーザが誤った操作を行った場合にリカバリを行うサポート工数です。

• 権限制御・棚卸工数　…　一般ユーザの中でも権限移譲の範囲を絞る場合、どのように権限付与の依頼を受け付けるか、権限の追加は誰がやるか、などを検討する必要があります。また、ISMSのスコープになっているような場合は定期的なシステムIDの棚卸が求められますが、一般ユーザに権限を委譲する場合はこの負荷が高まります

権限移譲の考え方

①制御が容易で、運用負荷が高い場合

この場合は特に議論なく移譲でよいでしょう。

②制御が難しく、運用負荷が低い場合

この場合も特に議論なく移譲する必要はないでしょう。ただし、将来的に運用負荷が高まり④になった場合には再度検討を行うべきです。また、SaaSやパッケージであれば、機能拡張によって③になる可能性もあることは意識しておくべきです。

③制御が容易で、運用負荷が低い場合

この場合は、将来的に運用負荷が高まり④になることが読めている場合、この段階で委譲してしまうのも一つだと思いますが、優先度の兼ね合いで様子見になることがほとんどでしょう。

④制御が難しく、運用負荷が高い場合

最も難しいのがこの場合で、運用負荷が高いのでできれば権限を移譲したいが、システム的に細かい制御が難しいのでやむを得ず管理者が行っているという業務が該当します。

例えば、グループのメンバの変更権限を移譲すると、ユーザ・グループ管理権限を渡す必要があり、全てのユーザを削除することも可能になってしまうような場合です。

私は、次のような要素を踏まえて、可能な限り移譲する方向で検討すべきだと考えます。

• 有事の際の業務影響　…　権限を移譲したユーザが「やらかした」ときの最悪の業務影響は何か

• リカバリ難易度　…　最悪の業務影響が発生した場合、リカバリの難易度はどの程度か

• 誤操作の起こりやすさ　…　システムのUIなどによって「やらかす」誤操作をしやすいのか、そうでない設計になっているかも考慮点です。例えば削除ボタンが送信ボタンの隣にあって誤って押してしまいそうなUIと、削除ボタンは一番押しづらいところにあり、かつ押されたときにはときにはポップアップが出て注意喚起をしてくれるUIでは後者のほうが権限移譲をしやすいです。

• ログ追跡性　…　ユーザが「やらかした」ときに誰がいつやったかをたどってリカバリや再発防止に役立てられるか

もちろん、リスクを考えると管理者が行ったほうが安全ではありますが、非ITの従業員のITリテラシーやその成長性を軽んじて過保護になると、非ITの従業員のITリテラシーが育たず、組織の拡大に伴いIT部門がどんどん苦しくなります。リカバリができるくらいのミスならむしろミスして学んでいただくほうが、長い目で見たときには組織にとってプラスに働くこともあると思います。

以上です。