Just how secure is the data I put on SQL Azure

From Copying Databases in SQL Azure

Permissions

In order to copy a database in SQL Azure, your login requires the following permissions:

On both servers: The login must have the same login name and password on both SQL Azure servers.

On the destination server: The login must be a member of the server-level dbmanager role. Note: the server-level principal of your SQL Azure server is not a member of the dbmanager role, but automatically has the same permissions. For more information about managing logins in SQL Azure, see Managing Databases and Logins in SQL Azure.

On the source server: The login must be the DBO of the source database. Only the login that created the source database, the DBO, can copy that database to another database on the same server or on a different server.

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.