SQL Server - Como desativar o login "sa" minimizando impactos

Visualizações: 1.797 views

Neste artigo

Tempo de Leitura: 6 minutos

Fala, meus queridos leitores!
Nesse artigo, eu gostaria de estender um pouco o tema sobre segurança e compartilhar com vocês como desativar o login “sa” minimizando impactos. Como eu já havia comentado no artigo SQL Server – Como ativar/habilitar o usuário sa, é uma boa prática de segurança manter o usuário “sa” desativado e renomeado, uma vez que esse usuário está na role sysadmin (não pode ser removido), não pode ser apagado da instância e é um usuário padrão, ou seja, está presente em qualquer instância do SQL Server, o que torna esse usuário o alvo preferido de possíveis invasores. Inclusive, esse é um dos ítens de segurança do Check-up GRATUITO do SQL Server que a Fabrício Lima está oferecendo para quiser conhecer a empresa.

Durante alguns dias eu deixei público para a Web, uma instância do SQL Server e do Power BI Report Server para realizar alguns testes. Após alguns dias, vi no error log do SQL Server que já estavam tentando invadir a minha base. Imaginem qual o usuário que mais tentaram utilizar para acessar o meu banco ?

Quer consultar como estão essas estatísticas na sua instância? Basta executar o script abaixo:

DECLARE @ArquivosLog TABLE ( LogNumber INT, StartDate DATETIME, SizeInBytes INT )
DECLARE @Dados TABLE ( [LogDate] datetime, [ProcessInfo] nvarchar(12), [Text] nvarchar(3999) )

INSERT INTO @ArquivosLog 
EXEC sys.xp_enumerrorlogs 1


DECLARE 
    @Contador INT = 0, 
    @Total INT = (SELECT COUNT(*) FROM @ArquivosLog)

WHILE(@Contador < @Total)
BEGIN

    INSERT INTO @Dados
    EXEC sys.sp_readerrorlog @Contador, 1, 'login failed'
    
    SET @Contador += 1

END


SELECT
   MIN(LogDate) AS Dt_Menor_Ocorrencia,
   MAX(LogDate) AS Dt_Maior_Ocorrencia,
   SUBSTRING([Text], 1, IIF(CHARINDEX('[', [Text]) = 0, LEN([Text]), CHARINDEX('[', [Text]) - 1))  AS Texto,
   COUNT(DISTINCT [Text]) AS Quantidade
FROM
   @Dados
GROUP BY
   SUBSTRING([Text], 1, IIF(CHARINDEX('[', [Text]) = 0, LEN([Text]), CHARINDEX('[', [Text]) - 1))
ORDER BY
   4 DESC

DECLARE @ArquivosLog TABLE ( LogNumber INT, StartDate DATETIME, SizeInBytes INT )

DECLARE @Dados TABLE ( [LogDate] datetime, [ProcessInfo] nvarchar(12), [Text] nvarchar(3999) )

INSERT INTO @ArquivosLog

EXEC sys.xp_enumerrorlogs 1

DECLARE

@Contador INT = 0,

@Total INT = (SELECT COUNT(*) FROM @ArquivosLog)

WHILE(@Contador < @Total)

BEGIN

INSERT INTO @Dados

EXEC sys.sp_readerrorlog @Contador, 1, 'login failed'

SET @Contador += 1

END

SELECT

MIN(LogDate) AS Dt_Menor_Ocorrencia,

MAX(LogDate) AS Dt_Maior_Ocorrencia,

SUBSTRING([Text], 1, IIF(CHARINDEX('[', [Text]) = 0, LEN([Text]), CHARINDEX('[', [Text]) - 1)) AS Texto,

COUNT(DISTINCT [Text]) AS Quantidade

FROM

@Dados

GROUP BY

SUBSTRING([Text], 1, IIF(CHARINDEX('[', [Text]) = 0, LEN([Text]), CHARINDEX('[', [Text]) - 1))

ORDER BY

4 DESC

Agora que já fiz um breve resumo do porque esse usuário deve ser desativado e renomeado, vou explicar como podemos fazer isso no seu banco de dados. Em teoria, é algo extremamente simples:

USE [master]
GO

ALTER LOGIN [sa] DISABLE
GO

ALTER LOGIN [sa] WITH NAME = [sa_DESATIVADO]
GO

USE [master]

ALTER LOGIN [sa] DISABLE

ALTER LOGIN [sa] WITH NAME = [sa_DESATIVADO]

Ou até mesmo, pela interface do Management Studio (SSMS):

: Renomeando o usuário SA

: Desativando o usuário SA

O problema é que muita gente fica insegura de fazer essa operação no seu banco de dados e acabar gerando impactos no ambiente. A minha ideia nesse post, é te ajudar a identificar e minimizar esses possíveis impactos para que você possa aplicar essas configurações de segurança em todos os seus ambientes.

