Perché un'applicazione non dovrebbe utilizzare l'account sa

La mia prima domanda in assoluto, per favore sii gentile. Comprendo che l'account sa consente il controllo completo su un SQL Server e tutti i database, utenti, autorizzazioni ecc.

Sono assolutamente convinto che le applicazioni non debbano utilizzare la password sa senza un motivo perfetto e incentrato sull'uomo d'affari perché. Le risposte a questa domanda includono molti dei miei ragionamenti per una discussione incentrata sull'IT

Sono stato costretto ad accettare un nuovo sistema di gestione dei servizi che NON funzionerà se non utilizza la password sa. Non ho mai avuto il tempo di capire perché durante l'impostazione di una valutazione, ma il team del server ha provato a installarlo per utilizzare un ruolo fisso che avevo impostato incorporando db_creater e altre autorizzazioni che pensavo avrebbero richiesto. che ha fallito. Ho quindi lasciato installare il team del server con l'account sa ma eseguito con un account nel ruolo dbo per il suo database ma anche quello non è riuscito. Scontrosamente ho provato a farlo funzionare con un account nel ruolo di amministratore di sistema, ma anche quello non è riuscito e non con utili messaggi di errore che mi hanno permesso di capire cosa stava succedendo senza spendere più tempo di quanto avessi a disposizione. Funzionerà solo con l'account sa e la password memorizzati in chiaro nel file di configurazione.

Quando ho fatto una domanda e il team del server ha parlato con il fornitore, hanno ottenuto la preoccupante risposta di "Qual è il problema?" e poi 'beh, possiamo guardare a criptare la password' a criptare ffs

So che ci sono modi e mezzi per limitare l'accesso al file, ma secondo me è solo un altro punto debole della sicurezza

Comunque, la mia domanda è, qualcuno potrebbe indicarmi un po 'di documentazione che posso usare per spiegare all'azienda il motivo per cui questa è una brutta cosa e dovrebbe essere un grande no no. Lavoro in un campo che significa che devo prendere sul serio la sicurezza e ho lottato per far capire il business e alla fine potrebbe essere fuori posto, ma devo provare.

Dipende dal vostro business, ma la cosa principale nella maggior parte dei casi è quello di assicurarsi che sia , non visto come un problema IT. È un problema di sicurezza e mentre i due si sovrappongono in maniera massiccia, le persone del business hanno maggiori probabilità di ascoltare se si dice "sicurezza" che se si "si lamentano delle cose IT generali".

Lavori con clienti che hanno requisiti di sicurezza? Questo è un buon punto di partenza. Se avessimo eseguito un'app con accesso a livello di sa, o solo un'app che non proteggeva correttamente le sue credenziali anche se non usavamo l'accesso con privilegi (preferiamo fortemente Windows integrato piuttosto che utente / pass memorizzato dove possibile), e siamo stati soggetti a una sicurezza audit, tale audit fallirebbe e rischieremmo di perdere clienti e / o dover restituire i soldi ai clienti dei nostri gruppi (organizzazioni bancarie nel caso del prodotto su cui lavoro principalmente, altre parti del gruppo si occupano di polizia e salute autorità e così via) la sicurezza fa parte della nostra offerta di essere idonei allo scopo. Gli uomini d'affari potranno capire la gravità di tale potenziale minaccia anche se di solito non più di a parole pagano per raccomandazioni.

Anche ignorando i requisiti imposti dal cliente, se ci si sforza di soddisfare vari standard di sicurezza standard del settore, anche in questo caso questo tipo di autenticazione dell'applicazione fallirà di fronte a un controllo in quanto è così lontano dalle migliori pratiche da essere considerato generalmente nell'elenco "semplicemente non dovrebbe essere fatto". Metti in chiaro ai responsabili della tua decisione aziendale che la sicurezza è una parte importante dell'applicazione e che il fatto che questo venditore non sembri essere consapevole (o almeno adeguatamente preoccupato) ti fa dubitare di cos'altro potrebbero non essere in grado di fare occuparsi di: conoscere le migliori pratiche di sicurezza del DB è (bene, dovrebbe essere) parte del loro lavoro e implementarlo non è difficile.

