Azure File Share no SQL Server – [3] Mapeamentos de file shares no Windows

Post 3/5. Este post é parte da série: Azure File Share no SQL Server
Tempo de leitura estimado: 3 minutos

Até aqui,  você já aprendeu como funciona o que é o file share do Azure e como criar um. Agora, vamos trazer isso, com mais detalhes, para um mundo com o qual você provavelmente está mais acostumado: Mapeamento de unidades de rede!

Mapeando o file share

Mapear o file share do azure funciona da mesma maneira que qualquer outro. Basta usar a interface do seu explorer (na opção mapear unidade de rede) ou via linha de comando, da seguinte maneira:

net use T: \\thesqltimes.file.core.windows.net\arquivos /user:Usuario password

Este comando não é específico do Azure, e sim, do Windows. Funciona para mapear qualquer unidade de rede, e permite especificar um usuário e senha. No caso do Azure File share, o nome do usuário é o nome da storage account, e a senha é uma das chaves da conta. Você pode obter a chave de várias maneiras, uma delas é usar o portal do azure, conforme mostrado no post anterior. Aqui está um exemplo da execução:

SQL Server e mapeamento de diretórios remotos

É comum nas empresas que o local de backup do SQL Server seja em um outro servidor, e não localmente. Para isso, geralmente é disponibilizado o caminho do share, junto com as credenciais. O grande problema com isso é mapear essa unidade de forma que o SQL Server possa escrever o arquivo de backup.

Creio que muita gente já passou por isso e com uma simples pesquisa no google, a resposta mais comum é essa:

  • Habilita xp_cmdshell
  • Mapeia usando o comando net use e passando o usuário e senha com a opção de persistência ativada
  • Deixe um condição no código que refaça os mapeamentos, caso, magicamente, o mapeamento deixe de funcionar

Tá, eu gosto e não gosto dessa solução por alguns motivos (fique livre para usar os comentários e trazer seus pontos de vista também):

  • Habilitar o xp_cmdshell
    Utilizar isso é ter muito cuidado. É uma boa prática de segurança não usar isso. Na verdade mesmo, o problema com xp_cmdshell é você habilitar e esquecer habilitado. Algumas ferramentas da Microsoft, utilizam o xp_cmdshell para realizar algumas tarefas. Minha implicância com isso é  só: SAIBA USAR e SAIBA O QUE ESTÁ EXECUTANDO e prefira não deixar isso ligado pra sempre.
  • Deixar um script que refaça o mapeamento
    Essa pra mim é mais doída do ponto de vista de segurança… Ora, alguém foi lá, adicionou uma camada de segurança e você simplesmente deixou a senha expostas em seus scripts… Novamente, é questão de tomar cuidado. Tentar procurar alternativas que envolvem criptografar a senha e controlar o acesso ao script, job, etc. onde ela está salva!
  • Acesso
    Esta alternativa é interessante porque somente o serviço do SQL consegue enxergar e acessar a unidade, protegendo de ataques contra RansonWare, por  exemplo. Como o mapeamento é visível apenas na sessão do SQL, dificilmente ele vai ter acesso (a menos que você tenha mapeado na sua sessão também).

Por que o SQL Server não enxerga o mapeamento que eu faço no meu usuário?

O motivo é muito simples: sessões e contextos dos processos no Windows. De uma maneira bem resumida, tudo que roda no Windows tem uma sessão associada. Especificamente, uma Logon Session.

Por exemplo, quando você loga, fisicamente ou via RDP, o Windows cria e atribui uma sessão para você. Certos recursos, como o mapeamento de unidades, só existem naquela Logon Session.

Cada serviço do Windows possui sua própria Logon Session.. Quando um serviço é iniciado, uma nova Logon Session é criada para este serviço. E é por isso que ele não enxerga os mapeamentos feitos por você em sua sessão, seu mortal!

Ao utilizar o xp_cmdshell, o SQL Server cria um novo processo na mesma Logon Session dele. Por isso que seu comando funciona e faz, milagrosamente, o SQL enxergar. E, mesmo usando “persistent yes” você eventualmente pode vir a ter problemas de conexão, devido ao fato de que o net use não armazena a senha!

E outra: Você pode ser muito espertinho(a), e tentar abrir um cmd.exe com a conta de serviço do SQL para fazer o mapeamento! Sinto muito! Mas este processo, cria uma nova Logon Session, e por isso não funciona também. ROLLBACK pro xp_cmdshell…

Então, o resumo da ópera: Você precisa utilizar o xp_cmdshell para mapear a unidade toda vez que o serviço do SQL reiniciar!

E tudo isso porque a senha não fica salva! E você tem que deixar um código pronto com a senha para refazer o mapeamento….

Bom, se você fazia assim, pare de fazer a partir de agora! (ou me dê razões nos comentários para continuar fazendo depois de ler o resto desta série).

No próximo post, te mostrarei um recurso extremamente importante do Windows!

 

 

Navegue na série<< Azure File Share no SQL Server – [2] Conceitos do Azure filesAzure File Share no SQL Server – [4] Windows Credential Manager >>
Compartilhe este post!

Leave a reply

Your email address will not be published.