情報処理安全確保支援士 2009年 秋期 午後2 問01

　X社は、従業者数10,000名の大手小売業である。X社は、各事業組織の独立性が高く、それぞれが必要な業務システムを開発し、情報システム部は主に基盤の提供、業務システムの開発ガイドラインの提供及び業務システムの運用管理を行っている。CIOは、ITガバナンスが不十分であると認識しており、効率的なIT運用を図ると同時に、セキュリティ管理の強化や技術標準の確立などを急く必要があると考えている。 　X社は戦略的に経営統合を行い、成長を図ってきた。現在、Y社と1年後の経営統合を目指して交渉を進めている。 　X社の経営トップは、経営統合のためには、統合両社の従業者による情報共有や連携作業を安全にかつ効率よく行う必要があると考えている。そこで、CIOは、情報システム部に対して、IT施策の実施を加速し、Y社との経営統合に間に合わせるよう指示を出した。情報システム部では、プロジェクトチーム（以下、Pチームという）を編成して検討を始め、まず、認証・認可基盤の構築が必要であると判断し、CIOに報告した。CIOの承認を受け、Pチームは認証・認可基盤構築の実施計画を策定する作業に入った。 　 〔X社情報システム群の概要と認証・認可基盤構築の基本方針〕 　X社には、図1に示す大小合わせて100の業務システム（以下、X社情報システム群という）が存在する。多くのシステムは、Web技術に基づいたもの（以下、Web方式という）であるが、基幹業務システムの一部には、Web方式でない独自技術に基づくクライアントサーバ方式（以下、C/S方式という）も存在する。C/S方式の業務システムについては、今年度後半に、Web方式に再構築することを計画している。 　現行の業務システムには、購買システムのように、アプリケーションプログラムに認証機能が組み込まれているもの（以下、アプリ認証方式という）と、研究開発システムのように、アプリケーションプログラムが稼働しているWebサーバの前段にリバースプロキシ型の認証サーバを設置しているもの（以下、プロキシ認証方式という）がある。 　Pチームでは、これまでのX社情報システム群の問題を洗い出し、認証・認可基盤構築についての基本方針を決定するために集中検討会を行うことにした。

　集中検討会では、利用者認証、アクセス権付与管理、利用者認証・認可に用いるディレクトリ（以下、ディレクトリという）の統合、利用者認証・認可に用いる情報（以下、利用者情報という）の維持管理の4点について現状と問題を整理し、改善策の検討を行った後、Y社との経営統合に備え、Y社の従業者によるX社情報システム群の利用について検討を行うことにした。 　 〔利用者認証に関する現状と問題〕 　利用者ID体系については、従業者番号に基づいた利用者IDを使用している業務システムが多いが、従業者の氏名に基づいた利用者IDを使用している業務システムもある。そのため、利用者は、各業務システムに利用者ID、パスワードなどを入力する際に混乱したり、覚えきれなかったりするという問題が起きている。 　 〔アクセス権付与管理に関する現状と問題〕 　X社では、組織変更に伴う役職に対する役割や職掌の変更が頻繁に発生する。例えば、請求書にかかわる業務は、現在は営業部の担当であるが、過去には営業部と独立した、ほかの組織が担当したこともあった。また、組織横断的なプロジェクトチームが組織されて業務を遂行することも多く、従業者が複数の組織に属したり、複数の役割を同時にもったりすることも、しばしば発生している。そのため、1人の従業者による業務システムへのアクセスでも、所属組織や役割によって、使用できる機能を限定することが必要になってきている。 　さらに、以前から、業務システムによっては不必要なアクセス権が利用者に与えられていて、セキュリティ上好ましくないという意見があった。 　 〔ディレクトリの統合に関する現状と問題〕 　現在のX社情報システム群の業務システム名、システム方式、認証方式、ディレクトリの実現方法、登録されている利用者ID数及び利用者情報を表に示す。 　ディレクトリについては、業務システムごとに構築され維持運用されているので、統合化などによって、運用効率及びコストの改善を図るようCIOから指示されている。 　そこで、Pチームでは、標準技術であるLDAP規格に準拠しているディレクトリは統合できるのではないかと考え、調査を行った。しかし、①LDAPを使用する業務システムを調査した結果、いずれもLDAP規格に準拠した製品を使用しているにもかかわらず、ディレクトリを容易に統合できないということが分かった。

