SaaSセキュリティとは｜利用者の責任範囲とリスク・対策の基本

SaaSセキュリティとは、SaaSで扱うデータやアカウントを守るための対策の総称で、サービスを提供する事業者と、使う側の企業が責任を分け合って進めるものです。サーバーやアプリ本体の保護は事業者が担う一方、ID・権限・設定・入力するデータの管理は利用者側の役割なので、「事業者に任せておけば安心」とは言えません。この記事では、責任共有モデルの考え方、SaaSの主なリスク、利用者側の対策、選ぶときの確認項目、ISMAP・ISMAP-LIU、個人情報保護法上の整理、導入後の点検サイクルとインシデント対応までを、ISMAPポータル、個人情報保護委員会、IPA（独立行政法人情報処理推進機構）、総務省の公開資料をもとに解説します。

目次

開く

閉じる

1. SaaSセキュリティとは｜事業者と利用者の責任範囲
2. SaaSの主なセキュリティリスクと弱点
3. 利用者側の対策｜認証・権限・アクセス・データの管理
4. SaaSを選ぶときの確認項目｜IPAの15項目と認証・評価制度
5. ISMAP・ISMAP-LIUとは｜民間企業での参考の仕方
6. SaaSと個人情報保護法｜委託とクラウド例外の考え方
7. 導入後に回したい利用者側の点検サイクル
8. インシデント発生時の対応フローを事前に決めておく
9. よくある質問(FAQ)
10. まとめ｜SaaSセキュリティで今日から行う5つのこと
11. 参考文献

SaaSセキュリティとは｜事業者と利用者の責任範囲

SaaSセキュリティとは、事業者が守る範囲（インフラ・アプリ本体）と、利用者が守る範囲（ID・権限・設定・データ）を分けて、両方で対策することです。

SaaS（Software as a Service）は、ソフトウェアをインターネット経由で利用するサービスです。自社でサーバーを用意せず、ブラウザやアプリからすぐに使えるため、会計、勤怠、顧客管理、ビジネスチャットなど、多くの業務で使われています。一方で、データはインターネット上の事業者の環境に置かれるため、「どこまでを事業者が守り、どこからを自社が守るのか」を理解しておくことが、SaaSセキュリティの出発点になります。

この考え方が、事業者と利用者が責任を分け合う「責任共有モデル」です。データセンター、ネットワーク、OS、アプリケーション本体の管理は事業者が担い、アカウント、アクセス権限、設定、そこに入れるデータの管理は利用者が担うのが基本です。IPAの「中小企業のためのクラウドサービス安全利用の手引き」も、クラウドサービスのセキュリティは、提供する事業者と利用者の両者が役割と責任を分担し、必要な対策を実施することで維持・向上できるとしています。

IaaSやPaaSと比べると、SaaSは利用者が管理する範囲がもっとも小さいクラウドの形態です。サーバーの脆弱性対応やパッチ適用を自社で行う必要はありません。ただし、範囲が小さいからといってゼロになるわけではありません。むしろ、残った範囲が「人の運用」に集中しているため、担当者の異動や退職、利用部署の増加といった日常の変化で管理が崩れやすいという特徴があります。

表は一般的な考え方を示したもので、実際の分担はサービスや契約によって異なります。総務省の「クラウドサービス利用・提供における適切な設定のためのガイドライン」（2022年10月）も、事業者と利用者の責任範囲・内容は一律に決まるものではなく、サービスの内容や利用条件によって異なるため、事業者の免責事項などで責任分界を確認する必要があるとしています。特に「アプリケーションの設定」は、事業者が用意した設定項目の範囲で利用者が選ぶ形になるため、どの設定が初期状態でどうなっているか（初期値）を把握しておくことが大切です。

利用者側が担う4つの領域

利用者側の責任範囲は、大きく次の4つに分けると社内で分担しやすくなります。

• アカウント管理：入社・異動・退職に合わせたアカウントの発行、変更、削除。共有アカウントを作らないこと。
• 認証と権限：多要素認証の有効化、パスワードの使い回し防止、必要最小限の権限付与、管理者権限を持つ人数の制限。
• データの取り扱い：どの情報をSaaSに入れてよいかの社内ルール、外部共有リンクの設定、ダウンロードや持ち出しの制限。
• 端末と利用環境：SaaSにアクセスする端末のOS更新やウイルス対策、公衆Wi-Fiなど安全でない環境からの利用ルール。

