論文治療クリニック（外来2003）
[治療FILE2003-002患者名：さんしのごい氏・・・3回目の治療]

ごいさんが「分かりにくい」と評判？の論文を診せてくれることになりました。では、本人から一言いただきましょう。

Ｄｒ．エーロン様

こんばんは、さんしのごいです。

掲示板では、ひとぎきの悪いことを言ってしまい失礼しました。論文本文だけであれば、著作者は私だけであり、特に問題ないと判断しました。

というわけで、早速送らせて頂きます。

この論文は、山口ヒカルさんの診療所でも診てもらったようですね。院長は、その診立ては見ていません。ですから、純粋なドクターの診立てをしてみましょう。それでは、まず、問題から拝見。

Ｈ１３−問２　セキュリティ対策としてのアクセスコントロール設計について

　ネットワークの活用によって、様々な人が情報システムに容易にアクセスできるようになり、利便性が向上している。その反面、情報システムに対する脅威は大きく広がり、セキュリティ対策の重要性が高まっている。種々の脅威に対してセキュリティを確保するためには、アクセスコントロールを堅固にすると同時に、運用負荷を軽減する検討も必要である。
　セキュリティ対策のひとつであるアクセスコントロールの設計においては、権限のある人が、必要なときに、必要な情報を過不足なく利用できることが前提となる。
　そのためには、次のような事項を組み合わせて設計する必要がある。

　・入力、変更、検証、承認などの操作を行うときにユーザ自身が持つユーザ権限
　・データの重要度によるランク付け
　・業務の種類、内容によるユーザＩＤへの制限の付与

　さらに、アクセスコントロールは、一般にユーザ部門の専任の管理者又は組織によって運用されるので、組織変更や人事異動などに迅速かつ容易に対応でき、日常業務を円滑に遂行できるような設計も求められる。
　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

設問ア
　あなたが携わったシステムの概要と、アクセスコントロールの概要を、業務の特徴を踏まえて 800字以内で述べよ。

設問イ
　設問アで述べたアクセスコントロールについて、与えられた要件に基づき、どのような仕組みを設計したか、工夫した点を中心に具体的に述べよ。また、運用上どのような点を考慮したか、具体的に述べよ。

設問ウ
　設問イで述べたアクセスコントロール設計を、あなたはどのように評価しているか。また、今後改善したい点は何か。それぞれ簡潔に述べよ。

この問題は、「セキュリティ対策としてのアクセスコントロール」ですね。ドクターがずばり予想し、見事に当てたテーマでした。当時の予想と予想結果を参考に掲載しておきます。

●予想内容　●予想結果


では、まず、論文構成を考えましょう。

＜ドクターが考える論文構成＞

では、早速論文を拝見。

１−１．システムの概要

　Ａ社は大手のカード会社である。基幹系システムの一部として、カード利用時の与信を行うサブシステムが存在し、２４時間３６５日稼動している。近年のＩＣカード普及に伴い、Ａ社もＩＣカードを発行することになり、先行して基幹システム側の準備対応を行う事になった。
　与信サブシステムにおける要件の１つに海外イシュアー向け電文の暗号化対応がある。ＩＣカードの電文で、機密性の高い情報は共通かぎ暗号方式により、暗号化した上で送受信する必要があった。このため、暗号化／復号化の処理を新たに開発すると同時に、かぎファイルに対して高いセキュリティが求められた。
　私はシステムベンダーの一員として、要件定義からこのシステムのアクセスコントロール設計に参画した。

１−２．アクセスコントロールの概要

　暗号化／復号化処理にはかぎファイル以外にも、かぎファイルのバックアップやかぎファイルを更新するためのバッチプログラム、暗号化／解読処理などが含まれる。
そのため、かぎファイルにアクセスする資産も含め、適切なアクセスコントロール設計を行う必要があった。
　実装にあたっては、ベンダーで販売しているアクセスコントロール用のプロダクトを使用することになった。
このツールはファイルやプログラムに対し、どのユーザＩＤにどのような操作（読み込み、書き込み、削除、実行）を許可するかをコマンドで設定する機能を持つ。
しかしながら、対象のファイル数が多いとＣＰＵ負荷が大きくなるという欠点があり、ディレクトリ単位でファイルのアクセスコントロールを設定するよう工夫する必要があった。