〔利用者情報の維持管理に関する現状と問題〕 　次にPチームは、利用者情報である利用者の認証情報（利用者ID、パスワードなど）と認可情報（アクセス権付与などの設定情報）の維持管理について、現状と問題を調査した。 　現状では、利用者認証・認可機能は、業務システムごとに個別に実装されており、利用者情報も、業務システムごとに維持運用されている。 　各業務システムの利用者情報の維持管理は、システムごとに決められたシステム管理者によって行われている。業務システムを新たに利用開始する従業者は、その業務システムの管理者に対して、利用者情報の登録申請を行っている。 　利用者情報の業務システムへの登録及び削除は、小規模な業務システムでは、システム管理者が管理台帳に基づいて手作業で行っているが、購買システムなどの基幹業務システムでは、個別に開発した利用者管理機能で行っている。利用者IDの新規作成やアクセス権の追加が必要になった場合には速やかに処理が行われるものの、②利用者IDやアクセス権の一部が不要になった場合に、その削除処理が忘れられることがしばしばある。 　 　以上のとおり、検討項目4点について現状と問題を整理した。これらの問題を解決するために、Pチームでは、まず、実際のアクセス権付与の状況を具体的に調査することにした。 　 〔主要業務システムにおけるアクセス権付与状況の調査〕 　調査には、システムモデリングの手法を用いることにし、職務の遂行者を抽象的に類型化したアクタ（例えば、営業部員、営業部長）ごとのアクセス権付与状況を洗い出した。具体的には、システム再構築を予定している購買システム及び顧客管理システム、並びに企業活動の中心となる営業管理システムに絞り、アクタごとのアクセス権付与の状況について調査を行った。購買システムは購買部で、顧客管理システム及び営業管理システムは営業部で使用されている。 　Pチームは調査結果を図2のとおり整理した。業務機能は、業務対象と業務操作から成っている。例えば、顧客管理システムでは、顧客情報という業務対象に対して入力更新という業務操作を行う業務機能があり、その業務機能に対するアクセス権が、アクタである営業部員に付与されている。営業管理システムにおいては営業部長に対して、購買システムにおいては購買部長に対して、すべての業務機能に対するアクセス権が付与されている。Pチームでは、営業部長及び購買部長に付与されているアクセス権が本当に必要なのかどうか、確認すべきであると考えた。

　そこで、従業者による業務の実態についてヒアリング調査を行い、ユースケース図を使って図3のとおり整理した。

　図3のユースケースは、業務システムの業務機能と、その業務機能を使用するアクタを示している。図3を職務規程と照らし合わせたところ、問題になる利用実態はなかった。 　次に、この図3を用いて、内部統制上の問題がないか、また、図2に過剰なアクセス権付与がないかを分析した。 　購買業務では、営業部が発行した購買依頼書に対し、購買部員が発注基準に従って、購買同意又は購買不同意の決定を行い、これを購買依頼書同意機能を使って処理する（業務量が多い場合には部長も当業務を行う場合がある）。購買同意の場合には、発注起案書の申請を購買部員又は購買事務員（派遣従業者）が発注起案書処理機能を使って行い、同じ発注起案書処理機能を使って購買部長が承認の処理を行う。③この購買業務には、アクセス権付与の問題はなかったが、内部統制上の問題が見つかった。そこで、購買部で職務規程を見直してもらい、その結果に基づいて、情報システム部で、どのように業務システムで対応すべきか検討することになった。 　営業部の業務には、顧客管理業務と営業管理業務がある。顧客管理業務は、顧客情報を保守する業務である。X社では、顧客ごとに1人又は複数の担当の営業部員が付いている。顧客情報の入力更新及び削除に関する業務は、営業部長は実施せず、個々の顧客を担当する営業部員だけが実施している。この業務には内部統制上の問題もアクセス権付与の問題もなかった。 　営業管理業務については、事前に営業部長の申請によって、部長の代行を務める営業部員にアクセス権が付与され、営業部長が不在の際、業務機能を使用する場合がある。営業部の業務には、内部統制上の重大な問題はなかったが、アクセス権付与に関して問題が見つかった。 　 〔利用者認証に関する問題の解決〕 　Pチームは、今年度後半、すべての業務システムをサインオン（以下、SSOという）を導入することで、X用者認証に関する問題の解決を図ることにした。 　 〔アクセス権付与に関する改善策の検討〕 　Pチームでは、調査を通して、組織変更や職掌変更などに伴うアクセス権付与管理を効率的に行うための仕組みが必要であるという結論に至り、各種アクセス制御の方式を比較検討した。その結果、業務に必要な最小限のアクセス権だけを付与することが実現しやすくなり、組織変更や職掌変更などに伴うアクセス権付与管理を効率的に行えるという理由で、ロールベースのアクセス制御を選ぶことにした。ロールベースのアクセス制御では、アクタに対するアクセス権をロールという単位で付与する。ここでロールとは、組織内における一定の権限や責任を伴う業務上の役割を意味する。 　Pチームでは、一つ以上の業務対象と一つ以上の業務操作との組合せに対するアクセス権をロールとして定義することにした。手始めに、営業管理システムにおける営業部長用のロールについて検討を行った。営業管理システムでは営業部長に一つ以上のロールが定義できると考え、図4に示す定義案を作成し、議論した結果、案4を採用することにした。 　