この4領域は、情報システム部門だけで完結しません。アカウント管理は人事部門との連携が必要ですし、データの取り扱いは各部署の業務ルールと重なります。IPAの「中小企業の情報セキュリティ対策ガイドライン」（第4.0版）は、経営者が認識し実施すべき指針と、社内で対策を実践する手順をまとめたものです。担当者を決め、部門をまたいで確認できる仕組みを作ることが、利用者側の責任を果たす近道です。

身近な例｜業務連絡を私用チャットで済ませていないか

利用者側の4領域は、「どのツールで業務をするか」を決めた時点から始まります。たとえば、社員が個人のスマートフォンの私用チャットで業務連絡をしていると、会社はそのアカウントを管理できません。退職者が業務のグループに残り続けていても気づきにくく、転送機能などで情報が社外に出ても、共有範囲やログを会社として確認しにくくなります。会社が許可・管理していないクラウドサービスの利用は「シャドーIT」と呼ばれ、SaaSのセキュリティで見落とされやすいリスクのひとつです。

対策の方向は、業務連絡を会社が管理できる業務用のツールにまとめ、私用ツールを業務に使わないというルールとセットで運用することです。

業務連絡を管理できるビジネスチャットに集約したい場合の一例が、株式会社kubellが提供するChatworkです。チャットのほかにビデオ通話・音声通話が標準で使え、タスクが完了すると自動でチャットに通知されます。ファイルをアップロードして、チャット参加メンバーのみで共有することもできます。公式サイトのセキュリティのページでは、通信やアップロードされたファイルの暗号化に加えて、利用者自身が設定する2段階認証や、管理者が各ユーザーの2段階認証・パスワード設定の状況を確認できる機能が案内されています。一方、フリープランでは閲覧できるのが過去40日分、5,000件までとされているため、履歴を残して使いたい場合は、プランごとの範囲を確認しておくと安心です。料金はプランによって異なるため、資料や公式サイトで確認してください。

個人のスマートフォンの私用チャットで業務連絡をしていたため、退職者がグループに残る、転送機能で機密情報が漏れるといったリスクがあったといいます。Chatworkの導入後は、私用チャットを業務に使うことを禁止し、運用ルールを見直したとのことです。

出典：Chatwork導入事例 フェイスラボ株式会社(取材：2022年6月)。取材時点の内容で、現在の機能やプランとは異なる場合があります。

SaaSの主なセキュリティリスクと弱点

SaaSの弱点は、インターネット経由で攻撃を受けやすいこと、環境を多数で共用すること、対策の全体を把握しにくいことの3点です。

SaaSのセキュリティリスクは、事業者側の問題と、利用者側の設定・運用の抜け漏れの両方から生じます。まず、SaaSという仕組みそのものが持つ特性を押さえたうえで、よくあるリスクを整理します。

SaaSの弱点は3つの特性から生じる

IPAの「中小企業のためのクラウドサービス安全利用の手引き」は、クラウドサービス固有のリスクとして、次の3点を挙げています。

• インターネットを使う：外部からの攻撃を受けやすい。
• 1台のコンピュータを多数で共用する：1台のインシデントが多数に影響する。
• 1つのサービスが複数事業者で構成される：すべての対策を把握することが難しい。

同じ手引きによると、データセンターやネットワーク回線などの設備、サーバーなどの機器、OSやアプリケーションなどのソフトウェアは、それぞれ別の事業者が運営していることがあります。そのため利用者は、サービスの機能だけでなく、サービスに付随するセキュリティ対策も確認したうえで使う必要があります。

主なリスクと、利用者側の対策

SaaSで起こりやすいリスクを、原因と利用者側の対策とあわせて整理すると次のとおりです。

設定不備は不正アクセスの主な原因のひとつ

総務省の「クラウドサービス利用・提供における適切な設定のためのガイドライン」は、クラウドサービスの設定不備による顧客の個人情報流出のおそれに至る事案が増えていると指摘しています。同ガイドラインは、IPAの「コンピュータウイルス・不正アクセスの届出状況2021年」で、不正アクセスの原因別の比率では設定不備が約17.7%で第3位だったと紹介しています。また、設定不備の背景には、利用側の理解不足や管理・作業体制の不十分さ、提供側の情報やツールの提供不足などが複雑に重なっていると整理しています。

IPAの「情報セキュリティ10大脅威 2026」の組織向け脅威でも、「サプライチェーンや委託先を狙った攻撃」が2位、「内部不正による情報漏えい等」が7位、「リモートワーク等の環境や仕組みを狙った攻撃」が8位に挙がっています。SaaSの利用は、取引先や委託先とのやり取り、社外からのアクセスと切り離せないため、自社の利用実態に当てはめて確認する必要があります。ランサムウェアなど、SaaSを狙った攻撃への備えは、SaaSのランサムウェア対策とは？被害範囲・初動対応・確認項目を解説で詳しく扱っています。

事故につながりやすい状態と、対策後の状態

設定や運用の抜け漏れが起きやすい状態と、対策後の状態を比べると次のとおりです（一般的な例であり、特定の事例ではありません）。

どのパターンも、事業者の対策がどれだけ強固でも防げない、利用者側の設定や運用に関わっている点が共通しています。逆にいえば、設定の初期値と定期的な棚卸しを押さえるだけで、防げる事故は多くあります。

利用者側の対策｜認証・権限・アクセス・データの管理

利用者側の対策の基本は、多要素認証の必須化、最小限の権限付与、外部共有とアクセスの制限、バックアップの4つを、入退社の手続きと一体で運用することです。

「SaaSのアクセス管理」や「SaaSの権限管理」と呼ばれる作業は、突き詰めると、誰が・どの端末から・どの情報に触れられるかを決めて、人の入れ替わりに合わせて更新し続けることです。ここでは、4つに分けて見ていきます。

認証を固める｜多要素認証・パスワード・SSO

IPAの手引きは、利用者の認証を厳格に行う例として、破られにくいパスワードを使うこと、IDとパスワードを共有しないこと、サービスが提供していれば2段階認証や電子証明書を使うことを挙げています。多要素認証は、記憶・所持・生体情報などの複数の要素を組み合わせる認証方式で、パスワードが漏れてもログインされにくくなります。

利用するSaaSが増えると、サービスごとに認証の強さがばらつきます。シングルサインオン（SSO）は、1回の認証で複数のSaaSを使えるようにする仕組みで、認証の一元管理やパスワードの管理負担の軽減に役立ちます。ただし、SSOに対応しているか、どのプランで使えるかは、サービスごとに異なります。たとえばChatworkでは、2段階認証のうちアプリ認証はフリープランを含む全プランで、SMS認証はスタンダードプラン以上で、シングルサインオンはプロフェッショナルプランで案内されています（公式のプラン別機能一覧。2024年11月現在の表記）。「機能がある」ことと「自社のプランで使える」ことは別なので、契約前にプランごとの対応を確認してください。

権限を絞り、入社・異動・退職に合わせて更新する

業務に必要な最小限の権限だけを付与する「最小権限」が基本です。IPAの手引きも、サービスを利用する人の範囲を決め、どのような権限を与えるかを適切に管理することを求めています（例として、承認権限は従業員の上司に付与する）。管理者権限を持つ人数は絞り、異動・退職の際に権限を更新する手順を、人事部門の手続きに組み込んでおきます。

管理者がユーザーの追加・削除を行えるか、各ユーザーの2段階認証やパスワードの設定状況を確認できるか、といった管理機能の有無も、サービスを選ぶときの確認項目になります。

アクセス制限と外部共有の初期値を決める

外部共有リンク、社外ユーザーとのやり取り、社外や私物端末からのアクセスは、初期設定のままだと範囲が広すぎることがあります。「リンクを知っている全員が閲覧可」のような設定は、ファイルの共有が手軽になる反面、リンクが転送されれば誰でも開けてしまいます。外部共有は初期値を制限し、必要なときだけ個別に許可する運用にします。

IPアドレス制限、端末の制限、社外ユーザーの制限といったアクセス制御の機能は、サービスやプランによって提供の有無が異なります。たとえばChatworkでは、IPアドレス制限、モバイル端末制限、社外ユーザー制限がプロフェッショナルプランの機能として案内されています。自社に必要な制限が、検討中のプランで使えるかを確認しておきましょう。

