代理IDとテナント分離

識別子の対応をどう管理するか

本人の内部識別子をそのまま外部に渡さず、tenant_id・service_id・内部識別子の組み合わせに代理IDを割り当てます。同一人物でもサービスが異なれば別の代理IDを使い、利用者同士の照合に共通IDが使われる範囲を抑えます。

tenant_id

企業の境界。認証済みのクライアント情報から決定する。

service_id

企業内の利用先。別サービスへIDを持ち回らせない。

proxy_id

外部に渡すランダムな識別子。氏名やメールアドレスを含めない。

subject_ref

保管庫内の本人参照。業務システムへの応答には含めない。

status / version

有効・無効の状態と更新競合を扱うバージョン。

発行・更新・削除の流れ

①認証された利用先の企業・サービスを確定。②既存の対応関係を確認。③必要な場合だけ安全な乱数でIDを発行。④一意制約とトランザクションで二重登録を防止。⑤停止時は参照を拒否し、対応表の削除は保持方針に沿って実施します。

発行の競合

同じ登録要求が並行して届いても、同じ対応関係を重複作成しない。

IDの更新

旧IDの失効と新IDの有効化を管理し、過去データの参照を移行する。

削除

代理IDの無効化と実データ削除を区別する。バックアップと証跡も対象を整理する。

IDを知っていても、情報を取得できない

代理IDは認証情報ではありません。すべての参照要求で、企業・サービス・対象レコードの権限をサーバー側で確認します。IDを差し替えて他社のレコードを取得できる設計を避けます。

横断参照を拒否

認証されたtenant_idと対応表のtenant_idが一致することを確認。

対応表を分離

業務DBと同じ権限で本人への対応関係を参照できないようにする。

連携の根拠

ID同士を結び付ける操作は、通常の照会より強い権限と証跡を必要とする。

DATA / INTEGRATION EXAMPLE

データ・連携の具体例

以下は設計を説明するためのサンプルです。フィールド名・値は例示で、実行用のAPIリファレンスではありません。

{
  "operation": "代理IDの発行・参照の設計例",
  "request": {
    "service_id": "shop-a",
    "registration_ref": "reg_example_01"
  },
  "response": {
    "proxy_id": "nym_example_01",
    "status": "active"
  }
}

registration_refは保管庫側の登録処理が発行する参照値です。メールアドレスのハッシュだけで本人照合や匿名化を行う方式ではありません。

関連する技術設計

業務とシステムに合わせた連携設計。

保有する情報、連携先、必要な処理を整理し、情報の露出を減らす方法を検討します。