I have very little social life, so I spent my weekend researching trends in database security. Part of my Saturday was spent looking at Microsoft’s security model for the Azure SQL database platform. Specifically I wanted to know how they plan to address database and content security issues with their cloud-based offering. I certainly don’t follow all things cloud to the degree our friend Chris Hoff over at RationalSurvivability does, but I do attempt to stay current on database security trends as they pertain to cloud and virtual environments.

Rummaging around MSDN, looking for anything new on SQL Azure database security, I found Microsoft’s Security Guidelines and Limitations for SQL Azure Database. And I downloaded their Security Guidlines for SQL Azure (docx). All 5 riveting pages of it. I have also been closely following the Oakleaf Systems blog, where I have seen many posts on secure session management and certificate issuance. In fact Adam Langley had an excellent post on the computational costs of SSL/TLS this Saturday. All in all they paint a very consistent picture, but I am quite disappointed in what I see. Most of the technical implementations I have looked at appear sound, but if the public documentation is an accurate indication of the overall strategy, I am speechless.

Why, you ask? Firewall, SSL, and user authentication are the totality of the technologies prescribed. Does that remind you of something?

This, perhaps?

 

With thanks to Gunnar Peterson, who many years ago captured the essence of most web application security strategies within a singe picture. Security minimalism. And if they only want to do the minimum, that’s okay, I guess. But I was hoping for a little content security. Or input validation tools. Or logging. I’m not saying they need to go wild with features, but at this point the burden’s on the application developer to roll their own security.

Share: