セキュリティポリシー

1. 基本方針

前川クリストファー海（屋号: Marupass、以下「当社」）は、サイバーセキュリティ基本法第7条が定めるサイバー関連事業者の責務に基づき、本サービスの情報システム及び情報通信ネットワークの安全性・信頼性の確保に、自主的かつ積極的に取り組みます。

本ポリシーは、個人情報の保護に関する法律（APPI）第23条が定める安全管理措置義務、及び金融情報システムセンター（FISC）安全対策基準V13の技術基準を踏まえ、当社の情報セキュリティ管理体制を定めるものです。Tier-1金融機関のベンダー評価に耐えうる水準を目指し、以下の原則を遵守します。

• 最小権限の原則（Least Privilege）：すべてのアクセスは、業務遂行に必要な最小限の権限に制限されます。
• ゼロトラストアーキテクチャ：ネットワーク境界ではなく、各リクエストの認証・認可を信頼の基盤とします。
• 多層防御（Defense in Depth）：単一の防御層の突破がシステム全体の侵害につながらない多層構造を維持します。
• 改ざん不可能な証跡（Immutable Audit Trail）：全てのセキュリティ上重要な操作は、WORM監査台帳に記録されます。

2. 準拠規格・ガイドライン

本サービスのセキュリティ管理体制は、以下の法令・規格・ガイドラインに準拠して設計・運用されています。

FISC V13カテゴリ別コントロールマッピング

3. インフラストラクチャ

本サービスは、Google Cloud Platform（GCP）上に構築されたフルマネージドインフラストラクチャで運用されます。

すべての永続データは日本国内リージョンに保管されます（EUテナントのお客様はフランクフルトリージョンをご利用いただけます）。Anthropic Claude APIへのアクセスはVertex AI Model Gardenのリージョン指定エンドポイント経由で行われ、テナントのoperating_region設定に準拠したリージョン内で処理が完結します。

3.2 マルチリージョンデータレジデンシー

3.3 ファイルアップロードのセキュリティ検証

4. マルチテナント分離アーキテクチャ

4.1 行レベルセキュリティ（RLS）による論理分離

本サービスのPostgreSQLデータベースでは、すべてのテナントデータテーブルに対してRow Level Security（RLS）ポリシーが適用されています。テナント分離は、以下のメカニズムにより強制されます。

• セッション変数による分離：すべてのデータベース接続は、アプリケーション層のtenant_connection()コンテキストマネージャを経由します。この関数は、JWTクレームから取得したテナントIDをSET LOCAL app.current_tenant_idとしてPostgreSQLセッション変数に設定します。
• RLSポリシーの強制：各テーブルのRLSポリシーは、current_setting('app.current_tenant_id')::UUID = tenant_id条件により、当該テナントのレコードのみを返します。このフィルタリングはデータベースエンジンレベルで実行されるため、アプリケーションコードのバグによるバイパスは不可能です。
• テナント横断クエリの禁止：アプリケーションのデータベースロールにはBYPASSRLS権限が付与されていないため、RLSポリシーを回避するSQLの実行は不可能です。
• トランザクションスコープの自動クリア：SET LOCALはトランザクション終了時（COMMIT/ROLLBACK）に自動クリアされるため、接続プール上でテナントIDが次のリクエストに漏洩するリスクは設計上排除されています。
• テーブルオーナーへのRLS強制：usersテーブルにはFORCE ROW LEVEL SECURITYが適用されており、テーブルオーナー（データベース管理ロール）に対してもRLSが強制されます。

4.2 親子テナントのアクセス境界

金融機関（親テナント）がBank RMポータルを通じてアクセスできるデータは、以下の範囲に厳格に制限されています。

