00:13
はい、みなさんこんにちは。 keithこと桑原です。本日もやっていきましょう。 keithのエンジニア雑談チャンネルです。
この番組では、ウェブ業界に関することや、エンジニアリング、いろんな技術についての雑談などの情報を発信していきたいと思います。
で、今日はですけれども、脆弱性と付き合う話っていうところで、とりあえず何か学びがあるとかじゃなくて、こんなことをやってますよっていうのが頭の整理のために喋ってみようかなと思った感じですね。
で、脆弱性のどう付き合うかってとこですけど、まずは脆弱性とは何だっていうと、学びのところですね。
これも今弊社やり始めたばっかりで、会社の名前出すとあれなんです。前者的にできてるかっていうとあれですけど、今から進めていきたいなっていう話を中で検討推進をしていこうっていうのが進んでいると。
ということで、昨今のウェブアプリケーション開発の開発環境というかツールだったりエコシステムっていうのがやっぱりちゃんと進化していて、フレームワークがその辺うまいことをラップしてくれて、僕らがあまり意識しなくても割とセキュアなコードが書けるっていう状況にはなっているのは加味した上で、どこまでやっていくかっていうのが今すごく難しいなと思ってるんですね。
昨年から多少ツールとか、いわゆるサースとかに頼って実際使ってみて、実際僕らが書いたコードの粘着性ってどれぐらいあるのかなっていうのを試してみたわけですけども。試しにスニークさんっていうサービスを入れてます。
大数ゼロの中の方でしたっけ?が独立して、そういう開発環境とかエンジニアの毎日のコーディングレベルでのセキュアな対策とかチェックツールであったりとかっていうのがあんまないよねっていうので、そのレベルからやれたらいざリリース前とかに大体的にチェックするというか、
負の遺産を後で全部探してチェックをして全部対策をするんじゃなくて、こまめにこまめに開発する中で見れたらいいよねっていうのが確か思想だった気がします。それなんか思想的に確かに良さそうだなっていうのと、いろんなセキュアなものをチェックする、粘着性試験をするサースって世の中たくさんあるんですけど、とりあえずパッと耳に聞いたことがあるかつ、そこそこ世界的にも使われていて知名度も高いし信頼性も高いみたいなところの情報を見たので、
使っても大丈夫そうかなっていうので入れてみたんですね。入れてみて、社内で作っているツールも実は何個かあって、外に出してなくてその社内のいろんなものを管理するっていうのを内製で作ってるんですけど、そういうものに対して駆けさせていただいたんですけど、思った以上に何も出なかったんですよね。
強いて言うと、ディペンダーボットってあるじゃないですか、GitHubの。あれレベルのものはもちろん出たし、あとはDockerコンテナですね。コンテナの中の一緒に入れている、イメージの中に含まれているPHPか何かの、マインスケールかな?のバージョンがちょっと古かったりとか、この辺脆弱性あるバージョンでアップしといてねみたいなのは検知されたんですよね。
03:13
その程度でしかなかったので、社内的にはあんまり評価は高くなかったんですけど、まだ見えなくはないっていうのはすごくいいなと思ったし、コミット単位とかレベルでも検知できるっていう仕組み化できるのはすごく良かったですけど、使ってわかったのはやっぱりSaaS系はとにかく高いなっていうのはつくづくで感じました。
なんていうか、保険と同じ考え方に近いなって正直思ってて。仕組みを入れておいて、まあでもじゃあ安心化っていうとそういうわけではないですし、かけた金の分を回収できてるかは正直わからないです。エンジニアのそのレベルが高ければ、そういうのに頼らずのエンジニア自身がちゃんと脆弱性に意識とかを持ちつつコーディングしてくれるので、そんな必要性はないし、最後のチェックを外部委託してっていう今までのプロでもまあいいのかもしれないですけど、お金とバランスの相談っていうのはありますけど。
スニークさんがちなみにカバーしてるのは、コシステムとかライブラリーとか、JavaScriptってノードオブジューズみたいな、サードパーティーのライブラリーとかのバージョンで、もしくは脆弱性のチェックとか常にアップデートですね。で、それを検知してそのままプルリクエストまで作ってるんですよ、勝手に。まあそういうものを入れてくれたりしますし、各種テキストエディターですね。
JetBrainsもそうですし、VS Codeもそうですし、その辺にプラグインがあって、そこに入れて、どこでチェックをかけるかってのがありますけど、まあ基本的にはプッシュじゃないですかね。プルリク作る前のブランチプッシュのところぐらいでやったりとか、まあいろいろな設定は確かできたはずなんですけど。まあそういうこともできますし、カスタムコードですね。自分たちが独自に書いたコード。プリマーク自身のコードではなくて、サードパーティーのライブラリーのコードではなくて、それらを使った皆さんが書いたカスタムコードの脆弱性も見てくれます。
あと何だっけ。先ほど言いましたね。コンテナですね。Dockerのコンテナみたいなものとかも見てくれます。最後はIACまで実は見てくれてて、インフラというかデプロイ周りのCICDのところで設定であったりとか、シークレット情報が漏れてないかとかみたいな、その辺まで確か見てくれた気がするんで、割と幅広く、手広く見てくれるっていうのはすごくありがたいとは思いますが、まあやっぱり高いなっていうのはあります。
アカウント数に応じて重量課金の料金体系になったはずなんですよね。なので、うちみたいに住宅開発とかクライアントワークの会社をやっている企業さんは導入しづらいなと正直思いましたね。
リポジトリアクティブにコミットしている人数に対して、さっき言った4つのカバーする範囲、それぞれに対してスネークさんはプロダクトを出しているので、それぞれに対してお金がかかるんですよね。
でなると、案件を多く回せば回すほど、住宅会社っていうのは基本的には大きく儲けることができるので、結局数の勝負をしに行くのが僕らのビジネスであることに変わりはない。
そうするとスネークさんにどんどん課金をしなきゃいけないっていうので、きついねっていうのがあります。
まあ、そりゃ仕方ないんですけど。
さておき、そういうのがあるので、住宅系では脆弱性のSaaSと付き合うのは結構難しいと思ったので、今はOSSを入れてやっています。
06:05
社内で最近、セキュリティの専門家みたいなNGの方を対応することができたので、その方と一緒にやっていて、
その方が今、社内で叩くことができるオープンバースの環境と、WASP ZAPは皆さんの端末にそれぞれ個別にインストールしていただく必要があるんですけど、
そのWASP ZAPを使って脆弱性の検知をするみたいなのを、いつでも僕らが勝手にできるようになったっていうのが一つ環境としては大きいなと思います。
それを後は皆さんに、本当はWebエンジニア全員に入れてほしい感はありますけど、それは難しいというので、いけるところまでいくっていうところですけど、
自ら開発者自身が自分たちのタイミング、自分たちの良きタイミングで実行できるようにっていう環境を揃えた、
WASPは最初からインストールするっていうものなのでいいんですけど、そのホスト上、自分たちのマシン上で動くものですので。
オープンバスはAWS上に確か環境を作ってくださったはずですね。
そこにログインして、どのサイトに対して接着性のチェック、開けるかというものを設定して、後はボタンポチでGOで走らせてくれて、後はそれを結果を待つ。
結果もいろんなフォーマットですね。もしくはXMLとかHTMLとかPDFとかも出力できたはずですね。
全部英語だっていうのが少しネックでありますけど、うちとしてもちゃんとセキュリティのことも意識してコードを書いてますよっていうのを
お客様とかにもドキュメントとして納品もできる、もしくは示すことができるっていうのはやっぱり大きいなと思ってます。
そんなものの対策をしていったりはしますけど、さっきととおりフレームワークがその辺をいろんなものをラップしてくれてるので、
あんまり意識しなくてよくないかっていう、難しいですね。必要性に駆られなければやらないっていうのは分かる。
起きるか分からない問題に対して時間とお金と労力をかけるってどうなのっていうのはもちろんある話で、
ビジネスのバランスの話に結局はつけると思いますけど、とはいえエンジニアとしてフレームワークがやってくれるから
意識しなくて良い、もしくは学んでなくても良いっていうのは僕としては正直ナンセンスかなと思ってます。
というので、社内でも推進はしていきたいなっていうのが正直あるわけですね。
今やろうとしているその推進は環境を作ったし、プロジェクト的にいつでもOSSなので無料で叩くことができるよ、
チェックするために使うツールを社内に用意できたっていうのは一つ大きい進歩で、
その後は社内のエンジニアとかPMGNとかにも展開をしていく話ですけど、
オープンバスは基本外から叩くものなんですよね。URLをここに設定をして、
ドメインとかを設定して、それを外からチェックかけるみたいなことをしてくれるのがオープンバスっていうツールなので、
まずは外からの脆弱性試験っていうのをやってくれるのが一つで、
あと何だっけ、NMAPか。NMAPっていうコマンドを最近僕は教えていただきまして、
09:00
要はどのネットワークが開いてますか、開放されてますかとか、
どこのネットワーク、例えば423とか80とかポート番号があるじゃないですか、
このポート番号は開いてますとか、このポート番号だったらアクセスできるみたいなのをちゃんと縛ってますかというか、
制限してますかっていうのを確かチェックしてくれるツールですね、NMAPっていう。
確かBlueでインストールできるコマンドだったはずですね。
僕も確かBlueでインストールしたんですけど。っていうのもやってくれますので、
次はそのネットワークレベルのどこまでの話かあれですけど、
一旦開けてるか開けてないかとその辺ブロックを設定しますかっていうのをチェックする。
あとはその中のカスタムコードですよね。
ブラックボックス的に外からではなくて、中のホワイトリスト的にコード自体、
カスタムコードをチェックするとかっていうのをやってくれたりするものもありますね。
さっき言ったそのWASP ZAPはそれに近いものとかがありますし、
WASPだと認証周りのところとかも突破する。
その本番環境でいきなりチェックをかけるのはさすがに怖いというか、
いろんな問題があるからできない。
なのでリリース前とかは基本テスト環境とかステージング環境にチェックをかけたりすると思うんですけど、
そういうのには経てて、ベーシック認証みたいな簡単なものもあればちゃんとIP制限をしたりとか、
サービス的にはGoogleの認証、Cognitoとかもそうですけどね。
とかでGoogleのフェデレーションを使っているときもあったりするじゃないですか。
そういうものを突破しないとアクセスできないというようなサイトに対して、
WASPの場合は1回認証させるんですよね。
その認証したものをWASPに1回教えて覚え込ませて、
そこでチェックをかけるみたいなことはできるらしくてですね。
本当にWASP便利だと思います。
その中でいろんなものをチェックかけてくれるっていうのはすごく強いなと思っています。
ただWASPもそんなカスタムコードレベルじゃなくて、
結局は外部的にアクセスをしてチェックをするみたいなものだったはずなので、
完全なるペネトロエーションテストではないはず。
ちょっと僕はその辺まだ不勉強で、
ペネトロエーションはどこまでがペネトロエーションなのか分かってないですけど。
とかはあるので。
とりあえずはオープンバスとかWASPザックレベルでかければ、
あとでぐらいかければ、
少なくとも外ですね。
外部からのアクセスとかアタックに対しての対策ができてますかっていうのは確認はできるので、
まずはそこからスタートで全然いいのかなと思います。
本格的にちゃんとやるんだったら、
他のツール使ったりとか、
ちゃんとお金かけてSaaS使ってペネトロエーションもやったりしますし、
OSSのペネトロエーションテストがやってくれるツールがあるらしいですね。
とかあるので、その辺まで最終的な対策したいですけど、
今は一旦外部からアクセスする対策の環境を作ったんですけど、
そういう環境を作るまではよくて、
社内への意識向上と推進のお話をどうしようかっていうので、
社内でそういうセキュリティのことを議論する委員会というのを去年から立ち上げてやってるんですけど、
難しいのはネイティブアプリケーションですね。
Android iOSのほうはネイティブな時点で、
言うてそれほどセキュアなところのアタックとか、
いわゆるクラッキングをするっていうのは、
かなり本格的にクラック能力をある人しかできなくなってくるので、
12:00
言うほどセキュリティのことを意識しなくて、
そもそも良いよねっていうのがバックボーンにあるわけですね。
なので、社内ではそういうテックリードの方々とかに、
セキュリティのことってどれだけ意識してますかとか、
開発の時にどんだけセキュリティのことを加味しながら開発しますか、
ほぼほぼ考えてないし、考えなくていい環境でいるからこそ、
勉強する機会もなかなかないねって話をされてて、
仕方ないなってそれは正直思ったし、
本当に必要ないんだったらそれでいいと思ってらっしゃいますね。
今、プラットフォームとかハードウェアレベルでその辺、
ちゃんと遮断されているっていう環境があるのであれば、
無理に勉強する必要は時間がもったいないのでなくてよい。
問題はウェブ系ですよね。
バックエンドとフロントエンドの方々に対して、
セキュリティ意識とか勉強の話を進めていきたいと思ってます。
結局ウェブって時点でHTTPでアクセスするしかないので、
その辺周りの勉強したほうがもちろんいいと。
ネイティブアプリも結局はAPIで叩くっちゃ叩くんですけど、
叩かれるAPIの方で脆弱性のチェックだったり、
ブロックを担保するのが正しいよねって話はもちろん当然ではあるので、
そちら側の人がメインになります。
もっと言うとバックエンドの人たちがもっと言うと中心になる話ではあるんですけど、
フロントの人もフロントだけをやるわけではないし、
フロントにもゼジラ性とかセキュリティの話は全然あったりはするんですけど、
そこは一旦度外視で、記録ウェブエンジンにあてるところで今はやろうとしていて、
やろうとしているのが徳丸先生のウェブアプリケーション、
安全なウェブアプリケーションの作り方という書籍ですね。
あれをベースとした試験みたいなのがちゃんとあるんです。
通称徳丸試験と言われるものがあると。
僕も最近初めて知ったんですけど、教えてもらって。
ウェブセキュリティ基礎試験ですね。
かっこして徳丸基礎試験というのがあります。
PHP技術者認定機構というところが出しているものですね。
もちろん名前の通りなんで、徳丸先生もしっかり監修に入ってやっているものですね。
これを資格取れとは言わないですけど、
取れるぐらいの知識とか試験というのをしっかり皆さんに叩き込みたいというか、
インストールさせたいなというのを進める方向で今は行っています。
それを来年の新卒からやっていきたいなというのが、
全員やれるかどうかは別として分からないし、
どこまで新卒研修プログラムに含められるかというのはすごく難しいし、
どうやって進めるかもかなり難しいんですよね。
この勉強するためにちゃんとDocker環境を用意してとか、
Firefoxでないと意外とこの本に書かれている内容が再現できなかったりとかするので、
進め方はすごく難しいとは思いますが、
ちゃんと新卒研修に入れて、
若い子たち、特にコードを今からバリバリ書いていただきたいなという人に対しては、
特にこの辺を進めさせたいと思っているので、
そういう進め方をしようとしているようという話ですね。
脆弱性と付き合うというところですけど、
チェックをするという、開発する現場でも脆弱性と付き合う。
脆弱性と付き合うためには自分たちが脆弱性のことを知らなきゃいけないので、
そういう勉強もすると。
特に先輩社員、既存社員もそうですけど、
社内全体としてまずは新卒を中心にやっていきつつ、
15:01
新卒のほうでも盛り上がっていくと、
先輩のほうもやっぱりやらないと怖いねというか、
僕らもその辺にちゃんと意識していなかったという、
ボトムアップ型で勉強というか、
そういうムード、流れを作っていきたいというのが僕の思惑としてあって、
来年の新卒メンバーに行きたい。
まずは基礎試験ですね。
あくまでこれはウェブセキュリティ基礎試験という名前の通りなので、
まず既存の勉強をしつつ、
その先どこまで発展をやるかというのはまた委員会のほうで議論していきたいと思いますけど、
まずは意識向上のところを醸成していかないことには話は始まらないし、
意識とか結局文化の醸成と似てくるんですけど、
結構時間がかかるものだし、
全員がそれをやってくださるとは正直最初は思ってないですけど、
仕事としてプロとしてコードを書くんだったら意識するものとしては、
これは含めていいと思っていますので、やっていこうかなというところですね。
はい、そういう話でした。
全然まとまりもなくザスクバランの話でしたけど、
今日はそんなところでございます。
では終わっていきたいと思います。
お疲れ様でした。
バイバイ。
