学生に対して情報セキュリティに関する高度な技術教育を実施し、次代を担う情報セキュリティ人材を発掘・育成する事業「セキュリティ・キャンプ」をご存知でしょうか？セキュリティ業界では名前のよく知られているこのイベントに、2017年よりメルカリは協賛を続けてきました。

このイベントは参加枠が限られており、参加のためには高倍率の選考をくぐり抜ける必要があるそうです。その代わりに、受講料や教材費などの負担が一切なく（！）、業界の最先端を行くキープレイヤーたちから質の高い講義を受けられるのが特徴です。

今回は、8月8日から5日間にわたって開催された開催された、「セキュリティ・キャンプ全国大会2022」で講師を務めた、末澤裕希さん（@rung）と上田拓也さん（@tenntenn）に、セキュリティ・キャンプでの講義のことから、最近のセキュリティの潮流に関する“よもやま話”まで、フリートーク的にお話を聞いてきました！

セキュリティ・キャンプの講師をすることで得られた学び

──早速ですが、お二人はどのような内容の講義をしたんですか？

@rung：僕は「Webセキュリティクラス」で講義をしました。Webセキュリティというと、ふつうはWebのことを話すクラスだと思われるかもしれないですが、今回プロデューサーの方の考え方が違っていて、Web以外のことも含めた、プロダクトを開発する際に直面する課題全体について学ぶクラスとして設計されていました。ユーザー企業で働き、課題解決している人に講師をしてほしいという意図があったらしく、まさにメルカリは自社プロダクトを有するユーザー企業で、他のエンジニアリング組織と協同して課題解決を行っていることから、今回声をかけていただきました。クラスのコンセプトや各講義についての詳細はプロデューサーの米内さんが、ブログで公開しています。

僕の講義では、開発者の使っている開発環境が今どういう問題に直面しているかについて話しました。タイトルは「開発環境のセキュリティおよびCI/CDパイプラインのセキュア化」で、現在の開発環境の変化により出てきた新たなリスクと攻撃パスの全体像をはじめに説明したあと、開発端末に残る認証情報とCI/CDパイプラインについて攻撃手法と守り方の双方を実際のハンズオンを通して解説しました。

ここ最近のPublic CloudやSaaSなどの利用の進んだ開発環境だと、Cookieやローカルファイルに認証情報が保管されます。どれだけ2要素認証などを用いて認証時のセキュリティを改善しても、認証後に発行される認証情報が取られたら攻撃が成功してしまう。また、CI/CDをセキュリティを気にせず使うと、一人のユーザが思わぬ強い権限を獲得できてしまう。そういった話について、たとえば端末にマルウェアなどを用いて侵入されたらどうなるのか、実際にChromeのCookieを復号したり、CI/CDを構築して攻撃して守るといったことを一通り解説し、参加者にはハンズオンで実践してもらいました。

末澤裕希（@rung）

ハンズオン資料：https://github.com/rung/training-devenv-security

@tenntenn：私が参加したのは「脅威解析クラス」で、おもにセキュリティの専門家が講師をしているのですが、私だけセキュリティの専門家ではなく、バックエンドエンジニアの立場として参加しました。講義の内容はほぼ丸一日使って、ソースコードから脆弱性を見つけようというものです。プログラムから脆弱性につながるような部分を探し出す解析ツールの作り方を学ぶ講義です。特に私が得意なこともありGoの静的解析についてお話しました。

講師をすることになった経緯については、静的解析という手法を趣味でやっているので、そういったところからsowawaさん（メルペイ・メルコイン取締役CISO・曾川景介）経由で話をいただいて参加することになりました。

学生は朝から夕方まで没頭し、その後も学んだことを復習していて、かつ5日間も続くので熱量がものすごく高いですよね。

登壇資料：https://tenn.in/seccamp22

──セキュリティ・キャンプに講師として参加してみて改めていかがでしたか？

@tenntenn：学生が参加するというと、だいたいの人は大学生を思い浮かべると思うんですけど、中学生や高専生もいて、一口に学生といっても年齢にも幅があり、いろんなバックグラウンドを持った、業界これからのを担うであろう人たちが集まっていました。みなさんの熱量は非常に高かったです。

上田拓也（@tenntenn）

@rung：講師をして思ったのが、学生などの若い方を相手にする際、講師だから教えてあげるという立場になることが多いと思うのですが、セキュリティ・キャンプの場合は各学生それぞれが得意とする分野を持っていて、自分たちも尊敬できるような人が集まっていました。逆に講師側が学ばせてもらうこともあったのが印象的でした。

