Bezpieczeństwo M365: jak wykrywać nadużycia uprawnień do SharePoint/OneDrive przez aplikacje OAuth

1. Wprowadzenie: dlaczego aplikacje OAuth są ryzykiem dla SharePoint i OneDrive w Microsoft 365

SharePoint i OneDrive przechowują znaczną część organizacyjnej wiedzy: dokumenty projektowe, umowy, dane osobowe i pliki robocze użytkowników. W Microsoft 365 dostęp do tych zasobów nie odbywa się wyłącznie przez przeglądarkę czy aplikacje pakietu Office. Coraz częściej pośredniczą w nim aplikacje zewnętrzne i integracje, które proszą o dostęp w modelu OAuth. To wygodne rozwiązanie dla użytkowników i zespołów IT, ale jednocześnie istotne źródło ryzyka, bo decyzja o przyznaniu dostępu bywa podejmowana szybko, a skutki mogą być długotrwałe.

OAuth w skrócie pozwala aplikacji uzyskać uprawnienia do danych w imieniu użytkownika lub jako samodzielna aplikacja, bez potrzeby poznawania hasła. Użytkownik widzi ekran zgody (consent) z listą żądanych uprawnień i jednym kliknięciem może je przyznać. Z perspektywy bezpieczeństwa oznacza to, że atakujący nie musi kraść hasła, aby uzyskać dostęp do plików — wystarczy, że doprowadzi do udzielenia zgody podejrzanej aplikacji lub wykorzysta nadmiarowo uprzywilejowaną aplikację, która już działa w środowisku.

Najważniejszy problem polega na tym, że OAuth omija klasyczny model „użytkownik loguje się do aplikacji”. Dostęp jest realizowany przez tokeny i uprawnienia nadane aplikacji. W konsekwencji część kontroli, do których przywykły zespoły bezpieczeństwa (np. koncentracja na logowaniach interaktywnych i zdarzeniach typu „hasło/MFA”), nie wystarcza do wykrycia nadużyć. Aplikacja może pobierać lub modyfikować pliki w tle, zautomatyzowanie i w godzinach, w których nikt nie zwraca uwagi.

Dlaczego to szczególnie dotyczy SharePoint i OneDrive? Ponieważ:

• Zakres danych jest szeroki — aplikacje mogą uzyskać dostęp do bibliotek SharePoint, plików w OneDrive oraz dokumentów współdzielonych.
• Dostęp bywa „cichy” — działania wykonywane przez aplikację mogą wyglądać jak legalna automatyzacja (synchronizacja, migracja, backup, podpis elektroniczny, workflow), co utrudnia odróżnienie nadużycia od normalnej pracy.
• Uprawnienia mogą być nadmiarowe — aplikacja prosząca o szerokie zakresy (np. pełny odczyt wszystkich plików) staje się atrakcyjnym celem lub narzędziem ataku.
• Skutki kompromitacji są trudne do szybkiego odwrócenia — wyciek może objąć tysiące plików, a wykrycie „kiedy i co zostało pobrane” nie zawsze jest trywialne.

Ważne jest też rozróżnienie dwóch podstawowych modeli działania aplikacji OAuth, które wpływają na profil ryzyka:

• Dostęp delegowany — aplikacja działa w kontekście zalogowanego użytkownika i zwykle ma zasięg zbliżony do jego uprawnień. To ryzykowne, gdy użytkownik ma szerokie dostępy lub gdy aplikacja uzyskuje możliwość masowego pobierania danych.
• Dostęp aplikacyjny — aplikacja działa jako „tożsamość aplikacji” i może mieć uprawnienia niezależne od konkretnego użytkownika, potencjalnie obejmujące całe środowisko lub wiele witryn. To szczególnie wrażliwy model, bo błąd w nadaniu uprawnień lub kompromitacja aplikacji może dać dostęp na dużą skalę.

W praktyce ryzyko nie wynika z samej obecności OAuth, ale z połączenia kilku czynników: łatwości udzielenia zgody, słabej widoczności działań aplikacji w codziennym monitoringu oraz faktu, że aplikacje potrafią utrzymywać dostęp przez dłuższy czas. Dlatego w środowiskach M365 ochrona SharePoint i OneDrive musi uwzględniać nie tylko użytkowników i ich logowania, ale również krajobraz aplikacji OAuth, ich uprawnienia i zachowanie.

2. Typowe wektory nadużyć: phishing consent, rogue apps, nadmiarowe uprawnienia i persystencja przez refresh tokeny

Aplikacje OAuth w M365 są wygodnym mechanizmem integracji, ale w kontekście SharePoint i OneDrive stanowią atrakcyjny cel, bo mogą uzyskać dostęp do danych bez przejmowania hasła i często działają w tle. Ten artykuł powstał jako rozwinięcie jednego z najczęstszych tematów poruszanych podczas szkoleń Cognity. Nadużycia zwykle opierają się na jednym z czterech schematów: nakłonieniu użytkownika do udzielenia zgody, podszyciu się pod zaufaną aplikację, wykorzystaniu zbyt szerokich uprawnień lub utrzymaniu długotrwałego dostępu dzięki tokenom odświeżania.

Phishing consent (wyłudzanie zgody)

W tym scenariuszu atakujący nie kradnie poświadczeń, tylko skłania użytkownika do kliknięcia „Akceptuj” na ekranie zgody dla aplikacji. Taki atak bywa skuteczny, ponieważ prośby o uprawnienia mogą wyglądać „biznesowo” (np. integracja z dokumentami, podpisywanie plików, automatyzacja pracy).

• Mechanika: użytkownik loguje się poprawnie do Entra ID, a następnie udziela aplikacji dostępu do danych (np. plików w OneDrive lub witryn SharePoint) w ramach uprawnień delegowanych.
• Skutek: aplikacja uzyskuje możliwość działania „w imieniu użytkownika”, często z dostępem do szerokiego zakresu plików, zależnie od przyznanych praw.
• Dlaczego to groźne: MFA i silne hasła nie pomagają, jeśli użytkownik sam zatwierdzi dostęp. Dodatkowo, żądanie zgody może zostać wywołane z dowolnego miejsca, a wrażenie „oficjalnego okna Microsoft” obniża czujność.

Rogue apps (złośliwe lub podszywające się aplikacje)

