Bezpieczne używanie programu Microsoft SQL Server z usługą Power Apps

Istnieją różne sposoby nawiązywania połączenia i uwierzytelniania z programem SQL Server za pomocą usługi Power Apps. W tym artykule opisano pojęcia, które mogą być przydatne podczas podejmowania wyboru sposobu nawiązywania połączenia z programem SQL Server przy użyciu podejścia zabezpieczeń spełniającego wymagania aplikacji.

Różnica między jawnymi, niejawnymi i bezpiecznymi połączeniami niejawnymi

Połączenie z programem SQL Server jest tworzone za każdym razem, gdy tworzysz aplikację przy użyciu usługi Power Apps łączącej się z programem SQL Server. Gdy takie aplikacje są publikowane i udostępniane innym osobom, zarówno aplikacja, jak i połączenie są wdrażane dla tych użytkowników. Innymi słowy, aplikacja i połączenie — oba są widoczne dla użytkowników, z których aplikacje są udostępniane.

Metoda uwierzytelniania używana dla takich połączeń może być jawna lub niejawna. Możemy również powiedzieć, że takie połączenie jest jawnie lub niejawnie udostępniane.

• Jawne połączenie udostępnione oznacza, że użytkownik końcowy aplikacji musi uwierzytelnić się w programie SQL Server przy użyciu własnych jawnych poświadczeń. Zwykle to uwierzytelnianie odbywa się w tle w ramach uzgadniania uwierzytelniania firmy Microsoft entra lub Windows. Użytkownik nawet nie zauważa, kiedy odbywa się uwierzytelnianie.
• Niejawnie udostępnione połączenie oznacza, że użytkownik niejawnie używa poświadczeń konta używanego przez twórcę aplikacji do nawiązywania połączenia i uwierzytelniania ze źródłem danych podczas tworzenia aplikacji. Poświadczenia użytkownika końcowego nie są używane do uwierzytelniania. Za każdym razem, gdy użytkownik końcowy uruchamia aplikację, używa poświadczeń, z którymi autor utworzył aplikację.
• Bezpieczne połączenie udostępnione niejawnie odnosi się do scenariusza, w którym użytkownik końcowy aplikacji niejawnie używa poświadczeń konta używanego przez twórcę aplikacji do łączenia się ze źródłem danych i uwierzytelniania go podczas tworzenia aplikacji. Oznacza to, że poświadczenia użytkownika końcowego nie są używane do uwierzytelniania. Zamiast tego, gdy użytkownik uruchamia aplikację, używa poświadczeń utworzonych przez autora aplikacji. Należy pamiętać, że użytkownik końcowy nie ma bezpośredniego dostępu do połączenia, a aplikacja zezwala tylko na dostęp do ograniczonego zestawu akcji i tabel.

W programie SQL Server dla usługi Power Apps można używać następujących czterech typów uwierzytelniania połączeń:

Niejawne ryzyko współużytkowania połączeń

Wszystkie nowe aplikacje automatycznie używają nowych bezpiecznych połączeń niejawnych. Jednak w przypadku aplikacji korzystających ze starszych "niejawnych połączeń" zarówno aplikacja, jak i jej połączenia są wdrażane dla użytkowników końcowych, oznacza to, że użytkownicy końcowi mogą tworzyć nowe aplikacje na podstawie tych połączeń.

Gdy autor używa bezpiecznych połączeń niejawnych, oznacza to, że żadne połączenie nie jest współużytkowane i żaden użytkownik końcowy nie otrzymuje obiektu połączenia. Eliminuje to ryzyko ponownego nawiązania połączenia przez autora końcowego w celu utworzenia nowej aplikacji. Zamiast tego aplikacja współpracuje z połączeniem serwera proxy, które zna aplikację i komunikuje się tylko z daną aplikacją. Połączenie serwera proxy umożliwia ograniczone akcje (tworzenie, odczyt, aktualizowanie, usuwanie) i dostęp do określonych tabel w aplikacji zdefiniowanych podczas publikowania aplikacji. W związku z tym tylko autoryzowane akcje i dostęp są przyznawane użytkownikowi końcowemu.

Starszy styl proste połączenie niejawne faktycznie dystrybuuje obiekt połączenia do użytkownika końcowego. Jeśli na przykład tworzysz aplikację, która filtruje dane, których użytkownicy nie chcą widzieć. Jednak odfiltrowane dane znajdują się w bazie danych. Jednak korzystasz z filtru skonfigurowanego w celu upewnienia się, że użytkownicy końcowi nie będą widzieć pewnych danych.

