コンテンツにスキップ

セキュリティ設定

Orbiee のセキュリティは、多層防御の設計思想に基づいています。PostgreSQL RLS によるテナント分離、Clerk による認証、トークンの暗号化、監査ログによるトレーサビリティを組み合わせて、組織のデータを安全に保護します。

テナント分離(マルチテナンシー)

Section titled “テナント分離(マルチテナンシー)”

PostgreSQL RLS(行レベルセキュリティ)

Section titled “PostgreSQL RLS(行レベルセキュリティ)”

Orbiee では、すべての主要テーブルに tenant_id カラムを持たせ、PostgreSQL の RLS によりデータベースレベルでテナント分離を強制しています。

テナント分離は以下の 2 つのレイヤーで保証されます。

  1. PostgreSQL RLS: データベースレベルでの tenant_id フィルタリング
  2. アプリケーションレベルのフィルタ: すべての CRUD 関数で tenant_id を必須パラメータとして要求

両方のレイヤーが同時に機能するため、一方に不具合があってもデータ漏洩を防止できます。

DB ロール権限用途
agent_read参照のみ(RLS で tenant_id 強制)AI エージェントの読み取り
agent_rw_limiteddrafts / proposals / tasks / agent_runs への書き込みAI エージェントの書き込み
app_apply正テーブル(deals 等)への更新Proposal 承認後の Apply 処理

Google OAuth のアクセストークン・リフレッシュトークンは、Fernet 暗号化(AES-128-CBC ベース)で暗号化して保管されます。暗号化キー(TOKEN_ENCRYPTION_KEY)は環境変数で管理され、コードにハードコーディングされることはありません。

暗号化対象:

  • Google OAuth アクセストークン
  • Google OAuth リフレッシュトークン
  • Slack 連携トークン

すべての通信は TLS で暗号化されます。

Orbiee は Clerk を使用して認証を管理しています。ユーザーは Google OAuth 2.0 でサインアップ・サインインします。

  • パスワードの管理は Google に委託されるため、Orbiee 側でのパスワード漏洩リスクがありません
  • 完全招待制のため、招待リンクがないとサインアップできません

フロントエンドからバックエンドへの API リクエストには、Clerk が発行する JWT トークンが使用されます。バックエンドは JWT を検証し、ユーザー情報とテナント情報を取得します。

セッション管理は Clerk に委託されています。

設定
セッション有効期限7 日間(10,080 分)
アイドルタイムアウト60 分
同時セッション複数デバイスからのログイン許可
JWT 有効期限5 分(自動更新)

AI エージェント(Claude Code)が直接書き込み可能なテーブルは制限されています。

  • 直接書き込み可能: drafts、proposals、tasks、agent_runs、customers、contacts
  • 承認が必要: deals、activities(Proposal フロー経由)

プロンプトインジェクション対策

Section titled “プロンプトインジェクション対策”
  • メール本文は「命令」ではなく「データ」として扱われます
  • AI エージェントの書き込み先が制限されているため、仮にインジェクションが成功しても被害が限定されます

Heavy Worker(Claude Code)は専用のワークスペース内で実行され、ソースコード・環境変数・シークレットファイルへのアクセスが禁止されています。

データの削除はソフトデリート(deleted_at タイムスタンプ)が基本です。ハードデリートは保持期間経過後にのみ実行されます。

  • バックエンドで Pydantic によるスキーマバリデーション
  • SQLAlchemy ORM によるパラメータ化クエリ(SQL インジェクション防止)

許可されたオリジンからのリクエストのみを受け付けます。

  • http://localhost:3000(開発環境)
  • https://app.orbiee.jp(本番環境)

API ゲートウェイレベルでレート制限が実装されています(デフォルト: 100 リクエスト/分/ユーザー)。