Power Apps で Microsoft SQL Server を安全に使用する

Power Apps での 接続 方法と SQL Server への認証方法にはさまざまな方法があります。 この記事では、アプリの要件に一致するセキュリティ アプローチを使用して SQL Server に接続する方法を選択する際に役立つ概念の概要を説明します。

重要

この記事は、すべてのリレーショナル データベースと暗黙的な接続に適用されます。

明示的接続と暗黙的接続の違い

SQL Server への接続は、Power Apps を使用して SQL Server への接続アプリを作成するたびに作成されます。 そのようなアプリが公開されて他のユーザーと共有されると、アプリと接続の両方がそれらのユーザーにデプロイされます。 言い換えれば、アプリと接続—はどちらも、アプリが共有されているユーザーに表示されます。

このような接続に使用される認証方法は 明示的 または 暗黙 です。 このような接続は、明示的または暗黙的に共有されているとも言えます。

• 明示的に共有された接続 は、アプリケーションのエンドユーザーが独自の明示的な資格情報を使用して SQL Server に対して認証する必要があることを意味します。 通常、この認証は Azure Active Directory または Windows 認証ハンドシェイクの一部として舞台裏で行われます。 ユーザーは、認証がいつ行われているかさえ気づきません。
• 暗黙的に共有される接続 とは、アプリの作成中にアプリメーカーがデータ ソースへの接続と認証に使用したアカウントの資格情報をユーザーが暗黙的に使用することを意味します。 エンドユーザーの資格情報は認証に使用され ません。 エンドユーザーは、アプリを実行するたびに、作成者がアプリを作成したときに使用した資格情報を使用します。

次の 4 つの接続認証タイプは、Power Apps 用 SQL Server で使用できます。

認証の種類	Power Apps の接続方法
統合済み Azure AD	明示的
SQL Server 認証	暗黙的
Windows 認証	暗黙的
Windows 認証 (非共有)	明示的

暗黙的接続共有のリスク

アプリとその接続の両方がエンドユーザーにデプロイされるため、エンドユーザーは、これらの接続に基づいて新しいアプリケーションを作成できます。

たとえば、ユーザーに見せたくないデータを除外するアプリを作成したとします。 除外されたデータはデータベースに存在します。 ただし、エンドユーザーに特定のデータが表示されないように構成したフィルターに依存しています。

このアプリをデプロイした後、エンドユーザーは、アプリでデプロイされた接続を、作成する新しいアプリで使用できます。 新しいアプリでは、ユーザーはアプリケーションで除外したデータを確認できます。

重要

暗黙的に共有された接続がエンドユーザーにデプロイされると、共有したアプリに設定した制限 (フィルターや読み取り専用アクセスなど) は、エンドユーザーが作成する新しいアプリでは無効になります。 エンドユーザーは、暗黙的に共有される接続の一部として認証で許可されるすべての権限を持ちます。

暗黙的接続の実際の使用

暗黙的認証方法と明示的認証方法の両方に有効な使用例があります。 アプローチを選択するときは、セキュリティ モデルと開発の容易さを考慮してください。 原則として、データを行または列ごとに制限する必要があるビジネス要件がある場合は、明示的認証方法を使用してください。

明示的接続のユースケースの例として、別の営業担当者が製品と価格を確認する必要がある同じテーブルにある価格割引または基本コストデータの表示のみを許可する必要がある営業マネージャーについて考えてみます。

ただし、すべてのデータを同じ方法で保護する必要があるとは限りません。 アプリは共有され、特定のユーザーまたはユーザーのグループにデプロイされます。 そのグループ外の人は、アプリや接続にアクセスできません。 したがって、グループ内の全員がデータベース内のすべてのデータを表示することを許可されている場合は、暗黙的共有方法が適切に機能します。

暗黙的接続のユースケースの例として、追跡しているプロジェクトの小さなデータベースがある部門について考えてみます。 データベースには、部門の作業チケットや会社全体の企業カレンダーなどの情報が含まれる場合があります。 このシナリオでは、アクセス権を付与されたすべてのユーザーがすべてのデータにアクセスできる限り、暗黙的に共有された接続の上にさらにアプリを構築することをお勧めします。

