インサイドセールス トレイル003

SaaS利用時のセキュリティチェック(3)

前々回から「他社サービスを利用する」サービスを立ち上げるにあたり、他社サービスを利用する部分のセキュリティ品質を「クラウドセキュリティチェックリスト【利用編】」でチェックしています。

前回のイテレーションでは、品質監理部門とクラウド事業者それぞれに対し、セキュリティ対策の方針を すり合わせました。 本スプリントでは、いよいよすり合わせた内容をもとにセキュリティチェックリストを詳細に確認しつつ 本サービスのセキュリティ対策を検討し、審査申請を行います。

クラウド利用時のセキュリティ対策

SaaS利用時のセキュリティ対策は、全て自社で構築するサービスのセキュリティ対策と以下の点で異なります。

  • 互いの保有することになる情報資産を明確にしなければ、SaaS利用にどのようなリスクが生じるのかが判断できない
  • 自分たちの「技術」で対策を打てる範囲が限られる
  • 互いの責任を明確にしなければ、両者の間でどのようなセキュリティをどちらが担保するのかという境界線が曖昧になる

これらは必ずしも”技術に閉じた”エンジニアリングだけで解消されることではなく、以下のようなことまで理解しなければ解決しません。

  • 立ち上げようとする新規事業の業務知識
  • 扱う情報資産の価値
  • SaaS事業者の利用規約・事業者との契約内容
  • SaaS事業者のとるセキュリティ対策
  • 場合によってはSaaSのアーキテクチャ

このため、SaaS利用におけるセキュリティ対策を詳細に検討する上では、新規事業の業務内容を改めて確認するとともに、SaaSの利用規約、結ぼうとしている契約書(覚書)にすべて目を通しました。 その上で、チェックリストと上記の理解を照らし合わせてリスクを分析し、妥当な対応を一件一件検討します。

抽象論だけだと実施したことが伝わりづらいため、具体的な対応例を挙げます。

  1. SaaSの目的外利用の防止
    • SaaSに預ける情報資産を不正利用されると、サービスのレピュテーションに大きな影響があるとともに、何よりサービスの顧客に被害が出てしまいます。対象となるSaaSを利用するのは自社の要員だけではないこともあり、事業オーナーと議論し、利用者に対する覚書に不正利用防止の旨を追加することにしました
  2. マルチテナント型SaaSに対するネットワーク分離要件の遵守見送り
    • マルチテナント型クラウドサービスを利用する場合、クラウドセキュリティチェックリストの推奨はネットワーク分離が原則になります。本事業でSaaSに預ける情報資産は必ずしもネットワーク分離で守らずともセキュリティリスクは小さいことから、ネットワーク分離をせずとも許容できると判断しました
  3. SaaS事業者への脆弱性チェック運用
    • 事業として定めたセキュリティ要件をベースに、アプリケーション脆弱性に対する運用への希望をSaaS事業者に伝え、運用に取り込んでいただきました

上記のような検討をチェック項目全件に対して行い、現時点で対応が難しい項目については、その理由と対応方針・期限を記載した上で、セキュリティ監査部門への審査申請を行いました。 最終的に本セキュリティ対策は審査を追加し、クラウド利用におけるセキュリティ対策として組織に認められました。

今回のイテレーションでの学び

SaaS利用におけるクラウドセキュリティに向き合って学んだのは、セキュリティは技術だけで解決するものではない、ということです。

これまで私たちはエンジニアとして、SQLインジェクションやCSRFなどの技術的な脆弱性の知識をもとに、技術を用いてセキュリティ品質をどう作り込むかに意識を向けてきました。しかし今回の取り組みを振り返ると、我々には以下が必要とされました。

  • サービスは業務上でどのような情報資産を持ち、どの情報資産をSaaS事業者に渡すのか
  • SaaS事業者に情報資産を渡した時、どこまでが自社の責任で、どこまでがSaaS事業者の責任になるのか
  • それぞれの責任に対して、両者がそれぞれどう対策をとるのか

これは技術的なことに目を向けているだけでは解決せず、サービス内容を理解し、SaaS事業者との契約内容やその利用規約を理解しなければなりません。必要があれば、SaaS事業者と調整しながらお互いの品質向上に資する運用を立てつけることも求められます。

会社が大きくなればなるほど扱う領域が縦割りとなり、我々エンジニアは「技術」のことだけ見ていれば良いというマインドになりがちです。 しかし、セキュリティは技術だけでは担保できません。特に少人数で進む新規事業開発においては、事業オーナーやそのほかのステークホルダと協力しながら、エンジニアも業務や法律、規約といったところまで踏み込む必要があるのだと再確認しました。