„Rogue app” to aplikacja OAuth, której celem jest nadużycie dostępu do danych lub identyfikacji. Może być od początku złośliwa lub „prawie legalna”, ale z ukrytym zakresem działania (np. wyciąganie dokumentów, metadanych, list użytkowników, mapowanie struktury SharePoint).

• Maskowanie: aplikacje często używają nazw i ikon sugerujących narzędzia produktywności, integracje PDF, „bezpieczne udostępnianie plików” lub rzekome dodatki do Teams/SharePoint.
• Łańcuch dostępu: nawet gdy początkowo uzyskają ograniczone uprawnienia, mogą wykorzystywać pozyskane informacje (np. nazwy witryn, identyfikatory bibliotek, listy udostępnień) do dalszej eskalacji poprzez socjotechnikę lub kolejne zgody.
• Ryzyko dla SharePoint/OneDrive: dostęp do plików i bibliotek dokumentów umożliwia kradzież danych, sabotaż (np. usuwanie/zmiany) oraz przygotowanie dalszych ataków (np. na podstawie znalezionych haseł, kluczy API, umów, danych osobowych).

Nadmiarowe uprawnienia (overprivileged consent)

Wiele aplikacji prosi o uprawnienia znacznie szersze niż realnie potrzebne. Czasem wynika to z wygody deweloperów, czasem jest elementem ataku. Kluczowe jest rozróżnienie typu uprawnień: delegated (działanie w kontekście użytkownika) oraz application (działanie jako aplikacja, niezależnie od użytkownika).

• Delegated: aplikacja działa „jak użytkownik”, więc zasięg zależy od tego, do czego użytkownik ma dostęp w SharePoint/OneDrive. To popularne w integracjach, ale groźne, gdy użytkownik ma szerokie uprawnienia lub dostęp do wrażliwych witryn.
• Application: aplikacja może uzyskać dostęp „samodzielnie”, potencjalnie do wielu zasobów w organizacji. To szczególnie ryzykowne, bo umożliwia masową eksfiltrację lub przegląd danych bez aktywnej sesji użytkownika.
• Typowy problem: zgody obejmujące odczyt wszystkich plików, pełny dostęp do witryn lub możliwość modyfikacji zawartości, mimo że deklarowana funkcja aplikacji wymagałaby znacznie mniej.

Persystencja przez refresh tokeny

Po uzyskaniu zgody aplikacja może utrzymywać dostęp przez mechanizmy tokenów. W praktyce oznacza to, że jednorazowa interakcja użytkownika może przełożyć się na długotrwałe działanie aplikacji w tle.

• Na czym polega persystencja: aplikacja wykorzystuje tokeny odświeżania do uzyskiwania kolejnych tokenów dostępu bez potrzeby ponownego „kliknięcia zgody” przez użytkownika.
• Dlaczego to ważne: nawet jeśli użytkownik przestanie korzystać z aplikacji lub „zapomni” o udzielonej zgodzie, dostęp może się utrzymywać, dopóki nie zostanie cofnięty na poziomie tożsamości/aplikacji.
• Efekt operacyjny: atakujący może prowadzić cichą, rozłożoną w czasie eksfiltrację danych z SharePoint/OneDrive, zmniejszając szanse na szybkie wykrycie.

Wszystkie powyższe wektory łączy jedna cecha: w przeciwieństwie do klasycznych włamań, nadużycie OAuth często wygląda jak „normalne” użycie mechanizmów platformy. To sprawia, że kluczowe jest rozumienie, jakie uprawnienia zostały nadane, komu, na jak długo i z jakim faktycznym wpływem na dane w SharePoint i OneDrive.

3. Audyt i kontrola consentów: przegląd aplikacji, uprawnień (delegated vs application), admin consent i governance

Kontrola aplikacji OAuth w Microsoft 365 zaczyna się od odpowiedzi na trzy pytania: kto udzielił zgody, czemu (jakim uprawnieniom) oraz jak aplikacja może działać (w imieniu użytkownika czy samodzielnie). Dla SharePoint i OneDrive kluczowe jest ograniczenie scenariuszy, w których aplikacja uzyskuje szeroki dostęp do plików i witryn, a następnie zapewnienie ciągłego przeglądu już udzielonych zgód.

3.1. Inwentaryzacja aplikacji: co masz w tenantcie

Podstawą audytu jest regularny przegląd rejestracji aplikacji i obiektów enterprise applications w Entra ID:

• App registrations – aplikacje zarejestrowane w tenantcie (Twoje lub zarejestrowane na potrzeby integracji).
• Enterprise applications – instancje aplikacji (również wielodzierżawnych) faktycznie używane w tenantcie, wraz z przypisaniami, zgodami i ustawieniami SSO/OAuth.

W praktyce warto prowadzić prostą klasyfikację: aplikacje biznesowo zatwierdzone, aplikacje do weryfikacji, aplikacje niepożądane. Już na tym etapie zwracaj uwagę na aplikacje, które:

• posiadają uprawnienia do Microsoft Graph lub SharePoint związane z odczytem/zapisem plików i witryn,
• są wielodzierżawne (multi-tenant) i zostały dodane przez użytkowników,
• mają nietypowego wydawcę lub brak informacji o wydawcy (np. brak weryfikacji),
• nie mają jasnego właściciela biznesowego po stronie organizacji.

3.2. Uprawnienia delegated vs application: różnice i konsekwencje

OAuth w M365 występuje najczęściej w dwóch modelach uprawnień. Z punktu widzenia SharePoint/OneDrive różnica wpływa na skalę dostępu i ryzyko automatyzacji działań.

W audycie koncentruj się na wykrywaniu:

• nadmiarowych zakresów (np. szerokie uprawnienia do plików i witryn, gdy integracja wymaga tylko odczytu wybranego zasobu),
• nieproporcjonalnego modelu (application permissions tam, gdzie wystarczyłby delegated),
• nietypowych kombinacji uprawnień (np. jednoczesny szeroki dostęp do plików i możliwość działania „offline”).

3.3. Consent: user consent vs admin consent

Zgody (consents) decydują, czy aplikacja dostanie tokeny z określonymi zakresami. W uproszczeniu:

• User consent – użytkownik sam akceptuje zakresy (w granicach polityk organizacji). Ryzyko rośnie, gdy użytkownicy mogą zatwierdzać szerokie uprawnienia do danych.
• Admin consent – administrator zatwierdza zakresy dla całej organizacji lub wybranych użytkowników/grup. To mechanizm kontrolowany, ale błędna decyzja ma większy „blast radius”.

