00:00
今回はですね、結界っていうツールについてお話しできたらなと思うんですけど、 片吊さん、まず結界ってどういったツールですかね。
はい、結界もあの自分が作ったツールなんですけど、 ちょっと話すの長くなるんですけど、結構あの
念頭に置かれているのは、PHPのちょっと古いPHPのアプリケーションを主に想定していて、 PHP以外でもできるんですけど、
PHPって、ファイルをポンって置いたら動くじゃないですか、PHPって。 はい、スクリプトを置いたら。
スクリプトを置いたら動くじゃないですか。 なので結構例えばそのOSコマンドインジェクション脆弱性みたいなのがあって、
ファイルを書き換えられたりとか、あと新しいファイルを置かれるみたいな攻撃が結構やられてるんですよね。
なのでそのファイルが、想定外のファイルとかがあったら検知したいですね。
これって意外と面倒くさくて、 真面目にやろうとすると。
例えば、なんか簡単に、すごい簡単にやろうとすると、例えばTAで固めて、
そのTAのMD5とかシャーニボロとか、なんかその値を見て、ハッシュ値が変わってるか変わってないか、
みたいなのを見れば、一応なんか割と簡単にできるんですね。 なんですけど、じゃあこれの問題点って何かっていうと、
そのTAって、そのメタ情報も入っちゃうんで、例えばファイルをタッチしたりとか、
なんかファイルの更新とかになっちゃうと、中身は一緒でも微妙に変わっちゃったりするんですよ。
そうすると、ダメなんですよ。
MD5ハッシュ値変わっちゃうんですね、TAのファイルだと。 けど、それ以外に何かいい方法あるかっていうと、実はあんまりないですよね。
簡単にやる方法って。
で、結界は、そのファイルの中身のハッシュ値を一個一個見に行くっていう形です。
あ、もう一個あったな、TAの後もう一個あって、そのログとか、例えばどっかのディレクトリにログ入ってます、みたいな状況の時に、
そのログもTAしちゃうじゃないですか。 そうなっちゃうと、当然ログファイル入っちゃったら、
もうそんなTAのハッシュ値なんていくらでも変わっちゃうじゃないですか。
うん、確かに。
なので、なかなか構成にもよるんですけど、結構難しかったりするんですよね。
なので、そこどうしようかってところで、結界を作ったんですよね。
結界は、ファイル一個一個のファイルの中身のハッシュ値っていうのを見に行って、
そのファイルのハッシュ値変わってないかとか、想定外のファイルが入ってないかとか、そういうのを一個一個見に行くっていうのが結界っていうツールで、
イグノアの設定とかもできるんで、このログディレクトリみたいなのがあったら、このディレクトリは無視してくださいっていうのができるっていうツールになってますね。
じゃあすごいざっくり言うと、サーバー上で実行されているプログラムのファイル群の改ざん検知ツールみたいな感じなんですかね。
03:08
まさにそうですね。基本ソースコード改ざん検知ツールですね。
既存のやり方だと、さっき言っていたターだったりとか、何らかまとめてファイル群のハッシュを見ていかないと、なかなか難しかったところをファイルごとのハッシュ値で検証していって、
改ざんされてないかっていうところが検知できるっていうのが結界のいいところというか、便利なところっていう感じですかね。すごいざっくり言うと。
それをシェルスクリートとかでも頑張ればできると思うんですけど、すごい大変だと思うんですよね。
そういうのがサクッとできるっていうのが結界の良さなのと、あと結構実際にこれデプロイしてるんですよ結界。
なので実際のデプロイも結構考慮した構成になっていて、これ一個一個話していくと、まずそのファイルのハッシュ値、このファイルのハッシュ値の情報ってどっかに保存しないと動かないじゃないですか、結界が。
保存するというのは、今の正常な状態でのハッシュ値。
そうです、正常なファイルのハッシュ値。
ステータスをどこかに保存しておかないといけないという。
どっかに保存しておかないとわかんないじゃないですか、検証できない。
単純に何らかのデータベースか、どっかに記録しておかないと差分がわかんないですよね。
差分がわからないんですよ、どっかに置かないといけないんですけど、じゃあそのサーバー上に例えばファイルとしてポンって置いておく、そういう機能もあるんですけど結界には。
サーバーにポンってファイルとして置いておくでもいいかもしれないんですけど、それだとサーバーに侵入されたときにそのファイルごと改ざんされるって可能性があり得るじゃないですか。
まあそうですね。
なのでこれだと不完全なんですよね。
なのでそのデプロイサーバー上で書き込めるけど、そのアプリケーションサーバー上では読み込みしかできないみたいなデータベースがあったら一番便利なんですよね。
デプロイサーバー上では書き込めるけどアプリケーションサーバー上では書き込めない。
データベースがもしあったらめっちゃいいじゃないですか、結果にとって。
ビルドしたときに書き込むデータベースみたいな感じですよね、イメージ的に。
そうですね。
そんなことできるかっていうと、AWSのEC2だとIAMでこのS3に対して権限付けられるんですよね。このS3に書き込みできる権限とか読み込みできる権限とか付けられるんじゃないですか、IAMを使えば。
細かく設定ができるってことですよね、IAMロールで。
なのでデプロイサーバーでIAMロールでそのS3のライトとリードを与えて、アプリケーションサーバー上はIAMのリードしか与えないっていう形にすれば、S3でそういう簡易的なデータベース。
06:03
デプロイサーバー上では書き込みできるけど、アプリケーションサーバー上では読み込みしかできないっていうデータベースを用意することっていうのが比較的簡単にできるんですね。
で、結界はそれを結構想定した作りになっていて。
そういった開発フローを想定して作っているってことですかね。
ファイルで保存する機能もあるんですけど、本番で使う場合はS3を使うことを想定して作られていて、
今言ったデプロイサーバー上でS3に対して書き込んで、アプリケーションサーバー上では検証するっていうのを想定した作りになっています。
なので、AWS SDKも内部で組み込んでいるので、その辺の設定もすごく簡単に、IAMロールさえ設定すれば結構簡単にできるように。
ちょっと分かってないのが、この結界、どちらかというとエージェントみたいな動きなのかなと思うんですけど、
よくあるニューレリックとか、ああいうメトリックス系のツールとかってエージェントインストールするじゃないですか、アプリケーションサーバーだったりとかに、
そんな感じで入れるイメージですかね、結界も。デプロイサーバーにエージェントとして入れてとか。
エージェントでも、実装しようと思えばエージェントでも作れるんですけど、
エージェントだと、そのエージェント自体がメモリリークしたりとかしたときに、サーバー全体が死んだりとかしかねないんですね。
なので、CLIツールとして作っていて、コマンドが2つあって、結界ジェネレートと結界ベリファイの2つあります。
なるほど。
デプロイサーバーで結界ジェネレートして、アプリケーションサーバーで結界ベリファイするっていう想定で作っていて、
デプロイスクリプトの中で結界ジェネレート、例えばPHPだったらコンポーザインストールみたいな処理が終わってから結界ジェネレートして、
それをS3に保存してもらうと。
で、その後にアプリケーションサーバー上で結界ベリファイするっていうのを取っていっても。
ちょっといいですかね。ジェネレートするタイミングは、デプロイするタイミング、デプロイの実行のアプリケーションサーバーが立ち上がる1個手前ってことですよね。
本当に直前みたいなイメージですね。
そうですね。
アプリケーションサーバー上に置くファイルができたタイミングで結界ジェネレートするっていう想定です。
理解です。
で、クーロンで実行してもいいし、それこそニューリリックみたいなエージェントで定期的に叩かせてでもいいし、
失敗したらエクジットステータスが非ゼロ、ゼロじゃないやつ返ってくるので、ゼロじゃないやつが返ってきたら何か異常ですよっていうのをアラートならせると。
じゃあこのアプリケーションサーバーで的実行されてるVerifyに関しては監視みたいな役割ってことですね。
09:04
そうですね。さっきのターのやつでもう1個問題があって、ターだと発射値が違うよって情報が出るんだけど、このファイルが違うよとかそういう情報で出せないんですよね。
例えばこのファイルが改造されてるよとか、このファイル追加されてるよとかそういう情報ってターだと出せないじゃないですか。
結果だと失敗した時にこのファイルがおかしい、変更されてるよとか、このファイルが追加されてるよとかそういうのがちゃんと出てくるので、
そのエラージュのログ出力をどっかに通知していれば明確何が起こったのかがすぐ分かるようになってます。
そのVerifyで発射値が違くなってるので、その後そのファイル実ファイル見てリフとかも見れるってことですよね。
実は今出してないんですけど、作れば出せるかな。
一応出力、JSONで返すやつと普通のテキスト返すやつオプションで変えられるようになっているので、
そういうことやりたい場合はJSONで出力して、それ情報を取ってきてもらってやる感じになるかなと思いますね。
EC2上で大体の、想定してたのがEC2上、AWS上で使うっていうような想定だったので、
大体はクラウドウォッチログ数とかでこのVerifyのログを監視して、
イベントのトラックとかをしてスラックに通知するみたいな、いうような想定なんですかね。
そこはあんまり結界側では規定してなくて、
自分が今見ているとこだとMACARELっていうサービスを使うと、
定期的にシェルスクリプトみたいなのを実行できて、
それで何か非ゼロが返ってきたらスラックに通知するみたいなのが結構簡単に設定できるので、
今のところ自分はMACAREL使ってやってるんですけど、
別にMACAREL以外でも定期的に実行してそれを通知するっていうのが何かでできれば大丈夫って感じですね。
ラムダとかでもいい、ラムダは無理か、EC2上で走っていかないといけないから、なるほど。
アプリケーションサーバーと同じインスタンス上で走らせられれば何でもいいよって。
何でも。これをシェルスクリプトで書けば何でもできるかなって感じですね。
ちなみに実際の具体的な例みたいなお話で、
なかなかアプリケーションのファイル自体を書き換えられた例っていうのが自分自身はあんまないんですけど、
書き換えられてたらかなり大変なことなので、セキュリティ的にあんまないんですけど、
具体例っていうか片杖さんが遭遇した事例みたいなのってあったりします?
自分が遭遇したというよりも、世間一般的な流れに沿ってるんですね。
クレジットカード決済とかの最近の攻撃って基本的に全部ファイルを改ざんされて、
そのクレジットカード決済、クレジットカードの番号を打ったら全然違うところのサーバーにその情報が送られるように改ざんされてるってケースが
12:04
基本ほぼ全部、僕が知る限りここ数年のやつ全部そうなんですよね。
そんな感じになってるんですよね。あれって基本的にクレジットカード番号をサーバー経由してはいけないみたいな感じに今なってるかなと思うんですけど。
そうですね。カード番号非通過化っていうのが現在どこも実装されてる。
実装しないと違反になっちゃう。PCI DSS違反になっちゃうので、今どこのサービスもクレジットカード番号っていうのは非通過化されてて、
そのサーバーに収入されても来ないんですよ。なのでその意図的にサーバー改ざんして、ソースコード改ざんして、
全然違うことをカード番号打ったら自分なんか全然違うところに送るようなプログラムに改ざんする。
そうしないとカード番号って奪えなくなってるんですよね、今って。
フロント側のコードを変えないとっていうことですかね。
JavaScriptで変なところにAPIリクエストみたいなの投げないといけないってことですよね。
そうですね。
ダッシュするにはクレジットカードの番号。
そうです。
今回のこの結界の場合だと、そこのJavaScriptを配信してるJavaScriptのハッシュ値が変わっていたらそれが検知できるってところなんですかね。
JavaScriptをもしそのサーバー上で配信してたらもちろん見れる感じですね。
想定通してはどんな感じなんですかね、さっきクレジットカードの。
要はクレジットカードの番号の場合はHTMLが書き換えられてるので、そういうサーバーでHTMLを変えしてるんだったらそのPHPのソースコード絶対改ざんしてるはず。
なるほど。
そこを見てるって感じですね。
サーバー側でレンダリングされるHTMLが改ざんされてるからっていうことですね。
そうですね。
理解しました。
そういったところがこの結界使えば早期に発見ができるってことですよね。
そうですね。
事前な防御ではないけども、なるだけ早くってことですよね。
気づける、何かあったときに。
確かに。
他のユースケースとかってあったりするんですかね。他にもしあったらなんですけど。
それは正直分かんないですよね。正直それを目的で作ったものなので、基本的にそれ以外の用途はないと思うんですけど。
何でか分かんないんですけど、ホームブリューでインストールできるんですよね。
ブリューインストール結界ってやったらインストールできるようになってて。
これ僕は一切関わってなくて、自分も気づいたら何か追加されてるってなったんですけど。
なのでMac上で使いたいのか、それとももしかしたらその人はLinux、ホームブリューってLinuxでも使えるので、
Linux上でブリューインストール結界したくて使ってるのかもしれないんですけど、ちょっと分かんないですね。その人が何をしたかったのか。
確かにホームブリューでインストールするって言ったら、大体Macかなとは思うんですけどね。
確かに何か謎というか不思議ですよね。ホームブリューで公開される。
15:00
しかも片辻さんがリリース作業したわけではないんですよね。
本当に全然知らない人がプリクを送っててマージされてるのを結構後で知ってていう感じですね。
そういうこともあるんだみたいな感じです。完全にOSSって。
多分ブリューインストールで入る自分のツール結界しかないので、何で結界だけ入ってるのかよく分かんないんですけど。
なるほど。ちなみにさっきのアーキテクチャ的な話聞いてて思ったのがGitっぽいなと思ったんですよ。
Gitも全てのファイルのハッシュ保存して、それが変わってたら作文検知するみたいな。
すごいざっくりとそんな感じなのかなと思ってるんですけど。そこら辺イメージしてたりするんですか?
そこら辺作るときにイメージはしてないんですけど、ただ意識したのはGitignoreと共有はしないっていう想定になってて。
でもGitignoreって例えばドットエンブファイルとか、設定を置くようなファイルとかそういうのも無視するじゃないですか。
けどそういうのも改ざんされたら困るじゃないですか。
ドットエンブとか改ざんされたら困りますもんね。
まずいじゃないですか。
一番。
まずいので、だからドットギットイグノアを使い回さないっていうのは意識したんですよね。
じゃあイグノアの設定どうするのかっていうと、ここも結構ちょっと強弁になっていて、
結界ベリファイの方、アプリケーションサーバー上でイグノア対象を増やせちゃったら、
そのイグノアのところに対して改ざんすればいいってなっちゃうじゃないですか。
確かに。
なので、ベリファイの段階ではイグノアできなくされてて、
結界ジェネレーターのタイミングでイグノアを指定して、
その設定ファイルにマニフェストファイルって呼んでるんですけど、
そのマニフェストファイルの中にどこをイグノアするのかって情報が入ってて、
結界ベリファイはそこしかイグノアしてくれないんですよね。
後から増やすなりですよね。
そのイグノア対象はドットギットを使わないように。
例えばドットギット、ギットイグノアって、
あと例えばコンポーザインストールとかジェムインストールとか、
そういうのしたときに手元にディレクトリ作られてソースコード入ってくるじゃないですか。
そこも結構ギットイグノア普通するじゃないですか。
けどそこも改ざんされたらやばいじゃないですか。
そこ改ざんされたら全部書けられちゃうから、
だからそこも結界のリードミーにちゃんと書いてるんですよね。
そこ絶対イグノアしないでくださいって書いてるんですけど、
なんでその結界がイグノアしたいファイルと、
ギットイグノアしたいファイルって根本的に違うんですよね。
だからギットイグノアは見ないっていうのは、
作るときに意識したところですかね。
18:01
そのギットイグノアを見ないというところはギットから、
てか大体のプロジェクトでギットイグノアが設定されてるから、
逆説的にそこを意識したっていうところがあるのかなとは思うんですけど、
そのギットのアーキテクチャのファイルの発祥を見るみたいないうところは、
別にギットを意識したわけではないっていうところですかね。
ではないですかね。
単純に。
ギットって今シャー1ニッパー確か使ってるんじゃないかな。
シャー1ニッパーって確か衝突が今だとできるんですよね。
この結界って性質上衝突させられたら困るんですよね。
1個ずつ違うやつじゃないといけない。
結構ここも迷ったんですけど、
例えば軽量な発祥を使うのか、それともちゃんとセキュリティ的に
衝突させるのが難しい発祥関数を使うのかっていうのを迷ったんですけど、
やっぱり結界ちゃんとしたソフトウェアにしたかったので、
ここはシャー2ゴローを今使っていて、
衝突させるのが難しい発祥関数を使って実装されてるっていうのが今の結界ですね。
ほぼほぼ衝突はしないだろうという。
そうですね。ギットは衝突させられるはずなんですよね、今って。
なんでそこは逆に意識しなかったというかって感じですかね。
そこは真似してないですね。
なるほど、ちゃんと目的ありきで設計したっていう感じですね。
これ結界側が書き換えられるってことあるんですかね、ちょっと試行実験みたいな感じなんですけど。
結界のバイナリーが書き換えられる可能性はあるんですけど、
ただそこは各自で頑張ってほしいなと思ってて、
ルートユーザーで書き込みしかできない、
例えば、ユーザーローカルBに結界っていうファイルを置いて、
その時に置くときにルートユーザーでしか書き込みできないっていうふうに設定してほしくて、
そうすればルートをダッシュしない限り書き換えられないはずなんで、
ルートダッシュされたらもう結界どころの騒ぎではないっていう話にはなるので、
そこはちょっと結界では防げないですね。
他のところでカバーしてくれっていうところですね、やっぱりセキュリティとして。
ダッシュされたとしても、ルートユーザー奪われないようにしてほしいってところですね。
普通の話な気がしますね、どちらかというと。
ちなみにこれ今EC2の話、EC2インスタンス上での使われ方的な話してたんですけど、
Dockerとかの場合どうなるんですかね、ECSとか。
そもそもDockerだと、これも設定によるんですけど、
比較的簡単な設定で、そもそもファイルを書き換えられなくできるんですよね。
そうなんですね、Dockerって。
Dockerって結構簡単にできます。なので、そもそもいらないんですよ、結界が。
21:01
じゃあDockerを使っていないEC2インスタンスだと、
そういうVPSみたいなところで使われる想定っていうのが、かなり割り切りとしてあるって感じですね。
割り切りとして、ECSみたいなDockerコンテナのやつだと根本的に必要ないんですよ。
けど、世の中そんなサービスばっかりじゃないと思うんですよね。
やっぱりEC2とかVPSとかで動いてるサービスって多いと思っていて、
そういうところで、けどファイル最低限守りたいよねっていうのって言ってあると思うんですよ。
けど、やっぱり今ってみんな新規だとDockerだから、正直こういうツールってないんですよ。
自分ずっとこういうツールあったらいいなってずっと思ってたのに、なくてずっと。
それはやっぱりDockerコンテナにしてたら関係ないからってのが大きいと思うんですよね。
根本からできないようになってるからね。
根本的にできないから。
なんとなく片杉さんがレガシーな環境というか、
そういったところとずっと戦ってきているからこそ、
こういう需要というか、こういう本当に必要なものが出てくるっていうような感じなんですかね。
そうですね。やっぱりレガシーな環境でも、やっぱりビジネスとして成り立ってるんだったらちゃんと守らないといけないので、
そういったところ、Dockerコンテナに行けばいいっていうのはあるかもしれないんですけど、
そんなすぐに行ける構成じゃなかったりするので、だからこういうツールあったらいいんじゃないかなと思って作ったし、
実際作ったとき、これ自分はずっと欲しいなって何年前からずっと欲しいなって思ってたんだけど、
欲しい人自分以外にいるのかなって疑問だったんですけど、
意外とGitHubスター100以上集まったんで、やっぱり需要あるところにあると思うんですよね。
なのでやっぱり需要あるんじゃないですかね、ヘッドは思ってますね。
もしかしたら片杉さんが思っている使われ方じゃない使い方されてる可能性もありますもんね。
可能性はあるかもしれないですけど、自分はちょっと思いつかないですね。
もしそういうユースケースがあったら、マジで教えてほしいぐらいですよね。
教えてほしいですね。
全然違うところがあったら。
ちなみにこの結界は全部Goで書かれてるんですか。
全部Goで書かれてます。
あとなんかプロダクションでこれ使ってるようなところとかって、片杉さん観測してたりするんですかね。
自分の、そもそも自分の会社で使うために作ったんで、自分の会社今本番投入してますと。
それはブログとか書いてますと。
自分の会社以外では今のとこ聞いてはないですね。
そういう実例ちょっと欲しいですね、声としてね。
そうですね。
プロダクションで使ってますけどね。
そこそこついたので、本番で使ってる人いたら教えてほしいなとは思ってますね。
24:01
あとですね、名前ですかね。結界ってめちゃくちゃ日本語名かなと思うんですけど、なんで結界にしたんですか。
ソフトウェアで日本語由来の名前のソフトウェア作るのちょっと憧れてたんで、これ作るにあたってなんか日本語名のやつ作りたいなと思って。
自分神社とかそういうの好きなんで、なんかそういう神社っぽいやつでソースコード守れるみたいな、そういうバリア的な何かないかなと思って、
ChatGPTとかと相談して、じゃあ結界がいいんじゃないかと。
結界だったら日本人じゃない人でも発音割としやすいので、結界がいいんじゃないかと思って名前つけたんですけど、
結構気に入ってて、なんか結界ジェネレートしてから結界ベリファイするのめちゃくちゃウケるんですよね、個人的に。
確かになんか領域展開をしてみたいな、そんな感じがする。
結界ジェネレートしたわーみたいな、今結界ベリファイしてるわーみたいな。
確かに、なんかあってますね、イメージ的に。
そう、名前ピッタシーだから結構気に入ってます。
フィルターというかなんていうか、守る壁を作ってみたいな。
バリアーって書いてあるはず。
バリアーか、確かにバリアーだ、英語で言うと。
なんか日本語名のOSSで言うと、有名なの雷とか、あと他何ありますかね。
今パッと思いついたのが雷ぐらいしかなかったんですけど。
なんかちょいちょいありますよ、日本人が作ってるやつでも。
日本人以外が作ってるやつでもあったりするし、結構なんかGoogleが日本語名つけるの好きらしくて。
そうなんですかね。
だいたい日本語由来なんですよね、Googleって。
そんなイメージが特になかった。
じゃあちょっと調べてみると日本語由来の。
そう結構ありますね。
なるほど、いいですね。
確かに日本語由来のそういうOSSのツール名つけるの、憧れありがちだと思いますね。
多分日本人のエンジニアだったら大体納得していただけるんじゃないかなと思うんですけど。
そうですね、意外と日本人以外でも日本語由来のやつ作ってること結構あるんで、結構日本語はそういうのに便利ですよ。
なんか海外の人、日本語のカタカナ大好きみたいなところありがちだと思うんで、そういうことなのかもしれないですね。
ちょっと話し変えて、さっきから言っていたGitHubスター100越えみたいなところのお話聞きたいなと思うんですけど、
結構100ってついた方かなと思うんですけど、これもまたハッカニュースとかに投稿とかしてるんですかね、結果について。
そうですね、ハッカニュースに投稿してますね。
やっぱりGitHubでリードミーも英語にした上で、ハッカニュース投稿して、ちゃんと海外の人にもスターつけてほしいなと思ってますね。
27:06
やっぱりハッカニュース投稿するとGitHubスター付けやすくなるみたいな感じがありそうですね。
それもやっぱり全然無封ってことも全然あったので、刺さるかどうかは結構賭けですね。
でも出しておくことに越したことはないかなみたいな感じで。
出すのは無料なんで、出した方がいいと思いますね。
出さないよりかは出した方がいいって感じ。
それは絶対そう思いますね。
あとリードミー見るとGMO OSSセキュリティプログラムみたいなバッジが付いてるかなと思うんですけど、これはGMOが提供している匠っていうサービスの何かなんですかね。
そうですね。GMOグループのフラットセキュリティさんっていうセキュリティ会社があって、そこで匠っていうAIを使ってセキュリティ診断とか色々できるっていうサービスがあって、
匠は基本的には月数万とかかかるサービスなんですけど、
OSSの開発エンジニアに関しては、確か3ヶ月だったかな。だけ無料で使えるっていうプログラムがあって、
それを使って、無料で匠使って、結界の問題点を見つけてもらって実際に修正したっていうのがあったので、それで使ったって感じですね。
基本的にこの匠はコードスキャンみたいな感じですかね、セキュリティの。
コードスキャンもGitHubのエポを指定して、コードスキャンみたいなのもできるし、あと普通に相談。
セキュリティの相談とかもできるし、セキュリティに関しては結構色々できる感じですね。
相談もできるんですか。それはAIに対して相談ができるみたいな。
そうですね。直接相談できますね。
このソースコードのセキュリティのコンテキストとしてはソースコードが分かってる前提で、みたいな感じなんですかね。
この仕様どうですかって相談もできるし、レポ見てもらって、この実装大丈夫ですかとかできるし、セキュリティ的に問題ないですかとかもできるし、結構色々できますね。
便利そう。使ってみてどうでした。結構見つかったんですかね、セキュリティイッシュというか問題点。
いくつか見つかっていて、結界に関しては保存のパスに特殊な文字を渡せてしまう問題とか、
あとこれ結構なるほどなってなったんですけど、キャッシュファイル、キャッシュにも対応してるんですけど、
その2回目以降の実行を早くするためにキャッシュも使えるようになってるんですけど、キャッシュファイルを作成するときに結構適当な実装になってて、
30:02
ファイル名.tmpっていうファイルを作って、書き込んだらリネームして作るっていう実装だったんですけど、
これだと結界ベリパイを複数同時に実行してしまったらお互い食い合っちゃうっていう指摘がきて、確かになと思ったんで、
ここは複数プロセス起動してもレースコンディションみたいなのが起こらないようにするっていうのを変更入れたりとか、
あとワークワーズっていうので、何並列でこれ計算するかっていうのを指定できるようにしてたんですけど、
ワークワーズを例えば100とか1000とか適当な数字渡せてたんで、そうしちゃうとDDoSみたいなのが自分でDDoSみたいにできちゃうよねみたいなものとか、
あとこのcache.dirっていうキャッシュのファイルを置く場所を指定できるようにしてたんですけど、それ存在しないところも受け付けられるよねとか、
そういうのがいろいろ教えてもらいましたね。
なんか聞いてる限りセキュリティというよりかはコードレビューみたいなことして指摘してもらってたみたいな感じなんですかね。
そうですね、結果的には。
セキュリティ的に致命的な問題が見つからなかったので、そういう問題を教えてくれたっていう形ですかね。
特になのがセキュリティって感じですね。
特化してるのはセキュリティだけども、他のところも見れるよねみたいな感じのツールなんですね。
ちなみにここいけてないなというか、使ってて微妙だなと思ったところとかあったりしました。
そうですね、Webアプリのセキュリティ診断が最年頭に置かれてるんで、結果みたいなCLIツールで使うと微妙だったりして、
例えばユーザーの入力をもっと制限しなさいとか結構言われて、
CLIツールでユーザーの入力制限しちゃダメでしょみたいな。
Webアプリケーションだったらわかるけど、CLIツールはダメでしょみたいなのとか、そういう指摘もいくつかあったので、
そこは微妙だなーっていうのありましたけど、セキュリティについて相談するんだったらだいぶやりやすいなと思いましたね。
同じ入力って言ってもコンテキスト違うよねってことですよね。
ブラウザから一般ユーザーが入力するテキストと、CLIツールみたいにオプションで渡して開発者が使うようなものと、
全然性質違うよねっていうところがコンテキストとしてちょっと抜かれてしまっていたっていうところなんですね。
そこはなかったですね、そこのコンテキストは。
まあそうだよねって感じがしますね、それに関しては。
一番最初のポイントとしてウェブアプリが念頭に置かれてるっていうのは、そりゃそうだよなーって感じがするんで、
最初からCLIツールにちゃんと対応してますって感じはあんま思い浮かばないんでね。
33:01
実務だとウェブアプリケーションの方が嬉しいと思うので、全然そこはそうだよなーって感じでしたね。
納得って感じ?
納得ですね。
匠に関しては今後も使っていきたいとか、ちょっとおすすめみたいな感じあったりします?
OSSのやつは自分はもう終わっちゃってるんで、今使えないんですけど、
OSS使ってる人は無料なんで、とりあえず申し込んでみたらいいんじゃないかなと思ってますし、
仕事でももし興味があれば全然使ったら便利なんじゃないかなと思ってますね。
ありがとうございます。
じゃあちょっといい感じの時間なんで、今回はここまでにしたいかなと思うんですけど、
最後に片杉さん、この結界、自分で作ったツール、結界、何か言いたいことあります?
結構ゴー的にも面白かったなーっていうのが結構あって、
例えばレートリミットの機能があって、
自分が今まで作ったゴーのプログラムって平行プログラミングして、
全力でリソース使い切るみたいな書き方することが多かったんですよね。
それでCPUのコア全部使い切れるようにコード書くとかが多かったんですけど、
結界って、結界ベリファイ、特に結界ベリファイの方でリソース使い果たしちゃうとやばいんですよ。
そのウェブアプリケーションが動いてるから。
そうですね。CPU一緒ですもんね。
そう、CPU一緒だから使い果たしちゃうとまずいんですよね。
なのでレートリミットを設定できるようになってて、
そのIo自体を遅くすることができるんですよね。
ファイルの読み込み速度っていうのを遅くすることができて、
これって今まで自分が書いたコードって基本的に全力で処理することしか考えたことなかったから、
レートリミットでファイルIoをわざと遅くゆっくり読み込むみたいな、
そんなプログラム普段書かなかったから、
結果実際作って動かしてみて、
最初できたできたと思ったんですけど、
実際動かしてみるとCPU全部使い果たしちゃうじゃんみたいな。
確かに。
意外と重いんですよ、シャーニゴルのハッシュストル処理って。
だから全力出しちゃうと普通にCPU使い切っちゃうんですよね。
それだと困るからゆっくり、Go側のアプリケーションでゆっくりやるっていうのが、
実はGoの公式のライブラリーで、
標準ライブラリーじゃないんですけど、
公式のライブラリーでレートリミット入れられるやつがあるんですよ。
それを使うとIoゆっくりできるから、
そういうことやったりとか、
Goの今まで自分が使ったことない仕組みとかもいろいろ使えたんで、
結構作るの楽しかったなと思ってますし、
あとこれ、実は結構クロードコードとかをガッツリ使ったやつなんですよ。
やっぱりこういう、今までこういうのあったらいいのになみたいなのをずっと思ってたんですよ。
何年前からずっと思ってたんですけど、
36:01
けど実際作るの結構めんどくさいんだよなと思ってたけど、
クロードコードとかに言えば実際出てくるなって、
実際出てきたやつ動かしたらリソース使い果たしちゃうなとか、
そういう今まで考えたこともなかったような問題がいくつも見つかって、
すごい勉強に自分もなったので、
結構楽しかったし、結構便利だと思うので、
本当に特定の環境においては、
PHP以外の環境でもやっぱRuby on Railsとか、
昔からやってるRuby on Railsとか、
そういう環境ってあると思うんですよね。
EC2でファイル置いてみたいな環境って。
そういうところだとかなり有用だと思うんで、
ぜひそういうハマる会社さんは使ってほしいなとは思ってますね。
ありがとうございます。
では今回はここまでにしたいなと思います。
ヤオヤロズのOSSでは毎回一つのOSSを取り上げて、
一つではないかもしれないんですけど、
その時々のOSSを取り上げて、
それについて渡辻さんとヘンテコで
技術的なところも深掘りしながら話をしていく番組です。
今後もその名の通りヤオヤロズのOSSを取り上げていきたいなと思ってますので、
ぜひ機能プラットフォームでフォローと高評価のほうをお願いします。
またこのOSSについても取り上げてほしいなどありましたら、
コメントやXなどで教えていただけると嬉しいです。
番組についての感想もお待ちしております。
Xなのでつぶやく際にはハッシュタグヤオヤロズのOSS、
漢字でヤオヤロズですね、をつけてください。
それでは今回もありがとうございました。
ありがとうございました。