マルチテナント分離
すべての業務テーブルをorganizationに紐づけ、support_program依存データも明示的に分離します。
Security
守る対象は、案件データだけではありません。
テナント間の漏洩、顧客への誤送信、データ損失を優先リスクとして扱い、画面・サーバー・データベースの各層で防ぎます。
Defense in depth
一つのチェックに依存しない、多層の防御。
クライアントが送るorganization_idを信用せず、認証済みユーザーの所属情報からアクセス範囲を決定します。
認証・認可
UIの非表示だけに頼らず、サーバー側でmembershipとroleを検証。DBではRLSを強制します。
メール送信の保護
ブラウザから直接送らず、キュー、送信ロック、action_request_id、冪等性キーで重複を防ぎます。
監査ログ
権限、案件、メール、配送、設定、請求などの重要操作を、実行者と対象を含めて記録します。
ファイル保護
容量とMIMEを検証し、公開URLではなく有効期限付きの署名付きURLでアクセスを制御します。
外部連携
StripeなどのWebhook署名を検証し、イベントIDを使った冪等処理と失敗履歴を残します。
データ保全
既存データはマイグレーションで保持し、削除ルール、バックアップ、エクスポート、保持期間を管理します。
アプリケーション保護
入力検証、CSRF・XSS対策、Security Headers、CSP、依存監査を継続して運用します。
Tenant isolation
リクエストからDBまで、同じ所属条件を貫く。
外部パートナーには割り当てられたsupport_programまたは案件だけを許可し、他企業・他仕入先のデータを取得できない設計です。
認証済みユーザー
session / membership
サーバー認可
role / program scope
PostgreSQL RLS
organization policy
テナント横断アクセスが拒否されることを統合テストで確認します。
Operational security
安全性を、運用でも維持する。
本番と開発の認証情報を分離し、秘密情報をクライアントや通常ログへ出しません。
環境分離
Supabase、Stripe、メール送信元を開発・本番で分離します。
ログ最小化
個人情報やメール本文全体を通常ログへ残しません。
停止と復旧
請求・セキュリティ事象に応じてorganizationを停止し、監査付きで復旧します。
退会・保持
保持期間、エクスポート、削除を権限と監査の下で実行します。
認証・認定に関する表示方針
取得していないISO認証、SOC 2、第三者認定は表示しません。認証取得状況や外部監査結果は、事実として確認できる情報だけを掲載します。