Skip to content

Commit c122817

Browse files
Maggiemouse1Maggiemouse1
authored
Merge pull request #195451 from mssindhurid/main
maa shoebox
2 parents 21a3ecb + 558e15f commit c122817

File tree

3 files changed

+63
-109
lines changed

3 files changed

+63
-109
lines changed

‎articles/attestation/audit-logs.md

Lines changed: 60 additions & 108 deletions
Original file line numberDiff line numberDiff line change
@@ -11,123 +11,75 @@ ms.author: mbaldwin
1111

1212
---
1313

14-
# Audit logs for Azure Attestation
14+
# Azure Attestation logging
1515

16-
Audit logs are secure, immutable, timestamped records of discrete events that happened over time. These logs capture important events that may affect the functionality of your attestation instance.
16+
If you create one or more Azure Attestation resources, you’ll want to monitor how and when your attestation instance is accessed, and by whom. You can do this by enabling logging for Microsoft Azure Attestation, which saves information in an Azure storage account you provide.
1717

18-
Azure Attestation manages attestation instances and the policies associated with them. Actions associated with instance management and policy changes are audited and logged.
18+
Logging information will be available up to 10 minutes after the operation occurred (in most cases, it will be quicker than this). Since you provide the storage account, you can secure your logs via standard Azure access controls and delete logs you no longer want to keep in your storage account.
1919

20-
This article contains information on the events that are logged, the information collected, and the location of these logs.
20+
## Interpret your Azure Attestation logs
2121

22-
## About Audit logs
22+
When logging is enabled, up to three containers may be automatically created for you in your specified storage account: **insights-logs-auditevent, insights-logs-operational, insights-logs-notprocessed**. It is recommended to only use **insights-logs-operational** and **insights-logs-notprocessed**. **insights-logs-auditevent** was created to provide early access to logs for customers using VBS. Future enhancements to logging will occur in the **insights-logs-operational** and **insights-logs-notprocessed**.
2323

24-
Azure Attestation uses code to produce audit logs for events that affect the way attestation is performed. This typically boils down to how or when policy changes are made to your attestation instance as well as some admin actions.
24+
**Insights-logs-operational** contains generic information across all TEE types.
2525

26-
### Auditable Events
27-
Here are some of the audit logs we collect:
26+
**Insights-logs-notprocessed** contains requests which the service was unable to process, typically due to malformed HTTP headers, incomplete message bodies, or similar issues.
2827

29-
| Event/API | Event Description |
30-
|--------------------------------------------|-----------------------------------------------------------------------------------------------|
31-
| Create Instance | Creates a new instance of an attestation service. |
32-
| Destroy Instance | Destroys an instance of an attestation service. |
33-
| Add Policy Certificate | Addition of a certificate to the current set of policy management certificates. |
34-
| Remove Policy Certificate | Remove a certificate from the current set of policy management certificates. |
35-
| Set Current Policy | Sets the attestation policy for a given TEE type. |
36-
| Reset Attestation Policy | Resets the attestation policy for a given TEE type. |
37-
| Prepare to Update Policy | Prepare to update attestation policy for a given TEE type. |
38-
| Rehydrate Tenants After Disaster | Re-seals all of the attestation tenants on this instance of the attestation service. This can only be performed by Attestation Service admins. |
28+
Individual blobs are stored as text, formatted as a JSON blob. Let’s look at an example log entry:
3929

40-
### Collected information
41-
For each of these events, Azure Attestation collects the following information:
4230

43-
- Operation Name
44-
- Operation Success
45-
- Operation Caller, which could be any of the following:
46-
- Azure AD UPN
47-
- Object ID
48-
- Certificate
49-
- Azure AD Tenant ID
50-
- Operation Target, which could be any of the following:
51-
- Environment
52-
- Service Region
53-
- Service Role
54-
- Service Role Instance
55-
- Resource ID
56-
- Resource Region
31+
```json
32+
{
33+
"Time": "2021-11-03T19:33:54.3318081Z",
34+
"resourceId": "/subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.Attestation/attestationProviders/<instance name>",
35+
"region": "EastUS",
36+
"operationName": "AttestSgxEnclave",
37+
"category": "Operational",
38+
"resultType": "Succeeded",
39+
"resultSignature": "400",
40+
"durationMs": 636,
41+
"callerIpAddress": "::ffff:24.17.183.201",
42+
"traceContext": "{\"traceId\":\"e4c24ac88f33c53f875e5141a0f4ce13\",\"parentId\":\"0000000000000000\",}",
43+
"identity": "{\"callerAadUPN\":\"[email protected]\",\"callerAadObjectId\":\"6ab02abe-6ca2-44ac-834d-42947dbde2b2\",\"callerId\":\"[email protected]\"}",
44+
"uri": "https://deschumatestrp.eus.test.attest.azure.net:443/attest/SgxEnclave?api-version=2018-09-01-preview",
45+
"level": "Informational",
46+
"location": "EastUS",
47+
"properties":
48+
{
49+
"failureResourceId": "",
50+
"failureCategory": "None",
51+
"failureDetails": "",
52+
"infoDataReceived":
53+
{
54+
"Headers":
55+
{
56+
"User-Agent": "PostmanRuntime/7.28.4"
57+
},
58+
"HeaderCount": 10,
59+
"ContentType": "application/json",
60+
"ContentLength": 6912,
61+
"CookieCount": 0,
62+
"TraceParent": ""
63+
}
64+
}
65+
}
66+
```
5767

