freeeの"マジ価値"なプロダクト開発の"現場"を体感する | Summer Internship 2018募集中!

freeeで新卒採用を担当している高森(@takamo15g)です。

freeeには2016年4月に新卒入社し、現在社会人3年目です。
今年の4月から主にエンジニア職の新卒採用を担当しています。

freeeでは今年もエンジニア職志望の学生向けにサマーインターンを開催します!

freeeとしてのサマーインターン開催は今年が3度目。

昨年は1週間だったインターンの期間も今年は2週間に伸ばし、より深くfreeeの開発現場を知ってもらえるよう設計しました。

freeeの"マジ価値"な開発の"現場"を体感するインターン

freeeでは freee が重要と考える価値基準の1つとして「ユーザーにとって本質的な価値があると信じることをする(通称、マジ価値)」というものを持っています。

freeeらしい行動や意思決定をするための5つの価値基準

この"マジ価値"を体現すべく、freeeには独自の組織体制や開発文化があります。

今回は昨年のサマーインターン参加者で来年4月に入社予定の内定者の声も交えて、「サマーインターンって何するの?」についてご紹介したいと思います。

サマーインターンってなにやるの?

サマーインターンでは上記のようなfreeeの開発文化を体感していただくことはもちろん、ひとりひとりにメンターがついて密なフィードバックやレビューを行うので、ご自身のエンジニアリング力を高める機会としても活用いただけます。

2週間のうち、初日はPC等の各種セットアップや事業・開発組織についての講義となりますが、2日目からは各自それぞれのチームに配属となり、実際のプロダクト開発に携わっていただきます。

配属チームについては、ご本人との面談のうえ、専攻されている内容や業務内容などを考慮しつつ、個別にアサインメントを考えていきます。

昨年は、会計freee・人事労務freeeのWebアプリケーションやモバイルアプリへの機能開発・機能改善のほか、インフラやセキュリティ関係のチームへも配属を行いました。

昨年のサマーインターン参加者の声

金子誠也くん(北陸先端科学技術大学院大学 / 来年4月入社予定の内定者)

——そもそもfreeeのインターンに応募したきっかけは?

サマーインターンを探しているときに、就活サイトで募集ページを見つけたことがきっかけです。

1dayインターンとして自作のモバイルアプリへのレビュー・フィードバック会が開催されると聞いて、興味を持ちました。*1現役で活躍しているエンジニアに自分のつくったアプリを見てもらう機会なんてなかなかないじゃないですか。

——1dayインターンに参加してみてどうだった?

ギークで技術的な知見を持っている社員から、鋭いフィードバックをもらって、圧倒されましたね。

この人たちと一緒に働いて、もっと吸収して力をつけたいと思い、1weekのインターン*2への参加も希望しました。

——1weekインターンでは具体的にどんなことをしたの?

freeeの事業や開発体制に関するレクチャーは1日目の前半で終わってしまって、後半は開発環境のセットアップをして、2日目からは早速チームに配属されて業務に当たりました。

僕が配属されたのはモバイルチームで、実際にfreeeが提供しているモバイルアプリを触って自ら課題点を洗い出して、その改善まで取り組む、ということを行いました。

2日目に課題点洗い出しを行い、残りの3日間で改善に取り組むという流れでした。

インターン中は同じモバイルチームの方にメンターとしてついてもらっていたので、適宜フィードバックやレビューをもらいながら進めていきました。

正直、5日間はけっこう短かったですね。

最後まで課題を潰しきれず、本当にあっという間に終わってしまったという感じでした。

——インターンを通じて学びになったことはある?

実際に動いているコードを触ることの大事さを実感したことですね。

freeeが提供しているモバイルアプリに実際に使われているコードに触ることで、複雑に絡み合ってアプリが設計・運用されていることを初めて具体的にイメージできました。

それから、やっぱり社員から直接フィードバックを得られる環境だったことも大きかったですね。

印象的だったのは、僕がアプリを触ってUI面での改善案をメンターに提案したら、すぐに社内のデザイナーを呼んできてくれて、話す機会を作ってくれたことです。

