Perché è una cattiva pratica consentire a tutti di utilizzare il login sa?

25

Anche Microsoft scoraggia l'uso della modalità di autenticazione di SQL Server , ma le nostre applicazioni lo richiedono.

Ho letto che è una buona pratica non consentire agli utenti di utilizzare sadirettamente il login, utilizzando invece l'autenticazione di Windows e consentendo a tali account (o gruppi di account) i privilegi di amministratore di sistema.

Non è essenzialmente la stessa cosa? Quali sono i vantaggi / gli svantaggi?
In che modo le migliori pratiche aumentano la sicurezza delle mie istanze di SQL Server?
Questo vale solo per le istanze di produzione o anche per le nostre istanze di sviluppo interno?

sql-server security

— Jon Seigel
fonte

Sto chiedendo questa metà come riferimento canonico in quanto non sono riuscito a trovare nulla tramite Google (sentiti libero di modificare un aspetto che non ho trattato) e metà per guadagnare munizioni per convincere il management che apportare questa modifica è una buona cosa (tm).

— Jon Seigel,

6

È una buona pratica quanto dare a tutti una copia della chiave di casa. ;)

— Geremia Peschka,

1

Per non parlare, "sa" è un nome di accesso pubblicamente noto per SQL Server, che lo rende quindi un obiettivo facile. Nessuna ipotesi davvero coinvolta. Ho visto le aziende cambiare il nome da "sa" a qualcosa di diverso. Anche se solo un piccolo livello, rende un po 'più difficile per i cyber intrusi ottenere qualcosa.

— Thomas Stringer

3

Le tue applicazioni non lo richiedono . Per favore, dicci perché pensi che lo facciano.

— nvogel,

Ottima domanda Se solo altri professionisti del database si fermassero e facessero questa stessa domanda, ci sarebbero molte meno falle nella sicurezza.

— Thomas Stringer,

52

Hai diverse domande qui, quindi le eliminerò individualmente:

"Ho letto che è una buona pratica non permettere agli utenti di usare direttamente il login sa, usando invece l'autenticazione di Windows"

Stai mescolando due cose qui: il concetto di SA e il concetto di autenticazione SQL e autenticazione di Windows.

L'autenticazione SQL è un elenco di nomi utente e password archiviati in ogni singolo SQL Server. Il fatto che sia archiviato in SQL è il primo problema. Se è necessario modificare una password di accesso, è necessario modificarla su tutti i server (o mantenere password diverse su server diversi). Con l'autenticazione di Windows, puoi disabilitare centralmente gli accessi, modificare le password, impostare criteri, ecc.

Se si sceglie di utilizzare l'autenticazione SQL, SA è solo un login di autenticazione SQL. È il nome utente predefinito dell'amministratore, proprio come l'amministratore ha l'autenticazione di Windows. Ha superpoteri locali in quell'unica istanza, ma non superpoteri globali in tutte le istanze.

"... e concedere a tali account (o gruppi di account) i privilegi di amministratore di sistema."

Qualunque sia il metodo di autenticazione che scegli, idealmente vuoi seguire il principio del privilegio minimo: garantire alle persone i diritti minimi necessari per svolgere il loro lavoro, e non di più.

Non pensarli come semplici accessi: sono persone che possono farti licenziare. Se rilasciano il database o disabilitano accidentalmente i processi di backup, non verranno licenziati, perché per impostazione predefinita SQL non tiene traccia di chi ha fatto cosa. Sei tu quello che verrà licenziato perché accadrà e non sarai in grado di dire quale persona l'ha fatto.

"In che modo le migliori pratiche aumentano la sicurezza delle mie istanze di SQL Server?"

Vuoi fare due cose:

Impedire alle persone di rompere il server
Quando si rompono il server, essere in grado di identificare esattamente chi lo ha fatto

Il primo è realizzato con il principio del privilegio minimo: dare alle persone solo le autorizzazioni di cui hanno bisogno, e niente di più.

