AIやIoTなど、先端IT技術を活用した新たなサービスやプロダクトがどんどん生み出され、イノベーションが加速するこの時代、最も大変なチャレンジを求められているのは、実は情報システム部門なのではないでしょうか？
「エンジニアに自由を与えたいけど、セキュリティやガバナンス面での制約が…」と悩むパーソルホールディングス 情報セキュリティ部 サイバーセキュリティ室長の持田広志が、月間のサービス利用者数1200万人を超えるメルカリのCSO 伊藤彰嗣氏とInformation Security Officerの江口詩織氏に、情報システム基準などについて聞いてみました。
エンジニアの開発環境とセキュリティのバランスは？
持田：新しくエンジニアの開発環境を強化し、新規事業を進めていく上で、その開発環境とセキュリティ対応について伺います。メルカリでは、バックオフィスや営業とエンジニアで社内のネットワーク環境を分けているのでしょうか？
▲パーソルホールディングス株式会社 情報セキュリティ部 サイバーセキュリティ室長 持田広志
伊藤：お客様対応など、非常に重要度の高い業務のネットワークと開発者、バックオフィスの人が協働するネットワークと大きく2つのセグメントを分けて構築しています。
▲株式会社メルカリ CSO 伊藤 彰嗣氏
持田：端末の管理についてはいかがでしょう。エンジニアはMacを使ったりすると思うのですが、管理やセキュリティ、監視はどうしているのでしょうか。
伊藤：メルカリがどうありたいか、メルカリのサービスでどう働きたいのか、長期戦略を立てて、整備をしています。CIOの長谷川と協力して、コーポレートネットワークに接続される会社が支給する端末に関してはすべて管理できるよう、システムインフラストラクチャを整備しているところです。EDR（Endpoint Detection and Response）を導入したり、認証基盤を今まで以上に統一した認証基盤にしたりすることで、管理をスムーズにできるよう、現在進行形で強めていく活動をしています。
持田：BYODは導入されていないのでしょうか。
伊藤：私用端末の利用は一部ありますが、重要業務には使えないようになっています。MDMのソリューションを入れて私用のスマートフォンを管理しています。Androidであれば、MDMの他にサンドボックス環境でアプリケーションを使うよう周知徹底しています。iPhoneに関してはMDM経由で構成ファイルを配布して、その設定通りにメルカリが推奨するアプリケーションについてはコントロールしています。
持田：リモートワークをする際はどのように端末のコントロールをしているのでしょうか。
伊藤：現時点でのメルカリは集まって作業することを重要視しており、リモートワークを積極的に導入するという状況にはありません。仮にリモートワークする場合でも、上司がそれを把握し、メンバーもそれを把握した上で行ってもらいます。
例えばテレビ会議に参加できる状態を作る、12時～16時のコアタイムに関しては、意思疎通できる環境を作ってくださいとお願いしています。
持田：リモートワークを実現するソリューションについて教えてください。外から社内のネットワークに繋ぐときはどのようにしているのでしょう。
伊藤：端末管理のソリューションを導入している端末から比較的緩やかに使えるようにしています。具体的には業務で利用する各種サービスにアクセスしてもらっています。
メルカリには、性善説を大事にするという考え方のベースがあります。だからといって、施策を設けないというわけではありません。当社の社員は「Go Bold」「All for One」「Be Professional」という3つのバリュー体現者として活動することが求められるので、それに反しないことを前提に許容をしているのです。
もし、それに反した活動をするメンバーが増えてきたり、メルカリ自身の成長段階によっても、考え方は変わると思います。先ほど紹介した認証基盤の整理やゼロトラストの環境の中で、我々従業員がどう働きたいか、それを実現できるかを今一生懸命考えているところです。将来的な世界としてはBYODになるかもしれないし、今の姿と将来の姿は一緒であるとは言えないでしょうね。
性善説に基づいた「抑止と検知」で情報を守る
持田：性善説は社員を信頼することになるが、信頼を裏切ったときの懲罰などは設けられているのでしょうか。
伊藤：我々は大枠の評価として、バリューを体現できるかという観点が設けられています。つまりバリューが体現できないような行動に起因して事故が起こると、そのときにはペナルティが発生します。
持田：評価制度に3つのバリューがあって、それに基づいて評価されていると言うことですね。バリューを強くしているんですね。
伊藤：そうですね。バリューの遂行という意味では、日本の企業の中で特に強く意識して活動をしている企業だと思います。
持田：バリューをどう体現していくかを意識していることで、性善説に立つことができるんですね。
伊藤：だから禁止というルールを作ることはしていません。抑止の考え方なんです。もちろん、抑止には限度があるので、リスクに応じてシステム統制など必要なコントロールは入れています。
例えばDLP（Data Loss Prevention）を導入していますし、今後はEDRの導入も検討をしています。将来的にはCASB（Cloud Access Security Broker）やエージェント型のDLPも業務に応じて入れていこうと考えています。リスクを評価して抑止した上で検知を重視していくというセキュリティ戦略を採っています。
持田：抑止と検知というコンセプトはセキュリティチームのメンバー、ボードメンバーだけではなく、事業部との合意はとったのでしょうか。
伊藤：経営会議は全事業部のトップが集まる会議です。その場で合意が取れているということは、事業部との合意が取れているということ。もともと私たちは検知だけで施策を講じていこうと思っていましたが、経営会議の場で「検知だけでは不足である。抑止が必要だ」という指摘を受け、それを取り込むことになったのです。
持田：抑止だと、エンジニアなど自由を求める側とガバナンスを効かせる側の間で軋轢は起こらないのでしょうか。
伊藤：銀の弾丸はないというのが結論ですね。解決するにはコミュニケーションをすること。私たちはガバナンスを効かせていく活動のチームですが、自分たちの情報資産を守る教育者であるべきだと思っています。
私がメルカリに本格的にジョインしたのは昨年10月。たしかに私たちセキュリティチームのミッションを遂行する際に、やや軋轢が出てくることは感じることはありました。許容できる範囲を超えている場合は、それをきちんと可視化してその理由を伝えています。そういうベースラインを作ることが大事だと考えています。
持田：ベースラインをガイドラインや規則など、目に見える形にして示していくということですね。
伊藤：昨年の10月から今年1月にかけて、江口ともう一人ISOのメンバーの2人で、約100本に及ぶ規程、細則、ガイドラインを作りました。特に具体的な作法に関して記述されているガイドラインについては、「これでは業務ができない」と言われたこともあります。ですが、私たちはユーザーと一緒にセキュリティを作っていく意識を大事にして、活動をしているのです。
持田：メルカリ版のISMSを作るイメージですか？
伊藤：意識しながら作っているのは事実ですね。将来的に外部から認証してもらうことを一つの目標にしています。
持田：コストという観点ではいかがでしょう。例えば情報が漏えいしたときのリスクを金額で見える化などして、投資額を決めるというようなアプローチはしていらっしゃるのでしょうか。
伊藤：システムだけではない全般的なリスクの評価の枠組みの中で、メルカリとして何のリスクが高いのかを可視化、評価するということを昨年末までに実施しました。その作業の中では、もちろんコストの概念が出てきます。
実際に資産が脅威によって侵害された結果、レピュテーションリスクもあれば金銭的リスク、場合によっては人命のリスクが生じるかもしれません。カテゴリー別にリスクを数値化して、最も高いものからシステムで統制をかける、追加のルールを入れる、物理的な施策を講じる、という3つの視点で適切にリスクの軽減を行っています。
持田：ユーザーが要望することについて、高いコストをかければできるということもあるでしょう。そういう場合はどのように判断していますか。
伊藤：コストだけで判断することはしません。そこにどのくらいのリスクがあるのか、それをどんな方法でどう軽減するのか、コストをかけた方がいいのか、他の方法があるのか。愚直に話していくことで合意を得るようにしています。
エンジニアが自由にはたらける開発できるようにすることにコストをかける
持田：では「こういうことはコストをかけてでも実現する」ということがありますか。
伊藤：エンジニアが自由に働けるようにすることに関しては、最大限コストをかけています。我々は基本的にTechカンパニーでありたいと思っていますから。エンジニアが存分に働けないIT環境の提供は筋がよくありません。
コストをかけてでも自由にするし、逆に言えば自由を奪うようなコストのかけ方は許容されないことが多いですね。私たちチームはメルカリグループの横断組織に所属しており、グループ全体のセキュリティを考え、それをサービスとして提供する役割を担っています。
どういう形であれば、事業部が守らないといけないものか。例えばメルペイであれば、他の事業部と同じではセキュリティが確保できないので、ベースラインルールと事業部特有のルールを2階建てとして提供するというように、事業部ごとの状況を見ながら、セキュリティサービスを提供しています。そして私はCSOとして、セキュリティエンジニア、インフォメーションセキュリティオフィサー（ISO）のコントローラ役を担っています。
持田：グループのセキュリティは横断組織に集約しているということですね。
伊藤：事業部ごとに求めるものも違いますし、カルチャーにそぐわないという意見をもらうこともある。苦労は多いです。最近、事業部の要望をコントロールできるよう、人材をアサインすることも検討しています。
持田：横断組織から事業部に人を出すということですね。
伊藤：アサインされたエンジニアは、アサインされたところの利益になり、かつベースラインを維持できるようにコントロールするという役割を担うのです。一方、横断組織は、事業部からフィードバックを受け、ベースラインの上げ下げを行ったり、例外の柔軟な許容を行ったりするような仕組みを考えています。
持田：どういうエンジニアが事業部にアサインされるのでしょうか。
伊藤：私たちのチームには、ISO、モニタリング、プロダクトサポート、エンジニアリングマネジャーという4つのロールがあります。モニタリングは横断組織側ですが、プロダクトサポート、ISOに関しては現場に即して動かないといけません。現場にアサインされるのは後者のロールのメンバーです。
江口：ロールは固定ではなくて、必要に応じて支援をするなど流動的です。私はもともと、入社した時は事業部にいましたが、今は横断組織で活動しながら、メルカリグループ全体のセキュリティのベースラインを引く活動をしています。
▲株式会社メルカリ Information Security Officer 江口 詩織氏
持田：事業部でセキュリティ人材を育成するということは考えていないのでしょうか。
伊藤：江口の話にもあったように、元々セキュリティチームは事業部にありました。しかし、たくさん事業が生まれ、1社以外にもセキュリティサービスを提供していかないといけない状況が生まれて、今のスキームになりました。
持田：事業部にいたときは、自由を求める側だったのが、今はガバナンスを効かせる側です。世界が変わると思うのですが、苦労はなかったですか。
江口：ミクロの世界で見るか、マクロで見るかという違いはたしかにあります。ですが、どこに属していたとしても、会社の情報資産を適切に守るためのリスクに応じたコントロールを設定するというところについては、事業部にいても、横断組織にいても変わらないと思います。
持田：横断組織と事業部にアサインされるメンバーの間で、セキュリティのベースラインの意識はすり合わせるために何か取り組みをしていますか。
伊藤：現在、メンバーは十数名と規模が大きくないので特にそういったことはしていませんが、今後、規模が大きくなると目線合わせは必要になると思います。
持田：どうやってガイドラインを作ったのでしょう。外部のフレームワークなども参考にされたのでしょうか。
江口：ISO/IEC 27001は我々がルールを作る上で、意識して参照しました。メルペイで必要となる追加コントロール部分としては、FISC（The Center for Financial Industry Information Systems）の安全対策基準などの参考にしています。
例外を許可する際には合意に至るまでの記録をとること
持田：例外で許可するケースなどもあるのでしょうか。
江口：ビジネスニーズとしてリスクを許容したいという考えがあるときは、例外の審査を上げてもらうようにしています。
持田：どういうラインで上げるのでしょうか。例外対応については経営会議にかけたりするのでしょうか。
江口：今後、詰めていくことになりますが、セキュリティ部門に上がってくる例外に関しては、まずはセキュリティ部門で例外のリスク評価を行います。
伊藤：例外を認めるときに大事なのは、説明できる状態すること。説明責任を果たせていないと、「前いいといったじゃないか」というようなことが起こりがちになりますからね。
持田：過去はこう、今回はこうでしたというようなエビデンスを出すような仕組みを設けているのでしょうか。許可の透明性に関するアドバイスをお願いします。
伊藤：記録の残し方から合意を取ることが大事だと思います。当社ではコミュニケーションツールとしてSlackを使っているが、Slackは後で編集できたり、流れたりするので、例外の許可のコミュニケーションについては、履歴としてストックできるような仕組みを用いています。
例外といってもそれぞれラインはいろいろなので、それに応じたコミュニケーションチャネルと承認の取り方、利便性と説明責任のバランスを考えることから始めなければなりません。例外を認めるプロセスを作ることも大変なことなんです。
持田：事業部が強かったり、経営陣が強かったり、営業が強かったりする中で、情報システム部門はなかなか力を持てなかったりします。どう立ち回っていけばよいのでしょう。
伊藤：我々も決して強いわけではありませんし、私自身、強くありたいと思ってもいるわけではりません。トップダウンでセキュリティを入れたいとは思っていないからです。
セキュリティが重要であるという合意がメルカリグループでとれている中で、例えばトップダウンでやるというのは、もうHowの部分でしかありません。Howの部分はどう成熟度を上げていくかという合意さえあればいいことだと思い、割り切っています。段階的にどう上げていくかということに注力して話し合いをしています。
時には心が折れることもありますし、失敗することも多々あります。ですが、失敗を楽しめなくなれば、セキュリティを担当するのはきついと思います。あとは許容できない失敗をしないよう、セーフティネットを設けておくことです。そしてそのセーフネットに穴が空いていないかどうか、確かめることですね。
持田：コミュニケーションツールとしてSlackを利用されているというお話でした。他にもSaaSを使いたいという場合、どのようなルールを設けているのでしょう。
江口：外部のサービスに我々の情報資産を置くときは委託と同義だと考えているので、委託先のセキュリティチェックが必要になります。
その際、情報の機密区分に応じたチェックを行っており、一番機密性の高い情報に関しては、高度なセキュリティチェックを、外部ベンダーのシステムに対しても実施しています。外部の診断レポートの提出を求める場合もあります。
持田：チェックプロセスは手間がかかると思いますが、何人ぐらいの方が担当されているのでしょう。
江口：法務と社内ITと我々の3部門横断で行っており、セキュリティチームでは3人で業務を担当しています。
持田：3部門に分けてチェックするとリードタイムはそれなりにかかりますよね。ユーザー側から突き上げをくらうことはないのでしょうか。
江口：クレームがくることはたしかにあります。だからこそ、情報の機密区分によって何をどこまで確認するかを明確にすることが重要だと考えています。
持田：一度審査に通ったツールは、他の部署でも使えますか。
江口：一度、審査が通ったもので、同じ機密レベルの情報しか扱わないのであれば、会社として許可したツールとして使うことができます。ただ、さらに機密性の高い情報を扱い場合など、当初の申請と差分がある場合は新たに申請が必要になります。
持田：サービスがグロースすると、機密度は高くないものの、扱う件数が多くなり資産価値が上がるものもあります。そういうものはどうやってキャッチアップしているのでしょう。
江口：情報資産の棚卸しはこれからやるべきところです。機密度合いは高くないけど、件数として多く、集合体として価値のある情報については、今後の情報管理体制を強化すると共に、情報資産の洗い出しをしっかりしていかなければならないと考えています。
「禁止」というルールは設けていない
持田：File storageなど、インターネットアクセスの制御などは行っていますか。
江口：非常に重要度の高い業務を行うメンバーは、ネットワーク的にも隔離されています。その業務エリアに関しては、ホワイトリスト形式でのネット利用となっています。つまり、業務で必要なサイトにしかアクセスできません。
持田：ログを取っていればいいのか、もともと情報が取れないようにするのかで悩んでいます。僕個人の考えだとログが取れていればいいなと思っているが、セキュリティを考えるともう少しがちっと固めた方がいいような気もしているのですが。
江口：例えば、非常に機密性の高い情報にアクセスできる者に関しては、ログを取るだけではなく、禁止行為が行われた時にアラートが上がるような仕組みなども考えられます。つまり抑止＋検知をしっかり実行する。もちろんログの収集も必要ですが。
持田：禁止を入れなかったことに大きな意味があるのかなという感じがします。
江口：検知するためには、禁止行為の定義が必要なので、禁止行為は定義されているんです。ただ、禁止行為が無意識に守れるようにするのが、セキュリティチームとして意識していることです。
持田：重要なネットワークから、SaaSなど別テナントへのアクセス制御を行っていると思うのですが、どのようなソリューションを使っているのでしょう。
江口：重要な情報資産を扱っている部門では、でシンクライアント端末上のVDI（Virtual Desktop Infrastructure）でしか情報へアクセスできない仕組みになっています。
とはいえ、そのような環境でもSaaSを使わないといけないことがあるので、そう言う場合はもう一台PCを用意しており、ブラックリスト方式を採用し、アクセスさせたくないものには、アクセスできないようにしています。この点も他社と比べるとゆるやかであると思います。
それもどこまでやるかは社内でも議論があるところ。ガチガチにしてしまうと、利便性が下がってしまいますからね。VDIはコピーアンドペーストができないので、例えばURLのコピペができないことで、オペレーションミスが発生するなど、別のリスクが生じていたりしているんです。
持田：VDIやシンクライアントの導入の際、エンジニアからの反発は大きくなかったのでしょうか。
江口：導入時の反発はあまりありませんでしたね。ただ、先ほども言ったようにコピーアンドペーストができないという運用レベルの不満はありました。
すべてのエンジニアの端末をVDIにするのは非現実的ですし、リスクに応じたお金のかけ方ではありません。本当にここだけは守りたいというところにお金をかけるのが私たちのスタイル。個人情報や本番環境にアクセスできる人のみそう言う施策を入れて、他の人にはもう少し緩やかなものを実装しているということです。
エンジニアが自由に働けるゼロトラストの世界観を目指す
持田：100個ぐらいルールを作られたという話がありました。その中で、これは秀逸だと思うルールがあれば教えてください。
江口：完璧なルールはないと思っていますが、何もルールがない中で、ベースラインをどう引くべきかというところはなかなか良くできたかと思います。
伊藤：私が一番作ってよかったと思っているのか、セキュリティのルールを作るに当たって、どういう方向性でいくのか、最初に定めた文章です。
抑止と検知の概念、リスクに応じたセキュリティ対策を入れていくという2つの方向性を示しているんです。この文章を作ったことが一番、記憶に残っていますし、今でも困ったときに立ち返る文章として役に立っています。
持田：情報セキュリティに対する教育について教えてください。
江口：入社時研修の一部として、90分のオリエンテーションの枠を設けて、セキュリティチームによる教育を行っています。それ以外にもeラーニングの実施もしています。実は教育に関しては私たちも悩んでいるところです。
エンジニアが求められるセキュリティの知識と法務部門で必要になる知識は異なります。それらに応じた教育を実施したほうがより効果的であるため、ロールに応じたより深掘りした教育を実施したいと考えています。
持田：先ほど、ゼロトラストという言葉が出ていましたが、今後はそこに向かって進んでいくということでしょうか。
伊藤：CIOの長谷川は、ゼロトラストの環境下であるから、エンジニアは自由に働けるんだという信念を持ち、その世界観の実現を目指しています。ゼロトラストという表現の仕方、このワードは時代とともに変わるかもしれませんが。
我々セキュリティは守りのチームだと思われがちですが、事業推進できなければ価値はないと思っています。CIOと一緒に事業を推進するセキュリティの構築を目指していきたいですね。
持田：大変参考になりました。ありがとうございました。