Aplicação utilizando SA

O primeiro ítem que deve ser verificado é se existe alguma aplicação que utiliza o usuário “sa” para se conectar no banco de dados (acreditem, isso existe). A forma mais fácil de identificar isso é questionando o fornecedor da aplicação ou o time de desenvolvimento.

Uma forma que pode te ajudar a validar essas informações e até mesmo já conseguir identificar se esse cenário está ocorrendo no seu ambiente, é consultando a DMV sys.dm_exec_sessions:

SELECT
    session_id,
    login_time,
    login_name,
    [program_name],
    [host_name],
    client_interface_name,
    [status],
    nt_domain,
    nt_user_name,
    original_login_name
FROM 
    sys.dm_exec_sessions
WHERE 
    session_id > 50
    AND security_id = 0x01

SELECT

session_id,

login_time,

login_name,

[program_name],

[host_name],

client_interface_name,

[status],

nt_domain,

nt_user_name,

original_login_name

FROM

sys.dm_exec_sessions

WHERE

session_id > 50

AND security_id = 0x01

Resultado:

Databases onde o usuário SA é owner

Essa é uma preocupação muito comum entre os DBA’s que se desativar o usuário SA e renomeá-lo, pode ocorrer algum problema nos databases onde o usuário SA é o owner. Entretanto, podem ficar tranquilos que não ocorre problema algum ao fazer isso. Já fiz vários testes em vários ambientes, tanto de testes quanto de produção e você desativar o usuário SA não causa nenhum impacto em relação à isso.

Para comprovar o que eu estou afirmando, segue uma demonstração:

SELECT 
    A.database_id,
    A.[name],
    B.[name] AS [owner],
    A.create_date,
    A.state_desc,
    A.[compatibility_level],
    A.collation_name
FROM 
    sys.databases A
    JOIN sys.server_principals B ON A.owner_sid = B.[sid]


SELECT 
    [name],
    is_disabled
FROM
    sys.server_principals
WHERE
    principal_id = 1 -- sa

SELECT

A.database_id,

A.[name],

B.[name] AS [owner],

A.create_date,

A.state_desc,

A.[compatibility_level],

A.collation_name

FROM

sys.databases A

JOIN sys.server_principals B ON A.owner_sid = B.[sid]

SELECT

[name],

is_disabled

FROM

sys.server_principals

WHERE

principal_id = 1 -- sa

Resultado:

Jobs onde o usuário SA é owner

Assim como ocorre quando o usuário SA é owner de um database, não há impacto algum referente à execução dos Jobs do SQL Agent ao renomear e desativar o login “sa”. Podem ficar despreocupados e não precisam sair alterando o owner de todos os jobs para renomear/desativar o sa.

Consulta utilizada para demonstração:

SELECT 
    A.[name] AS Ds_Job,
    B.[name] AS Ds_Owner,
    msdb.dbo.agent_datetime(C.run_date, C.run_time) AS Dt_Execucao,
    (CASE C.run_status
        WHEN 0 THEN '0 - Falha'
        WHEN 1 THEN '1 - Sucesso'
        WHEN 2 THEN '2 - Retry'
        WHEN 3 THEN '3 - Cancelado'
        WHEN 4 THEN '4 - Executando'
    END) AS Ds_Status,
    C.[message]
FROM
    msdb.dbo.sysjobs A
    JOIN sys.server_principals B ON A.owner_sid = B.[sid]
    JOIN msdb.dbo.sysjobhistory C ON C.job_id = A.job_id
WHERE
    C.step_id = 0 -- Geral

SELECT

A.[name] AS Ds_Job,

B.[name] AS Ds_Owner,

msdb.dbo.agent_datetime(C.run_date, C.run_time) AS Dt_Execucao,

(CASE C.run_status

WHEN 0 THEN '0 - Falha'

WHEN 1 THEN '1 - Sucesso'

WHEN 2 THEN '2 - Retry'

WHEN 3 THEN '3 - Cancelado'

WHEN 4 THEN '4 - Executando'

END) AS Ds_Status,

C.[message]

FROM

msdb.dbo.sysjobs A

JOIN sys.server_principals B ON A.owner_sid = B.[sid]

JOIN msdb.dbo.sysjobhistory C ON C.job_id = A.job_id

WHERE

C.step_id = 0 -- Geral

Resultado:

Linked Server

Essa é provavelmente a validação mais difícil de se fazer no ambiente, embora também seja bem incomum. Se existir algum Linked Server que aponte para sua instância, onde a conexão ao banco é feita utilizando o usuário “sa”, fixo no LS, você poderá ter problemas ao desativar e renomear esse usuário.

