PM2考察編・テンプレート化構想

前回の考察を受けての試みという事で、今回はPM１の過去問の内容を使って、
まずは、質問書と言われるテンプレート作成できるかやってみようと思います。

と、その前に、過去問の午後1と午後2のそれぞれの問題傾向（カテゴリ的なもの）を見てみようと
思います。
というのも、こういった対策本などに書かれているのは、午後2対策で論じるために必要なプロット
をその場で考えるのではなく、あらかじめいくつかの（多ければ多いほど良い）カテゴリに合った
サービス例をサンプルとして暗記するくらいで保持しておくと良いのだそうです。
また、これらサービス例は、モジュールと呼び、このモジュールをパーツとして分解して、題意に合う
パーツを差し替えるだけでその内容を後は論じるというか、予め想定されているサンプル例を論文
として記述すればよいのである。というものです。

”え？それって実際の自分の体験でなく、しかも過去問題の内容をパクッてるから、NGでは？”
って思われる真面目な（笑）人もいるかもしれませんが、実は僕も最近までそう思ってました。
しかしながら、本当に出題者がそんなところまで採点の対象にしてるかというと多分、Noでは
ないかと思われます。

色々と出題者のコメントなどを見る限り、そういうところはどうでもよく、如何に題意に沿って、
簡潔に論じているか？に尽きるように思われるからです。

そうだとしたら、究極は、全くの未経験者でも、その役になりきる事さえできれば、午後2も論じる
事ができる、つまり合格する可能性が十分にあると思われます。

ただ、注意すべきは、この考え方は、あくまでも、今の高度情報試験精度の中で通用する考え方で、
有名なPMP試験などはご存知かもしれませんが、少なからずともPM経験をしているだけでなく、その
携わった関係者（ステークホルダー）にも承認してもらえるような状況でないと受験ができないという
過酷な条件であれば、こういう”なり切り”だけでは、正体がばれて、結果、受験すらできない事にも
なりかねませんのでご注意を。

さて、話が結構脱線してきましたので修正。。。
え、と。そんなわけで、過去問のカテゴリ傾向を列挙。して、モジュール作成をしようかと思うのです（苦笑）
ちなみに、こういう考え方はあっても実際にモジュールの作り方とか書かれているようなのは、
みあたりませんでした。
先人の合格した人の体験記（を読むのは個人的に好きではないのですが向学のため仕方なくです）を見る
限り、このモジュールを駆使して自分の経験したサービスなどと合わせてるように見受けられましたが、
どういうモジュールを用意していたなどというのは概要程度はあっても、詳細なものはないように思え
ましたので、このブログで独学研究も含め、書き留めようと思います。

◆過去問における午後1と午後2の問題比較
ここで、とりあえず、過去5年間の午後1と午後2問題についての問題の出だしである、『××××　について・・・』
という　『ｘｘｘｘ』部分をまずは以下、表にまとめてみました。

表を作りながら、結構広範囲なキーワードだと感じましたが、
左の表で僕がやりたい事は、PM1でモジュールを作成するという事、
それと、PM2でのそれぞれの題意と、PM1で作成したモジュールが
当てはめること、もしくはまったくそのまま流用できるとは思えない
ので、モジュールを流用して組み合わせることができないか？など
の考察を行えればと思います。

と書いて、あぁなるほど、と理解できないかもしれませんが、
まずは、モジュールを作成するところから始められたらと。

また、モジュールには、当然先に記した、テンプレートにも
流用しないとおかしなことになるかもしれませんので併せて
テンプレートもセットで作成しようと思います。


◆過去問モジュール作成をするため　
まずテンプレートづくりとなりますね。

ちょっと、H21の午後1（PM1)問題の問1：キャパシティ管理からやってみようと思います。



H21/PM1-1のテンプレートを（注：あくまでも個人的に）作成してみました。

あ、これはどこでも書かれている事ですが、解答の選択肢の中には、分からない的なのもありますが、
かりそめにもあなたはITサービスマネージャであるなら、分からないのは問題と自覚する必要ありです。
つまり、これは出題者のトラップであり、この選択肢『分からない』は無視すべきです。

問題文中
・中堅の日用雑貨販売会社
・インターネット上で個人消費者向けに個人カタログを公開
・売り上げを伸ばすための宣伝チャネル強化のためにWebサイトシステム更新
より、

①サービスの名称（３０字以内）
→日用雑貨販売会社の個人カタログ公開Webサイトシステム（２７文字）

サービスが対象とする企業・機関
②企業・機関などの種類・業種（選択）
→情報サービス業

③企業・機関などの規模（選択）
（＊大規模経験のない人は見栄？を張ると整合性のバランスでバレてしまいそうです。
自分の体験位何と台数規模で書こうと思います）
→１０１～３００人

④対象業務の領域（選択）
→営業・販売

システムの構成
⑤システムの形態と規模（選択＆記入）
（＊問題内のシステム構成図より）
→Webシステム（サーバ約４台*1、クライアント約３００台*2）
*1：４台とは、DBサーバ、統合監視サーバ、APサーバ、APサーバ予備機
*2：３００台とは、③の回答に合わせるため、MAX数としただけ。

⑥ネットワークの範囲（選択）

→他企業・他機関との間

ITサービスの規模・形態
⑦ITサービスの利用者
文中：インターネット上で個人利用消費者向けに・・・
より
→個人

⑧ITサービスの利用者数
（＊まぁ普通これって⑤でのクライアント台数と合わせないとねぇ）
→約３００人

⑨ITサービス提供に携わる要員数
（＊まぁ普通これって⑤の規模と運用保守体制を想定した整合性を考慮すべきかと思われます。）
→約２人（が妥当かなぁと）

ITサービスマネジメントにおけるあなたの立場
⑩あなたが所属する企業・機関など（選択）
（＊個人的に他の選択肢は不適切な気がしますのでこれは固定でいいのではと思います。）
→ソフトウェア業・情報処理・提供サービス業など

⑪あなたの担当業務
（＊個人的に他の選択肢はITSMとして不適切な気がしますのでこれは固定でいいのではと思います。）

→運用・保守

⑫あなたが所属する部門またはチームの名称

文中よりこれ↓でいいんじゃないかと。

→Webサイト運用サービス（チーム）

⑬あなたの役割（選択）

（＊この場合、これ↓以下はマネージャより下なのでやはりもう固定でこれしかないと思います）

→部門マネージャ

⑭部門またはチームの構成人数＊

え～これには但し書きもあって、⑬の役割は部門の構成人数を記述するとの事

（＊まぁさすがに２人っていうのも寂しいですが（笑）、２人だと問題になるとも思えないので・・・）

→約２人（笑）

⑮あなたの担当機関

（＊この問題は２００９年なので、初めはそれくらいからにして、期間ですが・・・）

文中より

Webサイトシステムの稼働状況を２４時間365日体制で監視し、・・・・

とあるので、まぁ最初の契約は１年間で良いかなぁと・・・てきとうですいません（苦笑）

→2009年10月～2010年9月

以上。

という事で、どうでしょうか？テンプレート作成してみましたが、この記述がPM2の試験開始とともに

行わなければいけなく、これが既に制限時間の２時間のうちの時間内に含まれているのが要チェックです。

と、書いてるといつの間にか結構長くなったので、今回はこの辺で。

次回は、この感じで、過去５年間のPM１問題、合計２３問についてテンプレート作ってみようかと思います。

でわ。

PM2考察編・プロローグ

今回から高度情報試験の最後の砦と言われるPM2について、色々と
僕なりの研修や考察を行ってみようと思います。

◆ＰＭ２という砦を知る
まず、制限時間１２０分
そして、質問書と言われるテンプレートを記述。
で、問題はＨ２５年昨年からは２問から１問選択

つまりまずここで第一の関門が待っています。
割と軽く対策本で説明されているこの朱筆で書いたテンプレート
の記述は結構、相当、いや、かなり重要という点を自覚すべきです（少なくても僕は）。

