『どこまでやればいいのよ…🥲』SaaS時代のセキュリティで悩んだので、自分なりに整理してみた

セキュリティ コンピュータ その他

最近、情報漏洩のニュースをよく目にするようになりました。

目立つのは、自社の事故ではなく、業務委託先や、契約しているクラウドサービス側で起きた事故が、自社にも影響してくるというパターンにみえます。毎月のように、どこかで何かが起きているような印象…💧

これって、世の中の事故が急に増えたというよりは、法改正や開示義務の強化で、これまで水面下にあったものが表面化してきた側面が大きいのかも。

ただ、これをセキュリティ担当の立場で捉えると大きな頭痛の種になります。

自社で直接起きた事故じゃない領域に対して、どこまで、何をすればいいんだろう？

自分は最近セキュリティ関連のこともやることになっちまった😣ので、こういった課題にずっとモヤモヤしていました。特に「業務委託」とは性質の違う「SaaSのような外部サービスの法人利用」になると、どうすればいいのか頭の中の整理がうまくつきません。

今回は、開発という内容とは少し離れたセキュリティに関しても自分に整理し、方向性を書き残してみました。これは「正解」という話ではなく、ひとつの方向性としてのメモとなります。

⚠️ 本記事の情報は2026-05時点のものです。法改正やサービス仕様の変更で前提が変わる可能性があります。また、組織規模や業態によって現実的な選択肢は大きく変わるので参考にならない業種の方もいると思います。

1. 「業務委託」と「SaaS利用」は別物

外部に関わる事故として一括りにされがちですが、実はこのふたつ、性質がかなり違います。

業務委託は、自社の業務やデータ処理を外部に委ねている関係です。委託先は委託元の指示で動いてくれる。個人情報保護法でも委託元には「必要かつ適切な監督」が求められていて、ベースの姿勢は言い方はあれかもしれませんが「相手を管理する」ことです。

SaaS利用は、研修サービスのようなeラーニングやLinkedIn Learning、各種クラウドツールを、社員が会社のメールアドレスで使っているケースです。事業者は世界中の利用者に同じサービスを提供していて、個別企業の指示で運用を変えてくれるというわけではありません。

つまり、

SaaSの場合、相手を「管理・監督する」という発想自体が、そもそも成り立たない

たとえば研修サービスを行なってくれる企業に「うちのセキュリティ基準で運用してください」とは、言えなってことです。先方もそれに応じる構造を持っていません。

⚠️業務委託の延長線で「管理」の発想で考えていると詰まってしまう印象です😅

2. 「相手を管理する」から「自社を設計する」へ発想を変える

そんな、SaaS時代のセキュリティの基本姿勢は、以下のようなものかなと思いました。

相手は管理できない前提で、自社をどう設計するか

SaaS事業者の多くは、たぶん自社よりずっと高いレベルでセキュリティを運用しています。そして、どんなに信頼できる相手でも事故は起きうるので、それが起きたときに自社が大きく崩れない構造を作っておく、と考えておくことになるのかなと。

噛み砕くと、3つの方向があるかなと。

  • 認証を一箇所にまとめる
  • 自社のデータがどこにあるかを把握する
  • 漏れる前提で、検知と対応を整える

3. 認証を一箇所にまとめる

これがいちばん効きます。SaaSの世界で、自社が確実にコントロールできる数少ないものが「社員の認証情報（誰がログインするか）」だからです。

何が問題なのか

社員が各SaaSに個別アカウントを作って、それぞれパスワードを設定している状態では、こんな感じになると思います。

  • 社員がパスワードを使い回している
  • どこかのサービスが漏洩すると、同じパスワードを使っている他のサービスも芋づる式に乗っ取られる
  • 退職した社員のアカウントが、各サービスに残ったままになる

自社のデータが外にあること以上に、自社の認証情報が無数の外部サービスに散らばっていることのほうが、リスクががあるかなと。

認証基盤を中心に据える、というのが基本

基本的な立ち位置としては、社員のログインをひとつの認証基盤に集約することなんでしょうか。

認証基盤とは、社員が会社で使うさまざまなサービスへのログインを一元的に管理してくれる仕組みのことです。たとえば、Microsoft Entra ID（旧Azure AD）、Google Workspaceあたりがあると思います。Microsoft 365やGoogle Workspaceを業務で使っている会社であれば、すでに認証基盤は入っているはずかなと。

認証基盤があれば、こんな感じの構造で運用するのかなと…

  1. 社員はまず認証基盤にログインする（パスワード＋二段階認証など）
  2. 各サービスにアクセスするときは、認証基盤経由で「この人はうちの社員です」と認証情報が渡される
  3. 退職時は認証基盤側でアカウントを止めれば、紐づくサービスが一斉に止まる

この様になっていれば、SaaS事業者で漏洩が起きても、自社社員のパスワードは漏れません（そもそもSaaS側にパスワードを預けていないため）。漏れるとしてもメールアドレスくらいで、被害が標的型フィッシングのリスト入りまでで止まる、というイメージです。

メールアドレスの漏れも、フィッシングメールの脅威があるので、困るといえば困るのですが😧

