テクニカルエンジニア（情報セキュリティ）平成20年度試験問題（午後2問2）

情報セキュリティスペシャリスト試験情報＞テクニカルエンジニア（情報セキュリティ）平成20年度試験メニュー＞問題と解説
　

テクニカルエンジニア（情報セキュリティ）平成20年度試験問題（午後2問2）

　
問2　認証システムの企画・設計に関する次の記述を読んで，設問1～5に答えよ。
　
　L学園は，傘下に情報専門学校，ビジネス専門学校，建築・インテリア専門学校の三つの専門学校をもつ学校法人である。3校の学生数は合わせて3,000名，学校法人本部（以下，本部という）の職員を含めて教職員数は150名である。表1に示すL学園の情報システムは，本部の情報システム課で開発管理を行い，本部の人事課と各校の学生課などの各主管部署で運用を行っている。このほか，本部にはWebサーバがあり，各校の一般向けWebサイトと学生向けWebサイトをインターネット経由で公開している。
　

表1　L学園の情報システム
種別システム名クライアント
ソフト利用者サーバ名（設置場所）現行の認証方式

事務系人事給与システム Webブラウザ教職員人事給与サーバ（本部） Webサーバによるフォーム認証

財務会計システム専用クライアントソフト職員財務会計サーバ（本部）専用サーバソフトによる認証

教務系学籍管理システム Webブラウザ教職員教務系サーバ（本部） Webサーバによるフォーム認証

成績管理システム Webブラウザ教職員，
学生

就職情報システム専用クライアントソフト教職員就職情報サーバ（各校）専用サーバソフトによる認証

学生実習環境
（Web閲覧を含む）市販ソフト，
Webブラウザ教職員，
学生 PC実習サーバ（各校）ディレクトリサーバによる認証

UNIX実習サーバ（各校） UNIX OSによる認証

共通ファイルサーバ（OSの標準機能）教職員ファイルサーバ
（本部，各校）ディレクトリサーバによる認証

グループウェア専用クライアントソフト教職員グループウェアサーバ
（本部，各校）グループウェアサーバによる認証

電子メールメールソフト教職員，
学生メールサーバ
（本部，各校） IMAP4による認証

　
　学園全体でのシステム化が進むに従って，学生や教職員が利用する利用者IDとパスワードの数は増加する一方である。事務系，教務系の各情報システムでは主管部署が個別に利用者IDとパスワードを発行しており，学生の入学や卒業，教職員の異動などのたびにアカウントの追加や削除を行っている。各校では授業で利用するノートPCを一括購入して新入学生に配布していることもあって，年度末から新年度にかけては各部署での業務上の負担が特に大きくなってきている。
　また，各利用者に対して情報システムごとに利用者IDが付与されることが多くなったことから，複数校の授業を兼任する教員などからは，複数の利用者IDとパスワードを覚えるのが難しいという声が頻繁に聞かれるようになってきている。一方，一部の情報システムでは職員個人には利用者IDが割り当てられておらず，数人の職員が一つの利用者IDを共用しているケースもある。
　こうした状態はパスワードや情報の漏えいにつながりかねないとの経営陣からの指摘や，将来の想定される用途を踏まえ，情報システム課は，安全な利用者認証を実現する手段や，利用者認証の新たな用途への応用について検討することにした。
　次は，情報システム課のP課長とその部下のQさんの会話である。
　
〔学生向けWebサイトの認証方式〕

P課長：まず，公開しているWebサーバについて考えていくことにしよう。現在，一般向けに公開している各校のWebサイトには利用者認証が必要なページはないが，各校の学生向けWebサイトには認証が必要なページがあるね。

Qさん：各校の学生向けWebサイトでは，入学の際に利用者IDと初期パスワードを学生に通知し，最初のアクセス時に初期パスワードを変更してもらっています。WebサーバではHTTPでベーシック認証を行い，学生はシラバス（講義要領）などの資料や休講連絡のページにアクセスしています。

P課長：今はSSLを使用していないから，HTTP上でのベーシック認証ではパスワードが漏えいする可能性があるのが一番の問題だね。これは一般的にWebサイトでよく使われるフォーム認証でも同様だ。
ベーシック認証よりも安全な方法として知られているものには，［　　a　　］認証がある。この方法では，ハッシュ関数を用いたチャレンジ・レスポンス方式を採用することでパスワードの漏えいを防ぐことができる。しかし，古いブラウザなどでは対応していないという問題がある。

Qさん：学生は携帯電話からアクセスすることが多いのですが，携帯電話でも［　　a　　］認証には対応していないものがあると聞いたことがあります。

P課長：今はあまり重要な情報を提供してはいないが，将来は学生向けポータルサイトとして履修登録や成績の確認，学生の出欠管理もできるようにしたいという要求が各校から出ている。

Qさん：そうなると，Webサイト上で重要な個人情報を取り扱うことになりますから，やはり〔1〕［　　a　　］認証を採用するだけでは不十分ですね。

