last sync: 2024-Mar-01 17:50:27 UTC

Microsoft Managed Control 1110 - Audit Storage Capacity | Regulatory Compliance - Audit and Accountability

Azure BuiltIn Policy definition

Source Azure Portal
Display name Microsoft Managed Control 1110 - Audit Storage Capacity
Id 6182bfa7-0f2a-43f5-834a-a2ddf31c13c7
Version 1.0.0
Details on versioning
Category Regulatory Compliance
Microsoft Learn
Description Microsoft implements this Audit and Accountability control
Additional metadata Name/Id: ACF1110 / Microsoft Managed Control 1110
Category: Audit and Accountability
Title: Audit Storage Capacity
Ownership: Customer, Microsoft
Description: The organization allocates audit record storage capacity in accordance with Ability to retain at least 90 days’ worth of logs.
Requirements: Audit records for each Azure service are captured by the Geneva Monitoring Agent (MA) and retained in a service-specific Azure storage account. The MA collects data from the service assets and automatically uploads to the service storage account. Each storage account is allocated sufficient storage capacity for the retention of at least ninety (90) days’ worth of logs online and is monitored for usage by the service teams. If a storage account is near capacity, either - service teams are notified by Azure Storage automatically and the service teams creates an additional storage account or expand the current account’s capacity; or, if the service team has configured Azure Storage for auto-expansion, the storage is increased as needed. Each service team is responsible for its own log capacity planning. If the service team does not expand capacity for any reason, due to the high volume of events received, Azure audit collection settings are to overwrite when capacity is exceeded. The MA then sends the collected logs from the service-specific storage into a central log storage cluster known as the parsing engine. This local cluster stores centrally aggregated log data for the purposes of standardizing the ingested log data, such as time, date, field titles, etc., and parsing the data for alerting via multiple microservices. The logs do not reside on these servers long-term; once parsed, logs are provided to Kusto and Jarvis. Kusto and Jarvis then retain the parsed data as read-only, ensuring the integrity of the centralized logs, automatically growing the backend data storage. There is no hard limit associated with the central storage. Azure currently defines baseline requirements for local security audit log storage capacity to a window of at least ten (10) minutes of events on even Azure’s most active hosts. Events are continuously sent to Geneva Monitoring, which has adequate storage capacity to handle the volume of events captured due to auto-expansion. In the event of an audit failure or audit storage capacity being reached, Azure monitoring tools generate near-real time alerts to the C+AI Security Engineering team, who are assigned to address the processing failure.
Mode Indexed
Type Static
Preview False
Deprecated False
Effect Fixed
RBAC role(s) none
Rule aliases none
Rule resource types IF (2)
Compliance Not a Compliance control
Initiatives usage none
History none
JSON compare n/a