• 許可：自社が招待したSMEクライアント（子テナント）のポートフォリオ集計データ（SLL適格性スコア、CO₂排出量トレンド、コベナント達成率）
• 禁止：個別の子テナントの原本ファイル、未加工の光熱費請求書データ、個別サプライヤー名
• 強制メカニズム：ポートフォリオAPIはparent_tenant_id外部キーに基づく明示的なWHERE tenant_id = ANY($1::UUID[])クエリを使用し、RLSとは独立した追加の境界チェックを実施します。
• ポートフォリオRLS制御：銀行パートナーのモニタリング機能では、RLSポリシー内でapp.portfolio_tenant_idsセッション変数を使用し、許可されたテナントのデータのみを読取り専用でアクセスします。子テナントIDの自動取得（include_children=True）もRLSスコープ内で行われます。

5. ゼロトラスト監査人ブリッジ（Data Room）

外部監査人がお客様のESGデータにアクセスする際、当社はJWTやセッションCookieに依存しない、PostgreSQLバックドのゼロトラストアーキテクチャを採用しています。

5.1 認証：不透明トークン方式

• 監査人アクセスには、JWTではなくPostgreSQLテーブルに保管される不透明な暗号学的トークン（Opaque Token）を使用します。トークンの有効性はデータベースルックアップにより検証されるため、署名鍵の漏洩リスクが排除されます。
• トークンには有効期限が設定され、管理者はDELETE /api/data-room/share/{session_id}エンドポイントを通じていつでも即座に失効させることができます。
• JWTと異なり、トークンの失効はデータベースの行削除で即時反映されます。JWTの「有効期限まで取り消し不可能」というリスクを設計上排除しています。

5.2 認可：専用PostgreSQLロールと列レベルセキュリティ

6. データ暗号化

6.1 転送時の暗号化

• すべてのクライアント-サーバー間通信はTLS 1.3で暗号化されます。TLS 1.2以前のプロトコルは無効化されています。
• 内部マイクロサービス間の通信は、GCPのVPCネットワーク内で完結し、mTLS（相互TLS認証）により保護されます。

6.2 保管時の暗号化

• Cloud SQL（PostgreSQL）：AES-256による透過的データ暗号化（TDE）が適用されています。
• Cloud Storage：サーバーサイド暗号化（SSE）がすべてのオブジェクトに自動適用されます。
• 機密フィールド（ESG排出量数値、サプライヤー情報等）には、テナント固有のCustomer Managed Encryption Key（CMEK）による追加暗号化レイヤーが適用されます。

6.3 クライアント側暗号化

オフライン通報機能では、クライアント側でAES-256-GCM + RSA-OAEP-2048ハイブリッド暗号化を適用し、ブラウザ内IndexedDBに暗号文として保存します。復号はサーバー側の秘密鍵でのみ可能であり、クライアント側では平文にアクセスできません。

6.4 フィールドレベル暗号化

6.5 鍵管理

• 暗号鍵はGoogle Cloud KMSで管理され、HSM（Hardware Security Module）バックドの鍵保護が提供されます。
• 鍵のローテーションは90日間隔で自動実行されます。
• 鍵へのアクセスはIAMポリシーにより制限され、すべてのアクセスがCloud Audit Logsに記録されます。
• フェイルクローズド設計：KMS_REQUIRED=true設定時、KMS初期化が失敗した場合はアプリケーションが起動を停止します。弱い暗号化へのサイレントフォールバックを設計上排除しています。

6.6 ハッシュ化アルゴリズム

7. WORM監査台帳

本サービスの監査証跡は、Write Once Read Many（WORM）アーキテクチャにより保護されています。

7.1 WORM保護対象テーブル

以下の4テーブルにDELETE/UPDATEを拒否するPL/pgSQLトリガーが適用されています。

• audit_lineage_log — ESGデータの監査証跡チェーン
• user_confirmation_log — ユーザー確認操作の記録
• system_audit_log — システム操作ログ（IPアドレス、User-Agent含む）
• procurement_messages — 調達メッセージ（WORM不変）

7.2 メカニズム

• PostgreSQLトリガーによる強制：WORM台帳レコードに対するUPDATE及びDELETE操作は、データベーストリガーにより拒否されます。アプリケーションコードによるバイパスは設計上不可能です。
• 記録対象：ESG Ledgerへの全INSERT操作、ドキュメント処理パイプラインの各ステージ遷移、監査人Data Roomの開設・閉鎖、ユーザー権限変更、エクスポート操作。
• 完全性検証：verify_chain()関数が全ハッシュを再計算し、不整合が検出された場合はbroken_atシーケンス番号で報告します。

