- SaaS開発で最低限対応すべきセキュリティ要件
- マルチテナントアーキテクチャにおけるデータ分離設計
- 認証・認可の実装方法（MFA・SAML・RBAC）
- ISO 27001・SOC 2・GDPRなどのコンプライアンス認証の概要と取得優先度
- セキュリティ対応を段階的に進めるロードマップ
なぜSaaSのセキュリティ対応が重要か
SaaSは複数の顧客データをひとつのシステムで管理するため、セキュリティインシデントが発生した場合の影響範囲が広く、ビジネスへのダメージが甚大です。また、エンタープライズ顧客へのSaaS販売では、セキュリティ審査（ベンダー審査）が必須となるケースが増えており、対応できていないとそもそも契約に至りません。
SaaSのセキュリティリスク
| リスク種別 | 具体的なリスク | 影響 |
|---|---|---|
| データ漏洩 | テナント間のデータ混在、不正アクセスによる全顧客データ流出 | 最大 |
| 認証の脆弱性 | パスワード総当たり、セッション固定攻撃 | 高 |
| インジェクション攻撃 | SQLインジェクション、XSSによるデータ改ざん・窃取 | 高 |
| APIの脆弱性 | 認証不備・レート制限なしAPIの悪用 | 中〜高 |
| 依存パッケージの脆弱性 | OSS・ライブラリの既知脆弱性の未対応 | 中 |
マルチテナントアーキテクチャのデータ分離設計
SaaSのセキュリティで最も重要なのが、テナント間のデータ分離です。「あるテナントのデータが別のテナントから見える」という状態は、致命的な欠陥になります。
データ分離の3パターン
| パターン | 分離方法 | 分離の強さ | コスト | 向いている用途 |
|---|---|---|---|---|
| DB per Tenant | テナントごとに独立したDB | 最高 | 高 | エンタープライズ・コンプライアンス要求が高い場合 |
| Schema per Tenant | 同一DB内でスキーマを分離 | 高 | 中 | 中規模SaaS・PostgreSQL環境 |
| Row-Level Security | 共有テーブルにtenant_idカラムで分離 | 中（実装依存） | 低 | 小規模SaaS・コスト重視 |
Row-Level Security方式を選択する場合、すべてのクエリに必ずtenant_idフィルタが付いていることを保証する仕組み（ORMのスコープ・ミドルウェア）が必須です。一箇所でもフィルタが抜けると、全顧客データが漏洩するリスクがあります。
FUNBREWが推奨するアプローチ
FUNBREWでは、コストと安全性のバランスからSchema per Tenant方式を基本として推奨しています。テナント数が少ない初期フェーズでは運用コストも現実的で、かつ分離の強さも十分です。マルチテナント設計の詳細はマルチテナントSaaSの設計と実装をご参照ください。
認証・認可の実装
認証（Authentication）の要件
必須対応
- 多要素認証（MFA）: 特に管理者・高権限ユーザーには必須化を推奨
- パスワードポリシー: 最低8文字・複雑性要件・定期変更の強制
- ブルートフォース対策: 連続ログイン失敗時のアカウントロック・CAPTCHA
- セッション管理: セッションタイムアウト・同時ログイン数制限
エンタープライズ向け追加対応
- SAML/SSO: 企業のIdP（Okta・Azure AD等）との連携。大企業は独自IdPを持つため必須になることが多い
- SCIM: ユーザーのプロビジョニング自動化（入退社時のアカウント自動作成・削除）
認可（Authorization）の設計
RBAC（Role-Based Access Control）を基本として設計します。
- ロール設計: 最小権限の原則に基づき、必要な権限のみを付与
- テナント管理者: 自テナント内の管理権限のみ
- エンドユーザー: 自分のデータの読み書きのみ
- SaaS管理者: 全テナントを管理できるが、業務データは閲覧不可（プライバシー保護）
APIセキュリティ
SaaSはAPI経由でのアクセスが多いため、APIセキュリティは特に重要です。
APIセキュリティの基本対策
- 認証: すべてのAPIエンドポイントに認証を必須化（OAuth 2.0 / API Key）
- レート制限: DDoS・ブルートフォース対策のためのリクエスト制限
- 入力バリデーション: すべての入力値を検証し、インジェクション攻撃を防止
- HTTPSの強制: HTTP通信を全面的に禁止
- CORS設定: 許可するオリジンを最小限に制限
コンプライアンス認証の種類と優先度
主要なコンプライアンス認証
| 認証 | 対象 | 内容 | 取得優先度 |
|---|---|---|---|
| ISO 27001 | グローバル・国内大手 | 情報セキュリティマネジメントシステム。最も普及した国際標準。 | 高 |
| SOC 2 Type II | 北米エンタープライズ | セキュリティ・可用性・機密性の監査報告書。米国企業との取引に必要なケースが多い。 | 北米展開時 |
| Pマーク | 国内中堅・官公庁 | 個人情報保護の国内認証。官公庁案件では必須なことがある。 | 中 |
| GDPR対応 | EU顧客がいる場合 | 欧州一般データ保護規則。EU在住者のデータを扱う場合は法的義務。 | EU展開時 |
| クラウドセキュリティ認証（ISMAP等） | 官公庁・自治体 | 政府情報システムのセキュリティ評価制度。官公庁向けSaaSには必要。 | 官公庁向け時 |
日本のSaaSスタートアップにおける推奨取得順序
- まず基盤整備: セキュリティポリシー策定・脆弱性スキャン・ログ監視の整備
- ISO 27001の取得: 国内大手企業との取引に最も汎用性が高い
- Pマーク: 官公庁・自治体・保守的な大企業向けに必要なケースがある
- SOC 2: 北米展開・グローバルSaaS化の際に取得
セキュリティ開発ライフサイクル（SDLC）への組み込み
セキュリティは後付けでなく、開発プロセスに組み込む（Shift Left）ことが重要です。
各フェーズでのセキュリティ対応
- 設計フェーズ: 脅威モデリング（STRIDE等）・セキュリティ要件の定義
- 開発フェーズ: OWASP Top 10を意識したコーディング・静的解析ツールの導入
- テストフェーズ: 脆弱性スキャン・ペネトレーションテスト（定期実施）
- 運用フェーズ: ログ監視・異常検知・パッチ管理・インシデント対応計画
セキュリティ対応ロードマップ
初期フェーズのSaaSが段階的にセキュリティ対応を強化するロードマップです。
フェーズ1（MVP〜初期顧客獲得）
- HTTPS強制・入力バリデーション・SQLインジェクション対策
- 認証実装（MFA対応・ブルートフォース対策）
- データバックアップ・暗号化
フェーズ2（SMB〜ミッドマーケット）
- セキュリティポリシーの文書化
- ペネトレーションテストの実施
- セキュリティ問い合わせ窓口（security@）の設置
- SAML/SSO対応
フェーズ3（エンタープライズ展開）
- ISO 27001取得
- SOC 2 Type II取得（北米展開時）
- ISMAP登録（官公庁向け）
- セキュリティオペレーションセンター（SOC）の整備
まとめ
SaaSのセキュリティ対応は、スタートアップ段階から計画的に進めることが重要です。最初からISO 27001取得を目指す必要はありませんが、マルチテナントのデータ分離設計・認証・APIセキュリティの基盤は、初期から正しく設計しておくことが後のリスクを大幅に減らします。
FUNBREWでは、SaaSの設計段階からセキュリティを組み込んだ開発を支援しています。「セキュリティ要件をどこから考えればいいか」「エンタープライズ向けのSAML/SSO実装をお願いしたい」というご相談もお気軽にどうぞ。
関連記事: SaaS開発ガイド｜プロダクト設計からリリースまでの全工程【2026年版】 / マルチテナントSaaSの設計と実装｜アーキテクチャの選び方 / SaaSのカスタマーサクセス戦略｜チャーン率を下げてLTVを最大化する方法
この記事をシェア