Gyakorlati grafikon: A Microsoft AuditLog Query Graph API használata (előnézet)

Az egységes ellenőrzési napló nagyszerű információforrás

2016-os bevezetése óta az egységes auditnapló nagyszerű információforrás a Microsoft 365 bérlői rendszergazdái számára. A bérlőben futó munkaterheléstől függően a napló több mint 1600 különböző eseményt képes feldolgozni. A Purview Audit (standard) licenccel (Office 365 E3) rendelkező bérlők 180 napig, míg a Purview Audit (prémium) licenccel rendelkezők 365 napig férhetnek hozzá az eseményekhez. Annak ellenére, hogy bizonyos munkaterhelések által generált bizonyos auditálási eseményekben az információ fura formázása van, kétségtelen, hogy hasznos lehet az auditnapló lekérdezése annak érdekében, hogy megtudja, mi történt a bérlőben.

A Microsoft 365 ütemtervének 117587. számú tétele szerint az API általában 2024 májusában lesz elérhető.

Az AuditLog Query Graph API

Eddig az egyetlen programozott módszer a napló lekérdezésére a Search-UnifiedAuditLog parancsmag futtatása volt. Ez a módszer akkor is jól működik, ha a Microsoft 2023 közepén váratlan változtatásokat hajtott végre a parancsmag működésében. Egyelőre semmilyen nyilvános magyarázat nem igazolta a változtatást. Feltételezem, hogy a felhőben végzett munka öröméhez hozzátartozik a be nem jelentett változtatások felfedezése, amelyek hatással vannak az ügyfelek szkriptjeire.

A Microsoft 2022-ben új keresési funkciót vezetett be a Purview Compliance portálon. Az interaktív keresés helyett a portál keresési lekérdezéseket hoz létre, amelyeket a szolgáltatás a háttérben dolgoz fel. Az AuditLog Query Graph API (más néven Microsoft Purview Audit Search API) egy előnézeti funkció, amellyel keresési lekérdezéseket hozhat létre és futtathat, valamint a Purview által használt módon lekérheti a keresési eredményeket. A keresés végrehajtásához több lépésre van szükség:

Hozza létre a keresési lekérdezést a keresési paraméterek értékeinek megadásával.
Keresési lekérdezés (munka) beküldése.
Amikor a keresési lekérdezés befejeződött, kérje le a keresési eredményeket (audit rekordokat).

Mindez nagyon egyszerűen hangzik, de bonyolultabb, mint egy audit keresés futtatása a Search-UnifiedAuditLog parancsmaggal. Vizsgáljuk meg egy kicsit részletesebben az AuditLog Query API-t.

Audit keresési lekérdezés létrehozása

Az AuditLog Query API teszteléséhez a Microsoft Graph PowerShell SDK-t használtam. Az első dolog, amit meg kell jegyezni, hogy az AuditLogsQuery.Read.All engedélyt használtam a napló eléréséhez. Ez az engedély hozzáférést biztosít az összes audit adathoz. Más engedélyek is rendelkezésre állnak a megfigyelési adatokhoz való korlátozott hozzáférés biztosításához, például csak az Exchange Online naplózási eseményekhez való hozzáférés engedélyezése. A delegált engedélyek használatához rendszergazdai fiókkal is be kell jelentkeznie. A háttérfolyamatként futó feladatok, például az Azure Automation runbook, alkalmazásengedélyeket használnak, és nem kell rendszergazdaként bejelentkezniük.

Ez a kódrészlet megmutatja, hogyan hozhat létre egy hash-táblát egy új keresési lekérdezés paramétereivel, és hogyan teheti fel a lekérdezést a naplólekérdezések végpontjára új feladat létrehozásához.

$Uri = "https://graph.microsoft.com/beta/security/auditLog/queries"
$SearchName = ("Audit Search {0}" -f (Get-Date -format 'dd-MMM-yyyy HH:mm'))

$SearchParameters = @{
    "displayName"           = $SearchName
    "filterStartDateTime"   = $StartDateSearch
    "filterEndDateTime"     = $EndDateSearch
    "operationFilters"      = $Operations
}