@tenntenn：最終日に全体の発表会があるんですけど、そこでほかのクラスが何をやっていたのかとか、いろいろ話が聞けるんですけど、それがかなりおもしろかったですね。プレゼンの仕方も非常に上手でしたし、講師側としては学生たちに自分の講義がどう捉えられたかドキドキしながら聞いてました（笑）。

──講義の準備をすることが、ご自身の仕事を改めて言語化するいい機会になったのではないかと推測しますが。

@rung：まさにそうですね。自分の発表内容は実際にメルカリで得た知見や課題をまとめ直した話になっています。今回、学生やほかの講師陣、そして社外の方々に共有することで、メルカリだけでなく、今後世の中全体で考えていくべき課題が自分の中でも浮き彫りになった気がします。

@tenntenn：私もいろいろ調べたりしたのはもちろん、静的解析の話は脆弱性を見つけることだけではないので、今回のために脆弱性を見つけるというところのサンプルをは準備したんですけど、これまで若手のエンジニアにそういうことを伝える機会とかあまりなかったので、ちょっと難易度が高すぎたとか反省点はありました。もうちょっと簡単なところから教えたほうがよかったなとか。

@rung：講義は座学だけでなく、ハンズオンも含みます。理論だけでなく、実際に攻撃をしてみて、守って、というステップまで用意したので、今回の資料は学生だけでなく、すでに会社で働いているセキュリティエンジニアやプロダクト開発者の方も得られるものがあるのではないかと期待しています。

@tenntenn：全体的に価値のある資料ばかりですよね。基本的に、理論だけだとどうしても頭に入ってこないので、学生が手を動かしてもらうことを重視しています。知識のすでにある人に対して、「これとこれをやってください」というものではなくて、ある種の「縛りルール」のなかでハンズオンの課題をつくるのはけっこう難しいですね。あと、それ以上に時間の縛りがすごく難しい（笑）。

@rung：時間をオーバーしないように、必死でタイムマネジメントしながらやりましたね（笑）。

@tenntenn：私は準備したものがぜんぜん終わらなかったです（笑）。一区切りはしたけど、もうちょっとやりたかった…。

コンピュータ・サイエンスを学ぶことで、セキュリティをより深く理解できる

──ここからは少しフリートーク的にセキュリティについてお話をうかがっていきたいのですが、そもそもおふたりのセキュリティへの関心はどこから？

@rung：コンピュータの勉強をどんどん深めていくなかで、セキュリティのことを勉強するとコンピュータの仕組みがわかることに面白みを感じたことがきっかけです。もともと僕はコンピュータの仕組みを知ることに関心があって、どうやってプログラムが動いているのか、どうやってプログラムがコンパイルされるのかなどを知るのがすごく楽しかった。さらにセキュリティについて理解を深めていきたいと思って、新卒で入った会社でセキュリティの部門に異動させていただき、それからずっとセキュリティエンジニアをしています。

@tenntenn：私もそもそも専門外ではあるのですが、ソースコードの解析が好きで、もともと学生の頃からプログラミング言語とか、講義でいうとプログラミング言語論、形式言語論に関するものが好きだったので、その流れでソースコードを解析することをずっとやっていました。メルカリでrungさんと出会ったことが、私の中で静的解析とセキュリティがつながっていくきっかけになりました。

──セキュリティに興味を持った人がまず勉強するべきことはなんでしょうか？

@rung：その質問はセキュリティエンジニアになりたい人からよく受けます。そもそも論になると思うのですが、「まずは基礎的なコンピュータ・サイエンスなどの勉強をしたほうがいいです」と言うことが多いです。技術的なセキュリティ分野については、まずソフトウェアなどがあって、「穴」が一部で生まれるということがセキュリティの脆弱性だったりするので、OSやプログラミングなどのトピックについて、基礎的な勉強をするのがまず重要だと伝えています。

@tenntenn：結局、ソフトウェアだったり、なにかの「穴」を守るというのが、セキュリティの話になるということですよね？

@rung：そうです。特にソフトウェアエンジニアは自分がつくっているものを理解しておくことが重要なのかなという気がしています。

@tenntenn：コンピュータサイエンスはもちろんなんですけど、各プログラミング言語だったり、周辺のソフトウェアだったり、セキュリティエンジニアはかなり知識が問われると思うんですよね。そのあたりってどう勉強していくんですか？

@rung：もちろんセキュリティに特化した書籍もたくさんありますし、Goなどの具体的なケースを知りたい場合は、公開されているベストプラクティスなどから学んでいくのがいいのかなと思っています。GoだったらOWASPがセキュリティコーディングガイドを公開していたりするので、そういった資料からも学ぶことができると思います。

