Sugerir tradução
 
Outras sugestões:

progress indicator
Sem sugestões.
TechNet Magazine > Home > Todas as edições > 2009 > TechNet Magazine Maio 2009 >  Problemas de segurança de servidores SQL comuns...
Exibir Conteúdo: Lado a LadoExibir Conteúdo: Lado a Lado
Este é um conteúdo traduzido por máquina que os membros da comunidade podem editar. Incentivamos você a melhorar a tradução clicando no link Editar associado a qualquer sentença abaixo.
Security
Common SQL Server Security Issues and Solutions
Paul S. Randal
 
At a Glance:
  • Physical and network security
  • Attack surface, service accounts, and least privilege
  • Authentication, authorization, and SQL injection
  • Disaster recovery and auditing

Anyone who's been around the IT industry knows that security is a hot topic. After all, a company's data is one of the most precious assets it has and protecting that data is critical. As I was planning what to write for this security issue, I tried to determine which security feature should have an entire article dedicated to it. But then I started to think about the burgeoning numbers of "involuntary DBAs" (those IT pros who inadvertently wind up responsible for a SQL Server instance) and the great response we had to the Top Tips for Effective Database Maintenance article from the August 2008 issue. It struck me that what I should do is write an article that covers common SQL Server security issues—a sort of primer to better security for your SQL Server instances.
An article that describes all the security problems you should be looking at would be a whole magazine in itself, so I canvassed my fellow SQL Server MVPs (and my wife) for input as to what I should include. I settled on providing the top 10 security areas I think you should worry about if you're not a security-savvy DBA and suddenly find yourself responsible for a SQL Server instance and associated application. (Remember that this is by no means an exhaustive list.) For each issue, I've given a short overview of the problem, advice on how to mitigate it, and a link to more detailed information.
All the links to Books Online are for the SQL Server 2008 versions, but each Web page links to the SQL Server 2005 version as well. Wrapping up the article, I provide links to the main white papers and Books Online sections for security for SQL Server 2005 and SQL Server 2008.

Physical Security
It's imperative that you don't just consider SQL Server security itself, but all the layers that must be traversed to get to SQL Server in the first place. For this concept of layered security, often called "defense in depth," you don't just secure one layer, but consider the entire system.
The most obvious first consideration is the physical security of the machine running SQL Server—this layer, however, is often overlooked or is the subject of complacency. I'm not referring simply to whether the machine can be stolen or not, but also to physical access to things like the storage system hosting the database files, the backup tapes, and any servers hosting redundant copies of the database. Only those people with an actual need to physically touch these objects should have access to them; anyone who needs temporary access should be accompanied and monitored.
A less obvious consideration is the security of the desktops of the people who have high-privileged access to SQL Server. If someone has sysadmin access to SQL Server but they leave their Windows desktop unlocked, then all the security in the world isn't going to prevent someone walking past the unattended system from potentially accessing sensitive data. A more insidious problem would be if someone walked past and changed some data—for instance, a dishonest employee who knows the schema of the human resources database and tries to undetectably change a salary.
There's a very interesting TechNet white paper (including a slide-deck and webcasts), titled " Physical Security at Microsoft ," which describes how Microsoft manages the physical security of its many servers.

Network Security
Although your servers may be physically inaccessible, they're most likely connected to a network of some kind. This could be just an isolated company LAN with no outside connections, or it could be a direct connection to the Internet. No matter what the situation, there are some things you need to consider:
  • Ensure that the Windows server has proper network security configured.
  • Decide which network protocols to allow, and disable any that are not required.
  • Ensure there is a firewall set up (such as Windows Firewall) and configure it to allow access to SQL Server (as shown in Figure 1 ).
  • Decide whether to encrypt connections to SQL Server and configure appropriately.
  • If Kerberos will be used, register a Server Principal Name. Kerberos is an authentication mechanism that underpins Windows authentication (which I describe later in this article), but it is poorly understood. A clear and concise explanation was provided by Rob Greene, a Support Escalation Engineer, in the blog post " Kerberos for the Busy Admin ." I recommend checking it out.
  • Decide whether to use the SQL Server Browser Service to help clients find installed SQL Server instances, and decide whether you want to hide some instances. Hiding an instance means client applications and users will need to know the connection details of the SQL Server instance, but it prevents people from trawling the network to look for SQL Server instances.
Figure 1 Configure Windows Firewall to allow TCP access to SQL Server
All these tasks (and more) are explained in SQL Server 2008 Books Online, starting with the topic Server Network Configuration . There's also a good section on Client Network Configuration .

Attack Surface Minimization
The more services and features that are enabled, the more attack surface or surface area there is for bad guys to attack. SQL Server 2005 took the "off by default" strategy—features with security implications are disabled by default and are only enabled by the DBA when required. (This process of enabling and disabling services is commonly called surface area configuration.)
A prime example of a feature that you may want disabled is xp_cmdshell, which provides a way of executing commands on the host Windows system from within the context of a SQL Server instance. If an intruder compromises the SQL Server instance, and the SQL Server service account has elevated Windows privileges, xp_cmdshell can be used to gain access to the Windows system, too.
There are a variety of methods for surface area configuration. Both SQL Server 2005 and SQL Server 2008 support the SQL Server Configuration Manager for configuring services and network protocols. Both also support the sp_configure stored procedure for configuring database engine features and options. As an example, this code will disable the xp_cmdshell feature:
-- To allow advanced options to be changed
EXEC sp_configure 'show advanced options', 1;
GO
-- To update the currently configured value for -- advanced options
RECONFIGURE;
GO
-- To disable xp_cmdshell
EXEC sp_configure 'xp_cmdshell', 0;
GO
-- To update the currently configured value for this -- feature
RECONFIGURE;
GO
The graphical methods of configuring database engine options and features are quite different between the two versions. SQL Server 2005 introduced the SQL Server Surface Area Configuration (SAC) tool. This allows you to easily make changes. Figure 2, for instance, shows how you can disable xp_cmdshell using SAC.
Figure 2 Disabling xp_cmdshell using SAC in SQL Server 2005
In SQL Server 2008, SAC was completely removed and the functionality subsumed by the Policy-Based Management feature. You can find more information on this in the SQL Server 2008 Books Online topic " Administering Servers by Using Policy-Based Management ." Figure 3 illustrates creating a condition to check that xp_cmdshell is disabled. Once configured, policies can target both SQL Server 2005 and SQL Server 2008 instances and can even be "applied," allowing you to essentially change the setting with one click.
Figure 3 Creating a Policy-Based Management condition in SQL Server 2008