P課長：そうだね。学生向けポータルサイトにはSSLの導入が必要になりそうだ。

Qさん： SSLを導入する場合には外部のサーバ証明書発行サービスを利用することになると思いますが，携帯電話への対応はどうしましょうか。

P課長：利用者側でSSLに対応した携帯電話を利用するのはもちろんだが，携帯電話会社や機種の違いも考慮する必要がある。多くの機種に対応したサイトを構築するには，サーバ側で適切な配慮が必要になりそうだね。

　
〔情報システムの認証方式〕

P課長：次に，現状での情報システムの問題点について見ていこう。

Qさん：教職員からは，個別の利用者IDとパスワードが情報システムごとに割り振られているので使いにくいという話をよく聞きます。

P課長：各情報システムによって構築された時期が違うし，利用形態や稼働しているOSもそれぞれ違っているからね。そもそも財務会計システムなどでは，職員一人一人ではなく係単位でしか利用者IDが割り振られていないから．セキュリティ上大きな問題がある。

Qさん：どういったところが問題なのでしょうか。

P課長： IDは英語でidentifier（識別子）というくらいだから利用者の識別が主な目的ではあるが，もう一つ大事な目的として［　　b　　］制御がある。つまり，どの利用者に，どのリソースに対して，どのようなアクセスを許可するのかということだ。個別に利用者IDを割り当てないと，権限の管理が適切に行えないおそれがある。また，最近は内部統制の観点から［　　c　　］性という要素も重視されるようになってきている。

Qさん：事務系も教務系も，利用者IDとパスワードの管理が煩雑になっているのが一番の問題ですね。シングルサインオン（以下，SSOという）を実現して，一度の利用者認証で複数の情報システムを利用できるようにするのがよいのではないでしょうか。

P課長：いや，それよりも現状では各情報システムの利用者の登録や削除に伴う運用コストの方が問題だ。まずは，個々の利用者に対して学園内の各情報システム共通に利用できる利用者IDを発行したい。これを仮に共通IDと呼ぶことにしよう。その上で，この共通IDを含む認証情報と，利用者の氏名や所属などの属性情報を併せて一元管理するシステムを作るのがよさそうだ。これは仮に共通IDシステムと呼ぶことにしよう。〔2〕個々の情報システムがこの共通IDシステムの提供する認証情報を利用して認証を行えるようにすれば，最初に利用者IDの移行に伴う作業が発生するが，各情報システムの主管部署での運用コストは低減できる。その次の段階ですべての情報システムをSSOに統合するのがよいだろう。その際，すべての情報システムを一度にSSOに対応させることが難しいなら，一部の情報システムから対応させていってもいい。

Qさん：すべての情報システムがSSOに統合されると，共通IDシステムももちろんですが，SSO機能を提供するサーバの可用性も重要になってきますね。

P課長：それに加えて，利用者側での利用者IDやパスワードの管理の問題もある。先日ビジネス専門学校に打合せに行った時，利用者IDとパスワードが書かれた付せん紙がPCのディスプレイにはってあったのを見つけたよ。このような実態ではSSOを導入するとかえって危険だから，パスワードに代わる認証方式を導入したいところだ。

Qさん：生体認証やICカードなどの認証トークンを検討してはどうでしょうか。どんなデバイスを選ぶかにもよりますが，学生の出席確認や入退室管理など，将来いろいろな用途が想定されます。

P課長：そうだね。ただ，当学園の情報システムには，クライアントとしてWebブラウザを使うものと専用クライアントソフトを使うものが混在しているから，認証トークンを導入するとSSOへの対応が難しくなるかもしれない。更に言うと，認証トークンを使うかどうかにかかわらず，現行の情報システムはできるだけ改修せずにSSOへの対応を図りたいところだね。

Qさん：そうですね。ちょっと欲張りな要件のような気もしますが，ベンダの提案を聞いてみることにしましょう。

　
〔無線LANと利用者認証〕

P課長：ネットワークの構成に関しても，様々な要望があるね。学生からは，インターネットに接続可能な無線LANアクセスポイント（以下，APという）を食堂やラウンジに設置してほしいという要望が出ている。実習スペースのデスクトップPCや校内の情報コンセントからでもインターネットにアクセスできるが，数年前から学生に配布しているノートPCには無線LANの機能があるからね。

Qさん：複数校を兼任してノートPCを持ち歩いている教員からは，どの学校からでも同じように無線LANを使って成績管理システムにアクセスしたいという声を聞きました。個人情報を扱うことになるので十分な対策が必要だと思いますが，無線LANでよく使われる［　　d　　］フィルタリングによる接続の制限や，WEPによる暗号化だけで十分なのでしょうか。

