Pessoal, esta semana eu vou falar um pouco sobre o aspecto mais administrativo do SQL Server: Segurança!

Sim, este é um assunto de desperta muito interesse para a comunidade da informática pois determinadas informações são extremamente valiosas e devem ser protegidas a todo custo.

No SQL Server, como eu qualquer outro banco de dados Cliente/Servidor, existem diversas maneira de se tratar sobre segurança e vou comentar com vocês, nesta semana, sobre alguns itens importantes.

Quando um hacker invade um servidor, ele sempre vai procurar um lado mais fraco e este lado pode ser o banco de dados...

1. Senha do sa (system administrator)

Após uma instalação bem sucedida do SQL Server (desde a versão 6.5) a senha do sa (system administrator, ou seja, o usuário mais poderoso do banco) é perguntada. Pode-se colocar uma senha ou deixá-la em branco. Aqui temos um ponto muito importante: JAMAIS deixe a senha do sa em branco, principalmente se for em um servidor de produção. Nove entre dez instalações do SQL Server que eu encontro tem a senha do sa em branco. Além disso, tenham muito cuidado para quem vocês passam a senha do sa.

Quando possível, não coloque a senha do sa ‘engessada’ em sua aplicação. Já encontrei situações onde o DBA (Database Administrator) não podia mudar a senha do sa (que estava em branco) porque diversas aplicações continham em seu código fonte o login do sa ‘chumbado’ proibindo a mudança da senha, pois estas aplicações não mas iriam funcionar.

2. Modo de autenticação

Ainda na instalação do SQL Server, pode-se escolher dois modos de autenticação, que é a maneira de um usuário se logar no banco de dados:

* Windows Authentication Mode: O usuário só pode se conectar através de um login/senha já previamente cadastrado no Windows NT/2000. Geralmente esta é a senha que o usuário utiliza no login da sua máquina em um PDC (Primary Domain Controler) da rede.

* Mixed Mode: O usuário pode se conectar no banco através de um login/senha já previamente cadastrado no Windows NT/2000 ou de um login/senha fornecido no momento da conexão com o banco (SQL Server Authentication).

A Microsoft recomenda fortemente a utilização do Windows Authentication Mode pois é o próprio sistema operacional que fez todas as verificações de login, tornando o acesso um pouco mais seguro.

3. Login/Senha/Permissão

Uma vez conectado ao banco, é recomendado que este usuário possua somente o acesso a informação pertinente a função que ele vai executar. Por isso, crie logins/senhas para cada usuário ou grupo de usuários (chamados de roles) e atribua as permissões corretas. Isto é tão importante que se um usuário possuir uma permissão errada, pode deste ‘bisbilhotar’ informações restritas a ele até destruir completamente o servidor em que o SQL Server está instalado.

Procure também planejar o acesso aos objetos do banco de dados de modo que haja um certo nível de encapsulamento dos objetos base. Uma maneira de fazer isto é através de views.

4. Service Packs/Fixes

Sempre procure ficar atualizado quanto aos releases que a Microsoft lança sobre o SQL Server, sejam eles hot fixes ou service pack. A propósito pessoal, o service pack 2 do SQL Server 2000 já está para ser lançado. Junto com estes releases, a Microsoft sempre lança documentação e instruções para atualização que devem ser lidas com atenção.

5. Infraestrutura

Neste caso devemos tomar cuidado com o acesso físico e remoto ao servidor de banco de dados. Cuidados como não deixar o servidor logado, liberação do uso de CDROM/drive de disquete, acesso limitado à rede do servidor, evitar de utilizar o mesmo servidor de banco de dados para servidor de logon ou servidor de impressão ou servidor de arquivos.

Neste aspecto é importante frisarmos a política de segurança da empresa, que deve contar com: mudança de senhas periódicas, backup permanente, procedimentos de tolerância, planos de contigência, não só para o servidor de Banco de Dados mas para todas as estações que possuirem acesso ao servidor.

No servidor de banco de dados, evite acesso a qualquer meio externo, incluido aí internet, intranet e extranet. Verifique quais serviços estão rodando no servidor pois podem existir alguns serviços que não são necessários para um servidor dedicado de banco de dados, criando mais uma ‘porta’ para hackers.

Um abraço para todos e até a semana que vem.