次の方法で共有

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

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

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

セキュリティの 3 つの柱

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

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

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

プロバイダー 利用シーン ガイド
Microsoft Entra ID (EntraID/AzureAD) Microsoft ID を使用した運用アプリ Entra 認証を構成する
カスタム トークン（JWT） サードパーティ IDP (Okta、Auth0、Keycloak) カスタム JWT 認証を構成する
App Service Azure App Service EasyAuth (プラットフォーム ヘッダー) の背後で実行されているアプリ App Service 認証を構成する
シミュレーター ローカルでの開発とテスト シミュレーター認証の構成
静的 Web アプリ SWA 認証ヘッダーで保護されたアプリケーション App Service 認証を構成する

ヒント

開発時に シミュレーター プロバイダーから開始し、ID プロバイダーを構成せずにアクセス許可をテストします。 デプロイする前に運用プロバイダーに切り替えます。

認証

認証は、呼び出し元の ID を検証します。 データ API ビルダーは、JWT ベアラー トークン (EntraID/AzureAD、 Custom) を検証するか、プラットフォームによって提供される ID ヘッダー (AppService、 StaticWebApps) を信頼することで、要求を認証します。 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 認証プロバイダー (EntraID/AzureAD、 Custom、 AppService、 StaticWebApps、 Simulator)
runtime.host.authentication.jwt.audience JWT プロバイダーに対して想定される対象ユーザー要求 (AppService/StaticWebApps/Simulator では使用されません)
runtime.host.authentication.jwt.issuer JWT プロバイダーに必要な発行者/機関 (AppService/StaticWebApps/Simulator では使用されません)

詳細な構成については、「 Microsoft Entra ID 認証の構成」を参照してください。

認証

承認は、認証された (または匿名の) ユーザーが実行できる操作を決定します。 データ 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 ガイド
データベース ポリシー (行レベルのセキュリティ) ポリシー式を、要求またはセッション コンテキストに基づいて行をフィルター処理するクエリ述語に変換する 行レベルのセキュリティを実装する
フィールド レベルのセキュリティ ロールごとに特定の列を含めるまたは除外する フィールド アクセス

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

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

  • すべての接続に 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 ガイド
Microsoft Entra ID 認証を設定する Entra 認証を構成する
Okta または Auth0 を使用する カスタム JWT 認証を構成する
Azure App Service の背後で実行する App Service 認証を構成する
アクセス許可をローカルでテストする シミュレーター認証の構成
ユーザー別に行を制限する 行レベルのセキュリティを実装する
ロールの割り当てを理解する 認可とロール

関連コンテンツ

  • Last updated on