データのバックアップと、消失への備え

IPAの手引きは「バックアップに責任を持つ」として、クラウドサービスの拡張機能にバックアップがある場合は利用すること、定期的に社内の専用ハードディスクなどにも取得すること、直前より過去の状態に遡れるよう複数世代で取得することを例に挙げています。事業者側のバックアップの範囲や、利用者の誤操作で消したデータを個別に復元できるか、できる場合の期間や依頼方法は、サービスや契約プランによって異なります。業務に欠かせないデータは、復元の条件を事前に確認したうえで、定期的なエクスポートなど自社側でも写しを持つ運用を検討してください。

従業員の行動で破られる経路への備え

設定を整えても、使う人の行動で破られることがあります。SaaSのログイン画面を装ったフィッシングメールでIDとパスワードを入力してしまう、添付ファイルからマルウェアに感染して端末に保存された認証情報を盗まれる、といった経路です。これらは事業者の対策では止めにくく、利用者側で防ぐ必要があります。多要素認証の必須化に加えて、不審なメールやログイン画面の見分け方、パスワードを使い回さないこと、私物端末や公衆Wi-Fiでの利用ルールを、入社時と定期的な研修で従業員に伝えておきましょう。事業者側のシステム障害でサービスが止まった場合に備えて、代わりの連絡手段や業務の進め方を決めておくことも、事業継続の観点から大切です。

対策を支えるツールの用語整理

利用するSaaSが増えてくると、設定や利用状況を人手だけで追うのが難しくなります。そうした場面で使われる代表的なツールの呼び方を整理しておきます。いずれも必須ではなく、利用するSaaSの数や扱う情報の重さに応じて検討するものです。

ツールを入れても、運用する担当者とルールがなければ活かせません。まずはSaaSに標準で備わっている多要素認証・権限・ログの機能と、後述の点検サイクルを回すところから始めるのが現実的です。

SaaSを選ぶときの確認項目｜IPAの15項目と認証・評価制度

SaaSを選ぶときは、IPAの手引きにある15項目のチェックシートを使い、選択・運用・セキュリティ管理の3区分で、事業者の信頼性と自社の運用体制を確認します。

機能と料金だけで選ぶと、導入後にセキュリティ上の不足が見つかっても、見直す手間が大きくなります。IPAの「中小企業のためのクラウドサービス安全利用の手引き」には、利用者向けの「クラウドサービス安全利用チェックシート」があり、選択するときのポイント6項目、運用するときのポイント4項目、セキュリティ管理のポイント5項目の計15項目で構成されています。

運用の4項目は、そのまま前章で見た利用者側の責任範囲にあたります。選択とセキュリティ管理の項目は、事業者の公開情報や契約書、チェックシートへの回答で確認します。同じ区分の記事として、SaaS比較の正しい方法｜景表法に配慮した選び方と評価軸も参考になります。

事業者の信頼性を確認する認証・評価制度

IPAの手引きは、クラウドサービス選択時に参考となる制度として、次のものを紹介しています。いずれも、事業者が適切なセキュリティ対策や情報開示を行っていることを、第三者の目で確認する手がかりになります。

公式情報の読み方の例｜事業者の対策と、利用者が設定する機能を分ける

事業者の公式サイトのセキュリティのページには、事業者が行う対策と、利用者が設定・運用する機能が並んで書かれていることがあります。読むときは、「事業者が行う対策」と「利用者が有効化・運用する機能」に分け、後者は自社のプランで使えるかを確認します。Chatworkの公式サイトの記載（2026年10月15日確認）を例にすると、次のように整理できます。

Chatworkのプラン別機能一覧は2024年11月現在の表記で、機能やプランは変わることがあります。最新の内容は公式サイトで確認してください。ここでの整理は、他のSaaSの公式ページを読むときにも使えます。

ISMAP・ISMAP-LIUとは｜民間企業での参考の仕方

ISMAP（イスマップ）は「政府情報システムのためのセキュリティ評価制度」の通称で、政府が求めるセキュリティ要求を満たすクラウドサービスをあらかじめ評価・登録する制度です。政府機関がクラウドサービスを調達する際のセキュリティ水準を確保することを目的としています。

