If you've ever given any consideration to IT security, you've probably heard of the layered security model. It's often explained with an onion analogy: at the center are your assets, surrounded by multiple layers (security controls) protecting them. Those assets are often your company's data in a relational database management system (RDBMS), such as SQL Server. One of the last lines of defense against unauthorized access to your data is the security configuration of the RDBMS. It is what lets the good guys in and keeps the bad guys out. This is not something to be taken lightly.
Unfortunately, database administrators often find their hands tied by egregious security demands from software vendors. Here is one such example as found in an installation document:
If you're not familiar with SQL Server, the "sysadmin" server role conveys the highest level of authorization available to a login. "db_owner" also conveys a high level of authorization. Both requirements are far more than what is necessary and violate the Principle of Least Privilege. While I strongly disagree with the install-time requirements, I can at least understand the argument: it's a one-time activity. But elevated permissions at run time are inexcusable.
According to Wikipedia, the company in question was founded in 1998. As recently as 2014, they had revenue of $6 billion. This is a mature company with a multitude of resources that should have known better. Their security choices are lazy, irresponsible, and dangerous. We deserve better than this from our software vendors.
A Widespread Problem
The poor security we see here is not an isolated event. It is prevalent throughout the software industry from the largest of companies to the smallest. And there is plenty of blame to go around. Software architects, developers, data modelers, quality assurance testers, devops, and others have numerous opportunities to address the problem before software is released. Sure, there's plenty of pressure to get products to market as soon as possible. But after years of neglect and countless releases, the act has worn thin.
We Must Change
To the software vendors: poor security casts your company in an unflattering light. It makes customers wonder if there were shortcuts or omissions elsewhere within your application. They may assume that your company is incompetent or indifferent. As a former software developer, I'm familiar with many of the challenges and difficulties you face. In spite of all this, you continue to create some truly amazing stuff. But some of us can't even consider your product because we are bound by compliance standards (HIPAA, PCI, SOX), strict organizational security standards, or simply the desire to do the right thing. Tightening up RDBMS security makes it easier for us to choose and buy your product.
To my fellow database administrators and data professionals: if you haven't already, take some time to review your existing RDBMS authorizations. If you find elevated permissions, see if related documentation allows permissions to be scaled back. If not, contact your vendor and question them as to why. When you are evaluating new software, don't get too caught up in the marvelous features that will make your job easier. Make sure you know the security requirements during and after installation. Again, if elevated permissions are required, talk to the vendor. Let them know your concerns.
To the RDBMS evangelists, community leaders, and bloggers: you can help too by emphasizing and teaching about RDBMS authorization and the Principle of Least Privilege. Anyone that's even tangentially involved in the application development life-cycle should have at least a rudimentary understanding of how RDBMS authorization works. I know it's probably more fun to spend your time on the latest and greatest features. I get it--we all love the feature du jour. But RDBMS authorization topics are badly under-represented in professional presentations, videos, blog posts, etc. Will you heed the call?