というのも、このテンプレートは、PM２の時間中のどこでもよいが、
それでもここに記述するのを忘れたら完全にアウトという代物で、
この試験時間に少しでもここの内容について考えてしまってたら、
もう既に、不合格よりに傾いていると考えるべきです。

つまり！このテンプレートで費やす時間は無駄と考え、各質問に何も考えずにひたすら
機械的に書き、次の２セレ方式に移る時間を早くにすべきという事です。

とはいっても、適当ではダメなのです。
というのも採点者はこのテンプレートに沿って論じた内容を評価するからです。
（といっても実際にどうか知りませんが一般的な対策本に書かれていますので
恐らく多分そうなんでしょう）

では、このテンプレートの内容ですが、ざっと以下の通りです。

①サービスの名称　３０字以内で簡潔に！

サービスが対象とする企業・機関
②企業・機関などの種類・業種
③企業・機関などの規模
④対象業務の領域

システムの構成
⑤システムの形態と規模
⑥ネットワークの範囲

ITサービスの規模・形態
⑦ITサービスの利用者
⑧ITサービスの利用者数
⑨ITサービス提供に携わる要員数

ITサービスマネジメントにおけるあなたの立場
⑩あなたが所属する企業・期間など
⑪あなたの担当業務
⑫あなたの所属する部門またはチームの名称
⑬あなたの役割
⑭部門またはチームの構成人数
⑮あなたの担当機関

ここで、超重要なのは、上記で書かれた内容に沿って、
次のステップで選択する問題で論じた内容を評価するという恐ろしい事実です。

例えば、上記テンプレート⑬で当然どう考えてもＩＴサービスマネージャと書いてる
のに、論じた内容はマネージャから指示されて動いている人になってしまっていた
りしたら、もう完全にアウトってわけです。



そう、２問からの1問選択、２セレ方式を最初に適用！です。

◆制限字数に慣れ、そして攻略する方法を練る
まず、PM２、午後の第二試験は、PM1：第一試験を突破した人しか採点されないという
なんとも非情な（少なくてもPM１ダメでも一生懸命PM2論文書いた人にとってはそう思う）
決断を下されるという事実を知るべきです。

なんでこういう話を書くかというと、まずPM２での制限字数を越えて手で自書という、
当たり前であるが、これがまぁなんとも大変な作業だと実感するはずです。
しかもここまでしんどい目をしてもまるで採点されないなどもうなんか無駄な時間を
全身全霊使い切っている自分に情けなくなる

最初で一発合格する人はこういう気持ちはわからないのかもしれませんが、大半の人は、
この論文の制限字数に悩まされ苦しまされ、そしてようやくその字数に達した時の時間の
想定外の浪費を思い知らされ、気がつくと、心なしか腕がしびれてなんとなく手がだるく感じ
そうしているうちに周りの人のカン、カン、カン！という紙に書かれている音が、気になって
きた場合、もしかしたら、もう論文を書く作業から逃げ出したくなっているのかもしれません。

僕の場合、最初は無謀にも軽く対策本読んだだけで、特に訓練もせず、何の準備もなく、
結果、ほとんどこの制限字数に達する事が出来ずに自爆して大敗を喫していました。
しかも字数に達していない原因は、途中で書いていたプロットを消したりしているうちに・・・
というケースであるという事も視野に入れ、当然この字数制限という砦対策を考えるべき
と思います。

◆よくあるＰＭ２対策本に書かれているセオリーを知る
これはどの対策本にも書かれている、
①問題文からプロット（骨子）、章立てをし、段落（チャプター）、見出し分けを行う！
というものです。

例えば、問題で、超有名なパターンである設問アの場合、

設問ア　あなたが携わった　Ａ　と、Ｂについて８００字以内で述べよ。

というパターンが決まっているようです

設問アというのは、この問題全体が第1章という事で、

ここの『あなたが』を、『わたしが』に変えて、

Ａ　を第1章のチャプター１という事で、１－１、

Ｂ　を第１章のチャプター２という事で、１－２　とした場合、

論文のプロット（骨子）を、以下のように

１、Ａと、Ｂ
１－１　わたしが携わったＡ
１－２　Ｂ

