Meningkatkan Skala: Mengelola Pagination, Throttling, dan Audit M365 untuk Penyewa Besar

By Mirko Peters · 2026-08-11

Selamat datang kembali di blog! Jika Anda mengelola lingkungan Microsoft 365 berskala besar, Anda tentu sudah tahu bahwa alat pelaporan bawaan hanya menyentuh permukaannya saja…

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

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

Selamat datang kembali di blog! Jika Anda mengelola lingkungan Microsoft 365 yang sangat besar, Anda tentu sudah tahu bahwa alat pelaporan bawaan hanya mampu menyentuh permukaannya saja. Ketika tim keamanan dan petugas kepatuhan memeriksa penyewa berskala besar, skrip dasar dan tampilan bawaan pusat admin dengan mudah gagal menghadapi beban ribuan pengguna, grup, dan file. Mengaudit penyewa M365 berskala besar membutuhkan lebih dari sekadar skrip dasar; diperlukan pendekatan taktis dan terprogram menggunakan Microsoft Graph API. Dalam panduan komprehensif ini, kita akan melanjutkan langsung pembahasan dari episode podcast kami Map Microsoft 365 Users, Groups, Files, and Shares with Graph. Mari kita bahas secara mendalam cara menangani pagination @odata.nextLink, menghormati batas laju 429 dengan exponential backoff, serta menghindari jebakan umum seperti Page 1 bias untuk mencapai visibilitas penyewa secara menyeluruh.

Pengantar Tantangan Audit M365

Lingkungan perusahaan tumbuh secara organik. Pengguna datang dan pergi, proyek membentuk departemen dalam semalam, dan vendor eksternal diundang ke ruang kolaborasi. Seiring waktu, visibilitas administratif menurun. Pusat admin bawaan hanya menampilkan fragmen terisolasi dari infrastruktur Anda, sehingga menyisakan titik buta yang dapat dimanfaatkan oleh pelaku kejahatan atau orang dalam yang tidak sengaja. Untuk mendapatkan gambaran yang benar tentang postur keamanan penyewa Anda, Anda perlu beralih dari audit manual berbasis klik ke penelusuran graph berbasis API yang otomatis. Namun, menskalakan kueri ini ke ukuran perusahaan memunculkan hambatan yang rumit, termasuk muatan data yang sangat besar, throttling yang agresif, dan struktur relasional yang sangat berlapis.

Mengapa M365 Tidak Terisolasi: Memahami Akses Relasional

Salah satu kenyataan mendasar dari Microsoft 365 adalah bahwa layanan seperti SharePoint, Teams, dan OneDrive bukanlah silo yang terisolasi. Layanan-layanan tersebut saling terhubung secara terus-menerus melalui keanggotaan grup dan daftar kontrol akses yang mendasarinya. Satu tindakan administratif, seperti menambahkan pengguna ke grup keamanan, dapat merambat ke puluhan situs tim, pustaka dokumen, dan saluran privat tanpa meninggalkan jejak audit yang jelas di tampilan standar.

Hal ini menciptakan risiko kepatuhan yang tersembunyi. Tautan tamu yang dibagikan di obrolan terisolasi, file yang diduplikasi di berbagai pustaka tim, dan berbagi yatim dari proyek yang sudah lama berakhir membuka jalur tak terlihat menuju data perusahaan Anda. Akses di M365 pada dasarnya bersifat relasional, bukan berbasis lokasi. Untuk melakukan audit secara efektif, Anda harus memetakan relasi-relasi yang saling berantai, bukan memperlakukan setiap layanan sebagai pulau yang berdiri sendiri.

Pemetaan Jejak dengan Graph Explorer

Sebelum menulis otomatisasi berskala perusahaan, Anda perlu memahami cara menelusuri jejak pengguna secara manual menggunakan Graph Explorer. Menyusun kueri langkah demi langkah memastikan logika Anda sudah benar sebelum menulis baris kode. Berikut cetak biru untuk memetakan titik sentuh pengguna:

Mulai dari pengguna: Ambil objek pengguna inti dengan GET /v1.0/users/{userPrincipalName}?$select=id,displayName,userPrincipalName.
Hitung keanggotaan: Ambil grup dan peran yang terkait dengan identitas tersebut menggunakan GET /v1.0/users/{id}/memberOf?$select=id,displayName.
Beralih ke sumber daya dari grup tersebut: Untuk Grup M365 dan Teams, targetkan situs SharePoint yang mendasarinya menggunakan GET /v1.0/groups/{groupId}/drive/root/children?$select=id,name,lastModifiedDateTime,webUrl, atau telusuri drive situs secara langsung melalui GET /v1.0/sites/{siteId}/drives.
Ambil izin dan tautan item: Periksa akses file individual dengan GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$select=id,grantedToV2,link,roles,shareId.
Telusuri siapa mengakses apa: Korelasikan tindakan pengguna menggunakan log masuk atau peringatan keamanan yang dipasangkan dengan konteks file dan situs.
Tutup lingkaran ke postingan Teams: Cari pesan saluran untuk referensi file tertentu menggunakan GET /v1.0/teams/{teamId}/channels/{channelId}/messages?$search="filename" (dengan tetap memperhatikan izin dan persyaratan beta).

