|
| 1 | +Azure SQL auditing tracks database events and writes them to an audit log, but it requires explicit configuration choices before it can satisfy regulatory requirements. Contoso Financial Services must determine which audit action groups meet their compliance finding and how to scope auditing for a high-volume transaction processing database. |
| 2 | + |
| 3 | +| Capability | What it provides | |
| 4 | +|------------|------------------| |
| 5 | +| Event tracking | Records database operations using SQL Server Extended Events | |
| 6 | +| Audit action groups | Preconfigured sets of events like authentication, queries, and schema changes | |
| 7 | +| Server and database scope | Flexibility to audit all databases or individual high-priority databases | |
| 8 | +| Retention control | Configurable retention periods for compliance (0 = unlimited, or specific days) | |
| 9 | + |
| 10 | +:::image type="content" source="../media/azure-sql-auditing-flow.png" alt-text="Diagram showing the three-stage Azure SQL auditing configuration flow: database scope, audit action groups, and retention settings writing logs to Azure Storage." lightbox="../media/azure-sql-auditing-flow.png"::: |
| 11 | + |
| 12 | +## Choose audit action groups for compliance requirements |
| 13 | + |
| 14 | +Audit action groups determine what events Azure SQL auditing captures. The most important groups for financial compliance are BATCH_COMPLETED_GROUP, FAILED_DATABASE_AUTHENTICATION_GROUP, and SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP. |
| 15 | + |
| 16 | +With BATCH_COMPLETED_GROUP enabled, Azure SQL auditing records every T-SQL statement after execution completes. This group provides the most comprehensive audit trail because it captures all query activity, including SELECT statements that read sensitive financial data. With FAILED_DATABASE_AUTHENTICATION_GROUP, the audit log records every failed sign-in attempt, which helps detect brute force attacks and unauthorized access patterns. |
| 17 | + |
| 18 | +For Contoso's regulatory compliance requirement, enabling all three groups—BATCH_COMPLETED_GROUP, SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP, and FAILED_DATABASE_AUTHENTICATION_GROUP—captures all query activity, successful logins, and failed access attempts. This three-group combination is the Microsoft-recommended default and is what the Azure portal configures automatically when auditing is enabled. It satisfies the financial regulator's requirement to prove who accessed the banking database, when they connected, and what queries they executed. Omitting SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP means you can detect denied access but can't prove who successfully logged in—a critical gap for compliance reviews. |
| 19 | + |
| 20 | +Other audit action groups provide more granular control: |
| 21 | + |
| 22 | +- **DATABASE_LOGOUT_GROUP**: Records when users disconnect from the database |
| 23 | +- **DATABASE_CHANGE_GROUP**: Tracks database configuration changes like altering compatibility levels |
| 24 | +- **SCHEMA_OBJECT_ACCESS_GROUP**: Records access to specific tables and views |
| 25 | +- **DATABASE_OBJECT_PERMISSION_CHANGE_GROUP**: Tracks permission changes on database objects |
| 26 | +- **DATABASE_PERMISSION_CHANGE_GROUP**: Records changes to database-level permissions |
| 27 | + |
| 28 | +Beyond these built-in groups, you can create custom audit specifications using T-SQL. Custom specifications let you audit specific tables, schemas, or statement types when the built-in groups are too broad or generate excessive log volume. |
| 29 | + |
| 30 | +## Decide between server-level and database-level scope |
| 31 | + |
| 32 | +Azure SQL auditing operates at two different scopes, and the choice affects both performance and log organization. Server-level auditing captures events from all databases on a logical server, while database-level auditing tracks events for a single database only. |
| 33 | + |
| 34 | +The key technical difference lies in how extended event sessions are created. Server-level auditing uses a single extended event session for all databases on the logical server, while database-level auditing creates a separate session for each audited database. This architectural difference has significant performance implications for high-volume Online Transaction Processing (OLTP) environments. |
| 35 | + |
| 36 | +| Aspect | Server-level | Database-level | |
| 37 | +|--------|-------------|----------------| |
| 38 | +| Scope | All databases on the logical server | Single database only | |
| 39 | +| Extended event sessions | Single session for all databases | Per-database session | |
| 40 | +| Folder structure (SQL Database) | All logs in main folder | Database-specific folder | |
| 41 | +| Performance challenge | Higher in high-volume OLTP | Better for transaction-heavy workloads | |
| 42 | +| T-SQL creation | `CREATE SERVER AUDIT` + `CREATE SERVER AUDIT SPECIFICATION` | `CREATE DATABASE AUDIT SPECIFICATION` | |
| 43 | + |
| 44 | +For Contoso's transaction processing database, database-level auditing is the recommended choice. The single extended event session used by server-level auditing can cause performance degradation when handling the high transaction volume typical of financial services workloads. Database-level auditing distributes the auditing overhead across separate sessions, reducing contention. |
| 45 | + |
| 46 | +The folder structure also differs between the two approaches. With server-level auditing in Azure SQL Database, all audit logs are stored in the main database's folder. With database-level auditing, each database gets its own folder, making it easier to organize and retain audit logs according to different compliance requirements. |
| 47 | + |
| 48 | +## Configure retention settings for regulatory requirements |
| 49 | + |
| 50 | +Retention settings control how long audit logs are preserved in storage. The default retention value is RETENTION_DAYS = 0, which means unlimited retention and never automatically deletes audit logs. |
| 51 | + |
| 52 | +You can set retention to any integer value representing days. For Contoso's financial compliance requirement, a typical retention period ranges from 90 to 365 days minimum. Setting RETENTION_DAYS = 90 ensures the audit logs meet the regulator's minimum retention requirement while controlling storage costs. |
| 53 | + |
| 54 | +An important behavior to understand is that retention applies only to logs written after the retention value is set. If you initially configure unlimited retention (zero days) and later change to 90 days, the logs written during the unlimited period are preserved and not automatically deleted. This behavior protects historical audit data from unintended deletion when retention policies change. |
| 55 | + |
| 56 | +When the admin combines SQL auditing with immutable storage (WORM), the SQL retention setting must be longer than the immutable storage lock period. For example, if immutable storage has a 90-day lock period, RETENTION_DAYS must be set to at least 90 days to ensure audit logs remain available for the entire immutability window. |
| 57 | + |
| 58 | +For AI workload queries, the audit logs capture important context. When Contoso's fraud detection AI service connects using a managed identity, the BATCH_COMPLETED_GROUP records every query attributed to the managed identity's principal name. The audit log includes the server name, database name, application name, client IP address, statement text, duration, and success or failure status for each query. |
0 commit comments