Voice of the DBA

Tag: security

  • How to change the SQL Server service account

    It’s easy. First you click here:

    serviceaccount1

    Then you find the SQL Server 2008 or 2008 R2 program group

    serviceaccount2

    Open those and then pick the SQL Server Configuration Manager.

    serviceaccount3

    You might get a UAC message asking if you want to make changes to the system, and say yes. This application can change service accounts, which is a sysadmin function. The screen basically looks like this:

    serviceaccount4

    If you right click the SQL Server entry, the database engine, you can select the properties, and you’ll get this screen:

    serviceaccount6

    On this screen, you can change the service account, and this is where you should change it. There are the three built in accounts in the top drop down (Local System, Local Service, and Network Service). I don’t recommend these. Instead, I recommend you create a new Active Directory Domain account (or local user account), assign it no rights, and then use the lower radio button to select the account.

    serviceaccount7

    Note that you do can search for it, and also you need to enter the user account. The password, while conforming to your domain policy, shouldn’t be one you use elsewhere. Make it a long, impossible to guess combination of stuff. You don’t need to recover this or log on as the user after you’ve assigned it to SQL Server. If you need to recover the password, just change it.

    A couple quick notes, on the Service Tab you can set the startup mode (Manual, automatic) for the database engine.

    serviceaccount8

    You can also change startup parameters here, on the Advanced tab.

    serviceaccount9

    That’s it, it’s easy, and it’s how you should change the service account for SQL Server.

  • Encryption Works

    If you have better encryption than this, it will work.

    I don’t know that the government hires the best people or they have the best tools to work with, but they have some expertise. There’s a short note from Bruce Schneier that full disk encryption (FDE) does appear to by preventing unauthorized access to computer systems by police in many cases.

    If you read the comments, there are all sorts of flaws and potential holes with encryption, which are valid arguments. However that doesn’t mean that you shouldn’t implement any encryption on your removable or portable drives, especially those in laptops. Those devices are like the locks on your home or car. They can be defeated by determined professionals, but all too often the casual criminal doesn’t bother if they are in place.

    Keep in mind many laptops are lost, stolen, or sold without wiping the drives. Most people that received the drive wouldn’t bother to try and decrypt it unless they were sure it had something valuable on the drive. Since it’s no guarantee that a laptop grabbed at Starbucks or from a car has valuable data, most likely the target is the hardware, not the disk contents.

    I think disk encryption is a good layer of defense in your security strategy and worth implementing. My laptops are encrypted, mostly because it’s an easy security mechanism, and I’m not always sure if something I have on there is sensitive enough to worry about. My recommendation is that you implement FDE if you can.

    You should also make sure you are backing up your data. Losing the laptop might not result in the release of sensitive data, but losing the data itself could be a major problem.

    Steve Jones

    The Voice of the DBA Podcasts

  • Not So Unbreakable

    Nothing is unbreakable

    There’s a report on Dark Reading that says some researchers think Oracle is not working on security as hard as they should. The proportion of security fixes has diminished, which some people think implies that they are not taking security as seriously as they should. The window of time between the disclosure and the patch has grown wider, which is troubling, especially when newer software displays vulnerabilities.

    I’ve been proud to work on SQL Server over the last 6 years from a security perspective as there have been very few security patches issued, and correspondingly, few vulnerabilities disclosed. It’s possible Microsoft has muzzled some researchers, but I doubt it. I would guess that if any serious security issues existed in SLQ Server 2005, 2008, or R2, we’d have heard about them. I think the security engineering process that is used for SQL Server has truly resulted in more secure software.

    It’s possible that Oracle faces a resource issue with all their acquisitions, but for a billion dollar company that employs over 100,000 people, they shouldn’t be having resource issues with their development process. It’s a question of accepting greater development costs in order to ensure their software is secure.

    This is one area where we ought to have independent security researchers that can discuss, debate, and disclose vulnerabilities, after a limited amount of time. That would help us at least understand the security risks we face, and perhaps pressure companies to build better software.

    Steve Jones

    The Voice of the DBA Podcasts

  • Layers of Security

    Every little bit of security helps

    I haven’t configured many firewalls in my time, but if I were doing that job, I’m sure I’d be included in this report that says half of all firewalls are improperly configured. Firewalls are confusing, complicated, and it’s incredibly easy to make a mistake when you are dealing with the complex rules of Windows networking and various application requirements. These days I call a friend, who’s a firewall expert, to do any changes for me, and let him implement the rules. It’s a slow, annoying process to watch, but I also understand that it is complex task, and he does a much better job than I’d do. Probably because he’s more patient.

    For the database administrator, however, this should be a wake-up call that lets you know you can’t rely on the firewall to protect you. If you have a small 3 machine, one subnet network, maybe, but in most enterprises there are many subnets and complex rules to implement. That means that your company might not be a soft chewy center protected by a hard shell. It might be a soft center protected by Swiss cheese that does little to limit the influx of unauthorized requests.

    Good security involves lots of strict policies, strong passwords, and many layers. Depending on someone else to provide security for your database instance is not only a bad idea, it could be a reason to remove you from your position. Good administrators, and developers, will ensure that they enable security on their servers, limit access to authorized users, and grant appropriate rights.

    It’s a good habit to get into, and it’s good practice for developing an application that will remain secured once it’s deployed.

    Steve Jones

    The Voice of the DBA Podcasts