Voice of the DBA

Category: Editorial

  • PAAS

    Will we get a real platform in the clouds or just virtual machines?

    When I hear people talk about the “cloud” I often find that I have a different view of what “cloud” means.  What is a cloud? How is it structured? There are all sorts of definitions, but in my mind I have thought of the cloud as a service I can use, just as I use the web. My browser works with any kind of hardware, and software, as long as it handles the http spec.

    In my mind, that’s what I expect with a cloud database service. It conforms to what I expect in a SQL Server database, allowing me to deploy my data and objects, and expecting that I don’t need to worry about a database name, or configuring Windows logins, or even worrying about scaling up from 4 to 8 CPUs. I’d expect that the cloud would handle this fairly invisibly.

    There’s an acronym called PAAS, which is Platform as a Service, and it’s analogous to SAAS (Software as a service) and IAAS (infrastructure as a service). The idea is that an application platform exists in the cloud and you essentially upload your code, allowing the provisioning, scaling, and other details to be handled by the platform is interesting. This article talks about PASS solving lots of developers’ problems, but I think it’ s a little premature to think that this is the best solution for many types of businesses.

    I do hope that we find a way to smooth the deployment and access for our applications and services for both companies and consumers. It does feel that we spend a lot of time covering up for the inefficiencies in our entire application development and deployment life cycle. The cloud has some promise here, but it has to be more than a Windows host that runs on someone else’s hardware. It has to truly handle much of the complexity and abstract  us away from those details, in a secure, safe way.

    Steve Jones

    The Voice of the DBA Podcasts

  • Why Use the Principle of Least Privilege?

    This SQL Injection could be a problem in data entry

    SQL Injection is not the fault of the SQL Server. Brian Kelley pointed that out, and reminded me that SQL Injection isn’t an case of malformed SQL. It’s legitimate code, including SQL commands that we might use from any query connection, especially an administrative one. We regularly issue update and delete commands from our applications, and SQL Injection takes advantage of this to issue an update the we might not be expecting.

    Would you expect this input handwritten injection from an application? Or this table guessing attempt? You wouldn’t, but they can come through data entry in your application if the input isn’t well sanitized. Someone setting all your prices to $0.01 or all of your customers to “W3 0wnz U!” isn’t what you want to happen. You can’t necessarily prevent all of these patterns  or check for every permutation, but you can prevent things like ‘shutdown’ or ‘drop table’ from being run by your application. Even adding a new user to the database system isn’t something I would want to allow.

    Education is the key here. As Andy Leonard (blog | @AndyLeonard) would say, design patterns are important. When developers have an understanding of the issue, many of these things will be avoided. Having standard ways to begin building an application, checking for bad input, and setting up database users and permissions easily, should make this easy for anyone that wants to code against a database. We still have work to do here to build better frameworks, and ORM tools that require elevated permissions to the database are not the answer. They might become the answer, but they aren’t a better solution right now.

    Grant Fritchey wrote a nice piece about developers and DBAS, noting the need that we both have the same goals, but need to learn to communicate better.  This is one area where we ought to make an effort to communicate better, pass along education about security issues, and work to make life easier for developers to work with a database.

    That also means teaching them to work with the minimum privileges needed in order to make an application work, just in case someone plans on submitting some input you didn’t expect.

    Steve Jones

    The Voice of the DBA Podcasts

  • SQL Injection Everywhere

    I hope no one SQL Injects my washer

    I was doing the laundry the other day and thinking about SQL Injection. I have this fancy front load model that lets me load fabric softener and bleach into containers for release later, and it occurred to me that if my washing machine were connected to the Internet with some API, it’s possible someone could SQL Inject or buffer overrun a string that might release a stream of bleach into my colors.

    Not terribly dangerous, but it could be annoying, and it is exactly the type of hack some bored teenager would come up with. Then I started thinking about what else they might do. I wrote about the possibilities with cars recently, but what else could a hacker do in a connected world. What if someone could ignite my oven? Likely it wouldn’t do much more than cost me money. Turning up my fridge might make a mess of food, but not dangerous. However what if someone could turn off the lights when they saw you start running down the stairs?  That could be dangerous.

    What if they could remotely enable your sprinklers while you were at work. In some places that could result in a fine. Allowing that to happen a few times might get you arrested. Locking or unlocking your car doors (already a remote possibility) could endanger you. I’m sure there are more malicious possibilities I haven’t thought of, and as we move to a more connected world, I worry we will discover them only when some crime has been committed.

    I like the convenience of adding digital controls and remotes to more parts of our lives, but I do worry that we are doing so in a way that ignores security. Linking the convenience items of our lives to remote digital controls can be dangerous enough. Adding in more essential items, like heating, engines, etc., to the same control bus could be fatal.

    SQL Injection will likely be around for a long time, and it will get used in many new ways as more and more aspects of our lives are digitized. All developers should be aware of how an injection attack occurs, and code to be sure that we don’t allow any un-sanitized input into any of our databases, and that we also require separate authentication for the parts of a system that need more security.

    Steve Jones

    The Voice of the DBA Podcasts

  • The Standard Edition Wish List

    The SQL Server Platform. What does Standard Edition Need?

    I wrote recently about what might differentiate Enterprise Edition from Standard Edition, and there were some great responses from people. I don’t know if Microsoft will change the way they manage editions, but I know they are aware of the discussions on SQLServerCentral.

    This week, however, I wanted to turn things around. I’ve seen a few people talk about the reasons why Enterprise Edition makes sense, or what value you get. That’s good, but what about the people that are just stuck on Standard Edition? Corporate budgets are still tight, and many people might not even upgrade from their current version to SQL 11, even at Standard Edition.

    I wanted to see what might make the different for people in those situations. If there’s no hope for Enterprise Edition and you are even debating upgrading to the next Standard Edition version of SQL Server, answer this:

    What would you like to see in Standard Edition?

    If you had a wish list and could decide that one feature would get moved to Standard Edition, leave us a note in the discussion. Is there any one feature that would make a compelling case for your company to upgrade half their database servers to SQL 11?

    Enterprise has many things that you get with that large licensing cost: data compression, larger clustering limits, Resource Governor, partitioning, mirrored backups and more. It’s quite a list of features, but for me,  I’d like to have the ability with Resource Governor to limit the impact of certain groups of users on the server. I’d especially like to be able to throttle down the maintenance operations so they didn’t impact performance as much.

    Let me know this Friday what you really want to see in Standard Edition.

    Steve Jones

    The Voice of the DBA Podcasts