Azure File Share no SQL Server – [5] Tudo junto!

Finalmente, chegamos ao nosso último post da série sobre Azure File Share no SQL Server! No primeiro post, você viu a solução completa, sem muita explicação para o cenário “Como mapear um azure file share para que eu possa fazer backup no meu SQL Server da maneira mais segura possível”.

E então, nos posts seguintes eu mostrei alguns conceitos básico do Azure File Share, de diretórios de rede e as dificuldades e opções que temos para mapear diretórios de rede de forma que o SQL Server os enxergue! E, por último, mas não menos importante, te apresentei o Credential Manager do Windows, uma das grandes chaves para preencher o requisito “mais seguro” do nosso problema.

Eu resolvi abordar toda esses detalhes por um simples fato: A senha que você utiliza para acessar o Azure File Share é simplesmente a Account Key. Isto significa que, se você deixar isso solto em algum script no seu ambiente, você pode não comprometer somente seu SQL Server, mas toda uma storage account da sua empresa. E uma dica: Tudo que foi dito durante toda a série se aplica para os tradicionais file share, aqueles que são mapeados entre um servidor e outro dentro da rede da sua empresa, file server, etc.

Recapitulando o post anterior, eu mostrei como você pode armazenar as credenciais de um diretório de rede usando o Credential Manager. Graças a isso, eu consigo acessar o diretório sem precisar digitar senhas e usuários. E então, como uma pessoa espera que você é, pode após executar exemplo do post anterior, você pode ter tentado fazer isso no seu SQL Server:

O erro é esperado, pois eu cadastrei as credenciais na sessão do meu usuário. O credential manager, é por usuário (e não por Logon Session, como expliquei no terceiro post da série)!  Isso nos dá a vantagem de que eu preciso inserir apenas uma vez essas credenciais de acesso e mesmo após restarts de serviço, ou até mesmo da máquina, o acesso ao share irá continuam funcionando!

Logo, a única coisa que eu preciso fazer agora para que é cadastrar  as credenciais no Credential Manager apenas uma vez para o usuário do SQL (conta de serviço), e não para o meu. E isso é muito importante destacar: Alguns ransonwares já conseguem detectar sessões SMB e fazer o trabalho sujo, mesmo que não esteja mapeada como um drive local… Caso ele se instale na sua conta de usuário, você pode ter aberto um brecha… Mapear apenas para um conta de serviço, reduz mais ainda as chances, uma vez que ela não é interativa. Isso vai tornar sua vida mais difícil quando quiser validar algo… Mas a decisão é sua: mais segurança ou mais fácil?

Há várias maneiras de se mapear as credenciais para a conta do SQL, graças a ferramenta que mostrei no post anterior, cmdkey:

1. Logando com a conta do SQL, se você possui a senha dele
   1. Identifique a conta de serviço (pode usar configuration manager, services.msc, powershell, etc.)
      1. Eu gosto da DMV sys,dm_server_services
   2. Abra o cmd.exe e utilize o seguinte comando:
      
      Mapeando com runas.exe

      PowerShell

      runas /user:ContaServicoSQL "cmd /k cmdkey /add:StorageAccountURI /user:Azure\StorageAccountName /pass:AccountKey"

      1	runas /user:ContaServicoSQL "cmd /k cmdkey /add:StorageAccountURI /user:Azure\StorageAccountName /pass:AccountKey"

      

      O que este comando faz é simples: Ele inicia um cmd com  a conta de serviço e executa o comando cmdkey para adicionar as credenciais.
      Com isso, o cmdkey é executado no contexto do usuário do SQL e as credenciais são adicionadas para este usuário.

   3. Se tudo ocorreu com sucesso, você verá uma nova janela se abrindo:

      

2. Com xp_cmdshell
   1. Caso você não possua a senha da conta, ou a conta seja uma virtual account (ex.: NT SERVICE\MSSQLSERVER), você deverá usar este método!
   2. Novamente, vou alertar para as questões de segurança ao usar xp_cmdshell:
      1. NÃO ESQUEÇA DE DESABILITÁ-LA após o uso, caso você não precise usar para mais nada no seu ambiente;
      2. Não execute nenhum comando em produção, sem que você faça um teste antes!
   3. Dito isso, e considerando que irá executar por sua própria conta e risco, já deixei o script pronto no git que aceita algumas variáveis como parâmetros e faz todo o trabalho.

Após inserir na Credential Store da conta do SQL, o acesso funciona normalmente:

Você querer facilita sua vida, utilizando um symbolic link:

Mas isso faz com que o file share seja enxergado a nível de filesystem. Se estiver tentando dificultar a vida de um ransomware, por exemplo, isso pode não ser uma boa ideia. O link simbólico é um recurso muito pouco explorado no mundo Windows, porém bastante usado no mundo Linux. A ideia é criar um espécie de ponteiro para outros caminhos, de forma que você possa utilizar esse “ponteiro” como se fosse o caminho real. Deixei alguns links de referência para aprender mais. E algum momento posso abordar ele mais especificamente em outros casos envolvendo SQL Server. Mas, alerto que usá-lo aqui, pode realmente causar um efeito contrário do que você quer, em relação a segurança…

Finalizamos aqui nossa série e espero que ela tenha sido útil de alguma forma!

Utilize os comentários caso tenha ficado com alguma dúvida!

Fontes e Links úteis:

• mklink
  https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink
• NTFS Links
  https://en.wikipedia.org/wiki/NTFS_links

Rodrigo Ribeiro Gomes

DBA Team Leader na Power Tuning