「便利だから使いたい」と申請されたクラウドサービス、審査もなく承認していませんか。情シスが1人体制の中小企業では、SaaSの導入可否を判断する仕組みがないまま現場主導でツールが増え続けるケースが後を絶ちません。気づいたときには社外のサーバーに機密情報が保存されていた、退職者のアカウントが放置されていた——そんな事態が現実に起きています。
SaaSは便利な反面、設定ミスやアクセス管理の甘さが直接データ漏洩につながるリスクをはらんでいます。この記事では、SaaS導入時のセキュリティリスクの全体像と、情シス1人でも回せる承認フロー・評価チェックリストをわかりやすく解説します。
SaaS導入が招くセキュリティリスクとは？
SaaS（Software as a Service）とは、インターネット経由でソフトウェアを利用するクラウドサービス全般を指します。Slack、Zoom、Notion、Google Workspace、Salesforceなどが代表例です。手軽に使えるぶん、セキュリティ上のリスクも多様です。
IPAの「情報セキュリティ10大脅威 2026」でも、内部不正やクラウド設定ミスによる情報漏洩が上位に並んでいます。中小企業のSaaS利用で特に問題になりやすいリスクは次の4つです。
・シャドーIT化: IT部門に無断で現場が使い始め、管理外ツールに業務データが流れ込む
・設定ミスによるデータ公開: 共有設定を誤り、機密ファイルが誰でもアクセスできる状態になる
・退職者アカウントの放置: アカウント削除をし忘れ、元従業員が引き続きアクセスできる状態が続く
・連携アプリ経由の侵害: OAuthで接続したサードパーティアプリが侵害され、本体の認証情報も盗まれる
いずれも「SaaSを使っていること自体」が問題なのではなく、「導入と管理の仕組みがないこと」が根本原因です。管理できていないリスクは、知らないうちに積み上がっていきます。
攻撃者はSaaSをどう悪用するか
攻撃者の視点で見ると、SaaSは「正規の経路で機密情報に触れられる攻撃面」として積極的に狙われています。具体的な手口を理解することで、どこを重点的に守ればよいかが見えてきます。
1. パスワードスプレー攻撃でSaaSアカウントを乗っ取る
クラウドサービスのログイン画面は通常インターネットに公開されているため、攻撃者が「よく使われるパスワード」を大量のアカウントに試し打ちする「パスワードスプレー攻撃」の格好の標的になります。社内システムなら試行回数によるIPブロックが効くケースでも、SaaS側の設定によっては検知が難しいことがあります。
特に「Summer2024!」「Company123」のような予測しやすいパスワードは、公開されているパスワードリストに含まれている可能性があります。MFAが設定されていなければ、パスワードだけで完全にアカウントを奪われます。
2. 設定ミスのファイルを自動スキャンで発見する
GoogleドライブやSharePointの共有設定を「リンクを知っている全員」にしてしまったファイルは、検索エンジンにインデックスされることがあります。攻撃者は専用のスキャンツールを使って公開ファイルを自動収集しています。悪意なくやった設定ミスが、数分後には攻撃者に発見される可能性があります。
これを「クラウド設定ミスの自動スキャン（Cloud Misconfiguration Scanning）」と呼びます。実際に、国内企業の顧客名簿や見積書がGoogleドライブの設定ミスで外部公開されていた事例は複数報告されています。
3. OAuthアプリ連携を踏み台にする
「Googleアカウントでログイン」など、OAuth認証で連携しているサードパーティアプリが攻撃者に侵害されると、そのアプリに付与した権限の範囲でメールやカレンダー、ファイルにアクセスされます。利用者がパスワードを変えても、OAuthトークンが有効なままなら侵害は続きます。
これは「OAuth Phishing」と呼ばれる手法で、フィッシングメールから誘導する形でも悪用されています。「この便利アプリを使いますか？Googleアカウントを接続してください」という誘導に従ってしまうと、メール閲覧権限や連絡先情報が攻撃者に渡ります。
4. 退職者アカウントで静かに情報を持ち出す
退職後もアカウントが生きていれば、元従業員は在職中と同じように社内情報にアクセスできます。悪意がない場合でも、退職者が個人アカウントに仕事ファイルをコピーしていることがあります。意図的な内部不正では、競合他社に移る前に顧客リストを持ち出すケースも実際に起きています。
特にSaaSのアカウント管理はIdP（Identity Provider：ID管理基盤）と連携していないケースが多く、退職処理の抜け漏れが起きやすい部分です。「人事部から退職連絡が来たが、SaaSのアカウントは誰も消していなかった」という状況は珍しくありません。
SaaS導入審査チェックリスト
情シスが1人でも運用できる現実的な評価基準として、「最低限確認すべき5項目」を定めることをすすめます。すべてに合格しなければ導入禁止、という厳格なルールではなく、「リスクを把握したうえで経営判断する」ための情報収集ツールとして使うのがポイントです。
1. データ保存場所と暗号化の確認
・確認項目: データはどの国のサーバーに保存されるか
・確認項目: 保存データは暗号化されているか（AES-256等）
・確認項目: 通信経路はTLS 1.2以上で保護されているか
・確認方法: サービスのセキュリティホワイトペーパー・プライバシーポリシーを参照する
特に個人情報・顧客データを扱う場合は、EU内データを扱うGDPR対応の有無、日本の個人情報保護法との整合性も確認が必要です。「サーバーは米国内」と記載があっても、GDPR準拠のSCC（Standard Contractual Clauses：標準契約条項）が締結されているかどうかで扱いが変わります。
2. アクセス制御・MFA対応の確認
・確認項目: 多要素認証（MFA）に対応しているか
・確認項目: SSOと連携できるか（Google Workspace / Azure AD等）
・確認項目: ロールベースのアクセス制御（RBAC）が設定できるか
・確認項目: 退職時にアカウントを管理者側で即時無効化できるか
MFAが使えないSaaSは、それだけでリスクが跳ね上がります。重要データを扱う場合は、MFA必須を選定条件にすることをすすめます。SSOに対応していれば、IdP側でアカウントを無効化するだけで連携SaaSのアクセスも一括で止められるため、退職者対応が格段に楽になります。
3. ログ・監査記録の確認
・確認項目: ログイン履歴・操作ログが記録されるか
・確認項目: ログをエクスポートできるか（SIEM等への連携）
・確認項目: ログの保存期間は何日か（90日以上が望ましい）
インシデント発生時に「いつ、誰が、何をしたか」を追跡できる証跡がなければ、被害範囲の特定も困難になります。無料プランではログが記録されない・保存期間が短いケースも多いため、重要業務での無料プランの利用は原則避けるのが無難です。
4. サービスの信頼性・認証の確認
・確認項目: SOC 2 Type II や ISO 27001 などのセキュリティ認証を取得しているか
・確認項目: 脆弱性対応ポリシー（責任ある開示・パッチリリースまでの目標期間）が公開されているか
・確認項目: 過去1年以内に重大なセキュリティインシデントがなかったか
SOC 2 Type IIは、第三者機関が実際の運用を一定期間にわたって審査した証明書です。取得していないSaaSが必ずしも危険というわけではありませんが、取得していれば「セキュリティへの投資姿勢」を客観的に確認できます。ISO 27001はマネジメントシステム全体の認証で、特に国内企業との取引では信頼性の指標になります。
5. 契約・利用規約上のリスク確認
・確認項目: データの所有権はどちらにあるか（ユーザー側か、事業者側か）
・確認項目: サービス終了時にデータを持ち出せるか（エクスポート機能）
・確認項目: 事業者がユーザーデータを広告等に利用しないと明記されているか
無料プランは特に注意が必要です。「データを学習・広告に利用する」という規約が含まれているケースがあります。業務データには有料プランを使うことを基本方針にするのが無難です。AIアシスタント機能が組み込まれたSaaSでは、入力内容がAI学習に利用されるかどうかを規約で必ず確認してください。
情シス1人でも実践できる承認フロー設計
チェックリストを作っても、申請が来るたびに毎回ゼロから確認していては情シスがパンクします。「型を作る」ことで、1人でも回せる仕組みになります。
1. SaaS導入申請フォームを作る（Googleフォームで十分）
現場からの申請を口頭やSlackメッセージで受けるのをやめ、フォームに統一します。フォームに含める項目は以下のとおりです。
・申請者名・部署: 責任の所在を明確にする
・ツール名・URL: 対象サービスを特定する
・利用目的: 既存ツールで代替できないか判断するために必要
・扱うデータの種類: 顧客情報・個人情報・社外秘資料など
・利用予定人数と期間: リスクの規模感を把握するために必要
・無料・有料の別: 無料プランは利用規約を特に確認する必要がある
フォームへの回答をGoogleスプレッドシートに自動集約しておくと、後からの振り返りにも使えます。「先月何件の申請があったか」「どの部署からの申請が多いか」を把握するだけでも、シャドーITの傾向が見えてきます。
2. リスクレベルで審査の深さを変える
すべての申請を同じ深さで審査する必要はありません。扱うデータのリスクレベルに応じて、審査の簡略化と重点化を使い分けます。
| リスクレベル | 対象データ例 | 審査方針 |
|---|---|---|
| 高 | 顧客情報、契約書、財務データ | 全5項目をチェック + 経営者承認 |
| 中 | 社内資料、プロジェクト管理情報 | MFA・ログ・認証の3項目を確認 |
| 低 | 公開情報の収集、社内イベント管理 | 申請フォーム提出で簡略承認 |
「高」リスク判定のツールに対して経営者承認を要求することで、「使いたいから使う」という現場主導を防ぐと同時に、経営層にセキュリティリスクを共有できます。情シス1人が孤軍奮闘する構造を変えていくためにも、リスクの可視化は重要です。
3. 承認済みSaaSのホワイトリストを管理する
一度承認したSaaSはスプレッドシートで管理し、全社員が参照できるようにします。記録する項目は「ツール名・承認日・担当部署・アカウント管理者・次回レビュー日（年1回）」です。このリストがあれば、「このツールは使っていいのか」という問い合わせに素早く答えられます。
ホワイトリストにないSaaSの利用は原則禁止とし、「まずは申請フォームから」という文化を根付かせることがシャドーIT防止の核心です。強制力だけでなく、「申請すれば迅速に審査する」という情シス側の姿勢も大切です。現場がルールを守りたくなる仕組みを作ることが、長続きするセキュリティ対策の条件です。
4. 退職者のアカウント削除を退職処理フローに組み込む
退職処理の際に情シスへ連絡が来るルートを確立し、「SaaSのアカウント一覧をチェックして削除」を必須ステップとして組み込みます。チェックリスト形式にして、すべてに完了のチェックが入るまで退職処理を完了扱いにしないのが理想です。
IdP（ID管理基盤）としてGoogle WorkspaceやMicrosoft 365を使っている場合は、SSO連携しているSaaSのアカウントを一括で無効化できます。SSO非対応のサービスはホワイトリストに「手動削除が必要」と明記しておくことで、対応漏れを防げます。
中小企業でも今日からできること
「チェックリスト5項目を全部確認してから承認する」のが理想ですが、まず最初の一歩として取り組みやすいのは次の3つです。
Step 1: 現在使っているSaaSを棚卸しする
部署ごとに「どのSaaSを使っているか」をアンケートで把握します。費用の観点からは経費精算データを参照すると漏れが少なくなります。実態把握ゼロの状態から始めるのに最も効果的なアクションです。
Step 2: MFAを全員に強制する
Google WorkspaceやMicrosoft 365のMFAを管理者設定で全員に強制します。設定は数分で完了し、翌日からパスワード窃取によるアカウント乗っ取りリスクが大幅に下がります。コストゼロで効果が大きい対策として、最優先で実施してください。
Step 3: 申請フォームを1つ作る
Googleフォームで「SaaS導入申請フォーム」を作り、社内に周知します。完璧な審査フローがなくても、「申請する文化」を作るだけでシャドーITは大幅に減ります。フォームを作ることで情シスが「申請を待つ立場」に変わり、主体的に管理できるようになります。
よくある誤解と注意点
【誤解1】「大手のSaaSなら安全だ」
SaaSの事業者側のセキュリティ対策が万全であっても、利用者側の設定ミスやパスワード管理の甘さが原因で情報が漏洩するケースは多数あります。「責任共有モデル（Shared Responsibility Model）」と呼ばれる考え方で、クラウドサービスのセキュリティには事業者と利用者の両方に責任範囲があります。大手サービスだから安心、ではなく「使い方」が鍵です。
【誤解2】「無料プランでも同じセキュリティ機能が使える」
MFAやシングルサインオン（SSO）、監査ログが有料プランでしか利用できないSaaSは少なくありません。セキュリティ要件を満たすには有料プランへの移行が必要になるケースを事前に確認しておきましょう。初期費用を抑えた結果、セキュリティが担保できないまま使い続ける状況は避けるべきです。
【注意】過去に承認したSaaSの「年次レビュー」を忘れずに
導入時にクリアした要件が、1年後も同じとは限りません。利用規約の改定、機能変更、サービス提供国の変更、セキュリティインシデントの発生など、状況は常に変化します。ホワイトリストに年次レビュー日を設定し、定期的に再評価することが重要です。「導入して終わり」ではなく、「継続的に管理する」という意識が長期的なセキュリティを支えます。
本記事のまとめ
中小企業がSaaSを安全に活用するために抑えるべきポイントをまとめます。
| リスク項目 | 対策 | 難易度 |
|---|---|---|
| シャドーIT化 | 申請フォームで一元管理 + ホワイトリスト公開 | 低（すぐできる） |
| 設定ミスによるデータ公開 | 共有設定ポリシーの統一 + 定期棚卸し | 中 |
| 退職者アカウント放置 | 退職処理フローにSaaS削除を組み込む | 低（ルール化が重要） |
| OAuthアプリ連携の侵害 | 不要な連携アプリを定期的に確認・削除 | 中 |
| 認証情報の窃取 | MFA強制化 + パスワードマネージャー導入 | 低（効果は高い） |
SaaSのセキュリティは「高価なツールを導入する」よりも「仕組みを作って回す」ことの方がはるかに重要です。情シス1人体制でも、申請フォーム・チェックリスト・ホワイトリストの3点セットがあれば、リスクを許容範囲内に抑えながらSaaSを活用できます。
Linuxサーバー上でのアクセス制御や権限管理については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。クラウドとオンプレミスを組み合わせたセキュリティ設計に役立ててください。
SaaS管理の仕組み、まだ整っていませんか？
現場主導でSaaSが増え続けると、情シスが把握できないリスクが蓄積していきます。
正しいセキュリティ知識を体系的に身につけたい方へ、メルマガで実践的なセキュリティ対策ノウハウをお届けしています。
