上場前後でセキュリティ対策に関わる人員が3倍に　ココナラ・川崎氏が語る、体制の変化

リンクをコピー

記事をブックマークブックマーク解除

画像・スライド一覧

株式会社ココナラ・川崎氏、ENECHANGE株式会社・岩本氏、株式会社BookLive・日向野氏は、それぞれの企業におけるセキュリティ対策の見直しについて話しました。全3回。前回はこちらから。

株式会社ココナラは上場をきっかけにセキュリティ対策を強化

渡辺洋司氏（以下、渡辺）：いろいろ書いてあるんですが、いったん先にいきたいなと思っています。スライドがある会社さんとない会社さんでそれぞれあったりするので、いったん先にいきながらあとで僕がまとめようかと思います（笑）。

続きのトピックに入るんですが、その改革はどんな背景でやったかみたいなところ。体制の話をすると、結局「それはなんでやったのか？」みたいなところが（話題に）出ると思います。今回は、「実際の環境とか体制とかはどうだったんですか？」みたいな話をみなさんに聞いてみたいなと思っています。

川崎さんのところですね。ココナラさんのお話をお願いします。

川崎雄太氏（以下、川崎）：はい。（スライドを示して？）これはもうafter側なので、まず先にbeforeの話をします。先ほど「なんでセキュリティを強化したの？」というところで。

ココナラでいうと、2021年3月に上場をしたんですが、その前の上場に向けたいろんな審査がある時に、それに耐えられないシステムになっていたということがファクトでした。

私が入社したのが2020年10月ですが、ちょうど上場の半年ぐらい前。急務で「セキュリティができていないよね？　やらなきゃいけないよね？　上場の条件に必要なやつって何なんだっけ？」というところをまずは一つひとつ整理していって、優先度をつけてやっていくようなところから始まりました。

（スライドを示して）今のこれは完成形ですが、当時はCSIRTみたいなセキュリティの担当の人は誰もいない状況でした。あと、インフラとSREを両方やっているチームが私を入れて3名しかいない状態だったので、セキュリティの専任の者はいない状況。プラス、私も片足を突っ込んでセキュリティをやっていた身ではありますが、別にセキュリティのプロフェッショナルでもない状況でした。

なので、1人1つずついろいろな技術本を見たり、いろいろな会社のテックブログを見たり。あとは上場で何を苦しんだかというツラミとかをいろいろな会社さんから聞いて、そこでどうやってやっていくかを考えてやっていました。

現在はセキュリティ担当が3倍に

川崎：（スライドを示して）結果としてココナラが今どんな体制でやっているかというと、このような体制でやっています。上場前までは専任担当がいなかったんですが、今は少数精鋭ではあるものの、セキュリティの専門のエンジニアが1名います。今はちょうど2人目を採用しにいっているところです。

あとはインフラ・SREの部門も私を入れて3名だったのが、私を抜いて6名になったので、3倍ですかね。結果としては3倍になったところがあるので、インフラ・SREレイヤーからAWSのアカウントを分離していくとか、IAMロールを整備していくようなところはインフラのレイヤーでやってしまえということでやっていました。

CSIRTのほうでは攻撃対策ソリューションの導入、WAFとかを使っていたものの運用はされていないという課題があったり。あと、WafCharmもずっと入れていたんですが、「ちゃんと運用できていたんだっけ？」みたいなところの課題がありました。

なので、こういうところをしっかりと整備していくとか、あとはAWSの利用基準ならIAMのように、上のロールの整備と一緒に、「どの人にどういう権限を与えなきゃいけないんだっけ？」ということを、AWSもそうだし、AWS以外もやっていく体制を組んだというのが、ここ2年、3年かけてやっていたことかなと思っています。以上です。

渡辺：ちなみにこのCITチームというのは、何という名前なんですか？

川崎：コーポレートITの略です。なので平たく言うと情シス、社内SEみたいな感じです。

渡辺：なるほど。（スライドを示して）赤いところというか、ピンクの（囲いの）ところがプロダクト系が主にやるところ。

川崎：そうですね。そんな分担になっています。

渡辺：なるほど。6名に増えて楽になったとか、まだぜんぜん大変みたいなのはどうなんですか？

川崎：そうですね。セキュリティとかで諸々含めて言うと、やはりココナラも新規事業をやっていくとか、他の今ある事業にエンハンスしていくことに注力していくにおいて、足りているかというとちょっと足りていない部分もあります。

ただ、今までは優先度の高いものもできなかった状況から、優先度の高いものはなんとか回していけるところまで今は来たので、一定のクリティカルなところはしっかり防ぎつつ、事業のグロースもできているかなと思っています。

渡辺：なるほど。ありがとうございます。

ENECHANGE株式会社ではWAFまわりの設計が不安定だった

渡辺：いったん次に進んで。岩本さん、お願いします。

岩本隆史氏（以下、岩本）：はい。（スライドを示して）先ほどお話ししたものをシンプルに図にするとこうなります。一番左上のところがAWS WAFじゃない別のWAFがALBに紐づいていたんですが、ちょっと不安定だった。あと、他にもいろいろなALBだったり「CloudFront」だったりというWebサービスがあるんですが、ここにはWAFが適用されていない状況でした。

これは1つの見識だなと思っていて。脆弱性の検査などは別個でやっていて、丸腰ではあるんですが、そういった面で担保はされていたので、あえてしていなかった背景があったとは理解しています。

あとは「Trusted Advisor」のビジネスサポートプランを契約しているので、使える状況ではあったんですが、放置というか、誰も見ていない状況でした。

右上のところはCI/CDツールですね。先ほどチラッとお話ししたOpenID Connectに対応する前だったので、IAMのアクセスキーをそのまま払い出していたという状況がありました。

最後に、右下の「Slack」でモニタリングをしているんですが、インフラレイヤーのメトリクスの通知は来るんですが、セキュリティに関する通知は一切ない。そのような状況でした。