P課長：無線LANのセキュリティ対策には，利用者認証と暗号化方式の二つの側面がある。利用者認証の面から言うと，知識のある人なら［　　d　　］は偽装することができるから十分な対策とはいえない。さらに，各校のAPに利用者のノートPCの［　　d　　］をすべて登録する必要があるから，管理上の手間もかかる。また，暗号化方式の面では，WEPでは利用者が同じ暗号鍵を共用する上，解読が比較的容易だという脆(ぜい)弱性が知られている。

Qさん：利用者認証と暗号化方式の強化を考えなければいけないのですね。利用者認証の強化にはどのような方法があるのですか。

P課長：利用者認証には，IEEE 802.1Xという規格を採用するのがよさそうだ。これと暗号化方式の強化を組み合わせることでセキュリティの強化を図ることができるだろう。

Qさん：そういえば，私が駅やファストフード店でときどき使う公衆無線LANのAPでもIEEE 802.1Xを利用していたと思います。IEEE 802.1Xでは，利用者の認証はどのように行うのですか。

P課長： IEEE 802.1Xでは，利用者の認証情報はAPではなく認証サーバと呼ばれる別のサーバに格納されており，APはこの認証サーバにアクセスの可否を問い合わせる。そのプロトコルとしては［　　e　　］を利用する実装が多いようだ。

Qさん：以前はダイヤルアップのアクセスサーバなどでよく使われていたプロトコルですね。各校に認証サーバを設置して共通IDシステムと連携させれば，各校の間で共通に無線LANが利用できるわけですね。

P課長：そういうことだ。IEEE 802.1Xで使われるEAP（Extensible Authentication Protocol）というプロトコルはPPPを拡張したものだから，［　　e　　］とは親和性が高い。EAPでは，まず端末とAPの間で認証を行い，認証が完了した時点で端末に個別のセッション鍵を配送する。セッション鍵をもっていない未認証の端末は，APを超えてLAN側にパケットを送出することができない仕組みになっている。これに加え，EAPでは各種の認証方式を利用することができる。代表的な認証方式を挙げると，表2のようになる。

　

認証方式クライアント認証サーバ認証セッション鍵の自動生成ノートPCのOSでの対応

EAP-MD5 利用者ID/パスワードなしなし現在は実装なし

EAP-TLS ディジタル証明書ありあり標準対応

EAP-TTLS 利用者ID/パスワードありあり追加ソフトが必要

PEAP 利用者ID/パスワードありあり標準対応

　

Qさん：サーバ認証というのは，クライアント認証とは逆に，クライアントが認証サーバを認証するためのものですね。

P課長：そのとおり。EAP-MD5は〔3〕サーバ認証の仕組みをもたないのでリスクがあるし，学生に配布しているノートPCのOSでのサポートも打ち切られている。クライアント認証について言うと，EAP-TTLSではOSで標準的にサポートされていないので，追加ソフトが必要になる。したがって，共通IDシステムに公開鍵基盤（PKI）を導入するならEAP-TLSを，そうでなければPEAPを使うことになるだろう。

Qさん：セッション鍵の自動生成というのは，暗号化方式の強化に関係するものですね。

P課長：そうそう，暗号化方式を強化するという話がまだだったね。IEEE 802.1Xでは，利用者ごとに異なったWEP鍵が使用されることになっている。これに加え，セッション中も自動的にWEP鍵を更新することで，暗号化された通信の解読をより困難にするというわけだ。
無線LANの暗号化方式に関しては，近年になってより安全な規格が提案されている。WEPの後継規格であるWPAとIEEE 802.11i（WPA2）という規格では，利用者認証にIEEE 802.1Xを採用した上で，更に暗号化方式の強化を図っている。WPAでは，暗号化にはWEPと同じ［　　f　　］を使うものの，TKIPという鍵交換方式の採用によって暗号鍵を動的に変更することができる。また，WPA2では，暗号化に［　　g　　］を用いて暗号自体の強度を高めることができる。

Qさん：なるほど，暗号化方式の強化にもいろいろな方法があるのですね。

　
〔共通認証システム〕
　以上の検討を基に，P課長とQさんは共通IDシステム及びそれを利用して利用者認証を行うシステム（以下，両システムを併せて共通認証システムという）の要件をまとめ，図に示す提案依頼書をベンダ各社に提示した。
　この提案依頼書に対し，数社のベンダから提案書が寄せられた。その採否を検討する過程で，L学園はZ社に対してヒアリングを行うことになった。
　Z社の提案によると，利用者である個々の学生や教職員の認証情報と属性情報は，L学園本部に新たに設置するLDAPサーバにすべて格納される。このサーバが個々の情報システムに利用者の認証情報や属性情報を配信することで，情報システムが利用者認証を行うことができるようになっている。また，利用者認証にはPKIを利用することとし，公開鍵証明書と秘密鍵は，学生証又は教職員証を兼ねたICカードに格納して利用者本人に配布することとしている。
　

図　提案依頼書

共通認証システムに関する提案依頼書

1． L学園の情報システムの現状とネットワーク構成
（省略）