という風にしてくださいといったような内容で書かれているのが大半です。
まぁそれくらい決まり文句であるのですが、大変なのはこの章で区切った
各チャプタ－内で論文を展開させる必要があるという事です。
で、この１章全体が８００字以内という事は、１－１、１－２の２つで８００字
以内なので、チャプター１つにつき４００字以内という事になります。

つまり、字数だけで言うと

１、
１－１
（４００字以内）
１－２
（４００字以内）

という事です。

また、設問アで注目すべき点は８００字以内、つまり、”以内”です。
この”以内”は、僕が考えるに、どれだけ短く、かつ簡潔にまとめて
論じるかにかかってくるのではと考えます。
なぜなら、設問イ、ウと違い、最大リミットはあっても最小リミットが
無いからです。

②シナリオ作成
これもよく書かれている事で、要は論文構成をしっかりと考えてから
問題用紙に書きましょう。というもののようです。

たしかにそういう事は納得できるのですが、論文構成をどこへ書くのかという
素朴な疑問と、シナリオってどういう風に書くのが良いかという事を気にします。

◆ところで、論文構成プロットってどこに書くの？
最初の疑問、どこへ書くかについては、まぁ紙の余白って事ですが、
実際の答案用紙を見てみると、３頁ある事はH25年の過去問から判明です。
まぁ僕自身は受けたので体験済みですが・・・

これは何が言いたいかというと、この３頁を有効に使って２問のうちの自分が論じていけそうな１問を選んで、先に述べたプロットに沿った構成の概要を簡潔にまとめてメモる必要があると思われます。

最初から１ページ目に何を、２ページ目に何を…という風に考えておけばここの有効な書き方ができてるのではないかと思うのです。などという話は今までどの参考書や対策本に書かれてなかったと思いますが、実際、一見つまらないことかもしれませんが、メモをどこに書くか、余白はどれくらいどの場所にあるかなどを前もって練習しておけば迷わなくてもよいのではと思うのです。
（僕はいつもこういうつまらない事で時間を取ったりしてしまうので特にそう思うのです）

で、どうやって有効活用するか考えてみます。

そこでふと、３頁の余白の３という数字に、問われている問題もア、イ、ウと３問である事に
気がつきます。
しかも、このア、イ、ウという問題の数は昔からずっと変わっていないので、恐らくこの数は固定
ではないかと思われます。
だとしたら、余白の１ページはアの構成を、２ページ目はイ、３ページ目はウという風にメモって行く方法（自称：プロット分割法）が実現できないか考えてみます。

通常、論文は全体の構成を書きだして、それからア、イ、ウ毎で論じていくのですが、
全体の構成も結果的にア、イ、ウの総称という事なので、うまく分割できないか考えてみます。

何か過去の例文でやってみたいので、次回過去問の模範解答でやってみたいと思います。

◆で、今回のポイントのおさらいです。

まずは、試験官が、答案用紙をまだ開けてはいけないという、あの（結構個人的には長く感じられる）沈黙の時間が破られる、『はい、はじめてください』の言葉とともに、すべきことがどれだけ効率よいかで論文2の出だしの時間を稼ぎつつ、冷静な正しい行動ができるか。という事です。

”はじめ”の合図で、真っ先に行う事は、当然ながら、名前や受験番号などを間違わずに書く事です。って当たり前ですけど、最初にこれをやるって考えておくことは重要だと思います。
なので、
１、名前、受験番号などを書く

そして、次ですが、前述のとおり結構重要なポイントである、
２、質問書と言われるテンプレートを記述

ですが、もちろん、この内容も多少言い回しが違っても上記の通りと思われるので、
最初から暗記するくらいのレベルで何も考えずに機械的に書いて行く事が重要かと思われます。
なので、このテンプレートも、次回僕なりに考えてみます。
え？経験があまりないので書けないって？？？
はい、恐らくそんな人はたくさんいると思われますが、この試験の凄いというか恐ろしいというか、
まぁ経験者にとっては無免許運転できてしまうの？って感じですが、架空の状況を作っておき、自分がどれだけその架空のシステムにITサービスマネージャ（以下ITSM)として携わったかのなりきり度合いが高いならば、十分この試験合格の可能性があるという事になるようです。
ちょっとITSMいう、しかも主役を与えられた役者と思えばよいかも（苦笑）

