Over the years that I’ve worked in technology, I’ve found that the 80/20 rule seems to apply pretty well to all the different areas that one can specialize in. It doesn’t matter whether you build PCs, work on the help desk, administer systems or develop software, the rule has pretty well been true for my career.
The 80/20 rule essentially says this: 80% of your job takes 20% of your time (or skills) and the remaining 20% of your job takes 80% of your time (or skills). It doesn’t matter if this is your daily work or a project that you are assigned. Most of your effort is in finishing the last details, or handling the most complex parts.
I’ve heard this joked about in software development as the rule of 90s as well, saying that the first 90% of a piece of software takes 90% of your time and the last 10% takes the other 90% of your time.
I built my presentation, The Top Ten Skills You Need for SQL Server, based on this rule. It includes the most skills that often solve questions I see asked at events or on forums. It seems that these ten skills along with the basics of performing them will solve most of your problems.
This is the story of Manna, the manager of a fast food restaurant. It’s a great read, and perhaps a little shocking. Manna is a piece of software, reading sensors, reacting, and letting employees know what to do with a synthesized voice through a set of headphones that the everyone wears in a fast good restaurant. In this tale, Manna evolves into a software system that is spread throughout many industries, essentially displacing managers and many workers at all levels in all industries. With the ability of these different “Manna” variants to communicate and negotiate contracts among themselves, the US devolves into an Orwellian nightmare place to live.
It’s a science fiction story, but the fears that it evokes are similar to those I’ve heard expressed from many people in the IT field across my two decades in this industry. A friend of mine left IT a decade ago, while working as an Exchange admin for a company with 50,000 mailboxes. He was sure in 5 years his job would be automated and eliminated. I knew a few people that moved out of DBA work in the early 2000s, after Microsoft released SQL Server 7 and 2000, with some marketing messages that the products didn’t require a DBA. A few years ago I heard a few people arguing that PowerPivot would kill most BI development jobs because it was so easy for end users to build their own analysis applications.
The one constant in all of those stories is that they never came true. I hope that Manna never comes true either, but I’m not worried. I’m very confident that if there’s one truth to all the computer development we do, it’s that we make constant mistakes and there is very little chance that we will be able to automate any significant percentage of IT jobs away.
We do build better software, and we do allow an administrator to manage many more systems than in the past, but we also seem to constantly eliminate most of the efficiencies in two ways. One is by adding many more systems and applications, and the other is by introducing more complex systems that create new problems that need to be solved.
The bar for IT knowledge needed is always being raised, but I just can’t see us getting to the point of having automated or robot DBAs running SQL Server in my lifetime.
It seems that there are relatively few very talented hackers that can break into your systems. The vast majority of data breaches and issues are from one of two attack vectors: social engineering or script kiddies. Social engineering is hard to fight, especially in large companies where everyone doesn’t know everyone. Script kiddies are more numerous since they don’t need any talent and merely deploy scripts written by others to attack your systems.
Recently it seems that there have been quite a few hacker attacks on systems, often using fairly simple SQL Injection techniques, that aren’t vandalism, and aren’t for profit. These attacks are motivated by hackers who are offended by the companies or organizations and are standing up for customers. That might be worrisome to DBAs and data professionals since you can’t hide data breaches if the attackers publicly post the data they’ve copied and you will certainly receive some of the blame for any breach of security.
In the past it seemed most attacks were DDOS attacks, which were embarrassing for IT folks, but not overly damaging in the long term. The last year or two, however, the attacks have turned to the copying of data and its release. Embarrassing for the company and potentially costing it business, but also worrisome for the system administrators who might be held accountable and possibly lose their jobs.
These days when there is never enough time to test and resources for security are sparse, what is a technical professional to do? One would hope that we would not be held responsible when we cannot perform adequate testing of applications, or we cannot implement strong security, but that is not what happens. We are blamed for being too slow to deploy applications, blamed if security impedes access in any way, and assuredly blamed if there is any successful hack of our systems.
In my mind each technology worker should educate themselves on recommended security techniques and request those techniques be implemented. They might not be, but the documentation that you attempted to do so might save your job.
SQL Server doesn’t give logins or users any rights by default. That means when you add a login or user to the SQL Server instance, the user cannot access any of the data or objects in the instance until you grant rights.
That’s not the model that so many people have learned in many applications where once a user has access, they can view anything. This leads to many administrators and developers thinking something is wrong when they create a new login and data cannot be accessed.
So they start by granting one of two rights initially: sysadmin or db_owner.
That’s a huge mistake, and leads to security issues down the road if the database contains any type of sensitive information.
The Principle of Least Privilege
There’s a security tenet that is known as the principle of least privilege. This essentially means that any user is only allowed to the minimum amount of access needed to accomplish their job. A few examples of what this means in practice:
If a user is supposed to only use the HR application to add new employees, they shouldn’t have administrator access.
If a web application provides read only views of sales data, the account it uses to access SQL Server should only have read (SELECT) access, and no rights to change data (no INSERT/UPDATE/DELETE)
A manager that only maintains an employee’s address information in a self service situation should have read/write access to the address data, but not the salary data, name data, or any other employee data.
A developer that is allowed to back up a particular database from the production systems to restore this on the development server should not have system administrator access to production. They should have backup rights only for the database(s) the developer needs.
An auditing application that writes to an audit table needs INSERT rights on the table, but not UPDATE, DELETE, or SELECT.
There are many more examples, but the basic idea is that you grant the rights needed, not every right.
In Practice
It feels like a lot of work to deal with roles, or think about the rights needed. It’s really not. Set up a role when someone needs access and grant the rights they need to that object. If they need more rights, grant more rights.
Voice of the DBA 