ITと哲学と

IT系エンジニアによる技術と哲学のお話。

情報セキュリティマネジメント試験を受けてきた(事前準備編)

仕事柄セキュリティに携わっていることもあり、基本情報処理技術者試験などを行っているIAPから今年新設された「情報セキュリティマネジメント試験」なるものを受けてきました。

受験地は大阪の電気通信大で結構な人数が受けていました。 なんとなーく周りの人たちの参考書をチラチラ覗いていましたが、これを使っている人が結構多かった印象です。

結果はまだ出ていませんが午前問題は結構簡単でした。午後問題は問題が長く結構苦戦しましたが、まあ大丈夫だと思います。 ので、受かってるんじゃないですかね?と思っています。 結果はまた更新するとして、ここではどんな事前準備をしたかを残したいと思います。

回答がなんか見つかったぽいので自己採点してみた 午前が46/50で午後が31/32だった。

事前準備

下記2種類の参考書を読み、下記1種類の問題集を解きました。

情報処理教科書 情報セキュリティマネジメント 要点整理&予想問題集

まずはこれを読みました。 要点がぎゅっとまとめられており、1テーマごとにとても短くまとまっているので、読みやすいです。

ただその分、少し不親切な印象は受けました。 正直これ一冊だと必要な知識は網羅できないかもしれないと感じています。

が、ある程度セキュリティ関係に知識がある人であれば試験で求められていることのアウトラインが簡単にわかりますのでそういう方々にはオススメです。

(PDF・スマホ単語帳付)徹底攻略 情報セキュリティマネジメント教科書 平成28年度(2016年度)

上記の本で得られる知識の深さに懸念を感じていたので、次にこの教科書を読みました。

書かれている内容の濃さ的にはかなり濃いように感じます。 本試験に合格する上で必要不可欠な知識よりは上かな?と感じました。 ゼロからでも時間をかければセキュリティを理解して本試験に合格することができる参考書だと感じました。

が、前述の参考書に比べるとかなり分厚いし、時間がかかります。

あ、ちなみにPDFとかスマホ単語帳は別に使いませんでした。 単語帳で勉強できたら便利かなーとか思ってましたが、なんかこう、単語と意味をガチッと一致させて丸暗記する的なのはあんまり合わないかなと感じました。 午後問題では知識を使って実践的な回答を考える必要があるので、丸暗記では対処が難しく、その背景や意味を理解しておく必要があるからです。

(PDF・スマホ単語帳付)徹底攻略 情報セキュリティマネジメント予想問題集 ベテラン講師が徹底分析!

最後にこの問題集の午前問題を試験前日に解きました。

この時点でほぼ間違えることもなかったので、最終確認的な感じでした。 が、結構実際のテストと近かったと思います。 最終確認にはいいかもしれません。

午後問題は、文章問題読むのがめんどくさすぎて、参考書の付録の1問を解いたくらいで、問題集の方も解きませんでした。 まあ、そのせいで本番で結構苦労したんですけどね。

オススメ勉強法

まずは「情報処理教科書 情報セキュリティマネジメント 要点整理&予想問題集」を読み、ざっくりとしすぎていてなんかイマイチつかめないなーと思いながらもアウトラインをはっきりさせます。これによってある程度下地が出来た状態になるので「(PDF・スマホ単語帳付)徹底攻略 情報セキュリティマネジメント教科書 平成28年度(2016年度) 」を読んでその知識を深堀ります。可能であれば問題集を解いておいてもいいかもしれません。

そんな感じできっと合格できてるんじゃないかなーと思える試験後感を得ました。

5/22追記

受かってました!よかったよかった

AWSの認定試験2つ取ってみた

仕事上AWSを使うことが増えており、どうせなのでお勉強がてら資格を取ってみた。

Solution architect associate

とりあえずAWSのサービスでどんなものがあって、どんなことができるかはすべて押さえてみた。 サービスの名前と、それらがどんなことを叶えてくれるのかが1行で説明できるようなレベルでまずは浅〜くお勉強した。

そのあとはデザインパターン本(設計と実装)を読んででてきたサービスについてホワイトペーパーを読んで自分なりにまとめた。 さらにAmazon Web Services パターン別構築・運用ガイドも最後まで目を通した。

で、模擬試験を一旦受けてみたところ6割くらいで不合格。。。

VPCやEC2の深い部分への理解が足りていなかったのでそこら辺を再度洗い直した。

合格したのは1/29だった。

Amazon Web Services パターン別構築・運用ガイド

Amazon Web Services パターン別構築・運用ガイド

Amazon Web Services クラウドデザインパターン設計ガイド 改訂版

