1. h173.club
  2. 002: セキュリティ診断ってな..
2022-04-15 20:27

002: セキュリティ診断ってなんですか?

@kenchanと@takapi86の二人で、GMOペパボの各サービスが毎年行っているセキュリティ(脆弱性)診断について、EC事業部での実施の流れなどを話しました。


※ 当時の研修の名前の都合上「ホワイトハッカー研修」という言葉を使っていますが、現在はそういった専門性を持つ方々のことは「ホワイトハット」「セキュリティ専門家」「セキュリティエンジニア」と呼んでいます。

00:02
ひとなみクラブは、EC事業部の2人の高橋が、社内の出来事や最近気になっている技術について話す、
知恵もペパボの社内ポッドキャストです。
みなさんこんにちは、くんさんです。
こんにちは、たかぴーです。
今まで2回収録したんですけど、ずっと木曜日に収録して金曜日に公開するっていうのをやってたんですけど、
今週は木曜日、明日市販広告会があるので、実は水曜日に収録してますね。
なんか久々の全員の原則出社ということで楽しみなんですけど、たかぴーは最近はどれくらいの頻度で会社行ってるんですか?
僕はですね、アルマさんが最近入社されて、アルマさん今週3で出社をしているので、それに合わせて出社をしてますね。
なるほど、毎週最近は3日くらいは会社行ってるんですね。
そうですね。
最近は結構ずっと暑かったんですけど、明日は天気悪いみたいなんで、みなさん気をつけて出社しましょうね。
じゃあ今日はどんな話をしようかなと思ったんですが、
一つ、このポッドキャストやる前から一度たかぴーとこんな話したかったなと思うのがあったんで、それを今日話していこうかなと思ってます。
内容は石井事業部というか、ペパボー全社で各サービスがやってるんですけど、セキュリティ診断ってやつですね。
そもそもどういうものなんですか、セキュリティ診断っていうのは。
そうですね、いろいろ種類はあって、振入テストとかネットワークの診断とか、セキュリティテストの中でもいっぱいあるんですけど、
今回はカラーミーでやっているウェブアプリケーションの脆弱性診断についてちょっと説明すると、
ウェブアプリケーションに脆弱性がないかを検査していくという診断となります。
どうやってやってるかっていうと、ウェブアプリケーションって基本的な作りとしてはリクエストを送って、
レスポンスで返ってきてそれを描画するみたいなアプリケーションだと思うんですけども、
アプリケーションをリクエスト単位で脆弱性がないかを網羅的に検査していくような診断となります。
例えばどういうことかっていうと、admin.shoppro.jpすらログインみたいな感じのURLがあったとします。
そこにポストのリクエストを送ります。
そこのポストのリクエストにはIDとパスワードっていうパラメーターがついてますっていうところであるとすると、
例えばそのIDにそもそもSQLインジェクションの脆弱性がないかとか、XSSがないかとか、CSRFがないかみたいなところを全部網羅的にチェックしていく。
03:11
それが一通りスキャンしたら次にパスワードっていうパラメーターを網羅的にスキャンしていくみたいな流れで、
アプリケーションを全体的に試験項目に沿って脆弱性がないかを網羅的に調べていくみたいな診断となりますね。
なるほど。
じゃあということは結構こうやったらSQLインジェクションが起こりやすいとか、CSRFが起こりやすいみたいないくつかのパターンがあってそれを順番に試していくみたいな感じなんですね。
そういうイメージですね。
それを自動でやったりとか、自動でスキャンするツールがあって、それを実際に使ってスキャンしたりとか、あとは手動でやったりするみたいなイメージですね。
なるほど。自動でやる方だと、ここ1,2年やってない気もするんですけど、JMOインターネットグループ全体のホワイトハッカー研修みたいなのありましたよね、そういえば。
やりましたね。私もそれ参加して資格みたいなのを取得しまして、今社員賞にホワイトハッカーマークみたいなのがついてますね。
終了するともらえるんですよ、そのマークが。
最近ないですね。
そうですよね、確かに。またあれやってもらえると嬉しいですけどね。
あれめちゃめちゃ良かったので、またやってもらえると嬉しいんですけど、
セキュリティ周りとか、今他の家来さんとか入って、研修みたいなのやるみたいな話があったので、そこでやっていくのかなとは勝手には思ってるんですけど。
あの研修の最後のカリキュラムというかが、自分たちのサービスをツールで診断するみたいなやつだったんですよね、確か。
そうですね。
これはやりますね。
実際にそういう診断ツールみたいなのを使って、自分たちのサービスが安全かどうかっていうのを検証して、そのフィードバックをサービスを開発してる人たちに渡しておしまいみたいな感じでしたよね。
そうですね。
じゃあそうなると、自分たちでそのツールを使ってやるみたいな話もあったんですけど、カラーミーだと具体的にどういう感じでセキュリティ診断をやってるんですか。
カラーミーでは一応年1回シフトセキュリティ社というところの外部の会社に診断を依頼して、実際にやってもらってます。
06:10
どうやってやってるかっていうと、カラーミーでは脆弱性診断用の環境がありまして、フリースク環境って呼ばれてる環境なんですけど、
それに向けてリモートで、シフト社さんからリモートで脆弱性のスキャンとかしてもらってるという感じになりますね。
なるほど。他の会社さんに委託してやっていただいてるっていうことで、自分たちでツールでやるのとはまたちょっと違ったやり方がされたりするんですか。
基本的には同じなんではないかなとは思ってますね。
基本的な流れは一緒だと思うんですけども、違うところとしてやっぱりプロフェッショナルなところがあるので、
アプリケーション特有の脆弱性がないかみたいなところを見てもらったりとか、っていうところが実際に違うところかなと思います。
確か準備の段階ではどういうページがありますかとか、どこにリクエストするといいですかみたいな調査票みたいなものもあるんですよね。
セキュリティ診断の費用がリクエスト単位になるんですよね。
なるほど。
ポストリクエスト、ログインみたいな組み合わせで、それが何リクエストあるかみたいな感じで見積もりをしていくんですけども、
その見積もりは、まずあっちのセキュリティ会社がクローラーみたいな感じでリクエストを洗い出してくれるんですよ、リクエスト数を。
これでいいですかっていうふうな見積もりが来て、実はこういうリクエストも隠れてるんですよみたいなことをやり取りして見積もりが決まっていくっていう感じになります。
なるほど。
やっぱりその点で一度やり取りがあったり、ツールでまずやってみてこうですかっていうのに対して、
いやいや実はツールだと見つかってないんですけど、ここもあるんですよみたいなのがあるので、
そういうやり取りとか実際の診断そのものだったりを一緒に他の会社さんでやってもらってるっていうのに結構メリットがある感じなんですね。
そうですね。はい。
なるほど。さっき振り付く環境っていう話してましたけど、診断、いきなり本番環境にそういうことやられてもやっぱり困るわけですよね、おそらく。
そうですね。
その辺の準備とかはどういうことをやったり、どんなふうに進めてるんですか。
そうですね。もともとVM環境に振り付く環境がほぼインテグレーションと同じようなものがあるので、準備としてはソースコードを最新にするとか、
09:00
あとは外部にメールを飛ばさないようにするとか、他の決済会社にリクエストを飛ばさないとか、外部連携してるところを塞いだりみたいなところをやっていくっていう感じですね。
なるほど。
結構、私たちが普段使ってると困らないようなことでも、診断みたいなことをされると困るっていうケースがあるってことですね。
ありますね。
そういう準備とかはいつもどれぐらいかかってるものなんですか。
そうですね。基本的にはそんなにかからない。1日とかで終わるかなっていうところはあるんですけど、新しい機能が追加されたりとか、アーキテクチャーが変わったみたいなところがあると新しく準備しなきゃいけないので、
その上プラスのちょっと日数がかかるよっていうところはあるんですけども、今回でいうと、今年の診断でいうと、新しくフリープランが追加されてたんですね。
フリープランを申し込み終わって設定するときに、イプシロン側との通信のやり取りとかが発生してるんで、そこら辺の脆弱性診断で影響がないように工夫したりみたいなところは準備が結構必要でしたね。
そこは仕様を読み解かなきゃいけなかったので、そこは2,3日ちょっと時間がかかっちゃったりみたいなところもありましたね。
なるほど。結構その1年で増えた機能だったりの中で外部の通信があるところとか、これそのままだと診断されるとまずいようなところを全部把握して影響範囲調べて、
そのところを潰して診断してもらうみたいなのが必要なんですね。
そうですね。
なるほど。じゃあ結構最近1年とかいうスパンで入った大きな機能とかはほぼほぼ実は診断を準備すると把握できるっていうことですね。
そうですね。それはそうなるかなと思います。もちろんセキュリティ診断の対象になっているものっていう条件はあるんですけど、そういったところで新しいのを触れたりみたいなところができるので、そういったメリットみたいなのはありますね。
いいですね。そういう準備をしてこれぐらいのところをこことここを診断してくださいみたいなお話をした後に実際におそらく診断が始まるんですけど、診断はどういう感じで進むんですか?
診断は基本的にはもうあっちがやってくれるんで、こちらは特に何もしなくてもいいんですけど、たまにその仕様的にどうなっているんですかとか、こういうデータが作れないので作ってくださいみたいな、操作する上では通常作られない、
12:19
例えばそのバッチが外してないと作られないデータみたいなところがあったりとかするときはこっちで手動で対応したりとか、あとはその仕様がわからないところは説明してあげたりとかっていうところがあるかなと思いますね。
基本的にその質問表って形で来てそれに回答していくって感じなんですけど、基本的にはスラック上で回答してみたいな感じになります。
今はあれですよね、スラックのチャンネルもゲストがスラックコネクトか忘れましたけどありますよね。
そうなんですよね。シフト社さん用のゲスト参加してもらってそこにやり取りしているチャンネルがあるので、そこで質問だったりとかやり取りしたりとかしておりますね。
そうやって診断が進んでいくと最後はどういう感じになるんですか。
最後は脆弱性診断報告書っていう形で、診断が終わったら脆弱性がどういうのありましたっていう形で報告が来るので、それをもって完了っていう感じですかね。
プラスアルファ、脆弱性報告書に対して質問できる期間だったりとか、再診断できる期間っていうのが1ヶ月ぐらいあったかなと思うので、すべて完了したら終わりっていう感じになるんですけど。
診断結果ってどんな風に来るんですか。ここがやばいぞみたいなのが来るんですか。
そうですね。報告書は基本的にリスク順みたいな感じで並んでいて、例えばSQLインジェクションみたいなめちゃめちゃやばい脆弱性は緊急度高みたいな感じでバーンと来て、これは早く直しましょうみたいな、どうやって直せばいいですかみたいな感じの説明文が書かれていて、それに対して直していくって感じになるんですけども、
ここまでやばい脆弱性については診断をしながら速報っていう形で、やばい脆弱性が見つかった時にその日にお知らせをしてくれるので、だいたいそういうのって即時対応が必要なものなので、即時対応してっていう感じになるので、
レポートというか報告書が来た段階ではほぼほぼ完了になっているっていう感じではあるんですけど、そういった感じでリスク順に並んでどういう脆弱性がありますよみたいな感じで報告が上がってくるという感じですね。
なるほど、じゃあそういう速報みたいな本当にやばいぞっていうのはすぐに直すっていう形だと思うんですけど、それ以外の直した方がいいよとか、そういう緊急で来なかったものとかはどういうふうにしてるんですか。
15:13
緊急じゃないものに関してはリスクの評価をして、即時いつまでに対応が必要なのかっていう期限を設定して、いつまでにやりましょうっていうところで、その目標に対して修正していくっていう流れになりますね。
私の場合はそうですね、例えばCSRF1つ、同じCSRFだったとしても、例えばどの画面でそれが出てるかみたいなところによってリスクが違うので、例えばパスワード変更のところで出てたらかなりやばいっていうふうになるんですけども、全然その状態が更新されないようなものに関してはリスクがそこまで高くないので、ちょっと期限は遅めにしてみたいなところで優先順位をつけてやってますね。
それを私の方では最後に技術部の森太子君に見てもらって、OKだねってなったらその通りに行くみたいな、そのスケジュールで行くみたいな感じにしてます。
なるほど、じゃあシフト社さんはシフト社さんで、これは緊急度が高いよとか重量度が高いよっていうのをレポートとして出してくれるんだけど、
その場合はさっき言ってたみたいな、ここって実はあんまり重要な機能がないんだよとか、そういう脆弱性があっても影響が限定的だよっていうのは、実際サービス運用してたり開発してる側から見るとそういうのが分かってきたりするので、
改めてそこでこういう優先順位とか緊急度を設定し直して、それを赤帯に確認してもらって、OKだねってなったらそこから順番に対応していくみたいな感じですかね。
はい、そうですね。
なるほど、なんかそれってこう全部直し切るんですか。
結構いろんな項目が指摘されていて、例えば最近追加されたものだと、パスワード強度メーターが設置されてないみたいなとかも結構指摘事項としてあるんですね。
その情報、その参考レベルみたいな感じで情報レベルっていうのがあるんですけど、そういうのって今すぐ業務を止めてやれみたいな感じではないので、そういったものもあるんで、全部、最終的には全部対応した方がいいとは思うんですけども、
カラー網とかECのセキュリティ全部含めてどういう順番でやっていった方がいいのかっていうのは考えて計画を立てていくっていう感じになってます。
なるほど、すごくしっかりやってるし、そういうパスワード強度メーターみたいな話が出てくるのもすごい面白いですね。
そうですね、結構年々項目が追加されてきたりとかするので、なかなかそういうのも近年どういうのが注目されているかみたいなところが分かってきたりするので、そういうところが面白いなと思いますね。
18:14
確かに、今のモダンなっていうのはあれですけど、一般的なウェブアプリケーションであればこうあるべきとかこういうのが望ましいっていうのも、
セキュリティの観点から結構指摘いただいたりとか情報をいただけるっていうのは一つ、他社さんにお願いしているメリットっていうところはあるんでしょうね。
そうですね。
なるほど、分かりました。
一通り自分が話したかったなというセキュリティ診断についてっていうテーマでは一通り話せたかなと思うんですけど、再び追加でこれ言っておかなきゃみたいなものありますか?
特に話できたかなというか、一通り脆弱性診断についてはお話できたかなとは思いますね。
そうですね。今今私がいろいろ準備したりとか、シフト社さんとのやり取りとかしているんですけども、ちょっと後継者が欲しいなというところはあるので、
ちょっと来年とか一緒にやってくれる人を募集中ですという感じです。
なるほど、そういう意味ではセキュリティキープの1年っていうのは、いわゆる暦上の1年とちょっとずれていて、絡みだとおそらくセキュリティ診断は2022年度分が2023年の頭ぐらいにされるだろうっていう感じなので、来年って感じですね。
そうですね。
なるほど、わかりました。ありがとうございます。じゃあぜひぜひ、このポッドキャストを聞いているセキュリティちょっとやってみたいなという方は、たかぴーにお声掛けいただければと思います。
じゃあ今回は収録する度に長くなっていってこれまずいなとちょっと思ったんですが、そろそろ終わろうかなと思います。
このポッドキャストへのご意見ご感想話して欲しいトピックなどありましたら、スラックのh173ひとなみチャンネルまで来ていただけるとありがたいです。
じゃあ今日はこれで終わろうと思います。バイバイ。
ありがとうございました。
ありがとうございました。
20:27

Comments

Scroll