平成18年度テクニカルエンジニア情報セキュリティ午後U問題 (問1)
問1 システム統合時におけるアクセス制御の設計に関する次の記述を読んで,設問1〜3に答えよ。
X杜は,従業員数500名ほどの中堅エレクトロニクス関連総合商社である。X社では,これまでエレクトロニクス製品を扱うEL事業部と,コンピュータハードウェア関連製品を扱うIT事業部とで,事業を展開してきた。今後は,事業の強化・拡大と社内体制強化という二つの方針に従って,より一層の躍進を目指すことにした。
事業の強化・拡大の具体策として,ソフトウェア開発・販売会社のZ社を買収し,SW事業部とした。
社内体制強化の施策の一つは,社内における人材の有効活用である。このために,各事業部の人事担当者を集約して本社管理部人事グループとし,事業部の枠にとらわれずに全社的見地から人材活用を図ることにした。併せて,人事担当者と同様に各事業部に所属していた経理担当者,総務担当者を集約してそれぞれ経理グループ,総務グループとし,人事グループとともに統合して本社管理部とした。X社は,EL,IT,SWの3事業部と,本社管理部から構成されている。
社内体制強化のもう一つの施策は,重複している情報資産の排除及び集約化である。事業部ごとに構築してきた情報システムを見直して重複をなくすとともに,情報を集約して有効に共有するため,システムの統合を行うことになった。また,各事業部で管理してきた顧客情報も,全社的なビジネス戦略推進の観点から,本社管理部で集中管理することになった。
システムの統合において考慮すべき点は,昨今の情報漏えい事件などを踏まえ,機密情報の管理をこれまで以上に徹底することである。そこで,システム統合における最も重要な要件として高度なアクセス制御機能が必須と判断された。そしてシステム統合を担当する開発チームが組織され,検討が始まった。
〔情報セキュリティ基本方針及び対策基準とシステム要件〕
SW事業部の設置をきっかけに,X社ではセキュリティ強化のため,情報セキュリティ基本方針及び対策基準の見直しを行った。図1に示すように,改定後の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. |
機密情報資産以外の情報資産へのアクセス可否は,利用者の必要度に応じて情報資産の所有者が与えたアクセス権によって判断する。
|
(以下,省略)
|
システム統合の対象である,EL事業部,IT事業部及びSW事業部の人事管理システム,顧客管理システム及び文書管理システム(以下,これらを業務システムという)は,この情報セキュリティ基本方針及び対策基準に準拠して,再構築及び運用されることになった。
IT事業部の人事管理システム及び顧客管理システムのアプリケーションプログラムは,Y社に委託して開発されたもので,人事情報及び顧客情報は関係データベース(RDB)に格納されている。
EL事業部及びSW事業部の業務システムは廃止し,EL事業部及びSW事業部の人事情報,顧客情報,ソフトウェアの設計資料などの文書はIT事業部の業務システムに移行する。移行後のIT事業部の業務システム(以下,全社業務システムという)は,図2に示すように全社で利用する。

