Audyt Microsoft Power Platform to przegląd sposobu, w jaki organizacja tworzy, udostępnia i utrzymuje aplikacje Power Apps oraz automatyzacje Power Automate. Obejmuje zasoby i ich właścicieli, środowiska, konektory, polityki ochrony danych, uprawnienia, proces wdrażania zmian i licencje. Nie chodzi o ocenę każdego ekranu aplikacji, lecz o ustalenie, które rozwiązania są bezpieczne i pod kontrolą, a które zależą od przypadkowych decyzji.
Zakres audytu powinien wynikać z roli rozwiązań. Inaczej ocenia się formularz wykorzystywany przez kilka osób, a inaczej przepływ zatwierdzający zamówienia, bez którego dział zakupów nie może pracować.
Inwentaryzacja - co działa i kto z tego korzysta?
Pierwszym krokiem jest ustalenie, jakie aplikacje, przepływy i środowiska faktycznie istnieją. Sama liczba zasobów niewiele mówi. Istotne są ich funkcje, ostatnia aktywność, źródła danych, odbiorcy oraz zależności między komponentami.
- Aplikacje Power Apps. Które służą do obsługi procesów firmowych, a które są rozwiązaniami osobistymi? Czy nadal mają aktywnych użytkowników?
- Przepływy Power Automate. Co je uruchamia, jakie czynności wykonują i co stanie się, gdy przepływ przestanie działać?
- Środowiska i połączenia. Gdzie przechowywane są zasoby, z jakich konektorów korzystają i do jakich systemów uzyskują dostęp?
- Odpowiedzialność. Kto zna działanie rozwiązania, może je zmienić i zareagować na awarię?
Inwentaryzację można oprzeć na informacjach z Power Platform admin center i dostępnych narzędziach administracyjnych. Wyniki trzeba jednak odnieść do procesu biznesowego. Nieaktywny od miesięcy przepływ może być zbędny, ale może też obsługiwać zadanie uruchamiane tylko raz na rok.
Właściciele i połączenia - ryzyko ukryte w działającej automatyzacji
Jednym z częstszych problemów organizacyjnych jest uzależnienie ważnego procesu od konta konkretnego pracownika. Dotyczy to zarówno własności przepływu, jak i używanych przez niego połączeń.
Przykładowo przepływ pobiera dane z SharePoint, zapisuje je w systemie zewnętrznym i wysyła potwierdzenie do Teams. Jeżeli część operacji korzysta z poświadczeń osoby, która odchodzi z firmy, sama obecność współwłaściciela nie gwarantuje ciągłości działania. Trzeba sprawdzić połączenia każdej krytycznej akcji.
W audycie ocenia się również konta techniczne i tożsamości aplikacyjne. W wybranych scenariuszach właścicielem przepływu może być service principal w Microsoft Entra ID, ale taki model wymaga prawidłowej konfiguracji połączeń oraz osobnej weryfikacji licencjonowania i limitów. Nie jest uniwersalnym zamiennikiem konta użytkownika.
DLP, konektory i dostęp do danych
Polityki ochrony danych, określane jako DLP (Data Loss Prevention), pomagają kontrolować, które konektory mogą być wykorzystywane razem w aplikacjach i przepływach. W klasycznym modelu polityk konektory są przypisywane do grup Business, Non-Business i Blocked. Rozwiązania łączące konektory z niezgodnych grup mogą zostać zablokowane.
Audyt powinien sprawdzić nie tylko istnienie polityk, ale także ich zakres: czy obowiązują we właściwych środowiskach, jak traktowane są nowe konektory, konektory niestandardowe i połączenia HTTP oraz czy zmiana reguł nie przerwie działających procesów. W organizacjach stosujących zaawansowane polityki konektorów (Advanced Connector Policies, ACP) trzeba dodatkowo ocenić zasady dopuszczania certyfikowanych konektorów.
DLP nie zastępuje kontroli uprawnień. Nawet konektor należący do dozwolonej grupy może korzystać z konta o zbyt szerokim dostępie. Dlatego osobno sprawdza się uprawnienia do danych w SharePoint, Dataverse i pozostałych systemach, role użytkowników oraz sposób udostępniania aplikacji.
Środowiska i zasady administracyjne
Podział na środowiska pomaga oddzielić eksperymenty od rozwiązań produkcyjnych. W praktyce problem pojawia się wtedy, gdy kluczowa aplikacja pozostaje w środowisku domyślnym, a jej właściciel traktuje ją jak prywatny projekt.
Przegląd obejmuje przeznaczenie środowisk, przypisane role, polityki danych, reguły tworzenia nowych zasobów i sposób nadzoru nad aplikacjami produkcyjnymi. Warto również sprawdzić, czy organizacja korzysta z Managed Environments i czy aktywowane funkcje administracyjne odpowiadają potrzebom oraz uprawnieniom licencyjnym użytkowników.
Nie każda organizacja potrzebuje wielu środowisk o identycznej strukturze. Istotne jest to, aby dla ważnych rozwiązań istniała jasna granica między rozwojem, testowaniem i produkcją.
ALM - jak wprowadzane są zmiany?
ALM (Application Lifecycle Management), czyli zarządzanie cyklem życia aplikacji, określa sposób przygotowania, testowania i wdrażania kolejnych wersji. Podczas audytu sprawdza się, czy rozwój ważnych aplikacji nie polega na bezpośrednim poprawianiu produkcji.
W Power Platform istotną rolę odgrywają solutions, referencje połączeń (connection references) oraz zmienne środowiskowe (environment variables). Pozwalają przenosić komponenty między środowiskami bez wpisywania ustawień właściwych dla produkcji na stałe do aplikacji. Do kontrolowanego wdrażania można wykorzystać także pipelines, uwzględniając ich wymagania środowiskowe i licencyjne.
Jeżeli aplikacja obsługuje krytyczny proces, powinno być wiadomo, kto zatwierdza zmianę, gdzie jest ona testowana oraz jak wrócić do poprzedniego działania w razie problemu. Dla prostych rozwiązań osobistych proces może być lżejszy.
Licencje - nie tylko liczba przydzielonych planów
Koszt i zgodność licencyjna zależą od tego, kto używa aplikacji, jakie funkcje są wykorzystywane i w jakim środowisku działa rozwiązanie. Audyt nie powinien ograniczać się do zestawienia kupionych i przypisanych licencji.
Trzeba ustalić, które aplikacje i przepływy używają funkcji Premium, czy zastosowano odpowiedni model licencjonowania automatyzacji oraz czy Managed Environments, Dataverse i sposób uruchamiania przepływów nie powodują dodatkowych wymagań. Weryfikacja musi opierać się na aktualnych warunkach Microsoft, ponieważ dostępne plany i prawa użytkowania mogą się zmieniać.
Wynikiem nie zawsze będzie propozycja zakupu nowych licencji. Czasem wystarczy uporządkować wykorzystanie istniejących zasobów albo zmienić sposób wdrożenia konkretnego procesu.
Co powinien dostarczyć audyt Power Platform?
Przydatny raport z audytu wskazuje konkretne zasoby, zidentyfikowane ryzyko, jego wpływ na organizację i możliwe działanie naprawcze. Sam komunikat „uporządkować środowiska” jest niewystarczający.
Lepszym wynikiem jest na przykład informacja, że przepływ obsługujący akceptację faktur korzysta z połączenia prywatnego użytkownika, nie ma zastępstwa właściciela, a błędy jego wykonań nie są monitorowane. Tak opisany problem można przypisać do osoby odpowiedzialnej i zaplanować poprawkę bez zgadywania, od czego zacząć.
Rekomendacje warto podzielić według pilności: najpierw niekontrolowany dostęp do danych i ryzyko przerwania krytycznych procesów, później porządkowanie wdrożeń i optymalizacja kosztów. Audyt ma prowadzić do decyzji, a nie jedynie do długiej listy ustawień.
Najczęstsze pytania o audyt Power Platform
Czy audyt Power Platform wymaga zatrzymania aplikacji lub przepływów?
Zwykle nie. Inwentaryzację, przegląd konfiguracji i analizę uprawnień można prowadzić bez wyłączania rozwiązań. Testy zmian w politykach DLP, połączeniach czy wdrożeniach należy zaplanować osobno, bo mogą wpłynąć na działające procesy.
Czy polityka DLP wystarczy do zabezpieczenia Power Platform?
Nie. Polityki danych ograniczają możliwość używania określonych konektorów razem lub blokują wybrane konektory. Nie zastępują kontroli dostępu do źródeł danych, uprawnień w Dataverse, właściwego zarządzania tożsamością ani przeglądu połączeń używanych przez aplikacje i przepływy.
Co dzieje się z przepływem Power Automate, gdy odchodzi jego właściciel?
Przepływ nie musi od razu przestać działać, ale może utracić aktywnego właściciela lub korzystać z połączeń osoby, której konto zostało wyłączone. Audyt powinien wykazać takie zależności i wskazać właściwy model własności oraz połączeń.
Czy każda aplikacja Power Apps wymaga pełnego procesu ALM?
Nie. Prosta aplikacja osobista może mieć lżejsze zasady utrzymania. Aplikacja obsługująca ważny proces firmowy powinna mieć właściciela, dokumentację zależności, kontrolę zmian i możliwość bezpiecznego wdrażania kolejnych wersji.
Dokumentacja techniczna Microsoft
Przy przeglądzie zasobów, polityk ochrony danych, automatyzacji i wdrożeń pomocne są następujące materiały Microsoft Learn:
- Inwentaryzacja aplikacji, przepływów i środowisk Power Platform
- Klasyfikacja konektorów i zasady DLP
- Współwłasność przepływów i zarządzanie połączeniami
- Wdrażanie rozwiązań przez pipelines w Power Platform
- Podstawy licencjonowania Microsoft Power Platform
Powiązane materiały
Potrzebujesz wdrożenia lub audytu?
MicrosoftBI wyjaśnia podejście i architekturę. Jeżeli chcesz przejść do realizacji, sprawdź usługę Antdata odpowiadającą temu obszarowi.
Usługi Antdata →