----------------------------------------------------------------------

　（セキュリティ対策としてのアクセスコントロール設計について）

----------------------------------------------------------------------

----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
１−１．システムの概要
----
　Ａ社は大手のカード会社である。基幹系システムの一
部として、カード利用時の与信を行うサブシステムが存
在し、２４時間３６５日稼動している。近年のＩＣカー
ド普及に伴い、Ａ社もＩＣカードを発行することになり、
先行して基幹システム側の準備対応を行う事になった。

　与信サブシステムにおける要件の１つに海外イシュア
ー向け電文の暗号化対応がある。ＩＣカードの電文で、
機密性の高い情報は共通かぎ暗号方式により、暗号化し
た上で送受信する必要があった。このため、暗号化／復
号化の処理を新たに開発すると同時に、かぎファイルに
対して高いセキュリティが求められた。

　私はシステムベンダーの一員として、要件定義からこ
のシステムのアクセスコントロール設計に参画した。

----
１−２．アクセスコントロールの概要
----
　暗号化／復号化処理にはかぎファイル以外にも、かぎ
ファイルのバックアップやかぎファイルを更新するため
のバッチプログラム、暗号化／解読処理などが含まれる。
そのため、かぎファイルにアクセスする資産も含め、適
切なアクセスコントロール設計を行う必要があった。

　実装にあたっては、ベンダーで販売しているアクセス
コントロール用のプロダクトを使用することになった。
このツールはファイルやプログラムに対し、どのユーザ
ＩＤにどのような操作（読み込み、書き込み、削除、実
行）を許可するかをコマンドで設定する機能を持つ。
しかしながら、対象のファイル数が多いとＣＰＵ負荷が
大きくなるという欠点があり、ディレクトリ単位でファ
イルのアクセスコントロールを設定するよう工夫する必
要があった。

----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
２−１．設計したアクセスコントロールについて
----
　今回のアクセスコントロール要件において、私はまず
最も重要なかぎファイルへのアクセスを行うユーザＩＤ
を決めておく必要があると考えた。そしてユーザと共に
検討した結果、かぎファイルに対して権限の高い順に以
下３通りのユーザＩＤを設定することにした。

　１．かぎ所有者
　２．かぎ使用者
　３．上記以外

１は文字通りかぎファイルの所有者であり、かぎファイ
ルに対する全ての操作（読み込み、書き込み、削除）を
行う権限を持つ。それに対し２は、かぎファイルの使用、
すなわち読み込み権限のみ持つ。また、１、２以外のユ
ーザに対してはかぎファイルに対する全てのアクセスを
許可しない事にした。そしてかぎ所有者、かぎ使用者に
あたる新たなユーザＩＤを１つずつ割り当てる事にした。

　次に、暗号化処理におけるファイル、プログラムに対
して重要度のランク付けを行おうと考え、暗号化処理に
おける入出力関係を整理することにした。整理する方法
としては、情報処理技術者試験の問題で良くみかけたＣ
ＲＵＤ分析が有効ではないかと考えた。そこで、暗号化
処理の設計に携わっていたメンバーの協力も得て、全て
のファイル、プログラムを縦横に列挙した表を作成し、
発生し得るファイル操作（Ｃ、Ｒ、Ｕ、Ｄ）を埋めてい
った。そして、その結果をもとにして、各ファイル、プ
ログラムの所有ＩＤを前出３通りのユーザＩＤのうち、
可能な限り低い権限となるよう割り当てていった。例え
ば、かぎファイルを交換する夜間バッチ処理プログラム、
かぎファイルのバックアップファイルなどには、かぎ所
有者を所有ＩＤに割り当て、かぎを使って電文の暗号化
された箇所を復号するプログラム、及び復号プログラム
で参照のみに使用される設定ファイルには、かぎ使用者
を所有ＩＤに割り当てる、といった具合である。

