アスタリスク・リサーチ様との「Vex」の販売代理店契約を記念して、同社社長の岡田良太郎氏とユービーセキュア社長の観堂剛太郎氏が対談を行いました！

スピードを求められるDX時代、システム開発はどうあるべきか、セキュリティ確保のためには何が必要か、そしてセキュリティベンダに求められるものは！？大真面目に？アツいトークを繰り広げていただきました！全3編でお届けします。

株式会社アスタリスク・リサーチ　代表取締役社長　岡田良太郎氏

2006年、アスタリスク・リサーチ創業。同社では、アプリケーションセキュリティ・ガバナンスにかかわるリサーチとサービスを展開。また、公益的な活動としてOWASP Japanチャプターリーダやビジネスブレークスルー大学の非常勤講師を務め技術と人材の育成に携わる。

株式会社ユービーセキュア　代表取締役社長　観堂剛太郎氏

アプリケーション開発ベンダで開発に従事し、2000年のNRIセキュア創業年度に合流。セキュアプロダクトの開発を経て、脆弱性診断やインシデント対応等のテクニカルコンサルテーションを担当。2017年7月より、ユービーセキュアの代表取締役に就任。

クラウドに移行できないレガシーシステムを捨てる理由

観堂：近年、DX（デジタルトランスフォーメーション）ということが盛んに謳われています。DXと一口に言っても、顧客中心となるビジネスモデルに組み替え、新しい価値を提供することを指している人もいれば、レガシーな資産をクラウド化することを言う人もいます。まずは後者の話からうかがいたいと思います。

岡田：たしかにここ最近、多くの企業がDXを話題にしています。しかし、なかなか進んでいない要因の一つは、「ロールモデル」がないことだと思うんです。ITの活用によりDXが成功している企業のロールモデルがいくつか見えてくると、「うちはどこから手をつけたらいいのか」「このシステムはもう捨てた方がよいかもしれない」「新しいシステムにはこんなセキュリティ対策が必要だ」ということが解ってくる。

つまりビジネス戦略をITに落とすシナリオが見えてこないから、DXがなかなか進まないのではと思います。それで、ついつい道具先行の話に陥りがちなのではないでしょうか。

例えば、「オンプレミスのシステムをクラウドに移行したいのだが、そのシステムが古すぎて持って行くこともできず、どうすればよいかアドバイスしてくれ」とかですね。

あるあるなのは、そういったシステムの開発を担当していたエンジニアが退職されている。でも、システムは動いているので、捨てる決断はしづらい。そのシステムをそのまま維持する部分が変わらない限り、手の施しようがないんですよね。クラウドに持っていくかどうかが問題ではない、という具合です。

観堂：動いていて捨てられないということは、そこに何らかの業務があり利用しているヒトがいて、ベネフィットを得ている、ということだとは思うのですが、だからといってコストをかけて思い切って再構築する気にもなれない、というところでしょうか。

岡田：セキュリティを提供していたベンダー側のエキスパートがエンドユーザーに転職した先で、そういう火柱が上がっているシステムに遭遇して、助けてほしいという相談が来ることもありました。そういう企業は、情報システム部門より当然、事業部門の方が、圧倒的に力が強いんですよね。必然性は解った、実現も任せる。だがこのシステムは変えられない、などとつらいことを言われているんですよね。

観堂：なるほど。古いブラックボックス化したシステムを、なんとかそのままクラウド環境下で稼働させることに成功したとしても、もはややりたいことが何だったのかよくわからなくなりますよね。レガシーシステムから得ている価値を見直して、捨てるか、作り変える。言葉で言うのは簡単ですが、そうはいかないと。今動いているシステムをわざわざ新しくするモチベーションもわかないし、なるべく穏便に済ませたいという気持ちもわからなくはありません。強いリーダーシップがないとなかなか動けない。

岡田：刷新するのに理由を見つけられないから、予算がつかないんですよね。そういう意味での障壁が大きい。上から抗えないレベルの意思決定でもなかったら変化できないということなんでしょう。

DXを阻む要因の一つは従来型のセキュリティ対策

観堂：残っているレガシーシステムをなんとかしたいという思いはあるけど、なかなか取り組めないというジレンマに陥っている企業は多いと思います。DXを阻む要因としてそのような技術的負債だけではなく、「セキュリティ負債」などは考えられるでしょうか。

例えば今、多くの企業がリモートワークに移行しています。そういう環境において、これまでのペリメーター（境界）で作り込んできたセキュリティ対策は時代遅れだということには気づいている。しかし、レガシーなセキュリティルールに阻まれたり、そういう仕組みを作って運用してきた人の職を奪うことはできないので、ゼロトラストモデルに移行できない。そういったセキュリティ負債はないでしょうか？

岡田：端的な例はVPNの接続認証に使うアカウントですよね。せっかくSaaSサービスを使っていても、アクセス元はその会社の社内からのゲートウェイにアクセス制限しているため、結局リモートからはVPN経由でしかそのSaaSが使えないというような仕組みになっている。リモートワークのためには、社員はもちろんですが、オフィスで働いていたビジネスパートナーの分もVPN認証アカウントを発行しなければなりません。かといって、管理者の一存でVPNのアカウントをほいほい発行するようなことができたら、セキュリティが崩壊します。そういう仕組みは勇気を持って変えなければなければならない。

観堂：クラウド(SaaS)を利用しているにもかかわらず、自宅から直接クラウドにアクセスできずに、会社経由でしかアクセスできない、といったケースはありますよね。エンタープライズニーズの認証連携や二要素認証機能をサポートしていないクラウドを利用するため、半ば仕方なくアクセス元IPアドレスを会社経由にする、といったような例は少なくないと思います。こういったものが累積して負債となり、足枷になってゆくのかもしれませんね。