58-
### Sample Audit log
68+
Most of these fields are documented in the [Top-level common schema](/azure-monitor/essentials/resource-logs-schema#top-level-common-schema). The following table lists the field names and descriptions for the entries not included in the top-level common schema:
5969

60-
Audit logs are provided in JSON format. Here is an example of what an audit log may look like.
70+
| Field Name | Description |
71+
|------------------------------------------|-----------------------------------------------------------------------------------------------|
72+
| traceContext | JSON blob representing the W3C trace-context |
73+
| uri | Request URI |
6174

62-
```json
63-
{
64-
"operationName": "SetCurrentPolicy",
65-
"resultType": "Success",
66-
"resultDescription": null,
67-
"auditEventCategory": [
68-
"ApplicationManagement"
69-
],
70-
"nCloud": null,
71-
"requestId": null,
72-
"callerIpAddress": null,
73-
"callerDisplayName": null,
74-
"callerIdentities": [
75-
{
76-
"callerIdentityType": "ObjectID",
77-
"callerIdentity": "<some object ID>"
78-
},
79-
{
80-
"callerIdentityType": "TenantId",
81-
"callerIdentity": "<some tenant ID>"
82-
}
83-
],
84-
"targetResources": [
85-
{
86-
"targetResourceType": "Environment",
87-
"targetResourceName": "PublicCloud"
88-
},
89-
{
90-
"targetResourceType": "ServiceRegion",
91-
"targetResourceName": "EastUS2"
92-
},
93-
{
94-
"targetResourceType": "ServiceRole",
95-
"targetResourceName": "AttestationRpType"
96-
},
97-
{
98-
"targetResourceType": "ServiceRoleInstance",
99-
"targetResourceName": "<some service role instance>"
100-
},
101-
{
102-
"targetResourceType": "ResourceId",
103-
"targetResourceName": "/subscriptions/<some subscription ID>/resourceGroups/<some resource group name>/providers/Microsoft.Attestation/attestationProviders/<some instance name>"
104-
},
105-
{
106-
"targetResourceType": "ResourceRegion",
107-
"targetResourceName": "EastUS2"
108-
}
109-
],
110-
"ifxAuditFormat": "Json",
111-
"env_ver": "2.1",
112-
"env_name": "#Ifx.AuditSchema",
113-
"env_time": "2020-11-23T18:23:29.9427158Z",
114-
"env_epoch": "MKZ6G",
115-
"env_seqNum": 1277,
116-
"env_popSample": 0.0,
117-
"env_iKey": null,
118-
"env_flags": 257,
119-
"env_cv": "##00000000-0000-0000-0000-000000000000_00000000-0000-0000-0000-000000000000_00000000-0000-0000-0000-000000000000",
120-
"env_os": null,
121-
"env_osVer": null,
122-
"env_appId": null,
123-
"env_appVer": null,
124-
"env_cloud_ver": "1.0",
125-
"env_cloud_name": null,
126-
"env_cloud_role": null,
127-
"env_cloud_roleVer": null,
128-
"env_cloud_roleInstance": null,
129-
"env_cloud_environment": null,
130-
"env_cloud_location": null,
131-
"env_cloud_deploymentUnit": null
132-
}
133-
```
75+
The properties contain additional Azure attestation specific context:
76+
77+
| Field Name | Description |
78+
|------------------------------------------|-----------------------------------------------------------------------------------------------|
79+
| failureResourceId | Resource ID of component which resulted in request failure |
80+
| failureCategory | Broad category indicating category of a request failure. Includes categories such as AzureNetworkingPhysical, AzureAuthorization etc. |
81+
| failureDetails | Detailed information about a request failure, if available |
82+
| infoDataReceived | Information about the request received from the client. Includes some HTTP headers, the number of headers received, the content type and content length |
83+
84+
## Next steps
85+
- [How to enable Microsoft Azure Attestation logging ](azure-diagnostic-monitoring.md)

‎articles/attestation/overview.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -46,7 +46,7 @@ OE standardizes specific requirements for verification of an enclave evidence. T
4646

4747
Client applications can be designed to take advantage of TPM attestation by delegating security-sensitive tasks to only take place after a platform has been validated to be secure. Such applications can then make use of Azure Attestation to routinely establish trust in the platform and its ability to access sensitive data.
4848

49-
### Azure Confidential VM attestation
49+
### AMD SEV-SNP attestation
5050

5151
Azure [Confidential VM](../confidential-computing/confidential-vm-overview.md) (CVM) is based on [AMD processors with SEV-SNP technology](../confidential-computing/virtual-machine-solutions-amd.md) and aims to improve VM security posture by removing trust in host, hypervisor and Cloud Service Provider (CSP). To achieve this, CVM offers VM OS disk encryption option with platform-managed keys and binds the disk encryption keys to the virtual machine's TPM. When a CVM boots up, SNP report containing the guest VM firmware measurements will be sent to Azure Attestation. The service validates the measurements and issues an attestation token that is used to release keys from [Managed-HSM](../key-vault/managed-hsm/overview.md) or [Azure Key Vault](../key-vault/general/basic-concepts.md). These keys are used to decrypt the vTPM state of the guest VM, unlock the OS disk and start the CVM. The attestation and key release process is performed automatically on each CVM boot, and the process ensures the CVM boots up only upon successful attestation of the hardware.
5252

‎articles/attestation/toc.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -47,6 +47,8 @@
4747
href: claim-sets.md
4848
- name: Workflow
4949
href: workflow.md
50+
- name: Azure Attestation logging
51+
href: audit-logs.md
5052
- name: References
5153
items:
5254
- name: Regional availability

0 commit comments

Comments
 (0)