Service Accounts
SQL Server runs as one or more services on Windows, and each service needs to have a Windows account that is used to run the service. The account needs to have access to various resources on the Windows system (such as the network and various file system directories). The best practice is for the account to have the least possible privileges required to allow SQL Server to operate correctly. This is part of what is called the principle of least privilege, which states that a system can be made more secure by granting a user or process only those privileges required and nothing more.
As such, a SQL Server service account should not be a high-privileged account (such as Local System or Local Administrator) because if SQL Server is compromised, there is the potential for the Windows system to also be compromised. The services typically run under a built-in account called Network Service, but if SQL Server requires access to other domain resources, a new domain user account should be created with the minimum privileges and resource accesses required. The SQL Server 2008 Books Online topic " Setting Up Windows Service Accounts " provides a comprehensive list of service accounts, required privileges, and resources. Note that if you must change a service account (or anything about it), you should always use the SQL Server Configuration Manager to ensure that all the necessary configuration changes are properly made.

Restricting Use of Administrator Privileges
The more exposure the SA login or the sysadmin fixed server role has, the more potential there is for a security breach—or an accident. There are a few best practices to follow.
Minimize the number of people who have access to the SA account and restrict the membership of the sysadmin role (and other privileged roles) so only those people who really need sysadmin privileges have them. Don't give out the SA password to anyone who wants temporary access to SQL Server or to a SQL user who wants to perform some quick task. In these situations, create a new SQL login and grant whatever privilege is required.
It's better to have people as members of the sysadmin role rather than using the SA account. This way, you can remove a user's login without having to change the SA account password. If you take over an old server and you have no idea who had access to it before, change the SA password so you're in control.
One issue that provokes debate is whether to remove the Windows BUILTIN/Administrators group from the sysadmin role (it's added by default). Should a Windows admin be able to query the HR database? Or does your company explicitly trust all administrators to have integrity and honesty? If you decide to remove it, proceed with care. This is especially true in a clustered environment where if you don't take the correct steps, your SQL Server may not start. For more information on this and other clustering issues, see the Knowledge Base article " Clustered SQL Server Dos, Don'ts, and Basic Warnings ."
For those who do have sysadmin access, encourage them not to log in with high privileges unless absolutely necessary—give each of these users two logins, one privileged and one not. Using the nonprivileged account by default helps minimize the potential for costly mistakes, and also reduces the likelihood that an unlocked Windows terminal will have a window with sysadmin privileges open on it. Remember: defense in depth!
The last point I'll make here is to avoid having applications that require sysadmin privileges. Unfortunately, this is a common and unavoidable bad practice with some applications, but you should avoid this practice in homegrown applications and complain to any application developers that require sysadmin privileges.

Authentication
There are two authentication modes available: Windows Authentication and mixed-mode (which is Windows authentication combined with SQL Server Authentication).
Windows Authentication uses network/domain accounts to validate the Windows account being used to connect to SQL Server. If this is selected during setup, the SA account is created with a randomly generated password but effectively disabled. Immediately after installation, you should change the SA password to a strong and secure password but continue to leave the account disabled unless absolutely necessary.
SQL Server Authentication relies on each user having a defined SQL Server account and password stored in SQL Server. And, of course, this means that the SA account is enabled and must have a defined password. With SQL Server authentication, users have at least two user names and passwords (one for the network and one for SQL Server). It is generally recommended that you only use Windows Authentication when possible, as it is a more secure solution. The Books Online topic " Choosing an Authentication Mode " explains this in more detail, along with how to change the authentication mode.
If SQL Authentication is used, then all users should have a strong password—one that is complex enough to be resistant to being guessed by a password-cracking program. This is especially important for high-privileged accounts, such as SA and members of the sysadmin role. (One of the most common yet worst practices used to be to have a blank SA password. Fortunately, as of SQL Server 2000 SP3, that is not possible.)
Passwords should also be changed regularly and your company should publish corporate policies to help employees use secure and strong password best practices. For an overview of best practices for creating and protecting strong password, see the article " Strong Passwords: How to Create and Use Them ." You can incorporate these policies into a corporate policy.
If SQL Server 2005 or SQL Server 2008 is running on Windows Server 2003 or later, it can make use of the Windows password policy mechanisms to enforce complexity and expiration policies. The SQL Server 2008 Books Online section called " Password Policy " has information about support for strong passwords and various password policies in SQL Server.

Authorization
As I've already mentioned, one of the tenets of securing systems is to use the principle of least privilege. While this applies directly to admin-level privileges, it also applies to permissions for regular database users. A user in one database should (probably) not be able to access data in another database. The owner of one set of tables should not be able to mess with someone else's tables. Users should only be able to access the data they are supposed to access, and even then they should only be able to perform required actions on the data (for instance, SELECT but not UPDATE or DELETE).
All of this can be accomplished within SQL Server by a comprehensive, hierarchical permissions system where users or roles (called principals) are granted or denied certain specific permissions on certain resources (called securables) such as an object, schema, or database. An overview of the SQL Server permissions hierarchy is illustrated in Figure 4. This also implies that you follow the principle of least privilege. For example, don't make all database developers members of the db_owner role. Restrict permissions to the public role and only grant permissions to the lowest level (user or role) to minimize direct access. A full discussion of best practices for permissions is beyond the scope of this article, but SQL Server 2008 Books Online includes a section called " Identity and Access Control (Database Engine) " that offers drill-downs into all the concepts.
Figure 4 The SQL Server permissions hierarchy
To allow more granular permissions and better separation of roles within a database, SQL Server 2005 introduced user-schema separation, where schemas are independent of database users and are just containers of objects. This allows many behavioral changes, including more fine-grained precision for managing permissions. (Four-part naming follows the format server.database.schema.object in SQL Server 2005 and SQL Server 2008—the format was previously server.database.owner.object.)
For example, a schema can be created with database developers given CONTROL permissions. They can CREATE, ALTER, and DROP any objects within the schemas they control but they have no implied permissions to any other schemas within the database and they no longer need db_owner rights for database development. In addition, user-schema separation allows database users to be dropped without having to recode all of the related objects or the application with a new user name—the objects are members of a schema and they are no longer tied to the object's creator.
It's a best practice to use schemas for object ownership because of these reasons. More information can be found in SQL Server 2008 Books Online in the topic " User-Schema Separation ."
Another way of preventing users from doing things they're not supposed to do is to disallow direct access to your base tables. This can be done by providing stored procedures and functions that are used to encapsulate, control, and isolate operations like updates and deletes, and by providing views that allow controlled and optimal selects.

SQL Injection
One of the most common methods of gaining unauthorized access to data is to use a SQL injection attack. SQL injection can take many forms, but the primary approach takes advantage of code that uses dynamically constructed strings and "injects" unexpected code into the construct. For example, the following injection attack takes advantage of poorly written logic for validating user input to trick SQL Server into accepting input by including escape characters in the input string. Although contrived, this example highlights what can happen when code dynamically constructs strings using input that is not thoroughly validated:
DECLARE @password VARCHAR (20);
DECLARE @input    VARCHAR (20);
DECLARE @ExecStr  VARCHAR (1000);

SELECT @password = 'SecretSecret';

-- assume application gets input 'OR''='
SELECT @input = '''OR''''=''';

SELECT @ExecStr = 'IF ''' + @password + ''' LIKE ''' + @input + ''' PRINT ''Password Accepted''';

EXEC (@ExecStr);
GO
If you run this code, it will print the phrase "Password Accepted" even though the user input clearly did not match the password string. The user input contained an escape sequence that changed the Transact-SQL logic because the input was not properly parsed and checked.
SQL injection should not be a problem for a well-written application and there are some specific tricks (like using QUOTENAME to delimited identifiers). But if you inherit an old application (or maybe a homebrew project that became a corporate application), you should specifically test to see whether it is vulnerable to SQL injection attacks. There are a variety of techniques available to mitigate SQL injection attacks. SQL Server 2008 Books Online has a comprehensive section, starting with the aptly named topic " SQL Injection ."

Disaster Recovery
How much you need to worry about this depends on what your downtime and data loss requirements are. (If you haven't already defined these requirements, you should!) Security problems can occur at many levels. There are some concerns when disaster recovery involves failover to another SQL Server or the need to restore a database containing encrypted data.
In the first case, problems occur when the logins necessary to access the database have not been duplicated on the failover server—for instance, when using log shipping or database mirroring. If the database fails over to the mirror instance and the application tries to connect using a specific login that does not exist on the mirror server, the application will receive the 18456 error "login failed". The logins are part of the application ecosystem and must be defined on the instance hosting the database. Knowledge Base article 918992 " How to Transfer the Logins and the Passwords Between Instances of SQL Server 2005 " explains how to do this, and I will discuss troubleshooting error 18456 in a moment.
In the second case, problems occur when the database backup contains encrypted data and the encryption key (or keys) used to encrypt the data were not backed up or are not available in the SQL Server instance where the database is being restored. The best case here is that only some of the data in the database is encrypted and so only that subset of data cannot be accessed. The worst case scenario is that the entire database has been encrypted using Transparent Data Encryption (TDE) in SQL Server 2008. In that case, if the server certificate used to protect the database encryption key was not backed up or is not available, the entire database cannot be restored and the following errors will be returned:
Msg 33111, Level 16, State 3, Line 1
Cannot find server certificate with thumbprint
'0xFBFF1103AF133C22231AE2DD1D0CC6777366AAF1'.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
Of course, that's the point of TDE—that someone happening across a stray backup of the encrypted database can't restore it and access the sensitive data. But if the data is yours, and you need to access it, then you must have the server certificate available or the data is lost.
Encryption is a huge topic in itself and has comprehensive coverage in SQL Server 2008 Books Online, starting with the " SQL Server Encryption " section. You can also watch me demonstrate TDE and successfully restore to a second instance in an accompanying video screencast available at .com/tips.

Auditing
One of the most important things you should do to improve the security of a system is to implement auditing. With this, you'll know who's doing what. This may even be mandatory, depending on the nature of your business.
At the very least, you should audit both failed and successful logins so that you can tell if, for instance, five failed login attempts were followed by a successful one. Then you know when someone is trying to break into your SQL Server instance (and with which login). Figure 5 shows configuring login auditing through the Server Properties dialog box in SQL Server 2005 Management Studio. Failed logins are audited as message 18456 in the error log and the error state gives the reason for the failure. The best description I could find of the different states, as well as a long discussion about troubleshooting them, is in a post from Il-Sung Lee on the SQL Protocols blog titled " Understanding 'Login Failed' (Error 18456) Error Messages in SQL Server 2005 ."
Figure 5 Confi guring login auditing in SQL Server 2005 Management Studio
Comprehensive auditing of all actions is difficult in SQL Server 2005 (and well beyond the scope of this article). It involves various triggers and SQL Trace. In SQL Server 2008, auditing was vastly simplified with the introduction of a new feature: SQL Server Audit. This is covered in a recent, very detailed white paper titled " Auditing in SQL Server 2008 ." In the accompanying video screencast, I demonstrate SQL Server Audit. You can get details on the other auditing tools in the SQL Server 2008 Books Online " Auditing (Database Engine) " section.

Summary
That's a lot of topics and a lot of links, but that was the point of this article. I wanted to provide an overview of important security topics that you must consider when you're a DBA who isn't used to dealing with security.
There are some tools that can help you check your system for common security vulnerabilities. The first is the Microsoft Baseline Security Analyzer (MBSA) utility that will check for Windows, network, file system, and even some SQL Server 2000 and SQL Server 2005 security issues. The latest version is Microsoft Baseline Security Analyzer 2.1 . Again for SQL Server 2000 and SQL Server 2005 only, there is a SQL Server–specific tool called the Best Practices Analyzer (BPA). This uses a pre-defined list of rules to check your SQL Server configuration and flags any problems (for instance, a blank SA password).
Neither of these tools works with SQL Server 2008. In fact, BPA will not be released for SQL Server 2008 at all and has been replaced, along with the short-lived SQL Server 2005 Surface Area Configuration tool, by the new Policy-Based Management feature I discussed earlier. Part of the reason for this replacement is that BPA and SAC were read-only tools to help you find problems—they could not fix problems. Policy-Based Management offers many corrective choices and it can even be used to target SQL Server 2000 and SQL Server 2005 servers.
Of course, you should always be using Windows Update to ensure that new security patches and service packs are downloaded for you to install at an appropriate time—this is the best way to stay up to date with the latest updates. Installing these without taking downtime is beyond the scope of this article, but some ideas were presented in the December 2006 SQL Q&A column.
If you're trying to find general Microsoft resources on security, there are many destinations that will show up in your favorite search engine. To save you some time clicking around, I'll suggest two key white papers you should read.
For SQL Server 2005, the entry point into the security section of Books Online is the topic " Security Considerations for Databases and Database Applications ." For SQL Server 2008, the equivalent Books Online entry point is the " Security and Protection (Database Engine) ."
As far as takeaways from this article are concerned, I want you to realize that there are some steps you need to go through to ensure the data you are storing in SQL Server is as secure as you need it to be. This is especially important when you inherit a SQL Server instance that someone else has been managing. It's just like buying a house from someone—you need to ask if the alarm works, if the yard is fenced in, and who has copies of the keys. Running through the list I've given in this article is a good start, but make sure you dig deeper in areas that are relevant to you. And as always, if you have any feedback or questions, drop me a line at Paul@SQLskills.com .

Paul S. Randal is the Managing Director of SQLskills.com and a SQL Server MVP. He worked on the SQL Server Storage Engine team at Microsoft from 1999 to 2007. Paul wrote DBCC CHECKDB/repair for SQL Server 2005 and was responsible for the Core Storage Engine during SQL Server 2008 development. Paul is an expert on disaster recovery, high-availability, and database maintenance and is a regular presenter at conferences around the world. He blogs at SQLskills.com/blogs/paul .

Segurança
Problemas de segurança de servidores SQL comuns e soluções
Paul S. Randal
 
Visão geral:
  • Físico e segurança de rede
  • Ataque de superfície, contas de serviço e privilégios mínimos
  • Inclusão de autenticação, autorização e SQL
  • Recuperação de desastres e auditoria

Quem foi ao redor o setor de TI sabe que segurança é um tópico ativo. Afinal, dados da empresa são um dos ativos mais preciosa possui e proteger os dados é crítico. Como eu estava planejando que escrever para esse problema de segurança, eu tentei determinar qual recurso de segurança deve ter um artigo inteiro dedicado a ele. Mas, em seguida, iniciado para pensar sobre os números burgeoning de "DBAs involuntárias" (os profissionais de TI que inadvertidamente eólica up responsável por uma instância do SQL Server) e a resposta ótima tivemos que o Principais dicas para manutenção de banco de dados efetivas artigo de 2008 de agosto. Ele impressionou-me que o que deve fazer é escrever um artigo que aborda problemas comuns de segurança do SQL Server — um tipo de Introdução à segurança melhor para seus instâncias do SQL Server.
Um artigo que descreve todos os os problemas de segurança que você deve estar procurando em seria uma revista toda em si, portanto, eu canvassed meu colega MVPs do SQL Server (e minha esposa) para entrada de como a que deve incluir. Eu liquidadas em fornecer as principais áreas de segurança 10 ACREDITO que você deve se preocupar sobre se você não for um DBA savvy com segurança e, de repente, perceber que está responsável por uma instância do SQL Server e associados ao aplicativo. Lembrar que não é uma lista completa. Para cada problema, deu uma breve visão de geral do problema, conselhos sobre como atenuá-lo e um link para informações mais detalhadas.
Todos os links para livros online do são para as versões do SQL Server 2008, mas cada página de Web links para a versão do SQL Server 2005 também. Disposição até o artigo, fornecem links para o principais informes oficiais e seções de manuais online para a segurança para o SQL Server 2005 e o SQL Server 2008.

Segurança física
É imperativo que você apenas não considere segurança do SQL Server propriamente dito, mas todas as camadas que devem ser envolvidas para ir para SQL Server em primeiro lugar. Para esse conceito de segurança em camadas, chamado de "defesa em camadas," você não segura apenas uma camada, mas considere todo o sistema.
A consideração primeira mais óbvia é a segurança física do computador que executa o SQL Server — nessa camada, no entanto, geralmente é ignorada ou é o assunto da complacency. Eu não estou fazendo referência simplesmente para se o computador pode ser roubado ou não, mas também para o acesso físico a coisas como o sistema de armazenamento que hospeda os arquivos de banco de dados, as fitas de backup e os servidores que hospedam cópias redundantes do banco de dados. Somente às pessoas com uma necessidade real fisicamente tocar a esses objetos devem ter acesso a elas; qualquer pessoa que precisa de acesso temporário deve estar acompanhada e monitorada.
Uma consideração menos óbvia é a segurança das áreas de trabalho das pessoas que têm acesso de altamente privilegiado ao SQL Server. Se uma pessoa tem acesso sysadmin para o SQL Server, mas deixam sua área de trabalho Windows desbloqueada, em seguida, a segurança no mundo não vai para impedir que alguém movimentação após o sistema autônomo de potencialmente acessar dados confidenciais. Um problema mais traiçoeiro seria se alguém movimentado past e alterado alguns dados — por exemplo, um funcionário desonesto que sabe o esquema de banco de dados de recursos humanos e tenta alterar undetectably um salário.
Há um muito interessante TechNet white paper (incluindo um slide-baralho e webcasts), intitulado" Segurança física na Microsoft " que descreve como o Microsoft gerencia a segurança física de seus vários servidores.

Segurança de rede
Embora os servidores podem ser fisicamente inacessíveis, eles provavelmente estiver conectados a uma rede de algum tipo. Isso pode ter apenas uma isolado empresa LAN com não fora de conexões, ou pode ser uma conexão direta com a Internet. Não importa o que a situação, existem algumas coisas que você precise considerar (em inglês):
  • Verifique se o servidor do Windows tem segurança de rede adequada configurada.
  • Decidir quais protocolos de rede para permitir e desabilitar qualquer que não são necessários.
  • Certifique-se haja um conjunto de firewalls backup (como o Firewall do Windows) e configurá-lo para permitir acesso ao SQL Server (como mostrado na A Figura 1 ).
  • Optar por criptografar conexões com o SQL Server e configurar corretamente.
  • Se Kerberos for usados, registre um nome principal do servidor. Kerberos é um mecanismo de autenticação que underpins autenticação do Windows (que descrevo neste artigo), mas ele é mal compreendido. Uma explicação clara e concisa foram fornecida por Rob Greene, engenheiro de escalonamento de suporte, na postagem do blog" Kerberos para o administrador de ocupado ." Eu recomendo check-out.
  • Decida se você deseja usar o serviço Navegador do SQL Server para ajudar os clientes localizar instâncias do SQL Server instaladas e decidir se deseja ocultar algumas instâncias. Ocultar uma instância significa aplicativos cliente e os usuários precisarão saber os detalhes de conexão da instância do SQL Server, mas impede que as pessoas trawling da rede para procurar por instâncias do SQL Server.
Figura 1 configurar o Firewall do Windows para permitir o acesso TCP para o SQL Server
Todas essas tarefas (e muito mais) são explicadas em SQL Server 2008 Books Online, iniciando com o tópico Configuração de rede do servidor . Há também uma seção boa em Configuração de rede do cliente .

Minimization superfície de ataque
Os mais serviços e recursos que são habilitados, quanto mais houver para bandidos a ataques de área de superfície ou de superfície de ataque. O SQL Server 2005 levou o "desativado por padrão" estratégia — recursos com as implicações de segurança são desabilitados por padrão e são apenas habilitados por banco de dados quando necessário. (Esse processo de ativar e desativar serviços normalmente é chamado configuração da área de superfície.)
Um exemplo dos principais de um recurso que convém desativado é xp_cmdshell, que fornece uma maneira de executar comandos no host Windows sistema de dentro do contexto de uma instância do SQL Server. Se um comprometer intruso a instância do SQL Server e a conta de serviço do SQL Server possui elevados privilégios do Windows, xp_cmdshell podem ser usados para acessar o sistema Windows, também.
Há uma variedade de métodos de configuração de área de superfície. Tanto o SQL Server 2005 e o SQL Server 2008 oferecem suporte o SQL Server Configuration Manager para configurar serviços e protocolos de rede. Ambos também suportam o procedimento de sp_configure armazenado para configurar recursos do mecanismo de banco de dados e opções. Por exemplo, esse código desabilitará o recurso de xp_cmdshell:
-- To allow advanced options to be changed
EXEC sp_configure 'show advanced options', 1;
GO
-- To update the currently configured value for -- advanced options
RECONFIGURE;
GO
-- To disable xp_cmdshell
EXEC sp_configure 'xp_cmdshell', 0;
GO
-- To update the currently configured value for this -- feature
RECONFIGURE;
GO
Os métodos gráficos de configurar opções de mecanismo de banco de dados e recursos são muito diferentes entre as duas versões. O SQL Server 2005 introduziu a ferramenta SQL Server superfície área configuração (SAC). Isso permite que você faça facilmente alterações. a Figura 2 , por exemplo, mostra como você pode desabilitar xp_cmdshell usando o SAC.
A Figura 2 xp_cmdshell desabilitar usando o SAC no SQL Server 2005
No SQL Server 2008, SAC foi removido completamente e a funcionalidade incorporadas pelo recurso de gerenciamento de com base em diretivas. Você pode encontrar mais informações sobre isso no tópico manuais online do SQL Server 2008" Administrando servidores usando o gerenciamento com base em diretiva ." a Figura 3 ilustra criando uma condição para verificar que xp_cmdshell está desabilitado. Depois de configurado, as diretivas podem direcionar instâncias de SQL Server 2005 e o SQL Server 2008 e podem até mesmo ser "aplicadas," permitindo que você basicamente, altere a configuração com um clique.
A Figura 3 Criando uma condição de gerenciamento de diretiva-com base no SQL Server 2008

Contas de serviço
SQL Server é executado como um ou mais serviços no Windows, e cada serviço precisa ter uma conta do Windows que é usada para executar o serviço. A conta precisa ter acesso a vários recursos no sistema Windows (como a rede e vários diretórios de sistema de arquivo). A prática recomendada é para a conta tenha os privilégios menos possíveis necessários para permitir o SQL Server para funcionar corretamente. Isso faz parte do que é chamado o princípio de privilégio mínimo, que afirma que um sistema pode ser feito mais seguros, concedendo a um usuário ou processam apenas os privilégios necessários e nada mais.
Assim, uma conta de serviço do SQL Server não deve ser uma conta altamente privilegiado (, como sistema local ou o administrador local) porque se SQL Server for comprometido, há a possibilidade do sistema do Windows também ser comprometida. Os serviços normalmente são executados em uma conta interna chamada serviço de rede, mas se SQL Server exigir acesso aos outros recursos do domínio, uma nova conta de usuário de domínio deve ser criada com o mínimo de privilégios e recursos acessos necessários. O tópico manuais online do SQL Server 2008" Configurando contas de serviço do Windows "fornece uma lista abrangente de contas de serviço, privilégios necessários e recursos. Observe que se for necessário alterar uma conta de serviço (ou algo sobre ela), você deve sempre usar o SQL Server Configuration Manager para garantir que todas as alterações necessárias de configuração são feitas corretamente.

Restringindo o uso de privilégios de administrador
O logon de exposição a associação de segurança mais ou a função de servidor fixo sysadmin tiver, o potencial de mais houver para uma violação de segurança — ou um acidente. Existem algumas práticas recomendadas a seguir.
Minimizar o número de pessoas que têm acesso à conta SA e restrinja a participação da função sysadmin (e outras funções privilegiadas) portanto, apenas as pessoas que realmente precisam privilégios sysadmin têm-los. Não forneça a senha para qualquer pessoa que deseja acessar temporário para o SQL Server ou a um usuário do SQL que deseja executar alguma tarefa rápida. Nessas situações, crie um novo logon SQL e conceda a qualquer privilégio é necessário.
É melhor para que as pessoas que os membros do sysadmin em vez de usar a conta SA. Dessa forma, você pode remover logon do usuário sem ter que alterar a senha da conta. Se você assumir um servidor antigo e você não tem idéia que tinham acesso a ele antes, alterar a senha do SA portanto, está no controle.
Um problema que provokes debate é que se deseja remover o grupo do Windows Builtin/administradores da função de sysadmin (ele é adicionado por padrão). Um administrador do Windows poderá consultar o banco de dados de RH? Ou faz sua empresa explicitamente confiar todos os administradores tenham integridade e honesty? Se você decidir para removê-la, continue com cuidado. Isso ocorre especialmente em um ambiente de cluster em que se você não execute as etapas corretas, o SQL Server pode não iniciar. Para obter mais informações sobre isso e outros problemas de cluster, consulte o artigo da Base de Dados de Conhecimento" Cluster SQL Server dos, Don'ts e Basic Warnings ."
Para aqueles que têm acesso de sysadmin, recomende não fazer logon com privilégios altos, a menos que absolutamente necessário — fornecer cada um desses logons de usuários dois, um privilégio e um não. Usando a conta sem privilégios por padrão ajuda a minimizar a possibilidade de erros dispendiosos e também reduz a probabilidade de que um Windows desbloqueado terminal terá uma janela com privilégios sysadmin abrir em-lo. Lembre-se: proteção em camadas!
O último ponto que fará aqui é evitar ter aplicativos que necessitam de privilégios sysadmin. Infelizmente, isso é uma prática inválida comuns e inevitável com alguns aplicativos, mas você deve evitar esta prática em aplicativos pessoal e reclamar com aos desenvolvedores de aplicativos que necessitam de privilégios sysadmin.

Autenticação
Há dois modos de autenticação disponíveis: autenticação do Windows e modo misto (que é a autenticação do Windows combinada com a autenticação do SQL Server).
Autenticação do Windows usa contas de rede/domínio para validar a conta do Windows que está sendo usada para se conectar ao SQL Server. Se esta opção for selecionada durante a instalação, a conta SA é criada com uma senha gerada aleatoriamente, mas efetivamente desabilitada. Imediatamente após a instalação, você deve alterar a senha para uma senha forte e segura mas continuar a deixar a conta desabilitada a menos que absolutamente necessário.
Autenticação do SQL Server depende de cada usuário ter uma conta do SQL Server e a senha armazenada no SQL Server definido. E, obviamente, isso significa que a conta SA está ativada e deve ter uma senha definida. Com a autenticação do SQL Server, os usuários ter pelo menos dois nomes de usuário e senhas (uma para a rede) e outra para o SQL Server. Geralmente, é recomendável que você use somente autenticação do Windows quando possível, pois é uma solução mais segura. O tópico Books Online" Escolhendo um modo de autenticação "explica mais detalhadamente, juntamente com como alterar o modo de autenticação.
Se a autenticação de SQL é usada, todos os usuários devem possuir uma senha de alta segurança — uma que seja complexa o suficiente para ser resistente a sendo esperar por um programa para decifrar senhas. Isso é especialmente importante para contas altamente privilegiado, como associação de segurança e os membros da função sysadmin. (Um dos mais comuns ainda pior práticas costumava ser para ter uma senha SA em branco. Felizmente, como SQL Server 2000 SP3, que não é possível.)
As senhas devem também ser alteradas regularmente e sua empresa deve publicar diretivas corporativas para ajudar funcionários use práticas recomendadas de senha segura e alta segurança. Para obter uma visão geral de práticas recomendadas para criar e proteger a senha de alta segurança, consulte o artigo" Senhas de alta seguras: como criar e utilizar- ." Você pode incorporar essas diretivas em uma diretiva corporativa.
Se o SQL Server 2005 ou SQL Server 2008 estiver sendo executado no Windows Server 2003 ou posterior, ele pode fazer uso do Windows mecanismos de diretiva de senha para impor diretivas de complexidade e vencimento. A seção manuais online do SQL Server 2008 chamado" Diretiva de senha "possui informações sobre suporte para senhas de alta segurança e várias diretivas de senha no SQL Server.

Autorização
Como você já mencionei, uma das filosofias de proteção de sistemas é usar o princípio de privilégio mínimo. Enquanto isso se aplica diretamente a privilégios de administrador-nível, também se aplica às permissões para usuários do banco de dados regular. Um usuário em um banco de dados (provavelmente) não deve conseguir acessar dados em outro banco de dados. O proprietário de um conjunto de tabelas deve ser impossível estragar com tabelas de outra pessoa. Os usuários devem só consiga acessar os dados que deveriam para acessar, e mesmo assim eles devem apenas ser capazes de executar ações necessárias nos dados (por exemplo, SELECT, mas não UPDATE ou DELETE).
Tudo isso pode ser feito dentro do SQL Server por um sistema permissões abrangente e hierárquica onde os usuários ou funções (chamadas de objetos) são concedidas ou negadas determinadas permissões específicas no determinados recursos (chamados securables) como um objeto, esquema ou banco de dados. Uma visão geral sobre a hierarquia de permissões do SQL Server é ilustrada na Figura 4 . Isso também significa que você siga o princípio de privilégio mínimo. Por exemplo, não faça todos os desenvolvedores membros da função db_owner do banco de dados. Restringir permissões à função pública e só conceder permissões para o nível mais baixo (usuário ou função) para minimizar o acesso direto. Uma discussão completa sobre as práticas recomendadas para permissões está além do escopo deste artigo, mas os manuais online do SQL Server 2008 inclui uma seção chamada" Identidade e controle de acesso (mecanismo de banco de dados) "que oferece drill-liste em todos os conceitos.
A Figura 4 hierarquia de permissões O SQL Server
Para permitir que permissões mais granulares e melhor separação de funções dentro de um banco de dados, SQL Server 2005 introduziu separação de esquema de usuário, onde esquemas são independentes de usuários do banco de dados e são apenas recipientes de objetos. Isso permite que muitas alterações de comportamento, incluindo mais precisão específicas para o gerenciamento de permissões. (Quatro partes de nomeação segue o server.database.schema.object de formato no SQL Server 2005 e no SQL Server 2008, o formato era anteriormente server.database.owner.object.)
Por exemplo, um esquema pode ser criado com os desenvolvedores de banco de dados permissões de controle. Eles podem criar, ALTER e DROP qualquer objetos dentro dos esquemas elas controlam mas têm não permissões implícitas para outros esquemas dentro do banco de dados e eles não precisam mais direitos db_owner para banco de dados desenvolvimento. Além disso, a separação de esquema de usuário permite que os usuários do banco de dados ser descartado sem precisar recode todos os objetos relacionados ou o aplicativo com um novo nome de usuário — os objetos são membros de um esquema e eles não estão ligados a criador do objeto.
É uma prática recomendada usar esquemas de posse de objetos devido a esses motivos. Mais informações podem ser encontradas nos manuais online do SQL Server 2008 no tópico" Separação de esquema de usuário ."
Outra maneira de impedir que os usuários fazer as coisas que não precisa para fazer é impedir acesso direto à suas tabelas base. Isso pode ser feito fornecendo procedimentos armazenados e funções que são usadas para encapsular, controle e isolar as operações como atualizações e exclusões e fornecendo exibições que permitir controlada e ideal seleciona.

Inclusão de SQL
Um dos métodos mais comuns de obtenção de acesso não autorizado aos dados é usar um ataque de injeção de SQL. Inclusão de SQL pode tomar vários formulários, mas a abordagem principal aproveita do código que usa seqüências de caracteres construídas dinamicamente e "injeta" código inesperado para a construção. Por exemplo, o ataque de injeção seguinte aproveita mal-escrito lógica para validar a entrada usuário a rodada do SQL Server para aceitar a entrada, incluindo caracteres de escape na cadeia de caracteres de entrada. Embora contrived, este exemplo realça que pode acontecer quando o código cria dinamicamente seqüências usando entrada que não é validada completamente:
DECLARE @password VARCHAR (20);
DECLARE @input    VARCHAR (20);
DECLARE @ExecStr  VARCHAR (1000);

SELECT @password = 'SecretSecret';

-- assume application gets input 'OR''='
SELECT @input = '''OR''''=''';

SELECT @ExecStr = 'IF ''' + @password + ''' LIKE ''' + @input + ''' PRINT ''Password Accepted''';

EXEC (@ExecStr);
GO
Se você executar esse código, ele imprimirá a frase aceito de senha mesmo que a entrada do usuário claramente não corresponde a seqüência de caracteres da senha. A entrada do usuário continha uma seqüência de escape que alterou a lógica de Transact-SQL porque a entrada foi analisada e verificada corretamente.
Inclusão de SQL não deve ser um problema para um aplicativo bem escrito e existem alguns truques específicos (como usar QUOTENAME para identificadores delimitados). Mas se você herdar um aplicativo antigo (ou talvez um projeto de homebrew que se tornou um aplicativo corporativo), você deve testar especificamente para verificar se ele está vulnerável a ataques de injeção de SQL. Há uma variedade de técnicas disponíveis para atenuar os ataques de injeção de SQL. Manuais online do SQL Server 2008 tem uma seção abrangente, começando com o tópico apropriadamente nomeado" Inclusão de SQL ."

Recuperação de desastres
Quanto você precisa se preocupar com isso depende de quais são os requisitos de perda de tempo de inatividade e dados. (Se você já não tiver definido esses requisitos, você deve!) Problemas de segurança podem ocorrer em muitos níveis. Existem alguns problemas quando a recuperação de desastres envolve failover para outro SQL Server ou a necessidade de restaurar um banco de dados contendo os dados criptografados.
No primeiro caso, os problemas ocorrem quando os logins necessárias para acessar o banco de dados não tem sido duplicados no servidor de failover — por exemplo, quando usando o envio de log ou espelhamento do banco de dados. Se o banco de dados ocorrer failover para a instância de espelhamento e o aplicativo tenta se conectar usando um login específico que não existe no servidor espelho, o aplicativo receberá o erro 18456 "logon falhou". Os logins fazem parte do ecossistema de aplicativos e devem ser definidos na instância que hospeda o banco de dados. Artigo da Base de Dados de Conhecimento da 918992" Como transferir os logins e as senhas entre instâncias do SQL Server 2005 " explica como fazer isso, e irá discutir solução de problemas erro 18456 em alguns instantes.
No segundo caso, problemas ocorrem quando o backup do banco de dados contém dados criptografados e a criptografia de chave (ou chaves) usada para criptografar os dados não foram feitas backup ou não estão disponíveis na instância do SQL Server em que o banco de dados está sendo restaurado. O melhor caso aqui é que apenas alguns dos dados no banco de dados são criptografados e para que apenas esse subconjunto de dados não pode ser acessado. O pior cenário de caso é que todo o banco de dados foram criptografado usando a criptografia de dados transparente (TDE) no SQL Server 2008. Nesse caso, se o certificado de servidor usado para proteger a chave de criptografia do banco de dados não foi feito backup ou não estiver disponível, o banco de dados inteiro não pode ser restaurado e retornará os seguintes erros:
Msg 33111, Level 16, State 3, Line 1
Cannot find server certificate with thumbprint
'0xFBFF1103AF133C22231AE2DD1D0CC6777366AAF1'.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
Obviamente, isso é o ponto de TDE — que alguém acontecendo em um backup perdido do banco de dados criptografado não é possível restaurá-lo e acessar os dados confidenciais. Mas se os dados são sua, e você precisa acessá-lo, em seguida, você deve ter o certificado do servidor disponível ou os dados serão perdidos.
Criptografia é um tópico enorme em si e tem cobertura completa no SQL Server 2008 Books Online, iniciando com o " Criptografia do SQL Server "seção. Você também pode assistir me Demonstre TDE e restaurar com êxito para uma segunda instância em um acompanhamento screencast vídeo disponível em .com/dicas.

Auditoria
Uma das coisas mais importantes que você deve fazer para melhorar a segurança de um sistema é implementar a auditoria. Com isso, você saberá que o que está fazendo. Isso ainda pode ser obrigatório, dependendo da natureza da sua empresa.
No mínimo, você deve auditar logons com falha e bem-sucedidas para que você pode dizer se, por exemplo, cinco falhas em tentativas de logon foram seguidas por um bem-sucedido. Em seguida, você sabe quando alguém está tentando quebrar em sua instância do SQL Server (e com o logon). mostra a Figura 5 configurando a auditoria de logon pela caixa de diálogo Propriedades do servidor no SQL Server 2005 Management Studio. Logons com falha são auditados como mensagem 18456 no log de erros e o estado de erro fornece o motivo da falha. A melhor descrição que foi possível localizar os diferentes estados, bem como uma discussão longa sobre solução de problemas, está em uma postagem de il-Sung Lee no blog SQL protocolos intitulado" Noções básicas sobre 'Falha de Logon' (Erro 18456) mensagens de erro no SQL Server 2005 ."
A Figura 5 Confi guring logon de auditoria no SQL Server 2005 Management Studio
Auditoria completa de todas as ações é difícil no SQL Server 2005 (e muito além do escopo deste artigo). Ela envolve vários disparadores e rastreamento SQL. No SQL Server 2008, a auditoria foi bastante simplificada com a introdução de um novo recurso: auditoria do SQL Server. Isso é abordado em um recente, muito detalhado informe oficial intitulado" Auditoria no SQL Server 2008 ." O que acompanha screencast vídeo, demonstrarei auditoria do SQL Server. Você pode obter detalhes sobre outras ferramentas de auditoria no SQL Server 2008 Books Online" Auditoria (mecanismo de banco de dados) "seção.

Resumo
Que muitos tópicos e muita de links, mas esse era o ponto de neste artigo. Eu queria fornecer uma visão geral dos tópicos de segurança importantes que você deve considerar quando você estiver um banco de dados que não usaram para lidar com segurança.
Existem algumas ferramentas que podem ajudar você a verificar o sistema para vulnerabilidades de segurança comuns. O primeiro é o utilitário Microsoft Baseline Security Analyzer (MBSA) que verificarão para Windows, rede, sistema de arquivos e até mesmo alguns problemas de segurança do SQL Server 2000 e SQL Server 2005. A versão mais recente é Microsoft Baseline Security Analyzer 2.1 . Novamente para SQL Server 2000 e SQL Server 2005 somente, há uma SQL Server–specific ferramenta chamada a Best Practices Analyzer BPA (). Isso usa uma lista predefinida de regras para verificar a configuração do SQL Server e sinaliza problemas (por exemplo, uma senha SA em branco).
Nenhuma dessas ferramentas funciona com o SQL Server 2008. Na verdade, BPA será não liberada para o SQL Server 2008 em todos os e foi substituída, juntamente com a ferramenta de configuração de área de superfície do SQL Server 2005 curta duração, pelo novo recurso de gerenciamento de diretivas-com base em discutido anteriormente. Parte a razão para essa substituição é que BPA e o SAC eram ferramentas somente leitura para ajudar você encontrar problemas — eles não foi possível corrigir problemas. Gerenciamento com base em diretivas oferece muitas opções corretivas e ele ainda pode ser usado para servidores de destino SQL Server 2000 e SQL Server 2005.
Obviamente, você deve sempre ser usando o Windows Update para garantir que os novos patches de segurança e service packs são baixados para instalação em um tempo apropriado — essa é a melhor maneira para ficar atualizado com as atualizações mais recentes. Instalar esses sem levando tempo de inatividade é além do escopo deste artigo, mas algumas idéias apresentadas no Coluna de p & r do SQL de dezembro de 2006.
Se você está tentando localizar recursos Microsoft gerais sobre segurança, existem muitos destinos que aparecerão no seu mecanismo de pesquisa favorito. Para salvar alguns tempo clicando em torno, vai sugiro duas chaves white papers que você deve ler.
Para o SQL Server 2005, o ponto de entrada para a seção de segurança do Books Online é o tópico" Considerações de segurança para bancos de dados e aplicativos de banco de dados ." Para o SQL Server 2008, o ponto de entrada manuais online do equivalente é o " Segurança e proteção (mecanismo de banco de dados) ."
Como diz respeito takeaways deste artigo, eu quero você perceber que há algumas etapas que você precisa percorrer para garantir os dados que você está armazenando no SQL Server como seguras que ele seja necessário. Isso é especialmente importante quando você herdar uma instância do SQL Server que alguém Gerenciando. É exatamente como comprar uma casa de outra pessoa — você precisará perguntar se o alarme funciona, se o jardim é fenced em, e quem tem cópias das chaves. Execução através da lista que deu neste artigo é um bom começo, mas verifique se que você examine mais em áreas que são relevantes para você. E como sempre, se você tiver quaisquer comentários ou dúvidas, solte-me uma linha no Paul@SQLskills.com .

Paul S. Randal é o diretor de gerenciamento de SQLskills.com e um MVP do SQL Server. Ele trabalhou na equipe mecanismo de armazenamento do SQL Server da Microsoft de 1999 para 2007. Paul escreveu DBCC CHECKDB/reparo para o SQL Server 2005 e foi responsável pelo mecanismo de armazenamento principal durante o desenvolvimento do SQL Server 2008. Paul é um especialista em recuperação de desastres, alta disponibilidade e manutenção de banco de dados e é um apresentador regular em conferências em todo o mundo. Blogs de he em SQLskills.com/blogs/paul .

Page view tracker