インターン生の意見に対しても、こうやってしっかり向き合って対応してくれるんだと感じたことを覚えてます。

f:id:takamo15g:20180615192504j:plain

成果報告をする参加メンバー。メンター陣からも鋭い質問やフィードバックが飛んできます。

——インターンをやってみてfreeeに対する印象とか理解に変化はあった?

そもそも最初はベンチャーで働くってイメージが全く無かったんですよね。

キャリアとしてもベンチャーから大手メーカーまで幅広く見てましたから。

でも、インターンとしてfreeeで働く中で、本当にメンバーがのびのび働いているんだなということがわかりました。

フリードリンク制で社内にドリンクバーがあったり、リラックスできる畳スペースがあったり。

f:id:takamo15g:20180615194523j:plain
ドリンクやスナック類は完全無料。ちょっとリラックスしながら談笑できるカウンターもあります。

インターン初日に社内を見て回ったときに、地下に寝転べるスペースがあったのを見たんですけど、業務を始めてそのスペースで本当に寝そべりながらコードを書いてる人を見かけてびっくりしました。

「あ、これ飾りじゃなくて、本当に寝そべっていいやつなんだ」と驚きましたねw

f:id:takamo15g:20180615194025j:plain
地下のyogiboがあるスペース。地べたに座ってミーティングしたり、寝転がりながらコード書いたり、ちょっと仮眠をとったり、みな思い思いに過ごしてます。

——インターンを経て、freeeへの入社を決断してくれたわけだけど、何が一番の決め手だった?

インターンとして、1週間業務を体験してこれなら続けられそうだと思ったことですね。

一緒に働いたメンターとの性格が似てたことも大きかったです。

気を張らなくていいというか、自然体でいられる環境だなって思ったんです。

マネージャーや先輩に意見しても怒られないのが良いなと思いましたw

自分の意見をしっかり伝えて反映させていけそうだと思えましたね。

——やっぱりインターンを踏まえて実際に自分が働くことを具体的にイメージできたのは大きかったのかな。お話ありがとうございました!

サマーインターンにぜひご応募ください!

ここまでのインタビューを読んで、freeeのサマーインターンに興味を持ったみなさん!

今年はより深く実際の開発現場に入り込んでもらえるよう、期間を2週間に伸ばしてパワーアップしたサマーインターンにぜひご応募ください!

jobs.freee.co.jp

2週間も時間が取れない!という方へ

2週間のインターンプログラムに加えて、1dayインターンのプログラムもご用意しています。

今年は、昨年同様「モバイルコース」に加えて、「Kubernetesコース」の開催も決定しています。

www.wantedly.com

www.wantedly.com

研究などで2週間も時間が取れない!という方はぜひ1dayコースへの参加をご検討ください。

今後1dayコースは追加開催する可能性があります。追加開催を決定し次第、随時お知らせしていきますので、以下をご確認ください。

それでは、皆様のご応募お待ちしています!

*1:今年の1dayインターンはモバイルコースに加えてKubernetesコースも開催します

*2:今年は2weekです

RubyKaigi 2018に参加しました

こんにちは。freeeでアプリケーションエンジニアをしているimamuraです。

去年に続き、今年もRubyKaigiに弊社エンジニア数名で参加しました。 RubyKaigiはプログラミング言語Rubyの技術カンファレンスで、5/30~6/1の三日間でRubyに関する知見や最新の情報が共有されます。そして、今回もfreeeはスポンサーとして協賛させていただきました!

rubykaigi.org

RubyKaigi会場に置かれたfreeeのパンフレット

RUbyKaigi会場のスポンサーロゴが印刷された板

会場の雰囲気

1000人以上の色々な国からRubyエンジニアが集まっていました。 スポンサーブースでは、企業が展示をしてライブコーディングやノベルティの配布、書籍の販売などがあり、大変賑わっていました!

RubyKaigi会場の書籍販売ブース 自社パンフレットが置かれているのを撮影するfreee社員 *1

セッション

