デジタルトランスフォーメーション(DX)による開発の迅速化と、アプリケーションセキュリティとのギャップ
企業のデジタル化へのシフトは一気に加速している。単にショップで販売していた商材をネットの流通に乗せるというだけに留まらず、デジタルネイティブ世代の興味や体験を向上させるための仕掛けとして、新技術をふんだんに活用した挑戦に進化している。
DX時代におけるセキュリティのスピード感
圧倒的な利用者1st時代であり、利用者の選択肢の多さを考えれば、次々と新機能や新サービスをリリースし続け、フィードバックループを形成しなければサービスは利用され続けることができない。
そのため、新機能のリリース頻度は必然的に上昇する。顧客の期待を超え続けるため、リリースを100回/日の頻度で実現させている企業も存在するという。この頻度を達成するためにはあらゆる無駄を省いたリリースプロセスの自動化が欠かせない。デジタル化し利用者に向き合い、迅速化を志向する企業は、開発プロセス、デプロイやデリバリーを迅速化させなければならないからだ。しかも継続的に。
そして大抵、この取り組みは伝統的なセキュリティチェックと衝突する。セキュリティが担保されて初めてのユーザ体験の向上であることは明らかであり、そこから目を背けるプロダクトマネージャは10年前ならいざ知らず、現在ではほぼ存在しないと言っていいだろう。にもかかわらず、伝統的なセキュリティチェックはデジタル化され迅速化された継続的な開発に追い付けておらず、間に合っていない。そのため、競争にさらされたプロダクトマネージャは、基本的なセキュリティチェックすら行わずにインターネットにさらされる新サービスを、受容する状況が生まれている。それが適切ではないと感じながら。
また、開発者は迅速化に対応しながらも、セキュリティチェックがまだまだ自分達からほど遠い場所で行われていると感じており、また同様に組織から充分なセキュア開発の教育機会を与えられていないと感じている。
これらGAPを乗り越え、安全安心なベースラインを確保しながら、劇的なユーザ体験の向上を獲得していかなければならない。
伝統的なセキュリティチェック
外部セキュリティベンダへの診断依頼件数は急増しており、またシステムの規模や数も増大する中で診断対象の幅(IoT機器やスマートフォンアプリケーション等)も広がっているため、全体を俯瞰した安全性確認を行おうとすると、ベンダ側のケイパビリティにも依存するが、調整コストは高まる傾向にある。新規依頼に対しては、日程調整だけでそれなりの時間がかかってしまう場合もあるのではないだろうか。
また、余談で定性的な話だが、折角外部の専門家に自社のセキュリティを委ねるべく外部流出コストをかけるなら「思い」が通じる相手を選びたい。自分達が圧倒的な利用者1stでありたいと思いながら心血を注いだシステムを、言葉は悪いが単なるIPアドレスやHTTPプロトコルを通じた電文のやり取りとしか見ることができない「診断屋」に診てもらったとして、当該システムの真のリスク判定ができるのか、というとどうだろうか。逆に「思い」が通じる専門家は、大抵の場合リソースが逼迫している。
外部セキュリティベンダーへの診断依頼、様々な視点を入れるためにも同一システムの診断ついてには隔年でベンダーを入れ替えるといった施策があり、それ自体を否定するものではないが、同様に調整コストは高まり、また、日程の融通もしにくくなりがちである。逆にお抱えの専門医といったイメージで、長期契約で専門家のリソースを抑えるという考え方もある。DX時代にどちらがより目的を達成できるのか、という点は考慮の余地があるだろう。
さて、ここに至っては、セキュリティの担保を可能な範囲で内部に取り込む方向を模索すべきであろう。思いの通じる専門家に診てもらえるなら越したことがないが、そこに固執すると迅速さが失われてしまう場合もある。内部での取り組みと、外部の専門家の視点を取り入れながら、いかにして安全で迅速な新機能の投入を実現させ、ユーザを感動させ続けられるかを考えていかなければならない。
DevSecOps
そのような状況の中で、迅速化された開発プロセスの中にセキュリティ施策を取り込もうとする概念が登場している。言葉自体に目新しさは既になく、いかに自動的な開発プロセスに安全性を組み込めるか、手戻りを低減させ安全なコードのみがリポジトリにコミットされる状況を作れるか、といった理想へのアクトと言っていいだろう。
しかし、この理想への到達はまだ道半ばだと感じている。
現実的には未だ自動化でのセキュリティ担保は完全には難しい。SQLインジェクションやXSSといったレイヤのアプリケーション脆弱性は、自動化施策(アプリケーションセキュリティテスティングツールによる脆弱性の検出)にて根絶できる可能性があるし、これら脆弱性の与える影響は馬鹿にできるものではない。それだけでも恩恵があると考えるべきだが、脅威はそれだけではなく、要件定義や設計段階から考慮すべき脅威とその対策があり、現在のセキュリティツールでは検出しにくい脆弱性が存在するのも事実である。
IoTの勃興により「セキュリティ・バイ・デザイン」というワードが提唱され、基本原則として謳われているが、それはIoT機器の実世界に与える影響の大きさや、後からパッチをあてることの難しさ、そもそも機器の開発に携わる開発者がインターネットの世界が連綿と築いてきた、インターネットフェイシングにおけるセキュリティのベストプラクティスに不慣れであろうこと、などを考慮してのことであると考える。
ただし、何もその原則はIoTにだけ当てはまるものではなく、普遍的に常にそうあるべきである。特に、DXを志向する事業部門は、これまでのシステムインテグレーションでは物足りないと感じ、ユーザ体験の向上のための速度感や操作性/デザイン性の表現に特化した、新しい開発ベンダとタッグを組むこともあるだろう。そこでは同様に、インターネット業界が長年培ってきた、アプリケーションセキュリティのベストプラクティスに通じているかどうかを見定め、必要に応じたセキュア開発の教育やガイドラインの順守等を確認する必要がある。
速度感を求め、複数のAppSecテスティングツールを稼働させられたとしても、それだけでは担保しきれない問題が現時点では残されている。
更に、自動化が進むと新しい課題も出てくる。複数のスキャンツールが高い頻度で回れば、大量のSeverityの異なる脆弱性情報が日々蓄積され、開発側がトリアージに対応できない、といったことも想定できる。
上記のように、セキュリティ担保の自動化への組み込みは未だ解決すべき課題が多いのも事実である。「セキュリティ・バイ・デザイン」最初からセキュリティを考えるという思想は、何もここ最近出てきたものではない。価値を得るために新しい技術やアーキテクチャを採用したり、新しい開発ベンダを登用しているのであり、そうであるからには相応のリスクをはらむのは当然と考えるべきだ。組織に充分セキュアな能力が備わるまでは、もどかしいかもしれないが一歩踏みとどまって安全性の確認もしていきたい。
最後に
ゴールは一つである。いかにして迅速にセキュアでセーフティな新しい価値をユーザに届け、事業として勝ち抜いていけるか。
その為に、開発サイドもセキュリティツールベンダも努力を続けており、脅威モデルの自動生成を行うツールや、IAST/RASPといった国内での浸透はこれからのツール群も登場しつつあれば、DevSecOpsのどこにそれを組み込むべきか、といった議論も盛んになっている。
不断の取り組みによってゴールを目指しながら、ニッポンの企業が笑顔になれるように、業界をあげて努力していきたい。
