テクニカルエンジニア（情報セキュリティ）過去出題問題

平成18年　午後2　問1

最終更新日　2006/07/01
webmaster@tomnetwork.net

Tomのネットワーク勉強ノート

　過去問（午後）

テクニカルエンジニア（情報セキュリティ）過去問（午前・午後）

テクニカルエンジニア（情報セキュリティ）過去問平成18年午後2 問1

問1 システム統合時におけるアクセス制御の設計に関する次の記述を読んで,設問1～3に答えよ。

　X社は,従業員数500名ほどの中堅エレクトロエクス関連総合商社である。X社で
は,これまでエレクトロエクス製品を扱うEL事業部と,コンピュータハードウェア
関連製品を扱うIT事業部とで,事業を展開してきた。今後は,事業の強化・拡大と社
内体制強化という二つの方針に従って,よリー層の躍進を目指すことにした。

　事業の強化・拡大の具体策として,ソフトウェア開発・販売会社のZ社を買収し,
SW事業部とした。

　社内体制強化の施策の一つは,社内における人材の有効活用である。このために,
各事業部の人事担当者を集約して本社管理部人事グループとし,事業部の枠にとらわ
れずに全社的見地から人材活用を図ることにした。併せて,人事担当者と同様に各事
業部に所属していた経理担当者,総務担当者を集約してそれぞれ経理グループ,総務
グループとし,人事グループとともに統合して本社管理部とした。X社は,EL,IT,
SWの3事業部と,本社管理部から構成されている。

　社内体制強化のもう一つの施策は,重複している情報資産の排除及び集約化である。
事業部ごとに構築してきた情報システムを見直して重複をなくすとともに,情報を集
約して有効に共有するため,システムの統合を行うことになった。また,各事業部で
管理してきた顧客情報も,全社的なビジネス戦略推進の観点から,本社管理部で集中
管理することになった。

　システムの統合において考慮すべき点は,昨今の情報漏えい事件などを踏まえ,職
密情報の管理をこれまで以上に徹底することである。そこで,システム統合における
最も重要な要件として高度なアクセス制御機能が必須と判断された。そしてシステム
統合を担当する開発チームが組織され,検討が始まった。

〔情報セキュリティ基本方針及び対策基準とシステム要件〕

　SW事業部の設置をきっかけに,X社ではセキュリティ強化のため,情報セキュリ
ティ基本方針及び対策基準の見直しを行つた。図1に示すように,改定後のX社情報
セキュリティ基本方針及び対策基準では,情報資産の情報区分をより細分化すること
によって情報の機密管理を強化している。

基本方針
　(省略)
　〔情報資産の取扱い〕
　1.情報資産は,資産価値や機密度に応じて適切な情報区分に格付けする。
　2.情報資産に対する情報区分の格付け責任者は,情報資産作成者の部門長とする。
　　(省略)

〔情報資産に対するアクセス制御〕
　1.情報資産は,情報区分及び利用者のアクセス区分に応じて適切なアクセス制御を実施する。
　2.情報資産に対する情報区分の権付けや利用者のアクセス区分の付与(変更を含む)と,情報区分と利
　　用者のアクセス区分のシステム設定作業は,別の管理者が実麓する。
　　(省略)

対策基準
　〔情報資産の情報区分〕
　1.情報資産の情報区分は,取扱レベルとカテゴリから構成する。
　2.情報資産の取扱レベルは,機密度の高い順に次の6段階に分類する。
　　　-最高機密,極秘,秘密,社外秘,取扱注,一般
　3."社外秘"以上の取扱レベルの情報資産は,機密情報資産とする。
　4.カテゴリは,情報資産が帰属する事業部,部.プロジェクトなどの業務遂行単位を識別するために付
　　与する情報資産の属性である。

　〔利用者のアクセス区分〕
　1.利用者のアクセス区分は,権限クラスと一つ以上のカテゴリから構成する。利用者には同時に一つ以
　　上のアクセス区分を付与できる。
　2.利用者の権限クラスは,情報資産へのアクセス権限の高い順に次の6段階に分類し,職務権限に応じ
　　て付与する。
　　　-クラス6,クラス5,クラス4,クラス3,クラス2,クラス1
　3. 利用者のアクセス区分中の各カテゴリは,利用者が情報資産へのアクセス許可を得るために必要とな
　　　る情報資産の情報区分のカテゴリを示すために付与する利用者の属性である。