そして、RubyKaigiはRubyの生みの親こと、Matzによるkeynoteから始まりました。 MatzのCRubyへのバージョンを上げる以外のコミットがRuby 2.6.0 preview2には反映され、それが多分5年ぶりぐらいなので拍手が起こっていました。 そしてそのコミットは、プログラミングで名前の付け方が重要という前置きで、本人が名付けたyield_selfメソッドが分かりづらかったため、thenという名前への変更だったので会場では笑いが起こっていました。終始、和気藹々とした雰囲気でした。*2

Matzによるキーノートセッションの様子

そのあとは、三会場に分かれてそれぞれ多種多様なセッションがありました。普段Rubyを書いている際に意識していなかった仕組みについて考える機会になったり、RubyGems3の変更点についての話型システムやRuby 2.6.0-preview2からendless rangeという書き方ができるようになった話など最新のRubyに関する情報にキャッチアップすることもできました。

これらのセッションの中でも自分が面白かったセッションを紹介したいと思います。

Analyzing and Reducing Ruby Memory Usage

Analyzing and Reducing Ruby Memory Usage - RubyKaigi 2018

Ruby 2.6系のパフォーマンス改善についての内容でした。大きく分けて二つトピックがありました。*3

一つ目が共有文字列についてです。Rubyの文字列を表す構造体は、メモリが割り当てられた文字の配列の先頭の要素へのポインタと、そこからの長さの情報を持っており、部分一致する文字列は、作られるたびにメモリ割り当てをするのではなく、構造体のポインタと長さの情報だけ変えて同じメモリの文字列を参照するようにしたそうです。Rubyは、ファイルの位置が格納されている配列と、requireメソッドの引数のファイル名をキー、その配列のインデックスを値としたハッシュを持っており、先ほどの共有文字列の仕組みを使って、requireメソッドのパフォーマンスが改善した話でした。*4

二つ目に、Rubyのコードは、命令列(数字)の配列(ISeq Object)にされてからバイトコードになり実行されます。このISeqObjectが参照するオブジェクトはmark_arrayという配列にアドレスを入れて、GCされないように監視されるようになっていましたが、配列を使わずに、直接ISeqObjectからそのオブジェクトをマークするようになりました。これによってmark_arrayに必要なメモリが削減されたようです。

そして、改善を紹介するたびに、「あなたならこの機能にいくら払いますか?5000円、10000円、5000兆円?アップグレードすればタダです!」というセリフで会場が沸いていました。

セッション中の風景

Exploring Internal Ruby Through C Extensions

Exploring Internal Ruby Through C Extensions - RubyKaigi 2018

RubyのHashのパフォーマンスをCで拡張したものやC++で実装したものと比較する内容でした。RubyのオブジェクトがどのようにCの構造体と連携されているか、C側でRubyのデータがどのような構造体で表現されているかなどが説明されました。また標準のRubyのHashはC++で実装したものと条件によってはあまり差がなく、高速だったことが印象に残っています。

RNode with code positions

RNode with code positions - RubyKaigi 2018

speakerdeck.com

Rubyの2.5系から行番号だけでなく、カラムの情報を持つようになった話でした。 カラムとはその行におけるコードの位置のことで、これによってNoMethodErrorなどがどの行のどの位置で起こったかが分かるようになりました。「Rubyのしくみ」などで知っていたASTにどうやって複雑な位置情報を持たせるのかが興味深かったです。

Extend your own programming language

extend your own programming language - RubyKaigi 2018

speakerdeck.com

MinRubyというrubyインタプリタを使ってrubyのインタプリタを拡張する話でした。このインタプリタ自体もrubyで書かれています。rubyのASTを評価するevaluate関数を基本的な四則演算などを使って実装したりしていました。例えば、論理和・論理積の演算子を追加したり、末尾再帰で計算する関数を作ったり、Lindaという並列処理言語のevalを使って拡張したりがありました。具体的な実装でイメージしやすかったので、自分でもMinRubyを拡張したいなと思いました。

DRINK UPを開催しました!

freee.connpass.com

1日目の晩にRubyKaigiに参加された方の懇親の場としてDRINK UPを開催しました! 東京、福島、沖縄、海外など世界中のRubyistたちにお越しいただき、素敵な出会いがたくさんありました。その中にはRubyコミッターでpatch monsterことnobuさんや去年に引き続きご参加された方もいらっしゃいました。

