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

　 　A社は、従業員数700名の業務用ソフトウェアパッケージの開発販売会社である。都心に本社を構えるA社は、営業部、人事部、経理部、総務部、情報システム部、製品サポート部、製品開発部及び研究部から構成されている。 　A社は、長らくソフトウェアパッケージの販売を事業の中心としてきたが、最近刷新された経営陣の決定によって、SaaS（Software as a Service）型のインターネットサービスの提供及び関連SI事業（以下、SaaS型サービス事業という）を立ち上げる計画を開始した。 　 〔A社の情報システム〕 　A社における社内向けの情報システムは、表に示すように分類される。このうち、社内の情報技術基盤となる情報システム群（以下、インフラ系という）及び基幹業務に関する情報システム群（以下、基幹業務系という）は、情報システム部の所管である。インフラ系には、Webアプリケーション（以下、Webアプリという）向けにA社が独自に開発したシングルサインオン（以下、A-SSOという）システムが含まれている。他方、製品サポート部、製品開発部及び研究部が、部署ごとに導入して運用管理をしている情報システム群（以下、部署運用系という）があり、それらの一部は、認証にA-SSOシステムを採用しているWebアプリ（以下、A-Webアプリという）である。

〔認証統合プロジェクトの発足〕 　A社では、社内にA-SSOシステムを含む複数の認証システムが混在しており、システム監査において、図1に示す課題が指摘されていた。ここで、認証システムとは、アカウント情報の管理、利用者の認証及びアクセス許可を行うシステムのことをいう。

　そこで、認証システムを統合することになり、情報システム部を中心とした社内プロジェクトチーム（以下、Sチームという）が発足した。また、経営陣から、当該プロジェクトは、SaaS型サービス事業に活用できる成果を出すようにという指示があった。この指示を考慮し、プロジェクトの開始に先立ち、認証システムの統合の基本方針を図2にまとめた。 　

〔認証システムの洗い出し〕 　Sチームは、A社で利用している認証システムについて精査する必要があると判断し、まず、他社製の認証システムに関して、仕様を詳しく調査することにした。 　A社は、PC端末、ファイルサーバ及び一部のWebアプリにおける認証の仕組み、並びにディレクトリとして、C社製ディレクトリシステム（以下、C-DIRという）を、導入している。C-DIRでは、利用者、PC端末、プリンタ及びサーバから構成されるドメインという管理単位を定め、ドメインコントローラ（以下、DC という）によって管理する。また、DC では、C-DIR のディレクトリに保持されるアカウント情報を用いて認証を行う。認証には、C社独自仕様のチャレンジレスポンス認証（以下、C-CR 認証という）、又は Kerberos認証を利用することが可能である。 　C-CR 認証では、図3に示すプロトコルの(b)-1～(b)-4 において、①DC が生成した疑似乱数をチャレンジとし、それを受信したクライアントで、利用者ID、パスワード及びチャレンジの連結をハッシュ化したレスポンスを DC に返信し、アクセス許可を受ける。

　他方、Kerberos認証では、図4に示すように、クライアントが、DC における認証後、有効期限付のチケットが発行され、それをサーバに提示し、アクセス許可を受ける。

　C-CR認証の場合、クライアントはサーバへの接続のたびにDCにおいて認証を行う必要があるが、Kerberos認証の場合、有効期限内であればチケットをサーバに提示するだけでサービスを受けられる。A社では、トラフィックが少なくなるなどのメリットが多いKerberos認証だけを利用している。また、Kerberos認証において、②有効期限切れのチケットが悪用されないように、DCとサーバをaさせて運用している。 　研究サーバ用及び電子メール用のサーバマシンでは、UNIX OSが稼働しており、利用者認証のために、NIS（Network Information Service）が導入されている。ここで、NISとは、NISドメインと呼ばれる管理単位において、UNIX OSが稼働するマシン間で、利用者のアカウント情報を共有するための仕組みである。 　社外から社内LANへのアクセスのためのSSL-VPNでの認証、及び社内の無線LANでの認証には、RADIUSが使用されている。ここで、RADIUSとは、サーバにおいて、利用者の認証及びアカウンティングを実現するための仕組みである。 　以上の認証システム以外に、LDAPを用いて、パスワード認証を行う情報システムがある。 　 〔A-SSOシステムの仕様の確認〕 　Sチームは、次に、A社が独自に開発したA-SSOシステムの仕様を確認した。 　A-SSOシステムは、A-SSOサーバ及びA-SSO用のディレクトリで構成される。 　A-SSOサーバは、A-Webアプリの利用者を認証するために、A-SSO用のディレクトリに保持されるアカウント情報を用いる。認証には、図5に示すプロトコルを利用する。

