SQL Server Performance

Secure SQL Server - basic steps for any DBA

Discussion in 'Contribute Your Performance and Clustering Tips' started by satya, Jun 21, 2004.

  1. satya Moderator

    0. Learn from past mistakes. ***

    1. Limit number of DBAs: SQL Server's tight integration with Windows makes it far too easy to simply grant database administration rights to all domain administrators.

    2. Apply the rule of least privilege: Administrative access (and user-level access, for that matter) have the smallest subset of privileges necessary to carry out their job functions.

    3. Avoid hard-coded passwords.

    4. Get use to SQL Server Roles.

    5. Ensure to keep in touch with latest updates on service packs and hotfixes.

    http://www.microsoft.com/technet/security/prodtech/dbsql/default.mspx

    Satya SKJ
    Moderator
    http://www.SQL-Server-Performance.Com/forum
    This posting is provided “AS IS” with no rights for the sake of knowledge sharing.
  2. dtipton New Member

    The first step should be to give sa a STRONG password!

    ALthough I don't see sa/<blank> much anymore, I still have to argue with vendors about setting passwords like sa/sa or sa/admin for their third party packages.

    <<Limit number of DBAs>>

    Is it really a matter of limiting the number of DBAs or should it be ensuring that they logon using their own credentials (not Administrator or sa) and making sure auditing, both failure and success, is turned on. In other words, providing an audit trail.

    Out of curiosity, how many people are running SQL on a port other than 1433?


  3. ghemant Moderator

    Thats are really very good Tips Satya <br /><br />&gt;&gt; dtipton , i am running my box with port other than 1433 <br />though i am not an expert but some inputs from me ,other thing to be taken care is : <br />DISABLING NETBIOS<br />SET APPROPRIATE AUDIT LEVEL<br />File Systems must be NTFS<br />Windows EFS <br /><br />[<img src='/community/emoticons/emotion-1.gif' alt=':)' />]<br />Regards<br /><br /><br /><br /><br />Hemantgiri S. Goswami<br />ghemant@gmail.com<br />"Humans don't have Caliber to PASS TIME , Time it self Pass or Fail Humans" - by Hemantgiri Goswami<br />
  4. satya Moderator

    Out of curiosity, how many people are running SQL on a port other than 1433?
    All the SQL Servers have a differnt port to listenon at our end, I never allow even in the development environment using 1433.

    Having a blank password for SA account is disallowed since SQL 2000 SP3a (I think), so in this case DBA should stress for a password that can be managed without any easy guess by the other party.

    Never allow third party tools or tailor-made applications to use SA account in any case, to the extent allow DBO access.

    Satya SKJ
    Moderator
    http://www.SQL-Server-Performance.Com/forum
    This posting is provided “AS IS” with no rights for the sake of knowledge sharing.
  5. dtipton New Member

    ghemant you mentioned EFS, are you encrypting the data files and logs?

    Although I haven't tried this, I would think EFS would cause major slow downs.



  6. ghemant Moderator

    nope , not datafiles and logs ,only some vital documents on my boss's system. <img src='/community/emoticons/emotion-5.gif' alt=';-)' /> <br /><br /><br />Hemantgiri S. Goswami<br />ghemant@gmail.com<br />"Humans don't have Caliber to PASS TIME , Time it self Pass or Fail Humans" - by Hemantgiri Goswami<br />
  7. satya Moderator

    IN any case EFS has major part in degrading SQL server performance, always avoid SQL server related files for this encryption.

    One of the MS article refers
    NTFS is the preferred file system for installations of SQL Server. It is more stable and recoverable than FAT file systems, and enables security options such as file and directory ACLs and file encryption (EFS). During installation, SQL Server will set appropriate ACLs on registry keys and files if it detects NTFS. These permissions should not be changed.

    With EFS, database files are encrypted under the identity of the account running SQL Server. Only this account can decrypt the files. If you need to change the account that runs SQL Server, you should first decrypt the files under the old account, then re-encrypt them under the new account.


    Satya SKJ
    Moderator
    http://www.SQL-Server-Performance.Com/forum
    This posting is provided “AS IS” with no rights for the sake of knowledge sharing.

Share This Page