ISMAPポータルによると、この制度は2020年1月のサイバーセキュリティ戦略本部決定に基づき、国家サイバー統括室・デジタル庁・総務省・経済産業省が運営し、IPAが制度運用の実務と評価の技術的な支援を担っています。クラウドサービス事業者は、ISMAP監査機関リストに登録された監査機関の監査を受けたうえで申請し、審査を通過したサービスが「ISMAPクラウドサービスリスト」に登録されます。調達する府省庁等は、原則としてこのリストに掲載されたサービスの中から調達を行います。

ISMAP-LIUはリスクの小さい業務向けのSaaSが対象

ISMAPの中には、リスクの小さな業務や情報の処理に用いるSaaSを対象とした仕組みがあり、ISMAP-LIU（ISMAP for Low-Impact Use、イスマップ エルアイユー）と呼ばれます。すべてのSaaSに通常のISMAPと同じ水準の評価を求めると、事業者の負担が大きく、比較的リスクの低いサービスの登録が進みにくいため、扱う情報の重要度に応じて評価の範囲を調整した仕組みです。登録されたサービスは「ISMAP-LIUクラウドサービスリスト」に掲載されます。

民間企業は「登録の有無」だけで判断しない

ISMAPはあくまで政府調達のための制度で、民間企業がSaaSを選ぶときに登録済みのサービスを選ばなければならないという決まりはありません。登録には監査の費用や手間がかかるため、中小規模の事業者が提供するサービスや、政府機関を主な顧客としていないサービスは、十分な対策をしていても登録していないことがあります。

そのため民間企業では、ISMAPやISMAP-LIUへの登録を「第三者が確認した信頼性の目安のひとつ」として参考にしつつ、ISO/IEC 27001やISO/IEC 27017（クラウドサービスの情報セキュリティ）といった他の認証、事業者が公開しているセキュリティホワイトペーパーやチェックシートへの回答もあわせて確認するのが現実的です。また、ISMAPに登録されたサービスでも、冒頭で見た利用者側の責任範囲は変わりません。登録済みのサービスを選んでも、多要素認証を有効化していなければ不正ログインのリスクは残ります。

扱う情報の重さに応じて確認の深さを変える

すべてのSaaSに同じ深さの確認をしようとすると、担当者の負担が大きくなり、結果として確認そのものが形だけになりがちです。そこで、扱う情報の重さで確認の深さを変える方法が有効です。顧客の氏名や連絡先、取引情報、従業員の人事情報を扱うSaaSは、認証・契約・データの全項目を確認します。社内の予定共有やタスク管理のように機密性の低い情報しか扱わないツールは、多要素認証と権限設定、解約時のデータ削除といった基本項目に絞る、という考え方です。これはISMAPとISMAP-LIUが、扱う情報のリスクに応じて評価の範囲を分けている考え方とも共通しています。

医療・金融・教育など、業界ごとに別のガイドラインがある分野では、一般的な確認に加えて、その業界のルールへの対応状況も事業者に確認してください。医療分野の確認ポイントは、医療SaaSの選び方｜ISMAP・医療情報セキュリティ・電子カルテ連携で整理しています。

SaaSと個人情報保護法｜委託とクラウド例外の考え方

個人情報をSaaSに保存する場合、提供や委託に当たるかどうかは、事業者が個人データを取り扱うこととなっているかどうかで決まります。

顧客や従業員の個人情報をSaaSに保存する場合、その利用が個人情報保護法上の「第三者への提供」や「委託」に当たるかどうかで、利用者である企業に求められる対応が変わります。

個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン」に関するQ&A（Q7-53）では、クラウドサービスの利用が第三者提供や委託に該当するかどうかは、保存している電子データに個人データが含まれているかどうかではなく、クラウドサービスを提供する事業者において個人データを取り扱うこととなっているかどうかが判断の基準になるとされています。事業者が個人データを取り扱わないこととなっている場合は、個人データを提供したことにならないため、本人の同意を得る必要はなく、委託先としての監督義務もありません。これが一般に「クラウド例外」と呼ばれる整理です。取り扱わないこととなっている場合とは、契約条項で事業者がサーバーに保存された個人データを取り扱わない旨が定められ、適切にアクセス制御が行われている場合などが想定されています。

