Bezpieczeństwo Power Platform
Jak chronić dane, dostęp i aplikacje w ekosystemie Microsoft Power Platform
Czy infrastruktura IT, w której pracujemy i przechowujemy dane firmowe, jest bezpieczna?
To pytanie powinna zadać sobie każda organizacja korzystająca z usług chmurowych, aplikacji biznesowych i automatyzacji. W Polsce od 3 kwietnia 2026 r. obowiązuje nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa wdrażająca wymagania NIS2, a od 2 sierpnia 2026 r. stosuje się również unijny akt w sprawie sztucznej inteligencji (AI Act), z wyjątkami i okresami przejściowymi przewidzianymi dla części obowiązków. Choć regulacje te dotyczą różnych obszarów, wspólnym kierunkiem jest większa odpowiedzialność organizacji za sposób zarządzania technologią, dostępem do danych i ryzykiem.
Microsoft Power Platform udostępnia rozbudowane mechanizmy bezpieczeństwa, ale sama obecność tych mechanizmów nie oznacza jeszcze, że każda aplikacja lub automatyzacja jest bezpieczna. O rzeczywistym poziomie ochrony decydują również architektura rozwiązania, model uprawnień, polityki dostępu, sposób wykorzystania konektorów oraz governance całego środowiska.
W tym artykule wyjaśniamy, za co odpowiada Microsoft, za co odpowiada organizacja korzystająca z Power Platform oraz jakie mechanizmy pomagają chronić dane w Power Apps, Power Automate, Dataverse i pozostałych elementach ekosystemu Microsoft.
Czy moje dane w Microsoft Power Platform są bezpieczne?
Microsoft zapewnia warstwę infrastruktury chmurowej i odpowiada za bezpieczeństwo tych elementów, które pozostają pod jego kontrolą. Nie oznacza to jednak, że przejmuje pełną odpowiedzialność za bezpieczeństwo danych i aplikacji klienta.
Podstawą jest model odpowiedzialności współdzielonej (ang. Shared Responsibility Model). Zakres obowiązków Microsoftu i klienta zależy od modelu usługi, ale część odpowiedzialności pozostaje po stronie organizacji niezależnie od tego, czy korzysta ona z SaaS, PaaS czy innych usług chmurowych.
Microsoft odpowiada między innymi za fizyczne centra danych, fizyczną sieć, hosty oraz elementy platformy zarządzane przez dostawcę. Organizacja nadal odpowiada za własne dane, konta i tożsamości użytkowników, konfigurację usług, sposób nadawania dostępu oraz ochronę urządzeń końcowych.
W praktyce oznacza to, że Microsoft może zapewnić narzędzia do kontroli ról, polityk danych, uwierzytelniania i audytowania, ale to organizacja musi zdecydować, jak zostaną one skonfigurowane i egzekwowane.
Bezpieczny Microsoft ≠ bezpieczne wdrożenie
To jedno z najważniejszych rozróżnień w całym obszarze cyberbezpieczeństwa Power Platform.
Bezpieczna infrastruktura dostawcy nie zabezpieczy aplikacji, jeżeli użytkownicy otrzymają zbyt szerokie uprawnienia, dane biznesowe zostaną połączone z niewłaściwymi usługami, środowiska nie będą objęte politykami governance albo administrator nie będzie kontrolował sposobu wykorzystywania konektorów.
Podobnie współpraca z firmą wdrożeniową nie przenosi całej odpowiedzialności za bezpieczeństwo na dostawcę. Partner technologiczny może odpowiadać za prawidłowe zaprojektowanie architektury, konfigurację rozwiązania i zastosowanie uzgodnionych mechanizmów zabezpieczeń. Organizacja nadal pozostaje właścicielem danych, użytkowników, procesów i wewnętrznych polityk bezpieczeństwa.
Dlatego bezpieczeństwo powinno być projektowane od początku wdrożenia, a nie dodawane dopiero po uruchomieniu aplikacji.
Dlaczego infrastruktura Microsoft zapewnia wysoki poziom bezpieczeństwa?
Microsoft rozwija zabezpieczenia infrastruktury chmurowej w oparciu o standardy techniczne, procesy audytowe i rozwiązania wspierające zgodność organizacji z wymaganiami regulacyjnymi. Usługi Microsoft są objęte licznymi certyfikacjami i programami zgodności, w tym między innymi ISO 27001 oraz raportami SOC.
Ważne jest jednak rozróżnienie między zgodnością usługi Microsoft a zgodnością konkretnego wdrożenia. To, że platforma spełnia określone standardy lub udostępnia mechanizmy wspierające wymagania prawne i branżowe, nie oznacza automatycznie, że aplikacja zbudowana przez organizację również jest z nimi zgodna. Znaczenie ma między innymi konfiguracja, zakres przetwarzanych danych, sposób nadawania dostępu i przyjęte procedury.
Dla organizacji działających w Unii Europejskiej istotne są również mechanizmy data residency. Microsoft umożliwia korzystanie z usług w określonych regionach i makroregionach oraz rozwija EU Data Boundary dla usług chmurowych. Nie należy jednak rozumieć tego jako dowolnego wskazania konkretnego centrum danych przez klienta. Lokalizacja i przepływ danych zależą od wybranej usługi, regionu, konfiguracji oraz zasad obowiązujących dla danego produktu.
Szczegółowe informacje o programach zgodności dla Microsoft 365, Azure, Dynamics 365 i pozostałych usług znajdują się w Microsoft Compliance Offerings
Zero Trust
Nie ufaj domyślnie, weryfikuj dostęp.
Jednym z fundamentów podejścia Microsoft do bezpieczeństwa jest Zero Trust. Nie jest to pojedyncza funkcja ani produkt, ale model projektowania zabezpieczeń oparty na trzech zasadach: jawnej weryfikacji każdego dostępu, nadawaniu minimalnych wymaganych uprawnień oraz założeniu, że naruszenie bezpieczeństwa może już występować w środowisku.
W praktyce oznacza to, że decyzja o dostępie nie powinna wynikać wyłącznie z tego, że użytkownik zna hasło lub znajduje się w sieci firmowej. Pod uwagę mogą być brane między innymi jego tożsamość, urządzenie, lokalizacja, poziom ryzyka logowania i kontekst dostępu.
Takie podejście wspierają między innymi Microsoft Entra ID, uwierzytelnianie wieloskładnikowe MFA (ang. Multi-Factor Authentication) oraz Conditional Access. Dzięki nim organizacja może wymagać dodatkowej weryfikacji lub ograniczać dostęp w zależności od warunków logowania.
Microsoft rozwija również wieloletnią inicjatywę Secure Future Initiative, rozpoczętą w 2023 r.
Jej podejście opiera się na trzech zasadach:
Secure by Design – bezpieczeństwo uwzględniane już na etapie projektowania produktu lub usługi,
Secure by Default – zabezpieczenia włączone i egzekwowane domyślnie,
Secure Operations – ciągłe doskonalenie zabezpieczeń, monitorowania i sposobu reagowania na zagrożenia.
To podejście dobrze pokazuje kierunek, w którym powinny być projektowane również rozwiązania biznesowe: bezpieczeństwo nie jako dodatkowa funkcja, ale jako część architektury.
SharePoint czy Dataverse
Gdzie przechowywać dane?
W projektach Power Platform często pojawia się pytanie, czy dane aplikacji powinny być przechowywane w SharePoint, czy w Microsoft Dataverse. Oba rozwiązania mogą być wykorzystywane bezpiecznie, ale oferują inny poziom kontroli i są przeznaczone do innych scenariuszy.
SharePoint umożliwia zarządzanie uprawnieniami na poziomie witryny, listy, biblioteki, folderu oraz pojedynczych elementów i plików. W prostszych rozwiązaniach biznesowych może więc zapewnić wystarczający model dostępu. Wraz ze wzrostem liczby użytkowników, wyjątków i indywidualnych uprawnień zarządzanie takim modelem może jednak stawać się coraz bardziej złożone.
Microsoft Dataverse oferuje bardziej rozbudowany model bezpieczeństwa przeznaczony dla aplikacji biznesowych. Wykorzystuje kontrolę dostępu opartą na rolach RBAC (ang. Role-Based Access Control), Security Roles, zespoły i jednostki biznesowe oraz pozwala kontrolować dostęp do rekordów i wybranych kolumn. Dataverse posiada również mechanizmy audytowania zmian i dostępu.
Nie oznacza to, że Dataverse jest zawsze lepszym wyborem, a SharePoint rozwiązaniem wyłącznie dla małych projektów.
Decyzja powinna wynikać z architektury aplikacji, poufności danych, liczby użytkowników, relacji między danymi, wymaganego modelu uprawnień oraz przewidywanej skali rozwiązania.
DLP i Advanced Connector Policies
Kontrola przepływu danych.
Jednym z największych atutów Power Platform jest możliwość łączenia wielu systemów za pomocą konektorów. Ta sama funkcjonalność może jednak stać się źródłem ryzyka, jeżeli organizacja nie kontroluje, z jakimi usługami mogą komunikować się aplikacje i automatyzacje.
Do tego służą polityki danych, tradycyjnie określane jako DLP (ang. Data Loss Prevention). Administrator może klasyfikować i ograniczać wykorzystanie konektorów, aby zmniejszyć ryzyko niepożądanego przepływu danych między systemami biznesowymi a usługami, które nie powinny być z nimi łączone.
W 2026 r. Microsoft rozwija także Advanced Connector Policies (ACP), czyli bardziej restrykcyjny model zarządzania konektorami oparty na liście dozwolonych elementów. W ACP konektory są domyślnie blokowane, dopóki administrator ich jawnie nie dopuści. Pozwala to budować podejście typu default deny i precyzyjniej kontrolować, z jakich integracji mogą korzystać twórcy aplikacji i automatyzacji.
Na obecnym etapie ACP dotyczy certyfikowanych konektorów. W przypadku custom connectors i konektorów HTTP nadal istotne pozostają klasyczne polityki danych i pozostałe mechanizmy governance.
Dobrze zaprojektowana polityka konektorów nie polega więc na zablokowaniu wszystkiego.
Jej zadaniem jest określenie, które przepływy danych są dopuszczalne, a które zwiększałyby ryzyko dla organizacji.
Minimalne uprawnienia i kontrola dostępu
Drugą podstawową zasadą jest ograniczanie dostępu do minimum niezbędnego do wykonania pracy. Użytkownik nie powinien otrzymywać uprawnień „na zapas” tylko dlatego, że może ich kiedyś potrzebować.
W ekosystemie Microsoft pomagają w tym między innymi grupy zabezpieczeń w Microsoft Entra ID, Security Roles w Dataverse, role administracyjne oraz polityki dostępu warunkowego. Każdy z tych mechanizmów działa na innym poziomie, dlatego sama obecność użytkownika w odpowiedniej grupie nie zastępuje prawidłowo zaprojektowanych uprawnień do aplikacji i danych.
Ma to szczególne znaczenie przy danych pracowników, klientów, kontrahentów oraz innych informacjach podlegających ochronie na podstawie RODO (ang. General Data Protection Regulation, GDPR). Bezpieczeństwo nie powinno opierać się na założeniu, że pracownik celowo nie zrobi niczego niewłaściwego. Ryzykiem jest również przejęcie konta, phishing, błędna konfiguracja czy przypadkowe udostępnienie danych.
Audyt i monitoring
Bezpieczeństwo nie kończy się na konfiguracji.
Nawet poprawnie zaprojektowane środowisko wymaga kontroli po uruchomieniu. Z czasem pojawiają się nowe aplikacje, przepływy, konektory i użytkownicy, a konfiguracja, która była prawidłowa w momencie wdrożenia, może przestać odpowiadać aktualnym potrzebom organizacji.
Dlatego ważnym elementem governance jest audytowanie i okresowy przegląd dostępu. Dataverse umożliwia audytowanie zmian w danych i rejestrowanie określonych działań użytkowników. Administratorzy Power Platform mają również do dyspozycji mechanizmy pozwalające analizować środowiska i sposób wykorzystania platformy.
Celem nie jest wyłącznie wykrywanie incydentów.
Regularny audyt pozwala również znaleźć nieużywane uprawnienia, rozwiązania pozostawione po zakończonych projektach, niewłaściwie wykorzystywane konektory czy obszary, w których polityki organizacji przestały odpowiadać rzeczywistemu sposobowi pracy.
Microsoft Trust Center
Gdzie sprawdzać informacje o bezpieczeństwie?
Microsoft udostępnia centralne źródło informacji dotyczących bezpieczeństwa, prywatności, zgodności i transparentności swoich usług – Microsoft Trust Center.
Znajdują się tam materiały dotyczące między innymi Azure, Microsoft 365, Dynamics 365 i Power Platform.
To miejsce szczególnie przydatne dla administratorów, architektów, zespołów bezpieczeństwa oraz działów prawnych i compliance, które potrzebują zweryfikować deklaracje dotyczące sposobu ochrony danych, certyfikacji lub zgodności poszczególnych usług.
Świadome bezpieczeństwo
Czego Microsoft nie zrobi za Ciebie.
Najważniejsza zasada jest prosta:
Microsoft może dostarczyć bezpieczną platformę i zaawansowane mechanizmy ochrony, ale nie zaprojektuje za organizację wszystkich reguł dostępu do jej danych.
To po stronie firmy pozostają między innymi decyzje dotyczące klasyfikacji informacji, nadawania uprawnień, podziału środowisk, wykorzystania konektorów, zarządzania kontami użytkowników, cyklu życia aplikacji oraz reagowania na zmiany i incydenty.
Dlatego architektura bezpieczeństwa powinna powstawać razem z architekturą aplikacji. Jeżeli role, polityki danych, governance i sposób przechowywania informacji zostaną przemyślane dopiero po wdrożeniu rozwiązania, uporządkowanie środowiska będzie znacznie trudniejsze.
Microsoft zapewnia bezpieczną platformę
Ale sposób wdrożenia decyduje o bezpieczeństwie rozwiązania.
Power Platform daje organizacjom rozbudowany zestaw mechanizmów bezpieczeństwa: od zarządzania tożsamością i dostępem, przez polityki konektorów i modele uprawnień, po audytowanie oraz narzędzia governance. Sama dostępność tych funkcji nie jest jednak gwarancją bezpieczeństwa.
Bezpieczne środowisko powstaje wtedy, gdy mechanizmy platformy są świadomie dopasowane do danych, procesów, użytkowników i ryzyka konkretnej organizacji. W praktyce oznacza to stosowanie minimalnych uprawnień, kontrolę przepływu danych, właściwy dobór miejsca ich przechowywania, regularny audyt oraz projektowanie zabezpieczeń jeszcze przed rozpoczęciem developmentu.
Dlaczego Antdata to zaufany dostawca rozwiązań Microsoft Power Platform?
Wieloletnie doświadczenie i znajomość architektury platformy pozwalają nam patrzeć na wdrożenie szerzej niż tylko przez pryzmat działania samej aplikacji. Rozwiązanie musi nie tylko realizować proces biznesowy, ale również prawidłowo zarządzać dostępem do danych, skalować się wraz z organizacją i pozostawać możliwe do utrzymania w kolejnych latach.
Wdrożenia Antdata służą tysiącom użytkowników i od lat funkcjonują w organizacjach na całym świecie.
Projektujemy rozwiązania w ekosystemie Microsoft obejmujące aplikacje biznesowe Power Apps, automatyzacje Power Automate, analitykę Power BI i rozwiązania wykorzystujące AI. Prowadzimy również audyty istniejących środowisk i aplikacji.
Planujesz bezpieczne wdrożenie Power Platform?
Jeżeli planujesz wdrożenie Power Platform w swojej organizacji albo chcesz sprawdzić bezpieczeństwo już działających aplikacji, możemy przeanalizować architekturę rozwiązania, model dostępu, sposób przechowywania danych, polityki konektorów i governance środowiska.
Umów bezpłatną 30-minutową konsultację ze specjalistą Antdata i sprawdź, które obszary warto zabezpieczyć jeszcze przed rozwojem kolejnych aplikacji i automatyzacji.
Skontaktuj się z nami: contact@antdata.eu
lub skorzystaj z poniższego formularza.
Wybierz datę telefonicznej konsultacji.
