Skalowanie w górę: zarządzanie stronicowaniem, ograniczaniem przepustowości i audytami dużych dzierżaw Microsoft 365

By Mirko Peters · 2026-08-11

Witamy z powrotem na blogu! Jeśli zarządzasz ogromnym środowiskiem Microsoft 365, wiesz już, że standardowe, domyślne narzędzia raportowania ledwie muskają powierzchnię…

Automatically translated with AI from the original post. Read the English original

Titelbild: Scaling Up: Managing Pagination, Throttling, and Large Tenant M365 Audits

Witamy ponownie na blogu! Jeśli zarządzasz rozległym środowiskiem Microsoft 365, wiesz już, że standardowe narzędzia raportowania dostępne od razu po instalacji pokazują tylko wierzchołek góry lodowej. Gdy zespoły bezpieczeństwa i specjaliści ds. zgodności analizują duże dzierżawy, podstawowe skrypty i widoki z centrum administracyjnego po prostu nie radzą sobie z ciężarem tysięcy użytkowników, grup i plików. Audyt dużych dzierżaw M365 wymaga czegoś więcej niż podstawowych skryptów; wymaga taktycznego, programistycznego podejścia opartego na interfejsie Microsoft Graph API. W tym kompleksowym przewodniku rozwijamy wątki z naszej niedawnej rozmowy w odcinku podcastu Map Microsoft 365 Users, Groups, Files, and Shares with Graph. Przyjrzyjmy się szczegółowo temu, jak obsługiwać stronicowanie @odata.nextLink, uwzględniać limity żądań 429 za pomocą wykładniczego wycofywania oraz unikać typowych pułapek, takich jak błąd skupienia na pierwszej stronie, aby uzyskać pełną widoczność dzierżawy.

Wprowadzenie do wyzwań audytu M365

Środowiska przedsiębiorstw rozrastają się organicznie. Użytkownicy odchodzą i dołączają, projekty w ciągu jednej nocy powołują nowe działy, a zewnętrzni dostawcy są zapraszani do przestrzeni współpracy. Z czasem widoczność administracyjna się pogarsza. Domyślne centra administracyjne pokazują wycinki infrastruktury, pozostawiając martwe punkty, które mogą wykorzystać złośliwi aktorzy lub nieostrożni użytkownicy wewnętrzni. Aby uzyskać prawdziwy obraz stanu bezpieczeństwa dzierżawy, trzeba przejść od ręcznego audytu klikanego w interfejsie do zautomatyzowanego przeglądania grafu sterowanego przez API. Skalowanie tych zapytań do rozmiarów przedsiębiorstwa wiąże się jednak ze złożonymi przeszkodami, takimi jak ogromne ładunki danych, agresywne ograniczanie przepustowości i głęboko zagnieżdżone struktury relacyjne.

Dlaczego M365 nie jest odizolowany: zrozumienie dostępu relacyjnego

Jedną z fundamentalnych cech Microsoft 365 jest to, że usługi takie jak SharePoint, Teams i OneDrive nie są odizolowanymi silosami. Ciągle się przenikają za pośrednictwem członkostw w grupach i bazowych list kontroli dostępu. Pojedyncza czynność administracyjna, na przykład dodanie użytkownika do grupy zabezpieczeń, może rozejść się na dziesiątki witryn zespołów, bibliotek dokumentów i prywatnych kanałów, nie pozostawiając w standardowych widokach oczywistej ciągłości audytu.

Stwarza to ukryte ryzyka dla zgodności. Linki udostępniania utworzone w odizolowanych czatach, pliki odzwierciedlone w różnych bibliotekach zespołów oraz osierocone udostępnienia z dawno zakończonych projektów tworzą niewidoczne ścieżki dostępu do danych firmowych. Dostęp w M365 jest zasadniczo relacyjny, a nie oparty na lokalizacji. Aby skutecznie przeprowadzić audyt, trzeba odwzorować te kaskadowe zależności, zamiast traktować każdą usługę jako niezależną wyspę.

Mapowanie śladu z użyciem Graph Explorer

