Bezpieczne używanie programu Microsoft SQL Server z usługą Power Apps
Istnieje wiele różnych sposobów łączenia się i uwierzytelniania w programie SQL Server za pomocą Power Apps. W tym artykule przedstawiono koncepcje, które mogą być pomocne przy dokonywaniu wyboru sposobu łączenia się z programem SQL Server przy użyciu podejścia do zabezpieczeń zgodnego z wymaganiami aplikacji.
Ważne
Funkcja bezpieczne połączenia niejawne została wydana w styczniu 2024 roku. Microsoft zdecydowanie zachęca wszystkie aplikacje korzystające obecnie z niejawnych połączeń do konwersji na bezpieczne niejawne połączenia i do odwołania połączeń udostępnionych użytkownikom końcowym.
Różnica między połączeniami 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, zarówno aplikacja, jak i połączenie są wdrażane dla tych użytkowników. Innymi słowy, aplikacja i połączenie—są widoczne dla użytkowników, którym udostępniono aplikacje.
Metoda uwierzytelniania używana dla takich połączeń może być jawna lub niejawna. Możemy również powiedzieć, że takie połączenie jest udostępniane jawnie lub niejawnie.
- Jawnie udostępniane połączenie oznacza, że użytkownik końcowy aplikacji musi uwierzytelniać się w SQL Server za pomocą własnych jawnych poświadczeń. Zwykle to uwierzytelnianie odbywa się w tle w ramach uzgadniania uwierzytelniania usługi Microsoft Entra lub systemu Windows. Użytkownik nawet nie zauważy, kiedy odbywa się uwierzytelnianie.
- Połączenie niejawnie udostępnione oznacza, że użytkownik niejawnie używa poświadczeń konta, którego twórca aplikacji używał do łączenia się 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ń, za pomocą których autor utworzył aplikację.
- Bezpieczne, niejawnie współdzielone połączenie odnosi się do scenariusza, w którym użytkownik końcowy aplikacji domyślnie korzysta z poświadczeń konta, którego twórca aplikacji użył do połączenia i uwierzytelnienia ze źródłem danych 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ę, korzysta z poświadczeń, za pomocą których autor aplikacji ją utworzył. Należy zauważyć, że użytkownik końcowy nie ma bezpośredniego dostępu do połączenia, a aplikacja umożliwia dostęp tylko do ograniczonego zestawu akcji i tabel.
W programie SQL Server for Power Apps można używać następujących czterech typów uwierzytelniania połączeń:
| Typ uwierzytelniania | Metoda połączenia Power Apps |
|---|---|
| Zintegrowane Microsoft Entra | Jawnie |
| Uwierzytelnianie programu SQL Server | Niejawne / bezpieczne niejawne |
| Uwierzytelnianie systemu Windows | Niejawne / bezpieczne niejawne |
| Uwierzytelnianie systemu Windows (nieudostępnione) | Jawnie |
Niejawne udostępnianie połączenia
Wszystkie nowe aplikacje automatycznie korzystają z 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 użytkownikom końcowym, co oznacza, że użytkownicy końcowi mogą tworzyć nowe aplikacje w oparciu o te połączenia.
Gdy autor używa bezpieczne połączenia niejawne, oznacza to, że żadne połączenie nie jest udostępniane i żaden użytkownik końcowy nie otrzymuje obiektu połączenia. Eliminuje to ryzyko ponownego użycia połączenia przez autora użytkownika końcowego w celu utworzenia nowej aplikacji. Zamiast tego aplikacja działa z połączeniem proxy, które jest świadome aplikacji i komunikuje się tylko z tą konkretną aplikacją. Połączenie proxy pozwala na ograniczone działania (tworzenie, odczyt, aktualizacja, usuwanie) i dostęp do określonych tabel w aplikacji, które są definiowane podczas publikowania aplikacji. Dlatego tylko autoryzowane działania i dostęp są przyznawane użytkownikowi końcowemu.
Starszy styl prostego niejawnego połączenia faktycznie dystrybuuje obiekt połączenia do użytkownika końcowego. Na przykład, jeśli tworzysz aplikację, która filtruje dane, których nie chcesz, aby użytkownicy widzieli. Odfiltrowane dane są jednak obecne w bazie danych. Polegasz jednak na filtrze skonfigurowanym tak, aby zapewnić, że użytkownicy końcowi nie będą widzieć pewnych danych.
Ponownie, w przypadku starszych prostych połączeń niejawnych, po wdrożeniu aplikacji użytkownicy końcowi mogą korzystać z połączenia wdrożonego wraz z aplikacją w dowolnych nowych aplikacjach, które tworzą. W nowych aplikacjach użytkownicy mogą zobaczyć dane odfiltrowane w Twojej aplikacji. Ważne jest, aby korzystać z nowych bezpiecznych połączeń niejawnych.
Ważne
Po wdrożeniu starszego niejawnie udostępnionego połączenia użytkownikom końcowym, ograniczenia, które mogły zostać wprowadzone w udostępnionej aplikacji (takie jak filtry lub dostęp tylko do odczytu), nie podlegają już weryfikacji w przypadku nowych aplikacji tworzonych przez użytkowników końcowych. Użytkownicy końcowi będą mieli wszelkie prawa, na jakie pozwala uwierzytelnianie w ramach niejawnie współdzielonego połączenia. Dlatego po przekonwertowaniu aplikacji do korzystania z bezpiecznych połączeń niejawnych należy również odwołać połączenia udostępnione aplikacji. Administratorzy mogą uzyskać raport aplikacji z niejawnie udostępnionymi połączeniami za pomocą zestawu narzędzi COE.
Bezpieczeństwo klienta i serwera
Nie możesz polegać na bezpieczeństwie danych poprzez filtrowanie lub inne operacje po stronie klienta, aby zapewnić bezpieczeństwo. Aplikacje wymagające bezpiecznego filtrowania danych muszą zapewniać, że zarówno identyfikacja użytkownika, jak i filtrowanie odbywają się na serwerze.
Użyj usług, takich jak tożsamość Microsoft Entra, zamiast polegać na filtrach opracowanych w aplikacjach, jeśli chodzi o tożsamość użytkownika i bezpieczeństwo. Ta konfiguracja zapewnia oczekiwane filtry po stronie serwera.
Na poniższych ilustracjach pokazano, jak wzorce zabezpieczeń w aplikacjach różnią się między modelami zabezpieczeń po stronie klienta i serwera.
W wzorcu aplikacji zabezpieczeń klienta użytkownik [1] uwierzytelnia aplikację tylko po stronie klienta. Następnie [2] aplikacja żąda informacji usługi, a [3] usługa zwraca informacje wyłącznie na podstawie żądania danych.
We wzorcu zabezpieczeń na serwerze użytkownik najpierw uwierzytelnia usługę, dzięki czemu użytkownik jest [1]znany tej usłudze. Następnie [2]po wywołaniu połączenia z aplikacji usługa [3] używa znanej tożsamości bieżącego użytkownika do odpowiedniego filtrowania danych i zwraca [4] dane.
Opisane powyżej scenariusze niejawnego udostępniania działu obejmują kombinację tych dwóch wzorców. Użytkownik musi zalogować się do usługi Power Apps, używając poświadczeń Microsoft Entra. To zachowanie jest wzorzec aplikacji zabezpieczeń serwera. Użytkownik jest znany za pomocą Microsoft Entra tożsamości w usłudze. W związku z tym aplikacja jest ograniczona do zestawu użytkowników, dla których Power Apps formalnie została udostępniona.
Niejawne udostępniane połączenie z programem SQL Server jest jednak wzorcem aplikacji zabezpieczeń klienta. Program SQL Server wie tylko, że używana jest określone nazwa użytkownika i hasło. Wszelkie filtrowanie po stronie klienta można na przykład pominąć nową aplikację, używając 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 wierszy dla wierszy lub uprawnienia do blokowania określonych obiektów (na przykład kolumn) określonym użytkownikom. To podejście wykorzystuje tożsamość użytkownika Microsoft Entra do filtrowania danych na serwerze.
Niektóre istniejące usługi firmowe stosowane są w taki sam sposób, w jaki tożsamość użytkownika jest przechwycona w warstwach danych Microsoft Dataverse biznesowych. W takim przypadku layer biznesowa może lub nie używać zabezpieczeń na poziomie wiersza w programie SQL Server i odrzucać funkcje bezpośrednio. Jeśli tak się nie stanie, często jest konieczne, aby włączyć zabezpieczenia przy użyciu procedur przechowywanych lub widoków.
Warstwa biznesowa (po stronie serwera) używa znanej tożsamości Microsoft Entra użytkownika w celu wywoływania procedury przechowywanej jako nazwy głównej serwera SQL i filtrowania danych. Aktualnie Power Apps nie jest jednak nawiązywane połączenie z procedurami przechowywanymi. Warstwa biznesowa może również wywoływać widok, który używa tożsamości Microsoft Entra jako podmiotu SQL Server. W tym przypadku należy użyć funkcji Power Apps łączenia się z widokami w celu filtrowania danych po stronie serwera. Udostępnianie tylko widoków użytkownikom Power Automate może wymagać przepływów aktualizacji.