xp_cmdshell: dovrebbe mai essere usato?

È sempre un rischio . Dovrebbe sempre essere revisionato . Può essere attenuato .

Ci sono usi legittimi, a volte necessità, ma guarda attentamente i tuoi input!

Disattivare xp_CmdShell è un po 'come mettere un velo sulla carne in decomposizione. Porta un falso senso di sicurezza al tavolo e le mosche possono ancora arrivare alla carne. Permettimi di spiegare.

Chi può usare xp_CmdShell? Giusto. Solo gli accessi alle persone / app con i privilegiati "SA" o le persone a cui hai fatto l'errore orribile di concedere un proxy possono utilizzarlo.

Domanda successiva. Se hai disattivato xp_CmdShell, chi sono le uniche persone che possono riattivarlo? Correggere di nuovo! Solo le persone / app con privati "SA" possono riaccenderlo.

Quindi, qual è il vero problema con xp_CmdShell che rappresenta un rischio per la sicurezza? La risposta è xp_CmdShell NON è un rischio per la sicurezza. Scarsa sicurezza è l'unico rischio per la sicurezza. Se un hacker o un utente interno malintenzionato entra nel sistema con privilegi "SA", possono attivare xp_CmdShell nei momements. Sì, quell'azione viene registrata, ma questo fornisce solo testimonianze documentate che la sicurezza è stata gravemente carente all'inizio.

L'attivazione di xp_CmdShell non fa nulla per sicurezza se non fornire una possibilità per quella parte di codice di un hacker di riattivarlo per l'esecuzione.

Lo dirò di nuovo. xp_CmdShell non è un rischio per la sicurezza. Solo una cattiva sicurezza è un rischio per la sicurezza. Risolvi la tua sicurezza e quindi attiva xp_CmdShell. È uno strumento meraviglioso e ti stai perdendo a causa di cattive pratiche di sicurezza e mito.

Penso che "non dovrebbe essere usato" è probabilmente un buon consiglio. Non è categorico "È sempre insicuro", ma piuttosto un riconoscimento che xp_cmdshell è pericoloso e qualsiasi uso di esso è motivo di preoccupazione e scrupoloso controllo.

E anche se pensi di sapere come evitare i rischi per la sicurezza, xp_cmdshell probabilmente non è ancora il miglior strumento da usare. Le probabilità sono che ci sia una soluzione migliore (anche una che, casualmente, sembra essere meno rischiosa).

"Con un grande potere derivano grandi responsabilità". Detto questo, penso che xp_cmdshell sia uno dei peggiori trilli della sicurezza per farcela con Redmond.

Quale tipo di sicurezza viene utilizzato nell'ambiente di SQL Server, misto o integrato (Windows)? Quanti sono nel ruolo di SQL Server sysadmin? Le best practice MS richiedono l'autenticazione integrata (nessun accesso sa, nessun accesso SQL) e solo due nel ruolo sysadmin di SQL Server. Ritengo che il rispetto di queste migliori pratiche attenui notevolmente l'esposizione. Inoltre, xp_cmdshell (modalità pre-sqlcmd e pre-PowerShell) consente di copiare i file di registro delle transazioni dal server di produzione al server DR a centinaia di chilometri di distanza da un processo di SQL Agent pianificato. Nessun male qui, ma come dice un poster, "dipende".

Per sottolineare la risposta di jl01 (che ho dato un +1 a) ...

Stranamente, una buona misura di SQL Server correttamente protetto e sicuro è di avere effettivamente abilitato xp_CmdShell. Ciò che intendo è che se il tuo sistema è abbastanza sicuro, non dovresti preoccuparti di questioni banali come xp_CmdShell essere abilitato E USATO.

Soprattutto a partire da SQL Server 2005, non vi è praticamente alcun motivo per cui gli utenti diversi dai DBA dovrebbero avere privilegi maggiori dei privilegi PUBLIC e dei privilegi EXECUTE sulle stored procedure in un sistema correttamente bloccato. Infatti, implementati correttamente, gli utenti con PUBLIC privati dovrebbero essere in grado di eseguire una stored procedure che contiene chiamate a xp_CmdShell senza essere in grado di eseguire direttamente xp_CmdShell.

Penso che sia ironico che MS abbia creato il proxy di comando shell per consentire agli utenti privati di eseguire direttamente xp_CmdShell quando non dovrebbero nemmeno essere in grado di vedere una tabella.