Dobre praktyki kontroli consentów obejmują:

• ustalenie, kto może udzielać zgód i jakie kategorie uprawnień mogą być zatwierdzane przez użytkowników,
• wymuszenie procesu zatwierdzania (workflow) dla aplikacji wymagających dostępu do SharePoint/OneDrive,
• okresowy przegląd aplikacji z admin consent: czy nadal są potrzebne i czy zakres nie powinien zostać zawężony.

3.4. Przegląd uprawnień aplikacji do SharePoint/OneDrive: na co patrzeć

W praktyce audyt uprawnień sprowadza się do analizy poziomu i charakteru dostępu:

• Odczyt vs zapis – zapis i modyfikacja treści znacząco zwiększają wpływ incydentu.
• Zakres organizacyjny – uprawnienia obejmujące wiele witryn/bibliotek vs precyzyjne, zasobowe.
• Dostęp do plików – uprawnienia typu „read/write all files” są szczególnie wrażliwe w kontekście OneDrive.
• Możliwość działania bez aktywnej sesji użytkownika – zwiększa ryzyko utrzymania dostępu i automatyzacji.

Jeśli Twoja organizacja korzysta z aplikacji integrujących się z SharePoint/OneDrive, przypisz do każdej z nich: właściciela biznesowego, właściciela technicznego, uzasadnienie dostępu oraz deklarowany minimalny zestaw uprawnień.

3.5. Governance: zasady, cykl życia i przeglądy okresowe

Same ustawienia techniczne nie wystarczą bez prostych reguł zarządzania:

• Rejestr aplikacji: lista zatwierdzonych aplikacji (co najmniej: nazwa, AppId, właściciel, cel, data akceptacji, zakresy).
• Cykl życia: wymaganie przeglądu co określony czas (np. kwartalnie/półrocznie) oraz wycofywanie aplikacji nieużywanych lub nieposiadających właściciela.
• Rozdział ról: ktoś zatwierdza sens biznesowy, a ktoś weryfikuje minimalność uprawnień i ryzyko.
• Standardy integracji: preferowanie rozwiązań o wąskim zakresie, jasno określonych endpointach i możliwie ograniczonym dostępie do danych.

3.6. Szybki przegląd przez Microsoft Graph (przykład pomocniczy)

Poniższy przykład pokazuje kierunek, w jaki sposób zespoły często automatyzują raporty o zgodach i uprawnieniach. Traktuj go jako uzupełnienie, nie jako pełną procedurę.

GET https://graph.microsoft.com/v1.0/servicePrincipals?$select=id,appId,displayName
GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants?$select=clientId,consentType,principalId,resourceId,scope
GET https://graph.microsoft.com/v1.0/appRoleAssignments?$select=principalId,resourceId,appRoleId

W raportach najczęściej mapuje się: servicePrincipal (aplikacja w tenantcie) → grants/assignments (jakie zgody i role) → resource (np. Microsoft Graph/SharePoint) i wyłapuje aplikacje o szerokich zakresach związanych z plikami i witrynami.

4. Źródła danych i logi do wykrywania

Wykrywanie nadużyć uprawnień do SharePoint/OneDrive przez aplikacje OAuth wymaga połączenia trzech perspektyw: tożsamości (kto i jaka aplikacja dostała token), administracji (kto nadał consent i jakie uprawnienia) oraz aktywności danych (co aplikacja lub użytkownik faktycznie zrobił w SharePoint/OneDrive). W Microsoft 365 kluczowe są: Entra ID Sign-in logs, Entra ID Audit logs, Unified Audit Log oraz natywne zdarzenia SharePoint/OneDrive (raportowane przez UAL).

W czasie szkoleń Cognity ten temat bardzo często budzi ożywione dyskusje między uczestnikami, bo dopiero zestawienie tych trzech perspektyw daje pełny obraz ryzyka i pozwala odróżnić „normalne” użycie aplikacji od nadużycia.

Entra ID: Sign-in logs (logi logowań)

Sign-in logs opisują pozyskiwanie i użycie tokenów z perspektywy Entra ID. Są szczególnie przydatne do korelacji: aplikacja → użytkownik → warunki logowania → skutek (np. dostęp do Microsoft Graph/SharePoint API).

• User sign-ins – logowania interaktywne i nieinteraktywne użytkowników, w tym scenariusze OAuth, gdzie użytkownik „pośredniczy” w dostępie (delegated).
• Service principal sign-ins – logowania/wywołania wykonywane przez samą aplikację (application permissions), często bez udziału użytkownika; istotne przy aplikacjach działających w tle.

Na poziomie pól/atrybutów operacyjnie przydają się m.in.: identyfikator aplikacji (AppId), nazwa aplikacji, tenant, użytkownik, client app, adres IP, informacje o urządzeniu, status, a także kontekst zasobu (do jakiego zasobu uzyskano token). To pozwala szybko odfiltrować np. nietypowe lokalizacje, nagły wzrost logowań aplikacji albo użycie podejrzanych klientów.

Entra ID: Audit logs (logi audytu zmian)

Audit logs odpowiadają na pytanie: kto zmienił konfigurację i jakie uprawnienia zostały nadane. W kontekście OAuth do SharePoint/OneDrive są podstawą do wykrywania działań przygotowujących nadużycie, takich jak dodanie aplikacji, nadanie consentu czy zmiany w obiektach aplikacji.

• Rejestracje aplikacji i Service Principal – utworzenie/aktualizacja obiektów aplikacji oraz ich instancji w tenancie.
• Consent i uprawnienia – zdarzenia wskazujące na nadanie zgody (user/admin consent) i rozszerzenia zakresów.
• Zmiany w politykach i ustawieniach powiązanych z dostępem aplikacji (np. elementy governance), jeśli są audytowane w Entra.

Audit logs są kluczowe, bo wiele incydentów zaczyna się od „cichej” zmiany (np. dopisania uprawnienia application lub nadania admin consent), a dopiero potem pojawia się aktywność w SharePoint/OneDrive.

Unified Audit Log (Microsoft Purview Audit)

Unified Audit Log (UAL) zapewnia jednolity strumień audytu dla wielu usług M365 i jest najpraktyczniejszym miejscem do śledzenia aktywności na danych w SharePoint/OneDrive oraz działań użytkowników, które nie zawsze widać w Entra ID. UAL jest szczególnie użyteczny do:

