This article is contributed. See the original author and article here.

This blog post continues the series about Azure Security Center threat protection for SQL IaaS VMs. As you learnt in this blog post, Azure Security Center protects SQL servers hosted on either Azure VMs, Azure Arc and on-premises. This post will focus on SQL running on-premises and how to leverage ASC threat protection for SQL in this type of scenario.

 

SQL Server running on-premises

If your SQL server is installed in a Windows machine, located on-premises Windows and without Azure Arc, you really have two options for connecting it to Azure:

  1. Deploy Azure Arc
  2. Connect Windows machines to Azure Security Center without Azure Arc using Log Analytics agent.

Deploying Azure Arc

You can connect any Windows machine to Security Center, however, Azure Arc provides deeper integration across all your Azure environment. If you set up Azure Arc, you will see the SQL Server – Azure Arc page in the portal and your security alerts will appear on a dedicated Security tab on that page. The first and recommended option is to set up Azure Arc on the host. Please refer to this blog post for SQL VMs hosted on Azure Arc.

 

Connect Windows machines to Azure Security Center without Azure Arc

Security Center can monitor the security posture of non-Azure computers, but you need to first onboard these resources. If you choose to connect a SQL Server running on a Windows machine without using Azure Arc, you can use the option Add non-Azure servers from the Getting started blade or from the Compute blade as shown in ‘Image 1 & 2’.

 

Image 1: Add Non-Azure ServersImage 1: Add Non-Azure Servers

 

Image 2: Onboard servers to Security CenterImage 2: Onboard servers to Security Center

 

You will be redirected to Direct Agent page from where you can install appropriate Windows Agent.

 

TIP: You can connect any on-premises machine to Azure Security center by manually installing Log Analytics agent to extend the Security Center capabilities to servers running outside of Azure be it in on-premises or in other clouds. Just make sure the on-premises machine (In our scenario, SQL server) is connected to the relevant log analytics workspace. You can check this by navigating to Log Analytics workspace > Advanced settings > Connected sources > Choose either Windows/Linux server, as shown in ‘Image 3’.

 

Image 3: Confirmation of Connected SourcesImage 3: Confirmation of Connected Sources

 

Once you have the Log Analytics agent installed, Azure Security Center will start scanning the machines and flag prioritized list of recommendations accordingly, if not configured according to security best practices.

Note: for Step-by-Step instructions to onboard a non-azure computer, please refer to this article.

 

Validating SQL threat detection

When Azure Security Center identifies the pre-attack you should be able to view the alert in the Security alerts section as shown in ‘Image 4’

 

Note: Make sure you have non-azure environment selected from the Filter.

 

Image 4: Security Alerts snapshotImage 4: Security Alerts snapshot

 

Conclusion

Alerts are designed to be self-contained, with detailed remediation steps and investigation information in each one. You can investigate further by using Azure Security Center and Azure Sentinel capabilities for a broader view:

  • Enable SQL Server’s auditing feature for further investigations. If you are an Azure Sentinel user, you can upload the SQL auditing logs from the Windows Security Log events to Sentinel and enjoy a rich investigation experience. Learn more about SQL Server Auditing.
  • To improve your security posture, use Security Center’s recommendations for the host machine indicated in each alert. This will reduce the risks of future attacks.

What are you waiting for? Go ahead, leverage Azure Security Center to protect your SQL IaaS VMs.

 

Special thanks to:

Yuri Diogenes, Senior PM, CxE Security – ASC Team for reviewing this post.

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.