【対談】DevSecOpsの浸透において重要なのは「顧客起点」の着想である－後編

便利さに付随する危うさ

近藤　先日のイベント「DevSecOps Days Tokyo」で韮原さんが例に出していた「スマートメーターの『光と影』のケーススタディ」が個人的に非常に印象的でした。もう一度、概要を説明してもらえますか？

韮原　実例ではなく未来に起こりうるリスクイメージとして挙げましたが、家庭にスマートメーターが設置されていくと、機械学習を用いて電力使用量から家に人がいるかいないかが予測できます。そして、在宅の家だけをつないでいき配送ルートを最適化することで、物流会社は「再配達を90%なくす」ことができるといわれています。

また、これでガソリン消費量や CO2排出量も減るでしょう。素晴らしい取り組みに聞こえます。

近藤　まさに、「IoTが起点となったDX」とも言えますね。

韮原　ではこのユースケースを「セキュリティをソフトウェア開発のあらゆるプロセスに埋め込む」というDevSecOpsの考え方で捉え直すと、まずシステムを企画する段階で、家に人がいるかいないか外部から判別できるということは、「便利に感じる」という半面、「実は恐ろしいリスクである」ということが明らかになります。

確実に不在であるとわかれば、窃盗被害が起こり得ますし、確実に家に居るのであれば、レイプ被害や要人ならば暗殺等の脅威が増します。

「これはネガティブすぎるだろ」「そんな情報は出回らないはず」と思っても、そうとも言い切れません。このサービスの商用化には、多くの企業が関与することになります。スマートメーターの機器会社、インターネット回線を引く通信会社、契約している電力会社、宅配業者、在/不在の判別モデルを作るAI開発企業、システム化するSI企業とその下請企業など、サプライチェーン上にいろいろなプレーヤーがいますので、そのどこか一社からでもデータが漏れるだけで大事になりえます。宅配業者のドライバーがどこかに落とした携帯端末からでも、自身が身の危険にさらされるかもしれません。

近藤　スマートメーターを例に出しましたが、どの領域の新サービスにも言えることですね。「このようなリスクばかり考えてたら何もできない」と、一方でビジネス企画者からの悲鳴も聞こえてきそうですが・・・（笑）

韮原 　これは否定的な事を評論的に述べたいわけではなく、まさに「Security by Design（セキュリティ・バイ・デザイン）」の着想が大事だということが伝えたい意図なんです。「作ったものを守る」という「受け身の守り」ではなく、「あらかじめ攻撃可能性を考えたサービス設計」をビジネス企画人材も企画段階から意識してデザインしてリスク回避策を講じるという仕掛けが大事だということです。DevSecOps自体は、DevOpsの流れを汲んだソフトウェア開発と運用の徹底した自動化とそこへのセキュリティの埋め込みが主な内容ですが、ここでは企画の時点からセキュリティを考える必要性を、DevSecOpsの概念で説明してみました。

セキュリティの脅威を、どうビジネス判断するか

近藤　「攻撃可能性を考慮したサービス設計」をする事業企画意識。確かにそのとおりですね。

サービス提供者として「Security by Design」の意識、すなわち「ベネフィットとリスクの包含」した考えからビジネスデザインをしていく必要ということですね。

韮原　そうです。セキュリティもそうですし、あとは「プライバシー」も同様な考え方ですよね。

「自分はビジネス側の企画者だし、システム（テクノロジー）のことは一切知らない」では済まないのが今のご時世だと思います。セキュリティ、プライバシーもクリアできていないビジネス企画は、これからはお客様にも受け入れられないということです。

そう思うビジネス企画者が「なぜ」あまりいないのかというとただ「知らないだけ」なんだと思います。

中には「面倒くさいから考えない」という人たちもいるかもしれませんが、ほとんどの方はこうしてお話すると重要性を理解していただけます。まずは「知ること」が大事だと思います。全て熟知していなければ企画できないということでもなく、重要性を理解した上で走りながら考える、ということでよ良いと思います。

近藤　たしかに、サービスを通じて持続可能な社会を作っていく中で、「A社がやったことだから」「開発部門が配慮していなかったから」という他人事では済まなくなって、ビジネスとテクノロジーが連鎖・一体化する時代になっていますよね。自分が取り巻くビジネスにおいては、当事者として機能領域に向き合う姿勢、まさしく「自分ゴト化」がDevSecOpsの基礎マインドになるイメージだということがわかりました。

韮原　基礎マインドであり、「基礎知識であり基礎リテラシー」ですね。

欧米での議論を見ていても、テクノロジーそのものの議論はありつつも、この新しい必要性に、「どう組織が対応していくべきか」に関しては、実はまだ「最適解」には至っていないように感じますね。

たとえば、

• 1週間後のサービスリリース目前に、重大なセキュリティリスクが見つかった
• その対策を施すことにより、サービスリリースは1カ月後になってしまう
• セキュリティチームは「この基準ではリリースできない」と言う
• ビジネスチームは「この1ヶ月の遅延は競合に先を越される」と言う

