Governance Power Platform - praktyczna checklista

Governance nie powinien zaczynać się od zakazów

Governance Power Platform to zestaw reguł określających, kto może tworzyć rozwiązania, z jakich danych wolno im korzystać, kto odpowiada za działanie aplikacji i jak wprowadza się zmiany. Nie jest pojedynczą funkcją w panelu administracyjnym. Składają się na niego zarówno ustawienia techniczne, jak i decyzje organizacyjne.

Innych zabezpieczeń wymaga osobisty przepływ przypominający o zadaniu, a innych aplikacja zatwierdzająca wydatki, z której korzysta kilka działów. Najpierw trzeba rozróżnić te przypadki. Jednolity, ciężki proces dla wszystkiego szybko zniechęci użytkowników; brak zasad dla rozwiązań krytycznych pozostawi firmę zależną od ich autorów.

1. Środowiska - wiadomo, gdzie powstają i działają rozwiązania

Środowisko (environment) oddziela zasoby Power Platform według celu, zespołu lub poziomu kontroli. Środowisko domyślne jest dostępne szeroko, dlatego nie powinno bez dodatkowej analizy stawać się docelowym miejscem dla aplikacji obsługującej ważny proces firmowy.

• Przypisz przeznaczenie środowisk. Ustal, co może pozostać w środowisku domyślnym, gdzie rozwija się aplikacje i które środowiska służą do testów oraz produkcji.
• Wyznacz odpowiedzialnych. Dla każdego środowiska określ administratorów, zasady nadawania dostępu i osobę podejmującą decyzje o nowych zasobach.
• Ustal drogę do produkcji. Rozwiązanie wykorzystywane przez dział nie powinno trafiać do produkcji tylko dlatego, że autor udostępnił link większej liczbie osób.

Jak sprawdzić: administrator powinien umieć wskazać środowisko produkcyjne danej aplikacji, jego właściciela administracyjnego i sposób zatwierdzania zmian.

2. DLP - konektory mają jasne zasady wykorzystania

Polityki danych, tradycyjnie określane jako Data Loss Prevention (DLP), pozwalają klasyfikować konektory w grupach Business, Non-Business i Blocked. Kontrolują, jakie połączenia można wykorzystywać razem w aplikacjach i przepływach oraz które konektory można zablokować. Nie każdy konektor może jednak trafić do grupy Blocked.

• Podziel konektory według ryzyka. Określ, które usługi mogą przetwarzać dane firmowe i jakie integracje nie powinny występować w tym samym rozwiązaniu.
• Sprawdź zakres polityk. Zasady muszą obejmować właściwe środowiska; zweryfikuj także sposób klasyfikowania nowych i niestandardowych konektorów.
• Przetestuj zmianę zasad. Zaostrzenie polityki może wpłynąć na już działające aplikacje i przepływy. Najpierw ustal zależności, później wdrażaj ograniczenia.

Jak sprawdzić: dla aplikacji korzystającej np. z SharePoint i usługi zewnętrznej powinno być wiadomo, czy użycie obu konektorów jest dopuszczalne i która polityka o tym decyduje. DLP nie zastępuje uprawnień do samych danych.

3. Właściciele - aplikacja nie znika razem z pracownikiem

Typowy problem nie zaczyna się od błędu w kodzie. Przepływ obsługujący zgłoszenia działa przez dwa lata, a potem zatrzymuje się po wyłączeniu konta osoby, której połączenia wykorzystywał. Samo dopisanie współwłaściciela nie usuwa automatycznie zależności od wszystkich uwierzytelnień.

• Rozdziel odpowiedzialność. Właściciel biznesowy odpowiada za proces i jego reguły, a opiekun techniczny za działanie rozwiązania, połączenia i usuwanie awarii.
• Spisz zależności. Dla krytycznych przepływów wskaż używane połączenia, konektory, tożsamości i licencje oraz sposób ich odnawiania.
• Przygotuj zmianę właściciela. Uwzględnij odejście pracownika, reorganizację działu i przejęcie rozwiązania przez inny zespół.

4. ALM - zmiany przechodzą kontrolowaną drogę

