トップ > セキュリティキャンプ > セキュリティキャンプ2018　全国大会に参加して来た話 「開発運用コースでの5日間」 1日目/2日目とおまけの課題晒し

セキュリティキャンプ2018　全国大会に参加して来た話 「開発運用コースでの5日間」 1日目/2日目とおまけの課題晒し

セキュリティキャンプ 参加記録

みなさんこんにちは、azara（あざら）です。 この記事は僕が8月14日から18日までの4泊5日で参加して来たセキュリティキャンプについてお話しと課題についてお話ししていこうかなと。

3日目以降はこちら

謝辞

　この場を借りてこのようなイベントを主催していただいた独立行政法人情報処理推進機構様、一般社団法人セキュリティ・キャンプ協議会様はじめ協賛企業・協賛後援をいただいた省庁、そしてこの5日間近くで教えていただいた講師・チューターの皆様、お話をしていただいた協賛企業の社員様、出会った友人たちの皆様に感謝の意を示したいと思います。

ありがとうございます。

少し自己紹介

まず、著者のスペックについてお話ししていきたいなと。

名前 : azara
情報系の学部に入り : 1年3ヶ月
好きな分野&得意になりたい分野 : web(主に開発)とセキュリティ全般
選んだトラック : 開発運用

セキュリティキャンプ is 何？

詳しい内容はこちらの独立行政法人情報処理推進機構(以下IPAと記載)が記載している説明からどうぞ。
要約すると22歳までの若い高度IT人材の育成と発掘をするためにIPAと一般社団法人セキュリティ・キャンプ協議会が主催する参加費無料のBootCamp的なでっかなイベントだと僕は理解してる。
このセキュリティキャンプではその道のプロや有名人などの一流の方々から直接教えを請うことができ、自分たちの数年後と照らし合わせられるその道の先輩方、また同じ趣味を持つ仲間たちと約1週間一緒に生活ができるというのが特徴が！

なぜ参加したのか？

上の内容を去年参加していた先輩やTwitterから情報を手に入れていた僕は
「めっちゃすげえイベントがあるじゃねぇか！」
と思っていたんですね。それ故に自分の今後の道のりの中継点にこのキャンプに行けたらどれだけ最高なのだろうかと ・・・
そして今年の4月25日に2018年度の募集が始まり僕を含め同じ学校から数名このキャンプに応募、ただこの時に僕の中で一抹の不安が、それは「こんな1年目の小童が選考を通ることができるのだろうか・・・・」という不安だよ。

それでも気合と根性とちょっと少しの技術とで合格までたどり着けました。 その際の応募課題もおまけに貼っておきます！

1日目から最終日まで

1日目

　8月14日(火)この日は、雲の少なく空がきれいに見える日でした。最高気温は33度焼ける暑さ。
12:00 受付開始と書かれていたにもかかわらず、楽しみが勝り僕が現地に到着したのが10:00・・・
2時間も早くついてしまい「外で待ってみるか...」と佇む、10分後にチューターさんがコンビニから帰ってきて「入って待ってたら？」と言ってくれてやっとく中に潜入成功。

セキュリティキャンプの看板

　そこから20分後には続々と参加者の人たちが現れる現れる。そして始まった第1回名刺交換タイム！
こういったイベントはつかみが大事だ！スタートダッシュで躓くと誰とも話さないで終わる...そこで僕はすかさず入ってきた集団と名刺交換！.....ん？そこにいたのは前回のミニキャンプ神戸で出会っていたC0lumb1n3くんがいたのです。そこで僕の中で安堵が
「知り合いがいてよかった！」
その後、神戸のミニキャンプで出会った人たちやその場で出会った面白い方々とお話をして昼食へ、その時の昼食がこちら。

f:id:oukasakura3:20180819202702j:plain

昼食後に開会式の会場へ。 　開会式では経済産業副大臣の西銘恒三郎さんやIPAの理事長 富田達夫さん、そして一般社団法人セキュリティ・キャンプ協議会会長西本逸郎さんから挨拶があり開会式が終了。
　その後オリエンテーションやセキュリティの基礎、OpenSourceConferenceの宮原徹さんや技術のわかる弁護士 北條孝佳さんからの講演を聞かせてもらいました。 　オリエンテーションとセキュリティの基礎では「人間はすべてを台無しにする権限を持っている」という話や、失敗から学ぶといった話をしてもらい、僕は今まで失敗をまとめてこなかったなということや、同じグループの人たちとこのことについて話しました。OSCの話では「外部に発信する、そして目的の達成と自己満足は違い、手段と目的を取り間違えない」といった話があり、今後さらに活動するうえで大切なことを学びました。北條さんからは「ハッカーはなぜ法律を破るのか」という題材でITやセキュリティにかかわる法律の解説や行動を起こす前に考えるべきことについてお話を聞き、あぁ…少しは法律を知らないと知らず知らずに破ってしまいそうで大変だなと思いました。

そしてここからは夕食です。 先ほどの昼食もそうですが、朝昼晩と何もせずに出てくるこの環境が一人暮らしをしている身からするとすごくありがたい...
f:id:oukasakura3:20180819204452p:plain

夕飯はこんな感じ！すごくバランスのとれたおいしい食事でもはや涙が出てくるほど

f:id:oukasakura3:20180819204544j:plain

　夕食後は1日目の締めであるLT大会とグループワーク！ LT大会では平然と家にはサーバーが余っているものだという人やLPWANといったIoTの通信に関して話すすごい人や海外留学のすゝめをしてくれるチューターの方がいたり、Wiiの本当の遊び方を熱意あるお話をする人がいたりscratchでドローンを飛ばす人がいたりARMについて熱く語る人がいたりとすごく楽しくお話を聞けました。

　グループワークではグループでワークをするのではなく会場の人たち(チューターや講師・協賛企業の方)に今後の自分を照らし合わせながら話を聞くといった楽しい時間が待っていました。僕が今後歩くであろう道やその業界でのはなしを聞けてすごくためになりました。 　 1日目はこれで終了！みんな23:00には寝ましょう！とのことだったので就寝。

2日目

2日目から講義が開始です！この日は必須講義のみでこのような感じでした

講義講師
クラウド・ホスティングサービスのセキュリティと運用技術の研究松本 亮介 先生
ビヨンドブロックチェーン斉藤 賢爾 先生
Vulsとエクスプロイトで学ぶ、既知の脆弱性管理の重要性と効率的な対策方法神戸 康多 ・ 福田 鉄平 両先生

　この日は朝から若干の眠気が襲い掛かってくる…なんせ普段あまり早起きをしない性格で不健康な生活をしている僕が6:00に置き身支度をしているのだから。

　そして朝食の始まる6:30、朝食会場に向かうと思ったより多くの人たちが朝からいるではないか。前日の昼や夕は知らない人のところに駆け寄り話しながら食べたが朝はそんな元気がないので一緒に来た友人と朝食。だけどここはセキュリティキャンプ、みんな一人でいると着て話をしてくれるとてもうれしかった。
そんな朝食はこんな感じ

f:id:oukasakura3:20180819212540j:plain

ここのフレンチトーストがおいしくてこの後毎日フレンチトーストの為に起きていたのはまた別の話。

朝食後は軽く抗議の内容を見よう…としたが自分の所属するトラックの資料がほとんど乗っておらず本を読み始める。 そして講義が始まる

クラウド・ホスティングサービスのセキュリティと運用技術の研究

　この講義はGMOペパボでクラウドの研究やOSSの開発者として有名な松本 亮介@matsumotoryさんが講義をしてくれました。

　この講義ではクラウド・ホスティングサービスにおける高集積マルチテナント方式や大量のSSL/TLS証明書を管理する手法といった松本先生の研究する分野の話や技術の言語化(論文化)による改善のサイクルと学術への昇華といった話を講義していもらいました。

　普段使うような、サービスの裏側を知れ、さらにこのような研究があるからこそ大規模クラウド基盤を支えながらスムーズな運用ができるのだろうなと実感しました。僕自身がこの講義で最も心に残ったこととして松本先生がおっしゃっており、先生自らの研究テーマであるWebサービス利用者のユーザー体感の改善「当たり前に普通に違和感なく使い続けられることの快適さ」といった点で、僕は少し畑が違いますが同じような思いを持つ先輩エンジニアの考えとその手法を目の当たりにし僕の心の中ですごく熱い心が湧き出てきました。

　さらにこの講義では、セキュリティ的観点からリソース管理の重要性(可用性の確保)や隔離の分類による機密性の違いやプロセスレベルでの権限分離といった話をしてもらい、今後僕がサービスを展開するような機会が訪れるまで知識として頭にとどめておきたいと思いました。

