Detecting Misconfigurations on Azure Database Services

Microsoft Azure introduces multiple database services in different models. These services allow different levels of control over the database and operating system management. However, the basic challenge remains the same: misconfigurations can expose the information stored within the database. With a database typically storing sensitive information, any leak can spell catastrophe  with heavy fines and/or PR nightmares.

The Dome9 Compliance Engine provides an easy yet flexible way to detect these misconfigurations. Powered by Dome9’s innovative Governance Specification Language (GSL), the engine allows you to customize testing for misconfigurations,  and adapt them to your organizational policies and best practices. This article will present some examples of tests that can be applied on Azure Database Services, helping to keep your organizations name off the “2018 infamous data breaches” list. To read more about how we secure Azure environments, check out our recent blog on Azure Tamper Protection!

Azure PaaS and IaaS databases

Azure provides database services in different models.

– Azure SQL Database is an SQL database offered in a platform-as-a-service (PaaS) model. It is optimized for software as-a-service (SaaS) application development.

– SQL Server on Azure Virtual Machines is an infrastructure-as a-service (IaaS) database solution. It is a- SQL Server installed and hosted in the cloud on Windows Server Virtual Machines (VMs) running on Azure. It offers full control on SQL Server and the operating system.

For more information on the different models see here.

Keeping Azure database services private

As databases tend to contain very sensitive information, we would like to keep them as private as possible. The first step is making sure that the database is not exposed to the internet in any way:

SQLServer should have isPublic = false


The next step is establishing a protection against insider threats. Exposing the database to the entire Azure virtual network is bad practice and the following Dome9 GSL rule can detect such configurations:

SQLServer should have isAzurePubliclyAccessable = false


More fine-grained firewall rules can be tested, such as validation of specific IP ranges or enforcing the maximal size of IP ranges that can access the database:

SQLServer should not have firewallRules contain-any [ numberOfAddressesInRange > 50 ]


Enforcing encryption and key management best practices

Azure provides database encryption capabilities. By using encryption, you can  ensure that even by gaining network access, the infiltrator will not be able to read the data  without the proper key in hand.

The following Dome9 GSL rule helps you ensure that you do not forget to activate the encryption capabilities:

SQLDB should not have encryption.status='Disabled'


Using a key management system is recommended  to provide increased security and control over keys and passwords. This would also help in making sure that applications have no direct access to the keys. Azure provides Key Vault, a key management service designed for these purposes. For keys that were generated by Azure, Microsoft ensures rotation at least every 90 days. For keys created by the user, key rotation needs to be enforced as well. Here is a GSL example that validates 90 days key rotation:

SQLDB should have encryption.serverKeyType='AzureKeyVault' and encryption.serverKeyCreationTime after(-90, 'days')


User access restrictions

While access to databases in production environments is done using applicative users, administration is still needed from time-to-time. Dedicated power users should be created for these tasks, and restrictions of a default administrator access can be enforced:

SQLServer should not have administratorLogin like '%admin%'


Microsoft recommends using Azure Active Directory services to manage identities whenever possible. Enforcing the existence of active directory administrators could be done using a simple rule created by Dome9 GSL:

SQLServer should have adAdministrators


Additional rules can enforce other access related configurations, such as the number of users with access privileges.

Validating architectural configurations

Not only can security aspects be validated using the compliance engine, but databases configuration can be validated as well. Enforcing architecture best practices on Azure databases will ensure the service continuity. Let’s explore some examples.

Azure SQL Databases elastic pools are a simple, cost-effective solution for managing and scaling multiple databases that have varying and unpredictable usage demands. Dome9 can help to make sure that databases are assigned into elastic pools:

SQLServer should have elasticPools


Replication is often used to ensure rapid recovery from a disaster. Proper configuration of failover can be validated:

SQLServer should have failOverGroups length()>0


Additional configurations can be monitored using the Dome9 Compliance Engine as well, including the SQL Server database version, state and tagging.

Continuous database compliance on Azure

Keeping databases secure- is an ongoing effort. The smallest mistake could lead to attackers taking advantage of the vulnerability and extracting sensitive information. In this article you only got a taste of the countless configuration monitoring that could be easily written with GSL in the Dome9 Compliance Engine. No scripting knowledge is required to write the logic you want to monitor. The Dome9 Compliance Engine  will run the rules continuously, reporting back on any configuration that is not aligned with the best practices and organizational policies. To read more about the continuous compliance capabilities, check out our blog post here, or visit www.dome9.com/compliance