　〔情報資産に対するアクセス制御〕
　1.各機器情報資産の取扱レベルと利用者の権限クラスは,“最高機密"クラス6","極秘"と"クラ
　　ス5","秘密"と"クラス4",“社外秘"と“クラス3"に,それぞれ対応させる。
　2.機密情報資産へのアクセス可否は,情報資産の情報区分と利用者のアクセス区分によって判断する。
　　具体的には次のアとイ,又は,アとウの基準に基づいてアクセスを許可する。
　　　ア.利用者のアクセス区分中のカテゴリと,アクセス対象の情報資産の情報区分中のカテゴリとが
　　　　　一致する。
　　　イ.情報資産にアクセスする利用者の権限クラスが,それに対応する情報資産の取扱レベルに等し
　　　　　いか高い場合だけ,参照アクセスを許可する。
　　　ウ.情報資産にアクセスする利用者の権限クラスが,それに対応する情報資産の取扱レベルに等し
　　　　　い場合だけ,書込みアクセスを許可する。
　3.機密情報資産以外の情報資産へのアクセス可否は,利用者の必要産に応じて情報資産の所有者が与え
　　たアクセス構によって判断する。　
　(以下,省略)

　図1 改定後のX社情報セキュリティ基本方針及び対策基準

　システム統合の対象である,EL事業部,IT事業部及びSW事業部の人事管理シス
テム,顧客管理システム及び文書管理システム(以下,これらを業務システムとい
う)は,この情報セキユリティ基本方針及び対策基準に準拠して,再構築及び運用さ
れることになった。

　IT事業部の人事管理システム及び顧客管理システムのアプリケーションプログラム
は,Y社に委託して開発されたもので,人事情報及び顧客情報は関係データベース
(RDB)に格納されている。

　EL事業部及びSW事業部の業務システムは廃止し,EL事業部及びSW事業部の人
事情報,顧客情報,ソフトウェアの設計資料などの文書はIT事業部の業務システムに
移行する。移行後のIT事業部の業務システム(以下,全社業務システムという)は,
図2に示すように全社で利用する。

図2　システム統合のイメージ

　会社の人事情報を本社管理部で一括して管理することになったが,人事権及び人事
管理の責任は各事業部に帰属するという方針は,従来と同様である。人事管理システ
ムは,この方針を維持しつつ,システム統合後も本社管理部の業務が円滑に行われる
ようなアクセス制御が必要となる。

　文書管理システムは,従業員がPCで作成した,新製品などの企画文書,設計書,
図面ファイルなどの文書を保管する。これらは,システム統合前は各事業部で維持・
管理されていたが,システム統合後は,図1に示したX社情報セキュリティ基本方針
及び対策基準に準拠して管理されることになる。

〔人事管理システムのアクセス制御の設計〕

　X社開発チームから,システム統合の計画作成と実施を依頼されたY社では,セキ
ュリテイエンジ二アのH氏が後輩のC君を指導しながら,人事管理システムのセキュ
リティを設計することにした。次は,そのときのG君とH氏の会語である。

H氏：システム統合のために,EL事業部,SW事業部及び本社管理部の人事情報を,
　　　IT事業部のRDBに移行することになる。表1は,X社開発チームが設計中の
　　　新人事情報データベース(以下,人事情報DBという)の表のサンプルイメー
　　　ジだ。まずは,何をすべきか検討していこう。

表1 人事情報DBの数のサンプルイメージ(抜粋)

従業員名	性別	従来員番号	事業部/部	グループ	役職	スキル	考課	本格	交通費	・・・
高構美保	女	2008027	IT	PC HW	主任	NW	A	300,000	64,500	・・・
伊藤学男	男	1989032	EL	パーツ	部長	DB	B	450,000	78,000	・・・
小林愛	女	2004024	IT	ディスク	副主任	SU	C	280,000	54,000	・・・
佐藤一志	男	2002048	EL	弱電	副主任	-	D	260,000	98,000	・・・
田中和子	女	1993002	本社管理部	経理	課長	-	B	360,000	156,000	・・・
山本一郎	男	2001028	SW	業務SW	主任	AD	B	330,000	72,000	・・・
佐々木勝	男	1990009	IT	SAN	課長	SV	C	410,000	113,200	・・・
加藤千恵	女	1994033	SW	ゲーム	主任	AD	B	370,000	84,500	・・・
・・・	・・・	・・・	・・・	・・・	・・・	・・・	・・・	・・・	・・・	・・・

G君：所属事業部の範囲内で検索できるように,人事情報DBをアクセスするプログ
　　　ラム(以下,業務APという)に機能を追加する必要があると思います。

H氏：そうだね。本社管理部の人事グループでは,事業部ごとに担当者が分かれてい
　　　るので,職務の必要性に応じたアクセス制御ができるようにすべきだね。