Il secondo si ottiene dando a ciascuno il proprio login, non consentendo accessi condivisi (come consentire a tutti di usare lo stesso nome utente / password) e, idealmente, controllando gli accessi. Probabilmente non farai subito l'ultima parte, perché è un po 'dolorosa, ma mettiamo i pezzi al posto giusto in modo da poter aggiungere il controllo in seguito dopo che qualcuno ha lasciato un database e il tuo capo vuole sapere perché.

So cosa stai pensando: "Ma stiamo programmando le app e l'app ha bisogno di un login". Sì, concedi all'applicazione il proprio accesso e gli sviluppatori devono conoscere quella password, ma tale accesso dovrebbe essere così privato delle autorizzazioni che nessuno nella loro mente corretta vorrebbe usarlo. Ad esempio, potrebbe essere necessario essere nei ruoli db_datareader e db_datawriter da soli, nient'altro. In questo modo è possibile inserire, aggiornare, eliminare e selezionare dati, ma non necessariamente modificare schemi, aggiungere indici, modificare procedure memorizzate, ecc.

"Questo vale solo per le istanze di produzione o anche per le nostre istanze di sviluppo interno?"

Penso che si applichi altrettanto alle istanze di sviluppo perché di solito sono preoccupato per le persone che rompono le cose. Le persone adorano semplicemente rompere i server in fase di sviluppo. E, naturalmente, quando è il momento di raggruppare l'elenco delle modifiche da migrare alla produzione, ho bisogno di sapere se un determinato indice è davvero vitale per l'app o se qualche osso ha appena eseguito Database Tuning Advisor e gli ha detto di applicare tutte le modifiche . Le autorizzazioni appropriate aiutano a ridurre quel dolore.

— Brent Ozar
fonte

1

SA su un'istanza può conferire i diritti di Dio su tutte le istanze a causa di server collegati, ntfs ecc.

— gbn

@gbn - Non sono sicuro di seguirlo. Puoi indicarne alcuni esempi? Posso capire se stai parlando di configurazioni scadenti (come tutti i server che condividono lo stesso account di servizio) ma non sono chiaro su come lo stai realizzando quando i server sono in esecuzione con account di servizio diversi.

— Brent Ozar,

Una build standard userebbe lo stesso account di dominio in organizzazioni di grandi dimensioni. Anche se fossero diversi, sarebbero membri dello stesso gruppo AD (soggetto alle regioni, ovviamente, forse), quindi avrebbero gli stessi diritti. Ho visto entrambi in grandi organizzazioni mondiali (banche di investimento)

— gbn

9

Ok, questo è un problema diverso. Nella maggior parte delle organizzazioni sicure che ho visto, è prassi normale mettere ciascun server nel proprio account di servizio. Fa anche parte della mia lista di controllo dell'installazione di SQL Server online. Certo, se ignori quel passo ovvio di base, allora sei meno sicuro - ma che senso ha?

— Brent Ozar,

15

In realtà se leggi questo white paper: White paper sulla separazione dei compiti di SQL Server

Ti dirà che NESSUNO dovrebbe usare i privilegi di amministratore di sistema sul proprio account. Al tuo account di accesso giornaliero dovrebbe essere concesso l'accesso minimo, non i diritti espliciti di amministratore di sistema. Dato che CONTROL SERVER è in realtà vicino a ciò che è sysadmin e quindi ti consente di DENY / REVOKE accedere ancora dove non ne hanno bisogno. Consentire i diritti di amministratore di sistema a chiunque diventa un problema se viene richiesto di soddisfare gli standard di conformità IT. La maggior parte degli standard richiede un utilizzo minimo del ruolo di amministratore di sistema.

Disattivo e rinomino l'account "sa", proprio come faresti con l'account amministratore incorporato nel sistema operativo. Da usare solo in caso di emergenza.