仙台の美味しい料理と日本酒を飲みながらRubyの話、なぜかGoの話、エンジニアのキャリアの話などしながら、普段なかなか交流できない方々と盛り上がれたのは貴重な体験でした。

参加してくださった方々ありがとうございます! また来年もDRINK UPを開催しますので、次回の会場である福岡で皆様のご参加をお待ちしております!

DRINK UP恒例の集合写真

最後に

ここまで読んでくださりありがとうございます!

私自身は去年、新卒でfreeeに入社し2年目になりましたが、初めてのRubyKaigiへの参加でした。登壇者の話す内容のレベルが高くて正直、圧倒されました。自分はまだまだだなーと感じつつ、このままやっていけば自分もその高みに行けるのではないかといった不思議な気分になりました。

そして、何よりもっとRubyについて詳しくなりたい、Rubyでもっとコードを書きたい気持ちが高まった機会でもありました!

お約束の紹介になりますが、freeeではRubyを使ってプロダクトを一緒に成長させてくれる仲間を募集しています!興味を持ってくださった方はぜひfreeeに遊びに来てください!

jobs.freee.co.jp

www.wantedly.com

*1:これは、ブログ用の写真を撮る本人です。

*2:RSpecの英語のような書き方に馴染めないMatzがそれと同じような「then」メソッドを実装したことも笑いを誘ったポイントでした。

*3:Aaronの記事が参考になります。

*4:しかし、Aaronの考案の前にすでに修正されており、コードを書く前に検索しようという言葉でこの話は締めくくられました。これは数年前にあったRubyKaigi 2011の発表で、出てくる「書く前にグーグルしたほうがいい」と同じオチでした。

社内ポッドキャストのすすめ

社内ポッドキャストを始めました

freeeの加来(kakkunpakkun)です。

突然ですが今年からfreeeの社内でポッドキャストを始めました。

主に開発者向けに作っていて、普段録音をしている会議室の名前から「アナグマ.fm」という名前で社内で配信しています。ついこの間第7回が配信されました。

今回は社内ポッドキャストを始めた理由や、どうやって運営しているかなどを書いていこうと思います。

アナグマ.fmのロゴ。メンバーの奥さんが作ってくれました。作者はアナグマとハクビシンとタヌキの違いに悩み眠れぬ夜を過ごしたそうです

なぜ社内ポッドキャストを始めたのか

まずは何より楽しそうだったからですが、実際にアクションを起こしたのには他にも理由があります。

freeeは全社でも大きな組織になりましたが、開発組織もかなり大きくなり、一人一人の顔が分からない、誰がなにをやっているのか見えにくいという状況になってきました。

freeeは基本的にチームワークを重視している会社だと思っていて、それはfreeeの価値基準として掲げられている5つの要素の中にも “あえて共有する” という形で表現されています。

でもあまり知らない人同士で共有したりチームワークを発揮するのは大変ですよね。LTや勉強会もやってるのですが、もっと人や技術を知る場がほしい!

そういう課題についてなぜか毎週ラーメン屋で話し合っていて、そこで出たアイディアの1つが「ポッドキャストなら楽だし情報共有になっていいんじゃないか?」でした。 運営側としてはあらかじめ時間を取っておいてあとは話すだけ話して公開出来るから楽そうと考えたのです。

ポッドキャストなら聞く時間が自由になりますし、LTなどは発表者が固定されがちですがそこも運営側でゲストを指定すれば回避できるという利点もありました。

ちなみに他に出たアイディアとしては「社内技術情報新聞を発行する」というものがあったのですが、これはテキストとして残すということは結構大変で、以前にも似たような取り組みをやったことはあるのですが誤解のない表現にするようにしたり社内インタビューの内容を編集したりと非常に時間が掛かって挫折した経緯があって止めました。

えいやで始めてみよう!

そういうわけで、これまたfreeeの価値基準の1つである”アウトプット→思考”にしたがってまずはやってみて公開してみようという流れになりました。ラーメン屋で話をした人たちだけで勝手にえいやと始めることにしました。

