Eu sei que esta é uma ideia estúpida, mas estou tendo dificuldade em encontrar uma solução melhor agora. Preciso executar vários procedimentos armazenados em sql diariamente e, em seguida, executar um script powershell para acionar um aplicativo externo para extrair alguns dados do servidor sql
A segunda etapa precisa passar o nome de usuário e a senha como argumentos. Esses dois servidores não fazem parte do mesmo domínio do Windows, portanto, qualquer confiança no nível do usuário não é possível, apenas o envio explícito de um nome de usuário e senha nos scripts do powershell funcionará.
O servidor é SQL Server 2008, e não temos SSIS disponível como opção. O próprio servidor sql é restrito a apenas 3 usuários hoje, portanto, ter a senha em texto simples como uma etapa de comando do powershell em um trabalho de agente não obteria nenhum privilégio de usuário que eles ainda não possuem hoje, mas isso ainda parece como se devesse haver uma maneira melhor que estou perdendo.
Uma mitigação de risco é usar um procedimento armazenado assinado. Aqui está um exemplo disso em ação. Em resumo, você empacota todas as ações confidenciais (acesso à tabela, etc.) dentro de um procedimento armazenado. Você cria um certificado no servidor SQL para assinar esse SP. Você cria um novo login cuja única habilidade é executar o SP e envia a senha para esse login de baixo privilégio em texto simples. Dependendo de quão sensíveis são os dados provenientes do SP, isso pode limitar os danos de um vazamento de senha.