7.3 チェーンハッシュアルゴリズム

7.4 仮名化アカウンタビリティ

WORM台帳内のユーザー識別には、SHA-256ベースの仮名（Pseudonym）を使用します。仮名はSHA256("{tenant_id}:{user_id}")から決定的に生成され、元の個人情報への逆変換は不可能です。監査上の必要がある場合のみ、actor_resolutionテーブルを通じて実ユーザーとの紐付けが可能です。GDPR削除請求時にはこのテーブルの該当行をCASCADE削除することで、仮名と実ユーザーのリンクを永久に切断します（暗号学的シュレッディング）。

WORM書込み前に以下のPIIフィールドが自動除去されます：user_id, email, name, phone, ip_address。除去が実行された場合はWARNINGログが記録されます（多層防御）。

7.5 GDPR Tombstone

8. ネットワークセキュリティ及びアクセス制御

8.1 外部からの防御

• インバウンドメール：SendGrid ECDSA署名検証（X-Twilio-Email-Event-Webhook-Signatureヘッダー）により、偽造ペイロードを拒否します。署名検証に失敗したリクエストは403 Forbiddenで応答します。
• 送信元ホワイトリスト：署名検証後、送信者メールアドレスをテナント設定のwhitelisted_emailsと照合します。完全一致（user@corp.co.jp）及びドメインワイルドカード（@corp.co.jp）をサポートします。
• WAF：Google Cloud Armorにより、OWASP Top 10攻撃（SQLインジェクション、XSS等）をネットワーク境界でフィルタリングします。

8.2 内部マイクロサービス間認証（OIDC）

8.3 HTTPセキュリティヘッダー

8.4 CORS設定

• 許可オリジン： FRONTEND_URL + CORS_EXTRA_ORIGINS
• クレデンシャル： Yes
• メソッド： GET, POST, PATCH, DELETE, OPTIONS
• ヘッダー： Authorization, Content-Type, Accept-Language, X-API-Key

8.5 レートリミット

レスポンスヘッダー：X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset。Redis不可用時はフェイルオープン（可用性を優先した設計判断）。

8.6 SSRF防護

Enterprise Webhookのアウトバウンド送信においてSSRF防護を実装しており、localhost、クラウドメタデータエンドポイント、プライベートIP範囲への送信をブロックしています。

8.7 Webhook安全ミドルウェア

外部サービスからのWebhook受信エンドポイント（SendGrid、LINE、Twilio WhatsApp、SCIM等）では、例外発生時もHTTP 200を返却する安全ミドルウェアを実装しており、無限リトライループを防止しています。Stripe Webhookは署名検証のため実際のHTTPエラーコードが必要であり、この保護の対象外です。

8.8 認証メカニズム全体像

8.9 ロールベースアクセス制御（RBAC）

認可判定はrequire_permission(permission_name)関数により行われ、ロール直接比較よりも優先されます。スコープ付きロールのIntEnum階層バイパスリスクを回避する設計判断です。

8.10 アプリケーション層セキュリティ

• IDOR防止：テナントIDはJWTクレームからサーバーサイドで取得されます。URLパラメータやリクエストボディからテナントIDを受け付けないため、IDOR攻撃は設計上排除されています。
• 入力値検証：すべてのAPIエンドポイントはPydantic v2の型付きリクエストモデルにより入力値を検証します。不正な入力は422 Unprocessable Entity（RFC 7807準拠）で拒否されます。
• Feature Flag Gating：Enterprise機能（SSO/SCIM、Procurement Marketplace、SLL Finance、Enterprise API等）はテナント単位のfeature_flags JSONB設定により制御されます。フラグが無効なテナントからのアクセスはHTTP 403で拒否されます。

9. セキュリティインシデント対応