G君：はい。それ以外に,業務APの利用者だけでなく,システム管理者もRDBにア
　　　クセスすることを考慮して,設計を行う必要があると思います。

H氏：良い指摘だね。システム管理には様々な業務があるが,例えば,データベース
　　　管理とオペレーションの業務を同一の者が実施するのは,セキュリテイの観点
　　　からは適切な対応とは言えないね。【　a　】の原則を徹底するためには,人
　　　事管理システムの①運用体制を含めて考えなければならないな。次に,業務AP
　　　については,どのようなことに注意すべきかね。

G君：例えば,本社管理部の人事グループの人材管理担当者が,SW事業部からの要
　　　請でセキュリティ技術をもった人材を探す場合には,スキルやグループの情報
　　　にアクセスする必要がありますが,給与担当者の場合には,本給や交通費など
　　　業務に関係する情報だけを参照できれば十分です。RDBでこのようなアクセス
　　　制御を行うには,どんな方法があるのでしょうか。

H氏：RDBの利用者ビューを効果的に利用すれば,業務APへの依存度が低いアクセ
　　　ス制御が可能になると思うよ。つまり,RDBを設計するとき,アクセス制御に
　　　ついても十分に考慮しなければならないというわけだ。

G君：なるほど。業務APの利用者が必要とする表,又はその一部の【　b　】だけ
　　　で構成された利用者ピューを作成するのですね。

H氏：そのとおり。加えて,X社の人事管理方針では,例えば各事業部長は自事業部
　　　に所属する従業員の情報だけにアクセスできるように制御する必要がある。こ
　　　のような業務要件に対しては,どういう設計をしたらよいか検討してみよう。

G君：技術的には,表内の【　c　】単位で制御可能な関係データベース管理シス
　　　テム(RDBMS)に切り替えることも選択肢の一つですが,今回のシステム統合
　　　ではRDBMSは変更しない方針です。あるいは,② RDBの設計でも対応でき
　　　ると思います。この場合,表と利用者ビューは,利用者の業務要件を満たすよ
　　　うに設計します。利用者が人事情報DBヘアクセスする場合には,この利用者
　　　ビューだけが利用可能となるように制御すれば,【　a　】の原則が徹底でき
　　　ると思います。

H氏：そのとおりだね。結論としては,データベース設計にまで踏み込んだ議論が必
　　　要なので,X社開発チームと協議しながら設計を進めていこう。

〔文書管理システムのセキュリティ要件の検討〕

　次に,H氏とG君は,文書管理システムのセキュリティ要件の実現について技術検
討を行うことにした。

G君：文書管理システムは続製品などの情報も保持することになるので,データの完
　　　全性よりも機密性に重点を置いた対策が必要ですね。

H氏：文書管理システムでは,RDBMSを使わずに,OSファイルとして情報資産を保
　　　持することになる。一般のOSのアクセス制御機能で,X社の構報セキュリテ
　　　ィ対策基準を満たすことが可能かどうか考えてみよう。

G君：一般のOSでは,ファイルに対する操作権限として,参照,書込み,実行など
　　　のアクセス制御が可能なので,これらを適切に利用すればX社で必要とする機
　　　密保護は達成できると考えています。

H氏：そうだろうか。一般のOSでは,ファイルに対してアクセス制御を行っている
　　　だけなので,OSのアクセス制御機能だけでは足りないと思うよ。

G君：具体的には,何が足りないのでしょうか。

H氏：一般のOSでは,基本的にはファイル識別とファイルアクセス者の利用者IDに
　　　基づいてアクセス制御を行う。アクセス制御のルールはアクセス制御リストな
　　　どに保持されるが,このリスト管理はファイル所有者が行う。

G君：ファイル所有者の裁量によってアクセス権が規定されるので,【　d　】アク
　　　セス制御と呼ばれているのですね。でも,何が問題なのですか。

H氏：例えば,あるファイルを別のファイルにコピーするとしよう。元のファイルに
　　　対する参照権限と,コピー先ファイルヘの書込み権限があれば,ファイルのコ
　　　ピーは可能だ。つまり,ファイルの内容を別のファイルに移動することが可能
　　　となる。その結果,【　d　】アクセス制御の場合には,重要なファイルの内
　　　容が意図せず漏えいしてしまう可能性が出てくる。

G君：分かりました。では,どのような対応が必要なのでしょうか。

H氏：ISO/IEC 15408に基づいた,OS用プロテクションプロファイルの一つである
　　　Labeled Security Protection Profileによると,高度な機密保護のためには,
　　　【　e　】制御が必要であるとされている。

