技術書典に「Secure旅団」として出してきた話
TL;DR
- 技術書典6に新刊「セキュリティ畑でつかまえて」を頒布してきました。
- 新しい試みとして「学生・新社会人応援キャンペーン」を実施しました。
- 当日いらして頂いた・ご購入いただいた方・執筆いただいた方、本当にありがとうございました
- 被チェック数は504でした。
- うち学生・新社会人(2年目まで)は70人ほどでした。
- 今回は11人で執筆しました。
- 次の技術書典、当サークルでかいてみませんか?
出店してきました
技術書典3から勢いで始めた「Secure旅団」ですが、なんと技術書典6まで続いています。これには飽き性の自分自身驚くばかりです。 まあ、飽き性なところは正直変わってないのですが、「著者の好きなことを書きまくろう」という自分のアウトプット本位から、「多様なセキュリティのコンテンツを届けることで、こういったセキュリティもあるのか、という新しい発見を読者にもたらし、結果的にセキュリティの裾野が広がればいいな」と考えるようになるなど、多少の変化はあったようです。
そんなやつが主宰してるSecure旅団は、今回、様々なセキュリティのコンテンツをギュッと詰め込んだ薄い電子本*1「セキュリティ畑でつかまえて」を技術書典6で頒布させていただきました。
以下、目次と著者になります。
- GATTrackerとBurp SuiteではじめるBLE通信のキャプチャと改変 by @mahoyaya
- Fridaを用いたWindowsバイナリ動的解析の基礎 by @gr4vit0n
- Open Policy Agent 入門 by @ken5scal
- 実践 顔認証システム by @bbr_bbq
- ポートスキャン入門 by @ozuma5119
- nmapを使わない邪道なポートスキャン by @tigerszk
- K Frameworkを用いた脆弱性検出支援 by @K_atc
- WebAuthnライブラリを組み込んだパスワードレスログイン by @kg0r0
- コピペで動かすWordPress + WebAuthn by @ym405nm
- 見習いフォレンジッカー日記 by @greenshallot
- Terraformで作るHardening的演習環境 by @delphinz
↑に紹介させて頂いた皆様の力なしではSecure旅団は成り立ちません。 略式で恐縮ですが、この場をかりてお礼申し上げます*2
結果
上記の方々の協力もあり、今回はSecure旅団としては最大の頒布数になりました。 総売上はインターネッツ上で申し上げたくないマンなのでいいません*3*4。リアルで会う方にはポロッとお伝えするかもしれませんが...
個人的に一番嬉しい結果だったのは、計70人の学生・新社会人にご購入いただけたことです。
今回は新しい試みとして、学生・新社会人の方には新刊を500円で提供させていただきました。 その背景としては「セキュリティうん十万人不足」*5にあります。 数字の妥当性は置いといて、セキュリティ人材のニーズが高くなりつつある(と見える)のは間違いないです。しかし、どんな人材が不足していて、つまりどの分野に人が足りてないんでしたっけ?そもそもどんなセキュリティ分野と業務がこの日本国にあるんでしたっけ?というのは、セキュリティを主務にしてきた期間が短い方ほど分かりにくいんじゃないかな、と思っています。
だからこそ、多様で優秀な"セキュリティ人材"が寄稿する当サークルのコンテンツから、様々な分野を知り、それをもとに(おこがましいですが)自分の好きな分野へのキャリアを形成できるような層を増やしたい、そのためのハードルを下げたいという意図から、「学生・新社会人応援キャンペーン」を実施しました。 そのキャンペーンに賛同(?)してくれた方が70人もいたので、ああ、やってよかったな、と密かに思いました。
今後
飽き性なので、本サークルがいつまで継続するかわかりませんが、もうちょっと頑張って見たいと思っています。最終的に自分が目指したいのは、セキュリティ人材の不足分を埋めるというより、組織における各チームがセキュリティ機能を持つところにあります。これをどう達成していくかは、結構な頭の悩みどころです。
あと、ちょっと人数も増えてきたので、金回りなど組織的なあれそれをしないといけないので、仲間を募集しています。特に金回りに強いひと...
とりあえず
当日、当サークルに来れなかった方のために、boothでの販売を開始しました。もしよければご覧ください。 secure-brigade.booth.pm
また、もし本ブログを読んで趣旨に賛同いただけたり、新しくセキュリティネタでアウトプットしたい方がいれば、是非、次回の執筆陣にご参加いただければ幸いです*6。
「セキュア旅団」は技術書典6に出店します
TLDL
- 技術書典6にセキュア旅団として出典します
- 場所は「え01」です
- 著者は第一線で活躍している方がそれぞれ自信が注目・取り組んでいるセキュリティのことを好きに書きます
- すでに10人弱いますが、引き続き著者を募集中です。
主題
当サークルの目的
私が参加している「セキュア旅団」の技術書典6当確が決まりました。当日は「え01」にいますので是非起こしください。 思い出せば技術書展3に参加してから早3年なので、改めて当サークルが扱う内容について紹介します。
当サークルは名前の通り、セキュリティをメインに扱うサークルです。しかし、それを1つのトピックに限定することはしておりません。それは、主軸が異なる方にもセキュリティの多様性と楽しさを知っていただきたく事が目的だからです。
これは、NSCが開催しているサイバーセキュリティ月間が謳っている「みんなでしっかりサイバーセキュリティ」*1にも近いのですが、当サークルはよりグロースマインドセットな方向性を攻めて見たいと思っています。
どういうことかというと、当サークルにご参加いただいている著者に「自分(著者)の好きな・夢中になれる・楽しいと思えるトピック」を自由に書いていただき、読者の皆様にセキュリティの多様性と楽しみを感じ取れるようなサークルを私は目指しています。
最終的には、著者も読者も等しく当サークルの参加者と考えており*2、文章を通じて読み手と書き手が交わることで、一見特別に見えるセキュリティと他の領域の間にある壁を薄くし、交差する領域を実社会でも増やせれば最高です。
よって、ここでは私の書くことのみを紹介します。他の著者の内容は別途SNSなどで紹介いたします。 また、著者も絶賛募集中です!
ken\dscalが書くこと
私が何を書くかというと、今まではFIDO/OAuth/OIDC/FAPIなどの認証認可周りを書いてましたが、今回はお休みします。いや、正確に言うと認可には違いなにのですが、OAuthのような認可委譲の話ではなくクラウドネイティブやゼロトラストにおける権限ポリシーのエンジンについて書く予定です。どれくらい余裕があるかにもよりますが、平成の情シスおかしん@技術書典6さんの書く「ゼロトラストアーキテクチャ超入門」のうちの一部にフォーカスを当てた内容になります。
ご期待ください。
過去の作品
boothよりお求めいただけます。
https://booth.pm/ja/search/セキュア旅団
ぼやき
前回の技術書典5では「あ10」に配置だったのですが、壁際&角だと隣のサークルさんに並ぶ列が垂直に交わり、人の流れがこなかったんですよね...今回もリアル壁際なので同じ事にならないか心配です。ちょっとな〜...
g
っていうか、前回と今回で対角線上に配置されるの面白すぎない?
「セキュア旅団」は技術書典6に出店します
TLDL
- 技術書典6にセキュア旅団として出典します
- 場所は「え01」です
- 著者は第一線で活躍している方がそれぞれ自信が注目・取り組んでいるセキュリティのことを好きに書きます
- すでに10人弱いますが、引き続き著者を募集中です。
主題
当サークルの目的
私が参加している「セキュア旅団」の技術書典6当確が決まりました。当日は「え01」にいますので是非起こしください。 思い出せば技術書展3に参加してから早3年なので、改めて当サークルが扱う内容について紹介します。
当サークルは名前の通り、セキュリティをメインに扱うサークルです。しかし、それを1つのトピックに限定することはしておりません。それは、主軸が異なる方にもセキュリティの多様性と楽しさを知っていただきたく事が目的だからです。
これは、NSCが開催しているサイバーセキュリティ月間が謳っている「みんなでしっかりサイバーセキュリティ」*1にも近いのですが、当サークルはよりグロースマインドセットな方向性を攻めて見たいと思っています。
どういうことかというと、当サークルにご参加いただいている著者に「自分(著者)の好きな・夢中になれる・楽しいと思えるトピック」を自由に書いていただき、読者の皆様にセキュリティの多様性と楽しみを感じ取れるようなサークルを私は目指しています。
最終的には、著者も読者も等しく当サークルの参加者と考えており*2、文章を通じて読み手と書き手が交わることで、一見特別に見えるセキュリティと他の領域の間にある壁を薄くし、交差する領域を実社会でも増やせれば最高です。
よって、ここでは私の書くことのみを紹介します。他の著者の内容は別途SNSなどで紹介いたします。 また、著者も絶賛募集中です!
ken\dscalが書くこと
私が何を書くかというと、今まではFIDO/OAuth/OIDC/FAPIなどの認証認可周りを書いてましたが、今回はお休みします。いや、正確に言うと認可には違いなにのですが、OAuthのような認可委譲の話ではなくクラウドネイティブやゼロトラストにおける権限ポリシーのエンジンについて書く予定です。どれくらい余裕があるかにもよりますが、平成の情シスおかしん@技術書典6さんの書く「ゼロトラストアーキテクチャ超入門」のうちの一部にフォーカスを当てた内容になります。
ご期待ください。
過去の作品
boothよりお求めいただけます。
https://booth.pm/ja/search/セキュア旅団
ぼやき
前回の技術書典5では「あ10」に配置だったのですが、壁際&角だと隣のサークルさんに並ぶ列が垂直に交わり、人の流れがこなかったんですよね...今回もリアル壁際なので同じ事にならないか心配です。ちょっとな〜...
g
っていうか、前回と今回で対角線上に配置されるの面白すぎない?
セキュリティエンジニア in スタートアップが大事にすべき3つのポイント
FOLIOアドベントカレンダー ラストの個人投稿3回目です。過去2回は当社で利用しているプロダクトについてお話しましたが、今回は本ブログでも初のポエムになります。
セキュリティエンジニア(以降、エンジニア)がユーザー企業のスタートアップに転職したケースを目にする頻度が増え、時代の節目のようなものを感じます。
もちろん、昔からそういったスタートアップに参加するエンジニアはいたと思いますが、パブリックな情報として流れることは少なく、ましてや、経験した本人による体験談・ポエムは目にした記憶は全くありません。
そこで、今回はキャリアの選択肢の1つであろうスタートアップへの就職についての理解を深めるため、私の 超個人的経験と見解 をもとに、スタートアップで働く際に大事にすべきポイントをお話します。
どういうポジションから語るか
主観的な意見を述べるということは一定のポジションを取ることになりますので、最低限のバックグラウンドを共有させていただきます。
来歴
- 2011年: 某Nなセキュア。MSS/CSIRT/SOCに従事
- 2014年: 某MでFなFintech企業。創業2年目に参加して上場まで、社員数 50 -> 300を経験。モバイルアプリ開発とセキュリティ(なんでも)に従事
- 2018年: FOLIO。創業2年目。セキュリティ(なんでも)に従事 <- 今ここ★
スキルセット
- Blue成分多め。Red成分はGPENとWeb診断をツール回してできるくらい。
- 今後攻めていきたい分野
定義
- スタートアップ: 創業数年で、新たなビジネスモデルを開発して市場を開拓する段階の企業(コピペ)。セキュリティ専任はいない。
このような人間が超主観的に語るので、1㍉も賛同できない方はきっといると思います。そういった方は是非、別の経験と真実を共有いただければと思います。では、本題に入ります。
本題: スタートアップに入る際に大事にすべき3つのポイント
順番に紹介していきます。
VisionとCultureへ共感する
Visionはスタートアップが目指したい世界観であり、Cultureはその構築・運営時における価値観です。 そういった参加先のVision/Cultureにある程度、共感・納得しておくことが大事だと思います。 これは、リスクの多いスタートアップはは、ある程度の覚悟とその先にある世界観へ希望を持ってことにあたる必要があるためです。
どのようなリスクがあるのでしょう?まず事業リスクです。 よく言われることですが、創業から3年後のスタートアップは約50%が失敗します。そもそも市場の開拓 = 不確実性の高い領域で勝負するのですから、勝負に負けた場合、転職1年目で会社が潰れてしまうことだってありえます*1。
事業リスクのような外部だけでなく、社内部にもリスクはあります。 大きなリリースに向けた長時間勤務のような話がまずあげられます。ですが、これはスタートアップでなくともある話です。成長過程のスタートアップしかないリスクだと、いわゆる成長痛による社内の雰囲気の悪化などがあります。例えば、人事評価や組織の階層化の構築・運用開始時におけるメンバー間のスタンスの違いや、あるいは現在進行系の案件とVisionへのギャップを感じたコアメンバーの離脱などが挙げられます。
セキュリティエンジニアにとっては(プレイヤーとしての)成長の機会損失リスクです。確かにスタートアップは身軽ですが、身軽さ故に良くも悪くもおざなりになってる施策があります。そのボール拾いが最初の1年間のお仕事になる覚悟は必要です。例えば...
- 使い回されたパスワードの撲滅
- ばらまかれた特権の整理
- 整備されていないワークフローの洗い出し
- 業務端末一覧化
- 私用端末の撲滅
これらは最高に泥臭いですが、拾わなければいけないボールです。技術的なチャレンジはないただ淡々とこなす作業です。もちろん創意工夫の余地があることは否定しませんが、そんな余裕は普通ありません。技術にチャレンジする機会がすくないため、1人のエンジニアとしての技術的な成長をあきらめる一定期間というのは確実にありあmす*3。
このように、スタートアップには様々なリスクがあります。そのような環境で働くことに本当にそれだけの価値があるのでしょうか? それを見出すのがVisionとCultureです。なにも100%共感すべき、ビジョナリーカンパニーのように信望しろ、と言いたいわけではありません。 きたるツラミと戦うには一抹の希望を胸に抱かなければならなく、そのためにはVisionとCultureへの共感と納得が必要なのです。
多面的・多角的なインプットをする
スタートアップに入るセキュリティエンジニアは、おそらく最初のセキュリティエンジニアです。 そんなエンジニアにとっての最大の味方は上層部です。Visionを実現したい上層部はきたるリスクに対処する専門家の味方です。他のメンバーも同じです。
ただ、ちょっと穿った見方をすると「セキュリティなら仕方ないよね」という言い訳が通りやすい環境で、もっと穿ってみると専門家に物申す批判者が少ない環境です。
最高なUsableなセキュリティを実現しても、それが業界のレギュレーションに準拠していないならば、それは業界内の独り相撲です。逆にレギュレーションにきっちり100%沿っていても、実装がスタートアップの実態にあってないこともありえます。
技術が、規制が、コンプライアンスのうち何が優先度たかいのかという話ではありません。エンジニアがボトルネックである、という話です。1人の人間として得意とする or できることが、必ずしも全体における最適な選択肢ではない可能性があります。そして、ある選択肢を選んだエンジニアに突っ込める人はスタートアップでは本当に少ないのです。そのため、エンジニアの一面的な知識・経験ではそれ自体がリスクになる可能性があります。
したがって、エンジニアは最新技術のインプットのみならず、 フレームワーク*4やら業界規制やら社内の状況やらを様々な側面から入手・分析し、知識として蓄え、然るべき時に然るべきアウトプットを出せるようにしなければなりません。研ぐ対象が爪だけではなく、牙もわざマシンも魔具を準備しておくのです。
ビジネスとセキュリティのゴールをアライメントさせる(あるいはしているか確認する)
さて、エンジニアとして頑張った甲斐あって(?)会社も軌道にのったとしましょう。確実にその成長に貢献したと思っているところに、評価者から次のようなありがたいコメントを頂戴することもあります。
「何も成果をだしてない」
これはエンジニア本人にも評価者にも非常に悲しいことです。しかし、感傷的になっても生産的ではありません。原因を考えてみましょう。 恐らく、根本的な原因は評価者とセキュリティエンジニア間のゴールの共有不足ではないでしょうか。評価者はメンバーの貢献具合を計測します。そこには数字があり、スケジュールがあり、ロードマップがあります。セキュリティサイドにそれがない場合、またあっても共有不足で認識されていなければ、いくら貢献したと思っても評価されないのです。
せっかく使い回しのパスワード撲滅や全社2要素認証導入など泥臭い、しかし大事な作業をしたところで、その成果を認められなくては悔しくて夜も眠れないでしょう。悲しい思いをしたくないのであれば、セキュリティの戦略を作った上で、ビジネス上の戦略とのアライメントをとれるよう、密なコミュニケーションで働きかけましょう。ラフでもするのとしないのでは天地の差があります。
まとめ
スタートアップという特殊な環境にいる、特殊なセキュリティエンジニアだからこそ大事にしたい3つのポイントを共有させていただきました。この情報がスタートアップに対する転職の流動性にポジティブに働くかネガティブに働くかはわかりません。しかし、これをもとによりリアルなキャリア選択ができるようになることをのぞんでいます*5。
*1:そうなった方にこの間お会いした
*2:https://www.fool.com/careers/2017/05/03/what-percentage-of-businesses-fail-in-their-first.aspx
*3:個人活動は別
*4:例: https://csrc.nist.gov/Projects/Risk-Management
*5:できれば、一緒に働きましょう
AzureADでYubiKeyを管理しつつ認証(TOTP)する #azureAD #yubikey
FOLIOアドベントカレンダー 8日目、個人投稿2回目です。
8日に当社の勉強会「Scramble!」に来ていただいた皆様、ありがとうございました。
FOLIOの情報戦略のこれから_-_情報システムを添えて.pdf - Speaker Deck
その場でお話した通り、当社はMicrosoft365を中心にした社内基盤へ生まれ変わろうとしています。 Microsoft365のIdP「AzureAD」は柔軟かつ強固なMFA方式を自由に選べます。通知ベースのMFAもデフォルトでついてくるスグレモノです。*1 特に10月からPublic PreviewになったハードウェアキーによるTOTPは、自分にとって嬉しいニュースでした。なぜなら、何らかの理由でスマホを使えないメンバーに、完全に独立したセキュリティキーをお渡しできるからです。 そこで本エントリでは、それについて触れてみようと思います。
手順としては次の通りになります。ただし、ベンダーからバルクで購入する場合、1は不要になるようです。2までやってくれるかは原文からよみとれませんでした。
- YubiKeyに対するシードの設定
- YubiKeyとユーザーのヒモ付情報のAzureADアップロード
- 登録されたYubiKeyの有効化
YubiKeyに対するシードの設定
Yubikey Command Manger (CLI) を使って、シードをYubikeyに設定します。
% ykman oath add ken5scal@example.com Enter a secret key (base32): xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx A credential called ksuzuki@folio-sec.com already exists on this YubiKey. Do you want to overwrite it? [y/N]: y
YubiKeyとユーザーの紐づけたCSVファイルをAzureADにアップロード
さきほどのシードを登録したYubikeyをAzureADに登録します。その際に、下記のようにそのYubikeyとユーザー(UPN)を紐付けることができます。
upn,serial number,secret key,timeinterval,manufacturer,model ken5scal@example.com,111111,SECRET_KEY,30,YubiKey,HardwareKey
登録されたYubikeyを有効化
アップロードが成功したら、対象のYubiKeyを有効化します。
有効化する際に求められるOTPは、Yubikeyを挿した状態のYubikey Authenticatorに表示される値を入力すればOKです。
同様にYubikey Authenticatorで表示された値を用いて、ログイン(2段階目)をできます。
このようにして、Azure ADに対してYubikeyでOTPすることが可能です。
終わりに
実はいくつか制限があり、現在は1人に付き5デバイスまでしか設定できません。また、これは私だけかもしれませんが、一回登録を解除(削除)したYubiKeyはたとえシードを再設定したとしても、最有効化できないようです(失敗します)。Public Previewだからかもしれません。
とはいえ、やはり一番めんどくさいのはシードの設定とCSVのアップロード、そして有効化の一連の作業です。情シスの身として考えると、そこらへんの工程はできるだけなくして欲しいと思います。将来的には個人向けOffice365アカウントやGSuiteのように、そもそもYubikeyを指すだけで完結するようなることを期待しています。
9日目は @laysakuraさんです
*1:Oktaは月$6追加料金がかかります
踏み台環境でテレポートする
FOLIOのアドベントカレンダー1日目です。
ブラウザから使える踏み台(Bastion)であるGravitational社のTeleportについて書きます。SSH秘密鍵を始めとしたクレデンシャル情報をローカルからなくす(もしくはクレデンシャルのアクセス権限を永続化させない)というのは、おそらくセキュリティに携わる人の課題の一つだと思います。 踏み台の文脈におけるその課題は、AWSではSession Manager、GCPではCloud Shellなどで実現しつつあります。Teleportもそのようなソリューションの1つと捉えることができるでしょう*1。
おそらく日本語の公開事例としては初でやったぜこれでホットエントリで間違いなし承認欲求万歳、とウキウキしながらアドベントカレンダーの準備をしてたら、クラウドネイティブのすだちくんに先を越されて泣いています。あー悔しい。
というわけで、全体的なTeleportの紹介はそちらに譲り、本エントリでは当社ユニークな構成についてお話させていただきます。
- 当社の構成
- 改善ポイント
- 当社の貢献
当社の構成
構成そのものはスタンダードです。TeleportプロキシはCLIとブラウザで受けるために、それぞれNLBとALBを用意しています。 エンタープライズライセンスは共通するS3バケットにいれています。
通常利用時も特殊なことはしておりません。例外なくユーザーはIdPでのSAML認証とそのアトリビューションにより、Nodeへのログインに必要なフェデレーションおよび権限が割り振られています。ログイン後の作業ログはS3に保存され、ログインなどのイベントやセッション情報はDynamoに保存されています。
基本、AuthサーバーやProxyサーバーにログインできないようにしていますが、緊急時は停止させている緊急用踏み台を起動&SSH Proxyでのログインを実現しています。その場合、緊急ログイン用の秘密鍵が作業端末上にあると元の木阿弥ですので、当社ではKryptonと呼ばれるスマホ上のセキュアストレージに秘密鍵を入れるソリューションを使っています。これを使うと、ログイン時にスマホに利用可否通知がきて、そこでアクションをとることで初めてSSH鍵認証が完了します。原理上、秘密鍵はそこから取り出せないので、スマホを盗難されない限り安全です。
Krypton | Let's make two-factor easy & secure
プロビジョニングはConsul, Ansible, Teleportの組み合わせでしています。Nodeの方は既存の枠組に乗りAnsibleとConsulを使っています。ProxyおよびAuthサーバーはTerraformでAWSのリソースもTeleportの設定ファイルもプロビジョニングしています。
改善ポイント
デバッグ・デプロイの効率化
ログインイベントのデバッグをする場合、イベントログのはいってるDynamoを見るわけですが中々追いづらいです。また、構成管理権限を基本もっているので、デバッグのためにDynamoに入りたくないということもあります。当社の場合、Datadogを使ってメトリクスやログを収集しているので、今後はDatadogに寄せる予定です。
また、業務分掌(Segregation of Duties, SOD)を真面目にやろうとすると、Terraformでプロビジョニングしている設定ファイルとシェルスクリプトがuserdataのサイズ上限に引っかかってきます。また、デプロイ作業そのものもマニュアルな部分が多いです。よってそこは、同僚であるSREの @sion_cojp *2 の仕事を参照して、Fargate/Docker/SlackBot/Makeをもりもり使うイカしたものを作って行こうと思います。
業務分掌が辛いんじゃぁ〜
Teleport EntepriseはRBAC(Role Based Access Control)が可能です。しかしながら、あくまでもクラスターごとの設定であり、集中的な権限管理ができません*3。
真面目にSODをやろうとすると戦術の通り設定ファイルが大きくなります。各AWSアカウントごとの設定、更に言うとその中でもマイクロサービスごとに、もっというとチーム内の役割ごとに権限が異なるためです。残念ながらTeleportの設定はあくまでもYaml記述ですので、if stg && account {
if manager { allow root login} else { allow normal login } }
のような制御ができません。これに対するしくみは現状ありませんが、k8sのClusterRoleBinding
を真似して、コントロールプレーンのプラグイン作成のようなチャレンジをしてみたいと思っています。
当社のTeleportに対する貢献
当社はただTeleportを使うだけではありません。積極的に欲しい機能やバグ修正をPRするなど、コミュニティへの貢献もしております。
残念ながらまだコントリビューターにはなれていませんが(cherry-pickされてる)、OSSであるからには開発者と利用者が協力して継続的なサービス改善に挑んで行きたいと思います。
FOLIOでは仲間を募集しています
ビジネスとそれを取り巻く環境(含むセキュリティ)は日進月歩です。ビジネスサイドや開発者が圧倒的な進化を遂げて新しいサービスと価値を世に広めようとするなら、情シスやセキュリティもそれに適応していくことが求められます*4。
そのためには、最新の技術動向やOSSを含む製品選定が求められていくことになりますが、時には文字通りコミットすることで技術やOSSそのものをドライブすることも今後の情シス・セキュリティチームに必要になってくると思います。 そういったアクティブな情シス・セキュリティ活動を当社でやってみたいかたは Twitterの @ken5scal に気軽にDMください :)
2日目は @mura-mi さんです。
Go Global参加レポ
上記のイベントにシュッと参加してきたのでレポ。
tldr
現地で働いてるかたのナマの声などがきけて為になった。 leetcode頑張ろうと思いました。DroidKaigiが終わったら。
各セッション
「メルカリにおける技術者採用方法の変遷」とスマニューの「コーディング試験Codility運用の実態と実績」は遅刻したためレポなしです...すみません...
[リクルート] コードテストでtrack.runを使ってる話と採用フロー by @yosuke_furukawa
- インターンのコードテストでtrack.runを利用している。
- DB操作、HTTP API送信・受信、アルゴリズム問題、数学問題が題材
- 時間切れになってしても、回答の中でアピールすることが可能
- 中途面接の場合は、職務履歴書から質問を考えて、そのかたが何を学んだかにフォーカスする。自分の成長の場ともしている
[インディーゲーム開発者]:付け焼き刃でベイエリアの面接を突破するたった一つの方法 by @daigo
- ホワイトボード面接が苦手
- なぜなら通常の業務では鍛えられないスキルだから(Homebrewの作者も落ちる)
- とはいえ、変な人を入れるよりマシ
- 電話面接よりもマシ
- tips:
コーディング面接を受ける際の Tips by @thagikura
- ホワイトボード面接苦手税
- オンライン面接はIDE利用不可だが、易しめ
- オンサイトはホワイトボードで、コード以外にまれにアーキやデザインに関する題材もあった
- 時間は貴重
- 30min out of 45minくらいしかコードを書く暇がない
- 解決法を思いつくのはポイントの1つ
- 早く終われば終わるほど、自己アピールタイムも増える
- やはり記述料がすくない言語のがいいが、省略してもよいという面接官もいる
- メソッド分割も大事で、前提条件に特定のメソッドがあるということにしてもよい
- データ構造やアルゴリズムが大事
QuipperのWebエンジニア採用におけるコードて
- 今は1問あたり2hrほどの問題を3つ家で解いてもらっている
- 言語はRuby/JS
- もともとは1つのアプリまるまる作ってもらってたが、それだと時間がかかりすぎた
- したがって方針を1) コードテストはなくさず 2)要素技術のみを解いてもらい 3)アルゴリズム問題はださない、ことにした
- そうすることで2week -> 3dayのプロセスにした
人生出始めて外資の会社を受けてみた by @ganezasan
- 日本のコーディング面接は、予備動作がなく、面接の場でいきなり題材がでてくる
- また前提条件がざっくりしていることが多い
テックインタビュー裏表 by @mogutan88
- 一時期、学歴詐称が通るくらいゆるい基準だったことがある(というのが面白かった)
グローバルIT企業での働くまで・働いてみての学び by @daikikohara
- JDは熟読するべし
- 実務経験3年はCS1年分の学位に相当
- Cover LetterはLinkedInのプロファイルが充実していればいらない