　割ともらった資料の重厚さがあったので読み終わったら別枠で書くと思います。

昼食

f:id:oukasakura3:20180819215308j:plain

うまい(うまい)

ビヨンドブロックチェーン

　この講義のでは慶応義塾大学SFC研究所上席所員で環境情報学部講師の斉藤賢爾先生が講義をしてくれました。

　普段僕はブロックチェーンについて勉強も、使うこともなくどんな技術なのか？と思っていました。それ故に楽しみだった講義です。この講義でははじめにブロックチェーンとは何なのか？という問いから始まりました。
　この講義ではDLT(分散台帳技術)における改ざんとデータの確実性、そして仮想通貨における運用と技術、そしてブロックチェーンの技術的アーキテクチャとハンズオンといった流れで進んでいきました。

　DLT(分散台帳技術)における改ざんとデータの確実性においては、分散型台帳とは何のための技術であり何を保証しているのかという点で進められました。この講義では内容の否定の無効化(否定をさせない)といった点や改ざんがされていないという保証、そしてそのデータ等をだれにも阻止するすべを持たせないといったことがありました。そこからこの技術における課題や、転用できない分野(すげ替えのできる物におけるデータの正当性やプライベートDLTにおける阻止や否定の可能性等)などの話を聞き、ビットコイン当の仮想通貨の話になりました。

　先のDLTの話を前提に置きビットコインの生みの親とされているサトシ ナカモトの問いとそれに対する答えについての説明がありました。さらにこの仮想通貨における正当性の保証や存在性の証明、またナカモトコンセンサスやそれらの理論をより分かりやすく解説していただきました。 　 　そして最後に斉藤先生の制作しているBBc-1のハンズオンでこのDLCの改ざんについてなどを学びこの講義は終了しました。

　この講義で僕自身初めて触れるDLTや学ぶことがなかったこれらの技術に対する知見を得られたほか、公平性から見たDLTのすばらしさに感激しました。

夕飯

楽しすぎて・・・とるのを忘れ始めます・・・ごめんなさい。

確かこの日はオムライスを食べたと思います。このオムライスの卵がトロトロでおいしかったことは覚えてます！

Vulsとエクスプロイトで学ぶ、既知の脆弱性管理の重要性と効率的な対策方法

　この講義ではVulsの生みの親である神戸先生と福田先生の2名で進んでいきました。
　まず初めに脆弱性の説明やCVEなどの見方、エクスプロイトコードやPoCの書き方、そしてVulsの使い方などを教えてもらいexploit演習へ、まず初めにGitの脆弱性(CVE-2018-11235)によるRCE攻撃の実践を試してみました。この際僕はというと、初めてこのようなexploit演習を行ったのでワクワクと周りにいろんな人がいて画面をのぞかれることに対する嫌悪感と闘いながら講義を受けていました。この演習で理解しながら進んで行こうと思いながら演習をしていたら自分の悪い癖でいろんなことを試してみたくなってしまい少し寄り道。一応最後までこの演習を終わらせ、二つ目の演習へ。

　二つ目の演習では先ほどのCVEの見方や情報収集の仕方をもとにさらなるexploit演習へ、二人一組のチームで問題を解いていきました。その際Vulsで検出した脆弱性に対し公開されているPoCを改造し流しながらフラグをゲットしたりとして一応2問は収穫…ただ理解の仕方がまだ至らず...

　最後にVulsの生みの親である神戸さんからOSSのコミッターとしての話しや誕生秘話などを聞きこの講義は終了しました。

　そしてこの講義で学んだことは筋トレが大切であり、みんなでジムに行こうとの大切な知恵を学んだ！

　実践形式で学べてすごく楽しい講義でした！

グループワーク

　この日もお話を聞く会でした。この日は企業の方とお話しすることが多かったです。大手企業のセキュリティ部門の話や部門間での移動に関してお話をしました。

今回のおまけ

　今回のおまけは応募課題晒です。 　正確に言うと応募課題をさらし忘れて今頃さらすけどいつさらそうかと迷った結果ここで晒さざる得なくなりました。

間違った認識やおかしな部分もあると思いますが心を菩薩のようにしてみてください…

======ここから応募課題====== 　

共通問題

問1

ブログや、Twitter、GitHub、Slideshareなど公開している活動や資料があれば、URLなどを記載してください。

Twitter: https://twitter.com/ROT13bhxnfnxhen
GitHub: https://github.com/WestEast1st
Qiita: https://qiita.com/A_zara

問2

セキュリティ・キャンプ地方大会などのイベントに参加していれば、それを記入してください。

第3回 脆弱性診断 初心者ハンズオントレーニング
セキュリティ・ミニキャンプ in 兵庫 2018 専門講義

問3

自分のスキルについて、得意としている、あるいは得意としたい技術領域について、なぜその技術領域が好きなのか、その技術領域でどんな世界を作っていきたいのか、好きなだけ語ってください。

　私が得意とした技術領域、それはWeb技術領域であり、開発をはじめ、デザイン・設計・セキュリティ全てを愛し、得意としていきたいと思っています。

　私は、去年の春からこの情報技術分野に足を踏み入れました。私自身はもともと中学生の時は社会系の科目が好きで、世界史や日本史、さらに地理といった教科に没頭し、よく山川出版の世界史/日本史/地理B用語集や世界地図、またいろんな時代の歴史小説などを読む一風変わった日本史や世界史といった歴史が好きの子供でした。そして高校の時も変わらずその生活は続き、特に問題がなければそのまま史学科に入りそのまま史学の道を進む予定でした。ですが人生と言うものはうまくいかないもので志望校には2回の試験を受け、どちらも失敗と言う経験をしてしまいました。その間の2年間の浪人の中で、私は何か自分を変えてみなければ流れは変わらない。そう思いそもそもの方向性の転換を行いました。そしてこのかじをとった方向こそこの情報技術分野でした。

　6年間、歴史命だった私が初めて見る風景、どこを見ても新鮮なこの世界に、私は子供のように胸を躍らせながら、どの分野に触れるのが自分の性に合うのかを探していました。そのために何度も本屋に通い、先輩方からも話を聞きやってみよう触ってみようでいろんな技術に触れてみました。その中ひときわ目を引くものがありました。それがWebというものでした。私のWebという技術領域との出会いはこのような出来事からでした。今までは検索サイトで調べ物をしたり、ブログやSNSなどの使う側でしかない人間で裏の技術や仕組みなんて何にも知らない状態でした。 そうした中、突如中学の頃、初めて歴史に出会った時のような好奇心が湧いてきたのです。「このサイトの裏ではどのような動きをしているのだろうか？」という疑問を持ち、この疑問からさらなる疑問が生まれると言う連鎖が始まりました。例えば、このWebページはどのように作るのか？サーバーサイド？フロントエンド？SSL/TLS？パスワードや住所などの個人情報はどのように守られているのか？などの疑問の多くが、私の中の“知らない”そして“知りたい”を刺激してくれました。この好奇心や知識欲といったものを満足させたいと私は思い、この道に足を踏み入れたのです。

　この技術領域に足を踏み入れてから私は、まずはじめにWebページの基礎である、HTMLやCSS、また動的コンテンツを表現するためにJavaScriptやPHPといった開発言語を学びながら、安全なWebアプリケーションを作るためのセキュアコーディングの基礎を学びました。その中でどのようにコーディングを行うとぜい弱性が生まれ、どのような攻撃パターンを入力し検査を行うとそのぜい弱性を見つけ出せるのか、そしてそのぜい弱性を生まないようにする方法身につけました。ですが人というのは変わった生き物で、身につけたものは一度は使ってみたいと思ってしまうようで、私もその衝動に駆られてしまいました。ですが法律では不正アクセス禁止法や刑法の器物破損で罰せられてしてしまう場合もあり、さすがにそのようなことをしてしまうのは問題だろうと思い自分自身でWebサイトを制作しました。そこではSQL injectionやstored/reflected/DOM-based XSSなどのよく知られている攻撃だけでなく、CSRFやheader injectionといった一味変わった攻撃も再現し、どこでそういったものが発生するのかについて学びました。

　そういったセキュリティについても学んではいましたがその際に制作した自作サイトの構築が思ったより面白く、私はこの技術をまた違う場所で、私はこの技術をまた違う場所で使いたいと思い、校外に出て学んだことを活かし、課題解決に貢献できる場所を探していたところ、長期のエンジニアインターンシップを見つけました。私はそれに参加することで考え方を大きく変えた、とある一つの出会いがあったのです。それは、"このネットの向こう側にはユーザーがいる、そのユーザーが使うことによってサービスが成り立つのだから、そのユーザーの不快感を減らし使いやすさを追い求めなければならない"という、UXと呼ばれる考え方でした。私たちエンジニアが心がけるべき事の一つであると教えられたこの考え方は、自分のための開発を楽しんでいた自分に、衝撃と感動を与えてくれました。そして、私はさらにWebを好きになりました。