• wykrywania operacji na plikach (odczyt/pobranie, modyfikacja, usunięcie, udostępnienie),
• analizy masowych akcji (np. lawinowe pobieranie lub enumeracja),
• korelacji aktywności z kontekstem aplikacji (tam gdzie zdarzenia zawierają informacje o kliencie/źródle wywołania).

UAL jest też wygodny operacyjnie, bo pozwala jednym mechanizmem przeszukiwać zdarzenia dla SharePoint i OneDrive (OneDrive generuje zdarzenia w ramach SharePoint) oraz łączyć je z aktywnością z innych usług (np. Exchange), gdy incydent ma szerszy zasięg.

Zdarzenia SharePoint/OneDrive (warstwa aktywności danych)

W praktyce „zdarzenia SharePoint/OneDrive” do detekcji nadużyć OAuth to operacje na zawartości i uprawnieniach rejestrowane w audycie M365 (widoczne w UAL). Najczęściej interesują:

• Dostęp do plików i katalogów (przeglądanie, pobieranie, synchronizacja),
• Zmiany w udostępnieniach (tworzenie linków, zmiany w ACL/permissions),
• Operacje administracyjne w obrębie witryn (np. działania wpływające na zasięg dostępu aplikacji/użytkownika).

Ta warstwa odpowiada na pytanie: co faktycznie zostało zrobione na danych. Jest kluczowa, bo sama obecność consentu lub logowania aplikacji nie przesądza o nadużyciu — dopiero wzorzec aktywności w SharePoint/OneDrive pozwala potwierdzić eksfiltrację, sabotaż lub nieautoryzowane udostępnienia.

Porównanie: które logi do czego?

Minimalny przykład: szybkie wyszukiwanie w UAL

Poniżej przykład poglądowy (uzupełniający) zapytania PowerShell do przeszukania UAL pod kątem aktywności plikowej w SharePoint/OneDrive w danym oknie czasowym:

Search-UnifiedAuditLog \
  -StartDate "2026-03-01" \
  -EndDate   "2026-03-02" \
  -RecordType SharePointFileOperation \
  -ResultSize 5000

W praktyce takie wyszukiwanie stanowi punkt startowy do korelacji z identyfikatorem aplikacji (z Entra) i zawężenia do podejrzanych użytkowników, lokalizacji lub witryn.

5. Detekcje i alerty: reguły, anomalie, wskaźniki kompromitacji oraz integracja z Microsoft Defender/Sentinel

Wykrywanie nadużyć uprawnień do SharePoint/OneDrive przez aplikacje OAuth wymaga połączenia dwóch perspektyw: tożsamości (kto i jaka aplikacja dostała dostęp) oraz danych (co aplikacja robi w SharePoint/OneDrive). Dobre detekcje nie opierają się wyłącznie na pojedynczym zdarzeniu „consent”, ale korelują nadanie uprawnień z późniejszym zachowaniem (np. masowe pobrania, dostęp spoza typowych lokalizacji, nietypowe klienty i identyfikatory aplikacji).

5.1. Typy detekcji: reguły vs anomalie

5.2. Wskaźniki kompromitacji (IoC) i sygnały ostrzegawcze dla OAuth/SharePoint/OneDrive

• Nowo zarejestrowana lub nowo „użyta” aplikacja uzyskuje dostęp do SharePoint/OneDrive, zwłaszcza jeśli wcześniej nie występowała w środowisku.
• Uprawnienia wysokiego ryzyka do plików i witryn (np. szerokie odczyty/zapisy) nadane aplikacji, której profil nie pasuje do biznesu.
• Nietypowy tryb dostępu: aplikacja działa „w tle”, a zdarzenia dostępu do danych nie korelują z aktywnością użytkownika (brak interakcji, a rośnie liczba operacji na plikach).
• Skok wolumenu operacji: masowe pobieranie/odczyt, szybkie przeglądanie wielu lokalizacji, enumeracja struktur (wiele witryn/bibliotek w krótkim czasie).
• Dostęp do szerokiego zestawu użytkowników: ta sama aplikacja uzyskuje uprawnienia dla wielu kont lub zaczyna działać na zasobach wielu właścicieli.
• Oznaki persystencji: aplikacja stale wykonuje operacje mimo braku świeżych zdarzeń interaktywnych użytkownika (sugeruje długotrwałe użycie tokenów).
• Zmiany w konfiguracji aplikacji (np. modyfikacje uprawnień, dodanie poświadczeń) skorelowane czasowo z podejrzanym ruchem w SharePoint/OneDrive.

5.3. Przykładowe reguły detekcyjne (co warto alertować)

• Consent wysokich uprawnień do SharePoint/OneDrive (szczególnie, gdy udziela go użytkownik nietypowy dla takiej operacji).
• Nowy admin consent lub rozszerzenie uprawnień istniejącej aplikacji (np. nagle dochodzi zakres umożliwiający szeroki dostęp do plików).
• Nowy Service Principal pojawiający się w tenant i niemal natychmiast generujący aktywność na zasobach danych.
• Masowy dostęp do plików (download/sync) w krótkim oknie czasowym, zwłaszcza jeśli inicjowany przez aplikację, a nie typowego klienta użytkownika.
• Nietypowe kombinacje: aplikacja z wysokimi uprawnieniami + ruch z nietypowych lokalizacji/ASNs + brak wcześniejszej historii użycia.
• Wzorzec „spray”: wiele prób uzyskania consentu (lub wiele consentów) w krótkim czasie, potencjalnie po kampanii phishingowej.

5.4. Minimalny zestaw metryk do progów i anomalii

Progi powinny opierać się na baseline organizacji. Jako punkt startowy warto monitorować:

• Liczbę unikalnych aplikacji uzyskujących dostęp do SharePoint/OneDrive dziennie/tygodniowo.
• Liczbę nowych consentów i ich „ciężar” (wzrost sumarycznego poziomu uprawnień).
• Wolumen operacji na plikach per aplikacja (odczyt/pobranie/modyfikacja) i tempo (operacje/min).
• Rozpiętość zasobów: liczba witryn/bibliotek/użytkowników dotkniętych przez jedną aplikację.
• Różnorodność źródeł: geolokalizacje, sieci, user-agenty/klienci powiązani z dostępem.

5.5. Integracja z Microsoft Defender i Microsoft Sentinel (rola i zastosowania)

