You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/active-directory/roles/security-planning.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@ keywords:
7
7
author: rolyon
8
8
manager: karenhoran
9
9
ms.author: rolyon
10
-
ms.date: 11/04/2021
10
+
ms.date: 04/19/2022
11
11
ms.topic: conceptual
12
12
ms.service: active-directory
13
13
ms.workload: identity
@@ -110,7 +110,7 @@ Evaluate the accounts that are assigned or eligible for the Global Administrator
110
110
111
111
#### Turn on multi-factor authentication and register all other highly privileged single-user non-federated administrator accounts
112
112
113
-
Require Azure AD Multi-Factor Authentication (MFA) at sign-in for all individual users who are permanently assigned to one or more of the Azure AD administrator roles: Global Administrator, Privileged Role Administrator, Exchange Administrator, and SharePoint Administrator. Use the guide to enable [Multi-factor Authentication (MFA) for your administrator accounts](../authentication/howto-mfa-userstates.md) and ensure that all those users have registered at [https://aka.ms/mfasetup](https://aka.ms/mfasetup). More information can be found under step 2 and step 3 of the guide [Protect access to data and services in Microsoft 365](https://support.office.com/article/Protect-access-to-data-and-services-in-Office-365-a6ef28a4-2447-4b43-aae2-f5af6d53c68e).
113
+
Require Azure AD Multi-Factor Authentication (MFA) at sign-in for all individual users who are permanently assigned to one or more of the Azure AD administrator roles: Global Administrator, Privileged Role Administrator, Exchange Administrator, and SharePoint Administrator. Use the guidance at [Enforce multifactor authentication on your administrators](../authentication/how-to-authentication-find-coverage-gaps.md#enforce-multifactor-authentication-on-your-administrators) and ensure that all those users have registered at [https://aka.ms/mfasetup](https://aka.ms/mfasetup). More information can be found under step 2 and step 3 of the guide [Protect user and device access in Microsoft 365](/microsoft-365/compliance/protect-access-to-data-and-services).
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.
17
17
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.
19
19
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
21
21
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**.
23
23
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.
25
25
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.
| 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:
39
29
40
-
### Collected information
41
-
For each of these events, Azure Attestation collects the following information:
42
30
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>",
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:
59
69
60
-
Audit logs are provided in JSON format. Here is an example of what an audit log may look like.
| 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)
Copy file name to clipboardExpand all lines: articles/attestation/overview.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -46,7 +46,7 @@ OE standardizes specific requirements for verification of an enclave evidence. T
46
46
47
47
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.
48
48
49
-
### Azure Confidential VM attestation
49
+
### AMD SEV-SNP attestation
50
50
51
51
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.
Copy file name to clipboardExpand all lines: articles/azure-monitor/logs/cost-logs.md
+2-6Lines changed: 2 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -41,20 +41,16 @@ Some solutions have more specific policies about free data ingestion. For exampl
41
41
See the documentation for different services and solutions for any unique billing calculations.
42
42
43
43
## Commitment Tiers
44
-
In addition to the Pay-As-You-Go model, Log Analytics has **Commitment Tiers**, which can save you as much as 30 percent compared to the Pay-As-You-Go price. With commitment tier pricing, you can commit to buy data ingestion starting at 100 GB/day at a lower price than Pay-As-You-Go pricing. Any usage above the commitment level (overage) is billed at that same price per GB as provided by the current commitment tier. The commitment tiers have a 31-day commitment period from the time a commitment tier is selected.
44
+
In addition to the Pay-As-You-Go model, Log Analytics has **Commitment Tiers**, which can save you as much as 30 percent compared to the Pay-As-You-Go price. With commitment tier pricing, you can commit to buy data ingestion for a workspace, starting at 100 GB/day, at a lower price than Pay-As-You-Go pricing. Any usage above the commitment level (overage) is billed at that same price per GB as provided by the current commitment tier. The commitment tiers have a 31-day commitment period from the time a commitment tier is selected.
45
45
46
46
- During the commitment period, you can change to a higher commitment tier (which restarts the 31-day commitment period), but you can't move back to Pay-As-You-Go or to a lower commitment tier until after you finish the commitment period.
47
47
- At the end of the commitment period, the workspace retains the selected commitment tier, and the workspace can be moved to Pay-As-You-Go or to a different commitment tier at any time.
48
48
49
-
Billing for the commitment tiers is done on a daily basis. See [Azure Monitor pricing](https://azure.microsoft.com/pricing/details/monitor/) for a detailed listing of the commitment tiers and their prices.
49
+
Billing for the commitment tiers is done per workspace on a daily basis. If the workspace is part of a [dedicated cluster](#dedicated-clusters), the billing is done for the cluster (see below). See [Azure Monitor pricing](https://azure.microsoft.com/pricing/details/monitor/) for a detailed listing of the commitment tiers and their prices.
50
50
51
51
> [!TIP]
52
52
> The **Usage and estimated costs** menu item for each Log Analytics workspace hows an estimate of your monthly charges at each commitment level. You should periodically review this information to determine if you can reduce your charges by moving to another tier. See [Usage and estimated costs](../usage-estimated-costs.md#usage-and-estimated-costs) for information on this view.
53
53
54
-
55
-
> [!NOTE]
56
-
> Starting June 2, 2021, **Capacity Reservations** were renamed to **Commitment Tiers**. Data collected above your commitment tier level (overage) is now billed at the same price-per-GB as the current commitment tier level, lowering costs compared to the old method of billing at the Pay-As-You-Go rate, and reducing the need for users with large data volumes to fine-tune their commitment level. Three new commitment tiers were also added: 1000, 2000, and 5000 GB/day.
57
-
58
54
## Dedicated clusters
59
55
An [Azure Monitor Logs dedicated cluster](logs-dedicated-clusters.md) is a collection of workspaces in a single managed Azure Data Explorer cluster. Dedicated clusters support advanced features such as [customer-managed keys](customer-managed-keys.md) and use the same commitment tier pricing model as workspaces although they must have a commitment level of at least 500 GB/day. Any usage above the commitment level (overage) is billed at that same price per GB as provided by the current commitment tier. There is no Pay-As-You-Go option for clusters.
0 commit comments