一方で、事業者がデータの分析やサポート対応のために個人データの中身に触れる場合は、委託に該当する可能性があります。委託に該当すると、利用者である企業には、委託先を適切に選定し、必要な契約を結び、取り扱いの状況を把握するといった委託先の監督が求められます。また、クラウド例外に当たる場合でも、同Q&A（Q7-54）によると、利用者は自ら果たすべき安全管理措置の一環として、適切な安全管理措置を講じる必要があります。

データの保存場所が外国にある場合は、外国にある第三者への提供に関する規律や、本人への情報提供の考え方にも関わることがあります。また、個人データの漏えい等が発生して報告の対象になる場合、クラウド事業者が個人データを取り扱わないこととなっているときは、クラウドサービスを利用する事業者が報告義務を負います（同Q&A、Q6-22）。報告そのものは、事業者に代行させることもできるとされています。どの整理に当たるかは、個別の契約内容や運用の実態によって判断が分かれるため、判断に迷う場合は法務部門や専門家に相談してください。なお、本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。

導入後に回したい利用者側の点検サイクル

点検は、入退社の都度・毎月・四半期・年1回・契約更新前のタイミングで、アカウント・権限・共有リンク・SaaS一覧を見直す形で回します。

利用者側の責任範囲は、導入時に一度設定すれば終わりではありません。入退社や異動、利用部署の拡大、事業者側の機能追加や規約変更によって、設定と実態は少しずつずれていきます。導入時は適切に設定していても、SaaSは継続的に機能が追加されるため、時間とともに設定の安全性が下がる可能性もあります。そこで、点検のタイミングをあらかじめ決めておき、担当者が変わっても同じ確認が続く仕組みにしておくことが大切です。

このサイクルの土台になるのが、社内で使っているSaaSの一覧です。部署ごとに無料プランや個人契約でSaaSを使い始めると、情報システム部門が把握していないサービス（いわゆるシャドーIT）が増え、どの点検からも漏れてしまいます。新しいSaaSを使い始めるときの申請ルールを決め、一覧に載っていないサービスで業務データを扱わないことを社内に周知しておくと、点検の対象を把握しやすくなります。一覧には、サービス名、管理者、利用部署、扱う情報の重さ、契約更新日を記録しておくと、選ぶときの「確認の深さを変える」運用ともつなげやすくなります。

ここまでの内容を、自社の状況に当てはめてセルフチェックしてみましょう。当てはまる項目が多いほど、点検の仕組みづくりを優先する価値があります。

インシデント発生時の対応フローを事前に決めておく

インシデント対応は、発見と報告、初動対応、事業者への連絡、影響範囲の調査、報告と再発防止の5段階で、担当と連絡先を事前に決めておくのが基本です。

アカウントの乗っ取りや情報漏えいの疑いが見つかったときに慌てないよう、社内の対応フローをあらかじめ決めておきます。基本の流れは次のとおりです。

1. 発見と報告：気づいた従業員が、誰に、どの手段で報告するかを決めておく。
2. 初動対応：該当アカウントのパスワード変更やセッションの無効化、共有リンクの停止など、被害の拡大を止める。
3. 事業者への連絡：SaaS事業者の窓口に連絡し、ログの提供や調査への協力を依頼する。
4. 影響範囲の調査：監査ログをもとに、いつ、誰が、どの情報にアクセスしたかを確認する。
5. 報告と再発防止：個人データの漏えい等に当たる場合は、個人情報保護委員会への報告や本人への通知が必要になるケースがあるため、法務部門と連携して判断する。原因を振り返り、設定やルールを見直す。

事業者側で障害や情報漏えいが起きた場合に、どのような方法で通知を受けられるかも、契約前に確認しておきたい点です。通知の方法とタイミングが利用規約やSLAに書かれているかを見ておくと、実際に問題が起きたときの初動が速くなります。

もうひとつ、事前に確認しておきたいのが、調査に使える記録を取り出せるかどうかです。Chatworkの公式サイトでは、組織内ユーザーが参加するグループチャットやダイレクトチャットのメッセージログを、インシデント発生時の記録としてエクスポートできるチャットログのエクスポート機能が、プロフェッショナルプランの機能として案内されています。このように、インシデント時に頼れる管理機能は、プランによって使える範囲が異なります。ビジネスチャットを選ぶときは、必要な管理機能がどのプランに含まれるかを、資料で自社の要件と照らして確認しておくと、いざというときに慌てずに済みます。