Gli sviluppatori di solito hanno pieno accesso al loro ambiente di sviluppo. Quindi quando il loro programma viene spostato nell'istanza di pre-produzione, il loro accesso dovrebbe essere minimo o nessuno; proprio come sarebbe in produzione. Questo è un mondo perfetto. Se comunque non ci sei e i tuoi sviluppatori hanno privilegi più alti di quelli di cui hanno bisogno, controllerei il loro conto. Catturerei tutto e tutto ciò che fanno in una certa misura. Quindi, nel caso in cui qualcosa vada storto quando si trovavano sul tuo server di produzione, puoi tornare indietro e scoprire esattamente cosa hanno fatto.

— Shawn Melton
fonte

2

+1000 Quel white paper è eccellente. Ho imparato molto da questo.

— Jon Seigel,

8

Se sei soggetto a controlli o standard normativi esterni (SOX, PCI ecc.), Allora tu

fallirà un controllo
non riescono nei controlli mensili PCI

Gli sviluppatori dovrebbero avere db_owner su una rete SQL Server solo per lo sviluppo.

Se i tuoi SQL Server sono tutti sulla rete con una build standard (cioè lo stesso account di servizio), allora sa in uno conferisce diritti a tutti loro.

Se l'account del servizio è un amministratore locale, anche i tuoi sviluppatori hanno il pieno controllo sui server.

Non ci sono aspetti positivi.

— GBN
fonte

V'è un lato positivo, è solo superato dagli altri: la convenienza. È molto facile da usare per tutti sa(probabilmente con "password" come password), per questo continua come pratica.

— Jon of All Trades,

6

sa = amministratore di sistema

L'accesso con sa dà all'utente il potere di fare tutto quanto segue: - rilasciare e creare database - modificare oggetti nel database - rilasciare e creare accessi - cambiare password - eliminare tutti i dati

Concedere i privilegi di amministratore di sistema di un account Windows realizza la stessa cosa.

L'elenco potrebbe continuare, ma questo dovrebbe darti alcuni buoni motivi per NON permettere MAI MAI MAI MAI a un utente non amministratore di utilizzare sa.

È necessario creare un account Windows o SQL con i privilegi minimi necessari per far funzionare le app. (es. login, accesso a stored procedure e viste)

— datagod
fonte

5

La migliore pratica è mettere una password sicura e dimenticarla.

— Garik
fonte

1

Ho due opzioni in mente in questo momento, sul perché non si dovrebbe avere un account SA debole. Se hai una password debole / vuota per SA una persona malvagia (traducila in "collega amichevole") potrebbe:

abilitare la procedura di sistema xp_cmdshell e, usando i privilegi dell'account del servizio Sql Server, danneggiare la propria casella locale (creare / rimuovere file ..). Avere una bassa sicurezza per SA in realtà non dice molto sulle impostazioni dell'istanza, ma potrebbe implicare che l'utente del servizio potrebbe seguire cattive pratiche (come essere un amministratore :-));
abilita la posta sulla tua istanza e fai avanzare rapidamente un piccolo script divertente per lo spam (che probabilmente ti causerà qualche problema con il tuo provider di servizi Internet o con i tuoi colleghi ... a seconda di dove vanno le mail ;-));

Non sottolineerò i fatti ovvi che può eliminare database, accessi ... ecc.

Non è essenzialmente la stessa cosa? Quali sono i vantaggi / gli svantaggi?
Non necessariamente: ad es. Sull'istanza di SQL Server dal tuo laptop la differenza tra l'autenticazione di Windows e l'autenticazione di SQL significa che, in teoria, un utente malintenzionato esterno potrebbe utilizzare solo un account SQL, poiché l'autenticazione di Windows non può essere utilizzata al di fuori del proprio dominio account. Un utente potrebbe scansionare i laptop vicini dal centro commerciale dove stai bevendo il tuo caffè e potrebbe vedere che hai installato e avviato un'istanza SQL e potrebbe provare a divertirsi un po 'gratuitamente. Non è che potrebbe succedere spesso ... ma è una possibilità :-).
In che modo le migliori pratiche aumentano la sicurezza delle mie istanze di SQL Server?
Come ogni migliore pratica in questo mondo fa il suo lavoro ... diminuisce le possibilità di un possibile aspetto negativo (ad esempio: la migliore pratica di fare attività fisica diminuirà le possibilità che tu sia come me .. una patata bollente) che potrebbe accadere altrimenti.
Questo vale solo per le istanze di produzione o anche per le nostre istanze di sviluppo interno?
Diciamo che suggerirei di implementare le migliori pratiche di sicurezza (testate e modificate in base alle esigenze del tuo ambiente) almeno nella produzione. Ma se nello sviluppo usi anche i dati di produzione (sensitive..etc) di quanto indichi che devi anche modificare le tue pratiche di sviluppo.