Amazon Web Services クラウドデザインパターン設計ガイド 改訂版

Amazon Web Services クラウドデザインパターン実装ガイド 改訂版

Amazon Web Services クラウドデザインパターン実装ガイド 改訂版

Developer associate

こちらは本やホワイトペーパーでの学習は行わなかった。

ちょうど英語の勉強をしていること、Udemyが大幅なディスカウントをしていたこともあってこれを受講した。

www.udemy.com

10時間くらいの動画講義だったので朝ちょっと早く会社に行って動画見てというのをちまちま積み重ねてお勉強してみた。 最後まで通して見て、模擬試験を受けたところ9割ほど取れていたので、速攻で予約して受験した。

結果3/12に89%で合格することができた。

日本語ではこういう動画見つけられなかったので英語できると色々と捗るなと感じた。

次は今年新しく始まる情報セキュリティマネジメント資格を取って、それからSysAdminを受けようと思う。

AWS Cloud Roadshow

KeyNote1 普及期に来たクラウド。安心して企業に導入するためのポイント

去年は大阪で1000人のエントリ。今回は1300人を超えるエントリ。

クラウドとはIT利用の新しい形

キャズムを超えて普及期に入ったAWS=>2014年時点で25%の企業が利用中

Amazonのサービスを以下の観点から支えるために生まれたのがAWS

  • スケール
  • スピード
  • UX

AWSと同じことはやろうと思えば自前でもできる。 でも皆さんのやりたいことはそんなことじゃないはず。=>「価値をお客様に届ける」ことにAWSの顧客を集中させる

クラウドに踏み出せない方々の声

ICT白書によるとクラウドサービスを利用しない理由として以下の3つがよく挙げられる。

  • 必要がない(今のままで回ってるし業務)
  • セキュリティに不安(どうなの?)
  • クラウドへの移行コスト(どうなの?)

必要がないと思う人たちへ

2つのアプローチでAWSの利用を促進している。

カイゼン的アプローチ

御社のITを楽に早く安く実現できますよ

イノベーション的アプローチ

今までできなかったことができるようになりますよ

例えばソラコム

ソラコムはAWSを使ってフルクラウドな通信事業基盤を作っているので、他の通信事業者よりも格安なSIMが提供できている。 =>AWSを使うことで安くサービスが提供できるようになった。

セキュリティに不安を感じている人たちへ

導入後企業の多くがクラウド化することでセキュリティが向上するという感想を持つことが多いことがアンケートで分かっている。

なぜ?

災害対応などのために冗長化は必須だが自社でやろうとすると複数のDC契約して、それぞれを管理するというのはとっても面倒だし大変。

脆弱性対応のパッチをAWSのエンジニアが当ててくれるので早期対応ができ、自分でやる必要がない。

第三者認証もこれだけのものを自社で取得するのは大変だ。

移行コストが大変と思っている人たちへ

VPCを使って閉域網を構築できるし、専用物理サーバーを提供することもAWSではできるようになった。 すぐに試せる仕組みがあるので、とりあえず試してみましょうよ。

AWSのソリューションアーキテクトや多数のパートナーがお手伝いできます。

最後に

なぜクラウドにするとコストが下がるのか?

Sony銀行の公開している資料で詳しく説明がされているのでオススメ。

クラウドは失敗のコストを低減できる

オンプレミスでハードウェア買ってとかやってたら失敗した時に大きな損失につながる。

クラウドであれば最小限のコストで済む。

失敗のコストが下がれば挑戦のコストが下がるのでビジネスを加速させることができる!

コードネーム U.N.C.L.E見ました

コードネームU.N.C.L.E見ました。

あ、テレビ版は見たことないです。

結構面白かった!

一番良かったシーンはソロがワインを飲みながらボートを眺めてるあのシーンですねw 船の光がカメラの方に向いて強まるたびに、笑ってしまいました。

しかも裏で流れている音楽が謎にガラスの部屋

歌詞の意味を調べてみましたが「月は私たちと共に連れ添っていた」とかあって、月が出てたかもしれないなあのシーンそういえばとか思いました。

まあ歌詞はいなくなってしまった恋人への歌って感じなんですけどね。

こういう印象に残るあのシーンみたいなのがあるとやっぱりいいなーと思います。 ただ、そういう意味ではキングスマンの威風堂々のあのシーンには少し劣るかなーと思ってしまったのが残念。

まあでもキングスマンでもそうですけど、やっぱりスパイはスーツがいいですねー。 スマートな感じというか理知的な感じが出てていいです。まあガンガン銃打ったりするんですけどね。