G君：なるほど。X社情報セキュリティ対策基準では,情報が取扱レベルの上位から
　　　下位の方向へ移動しないように【　e　】制御されているのですね。

H氏：そのとおりだ。X社情報セキュリティ対策基準では,情報資産の機密性を重視
　　　するため,取扱レベルが【　f　】以上の情報資産においては【　g　】ア
　　　クセス制御が必要となるね。

〔文書管理システムのアクセス制御の設計〕

　H氏は,文書管理システム用サーパのパラメタ設定はシステム管理者が行い,シス
テムの起動,停止やデータの移動を含むバックアップ作業はオペレータが行うなど,
運用業務の役割を明確に分割した。H氏は,サーバ側のアクセス制御を徹底するため
のシステム構成及び運用体制をX社開発チームに説明し,了解を得た。

　次にH氏は,X社開発チームから入手した資料を基に,機密保護対象の情報資産と
それぞれの取扱レベルを表2に整理し,アクセス制御の設計作業を進めた。

表2 情報資産と取扱レベル(抜粋)

業務遂行単位	主管グループ	サポートグループ	情報資産名	取扱レベル
A製品開発プロジエクト	EL事業部パーツ	-	資料	極秘
B製品開発プロジェクト	EL事業部OEM	IT事業部ディスク	販売戦略	秘密
			製品仕様書	取扱注
			説明資料	一般
C製品開発プロジェクト	SW事業部オフィス	-	企画案	社外秘
D製品開発プロジェクト	IT事業部サーバ	SW事業部CAD	処理記述	秘密
			DFD	取扱注
			クラス図	社外秘
E製品開発プロジェクト	IT事業部AV	SW事業部ゲーム	企画案	最高機密
E製品開発プロジェクト	IT事業部AV	SW事業部ゲーム	市場調査結果	秘密
F製品開発プロジェクト	SW事業部業務SW	IT事業部サーバ	E-R図	秘密
			画面設計書	社外秘
			処理記述	極秘
健康管理業務	本社管理部総務	-	検診結果	秘密
市場調査業務	EL事業部営業推進	-	調査結果	社外秘
特許管理業務	SW事業部知的資産	-	願書	最高機密
財務管理業務	本社管理部経理	-	財務データ	社外秘
・・・	・・・	・・・	・・・	・・・

G君：表2では,文書管理システムの情報資産が業務遂行単位ごとに整理されていま
　　　す。例えば,E製品開発プロジェクトはIT事業部AVグループが主管していて,
　　　SW事業部ゲームグループがサポートグループとして参画しています。このプ
　　　ロジェクトには,・企画案"と“市場調査結果"という2種類の情報資産があり,
　　　取扱レベルとしてそれぞれ“最高機密"と“秘密"が設定されています。

H氏：取扱レベルの異なる情報資産が存在する文書管理システムについては,システ
　　　ム構成を考えなければならないな。例えば取扱レベルごとにサーバを割り当て
　　　る方法と,複数の取扱レベルの情報資産を一つのサーバで管理する方法とがある。

G君：前者は簡単そうですが,X社情報セキュリテイ対策基準においても取扱レベル
　　　ごとにサーバを分離することまでは要求していないと思いますし,複数の取扱
　　　レベルを扱う利用者には使い勝手が悪いと思います。

H氏：そのとおりだが,X社情報セキユリテイ対策基準では,機密情報資産とそれ以
　　　外の情報資産では,扱い方を変えなければならないので,この違いに応じてサ
　　　―バを分けた方がいいね。

G君：分かりました。では,文書管理システムを,機密情報資産を管理するサーバ
　　　(以下,機密情報管理サーバという)と,それ以外の情報資産を管理するサー
　　　バ(以下,管理文書サーバという)の2種類で構成することにします。

H氏：では次に,機密情報管理サーバに適用する【　g　】アクセス制御では,機
　　　密情報資産の情報区分及び利用者のアクセス区分を表す,ラベルと呼ぶ識別子
　　　を使って【　e　】制御を行う。情報資産の情報区分や利用者のアクセス区
　　　分に変更が発生すると,ラベルに変更を加える必要が生じる。このラベルの表
　　　現形式を考えてくれないか。

G君：はい。早速ですが,二つのラベルのうち,利用者に付与するラベルについては
　　　(L：C)のように表現します。Lは利用者の権限クラスを一つ,Cはその情報
　　　資産へのアクセスを可能とするカテゴリをすべて列記します。この表現形式に
　　　従い,X社情報セキュリティ対策基準に基づいて,利用者のアクセス区分にラ
　　　ベルを付与します。例えば,"クラス4"の権限クラスをもつ利用者は,情報区
　　　分中のカテゴリがその利用者のカテゴリと一致した,“秘密"と"社外秘"の機
　　　密情報資産を参照できることになります。