　私の中では、この考え方は心にのこるものであり、今まで考えてこなかったものだからこそ、さらに良いものを作ろうとなったのです。そしてこの考え方を持ってセキュリティや開発をすることによって、自らのためではなく自分を含めたみんなのために作り上げ、そして全員が気持ちよく使えると言う観点で物事を見られるようになれました。さらに新たな知識を身に付けたいと思うようになりました。

　インターン先でも普段触れることのなかったSPAやCDN、またPaaSと言う新たな技術を今までより積極的に触れて行きました。またフレームワークやOSSといった技術的選択肢にも多く触れられ、さらにそれをどのように組み合わせ、構築すればユーザーの望むサービスを展開できるようになるのかについて学べました。

　私はこの1年で知らなかった多くのことを学びました。ですがこのWeb分野というのはさらに奥は深くまだまだやっていないこと、やりたい事が多くあります。そうした中、私はWebという技術領域を学んで行く上で、自分自身の目指すエンジニア像というものを持ちながら歩みを進めています。

　そのエンジニア像は、初心を忘れずに現状への疑問を持ち、常に求め、経験を活かせるエンジニアです。まだ私はこの技術領域、そしてこのITの世界を知らなすぎて迷うばかりです。ですが、その先の見えない世界の中で私は、1700年代後半のアメリカ大陸に渡った開拓民のようにこのITという広大な平原を先へと進んで行くしかないのです。そのために私は学生のうちにWebを始めとするITの盤石な基礎知識と、それを活かせるようなトレンドのキャッチ、そして自分自身の好きも深掘りできるように頑張って行くと決意しています。

　最後に私のこのWebに抱く世界観と作り出したい世界について話して行きたいと思います。 　このWebと言う技術領域はこの私たちの住む世界でガスや水道のような社会インフラのようなものになってきています。そのWebと言う社会インフラの汎用性と誰しもが触れられるフラットな世界観であり、そのWebと言う世界が私は好きです。そして汎用だからこそどのようなことでもでき、誰しもが触れられるからこそ人間を選ぶことなく入れてしまう、そんなWebと言うのは危険とも隣り合わせであり、不意な事態で大きな事件が生まれてしまう。そんなWebをより安全で、より私たちの生きる世界の一つとしてもっと素晴らしいものにして行きたいのです。

　そうそして、Webと言う技術領域で私は、全員が家や自分の落ち着ける場所のような安心感を持てる世界、そして分け隔てなく利用する人々が自分の手足のように利用できるさらにフラットな世界を作り上げていきたい、そしてそれを利用する、作り上げる仲間たちとともにこの意識を分かち合い一緒に歩んでいきたいと私は思っています。この魅力的な輝かしい未来へとつながる世界を私は進んでいきたい、作り進めて行きたいと思います。

　〜〜だからこそ、私はWebと言う全ての技術を学びたいと思ったのです。〜〜

問4

あなたが今まで作ってきたソフトウェアにはどのようなものがありますか？ また、それらはどんな言語やライブラリを使って作ったのか、どこにこだわって作ったのか、たくさん自慢してください。

昨年の春に、ITの世界に踏み入れた私はそこまで多くを制作してきたわけではありませんが、数少ない制作物の中から自分の心に残り自分自身に何か成果を残してくれた制作物を下記に示したいと思います。

制作したもの

Python3でまるばつゲーム
Python3でPOSTとGETを送るだけのツール
自作やられWebサイトversion 1.0
新入生向け学内CTF向けサイト(Laravel+Vue)
インターン先のWebサイト
作って来たものを一つずつ話していきたいなと思います。

Python3でまるばつゲーム

　初めてプログラミングをした際に制作したCUIベースのまるばつゲームで、はじめのうちはライブラリといったものは使っていませんでした、自分自身にとって初めてのプログラミングであり、変数とは何か？ifやwhileと行った基礎的関数はどんな意味を持っているのか？配列はどんな構造なのか？と言う部分から入りました。連想配列の利用や配列内の情報照合、また縦横のマス数変更などの機能を実装しました。さらにゲーム性を高めるためにrandomモジュールを使用しNPCを実装したり、そのNPCを強化するために2/3以上の配置数や縦横の１列に相手の駒がない際、ほかには角を優先して配置などの各種優先度をつけるなどをしてこの要件を達成しました。この初めてのプログラミングで基礎的な原理やアルゴリズム、また自分で発想して実装するといったこともできるようになりました。

　このゲーム作りを振り返ってみると、ここでリファレンスの読み方や基礎的な部分を学べたのかなと思います。

Python3でPOSTとGETを送るだけのツール

このツールは、私がPythonで制作したまるばつゲームやその他の制作物を制作してで学んだことをより一層活用できる場はないかと思い制作に取り掛かりました。

　その時期に読んでいた徳丸浩先生の体系的に学ぶ安全なWebアプリケーションの作り方(通称:徳丸本)、さらに先輩からのアドバイスを元にWebアプリケーションに攻撃を投げるために制作しました。

　当時はburpやZAPなどの使用方法やそもそもの存在を知らなかったことから自らintruderのような機能を作って、それを試しては改良してということを繰り返し、多くの最終的にはレスポンスコードの表示と配列を利用したヒストリーのような機能も追加し、体系的に学ぶ安全なWebアプリケーションの作り方で使用されていたfiddlerの一機能を再現できたかなと自負しています。この開発でrequestsとurllib(request/error)と言う二つのモジュール(ライブラリ)を試して制作をしました。自分自身の個人的な感想ではありますが、requestsの方がわかりやすく組みやすいと思い、最後までrequestsを利用して開発をしていました。

　このツールはオブジェクト指向をがん無視した1ページでのコーディングをしており後々見ると長くみにくいコードになっており次の自作やられサイトからみやすさを意識したファイル分割をしrequireを利用し必要なファイルを読み込む形でコーディングをしました。

　この開発では、HTTPレスポンスを理解しながらヒストリー内検索のためにreライブラリなどを利用し必要なレスポンスのみを出力するなどを実装したことで、ツールの内部でどのようなことが起こっているのかが少しは理解できたかなと思いました。

自作やられWebサイトversion 1.0

　学校制作も慣れてきた6月ごろから進めてきたPythonのツール開発ですが、その中で常にPOSTやGETを送っていた徳丸本のやられサイトでは少し物足りなくなり、自分自身でこのやられWebサイトを作ってみたいと思いこのWebサイトを制作しました。

　今までPythonでプログラミングをやっていたものの、PHPやJavaScriptについて徳丸本で触れる程度の知識しかない私は、一からPHPについて、そしてJavaScriptについて学んでいき、それらの言語を利用し開発をして行きたいと思い制作しました。そして、このやられサイト構築を通して私は、Webサイト開発に必要なPHPやJavaScriptといった言語の基礎的な部分に触れられました。さらに初めてLAMP環境の構築なども行いさわりだけではありますが、サーバーを立て、APIを制作し、非同期（Ajax）を使い情報取得するなどの初歩的ではありますが一連のサイト構築の流れを把握できました。

　この構築までの段階で苦戦した事が数件あります。一つ目は、初めての使用となるPDOに苦戦をしました。その際に、取得した複数件結果の取り出し方やプリペアドステートメントなどのを利用したクエリ実行関数を実装する際に複数のプレスホルダの置き換えの仕方などについてわからない事がや結果取り出しの定石の原理理解に少し時間がかかりました。この開発で初めてオブジェクト指向的な考えに触れることになりmethodやクラスに触れそちらの使用に関しても手こずりました。二つ目はサーバーの立ち上げです。この際初めてのUnix系の操作でサーバーを立てました。HTTPサーバーはApacheでデータベースはMysqlでこれをうまく繋ぐことに苦戦をしたり、そもそものVMとのIP割り当てが変動しSSHができなかったりと初めてづくしでネットに頼りっきりになっていました。3つ目はJson形式での非同期通信についてです。まずはじめにAPIの返信の仕方に苦戦をしました。本来であればヘッダー情報にcontent-type : application/json ;charset=utf-8を入れなければJSONで返信をしないのにそれをせずにデフォルトの文字での返信を行なっていました。Ajaxでエラー連発、その際に検索等をした結果ヘッダーの付与を忘れていたことによる問題だと判明しひと段落しました。

