Se un utente malintenzionato ottiene l'accesso al server, è probabile che ci siano altri problemi oltre all'esposizione di credenziali di testo in chiaro in un file.
Inoltre, sei sulla strada giusta per chiedere informazioni sulle migliori pratiche di sicurezza. Non passare attraverso questo sforzo solo per inviare i risultati via email. L'email non è sicura, quindi i tuoi risultati dovrebbero essere crittografati o usare qualcos'altro come la tua menzione di SFTP.
Detto questo, hai due opzioni:
Account di Windows: esegui l'attività come un account Windows dedicato e utilizza l'autenticazione integrata. Ciò non richiederà la memorizzazione del nome utente / password nella stringa di connessione ma sarà necessario memorizzare le credenziali quando si imposta l'attività pianificata. Se questo account è compromesso, ora devi considerare quale accesso ha. Un account di dominio o un account locale sul server sql. Se il primo, saranno in grado di enumerare le risorse del dominio e se l'accesso successivo sarà limitato al server sql. Infine fai attenzione a quali gruppi di sicurezza questo account è concesso, se ce ne sono.
Account SQL - sarà specifico per l'istanza MSSQL anche se richiederà la memorizzazione della combinazione nome utente / password nella stringa di connessione. Un modo per aggirare questo è impostare le autorizzazioni NTFS solo consentendo all'account che esegue l'accesso all'attività pianificata. Ad esempio, se l'attività viene eseguita come SYSTEM, solo consentire l'accesso all'account allo script. Non dimenticare di includere anche l'account utilizzato per eseguire i backup e il tuo account.
DPAPI - Credo che questo sarebbe fuori dal campo di applicazione per quello che stai cercando di fare, quindi mi limito a menzionare che DPAPI consente di usare la crittografia asimmetrica nei file di configurazione e così via.
Considera la gestione degli account quando fai la tua scelta. Potrebbero esserci delle politiche che richiedono una modifica della password ogni ?? giorni. Guarda cosa si applica e scegli il tipo di account che meglio si adatta a ciò che stai cercando di ottenere.
Indipendentemente dall'opzione scelta, assicurati che l'account abbia accesso solo per eseguire le stored procedure applicabili. Ciò limiterà l'esposizione sul tuo server SQL qualora l'account venisse compromesso.
Infine, ci sono molti esempi di utilizzo di PowerShell per eseguire stored procedure. Ho appena usato la seguente stringa di ricerca che ha restituito molti risultati.
sql server stored procedure from powershell stackoverflow