É difícil validar isso, porque você tem que entrar em todas as instâncias do seu ambiente que podem ter algum linked server apontado para essa instância específica e validar se esse cenário está ocorrendo:

Não é muito comum o uso de Linked Server com usuário fixo na conexão, já que qualquer usuário na instância remota poderia executar QUALQUER COMANDO na instância destino, já que a conexão está chegando como “sa”, que é sysadmin, mas é uma validação que deve ser feita para garantir que a alteração não irá gerar impactos.

Você pode utilizar essa consulta para facilitar essa verificação:

SELECT
    B.[name],
    B.product,
    B.[provider],
    B.[data_source],
    A.remote_name
FROM
    sys.linked_logins A
    JOIN sys.servers B ON B.server_id = A.server_id
WHERE
    A.server_id > 0
    AND A.local_principal_id = 0 -- SA

SELECT

B.[name],

B.product,

B.[provider],

B.[data_source],

A.remote_name

FROM

sys.linked_logins A

JOIN sys.servers B ON B.server_id = A.server_id

WHERE

A.server_id > 0

AND A.local_principal_id = 0 -- SA

Objetos com IMPERSONATE utilizando o SA

É um tanto comum ver procedures e objetos que utilizem o comando EXECUTE AS para executar tarefas como se fossem outros usuário, especialmente para permitir que um usuário com poucos privilégios possa executar rotinas e comandos que exigiriam mais privilégios que ele possui, fazendo assim, uma elevação de privilégio. Caso você queira se aprofundar mais sobre o IMPERSONATE e elevação de privilégios, recomendo a leitura do meu artigo SQL Server – Como utilizar o EXECUTE AS para executar comandos como outro usuário (Impersonate login e user).

Para tranquilizar você, saiba que não é possível utilizar o EXECUTE AS USER e personificar o usuário “sa”, pois ele é um usuário “especial”, ou seja, menos uma preocupação para você.

Outros serviços

E por fim, para que você possa fazer sua alteração com toda a tranquilidade, recomendo que você valide se existe algum serviço do Windows, relatório do Reporting Services, alguma rotina Power Shell, ferramenta de monitoramento ou algum processo externo ao SQL Server que possa estar utilizando o usuário sa no seu ambiente.

Como são processos externos e podem ser específicos da sua empresa, não tem muita “receita de bolo” para tratar essas situações, mas não é nada comum um DBA permitir que um serviço utilize o usuário “sa” para tal operações, então deve ser muito difícil encontrar esse cenário.

Fique tranquilo e confiante ao desativar e renomear o usuário “sa”, pois essa é uma boa prática de segurança para o seu ambiente. Lembre-se de monitorar o log do SQL Server após essa alteração para consultar se estão ocorrendo mensagens de falha de login utilizando o “sa”. Disponibilizei uma consulta que dá até pra automatizar isso lá no começo desse post 😉

Caso você identifique algum problema, você pode ter descoberto alguma tentativa de invasão ou um processo na sua empresa fora do padrão, que deve ser alterado urgentemente para utilizar outro usuário para a conexão com o banco de dados.

Bom pessoal, é isso aí!
Espero que tenham gostado dessa dica, renomeiem e desativem o usuário “sa” em seus ambientes e até a próxima!

Ramiro disse:

14 de maio de 2020 às 09:44

Excelente conteúdo! Obrigado e Parabéns!

Responder
Aluisio Alves disse:

3 de outubro de 2019 às 22:11

Boa noite, tenho uma dúvida, pois sou novo nesse mundo SQL. Tem como criar um usuário somente para o software acessa o banco de dados? E caso esse usuário tente acessar o Management do SQL o mesmo não consiga acessa?

Responder

Assinar blog por e-mail

Visualizações do Blog

Microsoft MVP

Arquivo de Posts

Categorias

Posts recentes

SQL Server – Como desativar o login “sa” minimizando impactos

Aplicação utilizando SA

Databases onde o usuário SA é owner

Jobs onde o usuário SA é owner

Linked Server

Objetos com IMPERSONATE utilizando o SA

Outros serviços

You may also like...

2 Responses

Deixe uma respostaCancelar resposta

Aplicação utilizando SA

Databases onde o usuário SA é owner

Jobs onde o usuário SA é owner

Linked Server

Objetos com IMPERSONATE utilizando o SA

Outros serviços

You may also like...

SQL Server – Como criar um monitoramento de erros e exceções no seu banco de dados utilizando Extended Events (XE)

SQL Server – Como recuperar o código-fonte de objetos apagados (View, Stored Procedure, Function e Trigger)

SQL Server – Sua instância está constantemente com mensagens “Starting up database XXX” e databases “In Recovery”? Conheça o Auto Close

2 Responses

Deixe uma respostaCancelar resposta