Microsoft Defender jest praktyczny do gotowych sygnałów i alertów dotyczących tożsamości, aplikacji oraz zachowań w usługach M365 (w tym na danych). Z kolei Microsoft Sentinel daje elastyczność: budowę własnych reguł korelacyjnych, łączenie wielu źródeł i automatyzację reakcji (playbooki).

• Defender: szybkie „out-of-the-box” wykrycia, priorytetyzacja incydentów, korelacja alertów bezpieczeństwa z tożsamością i aktywnością w M365.
• Sentinel: zaawansowane analityki (KQL), korelacja między Entra ID a logami SharePoint/OneDrive, tworzenie własnych scenariuszy i raportowania pod wymagania organizacji.

5.6. Przykład szkicu reguły korelacyjnej (Sentinel/KQL) – consent → aktywność na plikach

Poniższy przykład pokazuje ideę korelacji: wykryj nowo udzielony consent i sprawdź, czy wkrótce potem pojawia się istotna aktywność na plikach. To nie jest gotowa reguła dla każdego tenant — ma ilustrować podejście.

// Szkic: korelacja zdarzeń consent z aktywnością plikową w oknie czasu
// Wymaga dopasowania do używanych tabel/connectorów w Twoim środowisku.
let ConsentWindow = 1h;
let ActivityWindow = 6h;
let highRiskScopes = dynamic(["Sites.Read.All","Sites.ReadWrite.All","Files.Read.All","Files.ReadWrite.All"]);

let consents = AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("Consent", "Add OAuth2PermissionGrant", "Add service principal")
| extend AppId = tostring(TargetResources[0].id)
| extend Scopes = tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)
| where Scopes has_any (highRiskScopes)
| project ConsentTime=TimeGenerated, AppId, Scopes, InitiatedBy=tostring(InitiatedBy.user.userPrincipalName);

let fileOps = OfficeActivity
| where TimeGenerated > ago(7d)
| where OfficeWorkload in ("SharePoint","OneDrive")
| where Operation has_any ("FileDownloaded","FileAccessed","FileSyncDownloadedFull")
| extend AppId = tostring(ClientAppId)
| summarize Ops=count(), Sites=dcount(SiteUrl), Users=dcount(UserId) by AppId, bin(TimeGenerated, 30m);

consents
| join kind=inner (fileOps) on AppId
| where TimeGenerated between (ConsentTime .. ConsentTime + ActivityWindow)
| project ConsentTime, TimeGenerated, AppId, InitiatedBy, Scopes, Ops, Sites, Users

5.7. Operacjonalizacja alertów: priorytet, kontekst i „co dołączyć”

Alert ma być użyteczny dla zespołu SOC bez natychmiastowego „ręcznego dochodzenia”. W praktyce warto dołączać do alertu kontekst:

• Identyfikatory aplikacji (AppId/Service Principal) i podstawowe atrybuty (czy aplikacja jest nowa w środowisku, czy miała wcześniej aktywność).
• Zakresy uprawnień i informację, czy był to admin consent vs consent użytkownika.
• Podsumowanie aktywności na danych: wolumen operacji, liczba dotkniętych witryn/plików/użytkowników.
• Okno czasu i sekwencję zdarzeń (co było pierwsze: consent, zmiana uprawnień, masowe pobrania).
• Ocena ryzyka (np. wysoka, gdy: nowe AppId + wysokie uprawnienia + masowy download w krótkim czasie).

6. Zasady least privilege i twarde ustawienia

Nawet najlepsze detekcje nie zastąpią ograniczenia „powierzchni ataku” na etapie nadawania uprawnień aplikacjom. W kontekście SharePoint/OneDrive kluczowe jest wdrożenie least privilege (minimalnych koniecznych uprawnień) oraz zestawu twardych ustawień, które ograniczają możliwość uzyskania i utrzymania dostępu przez aplikacje OAuth.

6.1. Least privilege dla aplikacji: zakresy, role i ekspozycja danych

W praktyce „least privilege” dla OAuth oznacza dobór uprawnień tak, aby aplikacja miała dostęp tylko do niezbędnych danych i tylko w potrzebnym modelu działania. Najczęstsze źródła ryzyka to zbyt szerokie uprawnienia Microsoft Graph/SharePoint oraz uprawnienia przyznane „na zapas”.

• Preferuj uprawnienia o węższym zakresie (np. dostęp tylko do wybranych zasobów, a nie do całego tenant’a lub całej biblioteki).
• Unikaj uprawnień umożliwiających masowy odczyt zawartości OneDrive/SharePoint, jeśli aplikacja nie musi przetwarzać plików użytkowników.
• Rozdziel funkcje: jeśli to możliwe, oddziel aplikacje do automatyzacji/raportowania od aplikacji, które faktycznie modyfikują pliki.
• Okresowo rewaliduj potrzebę uprawnień — szczególnie tych, które obejmują dane plikowe.

6.2. Ograniczenia aplikacji: kto może udzielać consentu i jakim aplikacjom

Najsilniejszą kontrolą jest ograniczenie możliwości udzielania zgód aplikacjom przez użytkowników końcowych oraz wymuszenie procesu zatwierdzania przez administrację.

• Wyłącz lub ogranicz user consent do aplikacji o niskim ryzyku oraz do zweryfikowanych wydawców.
• Wymuś admin consent dla uprawnień wrażliwych (szczególnie tych związanych z plikami i witrynami).
• Stosuj listy dozwolonych aplikacji (allowlist) dla integracji, które mają uzasadniony dostęp do SharePoint/OneDrive.
• Ogranicz możliwość rejestracji aplikacji (app registrations) do dedykowanej grupy/roli, aby utrudnić tworzenie „pozornie legalnych” aplikacji w tenant.

6.3. Publisher verification i zaufanie do tożsamości wydawcy

Weryfikacja wydawcy (publisher verification) pomaga odróżnić aplikacje pochodzące od zidentyfikowanego podmiotu od aplikacji anonimowych lub podszywających się. Nie gwarantuje bezpieczeństwa kodu, ale znacząco podnosi poprzeczkę dla atakującego i ułatwia egzekwowanie polityk.

• Wymuszaj preferencję dla aplikacji z „verified publisher” przy dopuszczaniu consentu.
• Traktuj aplikacje bez zweryfikowanego wydawcy jako podwyższone ryzyko — szczególnie gdy żądają dostępu do plików, witryn lub danych użytkowników.
• Sprawdzaj spójność nazwy aplikacji, domeny wydawcy i scenariusza biznesowego przed dopuszczeniem do środowiska.

