What changed in Microsoft Azure SQL Database STIG V2R4V2R4 changes

Discussion

Authentication with a DODDoW-approved PKI certificate does not necessarily imply authorization to access Azure SQL Database. To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DODDoW-approved PKIs, all DODDoW systems, including databases, must be properly configured to implement access control policies. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications, a category that includes database management systems. If Azure SQL Database does not follow applicable policy when approving access, it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and in conflict with applicable policy.

V-255303 in V2R4

Title

The Azure SQL Database must be configured to generate audit records for DODoW-defined auditable events within all DBMS/database components.

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within Azure SQL Database (e.g., process, module). Certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DODDoW has defined the list of events for which Azure SQL Database will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities, or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions. Organizations may define additional events requiring continuous or ad hoc auditing.

V-255324 in V2R4

Discussion

The DODDoW standard for authentication is DODDoW-approved PKI certificates. Once a PKI certificate has been validated, it must be mapped to an Azure SQL Database user account for the authenticated identity to be meaningful to Azure SQL Database and useful for authorization decisions.

V-255336 in V2R4

Check text

Refer to the online documentation for the Azure SQL Database Audit configuration or the online documentation for the PowerShell cmdlet Get-AzSQLServerAudit using the links provided below. https://docs.microsoft.com/en-us/azure/azure-sql/database/auditing-overview#manage-auditing https://docs.microsoft.com/en-us/powershell/module/az.sql/get-azsqlserveraudit?view=azps-6.4.0 Use the following PowerShell script to check for the proper configuration settings: $FormatEnumerationLimit=-1 Get-AzSqlServerAudit -ResourceGroupName "Resource Group Name" -ServerName "Azure SQL Server Name" | Format-List -Property ServerName, *TargetState IfEvaluate the BlobStorageTargetState, EventHubTargetState, orand LogAnalyticsTargetState. Of the three, ensure at least one TargetState is enabled. If they are all disabled, this is a finding.

Discussion

To ensure sufficient storage capacity for the audit logs, the Azure SQL Database must be able to allocate audit record storage capacity. Although another requirement (SRG-APP-000515-DB-000318) mandates that audit data be offloaded to a centralized log management system, it remains necessary to provide space to serve as a buffer against outages and capacity limits of the offloading mechanism. The task of allocating audit record storage capacity is usually performed during initial setup of Azure SQL Database and is closely associated with the DBA and system administrator (SA) roles. The DBA or systemSA administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both. In determining the capacity requirements, consider such factors as the maximum storage account size for blob data is 5PB, the total number of users; expected number of concurrent users during busy periods; number and type of events being monitored; types and amounts of data being captured; the frequency/speed with which audit records are offloaded to the central log management system; and any limitations that exist on the Azure storage accounts ability to reuse the space formerly occupied by offloaded records.

V-255343 in V2R4