２−１．設計したアクセスコントロールについて

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

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

１は文字通りかぎファイルの所有者であり、かぎファイルに対する全ての操作（読み込み、書き込み、削除）を行う権限を持つ。それに対し２は、かぎファイルの使用、すなわち読み込み権限のみ持つ。また、１、２以外のユーザに対してはかぎファイルに対する全てのアクセスを許可しない事にした。そしてかぎ所有者、かぎ使用者にあたる新たなユーザＩＤを１つずつ割り当てる事にした。
　次に、暗号化処理におけるファイル、プログラムに対して重要度のランク付けを行おうと考え、暗号化処理における入出力関係を整理することにした。整理する方法としては、情報処理技術者試験の問題で良くみかけたＣＲＵＤ分析が有効ではないかと考えた。そこで、暗号化処理の設計に携わっていたメンバーの協力も得て、全てのファイル、プログラムを縦横に列挙した表を作成し、発生し得るファイル操作（Ｃ、Ｒ、Ｕ、Ｄ）を埋めていった。そして、その結果をもとにして、各ファイル、プログラムの所有ＩＤを前出３通りのユーザＩＤのうち、可能な限り低い権限となるよう割り当てていった。例えば、かぎファイルを交換する夜間バッチ処理プログラム、かぎファイルのバックアップファイルなどには、かぎ所有者を所有ＩＤに割り当て、かぎを使って電文の暗号化された箇所を復号するプログラム、及び復号プログラムで参照のみに使用される設定ファイルには、かぎ使用者を所有ＩＤに割り当てる、といった具合である。
　こうして得られた結果から、今度は逆に各ファイル、プログラムに対し、前出３通りのユーザＩＤから、どのような操作を許可すべきかを決めていった。得られた結果を分析したところ、そのパターンはファイルでは１２通り、プログラムでは７通りに分類されることがわかった。そのため、私は運用にあたってはそれらの権限パターンに番号を付け、ＲＤＢでＳＱＬを用いて行うセキュリティ設定に出てくるロールと同様の考え方で、効率良く管理する方法が無いかを検討することにした。

２−２．運用上考慮した点

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

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

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

３−１．アクセスコントロール設計についての評価

　今回のアクセスコントロール設計にて実施した以下の施策について評価する。

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

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

３−２．今後改善したい点

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

他の患者さんはどう診ますか？診立てをしてみたい方はclinic@a-ron.netにメールで送付ください。（以下次回）

９月８日（月）さんしのごいさんの治療その３・・・その�A

ドクターです。早速、他の患者さんの診たてが届きました。トオルさんという方です。高度区分はじめてで、論文もはじめての患者さんです。ご自身の受験区分は「上級シスアド」ということなのですが、上級シスアドもAEも論文の基本は同じですので、一緒に治療して差し上げましょう。では、トオルさんのプロフィールなどを拝見。

はじめまして。トオルと申します。
「さんしのごいさんの論文の診立て」をお送りします。
まず、少し自己紹介をします。私は高度区分は未受験で、しかも受験予定区分が上級シスアドなので超初心者かつ技術のことは全くわからない患者です。

ですから、今回の投稿は「診立て」というのもおこがましく、率直な感想文とよんだほうが妥当かと思います。

さんしのごいさんの論文は、このホームページで拝見いたしております。とても書き慣れておられ文章も上手いので、私のような超初心者には非常に参考になります。他の患者さん方には私の記述内容のおかしい点について指摘していただけたら幸いです。
では、院長さん、さんしのごいさん、患者の皆さん、よろしくお願いします。

構成：設問に合致していると思います。

1−1：システムベンダーの一員というのはやや存在感が薄いように思いました。しかしこの表現の是非については私には判断できませんでした。AEの立場の勉強不足ですので・・。

