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

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

明示的、暗黙的、安全な暗黙的接続の違い

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

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

• 明示的に共有された接続 は、アプリケーションのエンドユーザーが独自の明示的な資格情報を使用して SQL Server に対して認証する必要があることを意味します。 通常、この認証は Microsoft Entra または Windows 認証ハンドシェイクの一部として舞台裏で行われます。 ユーザーは、認証がいつ行われているかさえ気づきません。
• 暗黙的に共有される接続 とは、アプリの作成中にアプリメーカーがデータ ソースへの接続と認証に使用したアカウントの資格情報をユーザーが暗黙的に使用することを意味します。 エンドユーザーの資格情報は認証に使用され ません。 エンドユーザーは、アプリを実行するたびに、作成者がアプリを作成したときに使用した資格情報を使用します。
• セキュアな暗黙的共有接続とは、アプリのエンド ユーザーが、アプリの作成時にアプリの作成者がデータソースへの接続と認証に使用したアカウントの認証情報を暗黙的に使用するシナリオを指します。 これは、エンド ユーザー自身の認証情報が認証に使用されないことを意味します。 その代わり、ユーザーがアプリを実行するときは、アプリの作者が作成した認証情報を使用します。 エンド ユーザーには接続への直接アクセスは提供されず、アプリは限られたアクションとテーブルへのアクセスしか許可しないことに注意することが重要です。

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

暗黙的接続共有のリスク

すべての新しいアプリケーションは、新しい安全な暗黙的な接続を自動的に使用します。 しかし、旧来の「暗黙の接続」を使用するアプリでは、アプリとその接続の両方がエンドユーザーに展開されるため、エンドユーザーはそれらの接続に基づいて新しいアプリケーションを作成することができます。

作成者が 安全な暗黙的な接続 を使用する場合、接続は共有されず、エンド ユーザーは接続オブジェクトを受信しません。 これにより、エンド ユーザーの作成者が接続を再利用して新しいアプリを作成するリスクが排除されます。 代わりに、アプリはアプリを認識し、その特定のアプリとのみ通信するプロキシ接続で動作します。 プロキシ接続では、アプリの公開時に定義されたアプリ内の特定のテーブルに対する制限されたアクション (作成、読み取り、更新、削除) とアクセスが許可されます。 したがって、エンド ユーザーには承認されたアクションとアクセスのみが許可されます。

古いスタイルの単純な暗黙的な接続では、実際には接続オブジェクトがエンド ユーザーに配布されます。 たとえば、ユーザーに見せたくないデータをフィルターにかけるアプリを作ったとします。 しかし、フィルターにかけられたデータはデータベースに存在します。 ただし、エンドユーザーに特定のデータが表示されないように構成したフィルターに依存しています。

旧式の単純な暗黙的接続では、アプリを展開した後、エンドユーザーはアプリと一緒に展開された接続を、作成した新しいアプリで使用できます。 新しいアプリでは、ユーザーはアプリケーションで除外したデータを確認できます。 新しい安全な暗黙的な接続を使用することが重要です。

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

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

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

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

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

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

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

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

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

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

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

関連項目

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