エンジニアのキャリアとモチベーション
日本最大級のエンジニアコミュニティ、Qiitaプロダクトマネージャーの清野俊文です。
この番組では、日本で活躍するエンジニアをゲストに迎え、キャリアやモチベーションの話を浮かぼりしながら、エンジニアの皆さんに役立つヒントを発信していきます。
ゲストは、Easy Sekiya Solutions取締役CTOで徳丸ひろしさんです。よろしくお願いします。
よろしくお願いします。
はい、今回もですね、徳丸さんとお送りしたいなと思っております。
今回はですね、徳丸さんとお送りするテーマは、Webセキュリティの面白さと本の執筆についてです。
はい、今回はですね、セキュリティのところについて、もうちょっと深掘りしながらお伺いしていきたいなと思っております。
わかりました。
はい、よろしくお願いします。
最初にお伺いしていきたいなと思っているところで言うと、前回、徳丸さんはセキュリティというところに面白さを感じて、のめり込んでいったってお話あったと思います。
ただ、その一方で、セキュリティ、僕自身もそうなんですけど、とっつきにくさみたいなのが結構あるなと思っていて、
Webアプリとかって書けば動いて嬉しいみたいなのが結構わかりやすいと思うんですけど、
セキュリティって攻撃をまず学んでいくとか、実際動かしてみるみたいなところが、面白さに気づくまで結構色々勉強しないといけないみたいなところがある気がしてます。
なので、これからセキュリティとかを勉強していく人たちに対してアドバイスというか、こういうことからやっていくといいよみたいなのがあったらぜひお伺いしてみたいなと思っていたんですけど。
はい、わかりました。
実はちょっとそういう質問が多いんですが、私自身はあんまりうまく答えられないことが多くてですね。
そうなんですね。
と言いますのは、私にとってはセキュリティって面白いものなんで、面白くないんですけどどうしたらいいですかって言われてもですね、
え、面白いけどみたいなふうになっちゃうんですが、そうも言っとれんので、やっぱり先ほども清野さんおっしゃったようにですね、
攻撃から入るっていうのは、出っ取ればいいかなとは思いますね。
で、こんなことができるのかみたいな、知的な驚きと言いますか。
そういうのをモチベーションにするのが早見しかなと思いますし。
逆にですね、あんまりそういうの面白くないって言うなら、無理にやらなくていいんじゃないかとさえ思ってしまいますね。
ソフトウェアを書く人であれば、安全にするっていうのは責務としてあるんですけども、
そうではなくて、セキュリティを仕事にするかどうかっていうことで言うと、
ソフトウェアのセキュリティの例えば攻撃とか興味のようなものを見て、これはすごいと思えないんだったら、また別の仕事でいいんじゃないかなと思ってしまいますね。
なるほど、ありがとうございます。
やっぱり今お話の中にもあったと思うんですけど、セキュリティってイメージ座学っぽさみたいなのはある気がしていて、
物作りというより最初に勉強していくみたいな、しかも現代においてのセキュリティって結構攻撃がいろいろ出てきていて、
それの対策みたいな感じになっちゃっているので、本来のセキュリティってそこを攻撃者側としてこういうことできるよねとか、
前回のお話にあった文字通りハックしていくというか、そういう面白さプラスそこをうまく防御していくっていう守りのセキュリティっていうところのお話がある気がするので、
そこら辺は確かに一緒に勉強していくところを手動かしながらやっていくのが面白いのかなって感じは、今お話聞いてて思いましたね。
セキュリティの勉強方法とテクニックの発展
私自身はあんまりやってないんですが、今ですといろんなサービスで、トライハックミーとか、ハックザボックスとか、そういった攻撃を学ぶとかですね、
あるいは攻撃を学びながらそのところまで学べるみたいなサイトもありますし、それからいわゆるやられサイトですね。
脆弱性がもともといっぱい入っているアプリケーションやサービスで、そこを自分で攻撃してみるみたいなのが古典的ですが、いいんじゃないかなと思います。
で、実は私自身ですね、バットトゥードゥ、トゥドゥってやつ、トゥドゥリストのトゥドゥですが、というのを発表してまして、皆さんに試していただけるようになっています。
これ、たぶん50個以上脆弱性が入っています。
それぞれパターン違うもので、非常にたくさんの脆弱性が入っています。
なるほど。徳丸さんの本自体もやっぱり手を動かして学べるスタイルになっている気がしているので、そこらへんを触りながらやっていくのはすごい面白そうですね。ありがとうございます。
そう思います。私の本の初版が2011年に出たんですが、その段階でそういう環境を添付したいということになりまして、当時初期の段階ではCD-ROMをつけたんですが、そこにVMウェアプレイヤーとかVMそのものとか、そういったものをつけて販売しておりまして、
ちゃんと手を動かして勉強してねというメッセージでありました。
これもぜひお伺いしてみたいなと思うところでいうと、徳丸さん自身ってセキュリティのキャッチアップとか勉強って今どうやってやってらっしゃるんですか?
徳丸 えっとですね、あんまりずっとこのサイトを見てるとかですね、そういうのは実はあんまりなくてですね。
そうなんですね。
徳丸 Xですね、旧ツイッターとか、あと自分が気にしてるテーマっていうのがありまして、それで検索したりたまたま引っかかったりしたらそこを深く追っかけるとかですね、そういうスタイルでやってますね。
これもあんまり人にお勧めできるかというとあんまりできない気もしますが、インターネット中心ではありつつも、例えばですね、いろんなプログラミングの仕方、ウェブアプリケーションの作り方がどんどん進化変化してるわけですが、
そういう中でこういう脆弱性が入るんじゃないかなという着想を得るわけですよ。
で、そうするとですね、これ前からやってるんですけど、昔ですとPHPの入門書って今世の中いっぱいあるわけですね、PHP言語の入門書です。
で、それを出たら買ってきてですね、脆弱性がないか調べるんですよ。
そうすると脆弱性が結構あると。
で、じゃあどういう人が書いてるかというと、別に単にプログラムのこと知らないライターさんが書くっていうのは実はあんまりなくて、
例えばフリーの開発者であったりですね、一応専門家なわけですよ。
で、専門家が書いてもやっぱりセキュリティという面ではこういうレベルなんだなみたいなことが間接的にわかるわけですね。
あるいは最近はYouTube動画なんかも見てまして、それはセキュリティのYouTube動画じゃなくて、
こうやって開発するんだよっていうのをですね、日本とかアメリカ、アメリカだとよくインド系の方がインドナマリの映画を喋っておられますが、
ああいうのを見たりしてですね、あれこれはちょっと違うんじゃないかみたいなところを気づき終えてですね、
そこを深掘りして調べるとかですね、いうことを自宅ではやってますね。
ああ、そうなんですね。結構いろんな方が作っているところを見ながら、
いわゆる一攻撃者目線というか、そういうところでいろいろハックというか、見つけていっているというような感じなんですね。
そうですね。前回でも言いましたが、やっぱりもともとあるのは仮説なんですよ。
新しい作り方になったらこういう脆弱性が生まれるんじゃないかと。
それはこういうことがあり得るということで、別に発表してもいいんですが、
一歩進めてですね、実際こういうことをやっているのを見つけたいんですね、私としては。
だからちょっといろいろ探し回っているというところですね。
そうやって探し回っている中で、よく言われている常識化したセキュリティのテクニックとか攻撃手法以外のところが新しく見つかるとかってあったりするんですか?
ありますね。
そうなんですね。
ありますが、それが常識でないかどうかっていうのは、それはもう常識でしょうみたいなこと言われちゃうかもしれませんけど、それはありますね。
そうなんですね。
そういうのを見つけるときってどうそれも調べていったりするんですか?
結構そのテクニックが分かっているものとかだったら、それを当てはめるとこういう攻撃できそうだなとかって分かる気がするんですけど。
全く新しいっていうのは実はそんなに多くなくて、
そうなんですね。
過去から蓄積された攻撃手法の延長線にあるものが多いんですね。
例えば、今となっては当たり前になりましたが、サーバーサイドリクエストフォージリっていう攻撃的脆弱性があります。
これは何かっていうと、サーバーなどからURL指定で外部のサイトなどに情報を取りに行くと。
その情報を取りに行くURLが外から指定できたりする場合がありますが、
そういう場合に、例えば外じゃなくて、データセンターとかクラウドの中の内部のサーバーにアクセスできちゃうと。
だからそのアプリケーションをいわばプロ機種として経由して攻撃できる、通信できるとダメだよねっていうのがサーバーサイドリクエストフォージリです。
ただこれは成り立ちとしては非常に古典的なディレクトリートラバーサルっていう攻撃と似ていまして、
ディレクトリートラバーサルの場合は、そのファイルのパスを指定できる場合に起こるんですが、
パスをURLに置き換えるとSSRF、サーバーサイドリクエストフォージリになるんですね。
ですから、その古典的な脆弱性を学んで、ただ丸暗記するんじゃなくて、咀嚼することで、その発展で新しい脆弱性に築ける。
SSRFは私が築いたわけじゃないですけども、そういう延長で考えるっていうのは有効だと思います。
なるほど。ありがとうございます。
今お話を伺ってて、ちょっと気になったところで言うと、
セキュリティみたいなところを発展させていくためにいろいろそういうハックをしていくと、
逆に新しい攻撃手法が見つかっていっちゃうじゃないですか。
そうするとそれが攻撃者も知ることになるので、
今までそれが気づかれてなかったから、特に攻撃されてなかったサービスとかが新しい攻撃されちゃうみたいなのがある気がしてて、
そこら辺のセキュリティっていうところを発展させていくためにいろいろやっていると、
Webセキュリティのジレンマ
結果的に攻撃手法も増えていくみたいなジレンマみたいなのって感じたりすることってありますか?
ありますね。
そうなんですね。
ですが、例えばこのサーバーに脆弱性があるって言うんだったら、
そのサーバーに管理者に伝えればそれで済むわけですが、
新しい手法に気がついたとなると、世界中の開発者にそれを教えてあげるけど、
攻撃者には教えないっていうことはできないわけですね。
ですから、結論としては広く発表するしかないということであります。
私、かなり前なんですが、第1回でiModeの話をいたしましたが、
iModeのサイトで当時簡単ログインといってパスワードレスで認証できる。
これはドコモが出している正式な認証サービスではなくて、
各サイトが独自にiModeの仕組みを使って認証がパスワードレスでできるという仕組みがあったんですが、
それが実は攻撃できてしまうということに気づいたんですね。
徳丸さんが気づいたんですか?
はい、私が気づきました。
ところが、これドコモ側で対策できれば、ドコモに伝えて対策よろしくって済むんですが、
これ対策できないことに気づいたんですよ。
そこも気づいたんですね。
ですから、相当悩んだんですが、これは発表するしかないということで発表しましたね。
ですから一部、なんで徳丸はゼロデイの脆弱性を発表したんだみたいなことを言う人もいたようですが、
これはちゃんと分かっている人から見れば、これは各サイトで対策するしかないので発表するしかないということになりました。
特にそれで非難されたり訴えられたりはなかったんですが、結構ドキドキしますよね。
なるほど、ありがとうございます。
結構今もゼロデイ的なものの発表って結構されることはあると思っていて、
そこら辺ってなんでなんだろうなみたいなのは結構気になったところだったので、お話伺えてすごい面白かったです。
やはりこれはいずれは攻撃側も気づくわけでして、そうすると本当のゼロデイになっちゃう。
先に発表することで、攻撃者も気づくけども対策側も同時に対策できるということで、
どっちがいいかというとやっぱり発表するしかないかなと思いますね。
そうですね。後から気づくよりかは同時に気づいて、なんとかして攻撃者が攻撃してくる前に守るみたいな。
そのスタンスが大事ってことですね。
はい。
ありがとうございます。
今みたいな話じゃないんですけど、私のXのメッセージですね。
これこれのサイトに脆弱性見つけたんですけどどうしたらいいですか?みたいな相談がたまに来る。
年に何回か来るんですけど。
それはもうサイトに連絡するしかないんじゃない?みたいな感じですね。
あるいはIPA通して届出するかですね。
それに返すしかないんですけどね。
確かに。見つけちゃったら見つけちゃったでそれをどう伝えていくかすごい悩む気がします。みんな。
そうですね。私はもうサイトの脆弱性ってあんまり探してなくて、
それ見つけても届出とかすればいいんでしょうけど、
それよりは例えばオープンソースのソフトウェアで脆弱性を探すとかですね。
そっちの方がいいというかあまりドキドキしなくて済むというかですね。
そうですよね。下手になんとなく一周とか書いちゃうと逆に危ないとかある気がする。
本当にそうで、サイトの場合ですね。気をつけないと自分自身が法律違反を犯してしまう。
特に不正アクセス禁止がありますね。
違反、自分自身が犯罪者になってしまいますし、
現にだいぶ昔ですけど逮捕されちゃった人とかいますので。
そういう意味でもウェブサイトの脆弱性探すっていうのはやめたほうがいいというか。
バグバウンティーといっていや報奨金出しますってやってるところは割と安全なんですが、
そうでないところですね。
ちょっと気をつけたほうがいいと思いますね。
ありがとうございます。
結構ここらへんはあんまりずっとやることではない、慣れないところな気がするので、
とても参考になる気がします。ありがとうございます。
脆弱性の発表とセキュリティの重要性
ちょっと今のお話から続いてなんですけど、
今まで結構いろいろ攻撃の定石はいろいろ出てきてるよねみたいな話はある気がしているんですけど、
セキュリティのトレンドみたいなのって今ってあったりするんですかね。
もっかいろいろ生まれてきてるとか考えないといけない議題になってるものとか。
ウェブのセキュリティという点で言いますと、
攻撃側がどんどん先を行くなんて話は実はあんまりなくてですね。
作り方が変わっていくと。
新しい作り方にこういう脆弱性が考えられるよねみたいな話が多いんですね。
ですから今時も珍しくはないですが、
例えばシングルページアプリケーションというのが出てきたと。
そうすると表示系は全部JavaScriptでやりますよと。
サーバー側にはもうAPIしかないですよというふうになったときに、
実は基本は変わってないんですが、
やっぱりシングルページアプリケーション、SPAならではの脆弱性の入り方っていうのがあると。
あるいは従来はちゃんと作る側は気をつけていたところが、
作り方がちょっと変わったためにそこがチェックされないようになってしまうとかですね。
こういうことはあり得ますね。
なるほど。
最近だとまたそのWeb系、特にWeb系だけでもないと思うんですけど、
生成系AIから始まるAI新時代というか、
AIで生み出すところがシステムの一部にどんどん組み込まれていくみたいな時代になってきている気がするんですけど、
そこら辺のセキュリティの話みたいなのもあったりするんですか?
ありますね。
そうなんですね。
例えばコパイロットみたいなものでもう簡単な指示をすれば、
英語や日本語で指示をすればソースコードを書いてくれるみたいなのはもう常にどんどん使われ始めていますが、
じゃあそのコードが絶対安全なのかというと、実はそうではないですね。
これは米国ではそういう発表、ブラックハットという催しで発表されたりもしてますが、
例えばコパイロットで生成されたコードにSQLインジェクションが入るとかですね。
私自身もコパイロットではなくてChatGPTですが、
これは脆弱性が入るんじゃないかと思って、
こういうプログラムを作ってくださいと指示したら、ちゃんと脆弱性が入るとかですね。
そうなんですね。
例えば著作権大丈夫なのかとかですね。
秘密情報漏洩しないかとかそういう話もあるんですが、
一方で質という問題もあって、
今の生成AIというのは時々嘘をつきますが、
プログラムについてもそうで、
これが単なるバグでですね、ちゃんと動かないんじゃないかって言うんだったらテストでわかるんですけど、
脆弱性となると、
普通の正常系のテストでは気がつかずにですね、
そのままプロダクトになってしまうとかですね。
いうのはあり得ますね。
なるほど。
今のお話だと、
攻撃とか問題は見えているって状態な気がしていて、
そこに対して、
一応ソフトエンジニアとかプロダクトを作っている人間として、
どういう守りを作っていくといいのかみたいなところもお話としてはあったりするんですかね。
これは生成AIを使うからということではなくて、
鵜呑みにしないということが大事で、
これ自分が書いてもちゃんとセキュリティのチェックはしなければいけないのと、
同じことがAIで作ったコードでもあるということであって、
別に全然変わるということではないと思うんですが、
ちょっと任せっきりはだめよということだと思います。
銀の弾丸というか、
魔法のツール的にもそれを信じ込んで使っていくみたいなところは、
まずやめていこうねというところが大事みたいな感じですかね。
AI技術の進化とセキュリティ
そうですね。
これは実は今に始まったことではなくて、
例えばGitHubとか、
それこそKitaとかですね。
そのコード例が上がっていると。
それをコピピして使っちゃう。
著作権上の問題がありますが、
それも多くの人はあまり気にしないですね。
公開されているんだからいいでしょうみたいな感じで使っちゃうと。
でも実はバグがあるとか、脆弱性があるとか。
私、たまにさっき言ったこれこれする処理という話しましたけど、
その内容でGoogle検索とかしてですね。
見つけたサイトにやっぱり脆弱性があったと。
コメントで教えてあげたりするんですが、
反応がなかったりですね。
ちょっと残念な気持ちでありますが。
これはですから多分そういうコード、
実はAIが学習してしまっている可能性があるわけですね。
逆にってことですね。
AIが完全に何もないところからコードを書くというのは、
今は多分あまりできてなくて、
過去のそういう人間が書いたコードを学習した積み重ねが
ベースになっていることが多いと思うんですが、
そうすると中には脆弱性があるサンプルもあるわけですね。
そういうものを学んでしまうということは現状あるように思います。
次の未来のためにみたいなアクションで言うと、
自分自身がみんなが生み出しているコードみたいなところを
それぞれがちゃんと担保していくみたいな、
そういうことの意識とかは大事そうってことですね。
そうですね。
これ近未来に起こりそうな、起こるかもしれないこととして、
今のAIは既存のコードを学習して、
それを元に生成されていると思うんですが、
仮にですね、全部AIで作ればいいじゃんとなってですね、
そういうコードを例えば発表をみんながしないとなると、
一体何を学習するんだろうということになるとか、
あるいは、特に最先端のプログラム言語とかですね、
元ネタが最初はないわけですから、
セキュリティのリテラシーを上げるためには
最初は誰かがインターネット上などに公開しないといけませんので、
その辺のライフサイクルが今後変化しないかなというのは、
個人的には興味があるんですよね。
確かにそうですね。
かつやっぱりそこが変わってくると、
エンジニアたちが気にしないといけないこととか、
そういうところも変わってくる気がするので、
確かにそこは見えないけど考えていかないといけないってところですね。
考えてどうにかなる問題でもないんですが、
ウォッチはしていかないといけないかなと思いますね。
ありがとうございます。
今のお話の中にもあったと思うんですけど、
やっぱりセキュリティみたいなところって、
一人が意識を高めてても、
やっぱり組織とか、それぞれのコミュニティみたいな中で、
全体のセキュリティのリテラシーを上げていくのとはまた別の話がない気がしていて、
業界全体のリテラシーを上げていくためにやっていったほうがいいこととか、
本当にちっちゃい組織単位とかチーム単位でそういうのをやっていくときに、
やっていったほうがいいこととか、そういうのってあったりしますか。
これはですね、私の本業でもありますし、
セキュリティの本を書くとか、いろんな発信をするという主要な動機でもあるんですが、
それを20年とかやってきててですね、
希望もあれば諦めみたいなのもありまして、
なんやかんや言って、あんまり難しいことは伝わらないなという、諦めみたいなのがありますね。
ちょっと専門的な話になりますが、
SKLインジェクションとかコロッサイトスクリプティングの対策として、
エスケープ処理というのをやれということになっていたんですね。
例えば、SKLでしたらシングルコートがあったらそれを重ねなさいとかですね。
小なる記号はアンパさんとLTセミコロンに変換しなさいとかコロッサイトスクリプティングですが、
これ簡単なように見えてですね、いろいろ組み合わせでやっていくと結構複雑になる場合がありまして、
複雑になるとやっぱり人間間違えるんですよ。
昔はですね、これはもうあるルールで決まっていることなんだから、
学習さえすればみんなが分かるはずだ。
それを私は伝えたいと思っていたんですが、
ある時期からですね、これはやっぱり分からん人は多分一生分からんなと。
それはその人がサボってるとかそういうことではなくて、人間慣れしも得意不得意がある。
走るのが速い人もいれば遅い人もいると。
それと似たようなことで、じゃあもうエスケープとかもういいと。
しなくていいようにできたらいいなと思ってたら、実際そうなってきてるんですね。
今時もうエスケープ修了しなきゃいけないなんて局面はほとんどないわけですね。
ですから、難しいやつはダメってことですね。
実践するのに難解なものはもう、これはもうみんな分からないんだから、難解でない方法を用意するしかないと。
いうふうに思ってますね。
常識に訴える意識形成の重要性
あとですね、やっぱり気持ちってすごく大事だと思うんですね。
やっぱり人間はなんやかんやに言って感情で動きますから、脆弱性があるとこんな怖いことが起こるんだよっていうのは、
やっぱりちゃんと感じてもらわないと困るわけです。
それは恐怖のどん底に陥れてなんか変な壺みたいなの売るとかですね。
そういうんじゃなくてですね、正しく心配してもらうために、甘く見てちゃダメだよっていうのを感情にも訴えることが大切で、
そうするとモチベーションも湧いてくるということだと思います。
なるほど、ありがとうございます。
じゃあなんかまとめると、そもそもこうセキュリティみたいなところの難しいところは考えなくても安全な世界観をちゃんと作っていこうねって話と、
どっちかっていうと知識っていうより常理に訴えていくというか、
やっぱりそこの大事だよねっていうところ自体の意識形成をしていくみたいなところが大事って感じですね。
なるほど、ありがとうございます。
はい、徳丸さん今日はありがとうございました。
まだまだですね、お話ししたりないので、次回も徳丸さんとお送りします。
はい、今回はですね、徳丸さんにセキュリティについていろいろお伺いしてきました。
なんかやっぱり今まで漠然とセキュリティ大事だなみたいな気持ちはあったんですけど、
それがやっぱりなんで大事なのかとか、
どういう気持ちで向き合っていくのが大事なのかみたいなところを今回はいろいろ考えさせてもらえるいい機会になったなと思ってます。
はい、さてこの番組では感想や質問、リクエストなどお待ちしております。
番組詳細欄にあるリンクよりお気軽にご投稿ください。
Xではハッシュタグエンジニアストーリーをつけてポストしてください。
そしてApple PodcastやSpotifyのPodcastやレビューもできますので、
こちらにも感想を書いてもらえると嬉しいです。
Kiita株式会社はエンジニアを最高に幸せにするというミッションのもと、
エンジニアに関する知識を記録、共有するためのサービス、
Kiita、エンジニアと企業のマッチングサービス、KiitaJobs、
社内向け情報共有サービス、Kiitaチームを運営しています。
ぜひカタカナでKiitaと検索してチェックしてみてください。
お相手はKiitaプロダクトマネジャーの清野利文でした。