2．共通認証システムの目的
　当学園に在籍する学生と教職員を対象とした共通認証システムを新たに構築することによって，セキュリティを保ちつつ［　　ア　　］ことと［　　イ　　］ことを目的とする。また，教務系の各情報システムでの学生情報の利用などへの活用も目的とする。

3．共通認証システムの概要及びその要求仕様

3.1 　本部及び各校のすべての情報システム利用者に対する共通的な認証基盤である共通IDシステムの構築

(1) 　共通IDシステムでは，利用者に対して本部及び各校で共通の利用者IDを付与すること

(2) 　共通IDシステムでは，利用者の認証情報（共通IDを含む）及び属性情報（氏名，所属など）を一元管理し，当学園の情報システムに対して配布できること

(3) 　共通IDシステムを利用した利用者認証には〔4〕二要素認証を採用すること。ただし，学生向けWebサイトでの認証を除く

(4) 　共通IDシステムは，業務のサービスレベルの観点から可用性に配慮すること

3.2 　主要な情報システムにおけるシングルサインオン（SSO）機能の導入

(1) 　利用者が複数の業務アプリケーションにアクセスする際，それぞれにログインし直す必要がないよう，表1の情報システムに対してSSO機能を提供すること

(2) 　SSO機能には，共通IDシステムが提供する認証情報を用いること

(3) 　SSO機能を提供するサーバは，業務のサービスレベルの観点から〔5〕可用性に配慮すること

(4) 　SSO機能の提供に当たっては，既存の情報システムの改修を極力少なくすること

3.3 　学生向けWebサイトのSSL化

(1) 　各校の学生向けWebサイトをSSLに対応させること

(2) 　携帯電話からのSSLによるアクセスに対応させるために，サーバ証明書はすべての携帯電話会社の主要な機種に組み込まれたルート証明書によって検証可能であること

3.4 　各校における無線LANアクセスポイントの設置

(1) 　各校に無線LANアクセスポイント及び認証サーバを設置し，IEEE 802.1Xによる利用者認証を行うこと

(2) 　各校に設置されたIEEE 802.1Xの認証サーバと共通IDシステムの連携を図り，利用者が3校間で同様に無線LANを利用できるようにすること

(3) 　EAPの認証には，クライアントとサーバ間の相互認証が可能な方式を利用すること

(4) 　通信の暗号化方式としてWPA又はWPA2を採用すること

（以下省略）

　
次は，P課長，QさんとZ社の担当者X氏との会話である。
　
〔SSO機能の実現方式〕

P課長： SSO機能の実現方式についてお聞かせください。

X氏　：今回はWebのSSO機能と専用クライアントソフトのSSO機能を両立できるシステムを提案しています。
WebにおいてSSOを実現させる場合には，クッキーにセッションIDなどの情報を格納することで，認証された利用者に対するセッションを維持するのが一般的です。しかし，貴学園の場合は〔6〕本部と各校がそれぞれ別個のドメイン名を使用しているので，本部と各校をまたがって，クッキーを利用してセッションを維持することができません。

P課長：そうですか。ドメイン名のことまでは考えが及びませんでした。

X氏　：そこで，現在のドメイン名を変更することなく複数のドメインにまたがってSSOを実現するために，今回の提案ではリバースプロキシという方式を採用した製品を選択しました。
この方式では，利用者とWebサーバの間にリバースプロキシサーバと呼ばれるサーバを設置します。利用者からのアクセスは，このリバースプロキシサーバが認証を行った上で各Webサーバに中継することによってSSOが実現できます。新たに機器を設置することになるので，ネットワークの構成やWebアプリケーションへのアクセスの方法は変わりますが，Webアプリケーション自体の改修は基本的には不要です。

Qさん：専用クライアントソフトでのSSO機能についてはどのように考えていますか。

X氏　：利用者のPCにエージェントモジュールをインストールすることで，SSO機能を導入したいと思います。専用クライアントソフトの起動時に，エージェントモジュールが認証情報の入力を自動的に代行することでSSOを実現することができます。今回提案するSSOシステムのエージェントモジュールは，今お使いになっている専用クライアントソフトにすべて対応しています。

　
〔PKIによる利用者認証〕

P課長：次に，共通IDシステムを利用した利用者認証の方式についてお聞かせください。

X氏　：利用者認証には幾つかの方式が考えられます。ワンタイムパスワードや生体認証も考えられますが，PKIであれば公開鍵暗号を利用してお互いの公開鍵証明書を検証することができるので，より確実な認証方法となります。この方式であれば，共通IDシステムとIEEE 802.1Xの認証サーバをLDAPで連携させることで，無線LANのクライアント認証も実現可能です。

P課長： SSOや無線LANの認証にPKIを利用するとなると，ディジタル証明書と秘密鍵を格納するデバイスをどうするかという問題が出てきますね。御社でICカードを提案されたのは，どのような理由からでしょうか。