次回はそういう観点で、やったことないシステムを過去問などでなり切ってみようかと（笑）
え？問題選んでもないのにそんな博打なことして大丈夫かって？
たぶん大丈夫です。だって、どんな問題でもそのシステムを携わったITSMとしての考え方を問題にしているはずなので、その題意に合えば問題ないと思われるからです。

で、次にする事ですが、、、まぁ当然、
３、２セレ方式

で、上記の通り２問からの1問選択です。そして忘れずに選択番号を問題用紙にマークです。
で、この方式の方法ですが、２問とも、”××××××について”と書かれており、
自分ができそうかどうかの判断は、その前の、”××××××”部分のキーワード
を見ながら論じそうかどうかを直観で考えて選ぶ必要があると思われます。

もちろん、直観で選んでしまうので、当たりはずれはないと言えばウソですので、
確実な方法があればよいのでしょうが、今の僕にはこれしか思いつかないので、とりあえず。

で、次は、ようやく
４、プロット分割法

で、設問ア、イ、ウを余白の３頁に分けて効率よく構成を書いて行ければと思います。

今回はこの辺で。
ではまた次回。

ITSM 心得帖・情報セキュリティ運用管理の心得。

さて、今回は情報セキュリティ運用管理です。

早速ですが、心得帖です。

という事で、今回は僕的には中々の問題でした。
で、Ｈ２２のＰＭ１問題全て完了となります。

さて、次回ですが、そろそろＰＭ２の研究序説という事で
色々と僕なりに考察を加えていこうかなと思う次第です。

まぁ、もちろんＰＭ１も視野に入れながら、ＰＭ１，ＰＭ２の
纏め勉強ブログにしていけたらと思います。

でわ。

僕流・高度情報処理試験・勉強日誌～ITSM（題意考察編１２）！！ H22/問4を振り返りながら

突然ですが・・・
残暑お見舞い申し上げます。

という事で、はい、今回の問4を振り返ってみようと思います。
まず、問4のキーワードは、セキュリティ管理における脆弱性検査。
でした。

いつもの通りＩＴＩＬ２０１１に当てはめてみようと思います。

サービスデザインプロセスに位置する場所の☆情報セキュリティでした。
で、この問題について、出題者は以下のような所感を残しています。
（記述内容は僕なりの簡易癇癪も含みます）

本問では、ＩＴサービスマネージャとして、情報セキュリティ上の問題について、
・リスク軽減の対策を行う能力
・アクセス管理のための技術的方策を策定する能力
などの実務能力を問う。

との事です。

またコメントではこの問4、全体として正答率が高かった・・・って、えぇっえぇえ！ほ、本当ですか？
少なくても僕にとっては取っ付きにくかったのですが、一般にはそうでもなかったようです。うぅ・・

まぁ気にせずに、設問1から振り返りです。

■設問1の題意

コメントを見ると、セキュリティ要件が理解されているかを見たかったような事を書かれている。
また、本問はアカウントの管理についての脅威を想定したセキュリティ要件の一般的な知識として回答を求められており、いつものようなリードバック法などではなく、もっと己が知識を書けばよかったというオチのようです。
なので、まぁそういうあぁこれは知識で書けばいいのかな？的な考えで回答した人の正答率が圧倒的に多かったという事なのかなと思います。
ちょっといやらしい目で見ると、正答した人たちは本当に、あぁこの問題の回答は本文中に書かれていないなと判断して書いたのかって事ですが、まぁそれはともかく、アカウントに関する一般的な脅威を想定したセキュリティ要件の内容であるという事のようですので、これは後ほど心得に纏めておこうと思います。

◆一応簡単に書くと、アカウントの管理に対する想定脅威によるキーワード
①不正利用した個人の特定
②退職者のアカウントの不正利用
③管理者による不正利用
④第三者のなりすましによる不正利用
です。