Filter Pengurang Kebisingan yang Benar-Benar Akan Anda Gunakan

Mengkueri Microsoft Graph tanpa filter adalah jalan pintas menuju kewalahan oleh aliran data yang masif. Untuk memunculkan risiko yang sebenarnya, Anda memerlukan strategi pemfilteran yang presisi. Berikut pola kueri yang sebaiknya Anda terapkan:

Berbagi eksternal dalam 7 hari terakhir: Targetkan tautan anonim atau tautan seluruh organisasi menggunakan GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$filter=link/scope eq 'anonymous' or link/scope eq 'organization'.
Hanya jenis file berisiko: Tambahkan filter seperti $filter=endsWith(resourceReference/name,'.xlsm') or endsWith(resourceReference/name,'.pst') untuk menemukan file makro dan arsip.
Penyebutan istilah sensitif di Teams di luar jam kerja: Cari pesan saluran yang berisi istilah seperti confidential, lalu saring hasilnya berdasarkan stempel waktu pembuatan yang berada di luar jam kerja normal.
Jaga payload tetap ringan: Selalu sertakan parameter $select agar hanya mengembalikan pengenal, nama, URL, dan stempel waktu yang diperlukan.
Batas untuk triage: Gunakan $top=50 untuk pemeriksaan cepat, tetapi hapus parameter ini saat menjalankan ekspor penuh ke penyimpanan data Anda.

Syarat Wajib Skala Enterprise: Pagination dan Throttling

Saat menjalankan audit di seluruh penyewa dengan ratusan ribu objek, skrip Anda akan terbentur tembok jika tidak memperhitungkan batas API dan pagination. Pengambilan data belum selesai selama Anda belum mengikuti properti @odata.nextLink untuk setiap halaman yang dikembalikan API. Jika diabaikan, skrip Anda hanya akan menangkap hasil batch pertama dan melewatkan sisa data di seluruh penyewa.

Selain itu, Anda wajib mematuhi respons HTTP 429 untuk pembatasan laju. Terapkan logika exponential backoff yang andal agar skrip Anda berhenti sejenak, menunggu masa pendinginan berakhir, lalu melanjutkan dari titik terakhir tanpa celah. Kelompokkan permintaan dengan bijak dengan lebih mengutamakan permintaan logis yang lebih sedikit tetapi lebih besar, serta cache pemetaan grup ke situs. Untuk penyewa berskala besar, bagi penelusuran berdasarkan situs atau rentang tanggal, dan jadwalkan pada jam sepi agar tidak memengaruhi performa produksi.

Jebakan Umum dan Solusi Cepat

Bahkan administrator berpengalaman pun sering menemui hambatan saat audit M365 diperluas. Berikut jebakan paling umum beserta cara mengatasinya:

Jebakan: Ekspor CSV menjadi tidak sinkron seiring skema yang berubah dari waktu ke waktu. Solusi: Gunakan Graph API secara langsung dengan transformasi berversi dan tangani field yang tidak dikenal dengan baik.
Jebakan: Pengenal campuran seperti GUID dan User Principal Name merusak join database. Solusi: Normalkan semua data ke dalam model semantik yang bersih yang mencakup Users, Groups, Sites, Drives, Items, dan Permissions.
Jebakan: Bias halaman 1 menyembunyikan sebagian besar insiden keamanan yang tersembunyi lebih dalam di kumpulan hasil. Solusi: Selalu catat total halaman yang diproses dan atur peringatan jika volume data yang diharapkan tiba-tiba turun.
Jebakan: Banjir file yang tidak relevan membebani mesin pemrosesan. Solusi: Terapkan filter ketat untuk cakupan berbagi, rentang waktu, dan daftar istilah sensitif.
Jebakan: Berbagi di Teams terputus dari file yang mendasarinya. Solusi: Korelasikan URL web pesan saluran langsung ke item drive dan simpan kedua pengenal tersebut bersamaan.

KPI Tingkat Eksekutif yang Terbuka Berkat Ini

Data teknis hanya bernilai jika Anda dapat menerjemahkannya menjadi intelijen bisnis yang dapat ditindaklanjuti oleh pimpinan. Membangun pipeline audit Graph otomatis membuka KPI eksekutif yang kuat:

Kecepatan paparan eksternal: Ukur jumlah tautan tamu baru yang dibuat per minggu, dirinci per situs dan tim.
Tingkat akses file sensitif: Lacak pengguna unik yang melihat konten berlabel, dengan memisahkan pengguna internal dari tamu eksternal.
Risiko riak grup: Ukur file yang baru dapat diakses dalam 24 jam setelah perubahan keanggotaan grup yang signifikan.
Sirkulasi bayangan: Pantau file sensitif yang muncul di beberapa tim atau situs dalam satu sprint.
Efektivitas pembersihan: Lacak jumlah tautan yang dicabut dan metrik waktu penyelesaian dari waktu ke waktu.

Resep Query Cepat untuk Memulai