Zanim napiszesz automatyzację na skalę przedsiębiorstwa, musisz zrozumieć, jak ręcznie prześledzić ślad użytkownika za pomocą Graph Explorer. Budowanie zapytań krok po kroku pozwala upewnić się, że logika jest poprawna, zanim napiszesz choćby jedną linijkę kodu. Oto schemat mapowania punktów styku użytkownika:

Zakotwicz się na użytkowniku: zacznij od pobrania podstawowego obiektu użytkownika za pomocą GET /v1.0/users/{userPrincipalName}?$select=id,displayName,userPrincipalName.
Wylicz członkostwa: pobierz grupy i role powiązane z tą tożsamością za pomocą GET /v1.0/users/{id}/memberOf?$select=id,displayName.
Przejdź od grup do zasobów: w przypadku grup Microsoft 365 i zespołów wskaż bazową witrynę SharePoint za pomocą GET /v1.0/groups/{groupId}/drive/root/children?$select=id,name,lastModifiedDateTime,webUrl lub wylicz dyski witryny bezpośrednio za pomocą GET /v1.0/sites/{siteId}/drives.
Pobierz uprawnienia i linki do elementów: sprawdź dostęp do poszczególnych plików za pomocą GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$select=id,grantedToV2,link,roles,shareId.
Ustal, kto i do czego miał dostęp: koreluj działania użytkowników, korzystając z dzienników logowania lub alertów zabezpieczeń powiązanych z kontekstem pliku i witryny.
Zamknij pętlę z postami w Teams: wyszukaj w wiadomościach kanałów odwołania do konkretnych plików za pomocą GET /v1.0/teams/{teamId}/channels/{channelId}/messages?$search="filename" (pamiętając o uprawnieniach i wymaganiach wersji beta).

Filtry eliminujące szum, z których naprawdę będziesz korzystać

Zapytania do Microsoft Graph bez filtrów to szybka droga do przeciążenia systemu strumieniem danych. Aby wydobyć rzeczywiste ryzyka, potrzebujesz precyzyjnych strategii filtrowania. Oto wzorce zapytań, które warto wdrożyć:

Zewnętrzne udostępnienia w ciągu ostatnich 7 dni: Wybierz linki anonimowe lub dla całej organizacji, używając GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$filter=link/scope eq 'anonymous' or link/scope eq 'organization'.
Tylko ryzykowne typy plików: Dołącz filtry, takie jak $filter=endsWith(resourceReference/name,'.xlsm') lub endsWith(resourceReference/name,'.pst'), aby wychwycić pliki z makrami i archiwa.
Wzmianki o wrażliwych terminach poza godzinami pracy w Teams: Przeszukaj wiadomości w kanałach pod kątem terminów takich jak confidential, a następnie przefiltruj wyniki według znaczników czasu utworzenia poza typowymi godzinami pracy.
Utrzymuj lekkie ładunki: Zawsze dodawaj parametry $select, aby zwracać tylko niezbędne identyfikatory, nazwy, adresy URL i znaczniki czasu.
Limit dla triażu: Użyj $top=50 do szybkich kontroli próbkowych, ale usuń ten parametr podczas pełnych eksportów do swojego magazynu danych.

Obowiązkowe elementy przy skali enterprise: stronicowanie i limitowanie żądań

Podczas audytów obejmujących dzierżawę z setkami tysięcy obiektów skrypty napotkają ograniczenia, jeśli nie uwzględnią limitów API i stronicowania. Pobieranie danych nigdy się nie kończy, dopóki nie podążysz za właściwością @odata.nextLink dla każdej pojedynczej strony zwróconej przez API. Zignorowanie tego oznacza, że skrypt pobierze tylko pierwszą partię wyników i całkowicie pominie resztę dzierżawy.

Ponadto musisz respektować odpowiedzi HTTP 429 (limit żądań). Wdróż solidną logikę wykładniczego ponawiania (exponential backoff), aby skrypt wstrzymywał się, czekał na zakończenie okresu schładzania i płynnie wznawiał pracę od miejsca przerwania. Mądrze grupuj żądania, preferując mniejszą liczbę większych, logicznych żądań, oraz buforuj mapowania grup do witryn. W przypadku bardzo dużych dzierżaw dziel indeksowanie według witryny lub zakresu dat i planuj je poza godzinami szczytu, aby nie wpływać na wydajność środowiska produkcyjnego.