全社の人事情報を本社管理部で一括して管理することになったが,人事権及び人事管理の責任は各事業部に帰属するという方針は,従来と同様である。人事管理システムは,この方針を維持しつつ,システム統合後も本社管理部の業務が円滑に行われるようなアクセス制御が必要となる。
文書管理システムは,従業員がPCで作成した,新製品などの企画文書,設計書,図面ファイルなどの文書を保管する。これらは,システム統合前は各事業部で維持・管理されていたが,システム統合後は,図1に示したX社情報セキュリティ基本方針及び対策基準に準拠して管理されることになる。
〔人事管理システムのアクセス制御の設計〕
X社開発チームから,システム統合の計画作成と実施を依頼されたY社では,セキュリティエンジニアのH氏が後輩のG君を指導しながら,人事管理システムのセキュリティを設計することにした。次は,そのときのG君とH氏の会話である。
H氏: |
システム統合のために,EL事業部,SW事業部及び本社管理部の人事情報を,IT事業部のRDBに移行することになる。表1は,X社開発チームが設計中の新人事情報データベース(以下,人事情報DBという)の表のサンプルイメージだ。まずは,何をすべきか検討していこう。
|
表1 人事情報DBの表のサンプルイメージ(抜粋)
従業員名 |
性別 |
従業員番号 |
事業部/部 |
グループ |
役職 |
スキル |
考課 |
本給 |
交通費 |
… |
高橋 美保 |
女 |
2002027 |
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,800 |
… |
田中 和子 |
女 |
1993002 |
本社管理部 |
経理 |
課長 |
− |
B |
360,000 |
156,000 |
… |
山本 一郎 |
男 |
2001028 |
SW |
業務SW |
主任 |
AD |
B |
330,000 |
72,800 |
… |
佐々木 勝 |
男 |
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 ]の原則を徹底するためには,人事管理システムの〔1〕運用体制を含めて考えなければならないな。次に,業務APについては,どのようなことに注意すべきかね。
|
G君: |
例えば,本社管理部の人事グループの人材管理担当者が,SW事業部からの要請でセキュリティ技術をもった人材を探す場合には,スキルやグループの情報にアクセスする必要がありますが,給与担当者の場合には,本給や交通費など業務に関係する情報だけを参照できれば十分です。RDBでこのようなアクセス制御を行うには,どんな方法があるのでしょうか。
|
H氏: |
RDBの利用者ビューを効果的に利用すれば,業務APへの依存度が低いアクセス制御が可能になると思うよ。つまり,DBを設計するとき,アクセス制御についても十分に考慮しなければならないというわけだ。
|
G君: |
なるほど,業務APの利用者が必要とする表,又はその一部の[ b ]だけで構成された利用者ビューを作成するのですね。
|
H氏: |
そのとおり。加えて,X社の人事管理方針では,例えば各事業部長は自事業部に所属する従業員の情報だけにアクセスできるように制御する必要がある。このような業務要件に対しては,どういう設計をしたらよいか検討してみよう。
|
G君: |
技術的には,表内の[ c ]単位で制御可能な関係データベース管理システム(RDBMS)に切り替えることも選択肢の一つですが,今回のシステム統合ではRDBMSは変更しない方針です。あるいは,〔2〕RDBの設計でも対応できると思います。この場合,表と利用者ビューは,利用者の業務要件を満たすように設計します。利用者が人事情報DBへアクセスする場合には,この利用者ビューだけが利用可能となるように制御すれば,[ a ]の原則が徹底できると思います。
|
H氏: |
そのとおりだね。結論としては,データベース設計にまで踏み込んだ議論が必要なので,X社開発チームと協議しながら設計を進めていこう。
|
〔文書管理システムのセキュリティ要件の検討〕
次に,H氏とG君は,文書管理システムのセキュリティ要件の実現について技術検討を行うことにした。
G君: |
文書管理システムは新製品などの情報も保持することになるので,データの完全性よりも機密性に重点を置いた対策が必要ですね。
|
H氏: |
文書管理システムでは,RDBMSを使わずに,OSファイルとして情報資産を保持することになる。一般のOSのアクセス制御機能で,X社の情報セキュリティ対策基準を満たすことが可能かどうか考えてみよう。
|
G君: |
一般のOSでは,ファイルに対する操作権限として,参照,書込み,実行などのアクセス制御が可能なので,これらを適切に利用すればX社で必要とする機密保護は達成できると考えています。
|
H氏: |
そうだろうか。一般のOSでは,ファイルに対してアクセス制御を行っているだけなので,OSのアクセス制御機能だけでは足りないと思うよ。
|
G君: |
具体的には,何が足りないのでしょうか。
|
H氏: |
一般のOSでは,基本的にはファイル識別とファイルアクセス者の利用者IDに基づいてアクセス制御を行う。アクセス制御のルールはアクセス制御リストなどに保持されるが,このリスト管理はファイル所有者が行う。
|
G君: |
ファイル所有者の裁量によってアクセス権が規定されるので,アクセス制御と呼ばれているのですね。でも,何が問題なのですか。
|
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事業部ゲーム |
企画案 |
最高機密 |
市場調査結果 |
秘密 |
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製品開発プロジェクトを示します。
|