　このサイト構築で学べたこととして上記以外にも、SQL injectionやXSSといったぜい弱性の基礎的な再現や、これらを防ぐセキュアコーディングなどに関しても学ぶことでできました。

新入生向け学内CTF向けサイト(Laravel+Vue)

　このサイトに関して前置きとして、サーバーサイドは制作はおおかたのスケジュール通り終えていてリリース手前の段階まで持っていけているのですが、フロントの開発の遅延があり7月ごろまでに完成し8月手前までに公開ができるように調整を行っています。それでは本題に入らせていただきます。

　私が所属しているサークル内で、2018年度に入学する1年生向けに一つCTFを作ろうという企画が上がり、そのサーバーサイド(Laravel)の制作とフロント(Vue)の制作支援を担当し、初のチームでの開発での制作をしました。

　このサイト構築の際に開発チーム内で、フレームワークを使わずにPHPとJavaScriptで制作をするか、フレームワークを使って構築をするのかについて話し合いを行い普段触れにくいフレームワークで開発しようと決定しました。自分自身はインターンがその時には決まっており、このフレームワークを利用することは決定していました。ですが触れること自体は初めてで、このコーディングをしたことのないフレームワークに不安もありましたが、"触ってみたい"と言う気持ちに後押しされ実際に触ってみることに決めました。フレームワークに触れてみると今まで無印のPHPやJavaScriptでは触れることのなかったURLでのページルーティングと言う機能やMVCと言う概念、O/Rマッパーといったデータベース操作を行う機能、そしてSPAと言う私の知らなかったWebのはやりなどに触れました。

　このCTFシステムを構築する際にはじめに行ったことは、APIのレスポンスデータの設計とデータベースの設計を行いました。この設計の際にフロント班のリーダーと話し、どのような情報が欲しくてどのような機能を実装して行きたいかをすり合わせながらAPI設計の修正などを行いました。このことについて一つずつ話して行くことによって自分自身の自己満足のためだけではなく"他の誰かに提供するために制作する"と言う課題を複数人で共有するなど、チーム開発の中で重要なことが少しは学べたと思っています。そして普段設計などを行わずに行き当たりばったりでの開発を行っていたので、設計をしてからの開発やチームでの開発に不安はありましたが、実際に開発を進めてみるとチームで作品を開発することで早く開発を進められ、設計をすることでコーディングの機能で迷うことが無くなっていました。

今の感想 (結局この開発は一人でやることになりましたが…そして9月までにスケジュールが伸びました) 　

インターン先のサイト

ごめんなさいここの部分は訳ありで削除しました

まとめ

　この1年私がどんなものを作る上で考えこだわった点が三つあります。一つ目はこの技術はどのようなとこれで使えるのか？そしてこの技術をどこで活用すればより面白くなるかと言うことを考えること。二つ目はこの経験した驚きや初体験の時のドキドキを忘れないこど。三つ目は作るだけでなく、それを次に活かせるところを探すと言う点です。

　この三つは一番初めのpythonのまるばつゲームの時から同じでまるばつゲームで得た基礎的なアルゴリズムはその後のプログラミングでも生かされるような考え方であり、二番目のツールも現在製作途中のため書きませんでしたがTwitterの画像を拾って来るためのスクレイピングツールに使われています。そして三つ目のやられサイトは、自分で制作して初めて完成させたサイトであり、それが完成した時の嬉しさはCTF向けのサイト構築やインターン先で制作したWebサイトでもまだ残り続け、Webと言うものは楽しいものである、物作りは楽しいと言う気持ちをまだ忘れていなかったこと、さらにこのそのやられサイトで原理を理解するためにUNION SQLinjectionが通った時の喜びと言うものは今でも私の中でのモチベーション向上に繋がっているのかなと思っています。

　このように私はその個としてのものを作る上でのこだわりと継続して持っているものを作る上でのこだわりというものがあり、前者は品質としてのこだわりが大きく、後者は心情的なこだわりというものが大きいと思っています。私はこのこだわりを今後も持ち続けながらより良いものを今後も日々精進しながら作って行きたいと思っています。

問5

あなたがこれまで利用したことがあるインターネットサービスの中で一番すごい！と思ったものについて、技術的なのか、仕組み的なのか、ビジネス的なのか、どんなところがすごいと思ったのかを説明してください。

何をすごいと思ったもの

　私は今年の3月頃にリクルートの元社員が起こしたベンチャー企業にエンジニアインターン生としてインターンに行き始めました。そのインターンに行き始め上司に私の今やりたいことや、自分のなりたいエンジニア像というものを話し、今後のロードマップに関して相談をしたところ、その上司からとある記事を読んでみてよと言われその記事と出会いました。その記事には、普段ご飯屋の予約の際に利用するホットペッパーやバイト探しに使ったタウンワーク、引越し先を探すときに使ったスーモといった各種ネットサービスを展開するリクルートの全社が共通で利用するプライベートクラウドの構築と言うことが心の中にあるこのサービスめっちゃすごい！と言うものでした。ネットサービスの提供に必要不可欠とも言える基盤構築とが私の中ですごくどきどきするものがあり、この話は私の中ですごくドキドキし、各種サービスはどのように動いているのかに興味を持つきっかけになりました。それではそのリクルートの全社共通のプライベートクラウドについて話して行きましょう。

　まずはじめに全社共通のインフラ基盤をなぜすごいと思ったのかについてお話ししていきたいなと思います。まず前置きとして、リクルートで行っているインターネットサービスは現在統一されたオンプレミスのプライベートクラウドと一部機能をパブリッククラウドで実装する複合環境で提供されているようです。しかし2009年以前はインフラなどに複数の課題を抱えていました。私はその課題の解決の仕方と現在のリソース提供の仕組み、そしてビジネスに寄り添ったインフラの提供ができるようになった仕組みに私はすごい！となりました。それでは、その課題の解決の仕方とその仕組みについて私の知る限りですが話していきたいと思います。

2009年以前の課題というのは、
- 4つのデータセンターに数多くのサーバーを設置
- データセンターごとサーバー/ネットワーク/ストレージにベンダーの異なる機材
- サービスごとに専用のインフラ基盤を構築しエンジニアを配置
- インフラを個別で最適化拡張を行いリソース余剰の共有ができずリソースの無駄が発生
- 数多くの新規サービスの立ち上げや環境の増改築・運用などでエンジニアを増やすことにより人件費が増加
- ビジネススピードが加速する一方でインフラのサービス提供が間に合わない状態
と課題が山積している状態でした。

　この課題を解決するためにリクルートテクノロジーズ(リクルートグループの横断機能領域企業)では大きな計画を立ち上げました。

　それは前述した現在使用されているプライベートクラウドを立ち上げです。今までは個別のデータセンターで異なる機種のインフラ機器を使用していたのを、全部仕様から機種まで統一を行いそれをリソースプールとしました。それにより課題となっていたベンダーが異なる機器を標準化し、設定や運用の画一化がなされました。これにより整備や運用が容易になったとされています。さらにこのリソースプールにより、論理分割を行うことや、各サービスにリソースの再分配や融通などが行えるようになり無駄の発生を防ぐこともできました。さらに今までは個別最適を行い必要に応じて発注などを行っていたのでその点でもリソースプールは活躍しました。

　この機器の統一でさらなる恩恵が得られた箇所がありました。それは課題として上がっていた数多くの新規サービスの立ち上げや環境の増改築・運用などでエンジニアを増やすことにより人件費が増加という点とビジネススピードとインフラサービスの提供に関する課題です。

　この課題において、問題となっていたことが"インフラコストの約半分は構築と運用の人件費"だったということと、サービス提供に時間がかかってしまうという点です。このまま新規サービスが増加しビジネスが拡大して行くといくらお金と時間ががあっても永遠と人件費は膨れ上がり、時間はかかってしまうという状態になっていたのです。その人件費、そして構築・運用の時間をできる限り抑え、迅速なインフラ提供をするためにに自動化を行ったのです。

　この自動化の手法はこのようなものでした。まず初めに各種構成情報をデータベース化し管理、それを自社開発の自動化システムと構成テンプレートを使い自動管理・構築を行ったのです。この自動化はRAID分割やOSのインストール、そしてミドルウェアのインストールと設定までを行う、この自動化で得られた効果が絶大で、リソースプールによる機材発注の効果も含めインフラ提供までの時間が3分の１まで下がったのです。

　これにより課題は解決されビジネススピードに合わせたインフラ提供ができビジネス機会のロスを防ぎ、柔軟なリソース調整ができるようになり現在のリクルートの多種多様なネットサービスができていると思うと素晴らしいものがあります。

まとめ