◆ログの管理場所
次の設問（２）は、ログの適切な格納場所を問うています。
場所はなんとなくわかるけどその理由は・・・・となった時に、この設問は知識で解答してはいけないのです。
システムのログを保存する場所はなぜそこなのかについては、システムを構築するうえでの様々な環境による理由を考慮すべきであるという事を言われている感じです。
つまり、今回の問題でのシステム環境の要件は、ログの管理という意味ではやはりセキュリティ要件に書かれている内容通りの場所だからという風に解答しなくてはいけなく、そういったセキュリティ要件を踏まえてログの保存場所を考えていますか？という題意も含まれていると思われます。

アカウントの管理同様、ログの管理もセキュリティ要件表が”要”という事のようです。

で、ログの管理に対する想定脅威によるキーワードは、
①ログファイルの改ざん
②サーバへの不正侵入や不正操作
とありますが、前の設問（１）は脅威を問うていましたが、今回の場合は、むしろその脅威に対する要件を問うています。

つまり・・・
①ログの改ざん　⇒　ファイルは外部から書き換えられないよう独立したサーバに集約
②サーバへの不正侵入や不正操作　⇒　ログは一定期間保存し、定期的に分析
という事で、今回の保存場所に関係した部分は①と推定。

こういったところからなぜその場所なのか？という解答にたどり着くのですが、
ＩＴサービスマネージャーたるもの、セキュリティ要件を考慮すべきという心得を忘れないでという事のようです。

◆設問2からセキュリティインシデント

■初回ログイン時のパスワード運用の心得。
今回のようにセキュリティ要件を考慮し、万全の体制を敷いたつもりでもインシデントが発生しました。まぁ人は完璧でないという事ですかねぇ。ｌ。
でもここでの題意は、初期パスワードについての運用が甘かったために起ったもので、早急な解決策を考える事ができるか？という事のようです。
初期パスワードはそのままアカウント付与依頼書上に書かれてしまい、誰でも見れるから、変更すべきといった当たり前のべき論をここで展開するための知識を活用する必要があるようです。

知識で解答しないと、強制的に初期パスワード変更させるためによくやる、初回ログイン時のパスワード変更メッセージを表示させて、ユーザが、仕方なく面倒でも変更するしかない、しかも忘れたら、基本的にリセットするしかないという運用が一般的のようで、まぁそこまで解答は要求されていないので、単純に初回ログインと、強制する、のキーワードがポイントだったようです。

■退職者＝不要アカウント運用の心得。
セキュリティ要件表、アカウントの管理の想定脅威による要件は、速やかに削除すべし。
となっているので、まさかそれは遵守されているでしょ。という思い込みは危険という事ですね。

この思い込みについては、僕自信も結構痛切な経験がたくさんあります。
人はどうして思い込んでしまうと目に見えなくなってしまうのでしょう。
恐ろしいのは、思った事が実際にはそうでなくても頭の中では、もうその事が
現実に起こった、済んでしまった事になってしまってる事です。
今回セキュリティ表に書かれているので、特にこの事は守られており、
その他に、表に書かれていない事が問われている事かな？などと思い込むと、
その瞬間！魔の手に捕まってしまっているという事です。

つまり・・・
セキュリティ要件表には正しくもっともな要件が順守すべき点として書かれていても、
１、それだけで十分とは限らない　⇒設問２（１）より
２、必ず守られているとは限らない。　⇒　設問２（２）より

という事がセキュリティホールにつながるという事を知る必要があるのです。

今回の場合、退職者の削除承認がすぐでも肝心の削除行為自体が、即座に行われていない事が
原因で、その要因は、即座と言いながら２週間のメンテ内の作業で削除実施となるという、まぁこういう書き方をすると、まったくのおかしい記述内容となるわけですが、この記述は、該当チャプタ〔トラブルの発生〕から、前の〔アカウントの管理〕内まで遡らないと判明しなく、知識で解答でないところが要注意です。

さらに解答としては２週間云々かんぬんはどうでもよくどのように変更するか？を簡潔に書く必要があるため、字数的にも、退職者のアカウントと、削除依頼時に即時削除、的なキーワードがポイントのようです。