1−2：業務の特徴を踏まえて、ときかれています。ですから、考慮点が必要となるような、業務がシステム設計へ与える困難な要件（人事異動が多いなど）について少し触れておいたほうがよいのではないでしょうか。論述内容をみると、単にシステム上の性能向上・ベンダー販売プロダクトの欠点に反応しているだけのように感じます。

2−1：CRUD分析を具体的に細かく記述されておられ、問題文の要件を忠実に再現されているように感じました。好感が持てると思いました。設問の「工夫点」という言葉には過去問題演習において毎回私も惑わされるのですが、記述内容を「工夫点」とみてもらえるのかどうかは私にもわかりません。院長さんに診てもらわないとなんとも言えません。

2−2：設問では「アクセスコントロールの仕組み運用の考慮点」ではなく「日常業務の運用が円滑に行われるための設計上の考慮点」をたずねているのだと思います。なので、懸案1,2の表現は「業務上の懸念事項」という内容にしてしまって、例えばその対応策がコマンドの作成、CPU負荷の軽減であることにしたらどうでしょうか・・（もちろん、「ユーザーでもメンテナンスしやすいシステム設計にし日常業務の負荷軽減を図った」という意味で捉えると設問に整合していると言えなくはないとは思いますが）。
どういうネタでくっつけるかは思いつきませんでした、すみません。

3−1：1.と2.については、自己（またはチーム）のスキルアップに対する感想のように読めました。できれば「設問イの施策は業務要件に対して有効に機能した」という内容が定量的におり込んであると、もっと読みやすいと思います。

3−2：今回のノウハウを後継のために体系化しておくことは、組織で働く技術者の姿勢として素晴らしいと思います。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
以上、観念的ではありますが（私の文章のウィークポイントです・・）感じたままに述べさせていただきました。

ふむふむ、なるほど。トオルさんは、なかなか熱心に自己治療を行っているようですね。では、細かく見ていきましょう。（以下次回）

９月１０日（水）さんしのごいさんの治療その３・・・その�B

ドクターです。では、論理的に治療していきましょう。トオルさんの指摘がどうなのかをすぐ指摘することもできるのですが、ここは、論文主張を明らかにした上で、ごいさんの論文とトオルさんの指摘の正当性を見ていくことにしましょう。では、主張チェック！（AE合格論文集調で）

（主張の前提・・・セキュリティ対策が重要）

　ネットワークの活用によって、様々な人が情報システムに容易にアクセスできるようになり、利便性が向上している。その反面、情報システムに対する脅威は大きく広がり、セキュリティ対策の重要性が高まっている。

（翻訳すると・・・）
ネットワークでつながったので、多くの人が簡単にシステムにアクセスできて便利になったよね。でも、ちょっと考えて。誰でも簡単にアクセスできるということは、漏洩のリスクも多くなったということじゃない。これは、何か対策しないとよくないことだよね。こんな状態は本当にまずいよね。だから・・・セキュリティ対策が重要になるんだよね。（この主張は、セキュリティ対策をやってよ！ということ）

（メイン主張・・・アクセスコントロールを堅固にし、同時に運用負荷を軽減すべき）

種々の脅威に対してセキュリティを確保するためには、アクセスコントロールを堅固にすると同時に、運用負荷を軽減する検討も必要である。

（翻訳すると・・・）

どこの馬の骨とも分からんやつの攻撃からシステムやデータを守るには、アクセスコントロールをしっかりやんないとあかんよね。でも、それだけじゃないよ。運用負荷も軽減しなくてはいけないよ。なぜなら、アクセスコントロールをいい加減にするのは簡単だけど、きつくするのは面倒だよね。面倒だと大変だから、運用作業もどうにか簡単にしとかないとやってられないよね。

(メイン主張の具体的説明1)

　アクセスコントロールの設計は
「権限のある人が、必要なときに、必要な情報を過不足なく利用できること」が前提。具体的には、以下の事項を組み合わせて設計すればよい。