　今ではAnsibleなどの自動化ツールやDockerなどの環境のコンテナ化技術が多く出回っていますが2009年にこの自動化技術を実装し、運用段階にのせサービスの抜本的な改革や効率化した技術、ビジネス的機動性を考慮した方向転換、そして大規模展開されたネットサービスを支えるインフラ技術とリソースの効率の良い分配のできる仕組みをすごいと思いました。さらに現在のリクルートではネットサービスを自社のプライベートクラウドとログ分析収集の基盤やプッシュ通知を送る基盤をパブリッククラウド(AWS)へと各種機能の分割などを行いさらなる運用効率の向上を図っているようなのでネットサービスの基盤拡充の姿勢がすごいと思う次第です。以上が私がすごいと思ったインターネットサービスです。

　私はこの記事からこのリクルートのプライベートクラウドについて調べる機会を与えられ、一つの手段としてのオンプレミスでのサーバーの重要性やその後のリクルートのインフラについて知る事ができました。この知見は私の今後にある何に役立つかなどは直接はわかりません。特に学生のうちにここまで広大なプライベートクラウドと出会うことも触ることもないでしょう。ですがこの知識は私に大規模サービスを展開する企業のインフラというものはこのようなものであるというアーキテクチャモデルをくれました。

　そして、この記事を読むことで私は学生のうちには経験のできない大規模なサービスの裏側を実体験せずに知見を得られ、その良かった点や悪かった点を学べたのです。 　

問6

今年のセキュリティ・キャンプ全国大会で受講したいと思っている講義は何ですか？
そこで、どのようなことを学びたいですか？なぜそれを学びたいのですか？
講義を担当する講師に響くようにアピールしてください(複数可)

B1:クラウド・ホスティングサービスのセキュリティと運用技術の研究

　　去年からITに触れ始めた私は、この1年間サービスの開発と運用について学んできました。そんな私がなぜこの講義を学びたいか、それを今から書いて行きたいと思います。まずはじめにこの講義で私がすごく気になっている点、それはクラウドホスティングサービスの最新運用技術動向についてです。私自身趣味でConohaやAWS、インターン先ではHerokuやさくらVPS、Azureなど数々のクラウドホスティングサービスに触れる機会がありまして、その中で自分自身でも興味があり私が使っているサービスや他のPaaSやIaaSなどはどのように構築され、どのように運用されているのかについて調べていくことが多くなりました。そうしているうちにますます興味が湧き始めた頃、このセキュリティキャンプの募集が始まり講義の内容を見てみるとこのクラウドホスティングのセキュリティと運用技術の研究という講義があり、是非ともこの講義を受けてみたいと思いました。

　この講義で学びたいことして、講師である松本さんが研究を行なっているテーマや専門分野であるWebサーバのセキュリティ・パフォーマンス・運用といった点や大規模証明書管理についてのお話が聞きたいと思っています。その理由として、松本さんの所属であるGMOペパボでもホスティングサービスを展開しており、そのWebサーバでのセキュリティ管理の手法やパフォーマンスチューニングの手法、また各種OSSとの運用についてや各種ホスティングサービス上でのSSL管理の手法を知りたいと思っています。その理由として将来もしWebサーバーを運用もしくは頼むとして、現在のざっくりした知識ではなくしっかりと知識を学び、それを発展させながら得た知識を利用しユーザーへの迅速で安全なサービス提供を行えるようになりたいと思っているのでこの講義を学んでゆきたいと思っています。

B3:Vulsとエクスプロイト演習で学ぶ、既知のぜい弱性管理の重要性と効率的な対策方法

　私がOSSのぜい弱性と言うものがあると言うことについて知ったのは去年の8月ごろでした。その時から少しずつCVEやIPAなどの配信する情報を眺めることがあったのですが、その量が尋常じゃないほどあるのでこれを実際に企業のサーバーやサービスを運用する人が見たら卒倒しそうだなと思いながら眺めていました。

　Webアプリケーションを提供する上で多くのOSSを利用する機会があり、そのOSSのぜい弱性管理はすごく手間のかかるものかと想像できます。いつどのようなCVEが公開され、それが今使っているOSSであるかどうか、またその変更がサービスに影響しないかなどを一元的かつ迅速な把握と対策を行えるVulsを一度触ってみたいと興味を持っていました。またこの講義ではそのvulsを使用した既知のぜい弱性へのエクスプロイト演習を行うとのことで、自分自身がこの既知のぜい弱性への攻撃手法を学んでみたいという気持ちがありその脅威度など、この身を以て体験してみたいと思っています。

　さらに、この講座の最後にある世界平和への貢献という点に私は惹かれており、その理由として自分自身のWebに対する気持ちがあります。その気持ちと言うのは、誰もがWebを安全で安心に使えフラットな危険のない空間、誰しもが私が求めるものにたどり着け、誰しもが自分の手足のように使え、誰しもが落ち着ける自分の部屋のような危険のない世界であってほしい、と言う気持ちです。それは自分だけでできるものではない、そのために近い志を持つ人たちと一緒に活動できる場という点でVulsの開発参画というものはすごく魅力的だと思っております。

B4:ソースコード解析による検査自動化ツールの作成

　なぜ私がこの講義を受けてみたいかというの本題に入る前に少し前置きが必要なので失礼します。 　昨年私は、MBSD(三井物産セキュアディレクション)が主催するぜい弱性診断コンテストに参加しました。初めの2週間で予選が開催され、その際ソースコードが配布されました。当時の私は一切のツールの使い方を知らずに参加し目視と自分の知っている知識で攻撃を仕掛けながらぜい弱性を探しました。コンテスト予選の期間内にぜい弱性を見つけそれを報告し、その報告の正確性や量、また他者へ見せる診断書作りができたチーム上位１０チームが本戦出場を果たしました。私達のチームは上級生2人は用事であまり参加できずに1年生2人で健闘し予選を突破し、結果本戦では惜しくも４位と言う結果に落ち着きました。

　それでは本題なのですが、そのコンテストで私は最終日2日前にripsと言う静的ソースコード検査ツールを見つけ最後の粗探し程度にと思いスキャンをかけて見ました。すると結果として言えば当たり前のものは出てくるのですが本来なら出ないはずのぜい弱性が報告されたり、逆に本来出るはずのぜい弱性を報告しなかったりと散々たる結果でした。ですが、そこで初めて私はソースコードの静的解析のツールというものに出会い、それを利用することで実際にどのような動きをしているかも見ることもできました。そのコンテストの後に後少し調べてみるとコードの静的解析の難しさが語られており「自分でも作れたらな・・・でも私より経験のあるはずの誰かが公開しているツールでもこの結果なのであれば作るのはそっと諦めよう。」と思い心にこっそりとしまっておきました。

　しかし今回セキュキャンに応募してみようかなと思い講義を見てみるとその心にしまってあった"ソースコード検査自動化ツール作成"なる言葉が書かれた講義があるのです。これは私の中でしまわれていた気持ちが再燃しました。これは作って見たい！難しくても自分でやって見なければ何もわからないままで終わってしまう！としまっていた気持ちが盛り上がり始めました。さらに私は今、インターンの関係で、普段Webサービスの開発をメインに行っています。そのインターンに行き作業を行う際は、開発の後に目視でぜい弱性が発生する箇所はないかなと探して見たり、PHPUnitを利用したバグの検査を行ったり、7回に一回程度Burpで私が持っているペイロードを利用しintruderを回してあげたり、ZAPを全力でかけて見たりと趣味程度にローカル上で遊んでいます。その際に自分で作って見たこの解析ツールを強化して行きより一層セキュアで品質向上の計れるのであればいいなと思います。

　この講義で学んで見たいこと、いややって見たいこととして、私は、この検査自動化ツールをぜひとも作って見たいとおもっており、この検査自動化ツールの他に動的検査やマッピングなどの自作burpや自作ZAPのようなぜい弱性診断用のツールを自分自身で作って見たいとおもっております。そのためにこの講義で、その難しさや詰まりそうな部分を学び制作の糧として行きたいと思っています。

B6:認証の課題とID連携の実装

　この講義を受けて見たい理由として、私は今までIDとパスワードでのログイン認証や、OAuthとJWTauthなどを利用したソーシャルログインなどの機能実装というものはやったことがあるのですが実際、どのような動きを行いその認証の課題や弱点、また私が制作してきた認証に問題がなかったのか否かというを行いた再認識いという点でこの講義を受けて見たいと思いました。さらに今後のWebサービスにおいてサービスごとの認可認証を設けるのではなく、他社の認証情報を利用し認証を行うといったことが多くなると言う動向が見られるのでその点で学んで見たい講義であると考えました。