Ponownie, przy użyciu prostych połączeń niejawnych w starszym stylu, po wdrożeniu aplikacji użytkownicy końcowi mogą używać połączenia wdrożonego z aplikacją w dowolnych nowych aplikacjach, które tworzą. W nowych aplikacjach użytkownicy mogą wyświetlać dane odfiltrowane w aplikacji. Ważne jest, aby używać nowych bezpiecznych połączeń niejawnych.

Zabezpieczenia klienta i serwera

Nie można polegać na zabezpieczeniach danych przez filtrowanie ani inne operacje po stronie klienta, które mają być bezpieczne. Aplikacje, które wymagają bezpiecznego filtrowania danych, muszą zapewnić, że zarówno identyfikacja użytkownika, jak i filtrowanie odbywa się na serwerze.

Użyj usług, takich jak Microsoft Entra ID, zamiast polegać na filtrach zaprojektowanych w aplikacjach, jeśli chodzi o tożsamość i zabezpieczenia użytkownika. Ta konfiguracja gwarantuje, że filtry po stronie serwera działają zgodnie z oczekiwaniami.

Na poniższych ilustracjach wyjaśniono, jak wzorce zabezpieczeń w aplikacjach różnią się między modelami zabezpieczeń po stronie klienta i po stronie serwera.

We wzorcu aplikacji zabezpieczeń klienta [1] użytkownik uwierzytelnia się tylko w aplikacji po stronie klienta. Następnie aplikacja żąda informacji o usłudze, a usługa [3] zwraca informacje wyłącznie na podstawie żądania danych.

We wzorcu zabezpieczeń po stronie serwera użytkownik najpierw uwierzytelnia się w usłudze, aby użytkownik był znany usłudze. Następnie [2] po wywołaniu z aplikacji usługa [3] używa znanej tożsamości bieżącego użytkownika do odpowiedniego filtrowania danych, a [4] zwraca dane.

Niejawne scenariusze udostępniania działów opisane powyżej są kombinacją tych dwóch wzorców. Użytkownik musi zalogować się do usługi Power Apps przy użyciu poświadczeń firmy Microsoft Entra. To zachowanie jest wzorcem aplikacji zabezpieczeń serwera. Użytkownik jest znany przy użyciu tożsamości Microsoft Entra w usłudze. W związku z tym aplikacja jest ograniczona do zestawu użytkowników, do których usługa Power Apps formalnie udostępniła aplikację.

Jednak niejawne połączenie udostępnione z programem SQL Server jest wzorcem aplikacji zabezpieczeń klienta. Program SQL Server wie tylko, że jest używana określona nazwa użytkownika i hasło. Filtrowanie po stronie klienta można na przykład pominąć przy użyciu nowej aplikacji przy użyciu tej samej nazwy użytkownika i hasła.

Aby bezpiecznie filtrować dane po stronie serwera, należy użyć wbudowanych funkcji zabezpieczeń w programie SQL Server, takich jak zabezpieczenia na poziomie wiersza dla wierszy, oraz odmów uprawnień do określonych obiektów (takich jak kolumny) określonym użytkownikom. To podejście używa tożsamości użytkownika Firmy Microsoft Entra do filtrowania danych na serwerze.

Niektóre istniejące usługi firmowe używały podejścia, w którym tożsamość użytkownika jest przechwytywana w warstwie danych biznesowych w taki sam sposób, jak usługa Microsoft Dataverse. W takim przypadku warstwa biznesowa może lub nie może bezpośrednio używać zabezpieczeń na poziomie wiersza programu SQL Server i funkcji odmowy. Jeśli tak nie jest, często jest tak, że zabezpieczenia są włączone przy użyciu procedur składowanych lub widoków.

Warstwa biznesowa (po stronie serwera) używa znanej tożsamości microsoft Entra użytkownika do wywoływania procedury składowanej jako podmiotu zabezpieczeń programu SQL Server i filtrowania danych. Jednak usługa Power Apps nie łączy się obecnie z procedurami składowanymi. Warstwa biznesowa może również wywołać widok, który używa tożsamości Microsoft Entra jako podmiotu zabezpieczeń programu SQL Server. W takim przypadku użyj usługi Power Apps, aby połączyć się z widokami, aby dane zostały odfiltrowane po stronie serwera. Udostępnianie tylko widoków użytkownikom może wymagać przepływów usługi Power Automate na potrzeby aktualizacji.

Zobacz także

Omówienie łączników dla aplikacji kanwy