Fluera

アーキテクチャ

Fluera はノートをどう守るのか。

このページでは、技術的な読者 — セキュリティ責任者、大学の CISO、興味のある開発者 — が期待するレベルでセキュリティモデルを説明します。技術者向けでない要約は /ja/security から始めてください。

脅威モデル

デバイスの盗難、ネットワーク傍受、バックアップやクラウド同期経由での偶発的な露出を想定しています。ユーザーの認証情報が侵害される可能性も想定しています。想定しないのは、ロック解除されたデバイスへの物理アクセスを伴う国家レベルの攻撃者です。Fluera は秘匿性のためのツールではなく、学習のためのツールです。

このモデルの中で、3つの保証があります。

  • ローカルデータは鍵がなければ読めません。盗まれたデバイスからは暗号化された blob しか得られません。
  • 同期データは私たちにも読めません。クラウドには暗号文しか保存されません。鍵の導出はデバイス上で行われます。
  • テレメトリは同意制かつ非識別化されています。完全な侵害が発生しても、アナリティクスからユーザーとそのコンテンツを結びつけることはできません。

保存時: SQLCipher、AES-256

各 Fluera ノートは、SQLCipher で暗号化されたローカルの SQLite データベースに格納されます。SQLCipher は広く監査された拡張機能で、データベースの各ページを AES-256-CBC で透過的に暗号化し、ページごとに HMAC-SHA512 整合性チェックを行います。

鍵の導出には PBKDF2 + SHA-256、256,000回の反復 (OWASP 推奨に準拠) を使用します。パスフレーズはプラットフォームの keychain — iOS/macOS では Keychain、Android では Keystore、Windows では DPAPI、Linux では libsecret — に保存されます。当社のサーバーには決して送信されません。

転送時: TLS 1.3、証明書ピンニング

すべてのネットワーク通信は最新の暗号スイートを用いた TLS 1.3 です。iOS と Android では、企業プロキシによる中間者攻撃を防ぐために、当社の CA チェーンに対する証明書ピンニングを実施しています。必要なネットワーク管理者向けには、ドキュメント化されたオーバーライド手段も用意しています。

デバイス間同期: エンドツーエンド

クラウド同期を有効にした場合、デバイス上で導出される別の鍵セットを使用します。同期サーバー (Supabase Storage、EU リージョン) には暗号文のみが保存され、復号できません。同期はノート単位でオプトインです。一部のノートはローカルのみに留め、他のノートだけ同期するといった使い方ができます。

鍵のローテーション: 任意のデバイスから開始すると、以降のすべてのペイロードが新しい鍵で再暗号化されます。古い暗号文は、すべてのデバイスでマイグレーションを確認するまで、古いクライアントから引き続き読み取り可能です。

P2P コラボレーション: 直接、暗号化

リアルタイムコラボレーションには、DTLS-SRTP 暗号化を伴う WebRTC DataChannel を使用します。Supabase Realtime はシグナリング (接続セットアップ) のブローカーとしてのみ機能し、実際のキャンバストラフィックのリレーは行いません。ハンドシェイク後、キャンバスの編集はピアツーピアで流れます。サーバーはそれを見ません。

制限の厳しい NAT 環境では TURN を経由しますが、その場合でもリレーには復号できない暗号化された DTLS パケットしか見えません。

AI 呼び出し: プロキシ経由、直接ではない

Google Gemini への呼び出し (Socratic Mode、Ghost Map、LaTeX OCR、Exam Session) は、API キーをサーバー側に保管する Supabase Edge Function を経由します。クライアントデバイスはキーを見ません。プロキシはプランごとのレート制限を適用し、課金のために呼び出し時間をログに記録します。キャンバスのコンテンツは決してログに記録しません。

設定 → プライバシー で AI 機能を無効にすると、デバイス内 OCR フォールバックを含め、キャンバスのコンテンツが Gemini に送られることはありません。

テレメトリ: オプトイン、ハッシュ化、許可リスト制

プロダクトアナリティクスはデフォルトで無効です。有効にした場合、イベントはサーバー側のホワイトリストに限定されます (セッション開始/終了、機能呼び出し、AI 呼び出しの所要時間 — コンテンツは含まれません)。ユーザー ID はデバイス上で SHA-256 でハッシュ化されます。平文の ID はクライアントから外に出ません。イベントは180日間保持され、その後は集計または削除されます。

監査ログ (機関アカウント)

共有ノートへの各アクセス — 誰が、どのデバイスから、いつ — は追記専用の監査ログに書き込まれます。管理者はログを CSV または JSON でエクスポートし、コンプライアンス管理に利用できます。ログは write-once です。削除には文書化された理由が必要で、削除自体もログに記録されます。

リカバリーと鍵の紛失

パスフレーズを紛失すると、暗号化されたデータは復元不能になります。これは意図的なものです。代替案は、暗号化モデルを必然的に弱めるリカバリーパスを設けることになるからです。機関アカウントでは、管理者が保管する任意のリカバリー鍵を設定できます。これは、機関が意識的に選択する文書化されたトレードオフです。

責任ある開示

セキュリティ研究者の方を歓迎します。脆弱性は security@fluera.dev 宛に PGP 暗号化 (鍵は GitHub プロフィールに公開) で報告してください。24時間以内に返信し、重大な問題は72時間以内にパッチを当てます。匿名希望でなければ、報告者を hall of fame に掲載します。

スコープ: Fluera アプリ (全プラットフォーム)、同期サービス、AI プロキシ、このマーケティングサイト。スコープ外: サードパーティサービス (Supabase、Google、Apple、Sentry、RevenueCat) — 該当ベンダーへ報告してください。

外部評価

Fluera は現時点で SOC 2 や ISO 27001 の認証を取得していません。エンタープライズロードマップに含まれており、完了次第、公に発表します。独立して検証していない管理策を主張するつもりはありません。

サブプロセッサーリスト は公開され、最新の状態に保たれています。データ処理契約 (DPA) は privacy@fluera.dev までご請求ください。