4度目のシステム監査

今年で4回目の受験となるシステム監査試験を受けてきた。
今回は2年前にITサービスマネージャ試験合格によって手にした午前I免除の特典期間中に新たに合格することが出来なかったので、午前Iから受験となった。
午前Iは自己採点で83点、午前IIは76点だった。

昨年度からシステム監査基準が改定になったことに伴い、午前IIはやたらと新基準についての問題が多かった。監査基準を丁寧に見直しておけば、もう少し点数アップが狙えたかもしれない。

午後Iも感覚としては悪くないが、問題は午後IIの論文だ。IoTのテーマと規程見直しに伴う監査となっていて、いずれも用意していたテーマに合っていなかったので、規程見直しの論文を書いたが、文字数の要件を何とか満たすことがやっとで、内容に正直自信がない。。。。

Non-Recurring Expense

開発依頼者が開発依頼先に開発費として一括で支払う方法のこと。
エンジニアリング・リソースや設計ツールの費用、デバイスを製造するための加工技術の費用など、デバイスの設計・製造にかかる経費の総計を指す。
⇔ Recurring Cost

スクラムガイド

2017年11月版より

スプリントプランニング
スプリントの作業計画。

スプリントレトロスペクティブ
スクラムチームの検査と次のスプリントの改善計画を作成する機会。
平成30年度システムアーキテクト試験では、スクラムチームで何がうまくいき、何がうまくいかなかったのかを議論し、継続的なプロセス改善を促進するアクティビティとなっている。

スプリントレビュー
スプリントの終了時にインクリメントの検査と、必要であればプロダクトバック ログの適応を行うもの。

デイリースクラム
開発チームのための 15 分間のタイムボックスのイベント。

CMMI 1.3版エンジニアリングのプロセス領域

平成30年度 システムアーキテクト試験 午前IIより
プロセス領域とは何か?より引用

【要件開発】顧客要件、成果物要件、および成果物構成要素の要件を引き出し、分析し、そして確立すること
【技術解】要件に対する解を選定し、設計し、そして実装することである。解、設計、および実装は、単体の、または適宜組み合わせた成果物、成果物構成要素、および成果物関連のライフサイクルプロセスを網羅すること
【成果物統合】 成果物構成要素から成果物を組み立て、統合されたものとして成果物が適切に動く (必要とされる機能性および品質属性を備えている) ようにし、そしてその成果物を納入すること
【検証】選択された作業成果物が、指定された要件を満たすようにすること
【妥当性確認】 成果物または成果物構成要素が、意図された環境に設置されたときにその意図された用途を充足することを実証すること

システムアーキテクト試験

初めて受験したが、論文で不合格になってしまった。ITサービスマネージャ試験を2年前に合格して以来不合格が続き、来春受験予定のシステム監査試験は午前I免除なしで、かなりしんどい試験になりそう。 ちなみにシステム監査試験は27年度に午後IIで論文でBランクになった後、29年度、30年度は午後Iで連続不合格になっているだけに、午後Iの対策がとても重要。。。。

受験番号  SA542-0124 の方は,   不合格   です

午前Ⅰ得点***.**点
午前Ⅱ得点72.00点
午後Ⅰ得点71点
午後Ⅱ評価ランクB

ウェルノウンポート

/etc/services を確認すればサクッと分かる。

# 21 is registered to ftp, but also used by fsp
ftp 21/tcp
ftp 21/udp fsp fspd
…(省略)…
domain 53/tcp # name-domain server
domain 53/udp
…(省略)…
ntp 123/tcp
ntp 123/udp # Network Time Protocol

またシステム監査に落ちた

今年も午後Iで落ちた。

度肝を抜かれた問題が出題された午後IIの論文が自信が全くなかったわけだけれど、採点すらされなかった。。。。3回目の正直にならなかった。実務が乏しいだけに論点がずれるんだろうな。

ITサービスマネージャのように7回くらい試験を受けないと合格できないかも。。。。泣

受験番号 AU542-0504 の方は、不合格です

午前I得点 ***.**点(平成27年度 ***.**点/平成29年度 ***.**点)

午前II得点 80.00点(平成27年度 64.00点/平成29年度 80.00点)

午後I得点 45点(平成27年度 75点/平成29年度 49点)

午後II評価ランク -(平成27年度 B/平成29年度 -)

クライアント証明書

クライアント証明書は、ID+パスワードによる認証などと並んだ認証方法の一つで、SSL通信が必須である認証方式。(Basic認証はSSL通信は必須ではないが、パスフレーズが暗号化されない点では、盗聴リスクがあることに留意しなければならない。)
クライアント証明書を使用した認証の流れについては、Apacheでのクライアント認証の仕組みに記載されているが、通信相手を信頼する方法は、公開鍵暗号方式を利用する点では、サーバ証明書と同一だが、下記の点で異なる。

  1. 公開鍵暗号方式で共有した共通鍵によって通信の暗号化を保証する方法がクライアント証明書には含まれていない点
  2. と秘密鍵を保持している端末が異なる。(サーバ(サーバ証明書の場合)とクライアント(クライアント証明書の場合))が

クライアント証明書は、秘密鍵を保持しているだけに、サーバ証明書と同様に正しく管理さえされていればなりすましによる認証の可能性が限りなく減らせる。ID+パスワードによる認証とあわせて、多要素認証とすることが出来れば、さらになりすましの可能性を減らせる一方で、証明書の配布と管理が煩雑である面を持つ。

気軽にクライアント証明書を試すには、下記2ステップとなる。
1.自己証明局を作成する。
オレオレ認証局の作り方~SSL証明書を無料で作る方法 on CentOS 5
2.認証方法の変更とクライアント証明書の作成方法
オレオレ認証局でクライアント認証 ~ ウェブの Basic 認証をリプレース
なお、上記では、Webサーバの設定にSSLVerifyClientオプションが登場してくるが、この意味合いについては、ApacheでIP制限とクライアント認証をor条件で運用するに記載されている。