6.4. Conditional Access dla aplikacji: kiedy ma sens, a kiedy nie

Conditional Access (CA) jest filarem kontroli dostępu w M365, ale w kontekście OAuth trzeba rozumieć jego zastosowanie: CA jest najskuteczniejsze dla przepływów interaktywnych użytkownika (delegated), natomiast w scenariuszach bez użytkownika (application permissions) możliwości CA bywają ograniczone lub pośrednie.

• Wymuszaj silne uwierzytelnianie dla użytkowników, którzy mogą udzielać zgód aplikacjom (np. administratorzy, zespoły IT).
• Ogranicz dostęp według kontekstu (lokalizacja, urządzenie zgodne, ryzyko logowania) dla scenariuszy, gdzie zgoda jest udzielana interaktywnie.
• Oddziel konta uprzywilejowane (admin) od codziennej pracy; to redukuje skutki „przypadkowego” udzielenia zgody z konta o wysokich uprawnieniach.

6.5. Policy governance: procesy i mechanizmy, które wymuszają standard

„Twarde ustawienia” bez governance prowadzą do wyjątków i obejść. Governance dla aplikacji OAuth powinno łączyć polityki techniczne z prostym procesem dopuszczania integracji.

• Model dopuszczania aplikacji: jasno zdefiniuj, kto i na jakich zasadach zatwierdza aplikacje żądające dostępu do SharePoint/OneDrive.
• Klasyfikacja uprawnień: oznacz uprawnienia plikowe i witrynowe jako „high impact” i wymagające dodatkowej kontroli.
• Standardy minimalne: wymagaj zweryfikowanego wydawcy (tam, gdzie to możliwe), ograniczonych scope’ów, uzasadnienia biznesowego i właściciela aplikacji po stronie organizacji.
• Cykl życia aplikacji: właściciel, przeglądy okresowe, termin ważności dopuszczenia, oraz zasady wycofania, gdy aplikacja nie jest używana.

6.6. Minimalny zestaw „twardych” ustawień (checklista)

• Ograniczony user consent (preferencyjnie: wyłączony dla szerokich uprawnień i dozwolony tylko dla niskiego ryzyka).
• Admin consent wymagany dla uprawnień do plików/witryn oraz uprawnień o szerokim zakresie.
• Preferencja dla verified publisher i blokowanie/ograniczanie aplikacji bez weryfikacji w scenariuszach wysokiego ryzyka.
• Ograniczenie rejestracji aplikacji do kontrolowanej grupy.
• Wzmocniony dostęp dla ról uprzywilejowanych (np. dodatkowe wymagania dostępu przy operacjach zatwierdzania zgód).
• Właściciel i odpowiedzialność za każdą dopuszczoną aplikację oraz okresowa rewalidacja potrzeby.

7. Reakcja na incydent: triage, wycofanie consentu, revokacja tokenów, blokada aplikacji i post-incident hardening

Nadużycie uprawnień do SharePoint/OneDrive przez aplikacje OAuth ma zwykle charakter „cichego” dostępu: dane mogą być pobierane bez klasycznego logowania interaktywnego, a skutki utrzymują się tak długo, jak długo ważne są przyznane zgody i tokeny. Skuteczna reakcja wymaga równoległego działania w dwóch obszarach: ograniczenia bieżącego dostępu (powstrzymanie eksfiltracji) oraz ustalenia zasięgu i źródła (które tożsamości, aplikacje i zasoby zostały dotknięte).

Triage: szybka ocena ryzyka i priorytety

Pierwszym krokiem jest rozróżnienie, czy mamy do czynienia z aplikacją, która działa w kontekście użytkownika (delegated), czy z aplikacją posiadającą uprawnienia działające niezależnie od użytkownika (application). To podstawowa różnica operacyjna: w modelu delegated ryzyko bywa związane z konkretną tożsamością i jej zakresem, natomiast w modelu application konsekwencje mogą być szersze, bo aplikacja może mieć dostęp do wielu zasobów bez udziału użytkownika.

• Oceń krytyczność uprawnień: czy aplikacja ma dostęp do plików w całym tenantcie, wszystkich witryn SharePoint, czy tylko do zasobów użytkownika, który udzielił zgody.
• Sprawdź „świeżość” zdarzeń: czy widzisz aktywność wskazującą na trwające pobieranie danych (np. masowe odczyty/eksport) lub tylko historyczne użycie.
• Określ punkt startu: czy zgoda została udzielona przez użytkownika, czy przez administratora; czy występują oznaki phishingu consentowego; czy aplikacja jest powiązana z podejrzanym wydawcą.
• Ustal zasoby o najwyższej wartości: witryny z danymi wrażliwymi, konta uprzywilejowane, konta z szerokim dostępem do SharePoint/OneDrive.

Powstrzymanie: wycofanie consentu i ograniczenie dostępu

Najbardziej bezpośrednim sposobem odcięcia aplikacji od danych jest wycofanie udzielonych zgód (consentów) oraz zablokowanie dalszego ich udzielania w danym kontekście. W praktyce zwykle łączy się działania na poziomie aplikacji i na poziomie konta użytkownika, który udzielił zgody.

• Wycofaj consent: usuń przyznane uprawnienia dla podejrzanej aplikacji (zarówno user consent, jak i admin consent, jeśli występuje). To kluczowe, bo same zmiany hasła użytkownika nie zawsze zatrzymują działanie aplikacji w oparciu o wcześniej przyznane uprawnienia.
• Zablokuj aplikację: jeśli ryzyko jest wysokie lub aktywność trwa, zablokuj możliwość logowania/uzyskiwania tokenów przez aplikację w środowisku (na poziomie konfiguracji aplikacji/enterprise app). To działanie ma charakter „twardego odcięcia”.
• Ogranicz konto użytkownika (jeśli dotyczy): w przypadku podejrzenia przejęcia konta, zastosuj czasowe środki ograniczające (np. wymuszenie ponownego uwierzytelnienia, blokadę konta w trybie awaryjnym), aby przerwać łańcuch działań napastnika.

Revokacja tokenów: przerwanie persystencji

Wycofanie consentu usuwa prawną „autoryzację” aplikacji, ale w praktyce należy też zadbać o unieważnienie istniejących tokenów, zwłaszcza gdy podejrzewasz użycie refresh tokenów do utrzymania dostępu. Różnica jest istotna: consent dotyczy uprawnień, a revokacja tokenów dotyczy aktywnych poświadczeń używanych do uzyskiwania dostępu.

