不正アクセス急増は“SaaS離れ”を招くか？ 露呈したもう1つの「SaaS is Dead」リスク

　相次ぐ不正アクセスと情報漏えい。いわゆる社内システムへの攻撃も目立つ一方、SaaS企業が提供する外部サービスが攻撃された結果、ユーザー企業の情報が漏えいする事案も少なくない。例えばLINEヤフーやパナソニック、スズキはコミュニティープラットフォームの「Commune」、ラクスルや東北電力はノーコードWeb制作プラットフォーム「Studio」に対する不正アクセスの影響を受けている。

　これに伴い、SNSなどでは「SaaS is Dead」を巡る議論が再燃しつつある。SaaS is Deadとは、自律的にタスクをこなしたり、ツールを生成したりできる「AIエージェント」が普及・発展することで、AIがSaaSの需要を置き換え、SaaSビジネスが限界を迎える──という見方のことだ。

　ただ、今回の議論は少し毛色が違う。SaaS経由での漏えいが相次ぐ中で「外部ツールに重要なデータを預けること」の必要性が改めて問われているのだ。一連のサイバー攻撃にAIが悪用されている可能性も示唆されていることも踏まえると、AIが発端なことには変わりはないものの、切り口がビジネスモデルからセキュリティに移り変わっている……という格好だろう。

　ただしセキュリティ企業・ラックの倉持浩明取締役上席執行役員CTOは「現状、セキュリティを原因としたSaaS離れのような声は聴いていない」と話す。そもそも事態は「SaaSをやめれば安全」という単純な話ではない、というのが倉持さんの見方だ。

　仮にSaaSの利用をやめた場合、移転先は自社のオンプレミスサーバや自社クラウドなどになるが「結局、ユーザー側としては、SaaSだろうがオンプレミスだろうが、最終的な責任はユーザー自身にある。SaaSをやめて自社開発に戻せば安全、というのは適切ではない」と倉持さんは指摘する。

　「結局は委託するSaaS企業のセキュリティ能力や、自社で運用できる可能性も踏まえてどちらにするか選択していく必要がある。脆弱性対応やバックアップ、ハードウェア故障時の復旧を運用できるのであれば（自社運用でも）問題ないが、多くの企業がSaaSベンダーに任せたほうがいいという判断でこれまでやってきた実態がある」とし、そもそも自社運用に戻せる組織が多くないのではないか、という見方を示す。

　ただ、SaaSベンダーへの要求自体はより高度になるかもしれない。「SaaSベンダー側もこれまでセキュリティ対策をやってきたと思うが、企業の方の選別も進んでくると思う。ただ有名だから、コストが安いからではなく、何かあった時にログをどれくらいの期間さかのぼって提供してもらえるか、どの程度情報開示がされるか、透明性や追跡性をより求められるようになるのでは」（倉持さん）

　ベンダー側、特に経営層においては、セキュリティ向上のためサービスを一時的に止める覚悟が必要になるとも説く。金融庁が5月に公開した「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応に係る要請」には「優先的に対応すべきサービス／ITシステムを能動的に停止させざるを得ない場合についても経営トップはあらかじめ選択肢として検討しておくべき」との記載がある。倉持さんは、金融以外のSaaSでも同様に、能動的なサービス停止を覚悟すべきという考えを示す。

　「SLAもあるだろうが、自分たちが使っているソフトウェアに重大な脆弱性が公表されたとき、一定期間サービスを緊急で停止してパッチを当てる対応を意識すべき」

　もちろん、セキュリティの見直しも必要だ。一連の攻撃について「コストや時間などの都合で専門家によるテストを行えていなかったり、後回しになっていたりするシステムもあると思うが、今回の攻撃はそういった対象を見逃してくれていない。対策ができていない箇所がないか、総点検すべき」

　ユーザー企業も、手をこまねいているだけではいけない。「なかなか利用を中断する判断は難しいと思うが、不必要な情報まで持ち続けていないかを含め、使っているSaaSで漏えいが起きたとき、いったいどんな情報が漏えいすることになるか、再確認しておくべき」と倉持さん。パッチ対応によるサービス停止についても「事業者（ユーザー）側も一定程度許容しなくてはいけない」と説く。

　一連の攻撃が、即座にSaaS離れにつながる……とするのは早計だろう。ただ、攻撃は長期化する可能性もあると倉持さん。ユーザーからベンダーへの要求が厳しくなったり、より透明性を求められたりという形での影響は、今後起こり得るかもしれない。