平成22年度 秋期に実施された情報処理安全確保支援士試験
午後Ⅱの全2問（記述式）の全設問に，運営者が独自に書いた解説を付けています。事例本文のどこが根拠になるかを示し，IPA の解答例・採点講評と並べています。
問1 安全なWebアプリケーションの開発
安全なWebアプリケーションの開発に関する次の記述を読んで，設問1〜5に答えよ。
X社は従業員数500名のソフトウェア会社で，10本程度の人事関連のソフトウェアパッケージ（以下，パッケージという）を開発，保守している。X社には，顧客から，パッケージを購入せず，利用料を払ってアプリケーションサービス（以下，サービスという）を受けられるようにしてもらえないかという問合せが増えている。また，競合他社の中には，そのようなサービスを提供するところも出てきている。このような状況を受けて，X社の経営陣は，パッケージに加え，サービスも商品ラインナップに加える方針を決定した。
X社は，手始めに，既存のパッケージではなく，新規の分野でサービスを提供することにした。具体的には，既存顧客から要望が出ていた，店舗で働くパートタイマやアルバイトの勤怠管理を行うシステム（以下，勤怠管理システムという）でサービスを提供することにした。また，システムの稼働率を高めるために，単一のシステムを複数の顧客で共用するマルチテナントのシステムとする方針を決定した。
一方，X社はこれまでイントラネット向けのパッケージ開発を専業としてきたので，インターネットに公開する安全なWebアプリケーションの開発ノウハウがなかった。X社の経営陣は，今後，サービス提供を拡大していくためには，安全なWebアプリケーション開発のノウハウ獲得が不可欠であると考えた。そこで，今回の開発プロジェクトを通じて，そのノウハウを身につけ，今後のほかの開発プロジェクトにも適用していくことにした。特に，今回のシステムはマルチテナントのシステムなので，顧客間でデータが漏えいしないよう，十分に検討して対策を行うことにした。
X社のシステム関連部署は四つあり，パッケージ開発部，システム技術部，システム運用部及びプロジェクト管理部である。パッケージ開発部はパッケージの開発・保守を行っている。システム技術部は，社内のネットワーク，サーバ，ミドルウェアなどのインフラ（以下，インフラという）の設計・構築を担当している。システム運用部は社内のインフラの運用を担当しており，セキュリティパッチ適用などの情報セキュリティ運用も行っている。プロジェクト管理部は，社内の開発プロジェクトを管理する部署である。
X社は勤怠管理システムの開発プロジェクトを立ち上げた。プロジェクト体制として，プロジェクトマネージャをプロジェクト管理部のP課長が務め，その下に，開発チーム及びインフラチームが作られた。開発チームは，アプリケーションの設計・開発を担当し，開発の一部は複数の外部委託先に委託した。そして，開発チームのリーダはパッケージ開発部のBさんが務めることになった。また，アプリケーション開発のセキュリティ対策を支援するために，システム技術部からD課長とF主任が開発チームに参加することになった。インフラチームは，システム技術部のメンバで構成され，インフラの設計・構築及び本番稼働までの保守・運用を担当し，インフラチームのリーダはシステム技術部のEさんが務めることになった。本番稼働後は，勤怠管理システムの運用をシステム運用部に引き継ぐことになっている。
〔勤怠管理システムの概要〕
勤怠管理システムは，店舗ごとの従業員情報（氏名，従業員番号など）の管理機能，勤務予定の作成及び勤務実績の記録と参照のための機能，並びに給与システムへの勤怠データ出力機能をもつ。勤怠データは店舗ごとに管理される。また，複数店舗の情報を集約する機能があり，システムを利用する1顧客当たり50店舗まで管理することができる。
〔勤怠管理システムのネットワーク構成〕
勤怠管理システムのネットワーク構成を図1に，ファイアウォール（以下，FWという）のアクセス制御ルールを表に示す。Webサーバ上ではミドルウェアとアプリケーションが稼働する。
図1 勤怠管理システムのネットワーク構成
表 FWのアクセス制御ルール
〔プロジェクト計画の策定〕
本開発プロジェクトの開始に当たって，F主任はP課長から提示されたプロジェクト計画書を確認した。
図2は，プロジェクト計画書中で示された，開発プロジェクトのスケジュール概要（開発チームの関連部分を抜粋）である。要件定義には，セキュリティ要件の定義も含まれている。また，システムテスト期間の後半で本番稼働前に，ルータ，FW，各サーバ及びWebアプリケーションの脆弱性テストを外部の専門家に依頼する計画となっていた。
図2 開発プロジェクトのスケジュール概要（抜粋）
F主任は，①本番稼働直前の脆弱性テストだけで安全なWebアプリケーションを開発しようとする計画には，プロジェクトマネジメント上，問題がある と考え，P課長に計画の変更を提案した。P課長は，F主任の提案を受けて，②レビューを設計工程（基本設計，詳細設計）及び製造・単体テスト工程に追加する形で計画を変更した 。
なお，外部委託先については，X社から開発ガイドライン準拠チェックリスト（以下，チェックリストという）を提供し，外部委託先からは工程ごとにチェック結果を提出してもらうことにした。
〔コーディングルールの作成〕
次に，F主任が本開発プロジェクトでのガイドラインを確認したところ，開発チームではX社の標準である開発ガイドラインを適用する計画となっていた。X社では開発ガイドラインを制定し，各パッケージの開発・保守に適用している。図3は開発ガイドラインのSQL処理に関する記載の抜粋である。
図3 開発ガイドラインのSQL処理に関する記載（抜粋）
F主任は，基本設計に先立って，開発ガイドラインを基に，開発言語として使用するJavaの具体的なコーディングルールも作成した。図4は，F主任の作成したコーディングルールのうちSQL処理に関する記載の抜粋である。
図4 コーディングルールのうちSQL処理に関する記載（抜粋）
F主任は，コーディングルールを作成後，プロジェクトメンバが参照できるようにファイルサーバに配置した。その後，開発プロジェクトは基本設計に入り，勤怠管理システムの設計が開発チームを中心に進められた。
〔勤怠管理システムのデータベース構成〕
勤怠管理システムはマルチテナントのシステムなので，一つのシステムの中で複数の顧客のデータを扱うが，顧客間でデータは分離する。顧客間でデータを分離する方法として，開発チームは，③データベースの各テーブルで，顧客を識別するカラムを追加する方式 を採用した。具体的には，顧客単位で区別するために，顧客IDを各テーブルに入れることにした。詳細設計におけるデータベース論理設計結果のうち，主なテーブルの概要を図5に，そのE-R図を図6に示す。
図5 主なテーブルの概要
図6 主なテーブルのE-R図
〔アプリケーション設計のレビュー〕
詳細設計工程に進んだところで，社内メンバにセキュリティの観点でのレビュー経験がないことから，社内でのレビューではセキュリティ上の設計ミスやプログラム中の脆弱性を発見しきれないのではないかとBさんは考えた。そこで，セキュリティコンサルティング会社のH社の支援を受けることを提案し，承認された。H社は，アプリケーションセキュリティの専門家であるGさんを担当者としてアサインした。
詳細設計終了後，Gさんは，Bさん，F主任とともに詳細設計結果に対するレビューを行ったところ，勤務実績表示の処理に問題があることを発見した。問題があった勤務実績表示の処理を図7に示す。従業員選択画面には，ログイン中の利用者が所属している店舗の全従業員がリストに表示される。従業員をリストから選択すると，選択された従業員の勤務実績が勤務実績表示画面に表示される処理となっている。図7の勤務実績表示のSQL文は，図中の勤務実績表示画面を表示するためのSQL文で，【選択した従業員の利用者ID】には，従業員選択画面のリストで選択した従業員の利用者IDが指定される。
図7 問題があった勤務実績表示の処理
Gさん：勤務実績表示画面では，他人の勤務実績を参照することができますね。 F主任：はい，この機能では，同じ店舗に所属しているほかの従業員の勤務実績が参照できるようになっています。 Gさん：同じ店舗だけならばよいのですが，このままではほかの店舗の従業員の勤務実績も参照することができます。具体的には，従業員選択画面のリストから従業員を選択して表示する処理に問題があります。 F主任：リストには，店舗に所属している従業員の一覧を表示し，HTMLのOPTIONタグのVALUE属性には，選択した従業員の利用者IDを指定するようになっています。従業員の一覧では，ログイン中の利用者と同じ店舗に所属している従業員だけが表示されますので，ほかの店舗の従業員を選択することはできないのではないでしょうか。 Gさん：いいえ，可能です。選択された従業員の勤務実績を表示する処理では，VALUE属性として送信されてきた利用者IDに対し，データの型をチェックした後，図7中のSQL文にそのまま使用する設計なので，これでは④ほかの店舗の従業員の勤務実績を権限なく閲覧される可能性があります 。 F主任：なるほど。分かりました。早速，対策を検討して対応します。 F主任はGさんのアドバイスを基に対策を考え，同様の問題がほかにないかどうかの確認も含めて，Bさんを通して対策を開発チームに依頼した。
〔SQLインジェクション脆弱性の発見と対策〕
製造・単体テスト，結合テストが終了し，システムテストに入った。一方，F主任はプロジェクト計画に基づき，外部の専門家による脆弱性テストを実施した。
脆弱性テストの結果，ある処理でSQLインジェクション脆弱性の作り込みが発見された。開発チームリーダのBさんに確認したところ，開発プロジェクトの途中で，外部委託先Z社に新規に開発を委託しており，その開発部分で発見されたことが分かった。
Z社から提出を受けていたチェック結果には“コーディングルールに適合”と記入されていたので，F主任はZ社に事実関係を確認した。Z社は，X社のコーディングルールの内容は十分に理解していたが，コーディングルール違反をレビューで見逃したままチェック結果をX社に提出していたと回答した。F主任はBさんに報告した。Bさんは，Z社の開発部分全体についてコーディングルールの遵守を確認するよう，開発チームに指示した。
〔ミドルウェアの脆弱性〕
システムテストが終了し，システム運用部が加わり勤怠管理システムをインターネットに接続して運用テストを進めていた。本番稼働の2日前に，システム運用部のメンバがインターネットのニュースサイトを見ていたところ，勤怠管理システムで使用しているミドルウェアにおける脆弱性が1か月前に公表されていることを，偶然見つけた。
X社のこれまでのパッケージ開発では，テスト期間中にミドルウェアのバージョンを見直すことはなかった。システム運用部は，インフラチームのリーダであるEさんに相談した。Eさんはベンダが発表している脆弱性情報と勤怠管理システムのミドルウェアのバージョンを確認し，その内容と影響を報告書にまとめた。図8はEさんのまとめた報告書である。
図8 Eさんのまとめた報告書
X社内で，関係者で検討した結果，Eさんのまとめた報告書にある脆弱性の内容及び影響に変化がなければ，サービスの本番移行は予定どおり実施するとの判断をした。また，根本対策として，次回の定期メンテナンスでセキュリティパッチを適用することにした。
その後，本番稼働までの2日間，脆弱性情報の更新を確認したが，特に更新はなかった。また，サービス稼働監視でも異常は発見されず，無事，本番稼働を迎えた。
〔本番稼働後の報告〕
本番稼働後，D課長はプロジェクト管理部に対して，今回の開発プロジェクトで発生したセキュリティ上の問題点と対応について報告を行った。プロジェクト管理部は，SQLインジェクション脆弱性の作り込みを踏まえた⑤開発委託先管理の問題点 と，開発プロジェクトにおける本番稼働前のシステムに対する⑥脆弱性情報の管理の問題点 を指摘し，今回の開発プロジェクトで得られた経験を，今後のシステムの開発，運用，保守に生かすため，D課長に具体的な解決策の提案を依頼した。
D課長はP課長，Bさん，F主任にも解決策の検討を依頼し，検討結果を取りまとめ，プロジェクト管理部に提案を行った。X社の経営陣は提案を承認し，X社のプロセスとしてシステムの開発，運用，保守に適用することにした。
出題趣旨（IPA）
クラウドコンピューティングの広がりによって，アプリケーションがサービスとして提供される機会が増えている。そのため，アプリケーション全体のセキュリティ対策をより適切に実施することが求められる。本問では，アプリケーションサービスの開発プロジェクトを題材として，安全なシステムの開発に必要な開発工程，アプリケーション実装及び共同利用型のシステムにおけるデータ分離の知識を問う。また，開発プロジェクトでの組織的な問題を解決する能力を問う。
採点講評（問全体・IPA）
問1では，開発プロジェクトにおいて安全なシステム開発のために情報セキュリティスペシャリストが支援すべきテーマについて幅広く出題した。全体として正答率は想定どおりだった。
設問と解答例
設問1
解答欄2つ
〔コーディングルールの作成〕について，図4中のa ，b に入れる適切な字句を解答群の中から選び，記号で答えよ。解答群 ア java.sql.PreparedStatement stmt = con.prepareStatement(sql); イ java.sql.ResultSet rs = stmt.executeQuery(); ウ java.sql.ResultSet rs = stmt.executeQuery(sql); エ java.sql.Statement stmt = con.bind(sql); オ java.sql.Statement stmt = con.doFilter(sql);
解説
本文の根拠
図3
SQL文の組立てには，プレースホルダ及びバインド機構を使用すること
図4
String sql = "SELECT * FROM atable WHERE name=?";
図4
stmt.setString(1, param);
a は“ア”，b は“イ”である。a は，空欄の次の行の stmt.setString(1, param); で使われる stmt を用意する行なので，SQL 文の雛形 sql を渡して java.sql.PreparedStatement 型の stmt を得る“java.sql.PreparedStatement stmt = con.prepareStatement(sql);”が入る。b は，値をバインドした後にその SQL を実行して結果（ResultSet）を受け取る行なので，引数なしの“java.sql.ResultSet rs = stmt.executeQuery();”が入る。
図4の sql は“name=?”と値の部分が空欄（プレースホルダ）のままになっている。Oracle の Java SE API 仕様（PreparedStatement）は，PreparedStatement を“precompiled SQL statement”を表すオブジェクトとし，Connection の prepareStatement で作って setXXX で値を位置指定して使う例を示している。executeQuery() も，同仕様に“Executes the SQL query in this PreparedStatement object and returns the ResultSet object generated by the query”とある。IPA の“安全なウェブサイトの作り方”も，SQL 文の組立ては全てプレースホルダで実装することを SQL インジェクションの根本的解決として挙げている。
ウは executeQuery(sql) と SQL 文を引数に渡す形で，雛形に値をバインドして実行する流れにならない。エ・オの java.sql.Statement stmt = con.bind(sql); や con.doFilter(sql); は，SQL 文の雛形を準備してから次の行の setString で値をバインドするという図4の流れに沿う書き方ではないので，a にはアを選ぶ。
設問2(1)
35字以内
本文中の下線①でF主任が，問題があると指摘した理由を，35字以内で述べよ。
解答例
修正に期間が掛かり，本番稼働が延期となる可能性があるから
解説
本文の根拠
〔プロジェクト計画の策定〕
また，システムテスト期間の後半で本番稼働前に，ルータ，FW，各サーバ及びWebアプリケーションの脆弱性テストを外部の専門家に依頼する計画となっていた。
図2
脆弱性テストは9月後半の短い期間（システムテスト期間の後半）。運用テストは9月末から10月初め。本番稼働は10月初め（▼印）。
問題は，脆弱性が見つかったときに直す時間が残っていないことである。解答例は“修正に期間が掛かり，本番稼働が延期となる可能性があるから”である。
図2のとおり，脆弱性テストはシステムテストの後半の短い期間に置かれ，その後は運用テストを経てすぐ本番稼働になる。ここで脆弱性が見つかると，設計やプログラムまで戻って直し，再度テストをすることになり，期間が掛かる。F主任が“プロジェクトマネジメント上”の問題と言っているのは，この手戻りが本番稼働の時期という納期に響くことを指す。
字数は28字で，制限の35字に収まる。講評は，“手戻りがある”とだけ書いた解答が多かったと述べている。手戻りで終わらせず，“修正に期間が掛かる”→“本番稼働が延期となる”という納期への影響まで書く。
採点講評（IPA）
設問2(1)は，プロジェクトマネジメント上の問題を問うたが，手戻りがあるとだけ解答したものが散見された。プロジェクトをセキュリティ面で支援するときには，納期やコストなどの問題を考慮して解答してほしかった。
設問2(2)
40字以内
本文中の下線②でP課長は，設計工程（基本設計，詳細設計）にレビューを追加した。その内容を，40字以内で具体的に述べよ。
解答例
セキュリティ要件が正しく設計に反映されているかどうかをレビューする。
解説
本文の根拠
〔プロジェクト計画の策定〕
要件定義には，セキュリティ要件の定義も含まれている。
図2
要件定義は3月。基本設計は4月。詳細設計は5月。
設計工程に追加するレビューの内容は，要件定義で決めたセキュリティ要件が設計に正しく反映されているかを確かめることである。解答例は“セキュリティ要件が正しく設計に反映されているかどうかをレビューする。”である。
要件定義にセキュリティ要件の定義が含まれているので，その要件を満たす実現方法が基本設計・詳細設計で設計される。設計にセキュリティ要件が反映されていなければ，後の工程で脆弱性対策をしても要件は満たせない。そのため，設計の段階で要件と設計の対応をレビューする。
字数は34字で，制限の40字に収まる。講評は，この設問の正答率は高かったが，設計工程で求められる“セキュリティ要件の実現方法を設計する”という観点が漏れた解答が散見されたと述べている。脆弱性の有無を調べるだけでなく，要件が設計に反映されているかを書く。
採点講評（IPA）
設問2(2)は，正答率が高かった。しかし，設計工程において求められる，セキュリティ要件の実現方法を設計するという観点が漏れている解答が散見された。脆弱性対策だけではなく，開発プロジェクトにおける工程ごとに行うべき作業を幅広く理解しておいてほしい。
設問2(3)
50字以内
本文中の下線②でP課長は，製造・単体テスト工程にレビューを追加した。その内容を，50字以内で具体的に述べよ。
解答例
開発ガイドライン及びコーディングルールに基づきコーディングされていることを確認する。
解説
本文の根拠
〔プロジェクト計画の策定〕
なお，外部委託先については，X社から開発ガイドライン準拠チェックリスト（以下，チェックリストという）を提供し，外部委託先からは工程ごとにチェック結果を提出してもらうことにした。
〔コーディングルールの作成〕
F主任は，基本設計に先立って，開発ガイドラインを基に，開発言語として使用するJavaの具体的なコーディングルールも作成した。
製造・単体テスト工程に追加するレビューの内容は，作成したプログラムが開発ガイドラインとコーディングルールに沿っているかを確認することである。解答例は“開発ガイドライン及びコーディングルールに基づきコーディングされていることを確認する。”である。
製造・単体テストはコーディングを行う工程なので，この工程のレビューはコードを対象にする。F主任は，開発ガイドラインを基にJavaの具体的なコーディングルールを作っており（図3・図4の SQL 処理の記載もその一部），これに従っているかが確認の基準になる。外部委託先にはチェックリストを渡し，工程ごとに結果を出してもらう計画である。
字数は42字で，制限の50字に収まる。設計工程のレビュー（設問2(2)）が“要件と設計の対応”を見るのに対し，この工程は“コードとコーディングルールの対応”を見る，という違いを書き分ける。
設問3(1)
55字以内
本文中の下線④の指摘は，具体的にどのようなHTTPリクエストによって閲覧されると指摘したものか。55字以内で述べよ。
解答例
【選択した従業員の利用者ID】を表すリクエストパラメタの値としてほかの店舗の利用者IDを与える。
解説
本文の根拠
〔アプリケーション設計のレビュー〕
リストには，店舗に所属している従業員の一覧を表示し，HTMLのOPTIONタグのVALUE属性には，選択した従業員の利用者IDを指定するようになっています。
〔アプリケーション設計のレビュー〕
VALUE属性として送信されてきた利用者IDに対し，データの型をチェックした後，図7中のSQL文にそのまま使用する設計なので
従業員選択画面のリストでは，同じ店舗の従業員しか選べない。しかし，選んだ従業員の利用者IDは VALUE 属性の値としてブラウザからサーバに送られ，サーバは型を調べるだけでSQL文に使う。したがって，リクエストの値を書き換えて，ほかの店舗の利用者IDを送れば，その従業員の勤務実績が表示される。解答例は“【選択した従業員の利用者ID】を表すリクエストパラメタの値としてほかの店舗の利用者IDを与える。”である。
図7のSQL文は，勤務実績テーブルから CUST_ID（ログイン中の利用者の顧客ID）と USR_ID（選択した従業員の利用者ID）で絞り込む。同じ顧客の別の店舗の従業員なら CUST_ID が一致するので，店舗の違いは検査されない。画面に表示されない値でも，送信されるリクエストの値は利用者が自由に変えられる。
字数は48字で，制限の55字に収まる。“どのようなHTTPリクエスト”と聞かれているので，リクエストパラメタ（利用者ID）の値を何に変えるのか（ほかの店舗の利用者ID）まで書く。
設問3(2)
60字以内
この問題を避けるためには，データの型をチェックした後，どのようなチェック処理を行うべきか。60字以内で述べよ。
解答例
【選択した従業員の利用者ID】の値がログイン中の利用者と同じ店舗の従業員の利用者IDかどうかをチェックする。
解説
本文の根拠
図7
WHERE CUST_ID = 【ログイン中の利用者の顧客ID】 / AND USR_ID = 【選択した従業員の利用者ID】
図5
従業員テーブル：CUST_ID（文字列，顧客ID，省略），USR_ID（文字列，利用者ID，省略），STORE_ID（文字列，店舗ID，省略），PASSWORD
型のチェックの後に行うべきチェックは，送られてきた利用者IDが，ログイン中の利用者と同じ店舗の従業員のものかどうかの確認である。解答例は“【選択した従業員の利用者ID】の値がログイン中の利用者と同じ店舗の従業員の利用者IDかどうかをチェックする。”である。
型のチェックは，値が文字列や数字として正しい形かを見るだけで，その人を見てよいかという権限の確認にはならない。図5の従業員テーブルには店舗ID（STORE_ID）があるので，送られた利用者IDの従業員の店舗IDが，ログイン中の利用者の店舗IDと同じかを，サーバ側で確かめられる。確認はリストの表示ではなく，勤務実績を表示する処理の側で行う。
字数は54字で，制限の60字に収まる。“同じ店舗かどうか”という確認の観点（アクセス制御）を書く。
設問4(1)
45字以内
SQLインジェクションが発生したときでも，ほかの顧客のデータをSQLで操作されにくいようにするためには，本文中の下線③の方式をどのように変更すべきか。45字以内で述べよ。
解答例
データベースのテーブルとアカウントを顧客ごとに分離し，アクセス権を設定する。
解説
本文の根拠
〔勤怠管理システムのデータベース構成〕
顧客間でデータを分離する方法として，開発チームは，③データベースの各テーブルで，顧客を識別するカラムを追加する方式を採用した。
〔勤怠管理システムのデータベース構成〕
具体的には，顧客単位で区別するために，顧客IDを各テーブルに入れることにした。
下線③の方式は，全顧客のデータを同じテーブルに入れ，顧客ID の列で区別する。この方式では，SQLインジェクションでWHERE句を書き換えられると，ほかの顧客の行にも触れてしまう。解答例は“データベースのテーブルとアカウントを顧客ごとに分離し，アクセス権を設定する。”で，顧客ごとにテーブルとデータベースのアカウントを分け，アカウントにはその顧客のテーブルだけへのアクセス権を与える方式に変える。
こうすると，SQLインジェクションが成立しても，使われるアカウントがその顧客のテーブルしか操作できないので，ほかの顧客のデータは操作されにくい。IPA の“安全なウェブサイトの作り方”も，SQLインジェクションの保険的対策として，データベースに渡す命令文の実行に必要な最小限の権限をデータベースアカウントに与えるよう挙げている。
字数は38字で，制限の45字に収まる。講評は，この設問の正答率が低く，アクセス権の設定の記述がない解答が散見されたと述べている。“テーブルを分ける”だけで終わらせず，“アカウントを分けてアクセス権を設定する”まで書く。
採点講評（IPA）
設問4(1)は，正答率が低かった。アクセス権の設定についての記述がない解答が散見された。SQLインジェクションは知っているものの，データベースのアクセス権に関する知識が十分活用されていなかった結果と思われる。本設問では，問題文の状況の下でマルチテナントのシステムにおけるデータベースの分離方法をセキュリティ面から検討している。これをきっかけにデータベースのアクセス権について理解しておいてほしい。
設問4(2)
50字以内
本文中の下線⑤の開発委託先管理の問題点を解決するために，X社が行うべきことを50字以内で述べよ。
解答例（2通り）
開発委託先の成果物に対して，委託先のレビューに加えて，X社でも受入検査を詳細に実施する。 チェックリストの各項目を判定する基準を示し，その判定結果と根拠を提出させる。
解説
本文の根拠
〔SQLインジェクション脆弱性の発見と対策〕
Z社から提出を受けていたチェック結果には“コーディングルールに適合”と記入されていたので，F主任はZ社に事実関係を確認した。
〔SQLインジェクション脆弱性の発見と対策〕
Z社は，X社のコーディングルールの内容は十分に理解していたが，コーディングルール違反をレビューで見逃したままチェック結果をX社に提出していたと回答した。
下線⑤の問題点は，委託先が出したチェック結果を，X社が確かめないまま信用していたことである。Z社は，ルールを理解していながら違反を見逃したまま“適合”と報告していた。解答例は二つの対策のどちらでもよい。一つは“開発委託先の成果物に対して，委託先のレビューに加えて，X社でも受入検査を詳細に実施する。”，もう一つは“チェックリストの各項目を判定する基準を示し，その判定結果と根拠を提出させる。”である。
前者は，委託先の自己チェックに任せず，X社が成果物を直接検査して違反を見つける方法で，後者は，“適合”の一言ではなく判定基準を与え，その結果と根拠を出させて，チェックの質を上げる方法である。どちらも，チェック結果の信頼性をX社の側で担保する点が共通している。
字数は，前者が44字，後者が38字で，制限の50字に収まる。どちらか一つを書けばよい。設問は“X社が行うべきこと”なので，X社の側の行動として書く。
設問5(1)
解答欄1つ
図8中のc に入れる適切な字句を解答群の中から選び，記号で答えよ。解答群 ア エクスプロイトコード イ セキュリティパッチ ウ セキュリティポリシ エ ゼロデイ攻撃手法 オ バッファオーバフロー
解説
本文の根拠
図8
ベンダはどのようなパケットでDoS攻撃が可能か公表しておらず，ベンダのその後の報告では，10月1日現在，脆弱性による不正な動作を再現するc は公開されていない。
図8
9月1日に，勤怠管理システムで使用しているミドルウェアにおける脆弱性情報及びセキュリティパッチが公表された。
c は“ア”のエクスプロイトコードである。脆弱性を悪用して不正な動作を起こさせるためのコードを指し，“脆弱性による不正な動作を再現する”ものという文意に合う。
図8の概要によれば，9月1日に脆弱性情報とセキュリティパッチは公表されており，イの“セキュリティパッチ”は“公開されていない”ことにならない。ウのセキュリティポリシは，脆弱性による動作を再現するものではない。エの“ゼロデイ攻撃手法”とオの“バッファオーバフロー”は，攻撃や脆弱性の種類を表す語で，不正な動作を再現するコードそのものを指さない。
記号で答える設問なので，語の意味を書く必要はない。“パケットでDoS攻撃が可能か公表しておらず”という文脈から，攻撃を再現するもの（コード）が公開されていない，と読む。
設問5(2)
解答欄1つ
図8中のd に入れる適切な実施済対策の内容を，50字以内で述べよ。
〔d〕解答例
ファイアウォールで，インターネットからのTCPポート番号8080への通信を拒否する。
解説
本文の根拠
図8
ミドルウェアには管理画面があり，TCPポート番号8080で利用できるようになっている。
表 FWのアクセス制御ルール
項番1：TCP，インターネット，Webサーバ，80，443，許可。
表 FWのアクセス制御ルール
項番5：すべて，すべて，すべて，すべて，拒否。注(1) “DB”は，データベースアクセスに必要なポート番号である。注 項番の昇順に，最初に一致したルールが適用される。
d には，ファイアウォールでインターネットから8080番ポートへの通信を拒否している，という対策が入る。解答例は“ファイアウォールで，インターネットからのTCPポート番号8080への通信を拒否する。”である。
管理画面は，ミドルウェアの TCP ポート番号8080で動作する。表を上から見ると，インターネットからWebサーバへの通信は項番1の80番と443番だけが許可され，8080番はどの許可ルールにも当たらず，項番5の“すべて拒否”に当たる。注のとおり，最初に一致したルールが適用される。管理セグメントからの通信は項番3で許可されるので，管理は社内から行える。このため，インターネットから直接，管理画面（8080番）へは届かず，図8の“インターネットから直接に攻撃を受けるわけではない”になる。
字数は42字で，制限の50字に収まる。“管理画面にアクセスできない”だけでなく，どの機器（ファイアウォール）で，どこから（インターネット）のどの通信（TCP 8080番）を止めているかまで書く。
設問5(3)
40字以内
本文中の下線⑥の問題点に対する解決策を，今後の開発プロジェクトの在り方の観点から，40字以内で述べよ。
解答例
X社の標準開発プロセスに脆弱性情報の収集と管理責任を規定する。
解説
本文の根拠
〔ミドルウェアの脆弱性〕
本番稼働の2日前に，システム運用部のメンバがインターネットのニュースサイトを見ていたところ，勤怠管理システムで使用しているミドルウェアにおける脆弱性が1か月前に公表されていることを，偶然見つけた。
〔ミドルウェアの脆弱性〕
X社のこれまでのパッケージ開発では，テスト期間中にミドルウェアのバージョンを見直すことはなかった。
下線⑥の問題点は，脆弱性情報を収集する担当や仕組みが決まっておらず，1か月前の公表に本番稼働の2日前まで気付かなかったことである。解答例は“X社の標準開発プロセスに脆弱性情報の収集と管理責任を規定する。”である。
イントラネット向けのパッケージ開発では，テスト期間中にミドルウェアのバージョンを見直すことがなかった。その習慣のまま，今回のインターネットに公開するシステムの開発でも，脆弱性情報を集めて管理する役割がなく，システム運用部のメンバが偶然見つけて初めて分かった。“今後の開発プロジェクトの在り方”の観点なので，個別の対応ではなく，X社の標準の開発プロセスに，収集と管理の責任を組み込む答えになる。
字数は31字で，制限の40字に収まる。“標準開発プロセスに規定する”という仕組みの面を書く。
出典：平成22年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問1（表記を一部改変）
問2 社内認証システムの統合
社内認証システムの統合に関する次の記述を読んで，設問1〜5に答えよ。
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社では，社内にA-SSOシステムを含む複数の認証システムが混在しており，システム監査において，図1に示す課題が指摘されていた。ここで，認証システムとは，アカウント情報の管理，利用者の認証及びアクセス許可を行うシステムのことをいう。
図1 A社の認証システムに関して指摘されていた課題
そこで，認証システムを統合することになり，情報システム部を中心とした社内プロジェクトチーム（以下，Sチームという）が発足した。また，経営陣から，当該プロジェクトは，SaaS型サービス事業に活用できる成果を出すようにという指示があった。この指示を考慮し，プロジェクトの開始に先立ち，認証システムの統合の基本方針を図2にまとめた。
図2 A社の認証システムの統合の基本方針
〔認証システムの洗い出し〕
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に返信し，アクセス許可を受ける。
図3 C-CR認証のプロトコル
他方，Kerberos認証では，図4に示すように，クライアントが，DCにおける認証後，有効期限付のチケットが発行され，それをサーバに提示し，アクセス許可を受ける。
図4 Kerberos認証のプロトコル
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に示すプロトコルを利用する。
図5 A-SSOシステムのプロトコル
次は，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に，即時，データ転送される。
図6 アカウント情報の反映のフロー
A社では，アカウント情報に関して，C-DIR用，LDAP用及びNIS用の3種類のデータ形式を用いている。LDAPのアカウント情報では，inetOrgPersonといったオブジェクトクラスによって組織の利用者の情報を管理する標準的なb を用いている。例えば，製品開発部のスズキタロウ氏が社内で利用するLDAP用のアカウント情報をc によってテキスト形式で示すと，図7となる。
図7 LDAPにおけるスズキタロウ氏のアカウント情報（抜粋）
〔統合認証システムの基本設計〕
社内の認証システムの仕様を洗い出した後，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という）システムを採用することにした。
図8 統合認証システムの基本設計概念
SAMLとは，記述言語としてd を用いて，認証及びe に関する情報を交換するための標準規格である。今回，A社で採用したSAML型SSOシステムにおける認証及びe を実現するプロトコルは，図9のとおりである。Webアプリ上には，SP（サービスプロバイダ）と呼ばれるモジュールが稼働しており，IdP（Idプロバイダ）と呼ばれるWebアプリと連携して，利用者認証を行う。IdPにおいては，様々な認証方式を採用できるが，A社では，入力フォームを活用した，利用者IDとパスワードを用いる方式を採用し，図8の統合認証システムにおけるLDAPサーバと連携させることにした。
図9 SAML型SSOシステムのプロトコル
次は，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のとおり，情報システムのリプレース及び認証システムの統合化計画案を策定した。
図10 情報システムのリプレース及び認証システムの統合化計画案
A社は，情報システムをリース契約で導入しており，4年ごとにリプレースを実施している。2012年にはインフラ系のリプレースが予定されており，2013年には基幹業務系のリプレースが予定されている。いずれの作業も，情報システム部が行う。他方，部署運用系のリプレース作業については，所管部門がそれぞれ行うことになっており，現在，製品サポート部及び製品開発部所管の情報システムのリプレース作業を行っている。また，2012年に，研究部所管の情報システムのリプレースを実施する予定である。
なお，A社では，ハードウェアの故障などのトラブルの発生が増えるのを避けるため，リース契約の延長は行わない。
図10の計画案の策定では，このような前提の下，認証システムの統合のスケジュールを検討し，次の3点を決定した。
SaaS型サービス事業は最優先であり，さらに，引き続きソフトウェアパッケージの開発及びサポート業務もあるので，製品サポート部，製品開発部及び研究部所管の情報システムのリプレースの時期は変更しない。 統合認証システムの構築作業を2011年に実施する。 A-SSOシステムのリプレースは，インフラ系のほかの情報システム群のリプレースとともに予定どおり行う。A-SSOシステムの廃止が可能になるのは，早くても，f 年の末である。それまでは，継続利用しようと考えたが，g という理由から，次回のインフラ系のリプレース時に，A-SSOシステムも，ほかのインフラ系の情報システム群と併せてリプレースしておく必要があると判断した。 Sチームが結論とした統合認証システムの基本設計と統合化計画案は，アカウント情報の一元化に伴う管理工数の削減やサーバマシン数の削減によって，運用コストの削減も見込めると期待され，認証システムの統合が正式にスタートした。
出題趣旨（IPA）
本問は，組織内の認証システムの統合を進める上で，情報システム部門が解決すべき課題を幅広く扱っている。認証及び関連技術に関しては，旧来の技術から最新の技術までを対象にして出題した。認証システムを統合する上での，基本的な設計能力及び重要な課題の一つであるスケジューリングに関する能力を問う。旧認証システムであるA-SSOシステムを利用しているシステムが，新方式である統合認証システムに連携し終わるまでA-SSOシステムを廃止できず，A-SSOのサービスを継続させなければならないということへの“気づき”を確認する。また，A-SSOのサービスを継続するための阻害要因を状況から見いだす能力に加えて，連携しているシステムのリプレース時期を見据え，A-SSOの廃止時期の判断を問う。
採点講評（問全体・IPA）
問2では，組織内の認証システムの統合に関する技術及び統合におけるスケジューリングについて出題した。全体として正答率は想定どおりだった。
設問と解答例
設問1
解答欄4つ
本文中のb 〜e に入れる適切な字句を解答群の中から選び，記号で答えよ。解答群 ア ELF イ LDIF ウ XML エ 構成管理 オ スキーマ カ 認可 キ パスワード ク パスワードファイル
解説
本文の根拠
〔A社のアカウント情報の反映のフロー〕
LDAPのアカウント情報では，inetOrgPersonといったオブジェクトクラスによって組織の利用者の情報を管理する標準的なb を用いている。
〔A社のアカウント情報の反映のフロー〕
例えば，製品開発部のスズキタロウ氏が社内で利用するLDAP用のアカウント情報をc によってテキスト形式で示すと，図7となる。
〔統合認証システムの基本設計〕
SAMLとは，記述言語としてd を用いて，認証及びe に関する情報を交換するための標準規格である。
b は“オ”のスキーマ，c は“イ”の LDIF，d は“ウ”の XML，e は“カ”の認可である。
b：RFC 4512 の4章は，LDAP のスキーマを，ディレクトリ情報木の構造に関する定義と制約の集まりとし，オブジェクトクラスの定義が，エントリが持つ（持てる）属性を定め，属性型の定義が構文などを定めるとしている。inetOrgPerson は RFC 2798 が LDAP と X.500 のために定めた，組織内の人を表すオブジェクトクラスで，本文の“エントリの属性を定義する”“拡張して”もスキーマの話である。c：図7は dn・cn・objectclass の各行が並ぶテキストで，RFC 2849 が定める LDIF（LDAP Data Interchange Format）の形式である。d・e：OASIS の SAML 2.0 技術概要は，SAML の assertion が認証（authentication），属性（attribute），認可（authorization）に関する情報を表す XML 形式のものとしている。
本文の“認証及びe ”は，この三つのうち，選択肢にある認可と読める。ア ELF，エ 構成管理，キ パスワード，ク パスワードファイルは，いずれも SAML が交換する情報の種類にも，ディレクトリのエントリを表すテキスト形式にもならない。
記号で答える設問なので，語の説明を書く必要はない。b と d の取り違えに注意する（スキーマは属性を定義する枠組み，XML は SAML の記述言語）。
設問2(1)
50字以内
本文中の下線①の疑似乱数の生成方法に問題があり，同じ乱数が生成される場合，どのような脅威が考えられるか。攻撃の手順とともに，50字以内で具体的に述べよ。
解答例
チャレンジとレスポンスのペアを盗聴し，正規のレスポンスを用いてリプレイ攻撃によるなりすましをする。
解説
本文の根拠
〔認証システムの洗い出し〕
C-CR認証では，図3に示すプロトコルの(b)-1〜(b)-4において，①DCが生成した疑似乱数をチャレンジとし，それを受信したクライアントで，利用者ID，パスワード及びチャレンジの連結をハッシュ化したレスポンスをDCに返信し，アクセス許可を受ける。
図3
(b)-3 利用者認証（レスポンス）（クライアントからサーバへ，点線）。
チャレンジが毎回変わることで，過去のレスポンスの使い回しを防ぐのがチャレンジレスポンス認証の仕組みである。疑似乱数の生成方法に問題があって同じ乱数（チャレンジ）が生成されると，過去に使われたチャレンジと同じ値が再び送られる。解答例は“チャレンジとレスポンスのペアを盗聴し，正規のレスポンスを用いてリプレイ攻撃によるなりすましをする。”である。
攻撃の手順は，(1) 正規の利用者の認証で，ネットワーク上を流れるチャレンジとレスポンスのペアを盗聴しておく，(2) 後日，同じチャレンジが DC から出されたとき，盗聴したレスポンスをそのまま返す，の2段階である。レスポンスは利用者ID，パスワード，チャレンジから作られるので，同じチャレンジに対する正規のレスポンスは，攻撃者が自分で作れなくても使い回せる。その結果，パスワードを知らなくても，その利用者になりすませる（リプレイ攻撃）。
字数は49字で，制限の50字に収まる。“脅威（なりすまし）”だけでなく“攻撃の手順（ペアの盗聴と再送）”を書くよう求められている。講評は，チャレンジレスポンス認証はネットワークにおける認証の基本であり，よく理解しておいてほしいと述べている。
採点講評（IPA）
設問2(1)は，正答率が低かった。チャレンジレスポンス認証は，ネットワークにおける認証の基本であるので，よく理解しておいてほしい。
設問2(2)
解答欄1つ
本文中の下線②を実現するために，a に入れる適切な字句を10字以内で答えよ。
解説
本文の根拠
〔認証システムの洗い出し〕
また，Kerberos認証において，②有効期限切れのチケットが悪用されないように，DCとサーバをa させて運用している。
〔認証システムの洗い出し〕
Kerberos認証の場合，有効期限内であればチケットをサーバに提示するだけでサービスを受けられる。
a は“時刻同期”である。Kerberos のチケットには有効期限があり，サーバは自分の現在時刻とチケットの期限を比べて，期限切れかどうかを判断する。RFC 4120 の1.6節は，ネットワーク上の各ホストの時計が“loosely synchronized”（ゆるく同期）していなければならないと定め，3.2.3節は，サーバの現在時刻がチケットの終了時刻よりも許容されるずれを超えて後なら，期限切れ（KRB_AP_ERR_TKT_EXPIRED）として扱うと述べている。
DCとサーバの時計がずれていると，この判断が狂い，期限が切れたチケットを有効と受け付けたり，有効なチケットを拒否したりする。DCとサーバの時刻を同期させて，チケットの有効期限を両者で同じ基準で見られるようにしておけば，有効期限切れのチケットを使った不正を防げる。
字数は4字で，制限の10字に収まる。解答例は“時刻同期”で，DCとサーバの間で何を揃えるのかを答える。
設問3(1)
45字以内
図1中の(5)の脆弱性とは何か。セキュリティ管理の現状とA-SSOシステムの仕様から判断して，45字以内で述べよ。
解答例
所管部門の異なるA-Webアプリのすべてに同一の暗号化鍵を配布していること
解説
本文の根拠
〔A-SSOシステムの仕様の確認〕
また，すべてのA-Webアプリには，クッキーを復号するために暗号化鍵を配布している。
〔A社の情報システム〕
他方，製品サポート部，製品開発部及び研究部が，部署ごとに導入して運用管理をしている情報システム群（以下，部署運用系という）があり，それらの一部は，認証にA-SSOシステムを採用しているWebアプリ（以下，A-Webアプリという）である。
図1の(5)の脆弱性は，所管部門が異なるすべてのA-Webアプリに，同一の暗号化鍵を配布していることである。解答例は“所管部門の異なるA-Webアプリのすべてに同一の暗号化鍵を配布していること”である。
A-Webアプリは，A-SSO用のクッキーを復号するための暗号化鍵を持つ。その鍵が製品サポート部・製品開発部・研究部などの部署運用系のアプリすべてに同じものとして配布されている。部署ごとに運用管理をしており，図1の(3)にあるように運用管理のセキュリティレベルが同じとは限らない。どれか一つのアプリや部署の管理が甘く，鍵が漏れた場合，ほかの部署のアプリのクッキーも復号できてしまう。
字数は37字で，制限の45字に収まる。講評は，セキュリティレベルの異なる部門において同じ暗号化鍵を用いることが問題であると，A-SSOシステムの設計及び問題文の状況設定から理解してほしかったと述べている。同一の鍵を配布していることを書く。
採点講評（IPA）
設問3(1)は，正答率が低かった。セキュリティレベルの異なる部門において同じ暗号化鍵を用いることが問題であることを，旧認証システムであるA-SSOシステムの設計及び問題文中の状況設定から理解してほしかった。
設問3(2)
70字以内
本文中の下線③の技術的課題に，SAML型SSOシステムではどのように対処しているか。図9中の字句を用いて，70字以内で具体的に述べよ。
解答例
暗号化及びディジタル署名したSAMLResponseメッセージを用いて，IdPからSPへ認証情報を転送している。
解説
本文の根拠
〔統合認証システムの基本設計〕
A-SSOシステムには，図1の(5)の指摘があることに加え，③A-SSO用のクッキーの利用が原因となり，A-SSOサーバとA-Webアプリが同じインターネットドメイン上にないとシングルサインオンを実現できないという技術的課題があった。
〔統合認証システムの基本設計〕
(d) IdPは，利用者IDなどの属性を暗号化及びディジタル署名したSAMLResponseメッセージを発行し，ブラウザ上のJavaScriptを用いて，それをSPに転送する。
〔統合認証システムの基本設計〕
(e) SPは，SAMLResponseメッセージのディジタル署名などを検証し，有効であれば，SP用のクッキーを発行する。
A-SSOシステムでは，A-SSOサーバが発行したクッキーをA-Webアプリが受け取る。クッキーは発行したドメインのサーバにしか送られないため，両者が同じドメイン上にある必要がある。SAML型SSOでは，IdP が認証結果を SAMLResponse メッセージにして発行し，ブラウザ上の JavaScript で SP に転送する。クッキーを使わずに，メッセージで認証情報を渡すので，ドメインをまたいでも認証できる。SP は検証の後，自分用のクッキーを発行する。解答例は“暗号化及びディジタル署名したSAMLResponseメッセージを用いて，IdPからSPへ認証情報を転送している。”である。
OASIS の SAML 2.0 技術概要も，ブラウザ SSO の HTTP POST バインディングでは，IdP の応答を含むフォームをスクリプトで SP に自動送信するのが典型だと説明している。メッセージの内容が暗号化され，ディジタル署名されているので，ブラウザを経由して送っても，利用者による改ざんを検知でき，内容も守られる。
字数は56字で，制限の70字に収まる。“図9中の字句を用いて”とあるので，SAMLResponse，IdP，SP を使う。講評は，SAMLではドメインをまたいだWebアプリケーションの認証にSAMLResponseメッセージを用いていること，そのメッセージでは暗号化とディジタル署名を用いてセキュリティを確保していることの理解を求めている。
採点講評（IPA）
設問3(2)は，正答率が低かった。SAMLではドメインをまたいだWebアプリケーションの認証にSAMLResponseメッセージを用いていることに加えて，SAMLResponseメッセージでは，暗号化とディジタル署名を用いて，セキュリティを確保していることを理解しておいてほしい。
設問4(1)
60字以内
統合認証システムにおいて，図1中の(2)の指摘にどのように対処しているか。60字以内で述べよ。
解答例
管理フォーマットを一つにし，IDMでパスワードを一元的に管理し，それを各情報システムが参照する仕組みを導入した。
解説
本文の根拠
図1
(2) 情報システムごとにパスワードルールが異なるので，同じレベルのパスワードの強度が確保されていない。
〔統合認証システムの基本設計〕
アカウント情報のシステム間の反映に関しては，人事マスタからID管理サーバ（以下，IDMという）にアカウント情報を日次で反映し，IDMのディレクトリ（以下，IDMマスタという）で保持し，変換後，IDMからC-DIRのディレクトリ及びLDAPにアカウント情報を即時反映する方式を採用した。
〔統合認証システムの基本設計〕
利用者がパスワードを変更したい場合は，IDMのWebインタフェースを通して，利用者が自ら変更することが可能で，C-DIR又はLDAPサーバなどに，即時反映される仕組みとした。
図1の(2)は，情報システムごとにパスワードルールが異なり，パスワードの強度が確保できていないという指摘である。統合認証システムでは，アカウント情報を一元的に管理し，パスワードはIDMで管理して，各情報システムが参照する仕組みにした。解答例は“管理フォーマットを一つにし，IDMでパスワードを一元的に管理し，それを各情報システムが参照する仕組みを導入した。”である。
旧環境では C-DIR 用・LDAP 用・NIS 用の3種類のデータ形式でアカウント情報を扱い，システムごとに別々にパスワードを管理していた。統合後は，IDMのWebインタフェースでパスワードを変更すると C-DIR や LDAP に即時反映される。パスワードの管理を IDM に集約すれば，パスワードのルールも一か所で決めて，全システムで同じ強度を保てる。
字数は56字で，制限の60字に収まる。“管理フォーマットを一つにする”“IDMで一元的に管理する”“各システムが参照する”の三つの要素を入れる。
設問4(2)
60字以内
本文中の下線④にあるA社にとっての運用管理上のメリットとは何か。SAML型SSOシステムの特徴に基づいて60字以内で述べよ。
解答例
SaaS型サービスのアカウント管理と運用を，必要に応じて，A社から切り分けることが可能となる。
解説
本文の根拠
〔統合認証システムの基本設計〕
Sチームは，SaaS型サービス事業への展開を視野に入れ，SAML型SSOを複数のIdPでも適用できるように設計した。
〔統合認証システムの基本設計〕
このサービスを導入する企業は，自社のイントラネットにIdPを用意すれば，導入する企業のイントラネットにあるPC端末からインターネット経由で，A社のデータセンタに配備されたSaaS型サービス事業のWebアプリを利用することが可能となる。
SAML型SSOでは，利用者を認証してアカウント情報を持つのは IdP で，SP（Webアプリ）は IdP が出す SAMLResponse を検証して利用を認める（図9）。IdP を顧客のイントラネットに置けば，顧客の利用者のアカウント情報の管理と認証は，顧客の側で行われる。解答例は“SaaS型サービスのアカウント管理と運用を，必要に応じて，A社から切り分けることが可能となる。”である。
A社は，SaaS型サービスの Webアプリ（SP）の側だけを運用すればよく，顧客企業の利用者のアカウントの追加・変更・削除や認証の運用に関わらずに済む。SAML型SSOでは IdP と SP が別の主体として分かれており，IdP を複数立てることも設計に入っている。
字数は47字で，制限の60字に収まる。“SAML型SSOシステムの特徴に基づいて”とあるので，IdP と SP が分かれていることを根拠にして，A社の運用負担が分離できることを書く。設問は“A社にとっての”メリットなので，A社の側の運用管理を書く。
設問5(1)
解答欄2つ
本文中のf に入れる適切な年を答えよ。また，Sチームがそのように判断する理由を40字以内で具体的に述べよ。
〔理由〕解答例
A-SSOシステムと連携した情報システム群のリプレースがすべて完了するから
解説
本文の根拠
〔移行計画の策定と実施〕
A社は，情報システムをリース契約で導入しており，4年ごとにリプレースを実施している。
図10
製品サポート部：2010年にリプレース（R），2011年から2013年にサポート準備（灰色の棒），2014年にリプレース（R）。製品開発部：2010年にリプレース（R），2011年から2013年に開発（灰色の棒），2014年にリプレース（R）。
表
基幹業務系：情報システム部。財務会計，勤怠管理，人事管理，施設予約，経費精算など。備考は，勤怠管理と施設予約はA-SSOシステムで認証。
f は“2014”，理由は“A-SSOシステムと連携した情報システム群のリプレースがすべて完了するから”である。
A-SSOを廃止できるのは，A-SSOシステムで認証している情報システムの全部が，SAML型SSOに対応した新しいシステムに入れ替わった後である。表から，A-SSOで認証しているのは，基幹業務系の勤怠管理・施設予約，製品サポート部の顧客管理・製品管理，製品開発部のグループウェア・eラーニング，研究部のナレッジベースである。図10のリプレースの時期は，研究部が2012年，基幹業務系が2013年，製品サポート部と製品開発部が2014年で，最後が2014年。矢印の右端が本稼働の開始時期なので，2014年に本稼働した後に使い始められる。したがって，廃止が可能になるのは早くても2014年の末である。
字数は，理由が37字で，制限の40字に収まる。“A-SSOシステムと連携した情報システム群”が“すべて”新しくなる，という二つの要素を入れる。f は年だけを答える。
設問5(2)
解答欄1つ
本文中のg に入れる適切な理由を45字以内で具体的に述べよ。
〔g〕解答例
A-SSOシステムが稼働するサーバマシンのベンダサポートが2012年末で切れる
解説
本文の根拠
表
・インフラ系のサーバマシン群のベンダサポートは2012年末に終了する(注1)。
〔移行計画の策定と実施〕
なお，A社では，ハードウェアの故障などのトラブルの発生が増えるのを避けるため，リース契約の延長は行わない。
表
注(1) A社では，ベンダのサポートが終了する前に，情報システムをリプレースすることになっている。
g は“A-SSOシステムが稼働するサーバマシンのベンダサポートが2012年末で切れる”である。A-SSOはインフラ系に含まれ，インフラ系のサーバマシン群のベンダサポートは2012年末に終了する。
本文は，A-SSOの廃止が可能になるのは2014年の末より前にはならないが，それまでは継続利用しようと考えたとしている。しかし，A社は，ハードウェアの故障などのトラブルが増えるのを避けるためリース契約を延長せず，ベンダのサポートが終了する前に情報システムをリプレースする決まりである。そのため，2012年のインフラ系のリプレース時に，A-SSOも新しいサーバマシンに入れ替えておく必要がある。
字数は39字で，制限の45字に収まる。“リース契約を延長しない”だけでなく，“ベンダサポートが2012年末で切れる”という期限まで書く。設問は“理由”なので，ベンダサポートの期限を根拠にする。
出典：平成22年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問2（表記を一部改変）