脆弱性検査ができない理由とは？

岡田：システム構築の姿が変化しています。現在はクラウドサービスやサブスクリプションサービスなどを組み合わせてシステムを構築することが当たり前になりつつあります。従来のシステム開発であれば、「セキュリティの仕組みを入れないと怖いよね」という話が出来ていましたが、何らかの作りつけのものがコンポーネントとして揃っているので、具体的な仕組みの実装の議論少なくなっていくように思われます。

開発ツールの発展で、大抵のものが安全に作れるようになったこともその背景にあるとはいえ、組み合わせて構築する以上、脆弱性検査の必要性は変わりません。しかし、脆弱性検査の必要性の認識も、2極化している気がするのですが、いかがでしょう。

観堂：当社が開発している脆弱性検査ツール「Vex」の売り上げはコンスタントに伸びており、利用ユーザ数も増加していますので、検査する企業は増えていると思います。ただし、確かに岡田さんがおっしゃるように脆弱性検査をする企業、しない企業があります。しかし、脆弱性検査は「必要ない」と考えている企業はなく、やりたくてもやれないのだと思います。

岡田：やりたくてもやれない理由には何があるのでしょうか？

観堂：理由の一つは、システムリリースのサイクルが短くなり、脆弱性診断ベンダー（もしくは社内の診断チーム）のリソースも十分ではないため、診断スケジュールの調整がつかず、リリースが間に合わなくなってしまうことだと考えます。リリーススケジュール優先で必要なレベルの脆弱性診断をしないままにリリースしてしまうという現実があるのだと。セキュリティのチェックが不完全で良いと思っているプロジェクトマネージャはいないと思いますが、同様にリリーススケジュールを順守することも強く求められるために、ケースによってはそうなってしまうと。

岡田：開発スピードとリリースプレッシャーは依然、大きな要因ですね。セキュリティテストへのスピードプレッシャーも大きいようです。当社が提供しているセキュリティテスト・マネージドサービスでも、5日かかる診断メニューよりも、3日しかかからないメニューが選択される傾向があります。より的確で、掘り下げられた診断レポートが出せるかどうかよりも、スピードプレッシャーが大きいんでしょうね。

観堂：より短期間の診断が好まれるんですね。

岡田：そうなんです。テスト期間3日が5日になるからといって、お客様サイドの労力が1.5倍になるわけではありません。当社のサービスは年間契約なので、本来、どちらのサービスを使っても負担は変わらないんですけどね。

観堂：通常5日でやるものを3日で行うということは、どういう検査をカットしているのでしょうか。

岡田：ツールでわかることはそんなに時間がかかりませんが、例えば認証が関係するマニュアルテストなどは、3日だと追いかけられる工数がごく限られます。一度みっちりテストしたものに対する繰り返しテストには向いているかもしれないけど、リスクのあるシステムではマッチしないでしょうね。お客様が、システムのリスクに見合った的確なテストを選ぶよう、カスタマーサクセスの担当が頑張ってお勧めしています。

観堂：お客さま側からすると、インフォメーションレベルのモノまで総ざらいしてきれいにまとめたものよりも、本当に直さなければならない悪用される可能性の高い、危険度の高い脆弱性を見つけてほしい、という気持ちが、スピードを求めることによって逆になってしまう、ということでしょうか。

岡田：そうですね。私はもともとエンジニアなので、その視点からすると、より精度の高い検査をする方がよいと思うんですよ。その一方で、ちょっとうがった見方かもしれませんが、みっちりテストすることで、大幅な手戻り、ややもすれば設計から見直すような脆弱性が見つかっちゃったらどうしようという心配もあるのかもしれない。

観堂：最後の仮説はちょっと怖いですね。もしあるとすれば極端な話、利用者の安全・安心よりも、リリーススケジュール順守の方が優先度が高いという話になってしまいます。恐れるべきは、安全性が不完全なままでリリースし、結局の所利用者に見放されてしまうことです。攻撃を受けてインシデントに発展したら目も当てられません。ただ、リスクゼロを追い求めて過剰なセキュリティ対策を行い、リリースが大幅に遅延して競合とのユーザ獲得で差をつけられてしまう、ということは望む結果ではないでしょうから、バランスの取れたセキュリティ対策が求められる。そう考えると、リリース前の脆弱性診断だけでは難しくなってきますね。

スピードが求められるシステム開発に伴走するセキュリティが必要

岡田：システム開発のセキュリティ対策において重要になるのが、開発者自身がもっと早期に、実装してすぐくらいの、今チェックして欲しい！という絶妙なタイミングでテストを実施できるような環境をつくることが大事です。

先ほどの通り、QAチームが結合テストのあと、システム全体を検査することは普通だと思いますけど、万一、その段階で初めて致命的な脆弱性が見つかると大変なことになりますよね。つまりスピードが求められるシステム開発と伴走できるセキュリティ対策が必要になるのではないでしょうか。

観堂： おっしゃる通りですね。リリース前の脆弱性診断、特にそのタイミングでの第三者による外部脆弱性診断は、最後の門番でセキュリティを担保しようとするゲートウェイ型といえます。開発者はリリースの直前で、セキュリティの専門家に脆弱性のリストをいきなり渡される、いわゆるダメだしを受ける構図です。最後の最後でボコボコにされるわけで、開発者としては面白くありませんし、伴走とは程遠い状況です。

開発者には開発に専念しながら、開発のワークフローに従っていれば自然とセキュリティのチェックが入るような仕掛けが必要でしょう。

Vol.2につづく (お楽しみに！！)