SaaSのセキュリティ｜利用者の責任範囲とISMAP・個人情報保護法の要点
Check!
- og:description
- SaaSのセキュリティを責任共有モデルで整理し、利用者側が担う4つの領域、ISMAP・ISMAP-LIUの位置づけ、個人情報保護法の委託とクラウド例外の考え方、導入前のチェックポイントと導入後の点検サイクル、よくある事故の原因まで、ISMAPポータルや個人情報保護委員会、IPAの資料をもとに解説します。
- ④チェックポイント
SaaSを導入すると、サーバーの管理やソフトウェアの更新は事業者が担ってくれます。そのため「セキュリティは事業者に任せておけば大丈夫」と考えがちですが、実際にはIDとパスワードの管理、アクセス権限の設定、取り扱うデータの選別など、利用者側にしか担えない責任範囲が残ります。情報漏えいの多くは、この利用者側の範囲で起きています。この記事では、SaaSのセキュリティを「事業者と利用者の責任分担」という軸で整理したうえで、政府のクラウド評価制度であるISMAP・ISMAP-LIUの位置づけ、個人情報保護法上の論点、民間企業が導入前と導入後に確認したいポイント、よくある事故の原因パターンまでを、ISMAPポータルや個人情報保護委員会、IPA（独立行政法人情報処理推進機構）の公開資料をもとに解説します。
あなたのSaaSセキュリティの課題を診断
Q1. 今使っているSaaSで、いちばん気になる点はどれですか？
おすすめ記事
目次
開く
閉じる
開く
閉じる
グループウェアで考えるSaaSセキュリティ｜選定時に確認したい8項目
SaaSのセキュリティを具体的に考えるなら、社内でいちばん多くの情報が集まるグループウェアを例にすると全体像がつかみやすくなります。グループウェアには、スケジュール、社内連絡、稟議や申請、共有ファイルなど、機密情報や従業員の個人情報が日常的に蓄積されます。しかも全社員が毎日ログインするため、アカウントの数が多く、権限設定や退職者の管理が崩れやすいSaaSの代表でもあります。
下の表は、セキュリティを重視してグループウェアを選ぶときの確認項目を、「事業者の対策を確認するもの」と「利用者が設定・運用するもの」に分けて整理したものです。同じ機能でも、事業者が備えているだけでは効果がなく、利用者が有効化して運用して初めて意味を持つ項目が多い点がポイントです。
| 確認項目 | 主に担う側 | 確認・運用のポイント |
|---|---|---|
| 第三者認証の取得 | 事業者 | ISO/IEC 27001（ISMS）やプライバシーマーク、ISMAP等への登録状況を公式情報で確認する |
| 通信・保存データの暗号化 | 事業者 | 通信経路と保存データの両方が暗号化されているかを確認する |
| データセンターの堅牢性・バックアップ | 事業者 | 災害時の復旧方針、バックアップの頻度と保管場所を確認する |
| 多要素認証 | 両方（機能は事業者、有効化は利用者） | 対応方式を確認し、導入時に全社で必須化する |
| アクセス制限（IP制限・端末制限） | 両方 | 社外や私物端末からの利用ルールを決め、設定に反映する |
| 権限設定 | 利用者 | 部署・役職ごとに閲覧範囲を分け、必要最小限の権限にする |
| 監査ログ | 両方（取得は事業者、確認は利用者） | ログの保存期間と出力方法を確認し、定期的に見る担当を決める |
| モバイル端末の遠隔ロック・データ削除 | 両方 | 紛失時の連絡手順と操作担当者をあらかじめ決めておく |
お名前.comビジネスコンシェルジュの「高セキュリティなグループウェア」の記事では、こうした選定ポイントに加えて、運用ルールの決め方や、セキュリティ強化用ツールの併用といった補強策も解説しています。紹介しているグループウェアの一例として、株式会社ネオジャパンのdesknet’s NEOは、情報共有から申請・承認、スケジュール管理までを1つで扱える多機能型で、クラウド版は初期費用無料で利用できる点が特徴とされています。一方で、業務アプリ作成ツールAppSuiteは一部のプランのみの標準対応です。機能や料金は変わることがあるため、最新の内容は公式情報で確認してください。
SaaSセキュリティの責任範囲｜事業者と利用者の分担
SaaSのセキュリティは、事業者と利用者が責任を分け合う「責任共有モデル」で考えます。データセンター、ネットワーク、OS、アプリケーション本体の管理は事業者が担い、アカウント、アクセス権限、設定、そこに入れるデータの管理は利用者が担うのが基本です。
IaaSやPaaSと比べると、SaaSは利用者が管理する範囲がもっとも小さいクラウドの形態です。サーバーの脆弱性対応やパッチ適用を自社で行う必要はありません。ただし、範囲が小さいからといってゼロになるわけではありません。むしろ、残った範囲が「人の運用」に集中しているため、担当者の異動や退職、利用部署の増加といった日常の変化で管理が崩れやすいという特徴があります。
| 管理対象 | オンプレミス | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| データの分類・取り扱い | 利用者 | 利用者 | 利用者 | 利用者 |
| ID・権限・利用端末 | 利用者 | 利用者 | 利用者 | 利用者 |
| アプリケーションの設定 | 利用者 | 利用者 | 利用者 | 利用者（設定項目の範囲内） |
| アプリケーション本体 | 利用者 | 利用者 | 利用者 | 事業者 |
| OS・ミドルウェア | 利用者 | 利用者 | 事業者 | 事業者 |
| サーバー・ネットワーク・施設 | 利用者 | 事業者 | 事業者 | 事業者 |
表は一般的な考え方を示したもので、実際の分担はサービスや契約によって異なります。特に「アプリケーションの設定」は、事業者が用意した設定項目の範囲で利用者が選ぶ形になるため、どの設定が初期状態でどうなっているか（初期値）を把握しておくことが大切です。総務省の「クラウドサービス提供・利用における適切な設定のためのガイドライン」でも、設定ミスによる情報漏えいを防ぐために、利用者と事業者の双方が設定の責任を理解することの重要性が示されています。
利用者側が担う4つの領域
利用者側の責任範囲は、大きく次の4つに分けると社内で分担しやすくなります。
- アカウント管理：入社・異動・退職に合わせたアカウントの発行、変更、削除。共有アカウントを作らないこと。
- 認証と権限：多要素認証の有効化、パスワードの使い回し防止、必要最小限の権限付与、管理者権限を持つ人数の制限。
- データの取り扱い：どの情報をSaaSに入れてよいかの社内ルール、外部共有リンクの設定、ダウンロードや持ち出しの制限。
- 端末と利用環境：SaaSにアクセスする端末のOS更新やウイルス対策、公衆Wi-Fiなど安全でない環境からの利用ルール。
この4領域は、情報システム部門だけで完結しません。アカウント管理は人事部門との連携が必要ですし、データの取り扱いは各部署の業務ルールと重なります。IPAの「中小企業の情報セキュリティ対策ガイドライン」でも、情報セキュリティを経営者が関与する組織的な取り組みとして進めることが求められています。担当者を決め、部門をまたいで確認できる仕組みを作ることが、利用者側の責任を果たす近道です。
見落とされやすい2つの備え｜従業員教育とデータ消失対策
4領域の設定を整えても、使う人の行動で破られることがあります。SaaSのログイン画面を装ったフィッシングメールでIDとパスワードを入力してしまう、添付ファイルからマルウェアに感染して端末に保存された認証情報を盗まれる、といった経路です。これらは事業者の対策では止めにくく、利用者側で防ぐ必要があります。多要素認証の必須化に加えて、不審なメールやログイン画面の見分け方、パスワードを使い回さないこと、私物端末や公衆Wi-Fiでの利用ルールを、入社時と定期的な研修で従業員に伝えておきましょう。IPAの「中小企業の情報セキュリティ対策ガイドライン」でも、従業員への教育は組織として取り組む対策のひとつに位置づけられています。
もうひとつが、データ消失への備えです。事業者が行うバックアップは、主に設備の障害や災害からサービス全体を復旧するためのもので、利用者の誤操作による削除や上書き、不正アクセスによる改ざんで失われたデータを、個別に元に戻せるとは限りません。削除したデータを復元できる期間や範囲、復元を依頼する方法は、サービスや契約プランによって異なります。業務に欠かせないデータは、復元の条件を事前に確認したうえで、定期的なエクスポートなど自社側でも写しを持つ運用を検討してください。事業者側のシステム障害でサービスが止まった場合に備えて、代わりの連絡手段や業務の進め方を決めておくことも、事業継続の観点から大切です。
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 | ISMAP-LIU |
|---|---|---|
| 対象 | クラウドサービス全般（IaaS・PaaS・SaaS） | リスクの小さな業務・情報の処理に用いるSaaS |
| 登録先 | ISMAPクラウドサービスリスト | ISMAP-LIUクラウドサービスリスト |
| 民間企業での使い方 | 登録は民間の調達では必須ではない。第三者の監査を経て一定の管理基準を満たしたことを示す参考情報として使う | |
民間企業は「登録の有無」だけで判断しない
ISMAPはあくまで政府調達のための制度で、民間企業がSaaSを選ぶときに登録済みのサービスを選ばなければならないという決まりはありません。登録には監査の費用や手間がかかるため、中小規模の事業者が提供するサービスや、政府機関を主な顧客としていないサービスは、十分な対策をしていても登録していないことがあります。
そのため民間企業では、ISMAPやISMAP-LIUへの登録を「第三者が確認した信頼性の目安のひとつ」として参考にしつつ、ISO/IEC 27001やISO/IEC 27017（クラウドサービスの情報セキュリティ）、プライバシーマークといった他の認証、事業者が公開しているセキュリティホワイトペーパーやチェックシートへの回答もあわせて確認するのが現実的です。また、ISMAPに登録されたサービスでも、前章で見た利用者側の責任範囲は変わりません。登録済みのサービスを選んでも、多要素認証を有効化していなければ不正ログインのリスクは残ります。
SaaSと個人情報保護法｜委託とクラウド例外の考え方
顧客や従業員の個人情報をSaaSに保存する場合、その利用が個人情報保護法上の「委託」に当たるかどうかで、利用者である企業に求められる対応が変わります。
個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン」に関するQ&Aでは、クラウドサービスの利用について、クラウドサービス事業者がサーバーに保存された個人データを取り扱わないこととなっている場合には、個人データの提供や委託には該当しないという考え方が示されています。これが一般に「クラウド例外」と呼ばれる整理です。取り扱わないこととなっている場合とは、契約条項で事業者がサーバーに保存された個人データを取り扱わない旨が定められ、適切にアクセス制御が行われている場合などが想定されています。
一方で、事業者がデータの分析やサポート対応のために個人データの中身に触れる場合は、委託に該当する可能性があります。委託に該当すると、利用者である企業には、委託先を適切に選定し、必要な契約を結び、取り扱いの状況を把握するといった委託先の監督が求められます。また、クラウド例外に当たる場合でも、利用者は自社の個人データを安全に管理する義務（安全管理措置）を負い続ける点に注意が必要です。
| 確認すること | 見る場所 |
|---|---|
| 事業者が個人データの中身を取り扱うか | 利用規約、データ処理に関する条項、プライバシーポリシー |
| 事業者側のアクセス制御の仕組み | セキュリティホワイトペーパー、チェックシートへの回答 |
| サポート時にデータを閲覧する条件 | サポート規約、問い合わせ時の同意手続き |
| データの保存場所（国内・国外） | 契約書、サービス仕様、データセンター情報 |
データの保存場所が外国にある場合は、外国にある第三者への提供に関する規律や、本人への情報提供の考え方にも関わることがあります。どの整理に当たるかは、個別の契約内容や運用の実態によって判断が分かれるため、判断に迷う場合は法務部門や専門家に相談してください。なお、本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。
民間企業がSaaSセキュリティを見るときのチェックポイント
SaaSを選ぶときは、機能と料金だけでなく、認証・契約・運用・データの4つの観点でセキュリティを確認します。導入後に見直すのは手間がかかるため、比較検討の段階でチェックしておくのが効率的です。
| 観点 | 主な確認項目 |
|---|---|
| 認証・評価 | ISO/IEC 27001・27017、プライバシーマーク、ISMAP・ISMAP-LIUへの登録状況。セキュリティチェックシートへの回答の有無 |
| 契約・規約 | SLA（稼働率の目標値、障害時の補償範囲）、データの取り扱い条項、サービス内容変更や提供終了時の予告期間 |
| 運用・インシデント対応 | 障害や情報漏えい時の通知方法とタイミング、問い合わせ窓口、脆弱性情報の公開方針 |
| データ | 保存場所、バックアップ、解約時のデータの返却・削除方法、エクスポートの形式 |
扱う情報の重さに応じて確認の深さを変える
すべてのSaaSに同じ深さの確認をしようとすると、担当者の負担が大きくなり、結果として確認そのものが形だけになりがちです。そこで、扱う情報の重さで確認の深さを変える方法が有効です。顧客の氏名や連絡先、取引情報、従業員の人事情報を扱うSaaSは、認証・契約・データの全項目を確認します。社内の予定共有やタスク管理のように機密性の低い情報しか扱わないツールは、多要素認証と権限設定、解約時のデータ削除といった基本項目に絞る、という考え方です。これはISMAPとISMAP-LIUが扱う情報のリスクに応じて評価の範囲を分けている考え方とも共通しています。
医療・金融・教育など、業界ごとに別のガイドラインがある分野では、一般的な確認に加えて、その業界のルールへの対応状況も事業者に確認してください。
情報が集まるSaaSから優先して見直す
すでに多くのSaaSを使っている企業では、どこから見直すかも重要です。優先度が高いのは、利用者が多く、社内のあらゆる情報が集まるSaaSです。その代表がグループウェアで、社内連絡や共有ファイル、申請書類が集中するため、1つのアカウントが乗っ取られるだけで広い範囲の情報に影響が及びます。グループウェアを乗り換えるタイミングや新しく導入するタイミングは、多要素認証の必須化、権限の整理、監査ログを確認する担当の決定といった社内ルールをまとめて整える好機にもなります。セキュリティ機能を軸にグループウェアを比べたい場合は、次の記事が参考になります。
導入後に回したい利用者側の点検サイクル
利用者側の責任範囲は、導入時に一度設定すれば終わりではありません。入退社や異動、利用部署の拡大、事業者側の機能追加や規約変更によって、設定と実態は少しずつずれていきます。そこで、点検のタイミングをあらかじめ決めておき、担当者が変わっても同じ確認が続く仕組みにしておくことが大切です。
| タイミング | 点検すること | 連携する部署 |
|---|---|---|
| 入社・異動・退職の都度 | アカウントの発行・権限変更・削除 | 人事部門 |
| 毎月 | 管理者権限を持つアカウントの一覧確認、不審なログインの有無 | 情報システム部門 |
| 四半期ごと | 外部共有リンクの棚卸し、使われていないアカウントの整理 | 各利用部署 |
| 年1回 | 利用中のSaaS一覧の更新、全ユーザーの権限見直し、規約・SLAの変更確認 | 情報システム部門・法務部門 |
| 契約更新の前 | セキュリティ関連の規約変更、認証の更新状況、継続利用の要否 | 契約担当部署 |
このサイクルの土台になるのが、社内で使っているSaaSの一覧です。部署ごとに無料プランや個人契約でSaaSを使い始めると、情報システム部門が把握していないサービス（いわゆるシャドーIT）が増え、どの点検からも漏れてしまいます。新しいSaaSを使い始めるときの申請ルールを決め、一覧に載っていないサービスで業務データを扱わないことを社内に周知しておくと、点検の対象を把握しやすくなります。一覧には、サービス名、管理者、利用部署、扱う情報の重さ、契約更新日を記録しておくと、前章の「確認の深さを変える」運用ともつなげやすくなります。
SaaSのセキュリティ事故でよくある原因パターン
SaaSに関わる情報漏えいや不正アクセスは、高度な攻撃よりも、利用者側の設定や運用の抜け漏れから起きるケースが目立ちます。IPAが毎年公表している「情報セキュリティ10大脅威」の組織編でも、内部不正や不注意による情報漏えいが継続して挙げられています。代表的な原因パターンと、対策後の状態を比べると次のとおりです。
| 原因パターン | Before（よくある状態） | After（対策後） |
|---|---|---|
| 共有設定のミス | 「リンクを知っている全員が閲覧可」の設定のまま、顧客情報を含むファイルを共有している | 外部共有の初期値を制限し、四半期ごとに公開中のリンクを棚卸しする |
| 退職者アカウントの放置 | 退職後もアカウントが有効で、本人や第三者がログインできる | 人事部門と連携し、退職日に全SaaSのアカウントを停止する手順を決める |
| パスワードの使い回し | 他サービスから流出したパスワードで不正ログインされる | 多要素認証を全社で必須にし、パスワード管理のルールを定める |
| 権限の付けすぎ | 異動前の権限が残り、不要な部署の情報まで閲覧できる | 最小権限を原則にし、年1回全ユーザーの権限を見直す |
| 事業者任せの思い込み | ISMAP登録済みなので設定の確認は不要と考えている | 責任共有モデルに沿って、利用者側の4領域の担当者を決める |
どのパターンも、事業者の対策がどれだけ強固でも防げない、利用者側の責任範囲で起きている点が共通しています。逆にいえば、設定の初期値と定期的な棚卸しを押さえるだけで、防げる事故の多くに対応できます。
インシデント発生時の対応フローを事前に決めておく
アカウントの乗っ取りや情報漏えいの疑いが見つかったときに慌てないよう、社内の対応フローをあらかじめ決めておきます。基本の流れは次のとおりです。
- 発見と報告：気づいた従業員が、誰に、どの手段で報告するかを決めておく。
- 初動対応：該当アカウントのパスワード変更やセッションの無効化、共有リンクの停止など、被害の拡大を止める。
- 事業者への連絡：SaaS事業者の窓口に連絡し、ログの提供や調査への協力を依頼する。
- 影響範囲の調査：監査ログをもとに、いつ、誰が、どの情報にアクセスしたかを確認する。
- 報告と再発防止：個人データの漏えい等に当たる場合は、個人情報保護委員会への報告や本人への通知が必要になるケースがあるため、法務部門と連携して判断する。原因を振り返り、設定やルールを見直す。
事業者側で障害や情報漏えいが起きた場合に、どのような方法で通知を受けられるかも、契約前に確認しておきたい点です。通知の方法とタイミングが利用規約やSLAに書かれているかを見ておくと、実際に問題が起きたときの初動が速くなります。
よくある質問（FAQ）
Q. SaaSのセキュリティは事業者に任せておけば十分ですか？
A. 十分ではありません。責任共有モデルでは、サーバーやアプリケーション本体の管理は事業者、アカウント・権限・設定・データの管理は利用者が担います。多要素認証の有効化や退職者アカウントの削除などは、利用者側で行う必要があります。
Q. ISMAPに登録されていないSaaSは使わないほうがよいですか？
A. ISMAPは政府調達のための制度で、民間企業の利用では登録は必須ではありません。登録の有無は参考情報のひとつとし、ISO/IEC 27001などの認証やセキュリティチェックシートへの回答、契約内容もあわせて確認して判断します。
Q. ISMAPとISMAP-LIUの違いは何ですか？
A. ISMAPはクラウドサービス全般を対象とした評価制度で、ISMAP-LIUはその中でリスクの小さな業務や情報の処理に用いるSaaSを対象とした仕組みです。扱う情報の重要度に応じて評価の範囲が調整されています。
Q. SaaSに個人情報を保存すると、必ず委託に当たりますか？
A. 必ずではありません。個人情報保護委員会のQ&Aでは、事業者が保存された個人データを取り扱わないこととなっている場合は、提供や委託に該当しないという考え方が示されています。事業者がデータの中身を取り扱う場合は委託に当たる可能性があるため、契約内容を確認してください。
Q. 多くのSaaSを使っている場合、どこから見直せばよいですか？
A. まず社内で使っているSaaSの一覧を作り、扱う情報の重さを整理します。そのうえで、利用者が多く情報が集まるグループウェアや、顧客情報・人事情報を扱うSaaSから優先して、多要素認証・権限・共有設定を見直すのが効率的です。
Q. 情報漏えいが起きたら、どこに報告が必要ですか？
A. 個人データの漏えい等で一定の要件に当たる場合は、個人情報保護委員会への報告と本人への通知が必要になるケースがあります。SaaS事業者への連絡とあわせて、法務部門と連携して判断できる体制を事前に整えておきましょう。
まとめ
SaaSのセキュリティは、事業者と利用者が責任を分け合う責任共有モデルで考えるのが出発点です。ISMAPやISMAP-LIUは信頼性の目安として参考になりますが、登録の有無にかかわらず、利用者側の責任範囲は残ります。今日から取り組めることは次の4つです。
- 社内で使っているSaaSの一覧を作り、扱う情報の重さと管理者を記録する。
- アカウント管理・認証と権限・データの取り扱い・端末の4領域について、担当者を決める。
- 個人情報を扱うSaaSは、事業者がデータを取り扱うかどうかを契約内容で確認する。
- 情報が集まるグループウェアから優先して、多要素認証・権限・共有設定を見直す。
参考文献
- ISMAPポータル「制度案内 ISMAP概要」
- 個人情報保護委員会「「個人情報の保護に関する法律についてのガイドライン」に関するQ&A」
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」
- IPA 独立行政法人情報処理推進機構「中小企業の情報セキュリティ対策ガイドライン」
- IPA 独立行政法人情報処理推進機構「情報セキュリティ10大脅威 2025」
- 総務省「クラウドサービス提供・利用における適切な設定のためのガイドライン」
