00:00
はい、じゃあこれからね、あのポッドキャストやっていくので、よろしくお願いします。
もちろん、こちらこそよろしくお願いします。
では早速行きましょう。
kekkaiの機能と利点
kekkaiがどんなツールなのか、簡単にお話しいただければと思います。
そうですね、一言で言うと、ファイル改ざん検知ツールになります。
ファイルの発出地を保存しておいて、そのファイルが改ざんされているということがわかったら、アラートするようなツールになっています。
なるほど、ファイルの発出地を保存しておいて、改ざんがあればアラートを出してくれるということですね。
それは面白いですね。
じゃあ例えばなんですけど、現場で実際にどんな場面でこのkekkaiが役立ちそうか、もう少し教えてもらえますか。
そうですね、例えば一番わかりやすいのはOSコマンドインジェクション脆弱性だと思うんですけど、
PHPとかそういうファイルが書き換わったら、すぐにレスポンスに影響してしまうような言語の場合、
OSコマンドインジェクション脆弱性で自分自身のPHPファイルを書き換えてっていうことをやられると、
変なことをやられてしまうじゃないですか。
でもそれってPHPファイルが大量にあると気づきようがないんですよね、改ざんされていても。
それがそのkekkaiを使うことによって簡単に検知することができるというふうになります。
なるほど、つまりOSコマンドインジェクションみたいな脆弱性でファイルが書き換えられても、
けっかいがあればすぐ気づけるってことですね。
それは現場で安心感がありますね。
AWS環境での運用技術
他のツールと比べてけっかいならではの特徴って何かありますか?
そうですね、基本的にはAWSのEC2上で使うことが想定されています。
これなんでEC2かっていうと、EC2ってIAMの機能が結構使いやすくて、
S3の権限っていうのが簡単に調整できます。
実際にデプロイサーバー上では書き込み、
アプリケーションサーバー上では読み込みだけができるS3っていうのが簡単に用意できるんですね、
AWSのEC2のIAMを使うと。
それを利用してデプロイサーバー上でしか書き込みができないっていう領域を作っておくと、
例えばファイルのハッシュ値を誰でも書き換えられるところに置いておくと、
アプリケーションサーバー上に侵入されたときに、
そのファイルを書き換えられたら分からないじゃんっていう話になってしまうので、
そうならないようにS3上にデプロイサーバー上でファイルを置いておいて、
アプリケーションサーバー上からそれは読みに行くだけっていう風になっています。
なるほど、つまりAWSのEC2とIAMを活用して、
デプロイサーバーだけがハッシュ値を書き込める領域をS3上に用意しておくわけですね。
アプリケーションサーバーはそのS3から読み込むだけにすればセキュリティが保たれると、
それは確かに合理的ですね。
今後、結界に追加していく予定の機能や展望みたいなものはありますか?
そうですね、特に機能追加っていうのは予定していなくて、
というのもやっぱりセキュリティに関わるツールなので、
そんなに頻繁に変更があってもあまり意味ないかなと思っていて、
Goのバージョンアップとかは対応していくつもりなんですけれども。
なるほど、セキュリティツールですから、
頻繁に機能を変えるよりも安定性を重視しているわけですね。
Goのバージョンアップ対応をしていくということで、
基本的には安定運用を大事にするという感じですね。
では最後に今日のまとめとして、
結界の特徴を簡単におさらえると、
ファイル改ざんをシンプルかつ確実に検知できるツールで、
AWS環境での運用に突破しているということですね。
今日はお話ありがとうございました。
まだ終わらせないでほしいんですけど、
これ結構難しいんですよ。
なので技術的な詳細についていろいろ話したいので、
ちょっとその辺深掘っていければと思っています。
もちろん、まだまだ続けましょう。
じゃあもう少し技術的な細かいところを、
ぜひ深掘りしていきましょうか。
例えば具体的な実装の工夫や、
どんなライブラリを使っているか、
あるいはパフォーマンス面で気をつけていることなんかを、
ぜひ聞かせてください。
そうですね、ライブラリは極力使いたくなかったんですけど、
やっぱりAWSなんで、
AWS SDK Goにはどうしても依存してます。
これのせいでちょっとバイナリーが重たくなっているっていうのはあるんですけど、
これについては言って仕方ない部分もあるので、
ここはちょっと今諦めてますね。
ただそれ以外のライブラリはあまり、
純公式ライブラリとかの依存はあるんですけど、
極力依存は減らしてます。
意外と大変だったのが、
レートリミットの部分で、
Goってやっぱりデフォルトだと全力出しちゃうので、
ファイルのハッシュ値を求める計算って結構CPU使うんですよね。
なので全力出されちゃうと、
アプリケーションサーバー上でCPUを一気にガッて使ってしまう、
っていう問題があったので、
アプリケーションサーバー上、
一応デプロイストサーバーというか、
マニフェストファイル作るときと読み込むとき、
どっちでも使えるんですけど、
レートリミットの機能がありまして、
レートリミットでIOの制限ができます。
なのでレートリミット制限しておくと、
ファイルを少しずつしか読み込めなくなるので、
必然的にCPU使用率も優しくなるというふうになっています。
なので実際に運用するってなると、
そういった機能が必要になるので、
そういうところの調整がちょっと面倒でしたね。
なるほど。
AWSのSDKにはどうしても依存しちゃうから、
バイナリが重くなるけど、
そこは割り切ってるんですね。
それ以外は依存を減らしてるということで、
やっぱりシンプルさと安定性を重視してる感じですね。
あとレートリミットの工夫は面白いですね。
GOだとゲフォルで全力でCPU使っちゃうから、
あえてレートリミットをかけて、
CPUの使用率を抑えるっていうのは、
確かに運用上大事なポイントですね。
そのあたりの調整が大変だったということで、
すごくよくわかりました。
では最後に今日お話しいただいたことをまとめると、
結界はAWS環境で安定的に動作するように設計されていて、
セキュリティツールとして必要最低限の依存率を踏めつつ、
結界の機能と工夫
レートリミットなどの工夫で負荷をコントロールしているといったところでしょうか。
まだまだお話は尽きないと思うので、
ぜひまたいろいろ聞かせてください。
そうですね、まだ終わらせないでほしいんですけど。
ちょっと機能として、
これだけだとCPUずっと使っちゃうの変わらないんで、
ちょっとキャッシュについても追加してます。
キャッシュは攻撃される可能性もゼロではないので、
キャッシュについてはデフォルトだと、
キャッシュが使える場合でも10%の確率で発射を求めるようになってます。
なのでちょっとキャッシュを使うと、
ハッシュ計算を少しスキップするっていうような想定で作ってます。
そのキャッシュってどういう前提でやってるかっていうと、
ファイルのCタイムでやっています。
ファイルのCタイムってこれチェンジタイムなので、
ファイルが変更されたら必ず変わるんですね。
これはLinux kernelのバグとかつかない限り、
多分回避する方法はないと思います。
なのでそのファイルのCタイムを見て、
Cタイムが変わってなかったら改ざんされてないでしょうというふうな判定を入れて、
ちょっとだけこれはデフォルト無効なんで、
オプション渡さないといけないんですけど、
キャッシュを使うことによって少しですね、
発射計算をスキップできるような形になってます。
了解です。じゃあもう少し続けましょう。
つまり機能としてはキャッシュも取り入れていて、
ファイルのCタイムを見て変わっていなければ改ざんされてないだろうと判断して、
一部の発射計算をスキップできるようにしてるわけですね。
それによってCPU負荷を抑えつつも、完全にキャッシュに依存しないように、
10%の確率で発射を求めるようにしてると、
なるほどそういうバランスを取ってるんですね。
じゃあこのキャッシュ機能はオプションで有効にする形ということで、
運用環境に合わせて使える柔軟性があるわけですね。
とても面白い工夫だと思います。
ではこういった工夫を踏まえて、
結界を使っていく上でユーザーに意識して欲しいことや、
現場でのオススメの運用ポイントがあれば、
ぜひ教えてください。
そうですね。
多分今のアプリケーションでライブラリ1個も使ってないってケースってないと思うんですよね。
PHPだったらコンポーザーとか、いろいろあると思うんですけど、
そのコンポーザーインストールすると、
ベンダーなんとかってディレクトリにライブラリがいろいろ入ってくると思うんですね。
そのライブラリのソースコードを改ざんされる恐れっていうのが当然あるので、
そういうライブラリが入っているディレクトリは無視しないでほしいっていうのがあります。
こういうのってGitignoreとかだとイグノアしてると思うんですよね、当然。
なんですけど、そのGitignoreは読まないので、結界は。
Gitignoreとは全く別の概念で、
エクスクルードすべきファイルっていうのは直接渡してもらう形になっていて、
エクスクルードするのはログファイルであるとか、ユーザーのコンテンツであるとか、
そういうのはエクスクルードしないといけないんですけれども、
そうですね、Gitignoreのものをそのまま指定するという形ではなくて、
結界専用でイグノアをエクスクルードで書き込んでほしいなと思ってます。
なるほど。確かにライブラリのディレクトリは改ざん検知の対象から外さないでほしいっていうのは大事なポイントですね。
Gitignoreとは別に結界専用の除外設定をちゃんと用意して、
ログファイルやユーザーコンテンツは除外しても、ライブラリはちゃんとチェック対象にしておくと、
そこを意識して運用することでより安全に使えるということですね。
よくわかりました。
今日のまとめとしては、結界はAWS環境で運用しやすく、
セキュリティを重視しつつも柔軟な設定ができるツールで、
検知やライトリミットの工夫も取り入れているということですね。
ライブラリの安全な運用
すごくためになるお話、ありがとうございました。
次回もぜひ色々とお話聞かせてくださいね。
最後に紹介するんですけど、結界なんですけど、先日GitHubのスター100超えました。ありがとうございます。
ぜひ気に入った方、GitHubのスターつけてもらえたら励みになりますので、よろしくお願いします。
それは素晴らしいですね。100スター達成おめでとうございます。
では最後にどういたしまして、こちらこそ楽しいお話ありがとうございました。
それではまた次回もよろしくお願いします。
お願いします。