　次は、A-SSOシステムのプロトコルの動作概要である。 　(a) 利用者のブラウザは、A-Web アプリにサービスを要求する際、A-SSO用のクッキーがあれば、それを A-Web アプリに提示する。その場合には(f)に進む。 　(b) A-Web アプリは、サービス要求を A-SSOサーバにリダイレクトする。 　(c) 利用者は、利用者IDとパスワードを入力し、認証を受ける。 　(d) A-SSOサーバは、認証が成功すれば A-SSO用のクッキーを発行する。 　(e) ブラウザは、クッキーを A-Web アプリに提示し、サービスを要求する。 　(f) A-Web アプリは、クッキーを検証し、有効ならば、サービスを提供する。ここで、A-SSO用のクッキーには、セッションIDやクッキーの発行日時などが設定されており、トリプル DES を用いて暗号化されている。また、すべての A-Web アプリには、クッキーを復号するために暗号化鍵を配布している。ブラウザは、一度、クッキーの発行を受けると、有効期間内であれば、(b)～(e)の手続なしに、すべての A-Web アプリにアクセスできる。 　 〔A社のアカウント情報の反映のフロー〕 　A社で利用している認証システムの仕様の確認後、S チームは、アカウント情報の反映のフローを確認した。 　図6は、認証システム間で、アカウント情報をどのように反映しているかのフローを示している。まず、人事マスタデータベース（以下、人事マスタという）から CSV 形式のファイル（以下、人事マスタファイルという）を手動で、適時、出力しておく。アカウント作成の際、人事マスタファイルを基に、利用者ID、パスワードなどのアカウント情報を、アカウント情報を管理する LDAP サーバのデータベース（以下、LDAP マスタという）に追加する。併せて、C-DIR のディレクトリにも追加する。さらに、LDAP マスタから、LDAP1 には即時に、LDAP2 には日次で、データ転送される。ここで、LDAP1 は A-SSOサーバから参照され、LDAP2 はそれ以外の LDAP を利用する認証システムから参照される。NIS と RADIUS のアカウント情報については、利用者からの申請後、手入力で NIS に追加する。その後、RADIUS に、即時、データ転送される。

　A社では、アカウント情報に関して、C-DIR用、LDAP用及びNIS用の3種類のデータ形式を用いている。LDAPのアカウント情報では、inetOrgPersonといったオブジェクトクラスによって組織の利用者の情報を管理する標準的なbを用いている。例えば、製品開発部のスズキタロウ氏が社内で利用するLDAP用のアカウント情報をcによってテキスト形式で示すと、図7となる。 　

〔統合認証システムの基本設計〕 　社内の認証システムの仕様を洗い出した後、Sチームでは、図8に示すとおり、新たに導入する認証システム（以下、統合認証システムという）の基本設計を行った。 　アカウント情報は、エントリの属性を定義するbを拡張して、A社で必要とする利用者ID、パスワード、所属、電話番号などの属性を管理できるようにした。また、統合認証システムではアカウント情報を一元的に管理することとした。 　アカウント情報のシステム間の反映に関しては、人事マスタからID管理サーバ（以下、IDMという）にアカウント情報を日次で反映し、IDMのディレクトリ（以下、IDM マスタという）で保持し、変換後、IDM から C-DIR のディレクトリ及び LDAP にアカウント情報を即時反映する方式を採用した。LDAP は、シングルサインオンシステム及び RADIUS での認証に利用される。NIS は DC と連携することができる。 　利用者がパスワードを変更したい場合は、IDM の Web インタフェースを通して、利用者が自ら変更することが可能で、C-DIR 又は LDAP サーバなどに、即時反映される仕組みとした。 　A-SSOシステムには、図1の（5）の指摘があることに加え、③A-SSO用のクッキーの利用が原因となり、A-SSOサーバと A-Web アプリが同じインターネットドメイン上にないとシングルサインオンを実現できないという技術的課題があった。社内ドメインだけでの運用では問題はないが、SaaS 型サービス事業を展開する上で、事業形態の制約となるので、製品開発部と研究部との検討の結果、統合認証システムでは、SAML（Security Assertion Markup Language）に準拠したシングルサインオン（以下、SAML 型SSOという）システムを採用することにした。