Power Apps を使用して作成されたアプリは、エンドユーザーが親しみやすいように設計されています。 この種のシナリオは、暗黙的な接続に関連する開発コストが低いため、一般的です。

部門ベースのアプリは、企業全体のミッションクリティカルなアプリに成長する可能性があります。 これらのシナリオでは、部門別アプリが企業全体に移行するにつれて、従来の企業セキュリティを組み込む必要があることを理解することが重要です。 このアプローチは、アプリ構築の取り組みには費用がかかりますが、企業全体のシナリオでは重要です。

クライアントおよびサーバー セキュリティ

フィルタリングやその他のクライアント側の操作によるデータのセキュリティを信頼してセキュリティを確保することはできません。 データの安全なフィルタリングを必要とするアプリケーションは、ユーザーの識別とフィルタリングの両方がサーバー上で行われるようにする必要があります。

アプリ内で設計されたフィルターに依存する代わりに、Azure Active Directory のようなサービスを使用します。 この構成により、サーバー側のフィルターが期待どおりに機能することが保証されます。

次の図は、アプリ内のセキュリティ パターンがクライアント側とサーバー側のセキュリティモデル間でどのように異なるかを説明しています。

クライアント セキュリティアプリのパターンでは、[1] ユーザーは、クライアント側のアプリケーションに対してのみ認証します。 次に [2] アプリケーションがサービスの情報を要求し、[3] サービスは、データ要求のみに基づいて情報を返します。

サーバー側のセキュリティパターンでは、[1] ユーザーは最初にサービスに対して認証を行うため、ユーザーはサービスに認識されます。 次に、[2] アプリケーションから電話がかかると、サービス [3] は、現在のユーザーの既知の ID を使用して、データを適切にフィルタリングし、[4] データを返します。

上記の暗黙の部門共有シナリオは、これら 2 つのパターンの組み合わせです。 ユーザーは、Azure AD 資格情報を使用して Power App サービスにログインする必要があります。 この動作は、サーバー セキュリティ アプリのパターンです。 ユーザーは、サービスで Azure AD ID を使用して認識されます。 したがって、アプリは、対象となるユーザーのセットに制限され、これは Power Apps はアプリケーションを正式に共有しています。

ただし、SQL Serverへの暗黙的な共有接続は、クライアント セキュリティ アプリのパターンです。 SQL Server は、特定のユーザー名とパスワードが使用されていることのみを認識しています。 たとえば、クライアント側のフィルタリングは、同じユーザー名とパスワードを使用する新しいアプリケーションでバイパスできます。

サーバー側でデータを安全にフィルタリングするには、行に対して 行レベルのセキュリティ などの SQL Server に組み込まれているセキュリティ機能、そして特定のユーザーに対する特定のオブジェクト (列など) へのアクセス許可の 拒否 を使用します。 このアプローチでは、サーバー上のデータをフィルタリングするための Azure AD ユーザー ID を使用します。

一部の既存の企業サービスでは、Microsoft Dataverse がおこなうのと同じ方法で、ユーザー ID がビジネス データ レイヤーにキャプチャされるアプローチを使用しています。 この場合、ビジネス レイヤーは、SQL Server の行レベルのセキュリティを使用する場合と使用しない場合があり、機能を直接拒否します。 そうでない場合は、ストアド プロシージャまたはビューを使用してセキュリティが有効になっていることがよくあります。

(サーバー側の) ビジネス レイヤー層は既知のユーザー Azure AD ID を使用して、ストアド プロシージャを SQL Server プリンシパルとして呼び出し、データをフィルタリングします。 しかしながら、Power Apps は現在、ストアド プロシージャに接続していません。 ビジネス レイヤーは、Azure AD ID を SQL Server プリンシパルとして使用するビューを呼び出すこともできます。 この場合、Power Appsビューに接続して、データがサーバー側でフィルタリングされるようにします。 ビューのみをユーザーに公開することが、更新のために Power Automate フローが必要ある場合があります。

関連項目

キャンバス アプリのコネクタの概要