残暑お見舞い申し上げます。
という事で、はい、今回の問4を振り返ってみようと思います。
まず、問4のキーワードは、セキュリティ管理における脆弱性検査。
でした。
いつもの通りＩＴＩＬ２０１１に当てはめてみようと思います。
サービスデザインプロセスに位置する場所の☆情報セキュリティでした。
で、この問題について、出題者は以下のような所感を残しています。
（記述内容は僕なりの簡易癇癪も含みます）
本問では、ＩＴサービスマネージャとして、情報セキュリティ上の問題について、
・リスク軽減の対策を行う能力
・アクセス管理のための技術的方策を策定する能力
などの実務能力を問う。
との事です。
またコメントではこの問4、全体として正答率が高かった・・・って、えぇっえぇえ！ほ、本当ですか？
少なくても僕にとっては取っ付きにくかったのですが、一般にはそうでもなかったようです。うぅ・・
まぁ気にせずに、設問1から振り返りです。
■設問1の題意
コメントを見ると、セキュリティ要件が理解されているかを見たかったような事を書かれている。
また、本問はアカウントの管理についての脅威を想定したセキュリティ要件の一般的な知識として回答を求められており、いつものようなリードバック法などではなく、もっと己が知識を書けばよかったというオチのようです。
なので、まぁそういうあぁこれは知識で書けばいいのかな？的な考えで回答した人の正答率が圧倒的に多かったという事なのかなと思います。
ちょっといやらしい目で見ると、正答した人たちは本当に、あぁこの問題の回答は本文中に書かれていないなと判断して書いたのかって事ですが、まぁそれはともかく、アカウントに関する一般的な脅威を想定したセキュリティ要件の内容であるという事のようですので、これは後ほど心得に纏めておこうと思います。
◆一応簡単に書くと、アカウントの管理に対する想定脅威によるキーワード
①不正利用した個人の特定
②退職者のアカウントの不正利用
③管理者による不正利用
④第三者のなりすましによる不正利用
です。
◆ログの管理場所
次の設問（２）は、ログの適切な格納場所を問うています。
場所はなんとなくわかるけどその理由は・・・・となった時に、この設問は知識で解答してはいけないのです。
システムのログを保存する場所はなぜそこなのかについては、システムを構築するうえでの様々な環境による理由を考慮すべきであるという事を言われている感じです。
つまり、今回の問題でのシステム環境の要件は、ログの管理という意味ではやはりセキュリティ要件に書かれている内容通りの場所だからという風に解答しなくてはいけなく、そういったセキュリティ要件を踏まえてログの保存場所を考えていますか？という題意も含まれていると思われます。
アカウントの管理同様、ログの管理もセキュリティ要件表が”要”という事のようです。
で、ログの管理に対する想定脅威によるキーワードは、
①ログファイルの改ざん
②サーバへの不正侵入や不正操作
とありますが、前の設問（１）は脅威を問うていましたが、今回の場合は、むしろその脅威に対する要件を問うています。
つまり・・・
①ログの改ざん ⇒ ファイルは外部から書き換えられないよう独立したサーバに集約
②サーバへの不正侵入や不正操作 ⇒ ログは一定期間保存し、定期的に分析
という事で、今回の保存場所に関係した部分は①と推定。
こういったところからなぜその場所なのか？という解答にたどり着くのですが、
ＩＴサービスマネージャーたるもの、セキュリティ要件を考慮すべきという心得を忘れないでという事のようです。
◆設問2からセキュリティインシデント
■初回ログイン時のパスワード運用の心得。
今回のようにセキュリティ要件を考慮し、万全の体制を敷いたつもりでもインシデントが発生しました。まぁ人は完璧でないという事ですかねぇ。ｌ。
でもここでの題意は、初期パスワードについての運用が甘かったために起ったもので、早急な解決策を考える事ができるか？という事のようです。
初期パスワードはそのままアカウント付与依頼書上に書かれてしまい、誰でも見れるから、変更すべきといった当たり前のべき論をここで展開するための知識を活用する必要があるようです。
知識で解答しないと、強制的に初期パスワード変更させるためによくやる、初回ログイン時のパスワード変更メッセージを表示させて、ユーザが、仕方なく面倒でも変更するしかない、しかも忘れたら、基本的にリセットするしかないという運用が一般的のようで、まぁそこまで解答は要求されていないので、単純に初回ログインと、強制する、のキーワードがポイントだったようです。
■退職者＝不要アカウント運用の心得。
セキュリティ要件表、アカウントの管理の想定脅威による要件は、速やかに削除すべし。
となっているので、まさかそれは遵守されているでしょ。という思い込みは危険という事ですね。
この思い込みについては、僕自信も結構痛切な経験がたくさんあります。
人はどうして思い込んでしまうと目に見えなくなってしまうのでしょう。
恐ろしいのは、思った事が実際にはそうでなくても頭の中では、もうその事が
現実に起こった、済んでしまった事になってしまってる事です。
今回セキュリティ表に書かれているので、特にこの事は守られており、
その他に、表に書かれていない事が問われている事かな？などと思い込むと、
その瞬間！魔の手に捕まってしまっているという事です。
つまり・・・
セキュリティ要件表には正しくもっともな要件が順守すべき点として書かれていても、
１、それだけで十分とは限らない ⇒設問２（１）より
２、必ず守られているとは限らない。 ⇒ 設問２（２）より
という事がセキュリティホールにつながるという事を知る必要があるのです。
今回の場合、退職者の削除承認がすぐでも肝心の削除行為自体が、即座に行われていない事が
原因で、その要因は、即座と言いながら２週間のメンテ内の作業で削除実施となるという、まぁこういう書き方をすると、まったくのおかしい記述内容となるわけですが、この記述は、該当チャプタ〔トラブルの発生〕から、前の〔アカウントの管理〕内まで遡らないと判明しなく、知識で解答でないところが要注意です。
さらに解答としては２週間云々かんぬんはどうでもよくどのように変更するか？を簡潔に書く必要があるため、字数的にも、退職者のアカウントと、削除依頼時に即時削除、的なキーワードがポイントのようです。
■ログの管理の心得。
という意味では、保存場所が最初に考えられますが、その次に気を付けるべき点が、この設問２（３）におけるポイントとなるようです。
問題では、ログの取得が一部のＩＤでなく全てのＩＤに変更するとあり、どう考えてもログの取得容量が増えるよなぁ。と、考える基本的なフットワークは必要です。
で、このログの管理内容が書かれているのが、前のチャプタ〔ログの管理〕となります。
ここでのポイントは、
①特権ＩＤを使用した操作・・・・記録。
②オーバーラップ方式で記録
③セキュリティ要件で規定された期間中は保存
②のオーバーラップ方式というのを、一応ググりました。
オーバーラップとは、上に重ねる、重なるという意味で、ログファイルの重ねるとは、
古いログ情報を次の新しいログ情報で、いわゆる上書きされるという事。
つまり、ここでログの保存容量が懸念されるという事で、何を懸念するかというと、
③の期間中は保存されるべきという点が、期間内に上書きされてしまうと仕様から
逸脱されてしまう点を懸念するという事です。
という事で、まぁ確認すべき点はＨＤＤ容量大丈夫かって事になるわけですね。
題意としても、セキュリティ要件だけでなく、設計仕様も遵守されてるかを留意してる
か？いう事なのかと思いました。
■セキュリティ監査の指摘点
ここでも知識だけではだめで、まず書かれている指摘点
①アカウント付与および削除が円滑でない
②管理者自身の不正利用の見直し
これらに対する是正策
①アカウント付与や削除の流れを見直す
②複数の管理者（特権ＩＤ管理者と特権ＩＤ使用者）同士での不正利用出来ない工夫
となるようでした。
①は、派遣社員の契約を変更したため総務部長無関係になったところがポイントで、
いつも総務部長の担当作業のところで滞っていたため、それがなくなったという事実。、
この事が円滑な流れとなるという問題の構成から見ると、そんな難しくないのかもという
、まぁ結果論ですけど、思われました。
つまり、問題造る観点で言うと、
滞っている流れ、ここでは総務部長が遅いという点。を作る。
そのながれがなくなるために契約変更という事実を作ればスムーズな流れになるという点。
また点検するためには他のアカウント付与申請をする窓口担当側で、点検ネタを準備してもらうという、まぁここでは各位サーバ毎に登録しているアカウントで不要なものを点検のためにチェックしてもらうという泥臭い手作業をお願いする必要が出てきたというわけですが、、、
前に書き換えましたが、やはりもし僕がこのチェックを頼まれたら、この忙しいのに、面倒だな。もう少し他の方法で不要アカウントを判明する方法とかないのか？また手作業でチェックした場合の間違い、思い違い、聞き違い等々のケアレスミスが下で、別のインシデントが発生するような気がするのは僕だけでしょうか？
あまり良い方法とは思えないので書きますが、この設問の解答にはまったく関係のない余計な懸念点かもですが、実際はそんなに甘くもないと思われました。
さて、②は、なかなか秀逸な方法です。
管理者は、承認するための特権ＩＤは使えません。
もちろん特権ＩＤ使えるユーザは特権ＩＤ管理ＩＤは使えません。
この事より、
施策
①特権ＩＤ管理者は承認しかできないので、特権ＩＤ使って不正できない、
②特権ＩＤユーザが不正したら特権ＩＤ管理者側から発覚するので、まぁ盤石な体制です。
題意でも、不正利用させないための仕組みを理解できてるか？って感じですけど、仮にそのような知識はないとしても、セキュリティ要件表、アカウントの管理の管理者による不正利用に書かれている要件、承認者と行為者の職務を分離という、承認者は特権ＩＤ管理者で、行為者が特権ＩＤユーザという当たりと、この分離で不正を無くすためというと、
問われている、特権ＩＤ管理者のセキュリティ要件に適合させる施策でなければいけません。
そのため、上記施策②でなく①の事を書くと良いのです。
という事で、セキュリティ問題も、セオリーがあって”慣れ”なのかなと思いました。
次回は、今回書かれた心得を、例によって纏めてみます。
でわ。
0 件のコメント:
コメントを投稿