General Notes on Security in Azure SQL Data Warehouse

i’m still learning about azure sql data warehouse (adw, cause i’m lazy). adw is a deceptively deep topic. initially, you think that it’s just sql server, what’s the big deal. then you start to understand the underlying architecture and things get complicated. then you begin to understand the implications of the architecture and things get downright arcane. however, i’d like to talk about some relatively easy concepts around security in your azure sql data warehouse. for lots more detail, see the excellent documentation provided by microsoft.

firewall security

the single most important aspect of security in and around azure is the fact that for the public facing aspects (and the database stuff is public facing), there is a built-in firewall. this firewall is enabled by default and actually can’t be disabled, although you can choose to completely bypass it (why you would choose this is beyond me, but you can choose to eat lead paint too, so….).

let’s say that someone knew that you had an azure sql server (the container for both azure sql database (adb, lazy again) and adw, not to be confused with an instance of the sql server boxed product) out there named “securitytestdw.” if they knew anything about azure, they’d know that the string to connect to this is “securitytestdw.database.windows.net” which gives them an attack vector of sorts. however, with a hole in the firewall, the best they get is an error stating “your client ip address does not have access to the server.” in short, they’re not getting in if you haven’t allowed for their ip address.

now, can you shoot yourself in the foot and expose your server to all ip addresses? yes.

however, you’d have to intentionally do this. don’t. then you avoid the problem.

login security

you have two core choices on logins. first, you have to create a sql login at the server level for both azure sql database and azure sql data warehouse. you can’t remove this or disable it (to my knowledge, and i’ve tried), so make the password a good one (and don’t lose it). you can then create other sql logins, but this is not a recommended best practice. in fact, i wouldn’t do it at all unless i was forced because of some third party product (few of which currently support azure anyway).

the next choice, the preferred choice, is to set up azure active directory. with azure ad you get all the functionality you’re used to with your local ad. further, you can federate azure ad with your local ad to control and manage the logins from within your network. you also get multi-factor authentication with azure ad. we are talking real security here. read through the documentation on setting up authentication to get it right. you can do the whole thing using powershell commands , so there’s no excuse on automating it.

auditing

auditing and threat detection are services that you pay for. they’re off by default. you can set them for the server or for individual databases. you’ll have to add storage for the audit logs. the threat detection looks for sql injection and sql injection vectors are anomalous client logins. remember, if you set this for a server, it includes all the databases under by default. you can change the databases individually through powershell, or here in the gui:

conclusion

the basics of security within azure sql data warehouse are pretty clear and easy to understand. leave that default firewall in place and only poke the holes through it that you actually need to, and you’ll be fine. get azure active directory set up so that you can use that (along with multi-factor authentication) to completely lock things down. finally, you can pay for the audit and threat detection. with all these options, you can secure your azure sql data warehouse properly.