— mariano
fonte

-1 La domanda ha davvero chiesto perché favorire l'autenticazione integrata di Windows ed evitare l'autenticazione di SQL Server mentre è semplicemente impossibile realizzare MA non come o "perché non si dovrebbe avere un account SA debole"

— Fulproof

@Fulproof: capisco quello che stai dicendo e grazie per il feedback. La mia interpretazione di un account SA debole è un account SA con una password debole / nessuna utilizzata da tutti in un'azienda. Ma la domanda è vecchia e non ricordo completamente tutti i dettagli. E avevo un accento sulla domanda principale del titolo: perché è una cattiva pratica consentire a tutti di utilizzare il login sa?

— Marian,

0

Rispondendo alla tua ultima domanda, utilizziamo gli account SA su tutti i nostri database di sviluppo (con la password "sa", a quello!)

Tuttavia, è fondamentale notare che non memorizziamo i dati e non li generiamo. I nostri database vengono utilizzati esclusivamente per un archivio dati per un'applicazione C / C ++. Questi database di sviluppo contengono puramente dati di test e vengono spesso creati, eliminati, modificati, ecc. \

Inoltre, altrettanto critici, tutti i database di sviluppo sono installati su macchine di sviluppo. (Almeno una copia per sviluppatore!) Quindi, se qualcuno ha incasinato un'intera installazione, hanno solo incasinato se stessi e nessun altro.

Quando si tratta di un ambiente in cui si desidera assicurare che il database, le tabelle e i dati siano effettivamente coerenti e sicuri, si desidera una password SA solida e solida. Se lo lasci debole, chiunque e tutti hanno pieno accesso ai tuoi dati e possono distruggere completamente il tuo database.

Per un gruppo di sviluppatori con le proprie copie del database che contengono puramente dati di test, devo ancora trovare un valido argomento per mantenere un account SA sicuro.

— Richard
fonte

1

Con sa, potrebbero abilitare XP_cmdshell per esempio e quindi richiedere che vada in prod. E come ho risposto, può conferire diritti su tutti i server. Dbo e sa parziale (creare db) ecc.: Nessun problema

— gbn

In un ambiente di sviluppo che non genera o memorizza i dati dei clienti, un ambiente in cui tutte le copie del database sono copie di prova, puramente per lo sviluppo e la distribuzione, non riesco a vedere che questo sia davvero un problema. Se c'è mai un potenziale di codice errato che colpisce i database di produzione, allora sì, posso vedere una nave un po 'più stretta.

— Richard,

0

Qualsiasi parametro di sicurezza del sistema SQL Server predefinito fornito deve essere modificato. Si consiglia di non utilizzare la modalità mista (abilita sia l'autenticazione Windows che SQL Server) per l'autenticazione. Passa invece solo all'autenticazione di Windows, che imporrà i criteri password di Windows, controllando la lunghezza della password, la durata e la cronologia. La funzionalità del criterio password di Windows che lo differenzia dall'autenticazione di SQL Server è il blocco dell'accesso: dopo un numero di tentativi successivi di accesso non riusciti, l'accesso diventa bloccato e inutilizzabile per un ulteriore utilizzo

D'altra parte, l'autenticazione di SQL Server non fornisce alcun metodo per rilevare i tentativi di attacco di forza bruta e, peggio ancora, SQL Server è persino ottimizzato per gestire un gran numero di tentativi di accesso rapido. Pertanto, se l'autenticazione di SQL Server è un must in un particolare sistema SQL Server, si consiglia vivamente di disabilitare l'accesso SA

— Ivan Stankovic
fonte