X氏　：認証用デバイスとしては，USBトークンやICカードを利用することが考えられます。どちらもデバイスの機能によってディジタル証明書と秘密鍵が保護されており，PINを入力することで二要素認証が実現できます。
一般的には，それぞれ表3のようなメリットとデメリットがあります。これらの特徴に加え，〔7〕将来の想定される用途を踏まえて両者を比較した結果，ICカードを採用すべきであると判断しました。

　

　　デバイス
料金 USBトークン ICカード

メリット

・機器のUSBポートに挿すだけで使える。

・デバイス自体に鍵のようなイメージがあり，利用者にとってなじみやすい。

・配布方法が既に確立されている学生証や教職員証を兼ねることができる。

・ USBトークンよりも安価である。

・用途に応じて接触方式又は非接触方式を選択できる。

デメリット

・ ICカードよりも高価である。

・ USBポートのある機器でしか利用できない。

・機器にICカード読取り機が必要である。

　

Qさん：新学期が始まる前にはICカードを大量に発行する必要がありますが，どのような方法で対応されますか。

X氏　： ICカードの発行は外部に委託し，各校で本人確認を行った上で配布していただくことを提案しています。

Qさん： ICカードの発行を外部に委託できるのであれば，年度末の負担もそれほど増えずに済みますね。

　
　L学園は更に検討を進めた結果，Z社の提案を採用し，共通認証システムの構築を完了することができた。
　

　
設問1　学生向けWebサイトの認証の手法について，(1)，(2)に答えよ。

(1) 　本文中の［　　a　　］に入れる適切な字句を答えよ。

(2) 　本文中の下線〔1〕について，Qさんが不十分としている理由を，25字以内で述べよ。

　

設問1の正解へ
　
設問2　情報システムの認証方式について，(1)～(3)に答えよ。

(1) 　本文中の［　　b　　］，［　　c　　］に入れる適切な字句を解答群の中から選び，記号で答えよ。
解答群

ア　効率イ　真正ウ　信頼

エ　責任追跡オ　認可カ　認証

(2) 　本文中の下線〔2〕について，個々の情報システムで行っていた利用者IDの発行を共通IDシステムに移行するとき，個々の情報システムの主管部署と情報システム課の間で必要となる調整事項を，30字以内で述べよ。

(3) 　図中の下線〔4〕は，共通IDシステムを利用してSSOを実現する際に考慮すべき，どのようなリスクの低減を意図したものか。60字以内で述べよ。

　

設問2の正解へ
　
設問3　SSOの実現方式について，(1)，(2)に答えよ。

(1) 　図中の下線〔5〕は，SSO機能を提供するサーバにおいてどのようなリスクの低減を意図したものか。60字以内で述べよ。

(2) 　本文中の下線〔6〕について，クッキーを利用したセッションの維持ができない理由を，クッキーの動作原理に基づいて40字以内で述べよ。

　

設問3の正解へ
　
設問4　無線LANと利用者認証の方式について，(1)，(2)に答えよ。

(1) 　本文中の［　　d　　］～［　　g　　］に入れる適切な字句を解答群の中から選び，記号で答えよ。
解答群

ア　AES イ　CHAP ウ　ESSID エ　IPアドレス

オ　MACアドレスカ　RADIUS キ　RC4 ク　RC5

ケ　SASL コ　URL サ　トリプルDES シ　パケット

(2) 　本文中の下線〔3〕について，無線LANのサーバ認証によってどのような脅威を防ぐことができるか。また，その脅威が防げない場合には，どのような直接の被害が発生する可能性があるか。それぞれ30字以内で述べよ。

　

設問4の正解へ
　
設問5　共通認証システムの設計について，(1)，(2)に答えよ。

(1) 　現状での情報システムの問題点に関するP課長とQさんの会話を踏まえて，図中の［　　ア　　］，［　　イ　　］に入れる共通認証システムの目的を，それぞれ15字以内で述べよ。

(2) 　本文中の下線〔7〕の観点から，USBトークンとICカードを比較した結果，X氏がICカードを採用すべきであると判断した理由を，30字以内で述べよ。

　

設問5の正解へ
　
メニューへ戻る
　

種別	システム名	クライアントソフト	利用者	サーバ名（設置場所）	現行の認証方式
事務系	人事給与システム	Webブラウザ	教職員	人事給与サーバ（本部）	Webサーバによるフォーム認証
事務系	財務会計システム	専用クライアントソフト	職員	財務会計サーバ（本部）	専用サーバソフトによる認証
教務系	学籍管理システム	Webブラウザ	教職員	教務系サーバ（本部）	Webサーバによるフォーム認証
	成績管理システム	Webブラウザ	教職員，学生	教務系サーバ（本部）	Webサーバによるフォーム認証
	就職情報システム	専用クライアントソフト	教職員	就職情報サーバ（各校）	専用サーバソフトによる認証
	学生実習環境（Web閲覧を含む）	市販ソフト， Webブラウザ	教職員，学生	PC実習サーバ（各校）	ディレクトリサーバによる認証
	学生実習環境（Web閲覧を含む）	市販ソフト， Webブラウザ	教職員，学生	UNIX実習サーバ（各校）	UNIX OSによる認証
