Security
信頼は、
構造で証明する。
MeMe は「ISO 取得済」よりも「そもそも漏れる経路がない」を優先しました。多層防御 + 物理分離 + 監査ログで、データの動きを構造的に追跡可能にしています。
Defense in Depth
7 層の独立した守り
外から内に向かって 7 層。攻撃が中央 (顧客データ) に届くには すべての層を同時に突破 する必要があり、構造的に困難です。各層を ホバー で詳細表示。
L0
ネットワーク / TLS
Cloud Run 標準 HTTPS、Google managed cert、Firebase Auth Domain 制限。
突破された場合
通信路盗聴・MITM 攻撃。HTTPS と Domain 制限が破れた場合に下層が露出します。
各層を独立に ホバー して、何が守られているかを切り替えられます。 実際のアプリでも、すべての層が独立に動作。
Tenant Isolation
他社のデータが、構造的に見えない。
1 つのアプリで N テナントを処理しますが、各テナントの DB は 物理的に独立。リクエストごとに「自社の箱」しか開けない設計です。
Architecture
1 つのアプリ × N 個の物理 DB
★ DB カードに マウスを乗せる と、対応するテナントだけが強調されます。
越境試行 (Tenant A ユーザー)
- 1自社の ID Token を取得
- 2URL の docId を改ざん (B 社の docId に書換え)
- 3リクエスト送信
MeMe の応答
- 1withAuth が ID Token から tenantId='a' を抽出
- 2getTenantDb('a') は A 社 DB のみを返す
- 3B 社 doc は コード上 到達経路なし → 404
POINT1 つの Cloud Run アプリ から複数テナントを管理しますが、コード上「自社の箱」しか開かない設計。バグや人為ミスでも、 他社データへの 到達経路が存在しない ため、構造的に防御できます。
AI 学習に使われない
Vertex AI 規約で明示
PAP 有効
Storage バケット直接アクセス禁止
Secret Manager 経由
API キーは平文 env なし
全 CUD 監査記録
before / after を audit_logs に
Security FAQ
よく聞かれる、10 個。
日本国内 Google Cloud asia-northeast1 (東京) に保管。Firestore / Storage は東京 (asia-northeast1) で完結します。
構造的に不可能です。テナント毎に 独立した Firestore named DB + Storage バケット を割り当てる Bridge パターン採用。
されません。Vertex AI 規約で「顧客データは基礎モデルの学習に使用しない」と明示。Consumer Gemini API / OpenAI / Anthropic は本番で一切不使用。
削除されます。退会即時に論理削除 (90 日猶予)、その後 Firestore named DB と Storage バケットを物理削除。エクスポートは事前に提供。
Firebase Authentication が hash 化して保管、AI-CRM 側からも見えません。2FA も標準対応。
テナント admin がユーザー管理画面から無効化 or 削除。即時ログイン不可になります。
AI-CRM 単体では未取得。ただし Google Cloud 上で稼働するため、インフラは Google が SOC 2 / ISO 27001 取得済。代わりに利用規約 + DPA + サイバー保険で担保。
Cloud Run + Firestore の Google 公開 SLA は 99.95%。エンタープライズプランでは個別 SLA (99.9%+) を契約可。
テナント admin が監査ログ画面で全 CUD 操作の before/after を閲覧可能。代理店 admin の操作も全て記録。
定期自動スキャン (gitleaks、依存ライブラリ脆弱性) を実施。第三者ペネトレは Enterprise 顧客の要望時に対応。