　・入力、変更、検証、承認などの操作を行うときにユーザ自身が持つユーザ権限
　⇒入力できる権限のあるユーザか、変更できるユーザか、検証できるユーザか、承認できるユーザか。つまり、人の資格などのランクに応じた権限設定をする。
　
　・データの重要度によるランク付け
　⇒漏洩したら会社が窮地に陥る顧客生データや給与や人事評価データとどうでもよい郵便番号テーブルはランクが当然違う。

　・業務の種類、内容によるユーザＩＤへの制限の付与
　⇒たとえば、顧客生データを業務上扱う必要があるユーザとそうでないユーザは制限レベルが異なる。人事業務をしているユーザと工場の担当者もまったく使用するデータは異なる。

　　　　　　　　　　　　　　　↓
これらをどのようの設計したかを書く。

(メイン主張の具体的説明2)
　さらに、アクセスコントロールは、一般にユーザ部門の専任の管理者又は組織によって運用されるので、組織変更や人事異動などに迅速かつ容易に対応でき、日常業務を円滑に遂行できるような設計も求められる。

アクセスコントロールは、ユーザで設定変更するのが普通だよね。でも、組織変更や人事異動で、ユーザ権限が変わる前提だから、そのような場合は現場は大変だよね。大変じゃないように設計してあげるのがよいアプリケーションエンジニアだよね。

　　　　　　　　　　　　　　　↓
人事異動や、組織改正などアクセス権限が変更になる場合にも、あまり負担にならないよいに設計すべき、あなたはどう設計したのかの工夫を書く。

（問題）

設問ア
　１−１あなたが携わったシステムの概要
　１−２アクセスコントロールの概要を、業務の特徴を踏まえて

設問イ
　２−１設問アで述べたアクセスコントロールについて、与えられた要件に基づき、どのような仕組みを設計したか、工夫した点を中心に
　２−２運用上どのような点を考慮したか、具体的に述べよ。

設問ウ
　３−１あなたはどのように評価しているか。
　３−２今後改善したい点は何か。それぞれ簡潔に述べよ。

問題の開胸はこのあたりでしょうか。ここまでさばくと、回答論述やトオルさんの指摘がどうなのか大体分かるかも知れませんね。では、診断に入りましょう・・・（以下次回）

９月１６日（火）さんしのごいさんの治療その３・・・その�C
ドクターです。患者のごいさん本人から自己治療が来ました。ちょっと本人の自己治療ぶりをみて見ましょう。ではどうぞ。

Ｄｒ．エーロン様、トオルさん

こんにちは、さんしのごいです。

トオルさん、診立てを有難うございます。
私も論文のある区分は、まだ１つも合格していない１患者です。強いて言うと、今年に入ってから論文を読んだり書いたりするのが好きになりました（合格論文集も読み終えました）。

というわけで、同じ患者として頑張っていきましょう。

それで、現在治療して頂いている「分かりにくい」論文ですが、書いたのが約２ヶ月前ということもあり、患者として自己診断を行ってみました。

＜経験と題意が合っているか？＞

　今年から設問をもとに骨子を作成する方法を採用しているのですが、今回の論文を作成した際、どうもこの骨子がうまく作成できませんでした。
今思うと、なまじの経験に縛られ、すでに患部をかかえていた気がします。


　では、肝心の経験と題意が合っているか、ですが、結論から言うと設問で想定しているアクセスコントロールに比べ、かなり狭い範囲を対象としたアクセスコントロールを書いていると思います。

　前者は会社や組織のネットワーク全部を対象としたセキュリティポリシーであるのに対し、私の記述は与信システムの暗号化処理、電文の重要箇所や
共通かぎのセキュリティ確保に止まっています。
このため、権限設定も本来もっと色々な種類が登場して然るべきなのに、共通かぎを中心に考えた３種類に止まってしまいました。

　アプローチのしかたも、本来トップダウンが期待されるところがボトムアップとなってしまっています。

加えて言うと暗号化処理の設計段階でＣＲＵＤ分析が行われているのはあたりまえのことで、アクセスコントロール設計のために、ＣＲＵＤ分析を行いましたというのは変です。すでにあったものを活用しましたという方がベターでしょう。