@tenntenn：なるほど。セキュリティのベストプラクティスを学んで、自分たちのプロダクトに反映していくと。

──特にここ最近でのセキュリティの変化や新しい課題はあるのでしょうか？

@rung：そうですね。自分の講義した内容にも関連しますが、最近はDevOpsのカルチャーが浸透してきて、開発と運用が近くなっている印象を持っています。たとえば今って、バックエンドエンジニアの人がクラウドの基盤もさわったりするんですね。あとはGitOpsでインフラを管理したりとか、コンテナをビルドするCI/CDを組んだりとかもしますよね。バックエンドエンジニアが考えないといけない領域はどんどん広がっているように思っています。

@tenntenn：メルカリみたいにチームがいろいろと分かれていて、それぞれが独立してセキュリティのことを考えている状況で、どう連携していくのがいいんでしょうか？

@rung：まさにそこがメルカリみたいな大規模かつ、多くのチームを抱えている会社が直面している課題だと思います。ひとつ解になるかなと思うのが、プラットフォームです。メルカリにはPlatformチームというチームがあります。そのチームがなにをやっているのかというと、開発者の基盤をつくるチームなんです。たとえば、インフラストラクチャーの設定の抽象化をするための仕組みを提供しています。開発者が新しい基盤を作るときに、共通化された設定を行うだけで、細かいことや複雑な設定は、プラットフォーム側の抽象化レイヤーで吸収してくれるような仕組みを提供しています。こういった方法を用いて、セキュリティがその抽象化レイヤーを改善することで、全社が自然と安全になっていくというアプローチがよいのではないかと思っています。

たとえば、Kubernetesはアプリケーション基盤としてよく使われるんですけど、かなり複雑なので、すべての開発者がKubernetesのことを理解することはできない。そういったときに、Platformチームとセキュリティチームが協力して抽象化レイヤーを改善することで、開発者は共通化された設定に従うだけで、セキュリティが自然と担保される状態を実現できるんじゃないかなと思っています。

@tenntenn：なるほど。アプリケーションって、セキュリティエンジニアがすべてに目を通すわけにはいかないと思うんですけど、セキュリティの担保はどうしていくんですか？

@rung：良い質問ですねー（笑）。さきほどはインフラレイヤーの話でしたが、今回の質問はアプリケーションに脆弱性をつくりこまないようにどうするかという話ですよね？

アプリケーションを定期的にセキュリティエンジニアがレビューして、脆弱性がないかを確かめるのが一般的なやり方なんですけど、たとえば現実的に開発者が1000人いて、セキュリティチームが10人しかいないような状況だと、それは現実的に行えるものではないですよね。ここ最近はDevSecOpsといって、書いたコードに対して自動的にセキュリティのレビューを入れていくアプローチがコンセプトとして提唱されています。

@tenntenn：ちなみにバックエンドエンジニアだと負荷対策・負荷試験をやるんですけど、セキュリティ的な面での負荷試験とかを行ったりするんですか？つくったもののソースコードのレビューをひとつずつは難しいと思うんですけど。

@rung：この10年で一気に発展したFuzzingというアプローチがあって、それはなにかというと、バグを見るけるために、プログラムに対して自動的に改変されたデータをInputとして与えて、長い時間をかけてプログラムの各実行パスのカバレッジなどを確認などして自動検査するアプローチです。今年Go 1.18でFuzzingの機能が標準搭載されましたよね。

@tenntenn：Goの場合は、標準で使えるようになって、Goチームやコミッターがコンパイラやランタイムレベルでの脆弱性を見つけるだけでなく、一般のGoエンジニアが自分たちのサービスにおける脆弱性を見つけるみたいなところにも応用がきいてくるのかなという感じがしますね。

バックエンドエンジニアがつくったものの品質的なものって、QAやテストで品質をはかるんですけど、セキュリティエンジニアはつくったものの品質はどうはかるんですか？単体テストでいうカバレッジのような指標とかそういう考え方ってあるんですか？

@rung：あー難しい質問ですね（笑）。アプリケーションの脆弱性診断を専門的に行う人などと話していてもカバレッジという概念が用いられることはありますが、なかなか実際に図るのは難しいと聞いています。逆に質問なのですが、DevSecOpsというコンセプトでは静的解析を用いたセキュリティ検査（SAST）が重要な一つの要素になるんですね。tenntennさんは静的解析ツールをたくさん作っていますが、静的解析の可能性や限界をどう捉えていますか？