• Unieważnij sesje i tokeny użytkownika: gdy incydent dotyczy delegated permissions i istnieje ryzyko, że refresh tokeny umożliwiają dalsze odświeżanie dostępu.
• Unieważnij poświadczenia aplikacji: gdy aplikacja korzysta z własnych sekretów/certyfikatów lub mechanizmów pozwalających na długotrwały dostęp w modelu application.
• Wymuś ponowne uwierzytelnienie dla tożsamości o podwyższonym ryzyku, aby odciąć stare konteksty uwierzytelnienia.

Ustalenie zasięgu: co zostało dotknięte i czy doszło do eksfiltracji

Równolegle do działań blokujących należy określić, jakie dane mogły zostać odczytane, pobrane lub udostępnione. W przypadku SharePoint/OneDrive kluczowe jest odróżnienie: czy dostęp był tylko do metadanych, czy do zawartości plików, oraz czy wystąpiły operacje wskazujące na masowe pobieranie lub enumerację.

• Zweryfikuj zakres zasobów: witryny, biblioteki, foldery i pliki, do których aplikacja miała realny dostęp w ramach przyznanych uprawnień.
• Oceń zachowanie: nietypowe wzorce pobierania, duża liczba odczytów w krótkim czasie, działania poza godzinami pracy lub z nietypowych lokalizacji.
• Sprawdź zmiany w udostępnieniach: czy aplikacja lub konto użytkownika tworzyły linki udostępniania lub zmieniały uprawnienia do zasobów.
• Zweryfikuj konta uprzywilejowane: czy consent nie został udzielony przez konto z szerokim dostępem do zasobów SharePoint/OneDrive.

Komunikacja i decyzje operacyjne

Incydenty OAuth często wymagają szybkich decyzji: czy blokować aplikację globalnie (ryzyko przerwania legalnych procesów), czy punktowo (ryzyko pozostawienia furtki). Warto ustalić jasne kryteria: krytyczność danych, skala uprawnień oraz dowody aktywnej eksfiltracji.

• Skonsultuj wpływ biznesowy przed globalną blokadą, jeśli aplikacja jest potencjalnie używana przez zespoły.
• Prowadź spójny przekaz do użytkowników: prośby o ponowne logowanie, wyjaśnienie dlaczego aplikacja została zablokowana, oraz jak rozpoznawać podejrzane ekrany zgody.
• Zabezpiecz materiał dowodowy: zachowaj identyfikatory aplikacji, zakresy uprawnień i oś czasu działań na potrzeby analizy i ewentualnych obowiązków raportowych.

Post-incident hardening: zmniejszenie ryzyka powtórki

Po opanowaniu incydentu celem jest ograniczenie prawdopodobieństwa ponownego nadużycia poprzez uszczelnienie procesu zgód i zmniejszenie „powierzchni ataku” aplikacji. Na tym etapie kluczowe jest odróżnienie działań organizacyjnych (governance i procesy) od działań technicznych (polityki i ograniczenia), tak aby zmiana była trwała.

• Zaostrzenie zasad consentu: ogranicz możliwość samodzielnego udzielania zgód do zaufanych aplikacji i zweryfikowanych wydawców oraz wprowadź workflow weryfikacji dla wyjątków.
• Przegląd uprawnień aplikacji: usuń nadmiarowe zakresy i wprowadź okresową weryfikację aplikacji mających dostęp do SharePoint/OneDrive.
• Wzmocnienie kontroli dostępu: dopasuj wymagania uwierzytelnienia i warunki dostępu tak, aby ograniczyć ryzyko nadużyć w przypadku przejęcia konta użytkownika.
• Usprawnienie detekcji: dopracuj reguły i progi alarmowania pod kątem masowych odczytów, nietypowych consentów oraz użycia aplikacji o wysokich uprawnieniach.
• Edukacja użytkowników: skoncentruj się na rozpoznawaniu podejrzanych ekranów zgody i na tym, kiedy eskalować prośbę o consent do IT/bezpieczeństwa.

Najważniejszy rezultat po incydencie to nie tylko usunięcie jednej złośliwej aplikacji, ale przywrócenie kontroli nad cyklem życia zgód OAuth: kto może udzielać zgód, jak szybko organizacja wykrywa nietypowe uprawnienia oraz jak skutecznie potrafi przerwać persystencję opartą o tokeny.

Checklista monitoringu i rekomendowane ustawienia bazowe dla organizacji

Poniższa checklista pomaga wdrożyć spójne minimum bezpieczeństwa dla SharePoint/OneDrive w kontekście aplikacji OAuth: co warto monitorować, jakie sygnały uznać za podejrzane oraz jakie bazowe ustawienia ograniczają ryzyko nadużyć uprawnień. Skupia się na praktycznych punktach kontrolnych, bez wchodzenia w szczegóły implementacyjne.

1) Bazowe ustawienia i „barierki” dla consentów OAuth

• Ogranicz możliwość udzielania consentu przez użytkowników do aplikacji o szerokich zakresach; preferuj model, w którym ryzykowne uprawnienia wymagają zatwierdzenia administracyjnego.
• Włącz i egzekwuj proces weryfikacji aplikacji: preferuj aplikacje z wiarygodnym wydawcą (publisher) oraz jasno zdefiniowanym właścicielem biznesowym i technicznym po stronie organizacji.
• Standaryzuj dopuszczalne zakresy (scopes) dla SharePoint/OneDrive i traktuj uprawnienia „pełnego dostępu” jako wyjątek wymagający uzasadnienia i ograniczeń czasowych.
• Wymuś zasadę „minimum uprawnień” przy rejestracjach i konfiguracji aplikacji: minimalny zestaw uprawnień, minimalny zasięg danych, minimalna liczba kont uprzywilejowanych.
• Ogranicz tworzenie i rejestrowanie aplikacji do kontrolowanych ról/zespołów, jeśli nie jest to konieczne dla wszystkich użytkowników.
• Zdefiniuj cykl życia aplikacji: data przeglądu, właściciel, cel, kryteria wycofania, a także wymaganie odświeżania akceptacji po zmianie zakresów.

2) Minimum monitoringu: co obserwować na bieżąco

