Power Apps を使用して SQL Server に 接続 して認証するには、さまざまな方法があります。 この記事では、アプリの要件に一致するセキュリティ アプローチを使用して SQL Server に接続する方法を選択する際に役立つ概念について説明します。
Important
セキュリティで保護された暗黙的な接続機能は、2024 年 1 月にリリースされました。 Microsoft では、現在暗黙的な接続を使用しているすべてのアプリを、セキュリティで保護された暗黙的な接続に変換したり、エンド ユーザーと共有されている接続を取り消したりすることを強くお勧めします。
明示的、暗黙的、およびセキュリティで保護された暗黙的な接続の違い
SQL Server への接続は、SQL Server に接続する Power Apps を使用してアプリを作成するたびに作成されます。 このようなアプリが公開され、他のユーザーと共有されると、アプリと接続の両方がそれらのユーザーに展開されます。 つまり、アプリと接続はどちらも、アプリが共有されているユーザーに表示されます。
このような接続に使用される認証方法は 、明示的 または 暗黙的にすることができます。 また、このような接続は明示的または暗黙的に共有されているとも言うことができます。
- 明示的に共有接続とは、アプリケーションのエンド ユーザーが、独自の明示的な資格情報を使用して SQL Server に対して認証を行う必要があることを意味します。 通常、この認証は、Microsoft Entra または Windows 認証ハンドシェイクの一部としてバックグラウンドで行われます。 ユーザーは、認証がいつ行われるかさえ気付きません。
- 暗黙的に共有接続とは、ユーザーがアプリの作成時にデータ ソースへの接続と認証に使用したアカウントの資格情報を暗黙的に使用することを意味します。 エンド ユーザーの資格情報は認証には使用 されません 。 エンド ユーザーは、アプリを実行するたびに、作成者がアプリを作成した資格情報を使用します。
- セキュリティで保護された暗黙的な共有接続とは、アプリの作成時にアプリ作成者がデータ ソースへの接続と認証に使用したアカウントの資格情報をアプリのエンド ユーザーが暗黙的に使用するシナリオを指します。 つまり、エンド ユーザー自身の資格情報は認証に使用されません。 代わりに、ユーザーはアプリを実行するときに、アプリの作成者が作成した資格情報を使用します。 エンド ユーザーには接続への直接アクセスが提供されておらず、アプリでは限られた一連のアクションとテーブルへのアクセスのみが許可されることに注意してください。
Power Apps 用 SQL Server では、次の 4 種類の接続認証を使用できます。
| 認証の種類 | Power Apps の接続方法 |
|---|---|
| 統合済み Microsoft Entra | Explicit |
| SQL Server 認証 | 暗黙的/セキュリティで保護された暗黙的 |
| Windows 認証 | 暗黙的/セキュリティで保護された暗黙的 |
| Windows 認証 (非共有) | Explicit |
暗黙的な接続共有のリスク
新しいアプリケーションはすべて、新しいセキュリティで保護された暗黙的な接続を自動的に使用します。 ただし、古い "暗黙的な接続" を使用するアプリでは、アプリとその接続の両方がエンド ユーザーに展開されるため、 エンド ユーザーはそれらの接続に基づいて新しいアプリケーションを作成できます。
作成者が セキュリティで保護された暗黙的な接続を使用する場合は、接続が共有されておらず、エンド ユーザーが接続オブジェクトを受け取っていないことを意味します。 これにより、エンドユーザーの作成者が接続を再利用して新しいアプリを作成するリスクがなくなります。 代わりに、アプリは、アプリを認識し、その特定のアプリとのみ通信するプロキシ接続で動作します。 プロキシ接続では、制限されたアクション (作成、読み取り、更新、削除) と、アプリの発行時に定義されたアプリ内の特定のテーブルへのアクセスが許可されます。 そのため、承認されたアクションとアクセスのみがエンド ユーザーに付与されます。
以前のスタイルの単純な暗黙的な接続は、実際にはエンド ユーザーに接続オブジェクトを配布します。 たとえば、ユーザーに表示させたくないデータを除外するアプリを作成する場合です。 ただし、フィルター処理されたデータはデータベースに存在します。 ただし、エンド ユーザーに特定のデータが表示されないように、構成したフィルターに依存しています。
繰り返しになりますが、以前のスタイルの単純な暗黙的な接続では、アプリをデプロイした後、エンド ユーザーは、作成した新しいアプリでアプリと共にデプロイされた接続を使用できます。 新しいアプリでは、アプリケーションでフィルター処理したデータをユーザーに表示できます。 新しいセキュリティで保護された暗黙的な接続を使用することが重要です。
Important
以前の暗黙的に共有された接続がエンド ユーザーに展開されると、共有したアプリに設定した制限 (フィルターや読み取り専用アクセスなど) は、エンド ユーザーが作成する新しいアプリでは無効になります。 エンド ユーザーは、暗黙的に共有される接続の一部として認証で許可される権限を持ちます。 そのため、セキュリティで保護された暗黙的な接続を使用するようにアプリを変換する場合は、アプリと共有した接続 も 取り消す必要があります。 管理者は、COE ツールキットとの暗黙的に共有された接続を持つアプリのレポートを取得できます。
クライアントとサーバーのセキュリティ
セキュリティを確保するために、フィルター処理やその他のクライアント側の操作を通じてデータのセキュリティに依存することはできません。 データのセキュリティで保護されたフィルター処理を必要とするアプリケーションでは、ユーザー ID とフィルター処理の両方がサーバーで行われるようにする必要があります。
ユーザー ID とセキュリティに関しては、アプリ内で設計されたフィルターに依存するのではなく、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 フローが必要になる場合があります。