How to secure SQL Server being accessed from the DMZ We have an internal stand alone SQL Server 2014 default instance that needs to be accessed from an application server residing in a DMZ.   The application team wants to open the default 1433 port so connections can be made to the SQL Server.

Is there a best practice for securing the SQL instance when it is going to be accessed from an application server within a DMZ?
For best practices on SQL Server security there are hundreds of pages of documentation from the DoD ("Security Installation Checklist" and "Security Checklist") and CIS ("SQL Server Security Benchmark").

This aside a more realistic approach is rooted in common sense.


Your firewall should only allow access from the specific IPs in the DMZ only directly to the IP of the database in your main domain. This is to reduce the attack surface.
The logins being used to access the new data should be specific to this purpose, and only have the permissions required; i.e. read or write (not necessarily both).
And as your server is used for other things you'd need to review its existing security setup.


What existing logins are there that may be able to access the data? For example sysadmin role users, users that can restore backups, users that are in msdb agent roles which can often be used to escalate privileges.
What administrator users are on the server itself? Anyone who has this will be able to access SQL Server and they can't be stopped, only slowed.
Is it patched (Windows and SQL)?

And what is in the data? Is it private? Could it provide insiders/competitors with financial advantage, or could an attacker use it to further penetrate a network? Those answers determine what other functionality you may need to put in place to safeguard it, and may require nothing special, or may require AlwaysEncrypted or encryption at rest for the disk files and backups.


But primarily once this is all together you put this in a document/email and get someone of appropriate authority to accept the risk in order to protect yourself. You are unlikely to be able to stop all risks, only reduce attack surface and add layers to the security onion.