この時、こだわり始めると何かと大変そうに思えたので、とにかく雑談でも良いのでfreeeの人を知れるということだけを目標に、とにかくさっと始めることにこだわりました。

まずは録音してみる

早速話をした3人で次の週に録音してみることにしました。 1人をゲストにして私ともう1人で司会とにぎやかしをやる感じで進めてみました。 ゲストと司会というのはRebuild.fm的な感じですね。偉大な先人がいるとそれをテンプレートとして構成を決められるのでそこも楽でした。

事前準備は出来るだけ少なくしようと思い、ゲストに話したいことをリストアップだけしてもらってそれをなぞっていくようにしています。 時間は30分から1時間以内にしようとしていて、これまでは全部1時間弱になっています。

最初は録音用にマイクを買おうという意見もあったのですが、会議室に置いてあるリモート会議用のスピーカーマイクがあるのでそれを使うことにしました。ソフトも特に編集もしないのでGarageBandを使っています。

f:id:kakkunpakkun:20180511145135j:plain
実際に使っているマイクです。よくオフィスで見かけるものかと思います

ちなみにアナグマ.fmという番組名は初回を収録してから決めました。これもこだわらないで済むものは出来るだけ後回しにしていった結果ですね。

あえて無編集即アップロード

もちろん無駄な話や間などもあったり聞き苦しいところもあると思うのですが、その辺りをこだわるよりまずは聞いてもらって反応を見ることの方が大事と思い、録音したものを編集するのはやめました。

編集をやるのは大変ですし時間がかかります。それをやらないことで労力がかからず運営としても継続しやすいかなと思いました。

なのでマイクや編集ソフトなども新たに準備することはありませんでした。もちろんクオリティの高いポッドキャストと比べると聞きづらい部分はありますが、耳障りな音や何言ってるかわからないことは少なかったので及第点かなと思っています。(いつか改善出来たらいいなというくらいの気持ちです)

なので、録音したらmp3化してすぐにアップしてます。 freeeはgoogle driveを使っていて、mp3の再生機能もあるのでまずはアップすれば最低限聴けるようになります。

勢いで社内向けにサイトも作り、r7kamuraさんのyattecastを利用しています。

結果、事前に話題のリストアップだけを行いあとは1時間の収録とアップロード作業だけで1回当たり1時間半も掛からずに公開出来ています。これなら続けられる気がする!

f:id:kakkunpakkun:20180514145015j:plain
実際のアナグマ.fmのサイト

f:id:kakkunpakkun:20180510202949p:plain
第1回のお知らせです。本当に何の予告もせず突然当然のように社内SNSにアップしました。社内公開なので社外では言えない話題も言えるし社内だけで通じる単語とかも使えます

月2回の更新

いろんなこだわりを捨てた分、ある程度の頻度で更新することは気にかけています。今はだいたい月に2回新規に更新するようにしています。 毎週だと運営側もゲストを選んだりスケジュール抑えたりに追われてしまう感じがありますが、1週休みを入れることも出来て余裕が生まれます。

話の内容はあまり深い技術の話ばかりになると聞く敷居が高くなるばかりなのであえて雑談っぽい話題なども増やしています。ただ、噂話などワイドショーっぽい感じにはならないように気をつけています。

収録の様子

ガイドラインの作成

なにもないとさすがに出演する人も何をどう話したら良いか分からないだろうと思ってガイドラインは作成しました。

アナグマ.fmのガイドライン

  • 基本は開発チームの “あえて共有”
  • ゆるゆる話してみる
  • プライベートの話はしたいならOK
  • あまりワイドショー的にしない
    • 噂話
    • 喜んで公開したいわけじゃないプライベート話
    • など
  • 聞きながらだったらそんなに仕事を邪魔しないので音声オンリー
  • 編集も基本しない(作成コストを低く)
  • カジュアルさを大事にしたい
  • 出演ハードルを高くしない

社内ポッドキャストをやってみて

始める時はどうしても有名なポッドキャストの二番煎じっぽくなりそうだし、新しい価値になるか不安だったりもしたのですが、えいやと始めて良かったなと思ってます。