　学んでみたいこととして、深い意味でのOAuthの理解と課題の認識、さらにしっかりとセキュアなID連携の実装と題名そのままの内容をぜひ私は学んで見たいと思っています。

B7:サーバーレス時代のシステム設計ワークショップ

　私が講義を受けたい理由として、私自身はインフラを専門で行なっているわけでなく、Webセキュリティや開発をメインおいて勉強しています。ですが、近年フルスタックエンジニアなる言葉が叫ばれ、実際に私も現在も参加しているベンチャーのインターンシップでは、開発以外にもセキュリティやインフラ、ネットワークの設定・開発のマネジメントやデザインといった幅広い技術を求められます。その中、私の中に一つの気持ちが芽生えました。それはだったらもっと先読みして学んでしまえば頼まれた時に困らないではないか。この気持ちからここ最近では業務では使わないAWSや仮想化といった分野や他社のアーキテクチャ、ログの管理や解析についても学んでいます。その中で私は1年間無料の期間を利用してAWSで学習用のサービスを立ち上げようと思っており、EC2を中心としたWebサービスのアーキテクチャを学んでいました。ですがAWSを学んでいるとちらほらと現れるLambdaやAPI gatewayで制作されたアーキテクチャ図を見るのです。もちろんその中にはEC2を中心にしていないので気になって調べてみたら、AWSサーバーレスアーキテクチャなるものでした。

　初めて聞いた時はサーバーレスアーキテクチャなる全体像が読めないこのアーキテクチャに疑問しかありませんでした。ですが調べていくとこのサーバーレスアーキテクチャは近年ではメジャーな開発アーキテクチャでありNTT東日本や日経新聞などの企業がAWSサーバーレスアーキテクチャを利用したサービス提供やNECのIaaSを利用した三井住友信託やエプソンなどの業務支援システムの構築やさくらVPSのIaaSを利用した学術データを運用する国立遺伝学研究所など多くの企業期間で多種多様な採用のされ方がされている事がわかり、これは今後のサービスに必要なものだと考えすごく学んでみたい分野の一つになりました。そしてこのセキュリティキャンプの応募が開始された際に私の目を引く講義が多くあった中の一つとしてこの講義がありました。

　そしてこの講義を通して私は、触れたことのないこのサーバーレスアーキテクチャについて実際に触れながら設計の流れや設計の仕方を学び、設計の際に気をつけた方の良い点や、そのセキュリティなどのことを知識として入れて行きたいと思っています。この講義の後はAWSを利用し運用実験を行い、より多くのことを学びたいと思っています。そして将来の自分自身の技術の選択肢、そして活用に向けた今後の学習のためのスタート位置にして行きたいと思います。 　

選択問題

以下の中から、2問以上を選んで回答してください。

問2

「1000万人が利用するTwitterみたいなサービス」をあなたが開発することになったとしたら、予算はあるとして、どんなアーキテクチャで設計しますか？
具体的に利用するミドルウェアやライブラリまで思い浮かぶ人はそこまで踏み込んで書いてください。

どんなアーキテクチャにするか

　予算があるとして、1000万人が利用するTwitterのようなサービスを自分自身が開発展開をするのであれば、このようなアーキテクチャで開発をして見たいと言うものは意外にもはっきりしています。
　本来であればOpen stackなどを利用してサービスの展開を行いたいのですが、自分自身が未だ使用していないと言う点や知識不足という理由があり、今回の基本のアーキテクチャはAWSアーキテクチャで話を進めていきたいと思っています。

AWSを使用する理由

　なぜAWSを使用して設計したい理由について述べていきたいと思います。 　その理由としてまず先に挙げられるのが維持管理の容易さです。私自身が開発を行う人間として常にサーバーにつきっきりになれないことや、ホスティングやVPSなどを利用して各種インストールから設定まで1から始めるのは大変骨が折れてしまうため、機能が独立しており必要に応じて機能の増強が可能なAWSはとてもうってつけなアーキテクチャと言えます。そのAWSのサービスにCDNやGitHubとの連携もできることや、WAFなどのその他のサポートサービスもあり、さらには自分自身がこのAWSに興味があり、いろんなサイトや構成などを見てきたことから自分で構成を組んで見たいという気持ちがあったので私はこれを選びました。

設計概要

使用サービス/ミドルウェア

  • Web/アプリケーション系
  • Server : AWS EC2（Nginx）
  • Storage : AWS S3
  • Front end : Vue.js
  • Serverside : Laravel
  • AutoScaling : AutoScaling
  • ネットワーク系
  • CDN : AWS CloudFront
  • DNS : AWS Route53
  • VPN : AWS VPC
  • Load Balancer : AWS Load Balancing　Application Load Balancer
  • データベース系
  • DB : AWS RDS（MariaDB）
  • QueryCACHE : AWS ElastiCache
  • セキュリティ系
  • WAF : AWS WAF
  • Server Monitoring : Zabbix
  • Operation : Lamuda
  • Monitoring : AWS CloudWatch
  • サーバー認証 : AWS AIM
  • イベント管理 : Amazon SNS
  • コード管理系
  • Deploy : AWS CodeDeploy
  • メール系
  • Mail : AWS SES 　

構成について

AWS-------------------------------------------------●
|                                                   |
| Route53                                           |
|   ⌞ CloudFront --> AWS WAF                        |
|       ⌞ S3(JS/imag/css)                           |
|       ⌞ VPC(Virtual Private Network)              |
|         ⌞ Load Balancing                          |
|           ⌞ app group[master] (availability zone) |
|             |     ⌞EC2      (Nginx WebServer ) |  |
|             |         ⌞___________[DB group]   |  |
|             |     ⌞EC2      (Nginx WebServer ) |  |
|             |         ⌞___________[DB group]   |  |
|             |     ⌞EC2      (Nginx WebServer ) |  |
|             |         ⌞___________[DB group]   |  |
|             ●----------------------------------●  |
|         ⌞ DB group ※1-------------------------●  |
|             | ⌞ElastiCache                     |  |
|             |     ⌞RDS_1 (MariaDB  DataBase)   |  |
|             |         ⌞S3 (backup)             |  |
|             |     ⌞RDS_2 (MariaDB  DataBase)   |  |
|             ●----------------------------------●  |
|       ⌞ SES                                       |
|       ⌞ CodeDeploy                                |
|       ⌞ Zabbix                                    |
|       ⌞ Lambda                                    |
|       ⌞ CloudWatch                                |
●---------------------------------------------------●

※1　mainが基本でトランザクションをさばき
AAの体裁が崩れている際はこちらをご覧ください:
https://drive.google.com/file/d/1_YcElpU9Gjpgs50ynIFtz1s5slKzOavw/view?usp=sharing

構成に関して

　構成に関しては私が採用する上で最もこだわったものを、構成図を元にして設計について話していきたいなと思います。まず初めにWeb/アプリケーション系について話していきたいと思います。
　Webサーバーを動かすサーバーとしてEC2を採用し、その中でWebサーバーであるNginxを稼働させることになります。Apacheを利用せずにNginxを利用する理由としてApacheとNginxの駆動形式が異なることから、大量のリクエストがあった際に処理をすること得意としているので、ミドルウェアとして採用しました。このアプリケーションを提供するサーバーグループをapp groupとし、そのグループ内では常に負荷分散と冗長化のために2つ以上のEC2を稼働させます。このサーバー内ではLaravelのRESTfulAPIとページの大元になるPHPbladeの配信を行います。その際にCSSや画像、またJavaScriptなどはS3から取り寄せることでレスポンスを早く行えると言う利点が挙げられます。この課題以外で自分自身がこの規模での設計を行っていないこともあり、どの程度のWebサーバーを用意すれば利用者数に応じてapp group内のEC2を増やしリクエスト処理の負荷分散などを行うこととしています。

　つづいてネットワーク系についてです。まずはLoad BalancingのApplication Load Balancerについてで、これを取り入れたいとした理由はWebサーバーへのアクセス分配を自動で行ってくれ、かつ各種アプリケーションに対してのヘルスチェック/モニタリングを行える点です。これを利用することで、可用性の向上が図れユーザーへの大規模なDDoS攻撃などがない限りサービス提供ができると思われます。次にCloudFrontで、これを取り入れたい理由は、S3などのコンテンツストレージからの呼び出しを高速化するためにHTTP/２を利用したいこと、さらにCDNのキャッシュを利用したコンテンツへの大量アクセスを防ぐことが挙げられます。さらにSSL/TLSも設定可能と言うこともあり通信の保護もできるとと考えます。
　つづいてデータベース系です。SNSや各種サービスにおいてデータベースというものは大変重要なもので、できる限り稼働し続けなければなりませんし、流出などに対しても考慮しなければなりません。流出における攻撃に関しては後述するWAFで述べるとして、先に可用性にについてです。データベースはRDSを利用し、ミドルウェアとしてMariaデータベースを使用します。このデータベースを2つ採用し1つはメインのデータベースとして、1つはホットスタンバイ状態で配置し、データベース同士をレプリケーションで同調させHAアーキテクチャを実現させようと思っております。そしてElastiCacheを使用することで、できる限りデータベースへの過度なリクエストを送らないように、さらにデータ取得のレイテンシを短くすることも可能になるのでできる限りのパフォーマンス向上へ寄与できると思いましました。