　結論：出題の意図に比べると記述したテーマは範囲が狭い

＜この論文の今後の活用法＞

　実は現在悩んでいるのはここです。ＣＲＵＤ分析をもとにしたアクセス権限設定の割り出し、コマンドの自動生成といった構成要素は悪くないと思うのですが、全体が設問とずれているだけにどう扱うべきか悩みどころです。

１．ブラッシュアップして題意に合うものにする
　　（治療続行）
２．見切りをつける。構成要素は部品化し、別の論文に流用
　　（死亡宣告＆献体）

の２つが考えられます。１を行おうとするとテーマの見直しが必要で、できたとしても、それはすでに原型を止めない別物になってしまう気がします。というわけで、思い切って２とすべきと考えます。（時間もだいぶ少なくなってきたので・・・）

院長、トオルさん、いかがでしょう？

うーん、「死亡宣告＆献体」とは面白い表現ですね。ちなみに、ドクターは投稿された論文を、著作者の同意を得たうえで、書籍や論文塾のテキストに使ったりします。これには、失敗系と成功系がございまして、失敗文は死亡宣告＆献体という表現がぴったりかも知れないですね。他の患者に有効に利用されるという意味で。

ただ、今回のごいさんのやつは、補足説明が大量に必要なので、テキストには使いにくいですね。テキスト向けには、万人が分かるテーマが適しています。いいにせよ（合格レベル論文）、悪いにせよ（不合格確定論文）。では、トオルさんの意見があればいただくとして、なければ、そろそろまとめしょうかねえ。（以下次回）

９月２２日（月）さんしのごいさんの治療その３・・・その�D
ドクターです。トオルさんから意見がきました。

エーロン先生、さんしのごいさん

１．ブラッシュアップして題意に合うものにする
　　（治療続行）
２．見切りをつける。構成要素は部品化し、別の論文に流用（死亡宣告＆献体）

のどちらにするかという問いへの私の考え。

私は、ブラッシュアップできない論文はないと考えています。その適用範囲はもとの論文の素質によるのかもしれませんけれど。

今回の論文は、題意に沿うための視点を要所(章)ごとに書いて、あとアレンジすればエーロン先生のおっしゃる「成功系」になるはずだと思います。
結果、見た目上「見切りをつけ」たかのような出来栄えになったとしても、同じテーマを考えつづけたという意味では、ブラッシュアップされたと言えるのではないでしょうか。

しかしエーロン先生が、「ほとんど手直し不要な論文」以外は「失敗系」として見切りをつける論文であると定義するのなら、手厳しいですね。
だから論文試験は難関だということになるのでしょうね。

私もあれからずいぶんこの論文について悩みました。このサイトやAE参考書を読んで、題意を読み取れていなかったことに気付きました。
アプリケーションエンジニアは奥が深いです。ぜひエーロン先生の紐解きをお願いします。

「失敗系として見切りをつける」とは手厳しい。ドクターも治療可能なものはどんどんやりますよ。そういえば、三連星さんの意見も掲示板にありました。次回は、それも見て参考にしてみましょう。（以下次回）

９月２６日（金）さんしのごいさんの治療その３・・・その�E
ドクターです。では、三連星さんの見立てを掲示板から再掲しましょう。

さんしのごいさん論文の見立て　投稿者：三連星 　投稿日： 9月19日(金)22時51分50秒

え〜と、ウチの会社の論文対策の方法でやってみます。
設問ア、設問イをすっ飛ばして設問ウを最初に読むという方法をとります。
設問ウで書かれた内容を要約。
＞ＣＲＵＤ分析（等）の手法は有効であった。「でも、本業務では○○に問題があった。」
＞よって、今後は、○○に気をつけつつ、有効な手法は使い続けたい。
ストーりーとしてはマル。（「」の部分は書いてありませんがまあいいことにします）。
というのは、よくみかける別パターンの
＞＞Ｘシステムのアクセスコントロールは一応終わった。次は、以前から要望のあった○○機能を追加したい
というのよりはずっと評価らしい形態をとっているから。