共通	ファイルサーバ	（OSの標準機能）	教職員	ファイルサーバ（本部，各校）	ディレクトリサーバによる認証
	グループウェア	専用クライアントソフト	教職員	グループウェアサーバ（本部，各校）	グループウェアサーバによる認証
	電子メール	メールソフト	教職員，学生	メールサーバ（本部，各校）	IMAP4による認証

P課長：	まず，公開しているWebサーバについて考えていくことにしよう。現在，一般向けに公開している各校のWebサイトには利用者認証が必要なページはないが，各校の学生向けWebサイトには認証が必要なページがあるね。
Qさん：	各校の学生向けWebサイトでは，入学の際に利用者IDと初期パスワードを学生に通知し，最初のアクセス時に初期パスワードを変更してもらっています。WebサーバではHTTPでベーシック認証を行い，学生はシラバス（講義要領）などの資料や休講連絡のページにアクセスしています。
P課長：	今はSSLを使用していないから，HTTP上でのベーシック認証ではパスワードが漏えいする可能性があるのが一番の問題だね。これは一般的にWebサイトでよく使われるフォーム認証でも同様だ。ベーシック認証よりも安全な方法として知られているものには，［　　a　　］認証がある。この方法では，ハッシュ関数を用いたチャレンジ・レスポンス方式を採用することでパスワードの漏えいを防ぐことができる。しかし，古いブラウザなどでは対応していないという問題がある。
Qさん：	学生は携帯電話からアクセスすることが多いのですが，携帯電話でも［　　a　　］認証には対応していないものがあると聞いたことがあります。
P課長：	今はあまり重要な情報を提供してはいないが，将来は学生向けポータルサイトとして履修登録や成績の確認，学生の出欠管理もできるようにしたいという要求が各校から出ている。
Qさん：	そうなると，Webサイト上で重要な個人情報を取り扱うことになりますから，やはり〔1〕［　　a　　］認証を採用するだけでは不十分ですね。
P課長：	そうだね。学生向けポータルサイトにはSSLの導入が必要になりそうだ。
Qさん：	SSLを導入する場合には外部のサーバ証明書発行サービスを利用することになると思いますが，携帯電話への対応はどうしましょうか。
P課長：	利用者側でSSLに対応した携帯電話を利用するのはもちろんだが，携帯電話会社や機種の違いも考慮する必要がある。多くの機種に対応したサイトを構築するには，サーバ側で適切な配慮が必要になりそうだね。

P課長：	次に，現状での情報システムの問題点について見ていこう。
Qさん：	教職員からは，個別の利用者IDとパスワードが情報システムごとに割り振られているので使いにくいという話をよく聞きます。
P課長：	各情報システムによって構築された時期が違うし，利用形態や稼働しているOSもそれぞれ違っているからね。そもそも財務会計システムなどでは，職員一人一人ではなく係単位でしか利用者IDが割り振られていないから．セキュリティ上大きな問題がある。
Qさん：	どういったところが問題なのでしょうか。
P課長：	IDは英語でidentifier（識別子）というくらいだから利用者の識別が主な目的ではあるが，もう一つ大事な目的として［　　b　　］制御がある。つまり，どの利用者に，どのリソースに対して，どのようなアクセスを許可するのかということだ。個別に利用者IDを割り当てないと，権限の管理が適切に行えないおそれがある。また，最近は内部統制の観点から［　　c　　］性という要素も重視されるようになってきている。
Qさん：	事務系も教務系も，利用者IDとパスワードの管理が煩雑になっているのが一番の問題ですね。シングルサインオン（以下，SSOという）を実現して，一度の利用者認証で複数の情報システムを利用できるようにするのがよいのではないでしょうか。
P課長：	いや，それよりも現状では各情報システムの利用者の登録や削除に伴う運用コストの方が問題だ。まずは，個々の利用者に対して学園内の各情報システム共通に利用できる利用者IDを発行したい。これを仮に共通IDと呼ぶことにしよう。その上で，この共通IDを含む認証情報と，利用者の氏名や所属などの属性情報を併せて一元管理するシステムを作るのがよさそうだ。これは仮に共通IDシステムと呼ぶことにしよう。〔2〕個々の情報システムがこの共通IDシステムの提供する認証情報を利用して認証を行えるようにすれば，最初に利用者IDの移行に伴う作業が発生するが，各情報システムの主管部署での運用コストは低減できる。その次の段階ですべての情報システムをSSOに統合するのがよいだろう。その際，すべての情報システムを一度にSSOに対応させることが難しいなら，一部の情報システムから対応させていってもいい。
Qさん：	すべての情報システムがSSOに統合されると，共通IDシステムももちろんですが，SSO機能を提供するサーバの可用性も重要になってきますね。
P課長：	それに加えて，利用者側での利用者IDやパスワードの管理の問題もある。先日ビジネス専門学校に打合せに行った時，利用者IDとパスワードが書かれた付せん紙がPCのディスプレイにはってあったのを見つけたよ。このような実態ではSSOを導入するとかえって危険だから，パスワードに代わる認証方式を導入したいところだ。
Qさん：	生体認証やICカードなどの認証トークンを検討してはどうでしょうか。どんなデバイスを選ぶかにもよりますが，学生の出席確認や入退室管理など，将来いろいろな用途が想定されます。
P課長：	そうだね。ただ，当学園の情報システムには，クライアントとしてWebブラウザを使うものと専用クライアントソフトを使うものが混在しているから，認証トークンを導入するとSSOへの対応が難しくなるかもしれない。更に言うと，認証トークンを使うかどうかにかかわらず，現行の情報システムはできるだけ改修せずにSSOへの対応を図りたいところだね。
Qさん：	そうですね。ちょっと欲張りな要件のような気もしますが，ベンダの提案を聞いてみることにしましょう。

