権限判定とAPI連携

すべての条件を満たしたときだけ許可する

クライアント認証で確定した主体とテナント、要求された操作、対象レコード、許可の有効期間を照合します。条件が不足する場合は拒否するdeny-by-defaultを基本にします。

主体

認証済みのサービス・連携先。要求本文のclient_idをそのまま信用しない。

対象

認証主体のtenant_idと一致するレコードに限定する。

操作と用途

shipping.address.readなど必要な権限と、配送などの用途を確認する。

追加条件

audience、期限、失効状態、利用回数、本人との関係を照合する。

判定の一貫性

実データ取得と利用回数更新までに状態が変わる競合を考慮する。

サーバー間の認証と資格情報の管理

認証にはMicrosoft Entraのアプリ用Bearer tokenを使います。Azure上ではManaged Identity、証明書方式では秘密鍵でアプリを認証してtokenを取得します。証明書は通信路のmTLS認証ではありません。現行Vaultが信頼するEntraディレクトリは1つで、他組織のIDをそのまま使えるとは限りません。資格情報はバックエンドだけに置きます。

利用先の制限

トークンのaudienceと接続先を確認し、別API向けのトークンを受け入れない。

資格情報のローテーション

古い鍵・資格情報の停止と切り替え期間を管理する。

ブラウザーとサーバーの分離

サーバー用の資格情報をJavaScriptやHTMLに埋め込まない。

エラー・再試行・監査の扱い

拒否の理由を内部の証跡に残しつつ、外部には他社のレコードの存在や本人情報を漏らさない応答を返します。タイムアウトで結果が不明な場合は、無条件に同じ処理をやり直さず、冪等性キーや処理状態の照会を使います。

401 / 403

認証の不足と権限の不足を区別し、詳細は安全な内部ログへ記録する。

404

存在しない対象と参照権限のない対象を区別しない応答も検討する。

409 / 429

冪等性キーの競合や処理回数制限。再送方針と待機時間を定義する。

503

権限や失効状態を確認できない場合は、許可扱いにせず処理を停止する。

DATA / INTEGRATION EXAMPLE

データ・連携の具体例

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

{
  "operation": "権限判定への入力と結果の設計例",
  "authenticated_context": {
    "tenant_id": "tenant_a",
    "client_id": "carrier-a"
  },
  "request": {
    "action": "shipping.address.read",
    "resource_ref": "order_example_01",
    "purpose": "fulfillment"
  },
  "decision": {
    "allowed": true,
    "fields": [
      "postal_code",
      "address",
      "recipient_name"
    ],
    "decision_id": "dec_example_01"
  }
}

認証コンテキストは検証済みの資格情報から組み立てます。クライアントが送ったtenant_idを権限の根拠として採用しません。

関連する技術設計

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

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