ありがちな裏切りの例の展開も後から考えると伏線というかなんというかが貼られてていい感じです。 ネタバレになるので説明できませんが、普通そこまで××!って思ってたところが解決しました。なるほどそりゃそうだわ、と。

ソロとイリヤのキャラが正反対に立っていたのでそれも良かったです。 ソロはスーツでプレイボーイ、イリヤはカジュアルでチェリー感。 細かい技術に得意不得意があって、装備の質に差があったりして。 でも同じ目的のために力を合わせて戦って、イリヤは過去のトラウマに打ち勝って、最後には2人で酒を飲み交わすっていう。

あ、最後の展開でチームが結成されたわけですが次回作もあるんですかねー あったらいいなーと思います。あのチームの活躍をもっと見てみたい。

スパイ映画は今年3本目できっと来週あたり4本目のスペクターも見ると思うので楽しみです。

キングスマン(字幕版)

キングスマン(字幕版)

デザインパターンと共に学ぶオブジェクト指向のこころ 第6章

Facadeパターン

Facadeとは見せかけという意味の単語です。 このパターンは複雑な既存システムを自分たちのプロダクトとうまく連携させるための方法を示しています。

複雑な既存システムを簡潔に呼び出せるようなインタフェースを用意するというパターンです。

こうしておくことでクライアント側は簡潔にシステムを呼び出せるようになります。

また、カプセル化によって既存システムのアップデートの際に影響を受ける範囲を限定的にできます。

Facadeパターンを使うと、既存システムに外から新たな機能を擬似的に持たせることもできます。

例えば既存システムの呼び出し回数を記録するような機能を追加したいとした場合、すべてのシステム呼び出しをFacade経由で行わせるようにしつつ、呼び出し回数をFacadeの中でカウントするような仕組みを作るだけで実現が可能になります。

f:id:masamasah:20151129121328p:plain

デザインパターンと共に学ぶオブジェクト指向のこころ001

第1章:オブジェクト指向パラダイム

オブジェクト指向を説明するために手続き的な方法とオブジェクト指向を対比して解説をしています。

オブジェクト指向以前のパラダイムであった手続き的な方法は機能分解と表現されており、機能に着目して メソッドを分解していくやり方として説明がされています。

実生活において複雑な問題に取り組むときは問題を小さい範囲に切り分けて小さく小さく解決していくという方法はよくある方法であり、それが有効な手段であることは実生活を送る中でイメージがつきやすいし、単純明快なので、楽です。 なので、易きに流れるという意味で、何にも考えずに開発を進めていくと手続き的になってしまうのは当然のことなんだということがわかりました。 なんとなく感覚として持っていたものですが言葉にされると腑に落ちる感じがしますね。

ただ、ソフトウェアの要求は絶えず変更されることが常であり、手続き的な方法だとその変更に柔軟な設計にならないという点が問題です。なのでオブジェクト指向を学びましょうねということです。

移譲や責任についての話がその後に出てきているのですが、Martin Fowlerのソフトウェア開発における3つの視点の話を知らなかったので学びになりました。

  • 概念:私は何に対して責任があるのか?という視点
  • 仕様:私はどのようにして使用されるのか?という視点
  • 実装:私はどのようにして自身の責任を全うするのか?という視点

概念レベルでそれぞれのオブジェクトが正しく会話するように設計することで低い結合性や高い凝縮性が実現できるようになるわけですね。

3つの観点からオブジェクトを見ると以下のように説明することができる。

  • 概念:オブジェクトは責任の集合である
  • 仕様:オブジェクトはその他のオブジェクトや自らを起動することができるメソッドの集合である
  • オブジェクトはコードとデータ、そしてそれらの相互演算処理である

DDD本を第2部まで読んでみて

ここまで読んでみて現場の業務でよく使われているDDD的な語彙をカバーすることがある程度できたように感じています。

エンティティやリポジトリなど設計の上で出てくるユビキタス言語を実感を持って理解できるようになったかなと感じています。

本文の中でも触れられていましたが、ユビキタス言語の中にはこのようなDDD用語も含まれており、DDDに取り組むチームの全てのメンバーはこれらを共有できてないといけないと思います。

そういう意味でやっと出発点に立てたのかなと思っています。

一方で、学べば学ぶほどもっと根本にあるオブジェクト指向デザインパターンについての理解が大切であることも強く感じるようになりました。

ということで並行してオブジェクト指向デザパタについても深く学んでいきたいとおもいます。 取り急ぎ以下の本をタイトルに惹かれて購入しました。

オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)

オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)

DDD本の学習とここへのアウトプットは継続しつつオブジェクト指向デザパタについても並行で学んでいきたいとおもいます。