Securing a Payroll Database

  • We have a request to set up a new server for a single use db - payroll. Finance wants the server/db super-secured. They don't even want IT to be able to access it. 

    Is it possible/practical to secure a SQL database such that the IT admins cannot even access the data?  Is there a doc someplace that outlines steps to take for such a level of security?


  • I don't know of a document that spells this out but the bottom line is this: the only way to keep IT out is to set up a separate instance of SQL server and then not grant sysAdmin access for that instance of SQL server to anyone in IT. IMHO the finance guys need to trust someone in IT. Your only practical alternative is to have a "Finance IT" person. Personally, I wouldn't trust an accountant to administer even an MS SQL database without demonstrating some basic competency as a SQL Admin first. SQL Server is a lot more complicated than an Excel spreadsheet.

  • i know. it's not practical but that's what they are asking. i have to placate them with some info on the subject.

    seems like there should be a way to secure the data but still allow administrative tasks to be performed on the database by IT. i think there is but i haven't hit on it yet.



  • 1. Isolate the machine in its own environment or network.

    2. Configure instance of SQL Server not to listen for network protocols

    3. Remove login "BUILTIN\Administrators".

    But you have to trust someone who has experience to administer the server and database.

  • Thanks for the info, Allen.  Regarding #2, can you expand a little? If you do this, how does the payroll app communicate with the database? Or are  you saying that they should use this machine exclusively for the app (for the front-end as well)?

  • Something more.

    Patch upadte.

    Run SQL Server service as local sysytem a/c.

    Disable MSDTC if you don't need it.

           Disable the Windows guest account.

    ·       Rename the administrator account.

    ·      Enforce strong password policy.

    Enable C2 audit.

    Protect your database backup.

    Verify Everyone Group Does Not Have Permissions for SQL Server Files

    Encrypt your data files using Encrypting File System (EFS).

    ·       Restrict access to the SQL server port.






  • Finance is being unrealistic.  If they expect IT to offer any support then at least on IT person has to have Admin access to the server and to the database.  You definitely dhould remove Builtin\Administrators account.

  • There is a fixed database role called "db_backupoperator".  Can this be used for the backups such that the system administrators (responsible for backups here) cannot access the database?  Is that it's purpose? 

  • I had the same request last fall so what I did was setup a new instance with only the payroll user (it's a SQL account not NT, I'm sure not all payroll programs are like this but our's is).

    There are no other NT accounts or groups setup, the BuiltIn/Administrators has been removed from sysadmin role.

    So basically there is me(the only DBA), the sa account(password resides only in my head and a sealed envelope with the HR manager) and the payroll user that can access the instance.

    Then to instill confindence about the security I enabled C2 auditing. This only works if you have the disk space for the trace files and time to monitoring it.

    They still have to trust me but the C2 auditing tracks every login and data access no matter who does it.

    It may not work for you depending on resources but my payroll department is happy with the solution.



  • It's an ugly problem with no easy answer. In the NT world you have auditing and the concept of ownership - the domain/enterprise admin can be locked out of viewing files but can change that by taking ownership and then changing it - something easy to see in the audit logs. I think the separate box approach is pretty common. Patching and backup would be the biggest concerns, something that can be addressed without that much headache.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply