BtoB SaaS セキュリティ設計総覧 — 多層防御と採用判断

🎯 はじめに：BtoB SaaS のセキュリティは「多層防御」で考える

本記事はシリーズ 「BtoB SaaS セキュリティ設計」の第 1 回（総論） です。当社が運営する BtoB マルチテナント SaaS（社内呼称: CTS-EC）で実際に採用しているセキュリティ対策を、設計判断と効果に絞って総覧します。

BtoB マルチテナント SaaS は、複数の顧客企業のデータを単一基盤に束ねるため、 攻撃者にとって攻撃価値が高い標的 です。一方で守る側は単一の銀の弾丸では守りきれません。そこで採るのが 多層防御（Defense in Depth） という考え方です。

どこか 1 層が破られても、次の層で食い止める。各層は独立して責務を持ち、互いに補完し合う。

本記事では、当社の SaaS におけるセキュリティを以下の 8 軸で整理します。

1. 認証層（誰であるかを確かめる）
2. 認可層（何ができるかを決める）
3. 通信・ネットワーク層（経路を守る）
4. インフラ・キーレス認証（基盤の信頼の根を作る）
5. データ保護（データそのものを守る）
6. 開発環境セキュリティ（作る場所を守る）
7. 監査・検知（事後に追跡できる）
8. コンプライアンス（法令・基準への対応）

各層の 「何を採用したか」「なぜ採用したか」「採用しなかった選択肢」「今後の対策」 を簡潔に示します。深掘りは次回以降のシリーズに委ねます。

🔐 認証層：AWS Cognito Essentials + パスキー

採用しているもの

• AWS Cognito User Pool（Essentials tier） をマネージド認証基盤として採用
• パスキー（WebAuthn / FIDO2） をネイティブ対応機能として有効化
• パスワード認証とパスキー認証を 併用 し、デバイス紛失時のフォールバック経路を確保
• 既存ユーザーへの 段階的移行（強制せず、初回ログイン後にパスキー登録を促す）

なぜパスキーか

パスキーは現時点で 最もフィッシング耐性が高い認証方式 です。秘密鍵が認証器（端末・セキュリティキー）から外に出ず、リライング・パーティのドメインに対してのみ署名するため、偽サイトへの誘導が成立しません。SMS や TOTP よりも強力で、ユーザー体験も生体認証 1 タップで完結します。

なぜ Plus tier（Adaptive Authentication）を採用しなかったか

Plus tier は IP リスク評価・侵害クレデンシャル検知などの脅威保護機能を提供しますが、月間アクティブユーザー単位での追加課金が発生します。当社の SaaS は 管理者向けログインに限定し、セルフサインアップを許可しない運用 のため、外部からの大量ブルートフォース等の脅威ベクトルが小さく、 Essentials tier + パスキーで十分 と判断しました。コストと脅威モデルのトレードオフによる選択です。

Google Cloud Identity Platform を選ばなかった理由

公式ドキュメント上、Google Cloud Identity Platform / Firebase Authentication は OIDC OP（Identity Provider）として SPA・モバイルに OIDC with PKCE を提供する仕組みを持ちません 。また WebAuthn / パスキーのネイティブ対応もありません。この経緯と裏付けは シリーズ第 2 回 で詳しく扱います。

🚪 認可層：3 層防御 と DB SSOT 方式

認可は「誰かがログインできた」あとの話です。認証が破られたとしても、認可で被害範囲を絞り込めれば全体への波及を抑えられます。当社では認可を 3 層で多重化 しています。

このうち Layer 3 で採用しているのが DB SSOT 方式（Database as Single Source of Truth） です。テナントコードやロール情報を JWT に埋め込まず、 API リクエスト到達時に DB から再解決 します。

JWT に権限情報を埋め込む方式は高速ですが、 JWT の有効期限内はロール剥奪・テナント停止が反映されない という致命的な欠点があります。BtoB SaaS では「契約終了したテナントを即時遮断したい」「不正利用を発見したらすぐ権限を剥奪したい」というニーズが頻出するため、 即時性を優先して DB SSOT を選択 しました。アクセス頻度の高いマスタはインプロセスキャッシュ（短い TTL）で性能劣化を抑えています。

詳細はシリーズ第 4 回で扱います。

🌐 通信・ネットワーク層：TLS / mTLS / CORS

採用しているもの

• HTTPS / TLS をすべての外向き・内向き通信で強制
• mTLS（クライアント証明書）で API 〜 Cloud SQL 間の接続を相互認証
• CORS はフロントエンドのオリジンをホワイトリスト化し、メソッドとヘッダを最小化
• Cookie は Secure HttpOnly SameSite=Lax を基本とし、CSRF 対策を実装

まだ採用していないもの（今後の対策）

• WAF（Web Application Firewall） : OWASP Top 10 への網羅的な防御として優先度の高い課題
• CSP（Content Security Policy） : XSS 防御の最後の砦として導入予定
• CDN によるエッジ防御 : DDoS 緩和とキャッシュ戦略

通信層の整備は「攻撃者の経路を狭める」ことが本質で、認証・認可で守りきれない部分を補完します。

🔑 インフラ・キーレス認証：WIF / Secret Manager / IAM 最小権限

クラウド時代のセキュリティの根は、 「静的な鍵をどれだけ無くせるか」 にあります。長寿命の API キー・サービスアカウントキーは漏洩時の被害が大きく、ローテーション運用も負担が大きいためです。

当社の対策：

• WIF（Workload Identity Federation） : CI から GCP への認証は静的鍵ではなく短命トークンに置き換え。GitHub / GitLab Actions の OIDC アサーションを GCP IAM が検証して キーレスで権限付与
• GCP Secret Manager : 本番のシークレットは一元管理し、Cloud Run のサービスアカウント経由でランタイム取得
• 開発環境 : dotnet user-secrets 等の Git 管理外のローカルストアを利用し、リポジトリへのコミットを物理的に防止
• IAM 最小権限 : サービスアカウントを機能ごとに分割し、必要最小限のロールのみを付与

WIF はシリーズ第 5 回で詳しく扱います。

💾 データ保護：マルチテナント分離と監査

マルチテナント SaaS の根本リスクは 「テナント A のデータがテナント B に漏れる」 こと（クロステナントリーク）です。当社は 論理分離を徹底 する設計を選択しました。

• Conjoined Multi-Tenancy : 各テーブルにテナント識別子を持たせ、ORM レベルで自動フィルタリング
• schema per tenant : 必要に応じて PostgreSQL スキーマで物理的に分離し、検索パスを切り替え
• 接続暗号化 : Cloud SQL への接続は TLS 必須、接続文字列も保管時に暗号化
• 監査ログ : ドメインイベント基盤で業務上重要な操作（注文・在庫変更等）を イミュータブルに記録
• 削除はソフトデリート : 復元可能性と監査要件を両立

ハードな物理分離（テナントごとの独立 DB）は採用していません。BtoB SaaS としては運用コストとオンボーディング速度を優先し、 論理分離 + ORM レベルの強制 + テスト網羅 で実用上のリスクを抑える選択です。

🧪 開発環境セキュリティ：DevContainer による作業範囲の隔離

AI 駆動開発が一般化し、ローカル環境にエージェントがコードを書く時代では、 開発環境そのものが攻撃面 になります。当社の対策：

• DevContainer で開発環境をコンテナ化し、AI エージェントの アクセス範囲をプロジェクトディレクトリに限定
• 認証情報（SSH 鍵、クラウド認証ファイル）は 読み取り専用マウント とし、書き換え・上書きを防止
• no-new-privileges:true で 特権昇格を禁止
• IDE 拡張・MCP サーバーは コンテナ内に閉じ込める

「AI が万一暴走しても、ホスト環境にも顧客データにも到達できない」状態を作ることで、開発者は安心して AI 駆動開発の高速化を享受できます。詳細はシリーズ第 8 回で扱います。

📊 監査・検知：Cloud Audit Logs + ドメインイベント

「攻撃を完全に防ぐ」ことは不可能なので、 「起きたことを後追いで再現できる」状態を保つ のが監査の役割です。

• Cloud Audit Logs : クラウド基盤側の操作（IAM 変更・リソース作成等）を全件記録
• Cloud Run / Cloud SQL ログ : ランタイムの挙動を時系列で保管
• アプリケーションのドメインイベント : 業務上の重要操作を共通カーネルで記録し、後続処理（通知・集計）と監査ログを 同じ流れで生成
• Wolverine の DLQ（Dead Letter Queue） : 失敗したメッセージ処理を保持し、原因調査と再実行を可能に

リアルタイム異常検知ダッシュボードは今後の対策に位置づけています。

📋 コンプライアンス：個人情報保護法を起点に

BtoB SaaS では取り扱うデータの多くが顧客企業の 個人情報・取引情報 です。当社のコンプライアンス対応は次の通りです。

• 個人情報保護法：適切なアクセス制御（RBAC）、テナント停止時の 即時遮断（DB SSOT 方式により実現）、削除要求への対応プロセス
• テナント単位の管理境界：契約上の責任分界をシステム上の境界と一致させる
• SOC 2 / ISMS 認証：現時点では未取得。将来の事業拡大フェーズに合わせて取得検討

「認証取得そのものを目的化しない。実装が伴わない認証は無意味」という方針のもと、 まず実装を整え、必要が顕在化した段階で認証取得に進む 段取りを取っています。

🚀 今後のセキュリティロードマップ

総論の最後に、現時点で 採用していない／弱い領域 を明示します。これがシリーズの後続記事で扱う各論のロードマップにもなります。

• WAF / CSP の導入 : 通信層の網羅的防御
• DB 列レベル暗号化（PII フィールド個別） : 漏洩時の影響範囲を最小化
• CI への SAST / Secret Scanning 組み込み : Pre-commit と GitLab CI の二段で検知
• リアルタイム異常検知 : ログ集約 + アラートで深夜帯の攻撃にも即応
• ゼロトラストへの段階移行 : デバイス検証・コンテキストベース認可の導入
• Cognito Plus tier の再評価 : ビジネス成長に応じた脅威モデル変化への追随

セキュリティはプロダクトとともに進化させる継続的な投資です。 「できていない部分を可視化し続ける」 ことが、改善のスタート地点だと考えています。

📚 シリーズ記事

📖 関連用語

• 多層防御 — 独立した複数の層で重ねて防御する設計思想
• ゼロトラスト — ネットワーク位置に依存せず ID で毎回検証するモデル
• BeyondCorp — Google の VPN 廃止型ゼロトラスト実装
• ネットワーク境界モデル — ゼロトラストが置き換える古いモデル
• パスキー — フィッシング耐性が極めて高いパスワードレス認証
• WebAuthn — W3C 標準の Web 認証 API、パスキーの基盤
• FIDO2 — WebAuthn と CTAP からなるパスワードレス認証の標準仕様群
• OAuth 2.0 — Web の認可フレームワーク（RFC 6749）
• OpenID Connect — OAuth 2.0 上の認証層
• PKCE — OAuth 2.0 で認可コードの横取りを防ぐ拡張仕様
• state / nonce — CSRF とリプレイ攻撃を防ぐパラメータ
• ID Token — OIDC が発行する署名付き JWT
• SAML — エンタープライズ SSO の XML プロトコル
• Adaptive Authentication — リスクベース認証
• IPv6 — NAT 不要のエンドツーエンド原則を復活させた IP 仕様
• Workload Identity Federation — 静的な鍵を使わないクラウド権限付与
• AWS Cognito — マネージド認証・認可サービス
• SSoT（Single Source of Truth） — 「真実の唯一の出典」を 1 箇所に集約する考え方

セキュリティは「終わらない投資」です。本シリーズが、自社の SaaS でセキュリティを設計する際の 判断軸 として役立てば幸いです。