Database Server Authentication Security Policy:
SQL Server allows two different modes for security authentication: Windows Only Authentication and Mixed Authentication consisting of Windows and SQL Server authentication methods. While you'll fmd numerous articles, white papers and proposals touting Windows Only authentication over SQL Server authentication thanks to the improved security that comes with Windows authenticating the users, you'll probably end up defining security for installations that running under mixed mode for various reasons.
I do agree that you simply should do your best to maneuver your installations to Windows Only Authentication but this may probably be an extended fight on your part and as soon as you are doing get everything moved over, someone would require a 3rd party application installation that only works with mixed mode. Mandate that the utilization of SQL Server authentication be by exception only and need all access to your database be made with the utilization of Windows authentication.
Operating System Microsoft Windows Authentication:
Windows authentication leaves the method of determining if the users are who they assert they're up to the OS . you'll still need to grant database access to Windows users or groups and provides objects permissions to those logins. you only don't need to worry about the passwords or authentication methods employed by the logins. Some experts recommend that you simply group your Windows users into Windows groups and provides access to the group instead of individual users. I also recommend you are doing this if possible so as to ease the administration of the logins within SQL Server. it's easier to get rid of a DBA from a Windows DBA group than it's to travel into every SQL Server instance and take away the individual's Windows user. You can get more ideas from our official blog for Oracle tutorials.
There are mixed Authentication also available to manage:
Mixed authentication mode allows both Windows authentication and SQL Server authentication. While it's often recommended that you simply use Windows Only authentication, you'll find applications that haven't been updated to figure with Windows authentication. If forced to use mixed authentication thanks to legacy applications, you ought to still work to urge individual users, new applications, and existing database processes moved over to Windows Only authentication whenever possible. Letting the OS handle authentication will close several of the main vulnerabilities found in SQL Server security over the past few years.
SQL Database Server Service Accounts Security Policy also available to manage:
One of the foremost discussed issues when handling SQL Server security are the safety needs of the SQL Server Agent and therefore the SQL Server executive accounts. After handling numerous companies, I even have found several different methods for handling these accounts. Some companies simply create a website account and make that account a website admin. Problem solved, SQL Server has all the rights it must work within the domain. Other companies don't create an account for SQL Server in the least and easily run it under the LocalSystem account as no network permissions are needed by their installations and this is often the simplest method to use. Other companies create domain user accounts, on the other hand make that user a part of the administrators group on each SQL Server. I even have yet to figure somewhere that runs SQL Server under an area user account, but there are many companies that have found out there SQL Servers to run this manner . What you would like to work out is which method is that the one you ought to use?
Which Type of Account to Use to manage strong security of database server?
After recent discussions on the precise accounts needed for the SQL Server executive service and therefore the SQL Server Agent, i like to recommend that your SQL Server security policy mandate that SQL Server service accounts operate under one among two sorts of accounts. If the SQL Server installation doesn't got to access the network, use SQL Mail, use the SQL Server Agent mail functionality, inter-act with heterogeneous data sources, or is involve with replication then your SQL Server service accounts should run under an area user account with rock bottom possible set of permissions needed thereon server. For those installations that need one or more of these services listed above, then a website user should be created for every of the SQL Server service accounts. Both service accounts should have a separate domain users created for them because you'll got to assign different network or local privileges to every one. For taking more guidance then contact our remote DBA services team.
Another point in your policy should be that the names of the accounts you create shouldn't divulge their purpose. If I hacked into your system and had limited time to try to to damage, wouldn't I tend to consider trying to interrupt into accounts with the name of SQLServerAdmin or SQLServerAgent rather than an account with the name of an actual person. Sounds a touch far fetched, but believe the names of your accounts and the way easily it might be for somebody to interrupt in under these accounts with simple guessing of the account name. I even have been at quite one place that used SQLServerAdmin because the name of their SQL Server executive account. That user would be one among the primary account names i might try when breaking into a server.
You can use Enterprise Manager to review the accounts your SQL Server installation is running under.
For the SQL Server service account — Right-click on the server in Enterprise Manager and choose Properties. Click on the safety tab and you'll be ready to see the service account information at rock bottom of the tab page.
For the SQL Server Agent service account — Expand the Management folder and right-click SQL Server Agent. Click on Properties and choose the Connection tab. you ought to see the service account information at the highest of the tab page.
