パイプドビッツは、「情報資産の銀行」を事業コンセプトに、情報資産プラットフォーム「SPIRAL®」シリーズを開発し提供してきました。「金融資産」を預かる銀行と同じように、お客様から「情報資産」を安全に預かり、有効活用していただくため、メール配信を始めとした様々なサービスを行なっています。現在顧客は3500社を超え、利用されている業界は金融、不動産、教育、介護、観光、メディアなど多岐に渡ります。
本稿では、そんなパイプドビッツの志賀正規氏(CISO)、鈴木信裕氏(CTO)、セキュリティ推進部長の横山大輔氏、システム基盤整備部長の引地千秋氏に、アスタリスク・リサーチ 岡田良太郎がこれまでの課題とその取り組みについて、お話を伺いました。
（※本インタビューは2019年12月に行われました。役職等は当時のものです）
「これからは情報利活用の時代になる」という理念のもと設計した、SPIRAL®
岡田良太郎（以下、岡田）： 本日はお集まり頂きありがとうございます。まずは御社のプロフィールからお聞かせ願えますか。
志賀正規（以下、志賀）：弊社は2000年に創業した会社です。初期はメルマガ配信などの要望に応えていましたが、創業社長であり、今はグループ代表を務める佐谷が、「これからは情報利活用の時代になる」と言って、お客様のデータを中心に考える方向にシフトチェンジをしました。「データベースの銀行」というワードでスタートしたものが、今の「情報資産の銀行」というビジョン、そして「SPIRAL®」の設計につながっています。
岡田：先見の明があったんですね。当時から比べると、メールやブログなど、情報配信システムというのは誰でも作れる時代になってきました。そんな中で御社のサービスが生き残っている理由って何だと思いますか？
鈴木信裕（以下、鈴木）：今は「個人情報を預かる」ということ自体が、顧客にとってリスクとなっていて、例えば個人情報の漏洩などを一番気にされています。そんな中で、国産ベンダーとして「しっかりデータをお預かりする」ことにコミットしているというところに、価値を感じて頂いていると思っています。
志賀：2000年代はメール配信が中心的な利用シーンでした。しかし、最近ではメール配信は一切しない中での「データの利活用」が活発で、利用シーン、パターンも増えています。
比較的新しいところでは、人事労務管理における給料明細の電子化等が挙げられますね。社員の給与の電子化のために月に一回、SPIRAL®を使って社内業務アプリケーションでWEB明細を社員に送る。他には、製品などの「人気投票キャンペーン」実施や、顧客エンゲージメント拡大のために「コミュニケーションツール」として利用するという例もあります。
メールはあくまでも接触手段の1つですね。最近ではメッセージングの手段としてLINEを使う、ということも増えてきています。
岡田：他のアプリとの連携の話は面白いですね。社会や顧客の要請でグイグイと増えてきたんでしょうか。
志賀：そうですね。我々の機能だけで完結しないプロセスを作っていく中では、今は外部連携サービスという選択肢が多いです。
セキュリティが常時ビルトインされている状態を作り出すのに苦慮した2000年代
岡田：創業された2000年代当時というのは、セキュリティアジェンダってまだ「コンプライアンス」程度だったと思うんです。そんな中「個人情報保護法（2003年成立）」や「J-SOX法（2006年成立）」が徐々に導入されてきました。これは御社にとって追い風だったのか、それとも向い風でしたか？
志賀：我々は「追い風だ」と認識していました。個人情報保護法が出る前から、個人情報を安全に運用するノウハウは時代の要請として必要になるだろうということで取り組んできていました。例えば、プライバシーマークは2001年に取得していて、先日10回目の更新をしたところです。
個人情報保護法のような法律が出ると、極端な会社さんですと「怖いから個人情報は扱わない」というところも出てくるんですが、そこで「自社でオンプレでサーバを立てて管理するよりも、我々のようなサービスベンダーに任せた方がいいよね」と思って頂けるように、我々はそのための運用体制を整えていきました。
岡田：2000年代は「セキュリティ」って言っても、「これ入れとくのが常識だろう」というのがあまりなかったですよね。そんな中で「情報預かりますよ」「弊社にお預けください」てことをバァーンと謳っていく。そこで求められる品質とか、安定稼働というような問題に、どう立ち向かっていたんでしょう。
志賀：SPIRAL®には「クライアント認証機能」を2004年に実装しています。セキュリティの機能強化をしよう、という意識は初期からあるんですよね。
横山大輔（以下、横山）：私は2002年頃にアルバイトから弊社に関わっていて、メンバーの中でも古株な方だと思うんですが、弊社がセキュリティとか品質を本気で見るようになったのは2010年頃だったと記憶しています。
志賀：2009年頃に現代表取締役CEOの林（2009年当時CTO）が入ってきて、「これからは品質を高めていこう」となりました。林は元々、前職で品質管理をやっていたので、そこで得た考え方をしっかりと持ち込んで、体制を立ち上げて進めたというところですね。ちょうどそこでSDLC (Software Development Life Cycle)という考え方について、整備が始まりました。
元々ISOとかPマークを持っていることもあって、セキュリティの機能は、いろんなリスク管理チームが兼務でやっていましたが、初めて部門名に「セキュリティ」と付く専門組織を設置したのは2015年です。「セキュリティ推進室」という部署ができました。
社員が増えていく中で、セキュリティ教育をしてもなかなか定着していかないことに焦りを感じていたからです。「セキュリティ意識」というのは、常時ビルトインされている状態にしておかなければならないものだと思いますが、そのきっかけとなることはだいたい2パターンしかなくて、「何かやらかした」か、「あなたセキュリティやってね、とアサインを受けた」か、どちらかなんです。
岡田：全社員が「やらかし」を経験するまで事故るわけにはいかないですよね。
志賀：どうすれば「きっかけ」を作っていけるかと考えた時に、もう一回心構えを醸成しよう、と思ったんです。皆、「情報資産の銀行」というキーワードで集っている社員なので、「セキュリティは大切」「情報をちゃんと守るということは大切」という意識のベースはあるんです。でもそれをどう行動にすればいいかのギャップが大きくて、それをなんとかしたいという思いでチームを作りました。まず最初に心構えを再定着させるためのスローガンを掲げて、活動を始めたのが2015年です。
「100-1=0」 をスローガンに、セキュリティチーム立ち上げ
岡田：「スローガン」というのは、志賀さんが社内に対して掲げてきた、「100-1=0」のことですね。
志賀：はい、我々が100の信頼を積み上げても、大きなセキュリティのインシデントが1つあれば、全ては無に帰してしまいます。この「1」を起こさないために、我々はセキュリティと向き合いましょう、ということですね。最初は社内でも「何言ってんだこいつ」的な感じだったと思うんですけど、2年位経ってくると、現場での会話でそのワードが滲み出すようになってきました。
岡田：おお〜。
志賀：でも結果的に、このスローガンを立ち上げた翌年の2016年に、大きなインシデントを起こしてしまいました。間に合わなかったんです…。（参考：「SPIRAL ECへの不正アクセスによる個人情報流出」）
岡田：そうですね…。振り返ってみれば「起こるべくして起こった」ということもあるかもしれませんが、当時は世の中のトレンドとしてもいろいろなインシデントが飛び交っていた時期だとは思いますけどね。このインシデントがSPIRAL®本体でなく、SPIRAL“EC”だったということで、よかったこと、悪かったとことがあったと思うのですが、振り返ってみて、どうですか？
鈴木：弊社は金融系のお客様が非常に多かったので、インシデントには特に繊細な対応が求められました。SPIRAL®もSPIRAL ECも同じ企業で、同じ人が作っている以上、SPIRAL®本体にも同じような脆弱性があるんじゃないか、ということについて、説明を要求されることが多かったですね。「本当に大丈夫なのか」を、棚卸し的にゼロベースで説明する必要がありました。志賀さんが順番を追って説明しに行っていて、非常に大変そうだなと思っていましたね。
岡田：インシデント後の、この、パイプドHD（株）の佐谷社長と、パイプドビッツの林社長のご説明を絶賛した人は多かったです。SPIRAL®そのものへのセキュリティの取り組みは、明らかにこの時、エンパワーされたと思うんですよ。
このインシデントがきっかけで、弊社とのお付き合いも始まり、3Dマネージドサービスを入れていただいたり、アドバイザリ定例が始まったりしました。2020年には、このお付き合いがまる4年になろうとしています。
インシデントをきっかけに、セキュリティチームの結束が固くなったというか、社内に対するプレゼンスが変化したところはありましたか？
志賀：もちろん、あります。今はもう、月に1回定例で行っていただいているアドバイザリ会議が、完全に全社的なセキュリティ活動の中に取り込まれている状態になっています。
自分たちで日々取り組んでいる中でモヤモヤしたことを、この対策会議でアジェンダとして挙げて議論させていただいて、方向性を確認する場にもなっていますし、議論するためには情報を事前に仕入れておかなければなりませんから、コミュニケーションを取るという意味でも、対策会議が重要なポイントになっています。
鈴木がやっている「開発運営会議」という週次の会議の中でも、定例議案のなかに「対策会議への相談事項は何かないか」という項目が入っているくらいです。
引地千秋（以下、引地）：運用体制側も、当然、意識が変わりました。まずはインフラの再構築に着手しましたね。構成面はもちろんですが、いかに攻撃を遮断できるか、アプライアンス製品をどううまく導入できるかというところにも、意識がいくようになりました。半年以上かかったと思いますし、今も引き続き、いろいろ取り組みはしています。
横山：インシデントが起こるまでも「品質管理」としてプロダクトのセキュリティ診断を年1回やっていて、当時としては、誤解を恐れずにいうと、「やれることはやっていた」つもりだったんですね。でもそれが、やった気になっていただけで、実際には事故があって…。技術的な面も含め、開発プロセス全体をガラッと変えるような見直しのきっかけとなりました。
例えばセキュリティ診断も、当時は年に複数回あるバージョンアップのタイミングで、リリースされた機能にフォーカスして診断をかけていました。本来であればリリース直前ではなく、開発のプロセスの中でしっかりと診断をして、脆弱性を拾っていくべきですよね。
もちろん、それまでのテストでもSQLインジェクションだとか、XSSみたいなブラックボックステストで簡単に拾えそうなものに関してはテストしていました。でも事故をきっかけに不十分さが露呈したというか、思い知らされた感じになりました。
志賀：当時はやはりまだまだ、「事後対策」をいかに厚くするか、という段階だったと思いますね。
岡田：“シフトレフト”が必要だったんですね。
横山：ほんとに、それが刺さった感じですね。
脆弱性を繰り返さない為のシフトレフトな仕組み作りはどうなっていったのか。──後編に続きます。お楽しみに。