【第2回】アイデンティティ管理とアクセス制御の関係、およびID統合管理の難しさ

アクセス権管理に言及した前回に続き、第2回となる今回は、アイデンティティ管理とアクセス制御について考察する。日本版SOX法のIT内部統制実現においては、アイデンティティ管理の統合がその大きく左右するといわれており、その可能性に大きな関心が集まるとともに、ベンダー各社からはID統合管理製品が発表されている。しかし、導入においてはいくつかの高いハードルがあるなど、安易な期待に注意を促す見方もある。今回も前回に引き続き、日本CA　セキュリティマネジメント プリセールス　カスタマーソリューションアーキテクトの中島 浩光氏に話を伺った。

ID管理はアクセス制御の一部

　狭義のアイデンティティ管理とは、“システムを利用しているのは誰か”を把握することである。IDカードやシステムのユーザーIDなどはその具体例であり、すでに多くの企業で採用されている。ただ、そこにはアクセス権の概念はない点に注意しなくてはならない。広義のアイデンティティ管理、つまりはアクセス権を含んだものとなると、そのID情報が誰のもので、それがどのようなリソースに対してアクセス権限を持っているのかを定義する必要が出てくるからだ。しかし、これだけでは、まだリソースに対するアクセスできる権利が与えられたのみとなる。本当のアクセス制御を実現するには、それから一歩進んで各IDのアクセスレベルのコントロールを実施しなくてはならない。この両方がうまく機能するシステムは「アイデンティティ・アンド・アクセスマネジメント」と表現されるように、実は表裏一体でどちらも不可欠なものとなっている。

日本CA株式会社
セキュリティマネジメント
プリセールス カスタマーソリューションアーキテクト
中島 浩光氏

　このように、IT内部統制におけるセキュリティの見地からは、アイデンティティ管理はアクセス制御の前提として考えることができる。日本CA　セキュリティマネジメント プリセールス　カスタマーソリューションアーキテクトの中島浩光氏はアクセス管理の重要性について、「リソースに対するアクセスがあった場合、アクセス制御に必要な要件は4W1H（Who（誰が）、When（いつ）、Where（どこでで）、What （何に対して）、How（どのようなことをしたか））です。特に、この中のWhoが最も重要になります。しかし、金融などの一部の業界を除く多くの企業では、こうしたことが実現できていません」と語っている。そもそも誰がどのシステムにアクセスしたかという情報が不明のままでは、セキュリティ上大きな問題になる。しかも、この4W1Hの情報はSOX法対策には不可欠な監査ログにそのまま保存される。アイデンティティ管理においてはWhoが揺らぐことのないようにし、アクセス制御と連携をとる必要がある。

ID管理を阻害する厄介な例外

　それでは、Whoが揺らぐということはどういうことなのか。基本的にIDはその本人しか特定しないものだが、いくつか厄介な例外がある。それが、退職者のIDと管理者のIDだと中島氏は指摘する。IDとその利用者は1対1が原則だが、退職者のIDの場合は1対0、つまり利用者が不在なのに権利だけが存在するということになる。また、管理者のIDは、複数人でIDを共有しているケースが多く、1対nの構図が出来上がる。そうなると、個人を特定する手段が曖昧になり、Whoへの信頼性が揺らぐ状態になってしまう。「IT内部統制上、これらは必ず押さえなければならないポイントといえるでしょう。特に退職者IDを原因とした情報漏洩も多く、速やかに除外することが大切です」（同氏）

　一方、アクセス制御の基本は、役割ベースのアクセス管理（Role Based Access Control : RBAC）といわれている。これはCOBITフレームワークの中に明確に表現されてはいないが、その概念は分散して内在されている。このRBACを理解するには、業務システム上での役割を考えてみることが必要だ。

　そのため、RBACの業務プロセスで定義された業務フロー図には、「どんな役割の人が」、「どのタイミングで」、「どのシステムの機能を使うか」ということが必ず明記されるようになっている。つまり、「どんな役割の人が」に個人名は出てこないのである。実行者の肩書き（○○部、△△職員など）が役割になり、かつ業務上必要最小限の役割をベースにアクセス制御をかけていくことになる。そうすることによって、この役割を持っている個人の権限が定義されるのだ。そこには、アクセスポリシーやアクセスコントロールリスト（ACL：指定の機能にアクセスする権限を持つユーザーのリスト）が活用されることになる。したがって、個人と役割を紐付ける部分がアイデンティティ管理であり、役割と実際の行動の部分を紐付ける部分がアクセス制御といえる。前回、日本の企業ではアクセス権が業務プロセスと一致していないケースが多いことに言及したが、サーバ管理者は、データベース管理者やユーザーID管理者も兼ね、ともすると一般ユーザーでもあったりする。しかしながら、管理者もシステムの利用者であり、本来それぞれの業務プロセスに従った権限を定義する事が必要であり、その時には権限の分離を意識しなくてはならない。日本はセキュリティよりもユーザビリティを優先させる傾向があり、管理者権限を明確に分離する意識が高くないのは確かなようだ。