　セキュリティ系についてですが、各種攻撃に対して対応するためにWAFを取り入れました。このWAFを採用することで目立った攻撃シグネチャを検知した際にブロックできる事、さらにAWSへの連携などが容易である事が挙げられます。次にZabbixについてで、これはAWSのデフォルトではついていないものでありますが、私自身が取り入れたいと思い記載しました。取り入れたい理由として、AWSない全体の一元管理やcloudWatchのメトリクスやそれを応用した料金表示、AutoScalingの自動変更を可能にし利用の拡大縮小を自動で行います。さらにLambdaを利用した各種オペの自動化ができるためとりいれたいとおもいました。

まとめ

　AWSの各種サービスを利用しサーバーレスのサービス展開を行いスピーディーかつユーザーへの通信的ローディング的な負荷つまるところレイテンシを下げサービスの可用性、またAIMなどを利用したサーバーへのセキュリティやHTTPS化による通信の機密性、WAFを利用した攻撃の検知などを行いセキュリティ的観点での設計、またユーザー視点での設計を行いました。 　サービスの継続性という点ではZabbixを利用した管理アーキテクチャでの運用自動化を行うことで極力管理者への負荷をかけにくい状態にしました。

問4

今までに起きたセキュリティ事故から一つ取り上げ、 その事故に対して、どのような仕組み・システムがあれば防ぐことができたかを考えてください。

　セキュリティ事故に関して私が取り上げるのは、とある教育系企業による情報流出事件です。 　この事件の大元としてあるものはこの企業の顧客データなどの機密情報の管理の仕方というものにあったと思われます。この事件では情報を持ち出した従業員がギャンブルで借金を行っていた点が問題としてよくとりだたされておりますが、そもそもの問題として顧客情報の適切な管理やそもそものセキュリティポリシーの再認識や共有がなされていなかった点があると思われます。この企業はこの顧客情報をグループ会社に委託し、￥管理を行っていました。本来であればこのグループ内で完結し管理されるような機密データをこのグループにおいてはその管理を再委託しその企業の派遣された従業員がグループ会社で作業をするといった状態でした。本来であればその点は問題がないと思われますが、その委託先セキュリティー上の問題が多々あります。一つ目としてPCへの記憶媒体接続の設定をパソコン側て許可していたこと、二つ目はその従業員は20年の勤続年数がありこの管理システムの開発にも携わった指導的立場におり内部監査や相互での確認を行う仕組みができていなかったことが挙げられます。この二点を元にどのような仕組みがあれば防げたのかを考えて見たいと思います。

　まずはじめにこの企業の現状を把握しておかなければなりません。この企業は現在も事業を続行しておりますが、セキュリティは過去のこの事件の時とは段違いといっていいほど強化されております。この問いにおけるどのような仕組みやシステムがあれば良いかというのも私たちはこの結果から導き出すこともできてしまうのですが、今回はそれらの結果を見ないで当時のニュース記事を見ながら書き最終的に結果はどうなったのかというのを書いていこうと思います。

　この事故において、私が最初に取り掛かりたいものとしてパソコンの記憶媒体への接続の禁止を明確化し、カバーなどをつけるなど物理的対策を行うのが先決であると考えました。その理由として、この従業員は20年の勤続年数を持っており開発にも携わっています。ですがこの事件があるまで対応がなされていなかった、またこの事件が起きてしまっていることを見るに、初手の段階においてそれ以上の流出を防ぐことが重要かと思い、このような対応をすると良いかと思われます。次にセキュリティポリシーの再認識と追加、そしてセキュリティーゾーンの設置についてです。

　セキュリティーゾーンに関しては個人情報を取り扱う関係上、記憶媒体の持ち込みまたは取り出しを禁止し、接続をした場合の各種規定を設けることでこのや作業の際は複数名でのチェックを行うことを明記し情報の抜き出し持ち去りや、作業内容のチーム内での相互認識を深めることで事前に対策が行えると思っております。さらにそのセキュリティーゾーンのある箇所への出入りにはカードキーなどを利用した入退室管理を行い、作業のログを記録することや、持ち込み物のさらなる規制(前述の記憶媒体の他にコードや無線機器など)や持ち込み物のチェックを行うことが有効でしょう。

　セキュリティポリシーに関しては、上記を踏まえながら再度社員への周知を行うことで情報流出のリスクは抑えられたのではないかと思われます。以上で私の考えは終わりです。
　それではこの企業の現在を見ていきます。この企業では現在子会社に情報システム運用や保守を担当するIT機能子会社を設立し、確実なセキュリティゾーン分けを行い、事件後の安全と信頼へ向け日々セキュリティに注力しています。さらにこのグループで情報を扱う会社三社がISMSの取得をし、組織としてのセキュリティにも力を入れていることがわかりました。

　このように企業としての信頼は一度地に落ちかけたましたが、自らを律しながらセキュリティ対応を行ったこの企業の事例や、後述する問6での各情報流出の事例をさらに学び私たちは学生、そしてセキュリティを学ぶエンジニアとして今後も胸にしまいながらエンジニア生活をしていければと思う次第です。

問5

活動しているオープンソースコミュニティがあれば、
そこでどんな活躍をしているのか自己紹介してください。
参加の形態は開発だけには限りません。
もし今は活動しなくとも、貢献しようと思っているコミュニティがあれば、
どんな貢献をしていきたいと思っているかを書いてください。

　私は、LaravelのJapanUserコミュニティとBurp SuiteのJapanユーザーコミュニティで今後活動をしていきたいと思っております。その理由を一つずつ話していきたいと思います。
　まずはLaravelからです。私は普段からLaravelを使うことが多く最近ではEloquentの中身に興味があり探るような生活をしています。このLaravelの中身を見る上でどのような構造をしていて、セキュリティ対策としてどのようなものがあるのかについて私は興味がありコツコツと解析を行なっています。そんな中でこのLaravelのユーザーグループに参加ができた際にこのような活動をして見たいと思います。
　一つ目はLaravel内のセキュリティ機構の解析とバグを探したいと思っています。なぜ私がこのLaravelでそのような事がしたいのかについてなのですが、このフレームワークは私にとってすごく愛着のあるフレームワークでこのフレームワークをもっと安全でより使いやすいフレームワークに僕も貢献したいと思っているからこそこのような活動を行いたいと思っています。
　二つ目はこのフレームワークを利用したサイト構築やセキュリティ機構に関するハンズオン形式の勉強会を開いて見たいと思います。先述した通り私はこのフレームワークが大好きで、他の開発者にも使っていただきたいと思うほどではあります。ですが私自身まだ利用し半年も立っていない新人であり、まだ中まで知らないわけです。ですので私は今後このフレームワークの解析を行いながら、エバンジェリストを自称できるのような活動を行うために勉強をおこないたいと思います。そして、私が教えられるようになった頃にこのもくてきをたっせいしたいとおもいます。

　次にBurp Suiteについてです。このburpに関してはそのものはOSSではないのですが、私自身が興味のあるユーザーコミュニティーでしたのでので書かせていただきました。私は最近burpを使用し始めました。その際に多くのコミュニティ参加者のブログや記事、また勉強会などに参加し使い方を学ばせていただきました。
　その中で私は、私のように初めてこのツールを利用人たちをサポートしたいと思っています。さらに自分自身でこのOSSとしての拡張機能を作って見たいという気持ちがありながらも、まだどのような拡張機能が必要なのか、また他の方が作っているのかがわからないのでその点を深く理解しながら使用していきたいと思っています。
　貢献という点ではまだ自分自身がセキュリティに対する知識やextension開発の知識を多く持っているわけではないのですぐに活動に貢献できるかはわかりませんが、貢献ができるように他の方の制作したextensionを理解しながらの開発やセキュリティエンジニアとしての知識をつけていきたいと思っています。 　

問6

「セキュリティ」は幅広い分野から成り立っていますが、 その中で私がもっとも興味があるテーマについて、好きなだけ書いてください。