Typowe pułapki i szybkie rozwiązania

Nawet doświadczeni administratorzy napotykają przeszkody podczas skalowania audytów Microsoft 365. Oto najczęstsze pułapki i sposoby ich naprawy:

Pułapka: Eksporty CSV rozjeżdżają się wraz ze zmianami schematu w czasie. Rozwiązanie: Używaj bezpośrednio Graph API z wersjonowanymi transformacjami i łagodnie obsługuj nieznane pola.
Pułapka: Mieszane identyfikatory, takie jak GUID-y a nazwy UPN, psują złączenia w bazie danych. Rozwiązanie: Znormalizuj wszystko do spójnego modelu semantycznego obejmującego użytkowników, grupy, witryny, dyski, elementy i uprawnienia.
Pułapka: Skupienie na pierwszej stronie ukrywa większość incydentów bezpieczeństwa zakopanych głębiej w wynikach. Rozwiązanie: Zawsze rejestruj łączną liczbę przetworzonych stron i skonfiguruj alerty, jeśli oczekiwana ilość danych nagle spadnie.
Pułapka: Zalew nieistotnych plików obciąża silniki przetwarzania. Rozwiązanie: Stosuj ścisłe filtry dla zakresów udostępniania, okien czasowych i list wrażliwych terminów.
Pułapka: Udziały w Teams są oderwane od bazowych plików. Rozwiązanie: Koreluj adresy URL wiadomości z kanałów bezpośrednio z elementami dysku i przechowuj oba identyfikatory razem.

Kluczowe wskaźniki KPI dla kadry zarządzającej, które to odblokowuje

Dane techniczne są wartościowe tylko wtedy, gdy możesz przełożyć je na praktyczną wiedzę biznesową dla kierownictwa. Zbudowanie zautomatyzowanego potoku audytu Graph otwiera możliwość śledzenia potężnych wskaźników KPI dla zarządu:

Tempo ekspozycji zewnętrznej: Mierz liczbę nowych linków dla gości utworzonych w tygodniu, z podziałem na witryny i zespoły.
Wskaźnik dostępu do wrażliwych plików: Śledź unikalnych odbiorców treści oznaczonych etykietami, rozdzielając użytkowników wewnętrznych od gości zewnętrznych.
Ryzyko efektu falowego grup: Mierz pliki, które stały się dostępne w ciągu 24 godzin od istotnych zmian członkostwa w grupach.
Ukryty obieg (shadow circulation): Monitoruj wrażliwe pliki pojawiające się w wielu zespołach lub witrynach w ramach jednego sprintu.
Skuteczność czyszczenia: Śledź liczbę unieważnionych linków oraz czas usunięcia problemów w czasie.

Przepis na szybki start z zapytaniami

Jeśli jesteś gotowy, by zbudować własny potok zbierania danych, skorzystaj z tego przepływu do skopiowania i wklejenia, aby ruszyć z miejsca:

Pobierz podstawowe dane użytkownika i jego członkostwa: /users/{upn}?$select=id,displayName oraz /users/{id}/memberOf?$select=id,displayName.
Dla każdej grupy Microsoft 365 wylicz elementy dysku: /groups/{groupId}/drive/root/children?$select=id,name,webUrl,lastModifiedDateTime&$top=200, pamiętając o podążaniu za @odata.nextLink.
Dla każdego elementu pobierz uprawnienia: /drives/{driveId}/items/{itemId}/permissions?$select=id,roles,grantedToV2,link, filtrując zakresy anonimowe lub organizacyjne.
Eksportuj wiersze do wyznaczonego magazynu danych, rejestrując czas dzierżawy, identyfikatory witryn, identyfikatory dysków, identyfikatory elementów, adresy URL, właścicieli, zakresy i szczegóły dotyczące wygaśnięcia.
Wizualizuj znormalizowane dane w Power BI na potrzeby pulpitów dla kadry zarządzającej i operacyjnych.

Zamiana tego w żywy pulpit

Jednorazowy audyt to tylko migawka, a audyt prowadzony w sposób ciągły to program bezpieczeństwa. Aby przekształcić surowe wywołania Graph w dynamiczny pulpit, zasil dane w Power Dataflows, aby uzyskać znormalizowane tabele dla użytkowników, grup, witryn, dysków, elementów, uprawnień i wiadomości. Zamodeluj dane w schemacie gwiaździstym z elementami w centrum i przejrzystymi relacjami z użytkownikami oraz grupami.