Zarządzanie cyklem życia aplikacji, czyli Application Lifecycle Management (ALM), zaczyna mieć znaczenie wtedy, gdy kolejna wersja może wpłynąć na proces biznesowy. Poprawka formularza w prywatnej aplikacji to co innego niż zmiana logiki zatwierdzania faktur.

• Umieść ważne rozwiązania w solutions. Pozwala to zarządzać składnikami aplikacji i przepływów jako całością, zamiast przenosić je ręcznie bez kontroli zależności.
• Oddziel rozwój, test i produkcję. Dla rozwiązań biznesowych ustal ścieżkę wdrażania, testy i osobę zatwierdzającą publikację. Warto korzystać z zarządzanych rozwiązań w środowiskach docelowych.
• Kontroluj konfigurację. Zmienne środowiskowe i odwołania do połączeń pomagają uniknąć ręcznego poprawiania adresów oraz kont po każdym wdrożeniu. Do automatyzacji wdrożeń można wykorzystać pipelines w Power Platform.

Jak sprawdzić: czy zespół potrafi odtworzyć ostatnie wdrożenie i wskazać, która wersja działa na produkcji, bez pytania autora o plik zapisany lokalnie?

5. Monitoring i licencje - wiadomo, co kosztuje i co przestaje działać

Nawet poprawnie wdrożona aplikacja wymaga nadzoru. W Power Platform trzeba rozróżnić problemy z samym przepływem, połączeniem, dostępem do źródła danych i uprawnieniami użytkownika. Dodatkowo zakres wykorzystania zasobów zmienia się wraz z liczbą odbiorców.

• Ustal cykliczny przegląd. Sprawdzaj aktywność aplikacji i przepływów, błędy uruchomień, zasoby bez właściciela oraz integracje, które przestały być potrzebne.
• Wyznacz reakcję na awarie. Określ, kto otrzymuje powiadomienia i co robi, gdy proces przestanie działać poza godzinami pracy autora.
• Sprawdzaj licencje w kontekście użycia. Konektor Premium, uruchamianie przepływów i korzystanie z Managed Environments mogą mieć różne konsekwencje licencyjne. Oceniaj konkretny scenariusz, nie samą nazwę produktu.

W szczególności Managed Environments oferują dodatkowe funkcje administracyjne, ale aktywne korzystanie z zasobów w takich środowiskach podlega odrębnym wymaganiom licencyjnym. Decyzję o ich włączeniu trzeba poprzedzić sprawdzeniem użytkowników i dostępnych uprawnień.

Od czego wdrażać zasady w już działającej organizacji?

Nie trzeba zaczynać od pełnej przebudowy wszystkich środowisk. Najpierw zbierz listę rozwiązań, które rzeczywiście obsługują pracę zespołów, korzystają z danych wrażliwych albo łączą wiele systemów. Dla nich sprawdź właścicieli, połączenia, polityki danych i plan awaryjny.

Dopiero później porządkuj mniej krytyczne aplikacje oraz automatyzuj utrzymanie wspólnych zasad. Taki podział pozwala ograniczyć najpoważniejsze ryzyka bez odbierania pracownikom możliwości samodzielnego usprawniania pracy.

Jeżeli nie wiesz jeszcze, jakie zasoby istnieją i z czego korzystają, dobrym punktem wyjścia będzie audyt Power Platform. Checklista opisuje zasady, które mają działać na co dzień; audyt sprawdza, na ile obecne środowisko rzeczywiście je spełnia.

Najczęstsze pytania

Dokumentacja Microsoft

Poniższe materiały Microsoft Learn opisują funkcje administracyjne i ograniczenia, do których odwołuje się checklista:

• Strategia środowisk Power Platform - podział środowisk i reguły zarządzania zasobami.
• Polityki danych i konektory - grupy Business, Non-Business i Blocked.
• Zmiana właściciela przepływu - konsekwencje własności i obsługa kont aplikacyjnych.
• Pipelines w Power Platform - kontrolowane wdrażanie rozwiązań.
• Licencjonowanie Managed Environments - wymagania dotyczące aktywnego korzystania z aplikacji i przepływów.

Powiązane materiały