@tenntenn：そうですね。まったくやったことのない人には夢のような技術だと思われる。しかし実行していないがゆえにやっぱり限界がある。実行してみて検査するものもあるけど、それはやはりコストがかかる。

ソースコードの解析は、エッジケースが多いので、例えばわかりやすい例でいうと、日本語でしゃべる可能性がある、表現できる可能性がある言葉って無限にある。コンピュータで処理されるプログラミングも同じような話なので、そこから無限にある組み合わせの中から、脆弱性を見つけるのは非常に難易度が高い作業。たとえ人間がつくったプログラミング言語であってもエッジケースは本当にいっぱいある。日本語でいうと「です」で終わっているのか、「である」で終わっているのか、そういった要因から解析が分岐してしまって、片方は追えていても、片方は漏れてしまう。たぶん脆弱性なんだけど、脆弱性にならないパターンもある…みたいな。中には静的解析では発見できず、本当に実行しないとわからないものもあります。ソースコードを解析するといっても完全にわかるわけではないんです。

@rung：自分も少しですが静的解析のコードを書いた限りだと、同じ認識です。過去にオープンソースの静的解析ツール（gosec）にコントリビュートした際、特定の条件だと検知しないな…などと思いながらコードを書いていました。

単純な関数の利用の検知であれば簡単ですが、複数の条件が関わってくると難しくなってくる。世の中に出回っている脆弱性のすべてを検知はできない、あくまで追加の対策のひとつとして入れる、そして、静的解析で拾えない箇所があることを認識しておくことが重要かなと思ったりしています。

@tenntenn：万能ではないということですね。セキュリティ・キャンプの講義でも伝えたんですけど、すべての解析、すべてのセキュリティ対策は万能であるとか、完全に防げるということはないですね。

「人は間違えるもの」。そのうえでどう安全にするのかを考える

──万能でないとなると、どのように精度を高めていくものなのですか？

@rung：自動セキュリティ検査のコンセプトはとても素晴らしいのです。ですが、まだ理想が現実になっているわけではなくギャップがあるので、コンセプト一辺倒で今までのものはいらないという考え方ではなくて、それらを組み合わせてリスクを減らしていくことを考えることが重要なのかなと。

@tenntenn：静的解析のなかでも解析のレベルがあるので、解析できる範囲が度合いによって変わってくるから、そのへんをがんばってつくるのも一つの手だと思うんですけど、それにも限界があるなと思います。

@rung：あとはtenntennさんとセキュリティキャンプの開催前などにも話していた話なのですが、Google社内の方が作成したsafe-sqlというライブラリがあるんですけど、そのアプローチはとてもおもしろいと思っているので紹介します。セキュリティ・キャンプ後に、tenntennさんが詳細をまとめた記事もあります。

このライブラリは、「セキュア・バイ・デフォルト（Secure By Default）」という考え方に基づいて作られています、人は必ず間違えることはあるし、開発者も増えていくにつれて、間違いが発生する確率は上がっていく。以前だとセキュリティは、「間違う人がダメ」で気をつけないから失敗するみたいな考え方があったように思うのですが、最近は考え方が変わってきていて、「人は間違えるもの」で、そのうえでどう安全にするのかを考えようという前向きな方向の議論が増えてきました。気をつけなくても、デフォルトの状態で安全ですというのが「セキュア・バイ・デフォルト」の考え方なんです。

safe-sqlというライブラリは、このライブラリを使えば安全ですと保証できる設計になっていて、そういったライブラリを用意した上で、全員に使ってもらう。そこでも静的解析の使い所はあって、今までの「危ないコードを検知」ではなく、「safe-sqlを使ってない場合は検知」という、逆のアプローチで使うことができます。そういった統制のための静的解析というのも、新しい可能性の一つとしてあると思っています。

@tenntenn：サービスを作ってると、特別なユーザーだけデータベースのこういうデータにアクセスできますとするものはよくありますよね。基本的に「全員アクセスできない」状態からはじまるのが「セキュア・バイ・デフォルト」の考え方。全部塞いで穴をあけていく感じ、穴をふさぐのではなく。そうすると穴をふさぎ忘れることがなくなる。

@rung：穴があれば防いでいくDeny list的なアプローチから、セキュアな状態が基本で、許可された例外のみAllow listで管理するアプローチに変えていくときに、社内では「セキュア・バイ・デフォルト」という言葉を使ったりしていますね。クラウドの権限については、数分から数時間などの一時的な権限を承認があった場合のみ与えることで、全員がデフォルトではアクセスできない状態を維持する仕組みも社内にあります。間違えてずっと権限が残り続けないための仕組みですね。