$SearchQuery = Invoke-MgGraphRequest -Method POST -Uri $Uri -Body $SearchParameters
$SearchId = $SearchQuery.Id

A $Operations változó a keresendő ellenőrzési események vesszővel elválasztott listáját tartalmazza. A keresés kezdő és befejező dátuma rendezhető dátumformátumban, Z utótaggal történik. Íme egy példa arra, hogy hogyan néz ki a hash-tábla egy olyan lekérdezésnél, amely két SharePoint Online-műveletet keres 2024. február 29. éjfél és 2024. március 2. éjfél között:

Name                           Value
----                           -----
filterEndDateTime              2024-03-02T00:00:00Z
displayname                    Audit Search 04-Mar-2024 05:29
filterStartarDateTime          2024-02-29T00:00:00Z
operationsFilters              {fileuploaded, filemodified}

Vannak, akik szeretnek lekérni egy adott időszakra vonatkozó összes audit rekordot, mert hosszú távú megőrzés és lekérdezés céljából be akarják tölteni az ellenőrzési adatokat egy SIEM-be. A Search-UnifiedAuditLog parancsmag segítségével az összes elérhető megfigyelési rekord lekérésének módja az, hogy nem ad meg semmilyen műveletet.

Ha egy adott időszakra vonatkozó minden ellenőrzési rekordot le szeretne kérni, ne vegye fel az operationsFilter elemet az Auditlog-lekérdezéshez használt paraméterek közé. A paraméterek ezután csak egy megjelenített név, kezdő dátum és idő, valamint befejezés dátuma és időpontja lesznek. Alternatív megoldásként beilleszthet egy recordTypeFilters szűrőt az Önt érdeklő naplózási rekordtípusok meghatározásához.

Audit keresési lekérdezés futtatása

A keresési lekérdezés befejezése akár tíz percig is eltarthat. Végül a keresés befejeződik, és lekérheti a lekérdezés által talált ellenőrzési rekordokat. Ez a részlet megmutatja, hogyan kell lekérni az ellenőrzési rekordok első oldalát.

$Uri = ("https://graph.microsoft.com/beta/security/auditLog/queries/{0}/records" -f $SearchId)
[array]$SearchRecords = Invoke-MgGraphRequest -Uri $Uri -Method GET

Az API 150 rekordot ad vissza egy oldalon. Ha 150-nél kevesebb rekordot kell lekérni, folytathatja a visszaküldött rekordok elemzését. Ha azonban több adat áll rendelkezésre, akkor a kódnak a következő oldal eléréséhez visszaadott nextlink URI-kat kell használnia a következő oldal lekéréséhez, amíg több nem áll rendelkezésre. A kód korlátozott darabokban történő lekérésére kényszerítése egy gyakori, lapozásnak nevezett folyamat, amelyet a Graph API-k az egyszerre lekérhető adatok mennyiségének korlátozására használnak. Íme a kód a lapozáshoz és a lekérdezéshez rendelkezésre álló ellenőrzési rekordok lekéréséhez:

# Paginate to fetch all available audit records
$NextLink = $SearchRecords.'@Odata.NextLink'
While ($null -ne $NextLink) {
    $SearchRecords = $null
    [array]$SearchRecords = Invoke-MgGraphRequest -Uri $NextLink -Method GET 
    $AuditRecords += $SearchRecords.value
    Write-Host ("{0} audit records fetched so far..." -f $AuditRecords.count)
    $NextLink = $SearchRecords.'@odata.NextLink' 
}

A lapozás jól működik a Graph API-kkal. Az AuditLog Query API előnézeti verziója meglehetősen kényesnek tűnik, és a nextlink-mutatók használatára tett kísérleteim egy része „500-as belső szerverhibát” eredményezett, amely blokkolta a megfigyelési rekordok lekérésére irányuló kísérleteket.

A Microsoft Graph PowerShell SDK megkönnyíti a fejlesztők dolgát azáltal, hogy számos parancsmaghoz tartalmaz egy All paramétert az összes elérhető adat lekéréséhez. A naplólekérdezések kezelésére szolgáló parancsmagok a Microsoft Graph PowerShell SDK-ban (V2.15) léteznek. Például a lekérdezés által talált megfigyelési rekordok lekéréséhez futtassa a Get-MgBetaSecurityAuditLogQueryRecord parancsmagot, és adja meg az All paramétert:

