Upload2Door

Security

PII完全分離。暗号化必須。最小権限の原則。

データ3層分離

機密度に応じた適切な保管場所

高機密PII（個人情報）
Firestore
  • 氏名
  • 住所
  • 電話番号
  • メールアドレス
中機密画像データ
R2（暗号化）
  • 顧客アップロード写真
  • 処理済み画像
  • サムネイル
低機密業務データ
D1
  • 注文ステータス
  • 商品マスタ
  • ログ
PII漏洩時の影響を最小化 → Firestore単独でも業務データは無意味

なぜこの構成は「証明可能に安全」か

運用が頑張らなくても安全な設計


  ユーザー
     │
     ▼
  Firebase Auth ─────── 本人確認（認証情報を自社で持たない）
     │
     ▼
  Firestore ─────────── PII（住所・連絡先等）
     │
     ▼
  Cloudflare Workers ── 毎回認可チェック（条件付きアクセス）
     │
     ├─▶ D1 ─────────── 業務データ（非PII：注文・原本メタ等）
     │
     └─▶ R2 ─────────── 完全非公開（直接URL不可）

認証・権限・データが分離

1か所が破られても全体は破られない。単一障害点がない設計。

URLだけでは絶対にアクセス不可

R2は完全非公開。Workers経由で毎回認可チェックが必須。

毎回機械的に認可チェック

アクセス時に必ずサーバー側で検証。人の判断に依存しない。

ヒューマンエラー耐性

URLは短期署名。ロール削除で即時アクセス不可。誤送信しても事故にならない。

役員・監査向け説明

「認証・権限・データを、それぞれ独立した専門基盤に分離しています。
単一障害点がなく、一部が侵害されても全体は破られません。」

暗号化レイヤー

レイヤー方式管理
通信TLS 1.3（Cloudflare自動）Cloudflare
ストレージ（R2）AES-256 Server-Side EncryptionCloudflare
ストレージ（Firestore）AES-256 + エンベロープ暗号化Google Cloud
アプリケーションPII項目の追加暗号化（検討中）Application

Firestore セキュリティルールの凄さ

アプリにバグがあってもDBが拒否する

アプリバグでもDBが拒否

アプリケーションコードにバグがあっても、Firestore側で不正アクセスをブロック。多層防御の最終ライン。

宣言的で監査説明可能

ルールはコードとして記述。「なぜ許可/拒否されるか」を監査人に論理的に説明できる。

権限変更は即時反映

ロール変更・退職処理が即座に反映。「次回ログイン時」ではなく「今すぐ」アクセス不可に。

バイパス不可

Firebase Admin SDK以外ではルールを迂回できない。Admin SDKはサーバーサイドのみ。

セキュリティルール例（実際のコード）
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    // 自分の組織のデータのみアクセス可能
    match /projects/{projectId} {
      allow read: if request.auth != null &&
        get(/databases/$(database)/documents/users/$(request.auth.uid))
          .data.orgId == resource.data.orgId;

      // 削除は管理者のみ
      allow delete: if request.auth != null &&
        get(/databases/$(database)/documents/users/$(request.auth.uid))
          .data.role == 'admin';
    }
  }
}
観点従来型（アプリ層で制御）Firestore Security Rules
アプリバグ時不正アクセス成立の可能性DBが拒否（多層防御）
権限変更の反映キャッシュ次第で遅延即時反映
監査への説明コード全体を見せる必要ルールファイル1つで説明可能
バイパスSQLインジェクション等のリスク構造的に不可能
テストE2Eテストが必要ルール単体でテスト可能

役員・監査向け説明（そのまま使用可）

「アプリケーションにバグがあっても、データベース自体が不正アクセスを拒否します。
これは従来のシステムにはない、設計段階で保証された安全性です。

権限ルールはコードとして記述されており、
監査人に論理的に説明可能です。」

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

ロール注文作成注文閲覧PII閲覧画像DL管理機能
customer✓自分のみ自分のみ自分のみ−
studio_staff✓事務所内事務所内事務所内−
factory_operator−全注文−全注文−
admin✓全注文全注文全注文✓

工場オペレーターはPIIにアクセス不可

工場では画像データのみダウンロード可能。配送先情報は印刷ラベル出力時にのみ参照され、 画面上では表示されない設計。

認証フロー

一般顧客
Firebase Auth (Passwordless)
  • メールリンク認証（パスワード不要）
  • Google OAuth連携
  • SMS認証（オプション）
事務所・工場スタッフ
Firebase Auth + Custom Claims
  • 組織IDによるテナント分離
  • ロールベースの権限管理
  • 管理画面からの招待制

追加セキュリティ対策

WAF

Cloudflare WAF（OWASP Top10対応）

Rate Limiting

IPベース・ユーザーベースの制限

DDoS Protection

Cloudflare Unmetered DDoS保護

バックアップ

Firestore（7日）+ D1スナップショット（30日）

監査ログ

全API操作のログ記録

脆弱性スキャン

Dependabotによる依存関係監視

コンプライアンス

項目対応状況
個人情報保護法対応済み（PII分離設計）
GDPR対応可能（データ削除API実装予定）
PCI DSSStripe/Paidy委託（Level 1準拠）
SOC 2 Type IICloudflare/Firebase/GCPが取得済み
ISO 27001インフラプロバイダが取得済み