Zabezpieczanie portalu Power Pages: dogłębne spojrzenie na uprawnienia tabel i zakresy
By Mirko Peters ·
Witamy ponownie w blogu podcastu! Budując aplikacje internetowe dla klientów na platformie Microsoft Power Platform, bezpieczeństwo nie może być dodatkiem na koniec. Power Pages to niezwykle przydatne narzędzie do szybkiego wdrażania solidnych portali zewnętrznych połączonych bezpośrednio z Dataverse. Jednak wraz z wielką mocą przychodzi wielka odpowiedzialność, a dokładniej odpowiedzialność za to
Automatically translated with AI from the original post. Read the English original
Witamy ponownie w blogu podcastu! Budując aplikacje internetowe dla klientów na platformie Microsoft Power Platform, bezpieczeństwo nie może być dodatkiem na koniec. Power Pages to niezwykle przydatne narzędzie do szybkiego wdrażania solidnych portali zewnętrznych połączonych bezpośrednio z Dataverse. Jednak wraz z wielką mocą przychodzi wielka odpowiedzialność, a dokładniej odpowiedzialność za to, by wrażliwe dane organizacji nie wyciekły przypadkowo do publicznej sieci ani nie przekroczyły granic organizacji.
W tym wpisie szczegółowo omówimy kluczowe koncepcje architektury bezpieczeństwa, o których rozmawialiśmy w ostatnim odcinku. Jeśli jeszcze go nie słuchałeś, koniecznie sprawdź odcinek Build Customer Portals with Power Pages and Dataverse, w którym znajdziesz kompletny przewodnik po konfiguracji środowiska, obsłudze zewnętrznych tożsamości i wdrażaniu pierwszego rozwiązania portalu.
Przyjrzyjmy się dokładnie mechanizmom zabezpieczeń Power Pages, zaczynając od tego, jak planować granice danych i opanować uprawnienia tabel.
Wprowadzenie do zabezpieczeń Power Pages
Gdy tworzysz nową witrynę Power Pages, platforma zapewnia elastyczne, wysoce konfigurowalne płótno. Pod nim kryje się jednak bezpośrednie połączenie z Twoim środowiskiem Microsoft Dataverse. Jeśli konfiguracja zabezpieczeń zostanie źle zarządzana, każdy pojedynczy rekord w bazie danych może zostać ujawniony przez niezabezpieczony punkt końcowy lub źle ograniczony widok listy.
Zabezpieczenia w Power Pages opierają się na wielowarstwowej strategii obrony. Na zewnętrznej warstwie znajdują się mechanizmy uwierzytelniania, takie jak Azure AD B2C, konta lokalne lub zewnętrzni dostawcy tożsamości, które zapewniają, że użytkownicy potwierdzają swoją tożsamość. Na wewnętrznej warstwie działają role sieciowe oraz uprawnienia tabel Dataverse. To one precyzyjnie określają, co uwierzytelnione tożsamości mogą widzieć, tworzyć, aktualizować lub usuwać. Poprawna konfiguracja decyduje o tym, czy portal firmowy będzie bezpieczny, czy stanie się źródłem poważnego wycieku danych.
Planowanie granic danych i uprawnień tabel
Zanim dotkniesz choćby jednego przycisku w Power Pages Studio, weź tablicę i dokładnie zaplanuj granice danych. Jest to prawdopodobnie najważniejsze 15 minut w całym cyklu życia projektu portalu.
Zacznij od sporządzenia pełnego spisu wszystkich tabel Dataverse, które zamierzasz udostępnić zewnętrznym użytkownikom. Dla każdej tabeli zdefiniuj absolutnie minimalny zestaw działań CRUD, który jest potrzebny. Czy klient naprawdę musi mieć możliwość usunięcia faktury, czy wystarczy mu uprawnienie Read i Append? Po określeniu działań musisz ustalić zakres wierszy dla każdej tabeli:
- Zakres kontaktu: Użytkownik może wchodzić w interakcje wyłącznie z rekordami bezpośrednio powiązanymi z jego rekordem kontaktu.
- Zakres konta: Użytkownik może wchodzić w interakcje z rekordami powiązanymi z całą jego firmą lub kontem.
- Zakres globalny: Użytkownik może zobaczyć wszystkie rekordy w całej tabeli (zwykle zarezerwowane dla publicznych artykułów bazy wiedzy lub metadanych).
Dzięki wcześniejszemu określeniu tych granic ustanawiasz podstawę zasady najmniejszych uprawnień, zanim zostanie zbudowana jakakolwiek konfiguracja w środowisku deweloperskim.
Zrozumienie zakresów kontaktu i konta
Jednym z najczęstszych źródeł nieporozumień dla twórców, którzy zaczynają pracę z Power Pages, jest zrozumienie różnicy między zakresami kontaktu i konta. Wybór niewłaściwego zakresu może albo całkowicie zepsuć doświadczenie użytkownika, ukrywając istotne dane firmy, albo nieświadomie ujawnić poufne dane nieupoważnionym osobom.
Zakres kontaktu został zaprojektowany z myślą o indywidualnych portalach w stylu konsumenckim. Jeśli użytkownik loguje się i zgłasza zgłoszenie do pomocy technicznej, uprawnienie z zakresem kontaktu zapewnia, że może przeglądać wyłącznie sprawy, w których jest jawnie wskazany jako główny kontakt lub twórca. Jeśli inny użytkownik z tej samej firmy zaloguje się, nie zobaczy osobistych zgłoszeń swojego kolegi.
Z drugiej strony zakres Account został zaprojektowany z myślą o architekturze portali B2B. W scenariuszu B2B chcesz, aby menedżer kont lub główny specjalista ds. zakupów mógł przeglądać wszystkie sprawy, zamówienia i faktury powiązane z nadrzędnym kontem firmowym. Gdy przypiszesz zakres Account do uprawnienia tabeli, portal sprawdza nadrzędne konto powiązane z rekordem Contact zalogowanego użytkownika, a następnie wyświetla wszystkie powiązane rekordy podrzędne należące do tej organizacji. Prawidłowe odwzorowanie tej relacji w usłudze Dataverse ma kluczowe znaczenie dla powodzenia w scenariuszach B2B.
Definiowanie ról sieci Web i unikanie pułapki roli Uwierzytelnieni użytkownicy
Role sieci Web łączą uwierzytelnionych użytkowników z uprawnieniami tabel Dataverse. Domyślnie usługa Power Pages zawiera rolę o nazwie „Uwierzytelnieni użytkownicy”. Wielu administratorów wpada właśnie w tę niebezpieczną pułapkę.
Domyślnie każdy użytkownik, który pomyślnie zaloguje się do portalu, automatycznie trafia do roli Uwierzytelnieni użytkownicy. Jeśli przypiszesz do tej domyślnej roli szerokie uprawnienia do tabel – a jeszcze gorzej, uprawnienia o zakresie Global – każda osoba rejestrująca się na stronie natychmiast odziedziczy te szerokie uprawnienia. To poważny antywzorzec zabezpieczeń.
Zamiast tego twórz własne, szczegółowe role sieci Web dopasowane do konkretnych typów użytkowników. Na przykład:
- CustomerUser: powiązana z zakresem Contact dla tabel operacyjnych, takich jak Cases i Orders, pozwalająca użytkownikom śledzić własne interakcje.
- AccountManager: powiązana z zakresem Account, dająca wyznaczonym liderom organizacji wgląd w zasoby całej firmy.
- KnowledgeBaseViewer: przypisana globalnie, ale ściśle ograniczona do działań tylko do odczytu na publicznie dostępnych artykułach pomocy technicznej.
Zawsze usuwaj niepotrzebny domyślny dostęp i upewnij się, że użytkownicy są jawnie przypisani do dedykowanych ról, zgodnie z ich relacją organizacyjną.
Wzmacnianie widoczności na poziomie pól i ochrona danych osobowych (PII)
Kontrolowanie dostępu do wierszy za pomocą zakresów tabel to dopiero połowa sukcesu. Musisz też zwracać szczególną uwagę na to, jakie dane są widoczne w poszczególnych wierszach i listach. Ujawnienie danych osobowych umożliwiających identyfikację (PII), takich jak numery telefonów, adresy domowe, dane finansowe czy wewnętrzne notatki o pracownikach, może prowadzić do poważnych naruszeń zgodności z przepisami (np. RODO lub CCPA).
Podczas tworzenia list i podstawowych formularzy w usłudze Power Pages usuń wrażliwe kolumny z widoków. To, że pole jest ukryte w układzie formularza po stronie użytkownika, nie oznacza, że nie można go odczytać lub pobrać przez bazowe interfejsy API sieci Web, jeśli uprawnienia są zbyt szerokie. Używaj oddzielnych, wzmocnionych widoków (na przykład wyznaczonego widoku „PublicView”), które zawierają wyłącznie bezpieczne, oczyszczone kolumny. Jeśli niektóre kolumny muszą pozostać w tabeli bazy danych, rozważ wdrożenie zabezpieczeń na poziomie kolumn w usłudze Dataverse, aby całkowicie ograniczyć dostęp na poziomie silnika bazy danych.
Testowanie penetracyjne uprawnień portalu
Nigdy nie możesz po prostu założyć, że model zabezpieczeń działa – musisz to udowodnić. Przed wdrożeniem dowolnego rozwiązania portalu do środowiska testowego lub produkcyjnego przeprowadź rygorystyczne testy penetracyjne uprawnień tabel i logiki routingu.
Utwórz konta testowe dla każdej zdefiniowanej roli sieci Web. Zaloguj się jako standardowy użytkownik CustomerUser i spróbuj wyświetlić dane należące do innego rekordu Contact lub Account. Wypróbuj manipulację adresem URL i modyfikację identyfikatorów GUID, zmieniając identyfikatory rekordów w pasku adresu przeglądarki, aby sprawdzić, czy serwer prawidłowo blokuje nieautoryzowane żądania. Ponadto przejrzyj dzienniki diagnostyczne i audytu portalu, aby zweryfikować, czy próby eskalacji uprawnień generują odpowiednie odpowiedzi 403 Forbidden.
Podsumowanie i najlepsze praktyki
Zabezpieczenie portalu Power Pages wymaga przemyślanego planowania, ścisłego przestrzegania zasady najmniejszych uprawnień oraz dokładnego zrozumienia uprawnień tabel i zakresów Dataverse. Odchodząc od niebezpiecznych ustawień domyślnych, takich jak rola Uwierzytelnieni użytkownicy, starannie ograniczając dostęp do tabel na poziomie Contact lub Account oraz wzmacniając widoczność pól, możesz zbudować portal dla klientów, który będzie zarówno w pełni funkcjonalny, jak i wyjątkowo bezpieczny.
Aby zgłębić ten temat jeszcze bardziej i zobaczyć kompletny przewodnik wdrożenia od początku do końca – obejmujący konfigurację tożsamości zewnętrznych, projektowanie architektury rozwiązania i przygotowanie do uruchomienia – koniecznie posłuchaj naszego towarzyszącego odcinka podcastu: Build Customer Portals with Power Pages and Dataverse. Dziękujemy za lekturę i zapraszamy do śledzenia kolejnych eksperckich porad dotyczących opanowania platformy Microsoft Power Platform!