※本記事は2022年2月1日にnoteにて掲載を行ったものを移管した内容になります。予めご了承ください。
こんにちは、Conoris VRM Laboです。
クラウドサービス利用時のセキュリティリスク・運用管理のプロダクトを準備中ということもあり、SaaSのセキュリティってどこまでやればいいものなんですか?という質問をよくもらいます。
セキュリティ自体は答えのないテーマですし、プロダクトの価格帯・領域や現実問題どれくらいコストがかけられるかによってもどこまでやれるかは変わりますが、ここまでやっていないと老舗大企業(東証一部の売上が1000億円以上の規模の会社)にいれるのはかなり困難という最低ラインをご紹介したいと思います。
→セキュリティチェックシートでほぼ間違いなく問われます。
特に新サービス側で未設定だが、よく聞かれることでいうと、
・災害やインシデント発生時の対応(BCP関連)
・サービス自体の終了や資本変更があった場合の取り扱いや事前通知
・解約後のデータの取り扱い
・ログの取得と開示の可否
→弊社では近い将来のISMS取得を視野にいれていることもあり、予めMFA設定するなど、わかりやすくできることはやっています。
また、これはセキュリティチェックに限った話ではないですが、気軽に開発側で強い権限をつけるのは、本当にやめたほうがいいです。
→いれていないとNGという会社をよく見かけます。
システムを運営していれば脆弱性は必ず発生します。また、発生した瞬間にパッチをあてるのは難しい場合も多いので、リスク回避のためにも導入をオススメします。
→現場が強く利用を希望している場合は、情シス側で色々と譲歩してくれたりするのですが、脆弱性診断だけはやっていないと問答無用で却下している会社をよく聞きます。
※本内容は、セキュリティチェック支援SaaSの開発を進める中で、お客様から聞く共通してここだけは守ってほしいとおっしゃることが多い点を抽出していますので、そこまで言われたことない!というSaaSベンダーの方もいらっしゃると思います。(弊社のお客様は大企業中心)
また、金融機関やインフラなどの一部の業界では業法や業界基準が存在するためこの限りではありません。
(Vertical SaaSじゃない場合は逆にいうとこの辺りをいきなり突破するのはセキュリティ対策負荷が高すぎるので、よほど資金的な余力がない限りは、腹を決めて最初から当たらないほうがいいかもしれません)
Product Led Growth型の個人向けに近い低単価SaaSや企業向けでもあまり厳しくない中小企業向けから登る場合には、そこまでチェックされないことも多いので、最初からすべてを対応しなくてもいいですが、①や②はしっかりやっておくとPマークやISMSなどの認証取得の際も楽になりますので、是非頭の片隅にいれておいていただければと思います。
顧客ターゲットに限らず、個人的には脆弱性診断もサービスリリース前後の比較的早いタイミングで必ず一度はやっておくことをオススメします。
何もせぬままサービスが伸び、シリーズAで大きな調達をした途端にサイバー攻撃の標的にされるというケースをちょくちょく目にします。
ちなみにConorisも先日脆弱性診断を受けました。
リリース前のプロダクトということもあり、人件費を除くと会社としても過去最高額の投資だったのですが(スタートアップのお財布には大きな出費、、涙)、顧客ターゲット的にやらざるを得ないという点を差し引いても、学びも多くやってよかったと思っています。
CEOが喜んでますw
このあたりは弊社CTOも色々と思うところがあるそうなので、いずれセミナーを開催したいと目論んでおります。