Ricorda inoltre che tu (l'acquirente) dovresti dettare ragionevoli requisiti di sicurezza al venditore, non viceversa. Sono i tuoi dati, quindi non sono qualificati per dichiarare ciò che è considerato abbastanza sicuro.

Nessuna applicazione deve avere accesso SA - mai. (A meno che il suo unico scopo sia l'amministrazione del database di qualche tipo.)

È una regola generale non concedere mai più diritti a qualsiasi accesso (applicazione o personale) di quanto l'azienda richieda tale accesso.

Nessuna applicazione è completamente sicura. La maggior parte ha qualche tipo di vulnerabilità di SQL Injection o XSS. Se un intruso riesce a eseguire una dichiarazione di sua scelta e ha accesso "SA", ci possono essere molte cose che possono accadere ai tuoi dati che potrebbero uccidere immediatamente l'azienda. (Soprattutto se i dati devono essere considerati attendibili perché utilizzati dalle forze dell'ordine.) Chiedere agli stakeholder cosa dovrebbero fare, se qualcuno fosse in grado di modificare deliberatamente anche un singolo record e che le informazioni fossero trapelate.

Ora, con accesso "SA", non solo il database dell'applicazione potrebbe essere modificato, ma anche ogni altro database sul sistema. Quindi, chiedi ai tuoi stakeholder cosa farebbero se realizzassero una copia di TUTTI i tuoi database e la spedissi al giornale. Perché ciò potrebbe accadere se un dipendente scontento capisse l'esistenza di questo buco nella sicurezza.

Il venditore ha detto che potrebbero confondere la password. Questo è BS. L'applicazione deve accedere alla password in chiaro per usarla, quindi la chiave per decodificare la password verrebbe memorizzata decodificata proprio accanto ad essa. Inoltre, come accennato in precedenza, il vero problema non è qualcuno che trova questa password; è che le persone (mis) che usano questo sistema attraverso una vulnerabilità avranno pieno accesso a tutti i tuoi database senza mai vedere la password.

La causa più probabile della richiesta di SA è che l'applicazione deve interagire con SQL Agent. Almeno questa è una delle funzioni più difficili da implementare nel modo giusto e la maggior parte delle persone prende la strada "usa SA" per aggirarla. La richiesta di "SA" potrebbe essere dovuta al fatto che il fornitore non è in grado di verificare le autorizzazioni di amministratore di sistema.

Esistono due soluzioni che puoi provare:

1. Rinominare SA (una best practice sulla sicurezza in ogni caso) e creare un nuovo account chiamato "SA" con diritti limitati. (Non l'ho mai provato, ma dovrebbe funzionare)

2. Non installare il software. Come professionista non puoi essere responsabile di tale azione, quindi non dovresti installarlo. Per fare un confronto, chiedi a un idraulico di far passare la linea del gas direttamente attraverso il camino invece che attorno ad esso per risparmiare un po 'di pipa / denaro. Potresti ridere di questa immagine, ma credo che sia un paragone appropriato - Questo software esploderà prima o poi, probabilmente prima. E quando lo fa potrebbe anche far fallire l'attività.

Se tutto ciò non impedisce a "loro" di richiedere questo software, l'ultima raccomandazione che posso darti è di eseguire. Se succede qualcosa ai dati, sarai il primo ad essere ritenuto responsabile. Quindi, con questa applicazione in atto probabilmente non hai alcuna sicurezza del lavoro, quindi trova un datore di lavoro che ti dia almeno un po '.

Vedo due linee per attaccare questo.

• Compliance . Esistono criteri di conformità obbligatori in vigore nel tuo negozio? Cerca attentamente attraverso la sua formulazione e vedi se trovi qualcosa che sarebbe incompatibile con il 'requisito' dell'applicazione. Se trovi qualcosa che ne impedisce l' sauso da parte di un'applicazione, hai una custodia impermeabile a prova di proiettile, poiché l'applicazione renderebbe la tua azienda responsabile ecc. Ecc.

• Accesso amministratore utente . Assicurati di presentare chiaramente il caso in cui un'applicazione che richiede l' saaccesso in effetti fornisca l' saaccesso a tutti gli utenti aziendali che dispongono dei diritti di amministratore sulle workstation in cui è installata l'applicazione. Non c'è modo di nascondere la sapassword agli amministratori locali in cui è in esecuzione l'applicazione, questo è un dato di fatto e nessuna quantità di 'scrambling' può impedirlo. Non esiste una radice di fiducia locale che un amministratore locale non può ottenere, se lo desidera. Rendi chiaro che avere un'applicazione che richiede saequivale a dare saprivilegi a tutti gli utenti che eseguono l'applicazione. Spiega cosa significa, cosa efficacemente gli utenti possono fare:

  • capacità di leggere qualsiasi dato nel server, non solo da questa applicazione ma da qualsiasi altro database ospitato su quel server
  • possibilità di modificare qualsiasi dato sul server, sempre da qualsiasi altro database sullo stesso server
  • capacità di cancellare qualsiasi traccia delle sue azioni dopo aver apportato una modifica
  • capacità di modificare qualsiasi audit e cronologia per far sembrare che determinate azioni siano state eseguite da un altro utente
  • capacità di utilizzare le credenziali di SQL Server per intensificare un attacco a qualsiasi altra risorsa che si fida di questo server. Ciò può implicare qualsiasi altro SQL Server ma anche altre risorse, inclusi ma non limitati a condivisioni di file, server di Exchange ecc., Poiché SQL Server può essere utilizzato solo come trampolino di lancio.

Spiegare ai decisori che accettare questa applicazione implica affidare a tutti i dipendenti che hanno accesso come amministratore alle workstation che eseguono l'applicazione con tutti i privilegi sopra menzionati. Il fornitore proverà a difendere la propria posizione invocando una sorta di "crittografia" della sapassword per l'applicazione. Questo non trattiene l'acqua. Non esiste uno schema di crittografia in grado di resistere a un attacco di un amministratore. E chiarire che la quantità di abilità tecnica richiesta per trovare una password localmente "nascosta" è completamente irrilevante. I dipendenti non lo faranno da soli, uno di loro lo farà su Google e scoprirà lo script facile da usare che lo fa.

Innanzitutto, la password sa è memorizzata in chiaro? Dovresti votare con il tuo portafoglio. Chi pensa che sia accettabile deve essere messo fuori servizio.

Ecco un'anologia che potrebbe aiutarti a spiegare il problema: la dipendente Alice ha bisogno di accedere al primo piano. Le dai la chiave principale dell'intero edificio o solo la chiave del primo piano? Risposta: Le dai solo le chiavi del primo piano. Perché? Perché riduce la possibilità di danni accidentali o intenzionali. Se Alice non riesce a raggiungere la sala server del secondo piano, in primo luogo, non farà mai nulla di male.

È il principio del minimo privilegio.

Sul motivo per cui l'applicazione deve utilizzare l'account sa, questa è una domanda a cui PerfMon o Extended Events dovrebbero essere in grado di rispondere. Crea una traccia PerfMon usando il modello T-SQL, magari filtrato per nome dell'applicazione.

Al di sopra della mia testa, ecco un altro argomento contro l'utilizzo di sa: l'utilizzo dell'account sa richiede che il servizio SQL Server sia in modalità di autenticazione mista. L'autenticazione solo su Windows è meglio perché possiamo sfruttare tutte le funzionalità sicure di Kerberos.

Da un punto di vista tecnico non c'è motivo per cui un'applicazione abbia bisogno delle autorizzazioni SA. Ciò che probabilmente è accaduto è che gli sviluppatori dell'applicazione probabilmente controllano se il loro login ha autorizzazioni sysadmin e, in caso contrario, genera semplicemente un messaggio di errore. In questo modo possono affermare che l'applicazione richiede diritti SA.

Se devi avere questa applicazione, la eseguirò su un'istanza separata che non contiene nient'altro.

Forse il tuo fornitore richiede / richiede "sa" perché da qualche parte nella sua applicazione stanno usando XP_CMDSHELL. (Non farmi iniziare sul danno possibile con accesso illimitato a XP_CMDSHELL. Basti pensare che questo potenzialmente apre non solo i tuoi dati ma il computer host e, forse, qualsiasi altra cosa sulla tua rete ad un accesso simile all'amministratore)

In caso di necessità legittima, è possibile fornire un accesso limitato tramite un account proxy. Vedi, ad esempio, BOL: http://msdn.microsoft.com/en-us/library/ms175046.aspx

Nessuna applicazione deve richiedere l'account e la password SA per funzionare.

Tuttavia, ho installato un prodotto di gestione dei servizi IT e durante il processo di installazione hai la possibilità di fornire le credenziali dell'account SA per consentire all'installatore di creare il DB e allegare un account al DB da utilizzare per il software. Le credenziali dell'account SA non vengono salvate nei registri dell'applicazione o dell'installer da nessuna parte. Questo software offre anche la possibilità di utilizzare un database pre-creato durante l'installazione.

Quindi vorrei solo confermare se è necessario l'account SA per l'installazione o il funzionamento di questo software di gestione dei servizi IT.

Se installazione: creare un account 'sa' temporaneo - eseguire l'installazione - e rimuovere l'account.

Se Operazione: evitare quel software come la peste. (o imposta un server SQL autonomo che ospiterà solo quel database.)

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