　まずはじめにこの項で触れる事例につきまして、企業名を実名で記載することはあまりよろしくないと私は判断したので実名は伏せて記載することをお許しください。
　私がセキュリティに於いて一番興味を持っているもの、それは"情報漏洩"について興味を持っています。この情報漏洩に関しては大きく分け、内部的要因と外部的要因があると私は考えています。
　まずはじめに内部的要因についてのお話をして行きたいと思っています。内部的要因での情報漏洩と言いますと、問4でも取り上げましたが、とある教育系の企業の情報管理の委託先である会社の従業員による情報持ち出しなどの人的要因、さらに外部的要因ともつながりますが某大手電子メーカーのグループでのSQL injectionやサーバー侵入です。などにによるシステム設計の段階で発生しうる設計的要因というものがありました。外部的要因としては、先ほどもあげた某大手電子メーカーグループのSQL injectionによる第三者から攻撃や公的なお金の運用を行う組織のサーバーに対する攻撃や衆議院サーバーハッキング事件など多岐に渡ります。
　この大分類において二つに分けた要因を考えた際に、全てのものに言えるものとして、継続的な注意をはらえていなかったにより発生したインシデントだと私は思っています。その理由として先に挙げたすべてで説明していきたいと思いますが、この二つの要因がどちら一方だけであることは少なく、ほとんどの場合は両方が発生の原因となっているものと私は認識しています。

　内部的要因で例に挙げた教育系企業に関する詳しいことは問4で記載しましたので簡単に触れます。この事件において人的要因についてどの点で注意をはらえていなかったのか言いますと、本来個人情報などの機密情報を管理する、もしくは管理しているデータベースにアクセスできる端末へのその他情報端末の接続は禁止すべき、もしくは設定として接続を拒否するべきものでした。ですがこの端末には、端子の差し込みやデータ転送が可能な状態になっていました。そのためデータの持ち出しが可能になってしまいました。さらに作業の内容を複数人で確認しながら行うことで見落としや不正などを防ぐことも可能であったと思われますが、この事件では20回以上の持ち出しがされていました。発覚まで誰もこの行為を見ていない、もしくはチェックしてしまっていたのではないかと考えられます。この企業においての原因をまとめますと、持ち込み物や行動においての物理的な注意が払えていなかったことになると思われます。
　続いて某大手電子メーカーのグループでの事件についてです。この事件ではWebサイトの構築段階やシステムの開発段階からの攻撃に対する入力値のチェック漏れというものがあるほか、サーバー設定項目のチェックミスやアクセスを想定していた端末以外からのアクセスが可能であった点などから注意が完全に払えていたとはいいがたい状態でした。この事件自体は内的要因である設計・設定段階での問題と外的要因での攻撃への監視という点で問題があったと思われます。
　まず内的要因からなのですが、HPの構築の際にページのURLにあるパラメータの処理の方に問題があったそうで、このパラメータをいじった際にSQL injectionが発生してしまったのです。この問題点としてこの発生した脆弱性に対する認識が薄く、対策を行なっていなかった点で問題が発生してしまいました。この事件を起こした企業は日本でも名前を知らない最大手の企業であり私たち一般人からすればある程度のテスト工程やセキュリティの検査などは行なってしかるべきであると思われますが、攻撃者が公開した情報によると、自動化された攻撃ツールを利用し脆弱性が発生したサイト等もあり、開発の段階でのセキュアコーディングやテスト工程、セキュリティの検査などの事前策が不足していたと思われます。
　他にもこの企業では情報流出の事件がありました。その事件では専用の端末からのアクセス以外を考慮していない設計をしており、その専用端末からの攻撃はない、通信はHTTPSだから改ざんはないであろうとしていたようです。ですがDNSキャッシュポイズニングのようなものを使いDNSのアドレスを変え攻撃者のサーバーにアクセスさせ、中間者攻撃でその通信を改ざんし不正に侵入するという攻撃が可能であり、実際にそ前述のような攻撃でWebベースで制作されたアプリケーションの残されていた脆弱性を攻撃し不正に情報を抜き取ったり各種攻撃を行なったととされています。
　この二つの攻撃はどちらともセキュアなコーディンを行なっていれば起きなかった事件でありながらも、開発段階でのレビューやテスト、診断などの段階においてのセキュリティに注意をしていなかったということで大きな情報流出につながりました。
　他にもこの事件に関しては外部的要因もあり、著名なハッカー(元来での意味)がPS3のハックを行いそれを公開しそれに対するとその企業グループがそのハッカーをアメリカの裁判所に提訴しました。その際にネット上のハクティビズムグループにより闘争宣言が出されるなど外部の政治的思想によるデモ行為に近い形での積極行動での表現が発生しました。その後それに誘発された愉快犯やクラッカーによDDoS攻撃が発生し混沌を増していくなどの匿名社会だからこその外部的要因が見られます。

　外部的要因にうつりましょう。まずはじめは公的なお金の運用を行う組織のサーバーに対する攻撃に関してです。 　この事件では多くの内部的要因と強力な外部的要因によって発生してしまいました。今回は主に外部的要因の一例としてあげましたがこの組織での内部の体制も大変よろしくない状態であったことは確かです。 　それでは簡単な経緯を話して行きます。この事件のきっかけはある一つのメールからでした。そのメールには制度の見直しについての試案と書かれたファイルが添付されておりそれを開いた事がことのはじまりでした。この組織での問題点としてこの最初の１通を開いた後の注意喚起の方法に不足があり、その後も同様のメールを開く職員が多く発生しました。このメールに添付されていたファイルはサーバーへの不正アクセスを行うためのマルウェアであった事が後に判明します。このウィルスに感染したことによりサーバーないから個人情報が抜き出されてしまいます。 　それではこの事件での外部的要因について話して行きたいと思います。この事件においてまずはじめにおこなわれたソーシャルエンジニアリングによるメール送信と、このメール自体がこの組織を含めた日本国内へ狙いを定めた攻撃があった事があげられます。
　この攻撃において使用されたマルウェアはEMDIVIであるとされており、この攻撃に使われたマルウェアの解析と調査報告の会見でこの攻撃が"サイバー諜報活動(サイバーエスピオナージ)"であるのではないかと注意喚起をする場面があった。この攻撃において問題となったのが個人や個々人が集まり行うハクティビズムとは違い、意思を持って動いた何かしらの組織が関与していたと推測され、その理由としてこの制作されたファイルの制作時間が昼間の時間帯に制作されており、土曜日の制作がほとんど行われていないことから何らかの組織の業務で制作された可能性に至ったとされている。
　次に衆議院サーバーハッキング事件についてです。この事件も先のようにメールを利用した手法でしたが、これに添付されていたものは画像であり、未知のメモリリークを利用したバッファーオーバーランの脆弱性をついたと思われてる。この技術の高度差から国家レベルもしくはそれに準ずる組織であると推測されているが、犯人は不明のままです。

　情報流出における内部的要因をまとめると
- 1. 内部のセキュリティ体制
- 2. セキュリティポリシーの周知の甘さや内容そのものの不足
- 3. セキュリティ教育の不足
- 4. 設計上の不備
　となります。

　外部的要因をまとめると
- 1. ハッカーの腕試し
- 2. 愉快犯やクラッカーによる破壊的いたずら
- 3. ネット上における積極的な抗議活動"ハクティビズム"
- 4. 国家もしくは会社内の諜報組織、もしくはそれに準ずる組織による"サイバーエスピオナージ"
となります。

　内的要因に関しては継続的な注意をはらえていなかったというのが納得いく内容ではありますが、なぜ外部的要因にもそのような事が言えるのかと言いますと、近年多くの企業や行政期間が情報化を進めており、そのことから全てがネットワークで繋がるようになってきました。このネットワークに繋がっていることや攻撃をされるかもしれないから注意をしようという意識が薄かったことにより、内的要因のぜい弱な部分を突かれ情報漏洩を起こしてしまったと思われます。

　なぜこの情報漏洩というテーマが好きかと言いますと、私を含めたITを触れる人間において一番の脅威となるものそれが情報漏洩であり、その情報資産の保護こそ私のようなセキュリティを学ぶ人間に課せられた使命だと思っているからこそこのテーマを意識していますし好いています。
　私は、この使命を元にセキュリティの技術的な面の他にも何か行えるものはないのだろうかと思い、情報漏洩事件の先例を洗い出しそれを学ぶことにしました。先例を学ぶことで攻撃者の心理を学び、どこを突く事で情報が抜き取ったり、悪い事ができるのかといった攻撃者の立場で考えセキュリティをおこないう事でその攻撃を未然に塞ぐ事ができる。だからこそこのテーマに興味を持っています。