P課長：	ネットワークの構成に関しても，様々な要望があるね。学生からは，インターネットに接続可能な無線LANアクセスポイント（以下，APという）を食堂やラウンジに設置してほしいという要望が出ている。実習スペースのデスクトップPCや校内の情報コンセントからでもインターネットにアクセスできるが，数年前から学生に配布しているノートPCには無線LANの機能があるからね。
Qさん：	複数校を兼任してノートPCを持ち歩いている教員からは，どの学校からでも同じように無線LANを使って成績管理システムにアクセスしたいという声を聞きました。個人情報を扱うことになるので十分な対策が必要だと思いますが，無線LANでよく使われる［　　d　　］フィルタリングによる接続の制限や，WEPによる暗号化だけで十分なのでしょうか。
P課長：	無線LANのセキュリティ対策には，利用者認証と暗号化方式の二つの側面がある。利用者認証の面から言うと，知識のある人なら［　　d　　］は偽装することができるから十分な対策とはいえない。さらに，各校のAPに利用者のノートPCの［　　d　　］をすべて登録する必要があるから，管理上の手間もかかる。また，暗号化方式の面では，WEPでは利用者が同じ暗号鍵を共用する上，解読が比較的容易だという脆(ぜい)弱性が知られている。
Qさん：	利用者認証と暗号化方式の強化を考えなければいけないのですね。利用者認証の強化にはどのような方法があるのですか。
P課長：	利用者認証には，IEEE 802.1Xという規格を採用するのがよさそうだ。これと暗号化方式の強化を組み合わせることでセキュリティの強化を図ることができるだろう。
Qさん：	そういえば，私が駅やファストフード店でときどき使う公衆無線LANのAPでもIEEE 802.1Xを利用していたと思います。IEEE 802.1Xでは，利用者の認証はどのように行うのですか。
P課長：	IEEE 802.1Xでは，利用者の認証情報はAPではなく認証サーバと呼ばれる別のサーバに格納されており，APはこの認証サーバにアクセスの可否を問い合わせる。そのプロトコルとしては［　　e　　］を利用する実装が多いようだ。
Qさん：	以前はダイヤルアップのアクセスサーバなどでよく使われていたプロトコルですね。各校に認証サーバを設置して共通IDシステムと連携させれば，各校の間で共通に無線LANが利用できるわけですね。
P課長：	そういうことだ。IEEE 802.1Xで使われるEAP（Extensible Authentication Protocol）というプロトコルはPPPを拡張したものだから，［　　e　　］とは親和性が高い。EAPでは，まず端末とAPの間で認証を行い，認証が完了した時点で端末に個別のセッション鍵を配送する。セッション鍵をもっていない未認証の端末は，APを超えてLAN側にパケットを送出することができない仕組みになっている。これに加え，EAPでは各種の認証方式を利用することができる。代表的な認証方式を挙げると，表2のようになる。

認証方式	クライアント認証	サーバ認証	セッション鍵の自動生成	ノートPCのOSでの対応
EAP-MD5	利用者ID/パスワード	なし	なし	現在は実装なし
EAP-TLS	ディジタル証明書	あり	あり	標準対応
EAP-TTLS	利用者ID/パスワード	あり	あり	追加ソフトが必要
PEAP	利用者ID/パスワード	あり	あり	標準対応

