特権IDは、その権限の高さから、厳格に管理するための方法についても、様々な観点から検討する必要があります。特に煩雑な管理では、かえって管理ミスを招く恐れもある他、継続して取り組むには一定の体制が必要となります。

一般的なガイドラインを見ただけではわからない特権ID管理のポイントや、実運用を考慮した上でのベストプラクティスを解説します。

情報セキュリティガイドラインが示す特権ID管理のあり方とその課題

情報セキュリティガイドライン等の基準には、特権IDのリスクコントロールのポイントとしておおむね以下のような指針が示されています。

• 共有IDの原則利用の禁止
• 最小権限の原則
• 承認ベースでの利用
• 利用状況の監視

この考え方に基づき、一般的に実施されがちな管理方法として、以下のような方法が取られています。

1. 作業者にそれぞれに個人アカウントを付与
2. 作業の際に承認ベースで作業に必要な権限を付与
3. 定期的に個人アカウントに付与されている権限を棚卸し、過剰な権限が付与されたままとなっていないかをチェック

確かにAdministrator/rootといったビルトインアカウントを複数の作業者で共有してしまうと、実際に誰が利用したのか判別がつかなくなります。また、これらのアカウントはすべての権利を有する最高権限を有しているため、作業に必要な最小の権限を越えることが可能な権限を保有しています。

したがって、ガイドラインに沿って管理プロセスを検討すると、おのずと前述した①～③の方法になります。

しかし、実運用を考えると、この管理方法が必ずしも最適とは言えない点がいくつかあります。

(1) 管理対象アカウントの絶対数の増加

1点目の問題は、個人アカウントを作業するシステム管理者の数だけ作成することによる、管理対象となるアカウントの絶対数の増加です。システム管理作業を行うための特権IDは、システムによっては各システム単位で作成しなければならない場合があるため、管理対象のシステムが多くなるにつれ、管理すべき個人アカウントの数は増大します。

例えば、100台のサーバーで構成されるシステムを外部委託先含め50名で管理する場合、トータルで5000個のアカウントを管理する必要があります。

管理対象のアカウントの絶対数が多いとその分管理負荷が増大し、管理ミスの発生確率が大きくなってしまいます。

(2) 「最小権限」に関する2つの問題

特権ID管理の考え方でよく言われる最小権限の考え方についても、実運用を考えると2つの問題があります。

1つが技術的な問題です。例えばデータベース内のレコード補正を行うために、あるテーブルの更新権限を付与するとします。本来更新すべき特定のレコードに対してのみ更新できるように権限を最小化すべきですが、行レベルでの権限付与に対応できるデータベースは、商用の一部のデータベースに限定されます。

最小権限の考え方をどこまで徹底できるかは、システムの対応に依存する点が大きいと言えます。

2つ目の問題は、権限の付与・はく奪といった管理自体の問題です。一般的にアカウントの権限を操作するには、アカウント管理に関する高い権限を用いる必要があります。個人アカウントに対して都度必要な権限を付与し、不要になったら権限をはく奪する管理プロセス自体が、特権IDの使用頻度を増大させているのです。

特権ID管理のベストプラクティス

弊社エンカレッジ・テクノロジが勧める特権アカウントのベストプラクティスは、実運用を考慮した、以下のような考え方に基づく管理です。

(1) 共有型特権アカウントの利用

情報セキュリティに関する様々なガイドラインによると、個人が特定できない共有IDの利用は極力避けるよう示されています。しかし、これが煩雑な管理が必要となってしまう最大の要因です。前述の通り、個人IDに特権を付与する運用は、管理すべきアカウント数が非常に多くなってしまうからです。

図：個人IDに権限を付与する方法の課題

この課題の解決方法として、個人IDではなく共有IDの利用を提唱します。共有IDにはあらかじめ業務や作業別に必要な権限を付与しておきます。この共有IDを利用するユーザーに貸し出す形で利用します。