そのときに、誰がどういう判断をするか？

セキュリティ脅威とビジネス機会といったトレードオフに対して、どう判断するのか。「玉虫色」な解決策が必要になることもあります。つまり、どちらを取るにもリスクがあるのはわかっていて妥協した判断を迫られることがあるということです。

極論ですが、サイバー脅威を気にしすぎて「何も開発しなければ」、リスクはゼロで一番安全ですが、あらゆるものが遅くなり、ビジネス勝機を逃した、ユーザーが離れた、会社が潰れた、となると、それは「セキュリティ云々以前」の課題に直面しますよね。

・セキュリティを担保する人
・売上を担保する人

このバランスが重要なのです。
バランスをとった企画立案、経営の意思決定が一番難しいところ。
セキュリティリスクを言い出して、1000個ある課題の全部を潰すことはできないです。

どこかで、玉虫色的な解決をしなければならない。欧米の先進企業が苦労しているところは、もともと白黒はっきりさせたい一神教的な文化の上で、こうした玉虫色な解決策しか打てないところからくる部分が大きいように見ています。

欧米文化は正解か不正解かを判断するような「二項対立」的な状況への対策は得意ですが、なんともはっきりしない「玉虫色的な解決」に対しては価値観的に戸惑っているように見えますね。

でも、日本って「玉虫色的な解決」得意じゃないですか？（笑）
なので、難易度は高いものの、この問題に対しては、「日本人らしい進め方」ができそうだなと、ある種の楽観的な期待はありますね。

DevSecOpsでのセキュリティ責任者は、「ゲートキーパー」ではなく「ガードレール」に

近藤　これを解決するための「組織論」が叫ばれそうですね。
でも、これはCISO（最高情報セキュリティ責任者）の要職範囲が拡大されることで解決する問題でもなさそうですよね。いまのCISOはバックオフィス的ポジションな印象なので。

「リスクがあるまま進めるなら、じゃあCEOが会社として責任を取ってください」のようなセキュリティリスクを評論家的に述べる人がいたところで、欧米企業で起きている戸惑いと同様なことが日本にも陥りそうな気がしているのですが、どうでしょうか？

韮原　アメリカではCISOをはじめとしたセキュリティ部門の役割は、伝統的には「ゲートキーパー」でした。「これをクリアしないと次に通せないよ」と言う門番としての存在です。ただ、そうなるとセキュリティ部門が足かせで、事業責任者やエンジニアチームが、出したいサービスが出せない、また使いたい技術が使えず疎まれる存在になります。

そうした状況に、アメリカの某有名テクノロジー企業のセキュリティマネージャーが言っていたのは、「もうゲートキーパーはやめ、ガードレールになろう」ということです。

ゲートキーパーだとゲートを守ることに終始し、社内で邪魔者扱いにもなりますし、またセキュリティを気にし過ぎて何もできずに、会社が潰れては元も子もない。ビジネスが高速に走るのを妨げず、されどしっかり事故だけは防ぐ「ガードレール」になろうと。

近藤　「ガードレール型CISO」の存在、いいですね！

韮原　そのために、セキュリティチームと開発チームが仲良くなる必要もあります。結局、組織の問題なんですよね。DXでも語られる課題の第一歩は組織問題が多いじゃないですか。そんな第一歩として、セキュリティチームのTシャツを作った、開発チームにスナックを配ったとか、そんなかわいげな話をアメリカでのカンファレンスで聞きました（笑）

近藤　DXもDevSecOpsも、「組織が一枚岩」にどうなっていくのかが大事ですね。
同じ目標・目的を持たずして、一枚岩の意義なしですから。

韮原　まさしく。「なんのために一枚岩になるのか」。
これは至極当然で、「お客様のため」に設定するものだと思います。セキュリティが突破されて会社も困るけど、一番困るのはお客様でしょう。お客様のために「便利さと脅威を防ぐ」両輪のサービス設計を、開発チームも運用チームもセキュリティチームも一体となって進めていく。DevSecOpsもCRMの一環としてやっていくことが重要です。

CRMの一環で、UI機能追加のデザインもするし、Security by Designもするし、DevSecOpsのセキュリティの塩梅も決める。「顧客起点」で多岐に渡る要件を考えるということです。顧客をよそにやって、それぞれのチームが保身に走ると、組織がガタつきます。

近藤　ガードレールをビジネス目線で敷くことができる人の存在は今後重要性を増すということが確定ですね。DXにおいて重要視される「攻めのITを考える人」の必須要件として「ビジネス設計とDevSecOpsの両面」を見ることになるのだと感じました。そのビジネスとIT接着点にDevSecOpsがありそうですね。

韮原　DevSecOpsだけだと、ITの中の話に捉えられがちなんですけど、DXは、お客様にとってよりよいサービスをビジネスとデジタル（IT）をどう巧く使いながらやるのかというものです。よって、当然ながらビジネスとITの「距離」も近くなる必要があります。その際、リードを誰がとるのか？ビジネス側から来てもいいし、IT側から来てもいい。