　SAMLとは、記述言語としてdを用いて、認証及びeに関する情報を交換するための標準規格である。今回、A社で採用したSAML型SSOシステムにおける認証及びeを実現するプロトコルは、図9のとおりである。Webアプリ上には、SP（サービスプロバイダ）と呼ばれるモジュールが稼働しており、IdP（Idプロバイダ）と呼ばれるWebアプリと連携して、利用者認証を行う。IdPにおいては、様々な認証方式を採用できるが、A社では、入力フォームを活用した、利用者IDとパスワードを用いる方式を採用し、図8の統合認証システムにおけるLDAPサーバと連携させることにした。

　次は、A社で採用したSAML型SSOシステムのプロトコルの動作概要である。ここで、各主体は、ほかの主体の公開鍵証明書を保持しているとする。 　(a) 利用者のブラウザは、Webアプリにサービスを要求する際、SP用のクッキーがあれば、それを提示する。提示したクッキーが有効であることが検証された場合は(f)に進む。 　(b) SPは、SAMLRequestメッセージをエンコーディングした上でURIに含め、サービス要求をIdPにリダイレクトする。 　(c) 利用者は、利用者IDとパスワードを入力し、認証を受ける。 　(d) IdPは、利用者IDなどの属性を暗号化及びディジタル署名したSAMLResponseメッセージを発行し、ブラウザ上のJavaScriptを用いて、それをSPに転送する。 　(e) SPは、SAMLResponseメッセージのディジタル署名などを検証し、有効であれば、SP用のクッキーを発行する。 　(f) SPが稼働するWebアプリは、該当するサービスを提供する。 　 　Sチームは、SaaS型サービス事業への展開を視野に入れ、SAML型SSOを複数のIdPでも適用できるように設計した。SAML型SSOシステムの導入によってA-SSOシステムの課題に対処できるので、SAML非対応の既存のWebアプリを、情報システムのリプレース時に、SAMLに対応するように改修を行うことにした。将来的には、全社でSAML型SSOシステムを採用することにし、統合認証システムの導入後、適切なタイミングでA-SSOシステムを廃止することを決定した。 　SaaS型サービス事業への展開としては、A社のソフトウェアパッケージをSPと連携するように改修し、WebアプリとしてA社のデータセンタに配備し、サービスを提供する予定である。このサービスを導入する企業は、自社のイントラネットにIdPを用意すれば、導入する企業のイントラネットにあるPC端末からインターネット経由で、A社のデータセンタに配備されたSaaS型サービス事業のWebアプリを利用することが可能となる。導入する企業は、Webアプリの運用をA社に委託できるので、自社内での運用に比べてコストの削減が期待できる一方で、④A社にとっても、IdPを顧客のイントラネットに構築することは運用管理上のメリットがある。 　 〔移行計画の策定と実施〕 　基本設計に続き、Sチームは、図10のとおり、情報システムのリプレース及び認証システムの統合化計画案を策定した。

　A社は、情報システムをリース契約で導入しており、4年ごとにリプレースを実施している。2012年にはインフラ系のリプレースが予定されており、2013年には基幹業務系のリプレースが予定されている。いずれの作業も、情報システム部が行う。他方、部署運用系のリプレース作業については、所管部門がそれぞれ行うことになっており、現在、製品サポート部及び製品開発部所管の情報システムのリプレース作業を行っている。また、2012年に、研究部所管の情報システムのリプレースを実施する予定である。 　なお、A社では、ハードウェアの故障などのトラブルの発生が増えるのを避けるため、リース契約の延長は行わない。 　図10の計画案の策定では、このような前提の下、認証システムの統合のスケジュールを検討し、次の3点を決定した。 　・Saas型サービス事業は最優先であり、さらに、引き続きソフトウェアパッケージの開発及びサポート業務もあるので、製品サポート部、製品開発部及び研究部所管の情報システムのリプレースの時期は変更しない。 　・統合認証システムの構築作業を2011年に実施する。 　・A-SSOシステムのリプレースは、インフラ系のほかの情報システム群のリプレースとともに予定どおり行う。A-SSOシステムの廃止が可能になるのは、早くても、f年の末である。それまでは、継続利用しようと考えたが、gという理由から、次回のインフラ系のリプレース時に、A-SSOシステムも、ほかのインフラ系の情報システム群と併せてリプレースしておく必要があると判断した。 　 　Sチームが結論とした統合認証システムの基本設計と統合化計画案は、アカウント情報の一元化に伴う管理工数の削減やサーバマシン数の削減によって、運用コストの削減も見込めると期待され、認証システムの統合が正式にスタートした。