[array]$AuditRecords = Get-MgBetaSecurityAuditLogQueryRecord -AuditLogQueryId $SearchId -All

Első pillantásra úgy tűnik, hogy a parancsmag nagyszerű módja annak, hogy lekérje az ellenőrzési naplókeresés által visszaadott összes audit rekordot. A parancsmag visszaadja az összes rekordot, de bármit is tettem, az AuditData tulajdonság tartalma mindig Microsoft.Graph.Beta.PowerShell.Models.MicrosoftGraphSecurityAuditData volt. Az elemzendő AuditData tulajdonság tartalma nélkül a visszakeresett auditrekordok értéke jelentősen csökken. A végeredmény az, hogy tovább dolgoztam a Graph lekérdezésekkel. Ez az a fajta probléma, amely valószínűleg megoldódik, amikor a Microsoft általánosan elérhetővé teszi az API-t.

Az ellenőrzési adatok elemzése

Az ellenőrzési jegyzőkönyvek két részből állnak. Az első az összes munkaterhelésben állandó, és olyan információkat tartalmaz, mint az időbélyeg, a művelet neve és a műveletért felelős felhasználói vagy rendszerfiók. A második, az AuditData tulajdonságban tárolt, ahol a történtekkel kapcsolatos információk találhatók. Mindegyik munkaterhelés szabályozza az AuditDataban tárolt információkat, és jelentős eltérések vannak a terhelések között. Emiatt az ellenőrzési rekordok tartalmának elemzése a szükségesnél több erőfeszítést és egyedi kódolást igényel.

A jó hír az, hogy az AuditLog Query API könnyen elérhető hash táblaként adja vissza az AuditData tulajdonságot. A rossz hír az, hogy a tartalom azonos eltéréseket mutat a munkaterhelések között (nem számítottam másra). Más szóval, minden típusú audit eseménynél ki kell találnia, hogy mit tartalmaz az AuditData tulajdonság, és mit jelentenek az adatok, ugyanúgy, mint a Search-UnifiedAuditLog által generált eredményeknél. parancsmag.

Az 1. ábra a lekérdezésből beolvasott ellenőrzési rekordokból származó információkat mutat be. Fogalmam sincs, melyik objektum azonosítója: eba15bfd-c28e-4433-a20e-0278888c5825. Nem találok ezzel az értékkel rendelkező felhasználói fiókot vagy egyszerű szolgáltatást. Ez egy áldott rejtély.

A teszteléshez használt szkriptet letöltheti a GitHubról.

A könyvvizsgálati események egyszerű kivonatolása

Mindig fontos emlékezni, amikor a szoftver előnézeti szakaszban van. A kódot az emberek tesztelhetik, és még javulni fog, mielőtt elérné az általános elérhetőséget. Tekintettel a Microsoft 365 műveletei által generált naplózási adatok mennyiségére, érthető, hogy a Microsoft el akar térni a szinkron interaktív naplózási keresési műveletektől, amelyek a Search-UnifiedAuditLog parancsmag által futtatott típusúak, és inkább a szolgáltatáshoz igazodtak. a háttérben futtatható műveletek. Így működik most a Purview megfelelőségi portál, és az AuditLog Query API megléte egy újabb jele annak, hogy a Microsoft szeretné, ha a rendszergazdák ebben a módban faggatnák le az ellenőrzési eseményeket.

A Microsoft problémája az, hogy az egyetlen PowerShell-parancsmaggal való munka egyszerűsége a háttérben futó aszinkron naplózási keresések beállításának, majd az eredmények lekérésének bonyolultságához képest olyannyira, hogy a rendszergazdák valószínűleg elkerülik a Graph API-megközelítést. Mindenki szereti a könnyű életet, és a Search-UnifiedAuditLog továbbra is a legegyszerűbb módja az adatok lekérésének a Microsoft 365 naplójából.