──なるほど、興味深い考え方ですね。

@tenntenn：バックエンドエンジニアのなかでは、まだあまり広まっていない話だと思います。バックエンドエンジニアが日頃使うライブラリとかエコシステムは、Goの場合は、公式に提供しているものやデファクトスタンダードになっているものが中心になるので、そこが対応しないとなかなか広まって定着しないので、そこにどう組み込まれるか重要になってくる。

@rung：ちなみにバックエンドエンジニアから、セキュリティエンジニアへの期待みたいなものってありますか？

@tenntenn：ほかの領域のエンジニアに対しても同じ感情を抱くんですけど、知らないことを知っている人だなと思うので、お互い積極的に情報交換をするべきだと思っています。バックエンドエンジニアは自分たちが使っている技術には詳しいんですけど、そこに脆弱性が入り込む余地があるのか、日頃の開発では深く考えることをしないかもしれないですね。

──メルカリではそういった交わる場とか仕組みはあるんですか？

@rung：セキュリティ・キャンプの前から、tenntennさんとは定期的に話をしていますが、もともとのきっかけは「Go Friday」というメルカリで毎週やっているGoの勉強会で話したことだったと思います。その他にも、YouTubeでの配信イベントで一緒に登壇したり、普段もSlackで情報交換したりと繋がりがありました。

@tenntenn：メルカリのエンジニアは横のつながりがフラットですよね。疑問に思ったことがあったら、誰かが誰かを紹介してくれるとか、そういうのでつながることは多いと思います。

@rung：セキュリティエンジニアとして働いていて、ソフトウェアエンジニアなどの別のチームと常に情報交換しながら現実的な問題とむきあえるのは新鮮だし、面白いなと思いながら仕事しています。

セキュリティって本当におもしろい

──最後に、今後もメルカリとして、セキュリティ・キャンプに継続して取り組んでいくのでしょうか？

@rung：今回講師を引き受けたのは、会社のためというよりは、普段とは違う視野でセキュリティを見つめるきっかけになるなど、自分自身にとって新たなチャレンジができると思ったからです。その上で、会社やセキュリティチーム全体としても協賛を継続したり、学生と交流するなど、今後もサポートできることがあるかと思っています。

世の中にセキュリティエンジニアはぜんぜん足りていないので、もっと増えてほしいと思っているのですが、今回改めてやる気のある好奇心を持った方々に会えて、将来が楽しみだなと思いました。そして、そういった方々が5年後10年後、メルカリに入社してくることもあるかもしれない。会社としても個人としても価値のある取り組みなので、今後も応援したいなと思いました。

@tenntenn：業界にとっても大事なことだと思います。

@rung：セキュリティだけじゃなくて、ソフトウェアが好きな人にも参加を検討してみてほしいと思いました。セキュリティを学ぶことは、ソフトウェアの開発者にとっても学びが多いですし。

@tenntenn：最初にrungさんが言っていた、セキュリティを学ぶにはコンピュータ・サイエンスを勉強をしたほうがいいという話とつながるのですが、やっている内容はコンピュータ・サイエンスについて深く知れたりとか、クラスによっては実働的な、実際のソフトウェアを開発するうえで現場の知識だったりとか、総合的に学べる場所なのかなと思います。自分が受けてない講義もおもしろいものも多いので、最後の発表会の資料をつまみぐいをするのもいいなと思います。

@rung：若い人にとってはコンピュータが好きな人が集まって学生のときに仲間を見つけるのって、すごく価値があるいい機会です。やっぱり、セキュリティって本当におもしろいと思うんですよ。穴を見つけるというのもそうですし、穴をふさぐというのも。自分はコンピューターを知れるというところが入り口だったんですけど、セキュリティ・キャンプの講義ってコンピューターをもっと深く知ることのできる内容がすごく多くて、そういうところに学生もおもしろみを感じていたんじゃないかな。

@tenntenn：子どもの頃にテレビゲームのバグを探したり、裏技を楽しんだりと同じようなところがあるんじゃないかと思っています。

@rung：パズル的なおもしろさはありますよね。

@tenntenn：知識量が満たされるというか、知識量が問われるパズルを解いている感覚はありますね。

@rung：講師目線で見ても、セキュリティ・キャンプは非常におもしろい取り組みです。全国大会は毎年開催されていますし、ミニキャンプと呼ばれる短い期間での講義も行われているので学生の方はぜひ参加を検討してみてください！

セキュリティ・キャンプ
https://www.ipa.go.jp/jinzai/camp/