The below are the best practices for security in order to avoid SQL injections etc .
*Minimize the number of sysadmins allowed
to access SQL Server.
*Only install required network libraries
and network protocols on your SQL Server instances.
*Ensure the physical security of each SQL
Server, preventing any unauthorized users from physically access your servers.
* As a DBA, log on with sysadmin
privileges only when needed.
*Use a Windows Authentication account to SQL
Server as a sysadmin.
* Create separate accounts for DBAs to access
SQL Server when sysadmin privileges are not needed.
*Assign the SA account a very obscure
password, and never use it to log onto SQL Server.
*Don't use the SA account, or login IDs
who are members of the sysadmin group, as accounts used to access SQL Server
from applications.
*Give users the least amount of
permissions they need to perform their job.
*Use stored procedures or views to allow
users to access data instead of letting them directly access tables.
*Use strong passwords for all SQL Server
login accounts.
*Don’t grant permissions to the public
database role.
*Remove user login IDs who no longer need
access to SQL Server.
*Disable the guest user account from each
user database by using REVOKE CONNECT FROM GUEST.
*Don’t use cross database ownership
chaining if not required.
*Never grant permission to the xp_cmdshell
to non-sysadmins until proper requirements.
*Remove sample databases from all
production SQL Server instances.
*Use Windows Global Groups, or SQL Server
Roles to manage groups of users that need similar permissions.
*Avoid creating network shares on any SQL
Server.
*Configure login auditing so you can see
who has succeeded, and failed, to login.
*Ensure that your SQL Servers are behind a
firewall and are not exposed directly to the Internet.
*In SQL Server 2005 and earlier, remove
the BUILTIN/Administrators group to prevent local server administrators from
being able to access SQL Server. In SQL Server 2008, the BILTIN/Administrators
group does not exist by default.
*Only give SQL Server service accounts the
minimum rights and permissions needed to run the service. In most cases, local
administrator rights are not required, and domain administrator rights are
never needed.
*Run each separate SQL Server service
under a different Windows domain account.
*When using distributed queries, use
linked servers instead of remote servers. Remote servers only exist for
backward compatibility.
*Do not browse the web from a production
SQL Server instance.
*Instead of installing virus/antispyware
protection on a SQL Server, perform scans from a remote server during a part of
the day when user activity is less.
*Add operating system and SQL Server
service packs and hot fixes soon after they are released and tested, as they
often include security enhancements.
*Encrypt all SQL Server backups with a
third-party backup tool, such as Red Gate SQL Backup Pro.
*Only enable C2 auditing or Common
Criteria compliance if required, as they add significant performance overhead.
*Consider running a SQL Server security
scanner against your SQL servers to identify security holes.
*Consider enabling SSL or IPSEC for
connections between SQL Server and its clients.
*If using SQL Server 2005/2008, enable
password policy checking.
*If using SQL Server 2008 in a high
security environment, consider implementing Transparent Data Encryption to
protect confidential data.
*If using SQL Server 2005, don't use the
SQL Server Surface Area Configuration tool to unlock features you don't
absolutely need.
*If using SQL Server 2005/2008 and you
create endpoints, only grant CONNECT permissions to the logins that need access
to them. Explicitly deny CONNECT permissions to endpoints that are not needed
by users.
No comments:
Post a Comment