個人情報保護法第26条（漏えい等の報告等）に基づき、当社は以下のインシデント対応手順を定め、運用しています。

9.1 インシデント対応タイムライン

9.2 通知の対象となるインシデント

個人情報保護委員会規則に基づき、以下の事態が発生した場合に報告・通知義務が生じます。

• 要配慮個人情報の漏えい
• 財産的被害が生じるおそれがある個人データの漏えい
• 不正アクセスによる個人データの漏えい
• 1,000人を超える個人データの漏えい

9.3 金融機関パートナーへの追加通知

親テナント（金融機関）に影響を及ぼすインシデントが発生した場合、法定の通知義務に加え、以下の追加対応を行います。

• 金融機関の指定する連絡窓口への優先通知（検知後24時間以内を目標）
• 影響を受ける子テナント（SME）の一覧と影響範囲の提供
• 金融庁への報告が必要な場合の情報提供支援

10. 事業継続・災害対策

• データバックアップ：Cloud SQLの自動バックアップが日次で実行されます。バックアップは7日間保持されます。
• ディザスタリカバリ（DR）：大阪リージョン（asia-northeast2）にCloud SQLのリードレプリカが配置されています。東京リージョンの全損時には、大阪リージョンへのフェイルオーバーが可能です。
• RPO（目標復旧時点）：最大24時間（日次バックアップ間隔）。
• RTO（目標復旧時間）：4時間（Cloud Runの自動デプロイ + Cloud SQLフェイルオーバー）。
• WORM台帳の耐障害性：監査台帳のハッシュチェーンはリードレプリカにリアルタイムで複製されるため、プライマリデータベースの喪失時も監査証跡の完全性が維持されます。

11. 脆弱性管理

• 依存関係の監視：Python（pip-audit）及びNode.js（npm audit）の依存パッケージを定期的にスキャンし、既知の脆弱性を検出します。
• コンテナイメージ：本番Dockerイメージはpython:3.11-slimベースであり、不要なシステムパッケージを最小限に抑えています。
• セキュアコーディング：OWASP Top 10に準拠したセキュアコーディングガイドラインに従い開発しています。SQLインジェクション対策（パラメータ化クエリ）、XSS対策（React自動エスケープ）、CSRF対策（SameSite Cookie）が実装されています。
• ファイル検証：アップロードされたファイルは、ファイル拡張子に加えてマジックバイト検証（%PDF、PK\x03\x04、UTF-8テキスト）により内容の整合性を確認します。拡張子とマジックバイトが一致しないファイルは拒否されます。
• シークレット管理：すべてのAPIキー、データベースパスワード、暗号鍵はGoogle Cloud Secret Managerで管理されています。ソースコードリポジトリにシークレットを格納しません。

12. セキュリティ評価・監査への対応

当社は、お客様（特に金融機関パートナー）のベンダーセキュリティ評価に対し、以下の資料を提供いたします。

• CSA CAIQ v4.0.2自己評価書：17ドメイン・262項目の回答を完了済み（246 Yes / 15 N/A / 0 No）。Excel及びPDF形式で提供可能です。
• FISC安全対策基準V13ホワイトペーパー：7カテゴリに対するSCXコントロールマッピングを、ライブデータベースエビデンス（最新WORMアンカーハッシュ、Data Roomセッション数、RLSポリシー確認結果）とともに提供するAPIエンドポイントを実装済みです。
• 個別質問票への対応：金融機関固有のセキュリティチェックシートへの回答に対応いたします。ご依頼はsecurity@scxaudit.comまでお問い合わせください。

13. データルーム・召喚状セッションのセキュリティ

14. Impersonation（なりすまし）制御

SUPER_ADMINがサポート目的でユーザーコンテキストに切り替える場合、専用のimpersonationトークン（scx.impersonation-token、有効期限1時間）が発行されます。このトークンはhttpOnly Cookieとして管理され、すべての操作がWORM監査台帳に記録されます。

15. Cookieセキュリティ

当サービスは機能上必要なCookieのみを使用し、アナリティクスCookie及び広告トラッキングCookieは一切使用しません。