H氏: |
B製品開発プロジェクトの“販売戦略”に書き込むために必要な利用者のアクセス区分のラベルはどうなるのかな。
|
G君: |
その場合には,([ h ],[ i ])が必要です。
|
H氏: |
D製品開発プロジェクトとF製品開発プロジェクトを統括する責任者P氏は,情報資産を参照し,情報資産に修正などが必要であれば,作業担当者に書込みを指示することになる。必要最小限の権限だけを与えるには,どのようなアクセス区分のラベルをもっていればよいのか。
|
G君: |
統括責任者P氏には([ j ]:(D製品開発,F製品開発))が必要です。
|
H氏: |
例えば,〔3〕X社開発チームのシステムエンジニアであるQ氏がF製品の“画面設計書”のレビューを実施するとしよう。レビュー時に必要な情報資産にアクセスするためにはアクセス区分のラベルはどうなるのかね。Q氏に対しては,参照した“画面設計書”に修正コメントを書き込めるようにラベルを付与する必要がある。
|
G君: |
その場合には,([ k ],[ l ])が必要になります。
|
H氏: |
分かった。これで,X社情報セキュリティ対策基準を反映したアクセス制御の基本的な設計はできたようだ。
|
H氏は,顧客管理システムについても同様の設計方針で作業を進め,X社の要求どおりのセキュリティ対策を実現した。
設問1 人事管理システムのアクセス制御の設計について,(1)〜(3)に答えよ。
(1) |
本文中の[ a ]〜[ c ]に入れる適切な字句を答えよ。
|
(2) |
本文中の下線〔1〕について,どのような体制を採るべきか。65字以内で具体的に述べよ。
|
(3) |
本文中の下線〔2〕の対応について,業務APの利用者に対するアクセス制御をどのように設計したらよいか。50字以内で述べよ。
|
設問2 文書管理システムのセキュリティ要件の検討について,(1),(2)に答えよ。
(1) |
本文中の[ d ]〜[ g ]に入れる適切な字句を,[ d ]及び[ g ]はそれぞれ2字以内,[ e ]は5字以内,[ f ]は4字以内で答えよ。
|
(2) |
X社情報セキュリティ対策基準において,機密情報資産に対するアクセス制御で用いる属性を,利用者ID以外に三つ挙げ,それぞれ5字以内で答えよ。
|
設問3 文書管理システムのアクセス制御の設計について,(1)〜(4)に答えよ。
(1) |
本文中の[ h ]〜[ l ]に入れる適切な字句を答えよ。
|
(2) |
カテゴリを本社管理部叉は事業部単位にすると,図1に示した情報セキュリティ対策基準に反することになる。その理由を35字以内で述べよ。また,その場合,どのようなセキュリティ上の問題が発生するか,60字以内で具体的に述べよ。
|
(3) |
B製品開発プロジェクトの,“製品仕様書”の取扱レベルを“取扱注”から“社外秘”に変更することにした。このときに必要となる一連の二つの処理について,それぞれだれが,どのような処理を行わなければならないか。処理の順に,“〜が〜する”という形式で,それぞれ55字以内で述べよ。
|
(4) |
本文中の下線〔3〕のQ氏に,F製品の“画面設計書”のレビュー完了後,追加で“処理記述”のレビューも実施してもらう場合,発生すると思われるアクセス制御上の問題と,その解決策を,それぞれ35字以内で具体的に述べよ。
|
|
|
スポンサードリンク
スポンサードリンク
|