社内で名前だけは知ってるけど何をやっているか分からない人について知ることが出来たり、思いがけない一面を知ることも出来ました。

なにより社内で時々「アナグマ.fm面白いっすね」「今度は〇〇さん呼んでくださいよ」など、ポジティブな反応がたくさんあってうれしいです。人や技術を知る場というのをちょっとでも増やせたなら良かったなと思っています。

数学について話をした回を聴いた人同士で数学の入門書を教えあったり、ツールの使い方を教えあったり実際に情報共有が進んで新しい価値が生まれたとも思っています

時間も掛からず、ながら聞きができて、情報共有も進む!と、たくさんのメリットがありました。

「ポッドキャストを始める」というとなんだか大変そうな印象がありますが、ここもfreeeの価値基準の”アウトプット→思考”に則って削れるところは削ってまずはリリースしました。

今後もマイペースに更新を続けていけたらなと思っています。

皆さんの職場でもえいやの勢いで始めてみてはいかがでしょうか?

アナグマ.fmは社内の人ならいつでも聴けるようになっています。 そうです、つまりこういうことです!↓

jobs.freee.co.jp

新人研修でHardening!

こんにちは、freeeのCSIRT専属エンジニアの杉浦英史です。 2018年4月、freeeは新卒3期生として27名もの新人さんをお迎えしました。 会社に入社すると、最初に待っているのは?

そう、新人研修ですね。

今年は、freee史上最も中身の濃い研修が行われていますが、 今回は、CSIRTが担当したセキュアコーディング研修について紹介します。 この研修は、4月中旬の3日間に渡って行われたものですが、8名の選りすぐりの新人達に参加してもらいました。

セキュアコーディング研修と聞くと、コーディングべからず集みたいなものを解説する座学を思い浮かべてしまうかもしれませんが、そんな生半可なものではありません。

Hardening!

Hardeningと呼ばれるトレーニングをみっちりやってもらいました。

スケジュールはこんな感じです。

半日座学の後は、1日半かけて修正、最終日の半日で攻撃を受けて、最後の半日で解説
Hardening実習スケジュール

最初の半日で、OWASP Top10や過去の事例に基づいた実際の攻撃手法の概略と、Hardeningのルールを説明したら、すぐにトレーニング開始です。

Hardeningというのは、チーム対抗戦で行われる競技です。今回は、4名ずつの2チームに分かれて対戦を行いました。

f:id:eiji-sugiura:20180501120140p:plain
実習環境
全てのチームに脆弱性が仕込まれた同じwebサービスを渡されるので、メンバは脆弱な点を探し出して修正し、さらに堅牢化してサービスとしての質を競います。 ちなみに、脆弱なwebサービスはfreeeが実際に提供しているサービスを CSIRTが腕によりをかけて改悪したものです。もちろん元のコードを参照するのは無しですよ。

ところで、守らなければならないのは、webサービスです。アプリケーションを動作させる環境を含めて、守らなければなりません。 日頃意識したことがないであろう、アプリケーションでのセッション管理、サニタイズ、Unixでのプロセス管理、ファイアウォールの設定やログの意味を調べ、攻撃への対処方法を編み出すことになります。

脆弱性の修正、堅牢化中です。

2日目の新人さん達の様子です。

会議室で作業している様子
2日目午後の様子
会議室にこもり議論しつつ、進めていくチーム。

大きなクッションでくつろぎながら作業している様子
寝そべってますけど、ちゃんと仕事しています。
地下のスペースで楽な姿勢で、集中しているチーム。

チームカラーの違いが出ていますね。

新人さん達の中には、コンピュータサイエンスを学びエンジニアとして入社したメンバーもいますが、全く違う分野を学んできたメンバーもいます。

デザイナーとして入社した人のPull Request。XSSとSQL Injectionに関する修正が出され、両方ともマージされている
PullRequest

UXデザイナーとして入社した新人さんは、自分がチームに貢献できなくて申し訳ないと思っていたようですが、彼はちゃんと新人研修で学んだRailsチュートリアルを読み直して、コード上の誤りを発見して、周りに協力を求めた上で、修正するためのPull Requestを出していました。すばらしい!側で見守っていたおじさんは、涙が出そうでした。