H氏：情報資産の情報区分には,階層関係を示す取扱レベルのほかに,カテゴリもあ
　　　るので,これも設計してくれないか。

　G君の行ったアクセス制御設計をH氏がレピューし,内容を検証することになった。

G君：表3は,表2を基に機密情報管理サーパに配置する機密情報資産と情報区分の
　　　対応を整理したものです。縦軸は取扱レベル, 横軸はカテゴリを示しています。
　　　業務・プロジェクト名をカテゴリとしました。例えば,“A製品開発"はA製
　　　品開発プロジェクトを示します。

表3 機密情報管理サーパの機密情報資産と情報区分の対応(抜粋)

取扱レベル＼　カテゴリ	A製品開発	B製品開発	C製品開発	D製品開発	E製品開発	F製品開発	健康管理	・・・
最高機密	-	-	-	-	企画案	-	-	・・・
極秘	資料	-	-	-	-	処理記述	-	・・・
秘密	-	販売戦略	-	処理記述	市場調査結果	E-R図	検診結果	・・・
社外秘	-	-	企画案	クラス図	-	画面設計書	-	・・・

H氏：B製品開発プロジェクトの“販売戦略"に書き込むために必要な利用者のアク
　　　セス区分のラベルはどうなるのかな。

G君：その場合には,(【　h　】：【　i　】)が必要です。

H氏：D製品開発プロジェクトとF製品開発プロジェクトを統括する責任者P氏は,
　　　情報資産を参照し,情報資産に修正などが必要であれば,作業担当者に書込み
　　　を指示することになる。必要最小限の権限だけを与えるには,どのようなアク
　　　セス区分のラベルをもっていればよいのか。

G君：統括責任者P氏には(【　j　】：(D製品開発,F製品開発))が必要です。

H氏：例えば,③ X社開発チームのシステムエンジ二アであるQ氏がF製品の"画面
　　　設計書"のレビューを実施するとしよう。レビュー時に必要な情報資産にアク
　　　セスするためにはアクセス区分のラベルはどうなるのかね。Q氏に対しては,
　　　参照した“画面設計書"に修正コメントを書き込めるようにラベルを付与する
　　　必要がある。

G君：その場合には,(【　k　】：【　ℓ　】)が必要になります。

H氏：分かった。これで,X社情報セキュリティ対策基準を反映したアクセス制御の
　　　基本的な設計はできたようだ。

　H氏は,顧客管理システムについても同様の設計方針で作業を進め,X社の要求ど
おりのセキュリティ対策を実現した。

設問1　人事管理システムのアクセス制御の設計について,(1)～(3)に答えよ。

　(1)本文中の【　a　】～【　c　】に入れる適切な字句を答えよ。

　(2)本文中の下線①について,どのような体制を採るべきか。65字以内で具体的に述べよ。

　(3)本文中の下線②の対応について,業務APの利用者に対するアクセス制限を
　　　どのように設計したらよいか。50字以内で述べよ。

設問2 文書管理システムのセキュリティ要件の検討について,(1),(2)に答えよ。

　(1)本文中の【　d　】～【　g　】に入れる適切な字句を,【　d　】及
　　　び【　g　】はそれぞれ2字以内,【　e　】は5字以内,【　f　】は4
　　　字以内で答えよ。

　(2)X社情報セキュリティ対策基準において,機密情報資産に対するアクセス制
　　　御で用いる属性を,利用者ID以外に三つ挙げ,それぞれ5字以内で答えよ。

設問3 文書管理システムのアクセス制御の設計について,(1)～(4)に答えよ。

　(1)本文中の【　h　】～【　ℓ　】に入れる適切な字句を答えよ。

　(2)カテゴリを本社管理部又は事業部単位にすると,図1に示した情報セキュリ
　　　ティ対策基準に反することになる。その理由を35字以内で述べよ。また,その
　　　場合,どのようなセキュリティ上の問題が発生するか,60字以内で具体的に述
　　　べよ。

　(3)B製品開発プロジェクトの"製品仕様書"の取扱レベルを“取扱注"から
　　　“社外秘"に変更することにした。このときに必要となる一連の二つの処理に
　　　ついて,それぞれだれが,どのような処理を行わなければならないか。処理の
　　　順に,“～が～する"という形式で,それぞれ55字以内で述べよ。