　こうして得られた結果から、今度は逆に各ファイル、
プログラムに対し、前出３通りのユーザＩＤから、どの
ような操作を許可すべきかを決めていった。得られた結
果を分析したところ、そのパターンはファイルでは１２
通り、プログラムでは７通りに分類されることがわかっ
た。そのため、私は運用にあたってはそれらの権限パタ
ーンに番号を付け、ＲＤＢでＳＱＬを用いて行うセキュ
リティ設定に出てくるロールと同様の考え方で、効率良
く管理する方法が無いかを検討することにした。

----
２−２．運用上考慮した点
----
　２−１で設計したアクセスコントロールを運用してゆ
くのにあたって、以下の事が懸念された。

　懸案１．暗号化処理のメンテナンスによるアクセスコ
　　　　　ントロールの再設計、設定コマンドの再作成
　　　　　及び発行
　懸案２．アクセスコントロール対象ファイルの増加に
　　　　　よるＣＰＵ負荷の増大

　まず懸案１であるが、設計にあたって作成した権限パ
ターンの一覧表を作成してから、その結果をもとに権限
設定コマンドを作成するまでの作業を自動化できないか
と考えた。そして検討の結果、設計した内容をＰＣ上の
ＤＢソフトに登録し、登録内容をもとに権限設定コマン
ドのマクロファイル（テキストファイル）を生成するユ
ーティリティを開発することにした。また、登録した操
作パターンを表計算ソフトのファイルとして出力する機
能も付加することで、設計書修正作業の負荷についても
低減を図ることにした。さらに権限パターンに番号を付
ける際、拡張性を考慮し、単なる連番ではなく１０ずつ
カウントアップされた連番を付与することにした。この
ことにより、暗号化処理に小規模なメンテンスが行われ、
権限パターンの廃統合が起きた部分のみ間の番号を使用
することで、パターン番号の変更を抑える事が可能とな
った。

　懸案２に対しては、ファイルの権限パターンが１２通
りに分類されたことから、権限パターン毎に格納するデ
ィレクトリを分け、ディレクトリ単位でのアクセスコン
トロールを行う事にした。その結果、将来暗号化処理の
メンテアンスに伴い、アクセスコントロール対象のファ
イルが増加した場合も、アクセスコントロール設定によ
るＣＰＵ負荷がファイル数分増大するリスクが低減され
ると予想された。

----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
３−１．アクセスコントロール設計についての評価
----
　今回のアクセスコントロール設計にて実施した以下の
施策について評価する。

　１．実装すべきアクセスコントロールを洗い出すため
　　　のＣＲＵＤ分析の活用
　２．コマンド、設計書の自動生成ツール作成
　３．拡張性、システムへの負荷軽減を考慮したディレ
　　　クトリ単位での権限設定

　まず１については、ＣＲＵＤ分析がアクセスコントロ
ール設計において、最適解を見つけるための手段として
役立つことを発見できたことは、予想以上の収穫であっ
たと考える。また、２については、当初計画外の作業で
あったが、その後暗号化処理の開発中に何度か設計の見
直しがあり、その都度ユーティリティを利用してコマン
ドファイルや設計書を自動生成する機会があり、改めて
有用性を認識することができたと考えている。最後に３
であるが、予め１で権限パターンを丁寧に洗い出したこ
とが、ディレクトリ単位での権限設定実装につながり、
結果的にＣＰＵ負荷軽減に結びついたと考える。

----
３−２．今後改善したい点
----
　まず、ＣＲＵＤ分析から権限パターンの一覧表を作成
する作業も自動化を検討したいと考える。また、アクセ
スコントロール設計でユーザＩＤを新たに２つ作成した
が、割り当てる担当者をユーザ側で検討中であるため、
企業全体としてセキュリティが有効に働くよう、セキュ
リティ委員会等の専門組織を設け、利用者はそのメンバ
ーに限定する等の提案を行ってゆきたいと考える。最後
に、アクセスコントロール設計の事例は、まだ社内でも
少ないため、設計時におけるＣＲＵＤ分析の有効性や自
動生成ツールについて、事例として情報展開し、今後発
生するであろう類似案件の生産性向上に貢献したいと考
えている。