DBA Checklist – Segurança
Essa série de Check List para DBAs SQL Server foi escrita por Brad McGehee para o site http://www.simple-talk.com/ . É um texto sucinto, mas muito completo. Tomei a liberdade de adicionar algumas observações(em itálico) que normalmente apontam para outros conteúdos em português. O texto original pode ser lidoaqui.
Segurança
- Garanta a segurança física de cada servidor SQL Server, evitando que usuários não autorizados acessem seus servidores fisicamente.
- Em suas instâncias SQL Server instale somente bibliotecas e protocolos de rede que sejam realmente necessários.
- Reduza a quantidade de sysadmins (administradores) que tenham permissão para acessar o SQL Server;
- Como DBA trabalhe com privilégios sysadmin somente quando necessário. Crie contas diferentes para os DBAs acessarem o SQL Server quando privilégios de administrador não forem necessários.
- Configure a conta SA com uma senha segura e jamais utilize esta conta para logar no SQL Server. Para acessar o SQL Server com direitos administrativos utilize uma conta com autenticação Windows.
- Quando conceder permissões para usuários, dê o mínimo de permissão necessário para que ele possa realizar o trabalho.
- Ao invés de permitir que usuários acessem os dados diretamente nas tabelas, utilize Store Procedures e/ou Views.
- Sempre que possível utilize contas com autenticação Windows (windows authentication) no lugar de logins SQL Server.
- Use senhas fortes em todas as contas com autenticação SQL Server.
- Não conceda permissões para a role Public.
- Remova logins que não precisam mais de acesso ao SQL Server.
- Remova a conta guest de todos os bancos de dados.
- Se não for necessário desabilite a propriedade Cross-Database Ownership.
- Nunca dê permissão na procedure xp_cmdshell para usuários que não são administradores.
- Evite criar compartilhamentos de rede no servidor SQL Server.
- Ative a auditoria de login, para que você possa ver quem teve sucesso ou falha no momento de logar no SQL Server. No SQL Server 2008 você poderá utilizar o SQL Server Audit.
- Não use a conta SA ou contas que são membros do grupo sysadmin como contas utilizadas por aplicações que acessam o SQL Server.
- Garanta que o servidor SQL Server esteja protegido por um firewall e não esteja exposto diretamente na internet.
- Retire o grupo BUILTIN/Administrators do SQL Server para prevenir que administradores do servidor tenham acesso ao SQL Server. Antes de fazer isso num SQL Server instalado sobre um cluster, verifique o Books Online.
- Tenha uma conta de domínio diferente para cada serviço do SQL Server.
- Conceda o mínimo necessário de direitos e permissões para as contas de domínio dos serviços SQL. Na maioria dos casos, direitos de administrador local ou administrador de domínio não são necessários. Fora poucas exceções a instalação do SQL Server configura automaticamente as permissões necessárias para as contas de serviços.
- Ao rodar consultas distribuídas, utilize linked server ao invés de remote servers.
- Não navegue na internet num servidor SQL Server.
- Ao invés de instalar um anti-vírus/anti-spyware no servidor SQL Server, execute os scans a partir de uma maquina remota, em horários onde a atividade dos usuários é menor, fora do horário de produção.
- Atualize service packs e hot-fix do sistema operacional e do SQL Server sempre que estes forem liberados e testados. Muitas vezes eles incluem melhorias na segurança.
- Criptografe todos os backups do SQL Server. Se você tem o SQL Server 2008 Enterprise Edition poderá usar a criptografia nativa, se não for o caso, poderá utilizar ferramentas de terceiros, como o SQL Backup Pro.
- Só habilite as auditorias C2 ou Common Criteria se isso for necessário.
- O SQL Server 2008 vem com uma nova funcionalidade de auditoria chamada SQL Server Audit. Ela pode auditar praticamente qualquer atividade do usuário, mas mantenha um número baixo de atividades e objetos auditados para reduzir a sobrecarga no desempenho.
- Considere executar o SQL Server Security Scanner nos seus servidores SQL Server para identificar falhas de segurança.
- Considere adicionar um certificado em suas instâncias SQL Server e habilitar SSL ou IPsec para conexões com clientes.
- Se estiver usando o SQL Server 2005/2008 habilite as opções de políticas de senha.
- Se estiver utilizando o SQL Server 2008 Enterprise Edition, considere implementar criptografia dos dados (Transparent Data Encryption) para ajudar a proteger os dados armazenados em disco.
This entry was posted
on Tuesday, October 13th, 2009 at 3:25 pm and is filed under Dicas, SQL SERVER 2000, SQL SERVER 2005, SQL SERVER 2008, SQL SERVER 2008 R2, SQL SERVER 7, Traduzidos.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Pergunta: Eu não manjo de SQL Server, mas sempre que eu tenho um servidor Oracle em Windows, eu considero a possibilidade de tirar o servidor completamente do domínio. Isso não ajuda um pouco na segurança do servidor?
Além dos compartilhamentos, quais serviços seriam importantes não ter habilitados no servidor?
É possível instalar o SQL Server trabalha num servidor sem a interface gráfica?
Rodar um antivírus remotamente não implica em ter um compartilhamento ativo?
Não existe o risco de o antivírus colocar algum arquivo do banco em quarentena? Parece brincadeira, mas eu já vi um antivírus fazer isso com uma base Oracle…. não foi um dia fácil.
Prezados,
Ao implantar um antivírus em servidor de banco de dado oracle, é necessário fazer algum procedimento como area de exclusão, arquivos confiáveis para que o antivírus não detecte um destes item como vírus?
Grato!