次の方法で共有


データ API ビルダー ソリューションをセキュリティで保護する

データ API ビルダーは、REST エンドポイントと GraphQL エンドポイントを介してデータを公開します。 API をセキュリティで保護するには、 認証 (呼び出し元)、 承認 (何ができるか)、 トランスポート セキュリティ (接続が保護されていますか?) という 3 つの主要な領域に注意する必要があります。

認証、承認、およびデータベース アクセスを示すエンドツーエンドの要求フローの図。

セキュリティの 3 つの柱

質問とその回答 主な概念
認証 呼び出し元は誰ですか? ID プロバイダーからのトークンを検証する
認可 彼らは何ができますか? エンティティに対するロールベースのアクセス許可
輸送 接続はセキュリティで保護されていますか? すべてのトラフィックに対するトランスポート層セキュリティ (TLS) 暗号化

認証プロバイダーを選択する

データ API ビルダーでは、複数の認証プロバイダーがサポートされています。 デプロイ シナリオに一致するものを選択します。

プロバイダー 利用シーン ガイド
未認証 DAB は、ID を処理する信頼されたフロントエンドの背後に配置されます (既定) 認証されていないプロバイダーを構成する
Microsoft Entra ID (EntraID/AzureAD) Microsoft ID を使用した運用アプリ Microsoft Entra 認証を構成する
カスタム JSON Web トークン (JWT) サードパーティ IDP (Okta、Auth0、Keycloak) カスタム JWT 認証を構成する
App Service Azure App Service EasyAuth (プラットフォーム ヘッダー) の背後で実行されているアプリ App Service 認証を構成する
シミュレーター ローカルでの開発とテスト シミュレーター認証の構成
OBO (ユーザー委任) 実際のユーザー ID を必要とする SQL データベース (行レベルのセキュリティ、監査) OBO 認証を構成する

このセクションで説明する Data API Builder 2.0 の機能は現在プレビュー段階であり、一般公開前に変更される可能性があります。 詳細については、「 バージョン 2.0 の新機能」を参照してください。

認証

認証は、呼び出し元の ID を検証します。 データ API ビルダーは、JWT ベアラー トークン (EntraID/AzureADCustom) を検証するか、プラットフォームによって提供される ID ヘッダー (AppServiceStaticWebApps) を信頼することで、要求を認証します。 Simulator は、開発用の外部検証をスキップします。

クライアントが JWT トークンを使用してデータ API ビルダーに対して認証する方法の図。

動作方法

  1. JWT プロバイダーの場合、クライアントは ID プロバイダーからトークンを取得します
  2. クライアントは、 Authorization: Bearer <token> ヘッダー (JWT プロバイダー) でトークンを送信するか、プラットフォームが ID ヘッダーを挿入します (EasyAuth/SWA)
  3. データ API ビルダーがトークンまたはプラットフォーム ヘッダー (JWT プロバイダーの発行者、対象ユーザー、署名) を検証する
  4. DAB は、トークンまたは ID ヘッダーからユーザーのロールを抽出します

クイック リファレンス

Setting Description
runtime.host.authentication.provider 認証プロバイダー (UnauthenticatedEntraID/AzureADCustomAppServiceStaticWebAppsSimulator)
runtime.host.authentication.jwt.audience JWT プロバイダーの対象オーディエンス要求 (AppService/StaticWebApps/Simulator/Unauthenticated では使用されません)
runtime.host.authentication.jwt.issuer JWT プロバイダーに必要な発行者/機関 (AppService/StaticWebApps/Simulator/Unauthenticated では使用されません)

プロバイダー固有の構成については、このセクションの認証ガイドを参照してください。

認証

承認は、認証された (または匿名の) ユーザーが実行できる操作を決定します。 データ API ビルダーでは、ロールベースのアクセス制御 (RBAC) を使用して、エンティティとアクションへのアクセスを制限します。

Data API ビルダーがロールを選択し、要求のアクセス許可を評価する方法の図。