Skonfiguruj przyrostowe odświeżanie na podstawie pól lastModifiedDateTime, z aktualizacjami w ciągu dnia dla witryn wysokiego ryzyka. Na koniec skonfiguruj zautomatyzowane alerty, które uruchamiają się zawsze, gdy na oznaczonej etykietą zawartości pojawią się nowe linki zewnętrzne lub gdy wskaźnik group-ripple wskaże skoki sugerujące nieautoryzowane rozszerzanie dostępu.

Plan wdrożenia na 30 dni

Rzym nie powstał w jeden dzień, a wdrożenie korporacyjnej struktury audytu wymaga starannego etapowania. Postępuj zgodnie z tym 30-dniowym planem wdrożenia, aby zapewnić sprawny przebieg:

Tydzień 1: skonfiguruj rejestrację aplikacji w Azure, przypisz uprawnienia interfejsu Graph API z najmniejszym wymaganym zakresem i ustal wartości bazowe pierwszych zapytań, używając parametrów $select oraz $filter.

Tydzień 2: opracuj skrypty stronicowania, znormalizuj identyfikatory do spójnych nazw UPN i nazw urządzeń oraz wykonaj pierwszy pomyślny eksport danych od początku do końca.

Tydzień 3: zbuduj model danych w Power BI i skonfiguruj kluczowe wskaźniki KPI, takie jak zewnętrzna ekspozycja, ryzyko group-ripple oraz osie czasu od dostępu do cofnięcia (dwell-to-revoke).

Tydzień 4: zautomatyzuj odświeżanie danych, wdróż alerty o anomaliach i udokumentuj standardowe procedury operacyjne dla zespołu prowadzącego dochodzenia w sprawach bezpieczeństwa.

Kto powinien to obejrzeć

Ta struktura została zaprojektowana z myślą o administratorach Microsoft 365 i liderach SecOps, którzy podejrzewają, że zielone pulpity ukrywają szare strefy, o zespołach ds. zgodności potrzebujących pełnej widoczności udostępnień bez mnożenia narzędzi zewnętrznych oraz o właścicielach współpracy odpowiedzialnych za utrzymanie bezpiecznych praktyk udostępniania zewnętrznego.

Wskazówki praktyczne

Podczas wdrażania tych skryptów w środowisku produkcyjnym pamiętaj o kilku szybkich wskazówkach. Zawsze zaczynaj dochodzenia od użytkownika lub pliku, a następnie badaj zależności w obu kierunkach, aby wyeliminować martwe punkty. Traktuj każde zdarzenie dodania do grupy jako zmianę wysokiego ryzyka i sprawdź dalszy dostęp w ciągu 24 godzin. Prowadź bieżącą listę wrażliwych terminów do przeszukiwania nazw plików i wiadomości w usłudze Microsoft Teams. Na koniec dokładnie rejestruj liczbę stron i wielkość wyników, ponieważ cisza ze skryptu często oznacza uszkodzone zadanie, a nie czystą dzierżawę.

Podsumowanie

Opanowanie stronicowania, przestrzeganie limitów żądań oraz unikanie faworyzowania pierwszej strony to kluczowe umiejętności dla każdego, kto odpowiada za zabezpieczenie dużej dzierżawy Microsoft 365. Wykraczając poza podstawowe centra administracyjne i wykorzystując pełne możliwości programistyczne interfejsu Microsoft Graph API, możesz przekształcić niewidoczne ryzyka udostępniania w jasne, mierzalne wnioski dotyczące bezpieczeństwa.

Aby poznać głębsze zagadnienia, próbki kodu i praktyczne przepisy na zapytania Graph, koniecznie posłuchaj naszej pełnej dyskusji w podcaście. Zapoznaj się z powiązanym odcinkiem i sprawdź wszystkie szczegóły pod adresem Map Microsoft 365 Users, Groups, Files, and Shares with Graph. Dbaj o bezpieczeństwo, automatyzuj dalej, a do zobaczenia w następnym odcinku!