■ログの管理の心得。
という意味では、保存場所が最初に考えられますが、その次に気を付けるべき点が、この設問２（３）におけるポイントとなるようです。
問題では、ログの取得が一部のＩＤでなく全てのＩＤに変更するとあり、どう考えてもログの取得容量が増えるよなぁ。と、考える基本的なフットワークは必要です。
で、このログの管理内容が書かれているのが、前のチャプタ〔ログの管理〕となります。

ここでのポイントは、
①特権ＩＤを使用した操作・・・・記録。
②オーバーラップ方式で記録
③セキュリティ要件で規定された期間中は保存

②のオーバーラップ方式というのを、一応ググりました。
オーバーラップとは、上に重ねる、重なるという意味で、ログファイルの重ねるとは、
古いログ情報を次の新しいログ情報で、いわゆる上書きされるという事。

つまり、ここでログの保存容量が懸念されるという事で、何を懸念するかというと、
③の期間中は保存されるべきという点が、期間内に上書きされてしまうと仕様から
逸脱されてしまう点を懸念するという事です。

という事で、まぁ確認すべき点はＨＤＤ容量大丈夫かって事になるわけですね。
題意としても、セキュリティ要件だけでなく、設計仕様も遵守されてるかを留意してる
か？いう事なのかと思いました。

■セキュリティ監査の指摘点
ここでも知識だけではだめで、まず書かれている指摘点
①アカウント付与および削除が円滑でない
②管理者自身の不正利用の見直し

これらに対する是正策
①アカウント付与や削除の流れを見直す
②複数の管理者（特権ＩＤ管理者と特権ＩＤ使用者）同士での不正利用出来ない工夫

となるようでした。
①は、派遣社員の契約を変更したため総務部長無関係になったところがポイントで、
いつも総務部長の担当作業のところで滞っていたため、それがなくなったという事実。、
この事が円滑な流れとなるという問題の構成から見ると、そんな難しくないのかもという
、まぁ結果論ですけど、思われました。

つまり、問題造る観点で言うと、
滞っている流れ、ここでは総務部長が遅いという点。を作る。
そのながれがなくなるために契約変更という事実を作ればスムーズな流れになるという点。

また点検するためには他のアカウント付与申請をする窓口担当側で、点検ネタを準備してもらうという、まぁここでは各位サーバ毎に登録しているアカウントで不要なものを点検のためにチェックしてもらうという泥臭い手作業をお願いする必要が出てきたというわけですが、、、

前に書き換えましたが、やはりもし僕がこのチェックを頼まれたら、この忙しいのに、面倒だな。もう少し他の方法で不要アカウントを判明する方法とかないのか？また手作業でチェックした場合の間違い、思い違い、聞き違い等々のケアレスミスが下で、別のインシデントが発生するような気がするのは僕だけでしょうか？
あまり良い方法とは思えないので書きますが、この設問の解答にはまったく関係のない余計な懸念点かもですが、実際はそんなに甘くもないと思われました。

さて、②は、なかなか秀逸な方法です。

管理者は、承認するための特権ＩＤは使えません。
もちろん特権ＩＤ使えるユーザは特権ＩＤ管理ＩＤは使えません。
この事より、
施策
①特権ＩＤ管理者は承認しかできないので、特権ＩＤ使って不正できない、
②特権ＩＤユーザが不正したら特権ＩＤ管理者側から発覚するので、まぁ盤石な体制です。

題意でも、不正利用させないための仕組みを理解できてるか？って感じですけど、仮にそのような知識はないとしても、セキュリティ要件表、アカウントの管理の管理者による不正利用に書かれている要件、承認者と行為者の職務を分離という、承認者は特権ＩＤ管理者で、行為者が特権ＩＤユーザという当たりと、この分離で不正を無くすためというと、

問われている、特権ＩＤ管理者のセキュリティ要件に適合させる施策でなければいけません。
そのため、上記施策②でなく①の事を書くと良いのです。

という事で、セキュリティ問題も、セオリーがあって”慣れ”なのかなと思いました。

次回は、今回書かれた心得を、例によって纏めてみます。

でわ。