Slackでの一幕。杉浦に「本当に防御できたのですか?と聞かれ、『調べます!』と回答する新人」
ちょっとしたツッコミ
もちろん、見守るだけではなくて、折角のSYN Flooding対策の動作確認を行なっていない新人さんがいたので、ツッコミを入れたりもしています。

2日目の午後になると、彼らは仕込んだ脆弱性のうち半分を修正してしまいました。

攻撃と防御

さて、与えられた修正期間は1.5日でした。その期間が過ぎ去ると、おじさん達が攻撃を開始します。

まずは、空いているportを探して見ましたが、ちゃんとFirewallを用いて、不要なportは閉じられていました。

SYN floodを受けているのに気付いて「たぶん影響なし」
SYN Flood?
探索活動も捕らえられてしまいました。ログもちゃんと観測していますね。 この時の探索で、SSH port*1を発見しましたが、すぐには悪用できないように対策されていました。

稼動状況のグラフ
攻撃中の稼働状況

攻撃時間の後半は、DoSからDDoSに攻撃方法を変化させました。ここで、グラフでは分かりにくいですが、対処方法の差が少し出始めました。

あらかじめ仕込んでいた脆弱性を狙ってみましたが、悪用が簡単なSQL injectionは、修正されていました。 でも、情報を搾取する糸口が全くないわけではないようでした。

結果は?

得点は、サービス稼働率と脆弱性対処数で評価することにしました。 サービス稼働率 Aチームが86% Bチームが85%

サービス稼働率は、Landing Pageの15秒以内での到達率と、E2E testの完走率の平均で評価したものです。 チームAは、より優れたSYN Flooding対策を施したことにより、Landing Pageの到達率を上げることができました!

脆弱性対処/報告数 Aチーム15% Bチーム18%

脆弱性対処数は単純な数の足し算ではなく、脆弱性を難しさに応じて傾斜配点*2し、対処されていたら+1点、テンプレートに従って報告がまとまっていればさらに+1点と評価しました。

両チームとも、アプリケーション自身が改竄されるような深刻な事態には至りませんでしたが、queryに細工することで、他のアカウントの情報が盗み見ることができてしまう脆弱性が残っていました。 debug modeによる情報漏洩に気づけたかどうか、そして質の良いレポート数の多さで、チームBが優勢となりました。

ということで、結果としては、痛み分けです。

競技を終えて

競技後のアンケートでは、「おじさん達にボコボコにされた」「もっと前提知識があれば...」といった趣旨の指摘をいただきましたが、あえて背伸びをしてもらうための研修という位置付けにした結果だと思います。

新人研修でHardeningを行うのは、「脆弱性対策として、多層防御を行うには、そもそも、ログをとって、検知しないと対処はできない」 といった、技術的にセキュリティ対策を理解することだけが、目的ではありません。 以下の状況を身を以て体験することが、社会人として仕事を始めるにあたって必要ではないかと考えたからです。

  • 実際に問題が起きた時には、訓練の時以上の質で、対処を行うのは難しい
  • 優先度をつけて作業を行わないと、最大の効果は望めない

今回、与えられる実習環境、ソースコードは、競技開始まで、誰も触ったことがないものでした。 それぞれが得意な分野を持ち寄って、未知の問題を血眼になって解決する時間って、とっても貴重なんですよ!

サービスで実際に動いているものを基にした真面目なHardeningなんて、freeeに入らない限りできない経験です。 「あの時あんなこと言ってたなー。」と、一つでも思い出していただければ、嬉しいです。

今回のHardeningは、せっかくなので7月くらいに新卒以外の人にもやってもらう*3予定です。freeersの皆さま、お楽しみに!

そういえば、勝った方のチームに、ビールを一杯おごる約束になってたのですが、どちらも勝ってはいるので、8人みんなにビールおごらないとね。

*1:port番号は変更されていました

*2:両チーム共に仕込んだ脆弱性の半分は修正していましたが、簡単なものから修正された結果、2割の得点率になっています

*3:ということで、ネタバレ禁止になっています。仕込んだ脆弱性については詳しく触れていません