　ほかの業務システムにおいても、案4と同様の考え方に基づいてロールの定義を行う方針にした。Pチームでは、ロールベースのアクセス制御を実現するために、④人事管理システムへの管理項目の追加と人事管理システムの運用見直しを行うことにした。 　 〔Y社従業者へのアクセス認可方式の検討〕 　次に、Pチームは、Y社の従業者に、X社情報システム群へのアクセスを認可する方式について検討を行った。Y社との経営統合では、顧客情報などを共有することが想定されている。顧客情報などを共有するための要件は二つある。まず第一に、X社情報システム群は、Y社情報システムの利用者認証結果に基づいて、Y社従業者にX社情報システム群へのアクセスを認可する。第二に、同様に、Y社の情報システム群は、X社従業者に、Y社の顧客情報を管理する情報システム群へのアクセスを認可する。このようなことを実現する技術の一つにID連携技術があるという意見が出た。ID連携技術とは、お互いに信頼する組織間で、それぞれが管理する利用者の利用者IDを結び付けることによって、複数の組織間のシステム利用において、利用者認証が一度だけで済むSSOを実現する技術である。 　Pチームは、検討した結果、ID連携技術を採用する方針に決めた。 　　 〔ID連携技術の検討〕 　Pチームの中でID連携技術検討の担当となったE君は、ID連携技術の選定について、セキュリティコンサルタントのF氏に助言を求めた。次はF氏のE君への説明である。 　 　F氏：私は、SAML（Security Assertion Markup Language）2.0という標準技術を使ったID連携のシステム構築の経験があります。SAML2.0では、異なる製品間の相互運用性について、技術標準を策定する団体が主導して試験を行い、検証結果を公表しています。 　E君：相互運用性が高い技術であれば、X社の技術標準として採用しやすいですね。 　F氏：そうですね。仕組みについてご説明します。図5が、SAML2.0を使ってSSOを実現する場合のメッセージフローです。この図にあるSP（サービスプロバイダ）は、認証された利用者に対して業務アプリケーションなどのサービスを提供する側の機能で、IDP（IDプロバイダ）は、利用者認証の結果をSPに提供する機能です。利用者がSP上のWebアプリケーションを利用する場合に、SPが利用者に対してWebアプリケーションのサービスを提供してよいかを判定する必要がありますが、この判定のためにSPはaをブラウザ経由でIDPから受け取ります。

　E君：なるほど、分かりました。 　F氏：Y社にもSAML 2.0のSPを導入したとします。この場合、X社の利用者が、X社情報システム群の認証サーバ、つまり、IDPで一度認証を受ければ、bするまでは、X社とY社のWebアプリケーションは、利用者が個別にサインオンしなくても利用可能となります。 　 　検証済製品にはY社が導入しているものも含まれており、Y社と協議した結果、2社間でのID連携には問題がないことが判明した。そこで、Pチームは、SAML 2.0を採用することに決めた。 　 〔X社情報セキュリティポリシの改訂〕 　Pチームでは、セキュリティ強化及びITによる内部統制の強化を図り、認証・認可基盤との整合性を確保するために、X社の情報セキュリティポリシを改訂すべきであると考えた。図6に改訂した情報セキュリティポリシ（以下、改訂ポリシという）（案）の改訂部分を示す。改訂ポリシ（案）はPチームでの確認と情報システム部内での審査を経た後、経営会議で正式に承認され、2か月後に発効することになった。Pチームは、各業務システムに対して、発効後1年以内に改訂ポリシに準拠するように求めることとした。

　 　 〔認証・認可基盤の全体方式の決定〕 　Pチームでは、認証・認可基盤の全体方式を決定するために議論を重ねた。次は、PチームのリーダであるG主任とメンバのHさんの会話である。 　 　G主任：現行の業務システムの利用者認証方式をSSOに統一し、各業務システムをSPとして構築するためにはどのような変更や作業が必要か説明してくれないか。 　Hさん：アプリ認証方式の場合には、プログラムの構造をかなり変更する必要があるので、移行作業には時間が掛かりそうですが、技術的な問題はなさそうです。プロキシ認証方式の場合には、Webサーバの接続先を、今まで使用していた認証サーバから、SSOサーバに切り替えます。各WebサーバがSSOサーバのインタフェースに対応可能であることは調査済ですので、容易に移行が可能だと思います。いずれの方式でも、SSOを実現するためにはID連携技術に対応したソフトウェアを追加で導入します。 　G主任：Y社との経営統合への対応を含め、利用者認証については、移行についても技術的にめどが立っているようで安心したよ。しかし、利用者情報の維持管理に関しては、どのような方式にするのがよいのかね。 　Hさん：総合的に考えて、図7に示す方式がよいと思います。人事管理システムから提供される利用者に関する情報と図4で検討したロールの定義を認証・認可情報リポジトリで一元管理します。それを利用者管理機能によって、SSOサーバと各業務システムのディレクトリに反映させます。

　

　G主任：そうすると、各業務システムの対応は、どうなるのかね。 　Hさん：SSO対応以外にも個々の業務システムの⑤システム改修と運用見直しが必要です。 　G主任：分かった。検討作業を続けてくれたまえ。 　 　以上のようにして、Pチームによる集中検討会は終了し、認証・認可基盤構築の実施計画が社内に発表され、認証・認可基盤の構築が開始された。