これは、ビジネスとITの距離がどうあるべきかと考えなくても、お客様にとってより良いサービスを作ろうとすると、当然両者は近づく必要が生まれます。

今や、セキュアなもの、レジリエントなものを作らないとお客様の信用も失墜しかねない。 そんな時代になっているが故の求められる働き方の変化なのかもしれませんね。

DevSecOpsの浸透に向けて、明日から自分たちは何をすればいいか？

近藤　最後の質問です。
DevSecOpsの概念や考え方を理解することはできました。そんな中で、具体的な第一歩をどう踏み出すかがポイントになると思います。

今の状況や環境の中で「明日から何をしたらいい？」と担当する顧客に聞かれたら、どのようなアイデアを出しますか？

韮原　冗談抜きにして、とりあえず「ホワイトハッカー」（※）を雇って、自社のシステムをハッキングしてもらうことでしょうか。

環境を預けて、攻撃してもらって、そこから問題点をあぶりだす。数週間から1か月もあれば十分でしょう。

サイバーセキュリティ監査というものはありますが、それはあくまで外部の基準に沿ってどうか、インタビューを中心に行うものがほとんどです。しかし、これは実際に狙われたときにどれだけ脆弱性のあるソースコードが眠っているかを明らかにすることはできません。

いきなりハッカーに狙われてみたら「どこまで影響が出るのかを知ること」が大事だと思います。

Netflixなどが取り入れたことで有名になった「カオスエンジニアリング」のように、本番稼働しているシステムに障害を与えてシステムを壊し、壊すとどうなるか、そこからどのように解決するかという考え方とも似ていると思います。日本の会社もホワイトな人に攻撃してもらったらいい。そこからですかね。

（※）サイバー犯罪を起こす「ブラックハッカー」に対する言葉で、倫理感を持ってハッキング技術を防衛のために用いるハッカーのことを指します。行政機関や民間企業から依頼を受け、ブラックハッカーによるサイバー攻撃を阻止し、コンピュータやネットワークを守ります。

近藤　なるほど。面白いですね。
ホワイトハッカーというのがポイントですよね。攻めさせてみて、ITだけの観点ではなく、ビジネス的な観点でも「ここまで影響が及ぼされる状況だったのか」を知ることができる。

韮原　頭ではわかってる事が本当に起こりうるのだということを現実に見るということですよね。たとえば、社員がうっかりメールをクリックしただけで、顧客情報が何万件流出する事態にまで発展する…ということも、経営者が分かるわけです。

本来そうしたリスクがあるものを「セキュリティ監査」で片付けがちですが、それでは本当の問題点は出てきづらいです。

今後デジタル化を進めていく中での実務的な被害・危険を経営側も当事者として見てみて、「そういう危険もあるんだ」ということを知る。知ることができれば、経営者はアクション出来ると思います。

近藤　今回の対談、多くの気付きがありました。DXを推進する方々がこのテーマに関心を持ち、社内で議論が交わされることのきっかけ作りになれたらいいですね。

顧客のDX推進されている方を交えて、また改めてこうした議論ができたらと思います。

本日はありがとうございました。

あとがき

サービスを提供する企業側の人としても、サービスを受ける側の人としても、常に自分ゴト化して「万が一」を考えることが、DevSecOpsを理解することに繋がります。

DXは、ビジネスとITが両輪となり最終的にはお客様にとってより良いベネフィットを提供していくものです。お客様にとっていいサービスとは何かを考えると、便利さや真新しいサービスを作ることも大事ですが、セキュアなサービスを作ることも同じく大事です。「昨今はサイバー脅威が増えているからセキュリティを強化しよう」ではなく、顧客起点で考えることによって、DevSecOpsはその必要性が増し、解像度が高くなってくるのではないでしょうか。

顧客のために組織が一枚岩となるのがDXの成功要因の一つであり、一枚岩になるための要素のひとつがDevSecOpsであることも、いい気付きでした。

「ガードレールのある道路で車を走らせる」―そんなDXが今後増えていくことに期待して、本記事の締めくくりにしたいと思います。

お話を伺った方

▼DevSecOpsに関しては下記連載もおすすめです。
連載：DXにおけるDevSecOpsとは？

「DevSecOps Days Tokyo」レポート①：「米・国防総省はどのようにしてKubernatesとIstioへの移行を果たしたか？
「DevSecOps Days Tokyo」レポート②：「DevSecOpsの導入を成功させるための5つのチャレンジ」
「DevSecOps Days Tokyo」レポート③（前編）：「AI/機械学習のサイバー脅威と、日本流DevSecOpsの導入方法」
「DevSecOps Days Tokyo」レポート③（後編）：「AI/機械学習のサイバー脅威と、日本流DevSecOpsの導入方法」
「DevSecOps Days Tokyo」レポート④：「AI/アナリティクス サービス企業でのDevSecOps：これまでとこれから」