Azure Attestation-Protokollierung
Wenn Sie eine oder mehrere Azure Attestation Ressourcen erstellen, möchten Sie überwachen, wie und wann auf Ihre Bestätigungsinstanz zugegriffen wird, und von wem. Sie können dies tun, indem Sie die Protokollierung für den Microsoft Azure-Nachweis aktivieren, wodurch Informationen in einem von Ihnen bereitgestellten Azure-Speicherkonto gespeichert werden.
Die Protokollierungsinformationen sind bis zu 10 Minuten nach dem Auftreten des Vorgangs verfügbar (in den meisten Fällen ist dies schneller). Da Sie das Speicherkonto bereitstellen, können Sie Ihre Protokolle über standardmäßige Azure-Zugriffssteuerelemente sichern und Protokolle löschen, die Sie nicht mehr im Speicherkonto behalten möchten.
Interpretieren Ihrer Azure Attestation-Protokolle
Wenn die Protokollierung aktiviert ist, werden möglicherweise bis zu drei Container automatisch für Sie in Ihrem angegebenen Speicherkonto erstellt: insights-logs-auditevent, insights-logs-operational, insights-logs-notprocessed. Es wird empfohlen, nur insights-logs-operational und insights-logs-notprocessed zu verwenden. Insights-logs-auditevent wurde erstellt, um frühzeitigen Zugriff auf Protokolle für Kunden mit VBS bereitzustellen. Zukünftige Verbesserungen der Protokollierung werden in den insights-logs-operational und insights-logs-notprocessed auftreten.
Insights-logs-operational enthält generische Informationen über alle TEE-Typen.
Insights-logs-notprocessed enthält Anforderungen, die der Dienst nicht verarbeiten konnte, in der Regel aufgrund falsch formatierter HTTP-Header, unvollständiger Nachrichtentexte oder ähnlicher Probleme.
Einzelne Blobs werden als Text und formatiert als JSON-Blob gespeichert. Schauen wir uns einen Beispielprotokolleintrag an:
{
"Time": "2021-11-03T19:33:54.3318081Z",
"resourceId": "/subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.Attestation/attestationProviders/<instance name>",
"region": "EastUS",
"operationName": "AttestSgxEnclave",
"category": "Operational",
"resultType": "Succeeded",
"resultSignature": "400",
"durationMs": 636,
"callerIpAddress": "::ffff:24.17.183.201",
"traceContext": "{\"traceId\":\"e4c24ac88f33c53f875e5141a0f4ce13\",\"parentId\":\"0000000000000000\",}",
"identity": "{\"callerAadUPN\":\"deschuma@microsoft.com\",\"callerAadObjectId\":\"6ab02abe-6ca2-44ac-834d-42947dbde2b2\",\"callerId\":\"deschuma@microsoft.com\"}",
"uri": "https://deschumatestrp.eus.test.attest.azure.net:443/attest/SgxEnclave?api-version=2018-09-01-preview",
"level": "Informational",
"location": "EastUS",
"properties":
{
"failureResourceId": "",
"failureCategory": "None",
"failureDetails": "",
"infoDataReceived":
{
"Headers":
{
"User-Agent": "PostmanRuntime/7.28.4"
},
"HeaderCount": 10,
"ContentType": "application/json",
"ContentLength": 6912,
"CookieCount": 0,
"TraceParent": ""
}
}
}
Die meisten dieser Felder werden im allgemeinen Schema auf oberster Ebene dokumentiert. In der folgenden Tabelle sind die Feldnamen und Beschreibungen für die Einträge aufgeführt, die nicht im allgemeinen Schema der obersten Ebene enthalten sind:
| Feldname | Beschreibung |
|---|---|
| traceContext | JSON-Blob, das den W3C-Ablaufverfolgungskontext darstellt |
| uri | Anforderungs-URI |
Die Eigenschaften enthalten zusätzlichen Azure-Bestätigungskontext:
| Feldname | Beschreibung |
|---|---|
| failureResourceId | Ressourcen-ID der Komponente, die zu Anforderungsfehlern führte |
| failureCategory | Breite Kategorie, die die Kategorie eines Anforderungsfehlers angibt. Enthält Kategorien wie AzureNetworkingPhysical, AzureAuthorization usw. |
| failureDetails | Detaillierte Informationen zu einem Anforderungsfehler, falls verfügbar |
| infoDataReceived | Informationen zu der vom Client empfangenen Anforderung. Enthält einige HTTP-Header, die Anzahl der empfangenen Header, den Inhaltstyp und die Inhaltslänge |