現実的な落とし所？

⚠️すべてのSaaSがこの仕組みに対応しているわけじゃないんですよね。特に中小規模の法人契約だと、上位プランにしないと使えないケースが多いかも😅

そんな中での選択肢としては、企業向けのパスワード管理サービスの全社導入かもしれません。1Password Businessが代表的でしょうか。

これがあれば、パスワードの使い回しが発生しにくくなります。被害も限定的になるので、安心感が高まります。

「対応できるサービスは認証基盤に寄せる、無理なものはパスワード管理サービスでカバーする」。このあたりが、現実的な落とし所なのかもしれません。

4. 自社のデータが、どこにあるかを把握する

次に「自社のデータが、どのサービスにどれだけ入っているか」をクリアにすることでしょうか。

何が問題なのか

意外と多くの組織で、「うちが契約しているSaaSって何があるんだっけ？」のリストすら作られていなかったりします。経理が把握しているのは「請求が来ている契約」だけで、無料プランで現場が勝手に使っているシャドーITは見えていないのかもしれません。

そういう「見えていないサービス」に、機密データが入っていたりする可能性があるわけです。議事録の自動文字起こしツールに社外秘の会議が流れていたり、翻訳サービスに顧客情報を貼り付けていたりとかとか…。

まずは棚卸し、そしてルール

最初の段階ではもっと素朴な方法を行うのが大切かなと。

棚卸し　…　契約しているサービスをリスト化する。並行して、社員アンケートで「業務で使っているサービス」を集める。両方を突き合わせると、契約しているのに使われていないもの、契約していないのに使われているものが見えてきます。

利用ルールの明文化　…　「このサービスにはこの種類のデータまで」という基準を作って共有します。

  • 研修サービスは学習目的のみ、業務データは入れない
  • 翻訳サービスに社外秘情報を入れない
  • 議事録ツールは、事前に確認したものだけを使う

明文化されているかどうかで、運用の質はまるで変わってくると思います。ルールがないと、社員は「どこまでならいいんだろう？」と不安になって、結局何もできなくなりますし。

「SaaSは便利な道具だけど、何を入れるかは自社で決める」を組織として徹底する、ということかなと感じています。

5. 漏れる前提で、検知と対応を整える

ここまでやっても、漏れるときは漏れますよね🤷‍♂️

3.と4.は被害を最小化する予防策ですが、事故をゼロすることはできないのです。

漏洩の監視

こういうのもありといえばありでしょうか。自社ドメインのメールアドレスが、漏洩データに登場していないかを継続的にチェックする仕組みを入れます。無料で使えるものとしては「Have I Been Pwned」が有名で、自社ドメイン全体の監視機能を無料で提供しています。漏洩が検知されたらメールで通知が来る仕組みです。

haveibeenpwned.com

まずはこのあたりから始めるので十分かもしれません。 というか、自分のアドレスをいれると…😣

対応手順を、事前に決めておく

「SaaS漏洩が検知された」という連絡が来たときに、何をするかを事前に決めておくことが大事ですね。事故が起きてから考え始めると、対応が遅れますし。

最低限、こんなところでしょうか。

  • 該当サービスの全社員パスワードの強制リセット
  • 同じパスワードを他で使っていないかの確認喚起
  • 漏れたメールアドレス宛にフィッシングが来る可能性を、全社通知

これを「対応手順書」としてまとめておくと、担当者が変わっても運用が継続できます。 事故対応って、その場で考えるとロクなことにならないので、平時に作っておくのがよさそう。

6. まとめると…

守るべき境界は、ネットワークから「誰がアクセスするか」に移った

従来のセキュリティは、「自社のネットワークの内側を守る」発想だったんでしょうね。 でもSaaS時代には、データは外にあって、認証は外で行われて、社員は自宅やカフェからもアクセスする。守るべき境界が、閉じたネットワークじゃなくなったわけです。

その代わりに何を境目にするか。それが「誰が、何に、どうアクセスするか」というアイデンティティの世界。最近よく聞く「ゼロトラスト」ってやつですね。

  • 「相手は管理できない」→ ネットワーク的・契約的な統制をある程度諦める
  • 「自社をどう設計するか」→ 認証、データ、検知の3つで自社側を強くする
  • 相手が崩れても自社が大きく崩れない構造を作る

これが、自分が感じている考え方なのかも。

おわりに

今回は、自分のもやもやを整理するために書いたもので、「正解」ではありません。方向性という程度なんでしょう。組織の規模や業態によって選択肢は変わります。

言えるのは「SaaSの選定を厳しくしよう」という方向だけだと、たぶん立ち行かない。企業の選定を厳しくしても、相手で事故は起きますしね。自社を事故に強い構造に作り変えていくのがいい方向かなと。

セキュリティを担当することになった方は、まず以下を自組織で調べるのがいいでしょうね。

  • うちは認証基盤を使っているかな？
  • 契約しているサービスのリストは、ちゃんとあるかな？
  • 漏洩したら、どう動くか決まっているかな？

多分、間違ったことも書いていると思いますので、ご指摘などあれば、ぜひおしえてください。