Consultoria DBA SQL Server

Como um DBA, você tem a responsabilidade de garantir a segurança do aplicativo e dos usuários relacionados aos SQL Servers que você gerencia. Mas quais são os princípios de segurança para DBAs que você segue para os administradores?

Existem regras rígidas e rápidas que devem ser seguidas? Quais preocupações devem ser levadas em consideração quando os direitos são atribuídos aos DBAs?

Como isso é diferente para uma organização grande versus uma equipe pequena em que há muitos dos membros da equipe (DBA, Desenvolvedor, Administrador de Rede, Administrador do Sistema, etc.)?

Maneiras diferentes de abordar a segurança para DBAs e administradores

O que é realmente necessário é ter o equilíbrio certo baseado no seu ambiente e indústria. No entanto, você pode estar se abrindo a vulnerabilidades desnecessárias com as contas que provavelmente são o alvo mais comum devido à profundidade e à amplitude dos direitos.

Com a segurança muito rigorosa, isso pode limitar as pessoas a serem capazes de fazer trabalhos que levam à frustração e dissensão.

Dependendo dos requisitos de organização e segurança no setor específico, os direitos administrativos podem ser diferentes e aceitáveis. Mas, a realidade é que alguém (ou algumas pessoas) precisa ter as chaves (ou acesso) para o reino.

Com tudo isso dito, há princípios de segurança para dbas que devem ser seguidos apenas pela natureza de servir sua organização em uma capacidade administrativa de TI.

Abaixo seguem 4 recomendações de segurança para dbas a serem consideradas para acesso administrativo ao SQL Server com base em observações recentes:

1. Não escreva senhas em notas adesivas e coloque-as no monitor

Só porque você não consegue se lembrar de uma senha de 15 caracteres que alguém criou não significa que alguém não possa olhar por cima do seu ombro e anotá-la. Em vez disso, considere o seguinte:

• Uma senha física ou eletrônica segura para armazenar com segurança as senhas
• Migre toda a autenticação do SQL Server para a autenticação baseada no Windows. Assim, você só precisará lembrar de uma única senha
• Não use a senha sa, a menos que você tenha uma necessidade muito específica que não possa ser cumprida com outra conta

2. Não crie logons padrão do SQL Server em todos os SQL Servers com direitos de administrador

Em vez disso, considere o seguinte:

• Antes de mais nada, migre toda a autenticação do SQL Server para a autenticação baseada no Windows. Dessa forma, você só precisará lembrar de uma única senha

3. Não faça o login com o login e a senha sa em todos os seus SQL Servers.

Assim é difícil auditar o login sa com uma senha compartilhada sem capturar o nome do host ou alguns outros dados pessoais identificáveis. Em vez disso, considere o seguinte:

• Migre toda a autenticação do SQL Server para a autenticação baseada no Windows. Assim, você só precisará lembrar de uma única senha
• Não use a senha sa, a menos que tenha uma necessidade que não possa ser cumprida com outra conta

4. Não configure a conta do DBA no Windows nem as contas de serviço do SQL Server como conta de Administrador do Domínio

Em vez disso, considere o seguinte:

• Para a conta DBA, uma conta de usuário do Windows é realmente tudo o que é necessário. Direitos individuais podem ser concedidos em cada SQL Server (máquina) se esses direitos precisarem ser elevados. Se o DBA também for o administrador da rede, considere duas contas separadas. Assim você irá executar atividades de tipo de usuário com uma e atividades administrativas com a outra.
• Para a conta de serviço do SQL Server, os direitos de Administrador de Domínio não são necessários. Portanto, não devem ser considerados um atalho ou um alivio na carga administrativa, em vez de conceder direitos a SQL Servers individuais (máquina) e compartilhamentos de rede. É fácil conceder esses direitos uma vez. Contudo, se este for um processo complicado ou uma bagunça, considere reorganizar o processo para torná-lo mais simples.