動作方法

  1. DAB は、トークンとヘッダーに基づいて要求にロールを割り当てます
  2. DAB は、そのロールに対するエンティティのアクセス許可を検索します
  3. 要求されたアクションに対するアクセス許可がロールに付与されている場合、DAB はクエリを実行します
  4. そうでない場合、DAB は 403 Forbidden 応答を返します

システム ロールとユーザー ロール

ロールの種類 Description
Anonymous 認証された ID が存在しない場合に割り当てられます
Authenticated 要求が認証され (JWT 承認済みまたは信頼されたプラットフォーム ヘッダー)、特定のユーザー ロールが選択されていない場合に割り当てられます
ユーザー ロール トークンの roles 要求 (またはプラットフォーム ロール) のカスタム ロール ( X-MS-API-ROLE ヘッダーを使用して選択)

デフォルトで安全が確保されています

エンティティには 、既定ではアクセス許可がありません。 アクセス権を明示的に付与する必要があります。

{
  "entities": {
    "Book": {
      "permissions": [
        { "role": "authenticated", "actions": ["read"] }
      ]
    }
  }
}

詳細な構成については、「 承認とロール」を参照してください。

行レベルおよびフィールドレベルのセキュリティ

きめ細かいアクセス制御を使用して、エンティティ レベルのアクセス許可を超えます。

特徴 Description ガイド
データベース ポリシー (行レベルのセキュリティ) ポリシー式を、要求またはセッション コンテキストに基づいて行をフィルター処理するクエリ述語に変換する 行レベルのセキュリティを実装する
フィールド レベルのセキュリティ ロールごとに特定の列を含めるまたは除外する フィールド アクセス
代理人 (OBO) 受信ユーザー トークンをダウンストリーム SQL トークンと交換して、データベースが実際の呼び出し元ユーザーとして認証されるようにします (mssql のみ) ユーザー委任認証

ロールの継承

DAB 2.0 では、エンティティのアクセス許可にロールの継承が導入されています。 継承チェーンは named-role → authenticated → anonymous。 エンティティに対してロールが明示的に構成されていない場合は、次の広範なロールから継承されます。 anonymousに対してアクセス許可を 1 回定義すると、すべての広範なロールが同じアクセス権を取得します。 詳細については、「 ロールの継承」を参照してください。

トランスポートと構成のセキュリティ

トランスポート セキュリティ

  • すべての接続に TLS を使用する: クライアントと DAB の間のトラフィックを暗号化する
  • 従来の TLS バージョンを無効にする: TLS 1.2 以降のみに依存する
  • HTTPS エンドポイントを使用する: 運用環境で暗号化されていない HTTP 経由で DAB を公開しない

詳細については、「 セキュリティのベスト プラクティス」を参照してください。

セキュリティ設定

  • 環境変数にシークレットを格納する: 構成で @env('SECRET_NAME') を使用する
  • Azure Key Vault の活用: シークレットを@azure('key-vault-uri')参照する
  • シークレットをコミットしない: dab-config.json パスワードと接続文字列を使用しない
{
  "data-source": {
    "connection-string": "@env('SQL_CONNECTION_STRING')"
  }
}

監視と更新

  • アクセスの監視: Application Insights を使用して要求を追跡し、異常を検出する
  • ログの確認: 失敗した認証試行とアクセス許可拒否を確認する
  • DAB を最新の状態に保つ: 最新バージョンにアップグレードしてセキュリティ パッチを適用する

クイック スタート ガイド

Task ガイド
DAB で JWT 検証なしで信頼されたフロント エンドを使用する 認証されていないプロバイダーを構成する
Microsoft Entra ID 認証を設定する Microsoft Entra 認証を構成する
Okta または Auth0 を使用する カスタム JWT 認証を構成する
Azure App Service の背後で実行する App Service 認証を構成する
アクセス許可をローカルでテストする シミュレーター認証の構成
ユーザー別に行を制限する 行レベルのセキュリティを実装する
ロールの割り当てを理解する 認可とロール