でも、前フリには、
＞＞１．権限のある人が、必要なときに、必要な情報を過不足なく利用できる
＞＞２．組織変更や人事異動などに迅速かつ容易に対応できる
＞＞という設計が必要
とあります。これって実現できたのですか？書いてないです。
実現できたかどうかというのが、設問ウでいう評価に該当します。
他のこと（例えば、アクセスコントロール実装の工夫点）を書くなとは言わないけど、
少なくとも１．２．の片方を書いた（業務の特徴により、１．２．のいずれかが目玉
というのがありうるので、「少なくとも片方」になる。）後に書くべきです。
そして、１．２．を述べていないということは、設問イでは、１．２．の視点で書いていないだろうという想像が
はたらきます。設問ア、イを見る前に採点終わり。
実際、設問イでは、
　「実装」の工夫点ばかりを書いている
ので、　設問ウの記述内容からの予想通り、題意を外していることに。

もう１箇所。
＞情報処理技術者試験の問題で良くみかけたＣＲＵＤ分析が有効と考えた
試験問題は、オーソライズされた技術が主体だから、書くなら、
＞＞学会誌で紹介されていたＣＲＵＤ分析が有効と考えた。
です。
学会誌なら最新情報も載っているので、問題は無いでしょう。

三連星さん。ありがとうございました。設問ウから入るという手法はドクターにはないです。ドクターは設問ウはあまり重視しないもので、新鮮な感じがしました。では、指摘も出尽くした感もありますので、そろそろ締めましょうか。では、論文構成とごいさんの論文を比較する表を整理しましょうね。

表1:ドクターの論文構成表とごいさんの論文

では、設問ごとに説明していきましょうか・・・（以下次回）

９月２６日（金）さんしのごいさんの治療その３・・・その�F
ドクターです。では、続けましょう。

まず、論文で一番大事なことをここではっきり言いたいと思います。それは、問題文の主張にぴったりする事例を使い、設問に正しく解答すること。これが一番大事ということです。

今回のケースでは、以下の通りになります。

�@対象事例
　アクセス管理がいいかげんだと大きな問題になるようなシステム
　→具体的には、顧客情報を管理するシステムなどが書きやすい。

�A対象システムの業務形態とアクセス制御
　管理職、上級担当者、下級担当者が、それぞれ業務を分担するような形態。当然、それぞれは、必要とする権限が異なる。下級担当者は単なる入力、上級担当者はチェックなどの業務を行うので、権限が高い。また、管理職は承認を行うので、全てのデータの責任をもち、権限が高い。たとえば、データ入力者は、顧客情報を細かく参照する必要はないので、その権限は不要。上級担当者や管理職は、顧客情報を分析しマーケティングに利用したりする場合は、顧客情報を詳細にチェックする権限が必要。

　また、同じ組織の階層だけでなく、所属によっても必要な権限は異なる。経理部門は、顧客情報は不要だが、販売企画部門は顧客情報が必要となる。

これらは、通常、マトリックスの権限テーブルとして設計されることになります。こういうアクセス制御コントロールが必要なシステムが、今回のテーマでは書きやすく、ぴったりするものだといえるでしょう。

�B運用の観点
　上記のような権限マトリクスを作成し、維持していくためには、組織変更、人の異動（転勤）の際に、正しく見直すことが必要と主張しています。これを行うためには、人事異動や組織改正の際に的確に権限の付与、解除を行う必要があるといっています。なお、今回の問題の前提では、これらの作業は、「利用部門で行うので大変だから、そこに手間がないように設計しなければならない」と述べられています。つまり・・・

�@アクセス制御を行うためには、人や組織に権限を付与する。
　　　　　　　　　　　　　　　　　　　　　↓
�A組織改正や人事異動時のメンテナンスは、利用部門で実施するが、労力がかかる。
　　　　　　　　　　　　　　　　　　　　　↓
�Bこれは、大変なので、何かよい方法をシステムに組み込んで設計すべき