よくある質問(FAQ)

Q1. SaaSセキュリティとは何ですか？

A. SaaSで扱うデータやアカウントを守るための対策の総称です。サーバーやアプリ本体の保護は事業者が、ID・権限・設定・入力するデータの管理は利用者が担う責任共有モデルで考え、両方で対策を実施します。

Q2. SaaSの弱点（セキュリティ上のリスク）は何ですか？

A. IPAの手引きは、インターネットを使うため外部からの攻撃を受けやすいこと、1台のコンピュータを多数で共用するため1台のインシデントが多数に影響すること、サービスが複数事業者で構成されるため対策の全体を把握しにくいことを挙げています。これに、利用者側の設定不備や権限管理の抜け漏れが重なると事故につながります。

Q3. ISMAPに登録されていないSaaSは使わないほうがよいですか？

A. ISMAPは政府調達のための制度で、民間企業の利用では登録は必須ではありません。登録の有無は参考情報のひとつとし、ISO/IEC 27001などの認証やセキュリティチェックシートへの回答、契約内容もあわせて確認して判断します。

Q4. SaaSに個人情報を保存すると、必ず委託に当たりますか？

A. 必ずではありません。個人情報保護委員会のQ&Aでは、事業者が保存された個人データを取り扱わないこととなっている場合は、提供や委託に該当しないという考え方が示されています。事業者がデータの中身を取り扱う場合は委託に当たる可能性があるため、契約内容を確認してください。

Q5. 多くのSaaSを使っている場合、どこから見直せばよいですか？

A. まず社内で使っているSaaSの一覧を作り、扱う情報の重さを整理します。そのうえで、利用者が多く情報が集まるSaaSや、顧客情報・人事情報を扱うSaaSから優先して、多要素認証・権限・共有設定を見直すのが効率的です。

Q6. 情報漏えいが起きたら、どこに報告が必要ですか？

A. 個人データの漏えい等で一定の要件に当たる場合は、個人情報保護委員会への報告と本人への通知が必要になるケースがあります。クラウド事業者が個人データを取り扱わないこととなっている場合は、利用する企業が報告義務を負います。法務部門と連携して判断できる体制を事前に整えておきましょう。

まとめ｜SaaSセキュリティで今日から行う5つのこと

SaaSのセキュリティは、事業者と利用者が責任を分け合う責任共有モデルで考えるのが出発点です。ISMAPやISMAP-LIUは信頼性の目安として参考になりますが、登録の有無にかかわらず、利用者側の責任範囲は残ります。今日から取り組めることは次の5つです。

1. 社内で使っているSaaSの一覧を作り、扱う情報の重さと管理者を記録する。
2. アカウント管理・認証と権限・データの取り扱い・端末の4領域について、担当者を決める。
3. 多要素認証の必須化と、入退社に合わせたアカウントの更新を、社内の手続きに組み込む。
4. 個人情報を扱うSaaSは、事業者がデータを取り扱うかどうかを契約内容で確認する。
5. 業務連絡を会社が管理できるツールにまとめる選択肢として、ビジネスチャットなどのSaaSを検討し、プランごとの管理機能を資料で確認する。

参考文献

• ISMAPポータル「制度案内 ISMAP概要」
• 個人情報保護委員会「「個人情報の保護に関する法律についてのガイドライン」に関するQ&A」
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」
• IPA 独立行政法人情報処理推進機構「中小企業の情報セキュリティ対策ガイドライン」
• IPA 独立行政法人情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」
• IPA 独立行政法人情報処理推進機構「情報セキュリティ10大脅威 2026」
• 総務省「クラウドサービス利用・提供における適切な設定のためのガイドライン」
• Chatwork「セキュリティ」
• Chatwork「プラン別機能一覧」
• Chatwork「導入事例 フェイスラボ株式会社」
• 一般社団法人情報マネジメントシステム認定センター「ISMSクラウドセキュリティ認証」
• 特定非営利活動法人日本セキュリティ監査協会「クラウド情報セキュリティ監査制度」
• 一般社団法人日本クラウド産業協会「ASP・SaaS情報開示認定制度」