Qさん：	サーバ認証というのは，クライアント認証とは逆に，クライアントが認証サーバを認証するためのものですね。
P課長：	そのとおり。EAP-MD5は〔3〕サーバ認証の仕組みをもたないのでリスクがあるし，学生に配布しているノートPCのOSでのサポートも打ち切られている。クライアント認証について言うと，EAP-TTLSではOSで標準的にサポートされていないので，追加ソフトが必要になる。したがって，共通IDシステムに公開鍵基盤（PKI）を導入するならEAP-TLSを，そうでなければPEAPを使うことになるだろう。
Qさん：	セッション鍵の自動生成というのは，暗号化方式の強化に関係するものですね。
P課長：	そうそう，暗号化方式を強化するという話がまだだったね。IEEE 802.1Xでは，利用者ごとに異なったWEP鍵が使用されることになっている。これに加え，セッション中も自動的にWEP鍵を更新することで，暗号化された通信の解読をより困難にするというわけだ。無線LANの暗号化方式に関しては，近年になってより安全な規格が提案されている。WEPの後継規格であるWPAとIEEE 802.11i（WPA2）という規格では，利用者認証にIEEE 802.1Xを採用した上で，更に暗号化方式の強化を図っている。WPAでは，暗号化にはWEPと同じ［　　f　　］を使うものの，TKIPという鍵交換方式の採用によって暗号鍵を動的に変更することができる。また，WPA2では，暗号化に［　　g　　］を用いて暗号自体の強度を高めることができる。
Qさん：	なるほど，暗号化方式の強化にもいろいろな方法があるのですね。

P課長：	SSO機能の実現方式についてお聞かせください。
X氏　：	今回はWebのSSO機能と専用クライアントソフトのSSO機能を両立できるシステムを提案しています。 WebにおいてSSOを実現させる場合には，クッキーにセッションIDなどの情報を格納することで，認証された利用者に対するセッションを維持するのが一般的です。しかし，貴学園の場合は〔6〕本部と各校がそれぞれ別個のドメイン名を使用しているので，本部と各校をまたがって，クッキーを利用してセッションを維持することができません。
P課長：	そうですか。ドメイン名のことまでは考えが及びませんでした。
X氏　：	そこで，現在のドメイン名を変更することなく複数のドメインにまたがってSSOを実現するために，今回の提案ではリバースプロキシという方式を採用した製品を選択しました。この方式では，利用者とWebサーバの間にリバースプロキシサーバと呼ばれるサーバを設置します。利用者からのアクセスは，このリバースプロキシサーバが認証を行った上で各Webサーバに中継することによってSSOが実現できます。新たに機器を設置することになるので，ネットワークの構成やWebアプリケーションへのアクセスの方法は変わりますが，Webアプリケーション自体の改修は基本的には不要です。
Qさん：	専用クライアントソフトでのSSO機能についてはどのように考えていますか。
X氏　：	利用者のPCにエージェントモジュールをインストールすることで，SSO機能を導入したいと思います。専用クライアントソフトの起動時に，エージェントモジュールが認証情報の入力を自動的に代行することでSSOを実現することができます。今回提案するSSOシステムのエージェントモジュールは，今お使いになっている専用クライアントソフトにすべて対応しています。

P課長：	次に，共通IDシステムを利用した利用者認証の方式についてお聞かせください。
X氏　：	利用者認証には幾つかの方式が考えられます。ワンタイムパスワードや生体認証も考えられますが，PKIであれば公開鍵暗号を利用してお互いの公開鍵証明書を検証することができるので，より確実な認証方法となります。この方式であれば，共通IDシステムとIEEE 802.1Xの認証サーバをLDAPで連携させることで，無線LANのクライアント認証も実現可能です。
P課長：	SSOや無線LANの認証にPKIを利用するとなると，ディジタル証明書と秘密鍵を格納するデバイスをどうするかという問題が出てきますね。御社でICカードを提案されたのは，どのような理由からでしょうか。
X氏　：	認証用デバイスとしては，USBトークンやICカードを利用することが考えられます。どちらもデバイスの機能によってディジタル証明書と秘密鍵が保護されており，PINを入力することで二要素認証が実現できます。一般的には，それぞれ表3のようなメリットとデメリットがあります。これらの特徴に加え，〔7〕将来の想定される用途を踏まえて両者を比較した結果，ICカードを採用すべきであると判断しました。

Qさん：	新学期が始まる前にはICカードを大量に発行する必要がありますが，どのような方法で対応されますか。
X氏　：	ICカードの発行は外部に委託し，各校で本人確認を行った上で配布していただくことを提案しています。
Qさん：	ICカードの発行を外部に委託できるのであれば，年度末の負担もそれほど増えずに済みますね。

(1)	本文中の［　　a　　］に入れる適切な字句を答えよ。
(2)	本文中の下線〔1〕について，Qさんが不十分としている理由を，25字以内で述べよ。

(1)	図中の下線〔5〕は，SSO機能を提供するサーバにおいてどのようなリスクの低減を意図したものか。60字以内で述べよ。
(2)	本文中の下線〔6〕について，クッキーを利用したセッションの維持ができない理由を，クッキーの動作原理に基づいて40字以内で述べよ。

(1)	現状での情報システムの問題点に関するP課長とQさんの会話を踏まえて，図中の［　　ア　　］，［　　イ　　］に入れる共通認証システムの目的を，それぞれ15字以内で述べよ。
(2)	本文中の下線〔7〕の観点から，USBトークンとICカードを比較した結果，X氏がICカードを採用すべきであると判断した理由を，30字以内で述べよ。