• Nowe zgody (consent) na aplikacje oraz wszelkie zmiany zakresów uprawnień, szczególnie dla SharePoint/OneDrive.
• Admin consent nadany aplikacji: kto zatwierdził, kiedy, dla jakich uprawnień i czy dotyczy całej organizacji.
• Dodanie/zmiana poświadczeń aplikacji (np. nowe sekrety/certyfikaty) oraz zmiany w właścicielach aplikacji.
• Logowania i tokeny dla aplikacji: nietypowe wzorce użycia, nowe lokalizacje, nagłe skoki wolumenu dostępu do zasobów.
• Aktywność plikowa w SharePoint/OneDrive skorelowana z aplikacją: masowe odczyty/pobrania, enumeracja, nietypowe operacje na dużej liczbie obiektów.
• Nietypowe operacje na witrynach: dostęp do wielu witryn w krótkim czasie, próby dostępu do zasobów wrażliwych lub rzadko używanych.

3) Sygnały ostrzegawcze (IOA/IOC) specyficzne dla nadużyć OAuth

• Consent udzielony tuż po podejrzanym zdarzeniu tożsamości (np. nietypowe logowanie użytkownika), zwłaszcza jeśli aplikacja żąda szerokich uprawnień do plików.
• Aplikacja o niskiej reputacji: brak weryfikacji wydawcy, niejasny opis, nietypowa nazwa lub brak spójności między nazwą a żądanymi uprawnieniami.
• Skok uprawnień: aplikacja wcześniej miała wąskie scope’y, a następnie pojawia się rozszerzenie do pełnego dostępu lub dostępu do wszystkich witryn/plików w organizacji.
• Wzorce „cichej” eksfiltracji: stały, długotrwały dostęp do plików bez interakcji użytkownika, w godzinach nietypowych lub z nietypowych źródeł.
• Rozbieżność między rolą użytkownika a zakresem danych: użytkownik bez uzasadnienia biznesowego inicjuje dostęp aplikacji do dużej części zasobów.
• Oznaki persystencji: aplikacja utrzymuje długotrwały dostęp mimo zmiany hasła użytkownika lub innych działań naprawczych, co może wskazywać na utrzymywanie dostępu przez tokeny.

4) Bazowe zasady dla kont uprzywilejowanych i administracji

• Oddziel konta administracyjne od codziennych i ogranicz użycie kont uprzywilejowanych do zadań administracyjnych.
• Wzmocnij kontrolę akcji administracyjnych: monitoruj nadawanie admin consent, zmiany konfiguracji aplikacji i modyfikacje zasad dostępu.
• Wprowadź okresowe przeglądy aplikacji z szerokimi uprawnieniami oraz aplikacji z dostępem do SharePoint/OneDrive w skali organizacji.
• Minimalizuj liczbę osób mogących zatwierdzać zgody dla całej organizacji i audytuj te działania jako zdarzenia wysokiego ryzyka.

5) Higiena aplikacji i danych: przeglądy, właściciele, wycofania

• Utrzymuj rejestr aplikacji z mapowaniem: właściciel, cel, zakres danych, uprawnienia, metoda uwierzytelniania oraz krytyczność.
• Przeglądaj aplikacje nieużywane i wycofuj zgody lub wyłączaj aplikacje, które nie mają uzasadnienia lub nie wykazują aktywności.
• Weryfikuj aplikacje integrujące się z SharePoint/OneDrive pod kątem zgodności z politykami organizacji (w tym lokalizacja przetwarzania, wymagania prawne i klasyfikacja danych).
• Ustal progi tolerancji dla masowych operacji na plikach i traktuj przekroczenia jako sygnał do weryfikacji.

6) Minimalny zestaw alertów operacyjnych

• Nowy consent do uprawnień o wysokim ryzyku dla SharePoint/OneDrive.
• Admin consent nadany aplikacji, która nie jest na liście dopuszczonych lub nie ma przypisanego właściciela.
• Zmiana poświadczeń aplikacji (dodanie sekretu/certyfikatu) lub zmiana właścicieli.
• Anomalie w dostępie do plików: gwałtowny wzrost odczytów/pobrań/usunięć, nietypowa liczba witryn lub użytkowników dotkniętych przez jedną aplikację.
• Nowa aplikacja uzyskująca dostęp do zasobów SharePoint/OneDrive w skali organizacji.
• Powtarzające się aktywności wskazujące na automatyzację dostępu do danych bez uzasadnienia biznesowego.

7) Rekomendowane minimum procesowe (kto i jak reaguje)

• Właścicielstwo i odpowiedzialność: wyznacz zespół odpowiedzialny za ocenę aplikacji oraz ścieżkę akceptacji/odrzucenia.
• Szybka ścieżka wstrzymania: zdefiniuj, kiedy można tymczasowo zablokować aplikację lub cofnąć zgody w trybie pilnym.
• Regularne przeglądy: cyklicznie weryfikuj aplikacje z szerokimi uprawnieniami oraz wszystkie integracje z SharePoint/OneDrive.
• Komunikacja do użytkowników: ujednolić zasady zgłaszania podejrzanych ekranów zgód i edukować, że „zgoda na aplikację” może oznaczać realny dostęp do plików.

8) Minimalny poziom gotowości audytowej

• Upewnij się, że zdarzenia są zbierane i retencjonowane w horyzoncie czasowym wystarczającym do dochodzeń (zgody, zmiany aplikacji, aktywność SharePoint/OneDrive).
• Korelacja tożsamość–aplikacja–dane: dąż do możliwości powiązania, kto zatwierdził dostęp, jaka aplikacja go użyła oraz do jakich zasobów faktycznie sięgała.
• Stała jakość logowania: eliminuj luki w telemetrii (braki w źródłach zdarzeń, niespójne identyfikatory, brak kontekstu aplikacji) jako ryzyko operacyjne.

Ta checklista stanowi punkt wyjścia do ograniczania ryzyka nadużyć OAuth wobec SharePoint i OneDrive: redukuje niekontrolowane zgody, porządkuje odpowiedzialność za aplikacje oraz zapewnia minimalny zestaw sygnałów do szybkiego wykrywania podejrzanej aktywności.

W Cognity łączymy teorię z praktyką – dlatego te zagadnienia rozwijamy także w formie ćwiczeń na szkoleniach.

Power Automate: wzorzec „kompensacji” (undo) w procesach — jak cofać zmiany bez ręcznego sprzątania 03 maja 2026

Dataverse w roli „źródła prawdy”: jak zbudować model danych, który skaluje PowerApps i raportowanie 01 maja 2026