gitでタグをつける方法
注釈付きのタグの作成する
-aオプションで注釈付きのタグが作成できます。
$ git tag -a v1.4 -m 'my version 1.4'
タグの名前を変更方法する
間違えてタグを名前をつけた場合は、次のようなコマンドで名前を変更できます。 例えば、既に存在するv1.0というタグをv2.0というタグにリネームする場合は次のコマンドを実行します。
$ git tag v2.0 v1.0
これで、v1.0と同じコミットにv2.0という新しいタグが付けられます。 続いてtagv1.0を削除します。
$ git tag -d v1.0
以上で完了です。
リモートリポジトリにも反映させるには、このようにそれぞれPushします。
$ git push origin :refs/tags/v1.0 $ git push origin :refs/tags/v2.0
サイバーセキュリティとは？
サイバーセキュリティとは
サイバーセキュリティという単語を情報セキュリティと同じ意味として使われているように思います。 書籍などでは、情報セキュリティと表現されています。これは、簡単には企業や組織の情報資産を守ることとよく説明されます。
特に、企業では経営資源を「人、モノ、金」とよく言いますが、最近ではここに「情報」を加えて、「人、モノ、金、情報」と言ったりするようです。 情報の大切さは、みなの納得するところでしょう。
では、情報資産とは具体的に何を言うのかって疑問に思うと思います。 「資産」というぐらいですから、これは「価値」があるものことを指します。 なので、「価値」がないものは「情報資産」には含めないようです。 例えば、次のようなものは情報資産には含まれないようです。
- 企業所在地
- 事務所電話番号
- Webページ上で発信している情報
みんなが知っているようなものは、情報として「価値」がなく資産でない上に、守ることができませんね。 ただし、標的型攻撃はこれらの情報を入り口に攻撃を開始するので軽く見てはいけないとは思いますが。
話を戻して、情報資産の例を挙げると
- 顧客情報
- 製品設計・開発情報
- 経営戦略情報
などが、「価値」のある「情報資産」と言えそうです。このような情報資産を守るのがサイバーセキュリティです。
サイバーセキュリティが満たすべき3つの性質
サイバーセキュリティはどうあるべきなんでしょうか？それを評価する性質として、次に示す3つの性質があると言われています。
機密性(confidentiality)
ある情報資産へのアクセスを許可されたものと許可されていないものと区別し、許可されたものだけが付与された権限の範囲で情報資産にアクセスできることを言います。 秘匿性と呼ぶこともあるようです。 一般に、暗号化や認証、アクセス制御によって実現される性質です。
完全性(integrity)
ある情報資産について、毀損や改ざんがされていないことを言います。 正真性(しょうしんせい)とも呼ぶようです。 例えば、通信の際にデータを暗号化することによって機密性は確保される（つまり、アクセスの制御ができている）が、それが送り主が送りたかったオリジナルのデータと同一であるかどうかという観点で見た場合に、満たされるべき性質です。 暗号化された状態でデータの一部が改変されるたような場合は、機密性は失われていないが完全性は失われたことになります。 ハッシュ関数やデジタル署名はこの完全性を確保するための技術です。
可用性(availability)
ある情報資産やITシステムなどにアクセスする際に、正常にサービスを利用できるような状態に保つことを言います。 システムがダウンして、利用できないようなことが無いことです。 つまり、使えなかったら、意味ないよねってことですね。
最近では、さらに4つの性質も満たすべき
実は、サイバーセキュリティの満たすべき性質は3つだけではなく、次に示す4つの性質も含まれるように考えられているようです。
真正性 (authenticity)
利用者、プロセス、システム、情報などが本物であることを確実にする性質のことです。 なりすましや受信した情報が偽の情報でないことを確実にする必要があります。
責任追跡性 (accountability)
利用者、プロセス、システムなどの操作や動作について、その主体と内容を一意に追跡できることを確実にする性質です。 「誰が」、「いつ」、「何を」、「どうした」のような情報を残し、セキュリティインシデントの原因や攻撃者の特定などをするために必要な性質です。
否認防止 (non-repudiation)
ある活動や事象が起きたことを、後になって否認されないように証明できる性質です。 例えば、AさんがBさんに「商品の注文情報を送信した」が、後になってAさんは「商品の注文情報など送信していない」と否認された場合、「商品の注文情報を送信した」ことを証明できなければ、電子商取引が円滑に進められません。そのため、AさんがBさんに「商品の注文情報を送信した」と証明できる必要があります。これが否認防止です。
信頼性 (reliability)
システムや処理の結果が矛盾なく動作すること、期待された結果と整合性がとれており、一貫して動作することです。 そもそものシステムにバグや欠陥がなく、正しく動作すると信頼できる状態である必要があります。
サイバーセキュリティの対象の分類
ここまで、サイバーセキュリティがどういうものかを見てきましたが、対策の対象になるものを整理します。 情報資産を守るために、何に対して対策が必要かということです。 大きく対象を分けると、物理的なセキュリティと、論理的なセキュリティがあります。 論理的なセキュリティはさらに、システム的なセキュリティ、管理的・人的セキュリティに分けられるようです。
物理的なセキュリティ
建物や設備などを対象にしたものです。 具体的には、次のITインフラ周りの設備です。
これらは、火災や災害などから情報資産への被害を最小限にします。 さらに、
- サーバルーム等の入退出管理
- 監視カメラ
なども含まれます。 不審な人物を情報資産に物理的にアクセスさせず、破壊や窃取されることを防ぎます。
論理的なセキュリティ
論理的なセキュリティとは、一般に、物理的なセキュリティ以外のことを指し、次のように分類されることが多いようです。
システム的なセキュリティ
暗号技術、認証技術や、アクセス制御技術など、ITシステムやネットワークにおける技術的なセキュリティ対策のことを言います。
管理的・人的なセキュリティ
情報セキュリティポリシの策定・運用・監査・見直しなどの組織やシステムの運用管理面における対策と従業員などに対するサイバーセキュリティの教育や訓練、セキュリティインシデントへの対処などの対策のことを言います。
サイバーセキュリティ対策では、これらの対象に対して、どのように対策を立てるかが問われるようです。
システムアーキテスト試験の午後2問題の傾向と課題について
はじめに
システムアーキテクト試験で一番対策が必要な午後2の論述問題について、簡単に傾向を見ました。
注意
見た問題は午後2問題の問1と問2の情報システムに関するものです。組み込みシステムの問題（問3）は経験がないので捨てることにしました。そのためここでは問3を除いてます。また、表中の設問、出題趣旨については過去問から適当に短くして抜き出しています。必ずしも表現が適切でないので注意してください。
問題の傾向
問題としては、出題趣旨の点について、システムアーキテストとして必要なポイントを押さえた考え方について、具体的な情報システムを基に論述できることがチェックされるようです。既にシステムアーキテクト的な立場の人で実務経験があれば、これまで携わった情報システムについて、問われている点を素直に記述すれば、合格が見えて来そうです。
私はミドルウェアの開発が主な仕事なので、それを使う業務システムの設計という意味では経験や考えが不足しています。そのため、携わった情報システムを捏造した上、設計時のポイントを押さえる必要があることがわかりました。
課題
情報システム設計時のポイントについては、ミドルウェアの設計にも通じる点があるでしょうから、それを情報システムとして応用すれば良さそうです。私にとっての一番の課題は、設計・開発に携わった情報（業務）システムをどのように捏造するかという点のようです。
現時点で、何か業務システムの開発について具体的に紹介している書籍やサイトを参考にそれらしいシステムを考えたいと思います。高度試験の設問で出題されているシステムも良いかもしれません。
年度別の設問と出題趣旨
| A | B | C | D | E | F | |
|---|---|---|---|---|---|---|
1 | ||||||
2 | 平成27 | 1 | システム方式設計について | ア | 対象の業務と情報システムの概要を、それぞれ特徴を含めて述べよ | システム方式設計について、設計とその決定理由、利用者の理解度を高めるための工夫ができる能力 |
3 | イ | どのようなシステム要件を実現するために、どのようなシステム方式を設計したのか。業務プロセスへの効果、実現可能性などの決定理由を含めて述べよ | ||||
4 | ウ | システム方式設計の結果を説明する際に実施した、利用者の理解度を高める工夫を、実例を含めて述べよ | ||||
5 | 2 | 業務の課題に対応するための業務機能の変更又は追加について | ア | 情報システムの概要、及び業務の概要とともに、業務の課題はどのようなものか述べよ。 | 業務の課題に対応するために必要となった業務機能とそれが必要な理由、それに対応するためのシステム変更・追加の内容とその工夫から評価する | |
6 | イ | アの業務の課題に対応するために、どのような業務機能の変更または追加が必要となったか。課題に対応できると考えた理由とともに述べよ | ||||
7 | ウ | 変更または追加の際に、既存機能の活用や既存の情報システムへの影響の最小化にどのような工夫をしたのか述べよ | ||||
8 | 平成26 | 1 | 業務プロセスの見直しにおける情報システムの活用について | ア | 携わった業務プロセスの見直しについて、見直しになった業務プロセス、及び関連する情報システムの概要とともに述べよ | 業務プロセスの問題点とその原因、原因を取り除くための情報システムの活用方法、例外的な状況でも業務プロセスが実行できるように想定した状況と対応する能力 |
9 | イ | アの見直しは、どのような業務上の問題とその原因に対応するためのもであったか、原因を取り除くためにどのように情報システムを活用したのか述べよ | ||||
10 | ウ | 例外的な状況でも業務プロセスが実行できるように、想定して検討した起こりえる状況とその対応を述べよ | ||||
11 | 2 | データ交換を利用する情報システムの設計について | ア | 構築に携わったシステムについて、データ交換を利用する目的を対象業務、及び対象の情報システムの概要を含めて述べよ | 企業間や企業内システム間でデータ交換をする情報システムを構築・設計する能力 | |
12 | イ | どのような制約事項を踏まえて、どのように情報システムを設計したか述べよ | ||||
13 | ウ | データ交換に伴うどのような異常を想定し、情報システムでどのような対応方法を用意したのか、どの対応が必要になる理由とともに述べよ | ||||
14 | 平成25 | 1 | 要求を実現する上での問題を解消するための業務部門への提案について | ア | 携わった要件定義について、その概要を、開発の背景、対象の業務、業務部門からの要求を含めて述べよ | 要件定義で提示された要求を実現する上で発生した問題の解消または軽減する設計能力 |
15 | イ | 要求を実現する上でどのような問題が発生したのか。その問題を解消又は軽減するために、業務部門にどのような提案をしたのか、業務や情報システムでの対応を中心に述べよ | ||||
16 | ウ | 提案の中で、業務部門が提案の採否を判断しやすいように提示した評価項目などと、提案を採用する場合としない場合とを対比して評会sた業務上の効果、￥及びその評価結果について述べよ | ||||
17 | 2 | 設計内容の説明責任について | ア | 携わったその対象業務、及びあなたが責任をもって説明をした設計の概要について述べよ | システム開発関係者に対して十分な情報を提供し、設計した内容が適切であることを説明する責任があり、その説明能力 | |
18 | イ | 設計の内容を、誰に、どのような項目を理解してもらうために、どのような観点から説明したか述べよ | ||||
19 | ウ | 説明を限られた時間内で効率よく理解してもらえるように、どのようにプレゼンテーションを工夫したたか。その結果から、プレゼンテーションの内容について改善すべきと考えた点について述べよ | ||||
20 | 平成24 | 1 | 業務の変化を見込んだソフトウェア構造の設計について | ア | 設計に携わったシステムにおける、対象業務の概要および特徴について述べよ | 業務の変化に対応して容易に機能を変更できるようなソフトウェア構造の柔軟性をもたせた設計能力 |
21 | イ | どのような業務の変化を想定したのか、業務が変化してもシステム全体を大きく作り直す必要がないように、どのようなソフトウェア構造を設計したか述べよ | ||||
22 | ウ | イの設計において、生じた課題とそれに対応するために重要と考えて工夫した内容、及び設計したソフトウェア構造に対するシステムアーキテクトとしての評価について述べよ | ||||
23 | 2 | 障害時にもサービスを継続させる業務ソフトウェアの設計について | ア | 携わった、対象業務とシステムの概要、サービス継続の方針について述べよ | 障害時にも継続運用を可能にする設計能力 | |
24 | イ | アで述べた方針に基づいて、障害時にサービスを継続することにした処理は何か。継続運用を可能にするために業務ソフトウェアをどのように設計したか述べよ | ||||
25 | ウ | イでの設計で、継続運用に備えた処理や障害復旧処理においてどのような工夫をしたか述べよ。 | ||||
26 | 平成23 | 1 | 複数のシステムにまたがったシステム構造の見直しについて | ア | 携わった見直しについて、見直しの背景と概要、対象になった複数のシステムの概要を述べよ | 複数のシステムにまたがったシステム構造の見直しの能力 |
27 | イ | アの見直しについて、業務とシステムをどのような視点から分析し、どのような新しいシステム構造を選定したのか。メリットなどの選定理由とともに述べよ。 | ||||
28 | ウ | イの新しいシステム構造には、どのようなデメリットがあり、どのような軽減方法を検討したのか述べよ | ||||
29 | 2 | システムテスト計画の策定について | ア | 携わったシステムテストについて、対象業務と対象システムの概要、及び期間や費用などの制約について述べよ | 制約の中で効率よくシステムの品質を確保するシステムテスト計画を策定する能力 | |
30 | イ | アのテストを計画する際に、どのようなテス重点確認項目を設定したか。考慮した業務の重要度や業務特性とともに述べよ | ||||
31 | ウ | イのテスト策定において、制約のある中で効率良くシステム音品質を確保するために、あなたが重要と考え工夫した点について述べよ | ||||
32 | 平成22 | 1 | 複数の業務にまたがった統一コードの整備方針の策定について | ア | 携わった統一コードの整備方針の策定における、複数の業務にまたがった業務改善の目的と、対象コードについて述べよ | 業務横断での業務改善が増えている。業務改善を実現するために、全体最適の観点から統一コードの整備方針を策定する能力 |
33 | イ | アで述べた業務改善を実現するために、現状の業務やシステムをどのような視点から調査したか。その結果に基づいて、どのような統一コードの整備方針を策定したか述べよ | ||||
34 | ウ | イで述べた整備方針の策定で、与えられたコストと期間で業務改善を実現するために重要と考え、工夫した点を述べよ | ||||
35 | 2 | システム間連携方式について | ア | 携わったシステム間連携方式の検討において、対象システムの概要と連携が必要になった背景について述べよ | システム関連連携時の要件を実現する最適なシステム方式の設計能力 | |
36 | イ | アで述べたシステムを連携させる際に、どのような業務要件を踏まえ、どのようなシステム要件を明確にしたか。その要件に基づいてどのようなシステム間連携方式を選択したか、選択した理由とともに述べよ | ||||
37 | ウ | イで述べたシステム間連携方式について、運用要件と実現方法を、重要と考えた点を中心に述べよ | ||||
38 | 平成21 | 1 | 要件定義について | ア | 対象業務の概要とシステム開発の目的を述べよ | 要件定義を行う上で必要な要求分析能力や要件定義能力 |
39 | イ | アで述べたシステムについて、ユーザ要求を正しく理解するために、どのような点に留意してユーザ要求をヒアリングし、どのような要件としてまとめたか述べよ | ||||
40 | ウ | イで述べた要件をまとめる際、ユーザとの認識の相違をなくすために、重要と考え工夫した点について述べよ | ||||
41 | 2 | システムの段階以降について | ア | システムの概要と段階移行の方法について述べよ | 移行方式の設計能力 | |
42 | イ | アのシステムについて、平行運用期間中の課題をどのように想定し、その課題に対してどのような対応方法を選んだか。その課題、対応方法、選んだ理由を、業務の特性を踏まえて述べよ | ||||
43 | ウ | イで述べた方法を実施する上で、重要と考え工夫した点を述べよ |
システムアーキテクト試験合格への対策検討
はじめに
2016年10月17日のシステムアーキテクト試験を受験するので、その試験勉強の方向を検討しました。
システムアーキテクトと試験項目
IPAのサイトのシステムアーキテスト（情報システム）の役割と業務の定義は、次のような項目なので、試験についてはこれらに関することが問われることになります。
- 情報システムの構造の設計 : 全体最適の観点から、対象とする情報システムの構造を設計する。
- 開発に必要となる要件の定義 : 全体システム化計画及び個別システム化構想・計画を具体化するために、対象とする情報システムの開発に必要となる要件を分析、整理し、取りまとめる。
- システム方式の設計及び情報システムを開発する業務 : 対象とする情報システムの要件を実現する最適なシステム方式を設計する。要件及び設計されたシステム方式に基づいて、要求された品質を満足するソフトウェアの設計・開発、テスト、運用及び保守についての検討を行い、対象とする情報システムを開発する。対象とする情報システム及びその効果を評価する。
午前1問題
この試験は、他の高度試験と共通です。次のいずれか一つでも満たせば免除されるので、何度か試験を受けたことがある人は免除されていると思います。試験を申し込みするときに、免除申請を忘れないように行います。
- 応用情報技術者試験（AP）に合格
- いずれかの高度試験に合格
- いずれかの高度試験の午前Ⅰ試験で基準点(60%)以上の成績をとる
ほとんどの問題は過去の問題と同じ問題が出題されます。 もし、条件を満たしていない場合は、応用情報技術者試験ドットコムさんの、「Webアプリ過去問道場」のひたすら解いて、解説で勉強すれば、合格できます。平成21年度からの過去問を一通りやれば間違いないです。
午前2問題
選択問題が25問が出題されます。時間は40分以内で、全ての問題を解答します。 感覚的に過半数の問題は過去問から出題されています。過去問を解いて、間違った点を学び直せば合格できるはずです。
午後1問題
4問題出題され、そこから2問を選択して解答します。時間は90分です。4問のうち、3問は情報システム関係、1問は組み込みシステム関係の問題です。 問題が扱う題材は、業種や業務は様々ですが、問題のポイントはシステムとしての考え方を問われるので、どの業種・業務でもそんなに変わりはしないと思います。
基本的に、解答に必要な情報はすべて問題文で与えられているので、基礎的な技術知識と業務への一般的な理解があれば、答えを導き出せるようになっています。この問題でのポイントとしては、次の2点です。これに気をつけて問題文から答えを探しだして記載すれば合格できるはずです。
- 問われている内容に答えていること
- 設問中の表現を利用して答えること
午後2問題
ここがシステムアーキテクト試験で一番のポイントです。ネットワークスペシャリストや情報セキュリティスペシャリスト試験などのスペシャリスト系の試験は、午後2問題も午後1問題の延長のような問題ですが、システムアーキテクト試験では論述形式のため、そもそも試験問題の性質が異なります。ただし、解答形式が異なるだけであって、試験のポイントは似たようなもので、次の3つだと考えています。
- 問われている内容に答えていること
- システム設計上のポイントを抑えていること
- 採点者が理解できる記述であること
これをクリアするために、次の勉強・訓練をすることにしました。
問われている点の把握できること : 設問をよく読み問われている点をピックアップします。設問自体に、システムアーキテストはこうあるべきと記載があるので、それの内容を論述内容に盛り込むようにします。
論述内容の構成を構築できること : 問われている点に答える形で章を構成します。その章構成をベースに、設計上のポイント（ほとんどの場合は、設問中に表現されている点）を盛り込んで肉付けします。文章の構成や書き方は、今回考える技術・書く技術―問題解決力を伸ばすピラミッド原則で学ぶことにします。論述系の試験ではここが最大のポイントだと思います。
一般的なシステム設計上のポイントの学習 : 過去問をしながら、午前1や午後2で問われる点を整理しようと思います。また、システム開発時のプロセスについて標準規格などに弱いのでその点を整理しようと考えています。
時間内に手書きで記述すること : 実際の解答を必ず、紙に記述します。筆記用具も試験当日に使うものを使った方が良いでしょう。手を動かして、試験当日までに慣れておきます。おそらくほとんどの人は、普段キーボードを使っているので、ここも重要な点だと思います。
問題はたいてい、1, 2問目が情報システムの問題、3問目が組込みシステムの問題で、そこから解答する1問を選択します。時間は2時間です。設問はア、イ、ウとあり、それぞれ800字以内、800字以上1600字以内、600字以上1200字以内で記述します。時間配分は20分、70分、30分くらいでしょうか。
設問アは、ほとんどの場合これから論述するシステムの概要や特徴の説明をします。そのため、この部分は題材となるシステムを準備をしておくことが可能そうです。設問イ、ウは、問われている点を論述することになります。過去問を簡単に分析して、ポイントを整理し、論述のイメージを形づくっておこうと思います。
Ubuntu 16.04LTS で使える Git GUIクライアント
Gitは普段コマンドで操作していますが、コミットやマージの履歴をみる場合だけ、どうしてもGUIで確認したくなります。 Linuxで使えるGit GUIクライアントもそこそこ色々ありますが、インタフェースを見た感じあまりぐっとくるものがありません。
- git-cola
- giggle
- gitk
- git-gui
- qgit
- gitg
- GitForce
- Egit
WindowsやMacではGUIクライアント豊富そうですが、Ubuntuだとなかなか無いです。 そんな中でも、次の3つが見た目が良く、おすすめです。
GitKraken
米Axosoftという会社がGitKrakenという新しいGit GUIを開発しました。 現在はこれを使っています。Electronが使われており、Windows、Mac、Linuxに対応しています。NodeGitが組み込まれているので、GitをインストールしなくてもGitKrakenだけで動作が可能らしいです。
このGUIクライアントでできることは他のGUIクライアントに比べて、多くはありませんが、基本的な操作はできるみたいです。私はGUIを使わずにgitコマンドで操作しているので使ったことが無いです。なんと言っても見た目が良く、コミットやマージの履歴を追いやすいです。私はGUIクライアントで履歴を追うために使うので、一番使い方に合っています。
インストールは公式サイトから、debパッケージをダウンロードして、Ubuntu Softwareかdpkgコマンドでインストールします。
SmartGit
独syntevoという会社が開発しているGUIクライアントです。一番最初にGUIクライアントにはこれを使いました。Windows、Mac、Linuxに対応しており、そこそこ見た目は良いのですが、無料で使えるのは非商用の場合だけなので、今回はパスしました。
インストールは、PPAを追加して、updateします。
$ sudo add-apt-repository ppa:eugenesan/ppa $ sudo apt-get update
その後、smartgitをインストールします。
$ sudo apt-get install smartgit
GitEye
米CollabNet社の開発です。これは、SmartGitの後に見つけて試したGUIクライアントです。これもWindows、Mac、Linuxに対応しています。Eclipse RCPフレームワークが使われています。GitKrakenが出るまではこれを使っていましが、履歴部分の表示が狭く感じていたのと、何やらUIが複雑でややこしいのであまり好きになれませんでした。
インストールは公式サイトから、ダウンロードボタンをクリックし、ダウンロードページを表示し、Linuxを選択して、zipをダンロードします。 zipを展開して、「GitEye」の実行ファイルから起動します。
それでもやっぱりCUIか
ここまでGUIクライアントを紹介してきましたが、tigというCUIベースでグラフィカルにgitを操作できるツールがあるようです。起動が早いし、そこそこ履歴が見やすく、なんと言っても端末からの操作できるので、今まで別々に行っていた履歴を見る操作とgitコマンドの操作がシームレスに行えそうです。今後、試してみようと思います。
インストールは次のコマンドでインストールできます。
$ sudo apt-get install tig
起動も次の3文字で素早く起動します。
$ tig
情報セキュリティスペシャリスト試験のための試験対策カリキュラム
カリキュラムの概要
今回は、実際に実施した情報セキュリティスペシャリスト試験の勉強計画を紹介します。 セキュリティに関する知識がほとんどなかったため、セキュリティの基礎から計画したものです。 平成28年度の春試験の情報セキュリティスペシャリストを受験しました。 勉強を開始したのは平成27年度秋試験終わった後の10月25日からです。 勉強期間は6ヶ月間です。 試験当日の前の週までみっちりやることになってしまいました。
学習項目としては次のような項目です。詳しくは具体的なカリキュラムを見てください。
今回は、過去問が3回分しかできていませんが、学習カリキュラムと並行して、過去問を解ければなお良いです。 情報セキュリティスペシャリストは、春秋と2回試験があるので、過去問もたくさんあります。 今回はセキュリティの基礎学習からやっていますが、セキュリティにある程度詳しい人であれば、過去問を毎週1回分して、わからなかった点を復習するような方法でも合格できそうです。
図書について
情報セキュリティ全体の概要を学ぶ
マスタリングTCP/IP 情報セキュリティ編 : この本で、情報セキュリティの全体像や各項目の概要を学びます。私はこの本をベースに全体の項目を勉強し、足りない部分や深めたい内容を別の図書で学びました。セキュリティのことを何も知らない状態で、最初に手にとった本でした。項目としては網羅されたものだと思います。セキュリティについて、どのような内容が必要かということを理解するのには良いものでした。ただし、ちょっと表現が硬いのか、全般を扱っているためか、説明の内容は少しイメージしにくかったです。
暗号技術を学ぶ
暗号技術入門 第3版 秘密の国のアリス : この本では、暗号技術の全般とPKI、セキュリティプロトコルについて、マスタリングTCP/IPよりも、もう少し突っ込んで学習できます。難しそうな内容が大変わかりやすく解説されているので、暗号技術の入門としては最適です。
ネットワークのセキュリティを学ぶ
実践ネットワークセキュリティ監査―リスク評価と危機管理 : この本では、ネットワーク周りのセキュリティに関する項目を学習します。この本も実際に手を動かして試すことができるので、知識の定着に良いです。ただし、2005年に出版されたものなので、少し情報が古い印象を受けました。その点だけ注意すれば、ネットワークのセキュリティに関して理解が深められます。
サーバのセキュリティを学ぶ
Linuxサーバーセキュリティ徹底入門 オープンソースによるサーバー防衛の基本 : この本で、各サーバの具体的な設定などを手を動かして試すことで知識が定着するようにします。一通りサーバでの注意点が記載されています。ただし、記載内容はそこまで深くありません。ネットで各サーバの注意点を調べた方が良いです。ただ、調べる取っ掛かりとして、この本の内容程度を学んでおくと良さそうです。
試験対策や復習をする
ポケットスタディ 情報セキュリティスペシャリスト 第2版 (情報処理技術者試験) : この本では、通勤・通学中のスキマ時間に、試験の出題傾向や注意点を学びます。少し日本語が分かりづらかったですが、試験のポイントは整理してあると思います。 この本は既にセキュリティがわかっている人が試験対策として使うような本です。セキュリティ初心者がこの本だけ読んでも理解が追いつかないと思います。 また、過去問を解けば傾向がわかるので、時間がある人は過去問をじっくりした方がいいかもしれません。
情報処理教科書 情報セキュリティスペシャリスト 2016年版 : この本は、試験項目とその内容が整理されているので、時間があるときに読み返えすと、学んだことを復習できます。 セキュリティにある程度明るい人であれば、この本と過去問だけで合格できるかもしれません。もう少し具体的なサーバの設定や攻撃を理解したい場合は、ちょっと物足りないです。
具体的なカリキュラム
以下の表が、今回やったカリキュラムです。単に予定したものではなくて、実際にやったものです。 学習した時期についても記載しておきました。ほぼ毎週、何らかの項目を学習しています。 セキュリティの基礎からやったので、時間的にギリギリなカリキュラムになっています。 その分、セキュリティのゼロの人でも、合格が望める程度の知識がつくカリキュラムになっていると思います。 これをベースに、自分の知っているところは除いて、知らないところや復習したい点を追加して、オリジナルのカリキュラムを作成してみてください。
| A | B | C | D | E | |
|---|---|---|---|---|---|
1 | |||||
2 | 情報セキュリティの概要 | 情報セキュリティの分類 | ・マスタリングTCP/IP 情報セキュリティ編 | 2015/10/25～11/1 | |
3 | 情報セキュリティが満たすべき3つの性質 | ||||
4 | セキュリティを構成する要素 | 暗号技術 | |||
5 | ディジタル署名 | ||||
6 | セキュリティプロトコル | ||||
7 | 認証 | ||||
8 | バッファーオーバーフロー対策 | ||||
9 | アクセス制御 | ||||
10 | ファイアウォール | ||||
11 | 暗号技術 | シーザー暗号 | ・マスタリングTCP/IP 情報セキュリティ編 ・暗号技術入門 第3版 秘密の国のアリス | 2015/11/2～11/8 | |
12 | 単一換字暗号 | ||||
13 | 使い捨てパッド（バナーム暗号） | ||||
14 | 共通鍵暗号化方式 | DES | |||
15 | トリプルDES | ||||
16 | AES | ||||
17 | 公開鍵暗号化方式 | RSAの仕組み | |||
18 | ハイブリッド暗号 | ||||
19 | 鍵共有アルゴリズム | ||||
20 | 認証技術 | 主体認証 | ・マスタリングTCP/IP 情報セキュリティ編 ・暗号技術入門 第3版 秘密の国のアリス | 2015/11/9～11/15 | |
21 | 認証プロトコルの基礎 | 脅威モデル | |||
22 | パスワードによる認証プロトコル | ||||
23 | 一方向ハッシュ関数 | ||||
24 | メッセージ認証コード | ||||
25 | デジタル署名 | ||||
26 | 時刻認証 | ||||
27 | ゼロ知識証明 | ||||
28 | ID連携 | ||||
29 | 公開鍵基盤（Public Key Infrastructure） | PKIの構成要素 | ・マスタリングTCP/IP 情報セキュリティ編 ・暗号技術入門 第3版 秘密の国のアリス | 2015/11/16～11/24 | |
30 | 認証局 | ||||
31 | 証明書チェーン | ||||
32 | 証明書の利用 | ||||
33 | 証明書の有効性のチェック | OCSP,SCVP | |||
34 | 証明書に対する攻撃 | ||||
35 | 証明書の種類 | ||||
36 | サーバ証明書 | ||||
37 | クライアント証明証 | ||||
38 | 証明書の標準規格 | X.509 | |||
39 | セキュリティプロトコル | SSL/TLS | SSL/TLSの全体像 | ・マスタリングTCP/IP 情報セキュリティ編 ・暗号技術入門 第3版 秘密の国のアリス | 2015/11/24～11/30 |
40 | SSLとTLSの違い | ||||
41 | Recordプロトコル | ||||
42 | Handshakeプロトコル | ||||
43 | IPsec | IPsecの全体像 | |||
44 | IPsecの処理の概要 | ||||
45 | AH | ||||
46 | ESP | ||||
47 | IKE | ||||
48 | ホストのセキュリティ | バッファーオーバーフローの仕組み | ・マスタリングTCP/IP 情報セキュリティ編 | 2015/12/7～12/13 | |
49 | スタックオーバーフローの仕組み | ||||
50 | ヒープオーバーフローの仕組み | ||||
51 | セキュアOS | セキュアOS | (1)強制アクセス制御(MAC:MandatoryAccess Control)機能 | ・マスタリングTCP/IP 情報セキュリティ編 | 2015/12/14～12/20 |
52 | (2)最小特権機能 | ・Linuxサーバーセキュリティ徹底入門 ープンソースによるサーバー防衛の基本 | |||
53 | LinuxにおけるセキュアOS | SELinux | |||
54 | セキュリティコンテキスト | ||||
55 | SELinuxのコマンドや設定 | ||||
56 | ネットワーク・セキュリティ | ファイアウォール | ・マスタリングTCP/IP 情報セキュリティ編 ・実践ネットワークセキュリティ監査 | 12/21～12/27 | |
57 | 侵入検知システム・侵入防御システム | ||||
58 | WAF（WebApplicationFirewall） | ||||
59 | ネットワークスキャン | ||||
60 | セッションハイジャック | ||||
61 | インターネットにおける攻撃の分類 | ||||
62 | ネットワーク列挙 | ||||
63 | インターネットにおけるホストとネットワークの列挙方法 | Web検索サービス | ・実践ネットワークセキュリティ監査 | 20/15/12/28～2016/1/3 | |
64 | WHOIS問い合わせ | ||||
65 | DNS問い合わせ | DNSゾーン転送 | |||
66 | リバースDNSスイーピング | ||||
67 | SMTPプロービング | ||||
68 | ネットワークスキャニング | ICMPスキャニング | SING | ・実践ネットワークセキュリティ監査 | 2016/1/4～1/11 |
69 | nmap | ||||
70 | 内部IPアドレスの収集 | ||||
71 | サブネットブロードキャストアドレスの特定 | ||||
72 | TCPポートスキャニング | 標準TCPスキャニング | |||
73 | ステルスTCPスキャニング | ||||
74 | スプーフィングおよび第三者中継TCPスキャニング | ||||
75 | UDPポートスキャニング | UDPポートスキャニングのためのツール | |||
76 | IDSおよびフィルタリングの回避 | スキャニングパケットの断片化 | |||
77 | 攻撃ホストの複数化スプーフィング | ||||
78 | ソースルーティング | ||||
79 | 特殊な送信元ポートの利用 | ||||
80 | ローレベルIP監査 | TCPおよびICMPプローブの応答分析 | |||
81 | ICMPメッセージの受動的な監視 | ||||
82 | IPフィンガープリンティング | ||||
83 | TCPシーケンス番号およびIPヘッダID値の予想 | ||||
84 | Webサービスの監査 | Webサービスの特定 | HTTPHEADメソッド | ・実践ネットワークセキュリティ監査 | 2016/1/12～1/118 |
85 | HTTPOPTIONSメソッド | ||||
86 | Webサーバの自動フィンガープリンティング | ||||
87 | SSLトンネルによるWebサーバの特定 | ||||
88 | サブシステムおよびコンポーネントの特定 | WebDAV | |||
89 | OpenSSL | ||||
90 | Web脆弱性の調査 | Web脆弱性を調査するためのツール | |||
91 | MicrosoftIISの脆弱性 | ||||
92 | Apacheの脆弱性 | ||||
93 | OpenSSLの脆弱性 | ||||
94 | HTTPプロキシによる第三者中継 | ||||
95 | HTTP認証に対するブルートフォース攻撃 | ||||
96 | パラメータ操作とフィルタリング回避 | ||||
97 | エラー処理の問題 | ||||
98 | Webアプリケーション監査ツール | ||||
99 | Web アプリケーションに不正なスクリプトや命令を実行させる攻撃 | 不正なスクリプトや命令を実行させる攻撃の種類 | ・情報処理教科書 情報セキュリティスペシャリスト 2016年版 | 2016/1/19～1/25 | |
100 | クロスサイトスクリプティング | ||||
101 | SQL インジェクション | ||||
102 | OS コマンドインジェクション | ||||
103 | HTTP ヘッダインジェクション | ||||
104 | メールヘッダインジェクション | ||||
105 | ディレクトリトラバーサル攻撃 | ||||
106 | Webサービスのセキュリティ | Apacheの基本 | Apacheのインストールと基本 | ・Linuxサーバーセキュリティ徹底入門 ープンソースによるサーバー防衛の基本 | 2016/1/26～2/1 |
107 | Webセキュリティの要点 | ||||
108 | Apacheの安全な設定と運用 | apache2.confの基本設定 | |||
109 | apache2.confの主な設定 | ||||
110 | 外部設定ファイル | ||||
111 | Apacheのログ | ||||
112 | ユーザー認証とホストベースのアクセス制御 | 基本認証 | |||
113 | ダイジェスト認証 | ||||
114 | ホストベースのアクセス制御 | ||||
115 | OSのセキュリティ | ブートローダーのパスワード設定 | 起動パラメータ | ・Linuxサーバーセキュリティ徹底入門 ープンソースによるサーバー防衛の基本 | 2016/2/2～2/8 |
116 | GRUBのパスワード設定 | ||||
117 | ユーザーアカウントの管理 | 一般ユーザーのログイン管理 | |||
118 | rootログインの禁止 | ||||
119 | suコマンドの利用 | ||||
120 | root権限の利用 | ||||
121 | パスワードの管理 | ||||
122 | サービス管理 | 不要なサービスの停止 | |||
123 | xinetd | ||||
124 | TCPWrapper | ||||
125 | プロセス監視 | psコマンドによるプロセス監視 | |||
126 | topコマンドによるプロセスとシステムの監視 | ||||
127 | ファイルシステムのセキュリティ | パーミッション | 所有者と所有グループ | ||
128 | アクセス権 | ||||
129 | アクセス権の変更 | ||||
130 | SUID、SGID | ||||
131 | スティッキービット | ||||
132 | デフォルトのアクセス権 | ||||
133 | ACL(Access Control List) | ||||
134 | ネットワークのセキュリティ | ネットワークの基本設定 | ネットワーク設定ファイル | ・Linuxサーバーセキュリティ徹底入門 ープンソースによるサーバー防衛の基本 | 2015/1/9～2/15 |
135 | /etc/hosts | ||||
136 | 基本的なネットワーク管理コマンド | ||||
137 | ネットワーク探査対策 | ||||
138 | ファイアウォール | パケットフィルタリングの仕組み | |||
139 | チェインとテーブル | ||||
140 | iptablesコマンド | ||||
141 | 基本的なパケットフィルタリングの設定 | ||||
142 | iptablesの応用 | ||||
143 | ip tablesコマンド | ||||
144 | CUIツールによるパケットフィルタリング設定 | ||||
145 | システムログ | システムログの管理 | システムログの概要 | ・Linuxサーバーセキュリティ徹底入門 ープンソースによるサーバー防衛の基本 | 2016/2/15～2/21 |
146 | ログが保存される仕組み | ||||
147 | syslogの設定 | ||||
148 | rsyslogの設定 | ||||
149 | ログサーバーの設定 | ||||
150 | ログのローテーション | ||||
151 | ログの監視 | ログファイルの監視 | |||
152 | logwatch | ||||
153 | swatch | ||||
154 | サーバの侵入検知 | セキュリティチェックと侵入検知 | ポートスキャンとパケットキャプチャ | ・Linuxサーバーセキュリティ徹底入門 ープンソースによるサーバー防衛の基本 | 2016/2/22～2/28 |
155 | nmap | ||||
156 | tcpdump | ||||
157 | Tripwire(ファイル改ざん検知) | ||||
158 | Rootkit Hunter(Rootkit検知) | ||||
159 | fail2ban(侵入防御システム) | ||||
160 | VPNのセキュリティ | IPSec VPN | IPSec VPN概要 | ・実践ネットワークセキュリティ監査 | 2016/3/1～3/6 |
161 | IPSec VPNの攻略 | ||||
162 | IPSecの列挙 | ||||
163 | IKEにおける既知の脆弱性 | ||||
164 | VPNにおける対策 | ||||
165 | DNSサーバのセキュリティ | DNSの基本 | 名前解決 | ・Linuxサーバーセキュリティ徹底入門 ープンソースによるサーバー防衛の基本 | 2016/3/7～3/14 |
166 | DNSの仕組み | ||||
167 | DNSサーバーの用語 | ||||
168 | DNSクライアントコマンド | ||||
169 | BINDの基本設定 | BINDのインストール | |||
170 | rndcコマンド | ||||
171 | BINDの設定ファイル | ||||
172 | BINDのログ | ||||
173 | キャッシュサーバーの設定 | named.confの設定 | |||
174 | ゾーンサーバーの基本設定 | named.confの設定 | |||
175 | ゾーンファイルの書式 | ||||
176 | ゾーン転送の制限 | ||||
177 | より安全なBINDの設定と運用 | バージョンの表示 | |||
178 | TSIG | ||||
179 | DNSSEC | ||||
180 | メールサーバのセキュリティ | メールサーバーの基礎 | メールサーバーの仕組み | ・Linuxサーバーセキュリティ徹底入門 ープンソースによるサーバー防衛の基本 | 2016/3/15～3/28 |
181 | Postfixのインストールと基本 | ||||
182 | Dovecotのインストールと基本 | ||||
183 | メールサーバーセキュリティの要点 | ||||
184 | 安全なPostfixの設定 | Postfixの基本設定 | |||
185 | main.cfの主な設定 | ||||
186 | 設定の反映と確認 | ||||
187 | SMTP認証 | ||||
188 | SSL/TLSの利用 | ||||
189 | OP25B対応 | ||||
190 | Postfixのログ | ||||
191 | POP／IMAP | Dovecotの基本設定 | |||
192 | POP/IMAP over SSL | ||||
193 | 試験形式の対策 | 平成21年度春試験 | 午前2問題 | 過去問 | 2016/3/15～3/28 |
194 | 午後1問題 | ||||
195 | 午後２問題 | ||||
196 | 平成23年度春試験 | 午前2問題 | 2016/3/29～4/4 | ||
197 | 午後1問題 | ||||
198 | 午後２問題 | ||||
199 | 平成23年度秋試験 | 午前2問題 | 2016/4/5～4/11 | ||
200 | 午後1問題 | ||||
201 | 午後２問題 | ||||
202 | 試験 | 2016/4/17 |
情報セキュリティスペシャリスト試験に合格したので、その時の勉強方法
勉強前のレベル
Webアプリケーションを開発する場合は、OSコマンドインジェクション、SQLインジェクション、JavaScriptのエスケープ、htmlのエスケープ対応が必要だということを知っているくらいです。
試験勉強の基本的な方針
試験だけの勉強ではない、もしくは試験勉強が目的ではない
試験だけの勉強になると面白くないので、学んだことを実際に手を動かして実験します。 セキュリティ関係の実験はなかなかおもしろいのですし、実際に知識を定着させて使えるようになることが目的です。 試験はあくまで学習した内容の評価基準のひとつで、単なる通過点です。実際に使える知識にすることを目標にします。
6ヶ月の計
6ヶ月間を計画して、余裕を持って受験します。 情報処理技術者試験は春と秋にやっているので、例えば、春試験が終わったらすぐに秋試験への対策を開始するといったスケジュール感です。 6ヶ月間あれば、十分に余裕があるので多少の予定変更は吸収できます。 ちなみに、情報セキュリティスペシャリスト試験は、春・秋の両方で試験が受けられるので、スケジュールが立てやすいです。他の試験は1年に1回です。
継続的にする、習慣化する
毎週1日は試験勉強をします。リズムを取ります。学習する週やしない週をなど、可能な限りムラをつくらないようにします。 学習をしない週があれば、どうせリカバリできないので無理に次の週に頑張らずに、スケジュールを立て直します。 スケジュールは実現可能な予定に変更して管理するものです。実現できないような予定を立てても仕方ないので、そういうことはしません。
試験本番を意識する
どうせなので、1度で試験を合格できるようにします。 試験を何度も受けるのは金銭的にも時間的にも、もったいないです。 試験は1回5700円（税込み）します。2回受けたら1万円を超えます。1万円あれば、他に何かできます。 1回目不合格になって、2回目の試験勉強の時間を、実機を使って手を動かして試す時間に割り当てた方が良いです。 1回で合格する強い思いを持ちます。同じ試験を2度も受けたくありません。
過去問はダウンロードできるので、印刷します。 印刷した試験問題を使って、実際の時間で問題を解きます。 これでかなり試験当日のことがわかります。 時間がどれくらい余るのか、見直しする余裕があるか、選択問題で自分が解きやすい問題をどのくらい吟味できそうか。 また、実際に筆記することも重要です。普段はキーボードを打っているので、筆記の感覚を取り戻す必要があります。 集中力がどれくらい長続きするかなども意識します。 このような観点で試験問題をとき、当日の試験にベストになるように時間配分と気持ちを調整します。 具体的には、試験当日は次のような試験時間です。
| 午前Ⅰ | 午前Ⅱ | 午後Ⅰ | 午後Ⅱ | |
|---|---|---|---|---|
| 試験時間 | 9:30～10:20 | 10:50～11:30 | 12:30～14:00 | 14:30～16:30 |
| (分) | (50分) | (40分) | (90分) | (120分) |
| 出題形式 | 多肢選択式（四肢択一） | 多肢選択式（四肢択一） | 記述式 | 記述式 |
| 出題数 | 出題数：30問 | 出題数：25問 | 出題数：3問 | 出題数：2問 |
| 解答数 | 解答数：30問 | 解答数：25問 | 解答数：2問 | 解答数：1問 |
試験日までの流れ
試験までの流れは次の4つのタスクを自分の好きな分量で行えばよいかと思います。
予定タスク
2種類あります。 最初の全体スケジュールと途中のリスケジュールです。
全体スケジュールは、最初に全体像を把握するために、勉強するべき項目を洗い出して、試験までの予定を立てます。 この全体像を把握することは非常に重要です。この作業でおおよそどのような項目があるのかを知ることができます。 この時点でおおよその項目を知ることで、実際に学習したときに、理解度が高まるように思います。 本来なら試験日までの2/3〜4/5の期間で学習タスク（訓練タスク）が終わるように予定が立てられると良いと思います。 学習タスク（訓練タスク）の合間に試験タスクを組み込みます。このとき日々の生活リズムを反映することがポイントです。 実際の生活と乖離した努力目標のようなスケジュールは、苦しいばかりであまり役に立ちません。実現可能な予定にします。 こうしてできたスケジュールに沿って、勉強するというよりは、生活をするという意識で臨みます。
リスケジュールは、気が乗らないときや風邪を引いて、学習できなかった場合に、予定を変更する作業をします。 気が乗らない場合は勉強をあえてしないというのもありです。そうすることで心に余裕が生まれます。結果的に、勉強しないことが少なくなった気がします。 やらなくてもいいけど、予定になっているし、やっとくか、って感じです。 リスケジュールのやり方は、単に残りの全体スケジュールを遅れた分だけ後ろにずらします。そのための6ヶ月間の勉強期間です。 無理をせず、ずらしてしまいます。遅れを取り戻すことは、ほとんどの場合できません。 ただし、連続して2, 3回スケジュールを遅らせるようなことがあれば、スケジュールを立てた時に見落としていたことがあるので、それを含めて予定を見直します。 見直すときは、残りの期間と残りの学習タスク（訓練タスク）・試験タスクの量で決めます。基本的には、タスク量が平均的になるように再分割して、残りの期間に割り当てます。
試験タスク
試験問題を印刷し、通して1回分の試験を実施します。 現在の試験制度になってから(たしか平成21年度から)の試験をすべてやるように予定に組み込みます。 試験を解いて、すぐに答え合わせをします。わからない単語や問題があればすぐに調べて、メモを作成します。 このメモは、試験が近づいてきた時に、自分の弱い点を見直すときに使います。
学習タスク
理論を学ぶタスクです。全体スケジュールを立てるときに、勉強するべき項目について、洗い出しています。 この学習項目について、書籍やネットの情報を元に学びます。 私は、学習する本の内容を実際に手を使って試したり、メモを取って学びました。 私は、基本的にはやりっぱなしでしたが、復習するとより良いと思います。 ここでやりっぱなしと言いましたが、学習した項目についての理解度の評価は、試験を解くことで代用できています。 また、試験タスクでわからない点や間違った点は調べたりして復習します。 習熟度の低い学習項目はこの学習タスクとして実施します。
訓練タスク
実践するタスクです。試験問題を解いて、調べるだけでは、物足りません。実際に、PC上でどのように実現するのかなどを調べて試します。 最終的な目標としては、アプリケーションを作成したり、システムを設計する時に使うことです。 実際にPC上で学んだ知識を再現したり、試すして、試験で得た知識を自分の血肉とすることです。 時間がかかりますが、実際に学んだ知識の効果を確認することができて、面白いですし、理解度がぐっとあがります。 このタスクをどの程度全体スケジュールに含めるかは、どの程度学習項目の内容を知っているかによります。 よく知っている学習項目であれば、学習タスクの量を減らして、その分を訓練タスクとして実施すればより良いです。
ポイントをまとめると
- 6ヶ月間の予定をたてる
- 毎週1日は勉強する
- さぼったら単にずらす
- 本番さながらで試験問題を解く
- 可能な限り手を動かす
全体的なやり方としてはこのように進めました。参考にしてみてください。