ということになります。これをシナリオに論文を展開し、正しく論旨転換すれば、必ず合格論文になると言えるでしょう。つまり、これが模範例なんです。これ以外の論文を書いて合格するかははっきり言って分かりません。しかし、他の受験者がぴったり論文を書いてくれば、そちらのほうが得点は高くなり、合格する可能性が高くなるのは明白です。出題側が、わざわざ「こう書いてほしい」と思って、問題文にヒントを与えているのですから。・・・では、これを意識して、ごいさんの論文を最終診断しよう。ファイナルチェック！

チェック１

まず、分かりやすいところからいきましょう。最も分かりやすい病巣は設問イの２です。ここは、最初に目に付くまずい点です。いわば、「悪性新生物」といったところでしょうか。

２−２．運用上考慮した点

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

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

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

＜病巣＞利用部門が、人事異動や組織改正時に行う作業の軽減策とは異なることが書かれていますね。

特に、懸案２は、まったく関係ないです。問題の意図とは違うことがかかれています。設問イの２は、利用部門の負担を軽減する方策を書くべきです。

ここでは、利用部門の運用ではなく、システム運用のことがかかれている印象を持ちます。それも、内容がよく分からない（分かりにくい）のです。細かすぎるのです。細かければ細かいほど、採点者には理解されにくいと思ってほしいです。

ここで実施したことはいいことかもしれませんが、採点者が期待している解答論述とは違うと思うし、上手く伝わらないと思います。「伝える」ということは、事実をそのまま書くということではないのです。ちょっと厳しい言い方かもしれませんが、ごいさん冷静に聞いてください・・・（以下次回）

１０月８日（水）さんしのごいさんの治療その３・・・その�G
ドクターです。では、他の指摘をします。

２−１．設計したアクセスコントロールについて

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

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

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

ここでは、かぎファイルとアクセスの関係を述べていますね。かぎファイルに対し、かぎ所有者、かぎ利用者、それ以外の３通りのアクセスランクを設定したということですね。これは題意に合っているといえるでしょう。

　次に、暗号化処理におけるファイル、プログラムに対して重要度のランク付けを行おうと考え、暗号化処理における入出力関係を整理することにした。

この表現がよく分かりません。「暗号化処理における入出力関係」という表現が、言葉足らずになっており、少なくとも私には分かりません。

整理する方法としては、情報処理技術者試験の問題で良くみかけたＣＲＵＤ分析が有効ではないかと考えた。そこで、暗号化処理の設計に携わっていたメンバーの協力も得て、全てのファイル、プログラムを縦横に列挙した表を作成し、発生し得るファイル操作（Ｃ、Ｒ、Ｕ、Ｄ）を埋めていった。そして、その結果をもとにして、各ファイル、プログラムの所有ＩＤを前出３通りのユーザＩＤのうち、可能な限り低い権限となるよう割り当てていった。

例えば、かぎファイルを交換する夜間バッチ処理プログラム、かぎファイルのバックアップファイルなどには、かぎ所有者を所有ＩＤに割り当て、かぎを使って電文の暗号化された箇所を復号するプログラム、及び復号プログラムで参照のみに使用される設定ファイルには、かぎ使用者を所有ＩＤに割り当てる、といった具合である。

この表現も意味がよく分かりません。

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

「〜効率よく管理する方法がないかを検討することにした。」で終わっていますね。その結果どうなったのでしょう？それが、２−２（運用の言及）につながると言うことでしょうけど、この２−１がよく分からないので、２−２も理解するのは大変です。ところで、この論文は、セキュリティ関係のかぎ管理の話なのですが、ドクターもかぎ管理は詳しくありません。しかし、詳しい、詳しくない以前の問題として、この論文は文章として、十分説明できていない箇所が多いのではないでしょうか。だから「分かりにくい」論文と評価されたのだと思います。もっと、何が問題で、どう考えて、何をしたのか理解してもらえる文章にしなくてはいけません。ごいさん　よろしいでしょうか。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（ごいさんの治療�B　分かりにくい論文　診断完了）

Copyright ©2000 ：2003　OFFICE A-RON all right reserved