SaaSのセキュリティ｜利用者の責任範囲
Check!
- 責任共有モデルと利用者の責任範囲がわかる
- ISMAPの意味と位置づけがわかる
- 個人情報保護と導入前チェック観点がわかる
SaaSを導入すれば、セキュリティ対応はすべて提供事業者が担ってくれると思われがちですが、実際には利用者側にも一定の責任範囲があります。本記事では、SaaSのセキュリティを、利用者の責任範囲とISMAP・個人情報保護法の要点として整理します。ランサムウェア被害を想定した攻撃パターン・初動対応・BCPへの組み込み方はSaaSとランサムウェアの記事で詳しく解説しています。
おすすめ記事
目次
開く
閉じる
開く
閉じる
SaaS利用時のセキュリティリスクと利用者の責任範囲
IPA(情報処理推進機構)の資料に基づくと、データセンターやOSの管理は事業者側が担い、ID・パスワード管理や権限設定は利用者側が担うという「責任共有モデル」で整理されます。すべてを事業者に任せられるわけではなく、利用者側の管理範囲を正しく認識する必要があります。
ISMAP(政府情報システムのためのセキュリティ評価制度)とは
ISMAPとは、政府情報システムにクラウドサービスを採用する際のセキュリティ評価制度です。政府調達では原則基準となっていますが、民間企業には必須ではなく、参照が期待される制度として位置づけられています。
SaaSと個人情報保護
個人情報保護委員会は2024年、クラウド事業者が個別データを実際に取り扱う場合は委託に該当する可能性を強調する注意喚起を公表しました。SaaS利用にあたっては、委託先の管理体制や、データ保護の仕組みを確認する必要があります。
導入前のセキュリティチェック観点
認証・認定、契約・利用規約、運用・インシデント対応、データ・サーバー所在地という4観点で、導入前のセキュリティチェックを体系化できます。社内のスケジュール共有やファイル管理を担うグループウェアのような身近なSaaSでも、この4観点を確認する習慣をつけておくことが役立ちます。
利用者側の責任範囲を実務でどう管理するか
責任共有モデルにおいて利用者側が担うID・パスワード管理や権限設定は、日々の運用の中で形骸化しやすい領域のため、定期的な棚卸しの仕組みを社内に組み込んでおくことが重要です。
特に見落とされやすいのが、退職・異動した従業員のアカウント削除です。従業員が退職した後もSaaSのアカウントが有効なままになっていると、本人以外がそのアカウントを不正に利用するリスクや、退職者が意図せずデータにアクセスできてしまうリスクが残ります。人事部門と情報システム部門が連携し、退職・異動が発生した際にどのSaaSのアカウントを削除・変更すべきかを一覧で管理しておくことで、こうしたリスクを防ぎやすくなります。
また、権限設定についても、入社時に付与した権限が業務内容の変化後もそのまま残り続け、必要以上に広い範囲のデータにアクセスできる状態になっているケースが少なくありません。半年から1年に一度など、定期的に「誰がどのSaaSにどの権限でアクセスできるか」を棚卸しし、不要になった権限を削除する運用を社内ルールとして定めておくことが、責任共有モデルにおける利用者側の責任を実務で果たすための具体的な方法です。
SaaSセキュリティでよくある失敗パターン3つ
セキュリティ対応を事業者に全面的に委ねると考える、ISMAP登録の有無だけで判断する、個人情報の委託該当性を確認しないという3つが、SaaSセキュリティでよく見られる失敗の典型です。
失敗パターン1:セキュリティ対応を事業者に全面的に委ねると考える。ID・パスワード管理等の利用者側の責任範囲を怠るケースです。責任共有モデルを理解することが回避策になります。
失敗パターン2:ISMAP登録の有無だけで判断する。民間企業には必須ではない制度であることを踏まえず、登録の有無のみで評価するケースです。他の認証・認定も含めて確認することが回避策になります。
失敗パターン3:個人情報の委託該当性を確認しない。クラウド事業者へのデータ取り扱いが委託に該当する可能性を見落とすケースです。個人情報保護委員会の注意喚起を踏まえて確認することが回避策になります。
インシデント発生時の対応フローを事前に決めておく
SaaS利用中に情報漏えいや不正アクセスといったセキュリティインシデントが疑われる事態が発生した際、慌てずに対応できるよう、社内の対応フローをあらかじめ決めておくことが重要です。
まず、インシデントを発見した従業員が誰に、どのような手段で報告すればよいかを明確にしておく必要があります。情報システム部門の窓口が分からず対応が遅れると、被害が拡大するリスクが高まります。社内向けの一覧表やマニュアルに、緊急連絡先とエスカレーションの手順を明記しておくことをおすすめします。
また、SaaSベンダー側でインシデントが発生した場合(ベンダー起因の障害・情報漏えい等)に、どのような形で通知を受けられるかも、契約前に確認しておきたいポイントです。ベンダーの利用規約やSLA(サービスレベルアグリーメント)に、インシデント発生時の通知義務や対応方針が明記されているかを確認しておくと、実際に問題が起きた際の初動が早くなります。個人情報の漏えいが疑われる場合は、個人情報保護法に基づき、個人情報保護委員会への報告や本人への通知が必要になるケースもあるため、法務・コンプライアンス部門とも連携できる体制を整えておくことが望ましいとされています。なお、本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。個別の対応については専門家にご確認ください。
取り扱うデータの機密性に応じてセキュリティ対応を使い分ける
SaaSのセキュリティ対応は、すべてのデータに同じ水準を一律に適用するのではなく、取り扱うデータの機密性に応じて濃淡をつけて考えることが実務上は現実的です。個人情報や取引先の機密情報を扱うSaaSと、社内の予定共有やタスク管理のように機密性の低い情報を扱うSaaSとでは、確認すべき項目の深さが変わります。
例えば、顧客の氏名・連絡先・取引履歴といった個人情報を扱う営業支援系や顧客管理系のSaaSでは、データの暗号化方式、アクセスログの保存期間、退職者アカウントの自動失効設定の有無まで踏み込んで確認することが望ましいとされています。一方で、社内会議の日程調整のみに使うようなツールであれば、ID・パスワード管理と多要素認証の設定といった基本的な項目を押さえておけば、実務上は十分なケースが多いといえます。すべてのSaaSに同じ工数をかけて確認しようとすると、情報システム部門の負担が過大になり、結果として確認作業自体が形骸化しかねません。
また、医療・金融・官公庁関連の業務でSaaSを利用する場合は、業界固有のガイドラインや規制(医療分野であれば医療情報システムの安全管理に関するガイドライン等)が別途存在することがあるため、一般的なセキュリティチェックに加えて、自社が属する業界の規制動向も確認しておく必要があります。業界固有のルールへの適合状況については、SaaS事業者に直接問い合わせて確認するか、必要に応じて社内の法務・コンプライアンス部門や外部専門家に相談することをおすすめします。
多要素認証とアクセス制御を実務にどう組み込むか
責任共有モデルにおいて利用者側が担う代表的な対策の一つが、多要素認証(MFA)の導入とアクセス制御の設計です。ID・パスワードのみによる認証は、パスワードの使い回しや漏えいによって不正アクセスを受けるリスクが常につきまとうため、多要素認証を組み合わせることで、リスクを大きく下げることができるとされています。
多要素認証には、SMSやメールで送られる確認コードを入力する方式、専用の認証アプリで生成されるワンタイムパスワードを使う方式、物理的なセキュリティキーを用いる方式など複数の選択肢があります。SaaSごとに対応している方式が異なるため、導入前にどの方式に対応しているかを確認し、自社の運用体制に合った方式を選ぶことが重要です。特に、経営情報や人事情報など機密性の高いデータにアクセスできるアカウントについては、より強固な方式を優先的に適用するといった濃淡のつけ方も有効です。
アクセス制御についても、全従業員に同じ権限を一律に付与するのではなく、業務上必要な範囲に限定して権限を付与する「最小権限の原則」に基づいて設計することが望ましいとされています。部署異動やプロジェクトの終了に伴って不要になった権限を放置せず、都度見直す運用ルールを整備しておくことで、責任共有モデルにおける利用者側の管理範囲を実務レベルで満たしやすくなります。加えて、管理者権限を持つアカウントは特に厳格に管理し、付与できる人数を最小限に絞ったうえで、定期的に利用状況を確認する体制を整えておくことも、SaaS利用時のセキュリティ対応として有効な取り組みの一つです。
SaaS事業者を選定する際に契約書・利用規約で確認したい項目
SaaSのセキュリティは、機能や画面上の設定だけでなく、契約書や利用規約に何が明記されているかによっても実質的に左右されます。導入前に契約内容を確認しておくことで、実際にトラブルが起きた際の対応がスムーズになります。
まず確認したいのは、データの保存場所と、契約終了後のデータの取り扱いです。サーバーが国内にあるか海外にあるかによって、適用される法制度が異なる場合があり、特に個人情報を扱う場合は影響が大きくなります。また、契約を終了した際にデータがどの程度の期間保存され、いつ削除されるのかが明記されているかも確認しておくべきポイントです。データの取り出し(エクスポート)に対応しているか、対応している場合はどのような形式で取り出せるかも、乗り換えの可能性を考えると事前に押さえておきたい情報です。
次に、サービスレベルアグリーメント(SLA)の内容です。稼働率の目標値や、障害発生時の補償範囲、通知のタイミングと手段が契約書や利用規約に明記されているかを確認します。SLAが明文化されていない、あるいは内容が曖昧な場合は、実際に障害が起きた際の対応方針が不明確なまま利用を続けることになるため、営業担当者や問い合わせ窓口に個別に確認しておくことをおすすめします。加えて、サービス内容や料金プランの変更、サービス自体の終了(サービス終了)に関する予告期間についても、規約上どのように定められているかを確認しておくと、将来的な業務への影響を見積もりやすくなります。これらの契約条件は事業者やプランによって異なるため、必ず最新の公式情報を個別に確認したうえで判断することが重要です。
さらに、複数のSaaSを組み合わせて業務を運用している企業では、契約更新のタイミングがサービスごとにばらばらになりがちです。契約更新月をまとめて一覧化しておき、更新前にセキュリティ関連の規約変更がないかをあわせて確認する運用にしておくと、規約改定の見落としを防ぎやすくなります。担当者が異動・退職した場合に備えて、契約内容の確認結果を個人のメモではなく部門内で共有できる形で記録しておくことも、実務上は有効な工夫です。
よくある質問(FAQ)
Q1. ISMAP非登録のSaaSは使用できませんか?
A. 民間企業には必須ではないため、非登録であっても他の認証・認定を確認して利用することは可能です。
Q2. SaaS利用は必ず個人情報の委託に該当しますか?
A. 個別データを事業者が実際に取り扱う場合に委託に該当する可能性があり、必ずしも一律ではありません。
Q3. 「絶対安全」を謳う事業者は信頼できますか?
A. セキュリティに絶対はないため、そうした表現を掲げる事業者には注意が必要です。
Q4. 脆弱性診断の責任範囲はどうなっていますか?
A. 責任共有モデルに基づき、事業者・利用者それぞれの管理範囲に応じて責任が分かれます。
Q5. ISMAPとは何ですか?
A. 政府情報システムにクラウドサービスを採用する際のセキュリティ評価制度です。
Q6. 導入前に確認すべき観点は何ですか?
A. 認証・認定、契約・利用規約、運用・インシデント対応、データ・サーバー所在地の4点です。
まとめ｜今日からできる3つのこと
- 責任共有モデルを理解する:事業者に全面的に委ねません。
- 複数の認証・認定を確認する:ISMAPの有無だけで判断しません。
- 個人情報の委託該当性を確認する:見落としません。
