As developers, we are up against odds that push us to make trade-offs in order to go into production on time. More often than not, it’s a race where security becomes an afterthought.
Securing Azure SQL Databases
Security mechanisms come in many flavors. It is a requirement that needs to be defined and implemented on day 1. These rituals (policies and practices), must become natural in your application life cycle management. Consider these as a starting point from which you can develop your own security practices.
- Do not use the default user for development, testing or for deployments
- Create a user specifically for deployments (can perform schema alterations)
- Create a user on a per application basis (cannot alter schema and has limited write access)
- Create a user for support investigations (this should be read-only)
- Create individual accounts for members of DevOps who will need to act upon the database. (these accounts should have limited write access)
- Reference data should be read-only (immutable versions) and should only be updated through deployments. This type of data can be stored in NoSQL data services to augment the overall scalability of your application.
- Enable Auditing for Azure SQL Database, this feature will give you deep insight in how the database is manipulated and about how it is used.
- Use SQL Database Projects to design, build, version and deploy
- Use schemas to segregate tenants, reference data, activity data and resouce (shared) data.
- Use schemas to keep track of ownership chaining
- Encrypt connection string passwords at rest
- Use strong passwords
- Set Trusted_Connection=False in the connection string. This forces server certificate validation
- Set Encrypt=True in the connection string to force the client to use SSL
- Ensure that you are covered against SQL Injection
- SQL Database Firewall rules should block everything except the consuming applications
- SQL Database Firewall rules should be set on both the Server and Database