この方法により、管理すべき対象のアカウント数を大幅に減らせますので、管理負担と管理ミスを減らすことできます。

図：共有IDを利用する考え方

(2) 承認ベースでの共有アカウント貸出の実施

共有IDを利用する上の課題は、利用者が特定できないことです。そこで必要なのが、共有IDを貸し出すための申請承認ルールと貸出履歴の管理です。定められた承認ルートにより特定のユーザーに対して特定の期間だけ、共有IDの利用を許可します。必ずその履歴は改ざんされることなく保存されていること、そして貸し出された共有IDは、承認されたユーザーだけが利用でき、貸出期間の終了、返却後にパスワードを変更/無効化して、貸出期間後に利用されないようにすることで、共有IDであっても利用者の特定を担保できます。

表：作業申請と貸出履歴管理の例

申請者	山田 太郎
作業者	作業 一郎
私用ID	BackUpAdmin
対象サーバー	会計サーバー
使用開始日時	2011/2/1 14:00~15:00
作業内容	バックアップコマンドの実行

(3) 脱 最小権限の原則

ガイドラインで示される特権IDの「最小権限の原則」は、技術的側面と実際の運用の側面からあまり有効な方法とは言えません。例えば、データベース内のデータ補正を行う作業には、更新権限を有するアカウントが必要です。補正すべきレコードだけを更新できるようにしなければ、他のレコードについても更新されてしまうリスクが生じます。

一部のオープンソース系のデータベースでは、特定の行だけをアクセス可能とする行レベルのアクセス権限の設定を行うことができません。つまり、最小権限の原則を守るために利用できるテクノロジーの選択肢が狭められてしまう可能性があります。UNIXシステムのrootアカウントの権限を制限することはできませんが、一部のサードパーティのアクセスコントロール製品を利用すると、rootアカウントであってもコマンドを制限したりすることができます。
しかし、これらのアクセス制御を実現するためにはオペレーションシステムのコアに近い部分でコマンドをインターセプトするためのプログラム制御が必要です。重要なシステムを稼働させているサーバーに対して、アクセス制御のための常駐型の専用プログラムを導入することは、別の意味でリスクがあります。

一方、行レベル権限管理機能を持つデータベースを採用し、技術的には可能になったとしても、実際に運用するとなると、補正するレコードだけに権限を付与する作業を、毎回行う負荷・体制を考慮する必要があります。また、権限設定を行うことができる、より高い管理者としての権限を、頻繁に利用しなければならない点もリスクとなるため、権限を付与できる管理者が不正行為をするリスクに対して、新たなリスクコントロールの手段が必要になってしまいます。
つまり最小権限の原則には、「アカウントの権限管理を行う管理者の不正や不備」を担保することができません。

弊社が考える特権ID管理のベストプラクティスでは、最小権限の原則にはこだわらないことがポイントです。前項で示した通り、業務や作業に合わせて事前に適切な権限が設定された共有IDを準備し、大きな業務変更が行われない限り権限を変更せず利用します。これにより、アカウント管理者がアカウントに対する権限設定を行う機会自体を減らすことで、管理負荷を下げるとともに、「アカウントの権限管理を行う管理者の不正や不備」に対しても担保することができます。

(4) 操作ログを用いた作業内容の突合

最小権限の原則の代わりに点検業務の強化を推奨します。データベース補正の作業の際には、補正対象のレコードだけが更新できる権限を付与するのではなく、対象のレコード以外に更新処理をしなかったかどうかを確認すればよいのです。

事前に権限設定を行うには、特権IDの利用が不可欠ですが、点検業務を行う場合には、閲覧すべき操作記録に対する参照権限があればよいため、最小権限の原則のように権限者の管理のジレンマが発生しません。

ただしこの方法は、事後的に行為を発見するものであるため、不正行為を完全に防止することはできません。しかしレビュー範囲を作業単位とすることで、レビュアによる発見を容易かつ迅速に行え、早期の対応をとることで十分なリスク低減効果があります。