Jika Anda siap membangun pipeline pengumpulan data sendiri, gunakan alur salin-dan-tempel berikut untuk mulai:

Ambil detail inti pengguna dan keanggotaannya: /users/{upn}?$select=id,displayName dan /users/{id}/memberOf?$select=id,displayName.
Untuk setiap grup M365, daftarkan item drive: /groups/{groupId}/drive/root/children?$select=id,name,webUrl,lastModifiedDateTime&$top=200, pastikan untuk mengikuti @odata.nextLink.
Untuk setiap item, ambil izinnya: /drives/{driveId}/items/{itemId}/permissions?$select=id,roles,grantedToV2,link, dan filter untuk cakupan anonim atau organisasi.
Ekspor baris ke penyimpanan data yang Anda tentukan, dengan mencatat waktu penyewa, ID situs, ID drive, ID item, URL web, pemilik, cakupan, dan detail kedaluwarsa.
Visualisasikan data yang sudah dinormalisasi di Power BI untuk dasbor eksekutif dan operasional.

Mengubah Ini Menjadi Dasbor yang Terus Diperbarui

Audit yang dijalankan sekali hanyalah sebuah potret sesaat; audit yang dijalankan terus-menerus adalah sebuah program keamanan. Agar panggilan Graph mentah berubah menjadi dasbor yang hidup, alirkan data Anda ke Power Dataflows untuk menghasilkan tabel ternormalisasi untuk Users, Groups, Sites, Drives, Items, Permissions, dan Messages. Modelkan data Anda dengan skema bintang (star schema) dengan Items di tengah, dan bangun relasi yang jelas ke Users dan Groups.

Konfigurasikan penyegaran inkremental berdasarkan field lastModifiedDateTime, dan jalankan pembaruan intra-hari untuk situs berisiko tinggi. Terakhir, siapkan peringatan otomatis yang terpicu setiap kali tautan eksternal baru muncul pada konten berlabel, atau ketika lonjakan group-ripple menandakan perluasan akses yang tidak sah.

Rencana Penerapan 30 Hari

Roma tidak dibangun dalam sehari, dan kerangka kerja audit tingkat perusahaan membutuhkan tahapan yang cermat. Ikuti rencana penerapan 30 hari ini agar proses deployment berjalan lancar:

Minggu 1: Siapkan app registration di Azure Anda, berikan izin Graph API dengan hak akses paling minimal, lalu uji kueri dasar Anda menggunakan parameter $select dan $filter.

Minggu 2: Kembangkan skrip paginasi Anda, normalisasikan identifier menjadi UPN dan nama perangkat yang konsisten, dan jalankan ekspor data end-to-end pertama Anda yang berhasil.

Minggu 3: Bangun model data Power BI Anda dan konfigurasikan indikator kinerja utama seperti paparan eksternal, risiko ripple, dan waktu dwell-to-revoke.

Minggu 4: Otomatisasi penyegaran data, terapkan peringatan anomali, dan dokumentasikan prosedur operasional standar (SOP) bagi tim investigasi keamanan Anda.

Siapa yang Sebaiknya Menyimak

Kerangka kerja ini dirancang khusus untuk administrator M365 dan pemimpin SecOps yang mencurigai bahwa dasbor hijau mereka menyembunyikan area abu-abu, tim kepatuhan yang membutuhkan visibilitas berbagi dari ujung ke ujung tanpa menambah banyak alat pihak ketiga, serta pemilik kolaborasi yang bertanggung jawab menjaga praktik berbagi eksternal yang aman.

Tips Lapangan

Saat Anda menerapkan skrip ini di dunia nyata, perhatikan tips singkat berikut: selalu mulai investigasi Anda dari pengguna atau file, lalu lakukan pivot ke kedua arah untuk menghilangkan titik buta. Perlakukan setiap peristiwa penambahan ke grup sebagai perubahan berisiko tinggi, dan tinjau akses turunannya dalam waktu 24 jam. Simpan daftar istilah sensitif yang terus diperbarui untuk dicari di nama file dan pesan Teams. Terakhir, catat jumlah halaman dan volume hasil dengan cermat, sebab skrip yang diam sering kali menandakan pekerjaan yang rusak, bukan penyewa yang bersih.

Kesimpulan

Menguasai paginasi, menghormati batas laju (rate limit), dan menghindari bias Halaman 1 adalah keterampilan esensial bagi siapa pun yang bertugas mengamankan penyewa Microsoft 365 berskala besar. Dengan melampaui konsol administrasi dasar dan memanfaatkan sepenuhnya kekuatan pemrograman Microsoft Graph API, Anda dapat mengubah risiko berbagi yang tidak terlihat menjadi wawasan keamanan yang jelas dan terukur.

Untuk pembahasan yang lebih mendalam, contoh kode, dan resep Graph dari dunia nyata, simaklah diskusi lengkap kami di podcast. Lihat episode terkait dan temukan semua detailnya di Map Microsoft 365 Users, Groups, Files, and Shares with Graph. Tetap aman, terus otomatisasi, dan sampai jumpa di episode berikutnya!