Protezione

Problemi di protezione di SQL Server comuni e soluzioni

Paul S. Randal

 

In un riepilogo delle:

  • Fisico e protezione di rete
  • Attacchi superficie, account di servizio e privilegi minimi
  • Inserimento di autenticazione, autorizzazione e SQL
  • Ripristino di emergenza e il controllo

Contenuto

Protezione fisica
Protezione di rete
Attacchi Minimization superficie
Account di servizio
Limitare l'utilizzo di privilegi di amministratore
L'autenticazione
Autorizzazione
Infiltrazione SQL
Ripristino di emergenza
Controllo
Riepilogo

Chiunque è stato attorno il settore IT sa che protezione è un argomento nello stato attivo.Dopo tutto, dei dati di una società sono uno dei cespiti più prezioso che è e proteggere i dati è fondamentale.Come È stato pianificazione da scrivere per questo problema di protezione, si tenta di stabilire quali funzionalità di protezione deve dispone di un intero articolo dedicato a esso.Ma quindi È avviato da considerare i numeri burgeoning di "DBA involontarie" (i professionisti IT che inavvertitamente risultato dei responsabili di un'istanza di SQL Server e la risposta grande che è stato necessario ilSuperiore suggerimenti per la manutenzione dei database validearticolo dal numero di agosto 2008.Riporta me che operazioni deve eseguire è scrivere un articolo che copre comuni problemi di protezione SQL Server, un tipo di panoramica per la protezione migliore per le istanze di SQL Server.

Un articolo che descrive tutti i problemi di protezione che è consigliabile effettuare la ricerca in sarebbe un'intera rivista in sé, pertanto canvassed mio fellow MVP di SQL Server e mia moglie per l'input per che cosa È necessario includere.Liquidato fornire le aree di protezione 10 superiore che si ritiene necessario preoccuparsi se non si è un amministratore di database savvy la protezione e improvvisamente manualmente responsabile di un'istanza di SQL Server sia associato dell'applicazione.Tenere presente che questo assolutamente è un elenco completo. Per ogni problema È stato assegnato una breve panoramica del problema, suggerimenti su come ridurre e un collegamento ulteriori informazioni.

Tutti i collegamenti alla documentazione in linea sono per le versioni di SQL Server 2008, ma ogni pagina Web si collega agli anche la versione di SQL Server 2005.Disposizione dell'articolo, sono disponibili collegamenti alle principale white paper e documentazione in linea di sezioni per la protezione per SQL Server 2005 e SQL Server 2008.

Protezione fisica

È fondamentale non solo valutare la protezione di SQL server stesso, ma tutti i livelli devono essere considerati per accedere a SQL Server in primo luogo in.Per questo concetto di protezione a più livelli, spesso denominato "Defense in dettaglio," non protetto solo un livello, ma si consiglia l'intero sistema.

La considerazione prima più ovvia è la protezione fisica del computer che eseguono SQL Server, questo livello, tuttavia, è spesso omesso o è l'oggetto del complacency.È possibile non sono riferimento semplicemente se furto del computer o non, ma anche accesso fisico a elementi quali il sistema di archiviazione che ospitano i file di database, i nastri di backup e qualsiasi server che ospitano ridondanti copie del database.Solo le persone con un tocco fisicamente questi oggetti è necessario effettivo devono dispone di accesso a essi, chiunque deve disporre dell'accesso temporaneo deve essere accompagnata e monitorati.

Una considerazione meno evidente è la protezione del desktop delle persone che hanno accesso privilegiato alta a SQL Server.Se un utente dispone di sysadmin accesso a SQL Server ma lasciare Windows desktop sbloccato, quindi la protezione nel mondo non desidera impedire a qualcuno esame oltre il sistema automatico di potenzialmente accedere a dati riservati.Un problema più insidious sarebbe se qualcuno past esaminato e modificati alcuni dati, ad esempio, un dipendente dishonest che conosce lo schema del database delle risorse umane e tenta di modificare undetectably un stipendio.

Non c'è un molto interessante TechNet white paper (incluse un deck diapositiva-schema e webcast), dal titolo"Protezione fisica in Microsoft" cui viene descritto il modo in cui Microsoft gestisce la protezione fisica dei relativi server molti.

Protezione di rete

Anche se i server potrebbero essere fisicamente inaccessibili, probabilmente è connessi a una rete di vario genere.È possibile solo un'isolata società LAN senza all'esterno di connessioni oppure può essere una connessione diretta a Internet.Indipendentemente dal quale la situazione, esistono alcune operazioni che è necessario prendere in considerazione:

  • Accertarsi che il server di Windows disponga di protezione di rete corretta configurato.
  • Decidere i protocolli di rete per consentire e disattivare qualsiasi non sono necessari.
  • Verificare che sia un set di firewall alto (ad esempio Windows Firewall) e configurarlo per consentire l'accesso a SQL Server (come illustrato nellaNella figura 1).
  • Decidere se si desidera crittografare le connessioni a SQL Server e configurare correttamente.
  • Se verrà utilizzato Kerberos, è necessario registrare un nome di server principale.Kerberos è un meccanismo di autenticazione underpins l'autenticazione di Windows (che è possibile descrivere più avanti in questo articolo), ma è riconosciuto.Una descrizione chiara e concisa fornita dal Greene Rob, Support Escalation Engineer, nel post del blog"Kerberos per l'amministratore non disponibile.." SI consiglia di estrarlo.
  • Decidere se utilizzare il servizio SQL Server browser per client individuare le istanze di SQL Server installate e decidere se si desidera nascondere alcuni casi.Nascondere un'istanza significa che le applicazioni client e gli utenti dovranno conoscere i dettagli di connessione dell'istanza di SQL Server, ma impedisce agli utenti di trawling alla rete per cercare le istanze di SQL Server.

fig01.gif

Figura 1 configurazione Windows Firewall per consentire l'accesso TCP a SQL Server

Tutte queste attività (e altro ancora) vengono descritte in 2008 documentazione in linea di SQL Server, inizia con l'argomentoConfigurazione di rete server. Inoltre, esiste una buona sezione suConfigurazione di rete client.

Attacchi Minimization superficie

Altri servizi e funzionalità che vengono attivate, il più attacchi area superficie o superficie è disponibile per guys non valido a possibili attacchi.SQL Server 2005 ha richiesto la "off per impostazione predefinita" strategia, le caratteristiche implicazioni a livello di protezione per impostazione predefinita sono disattivate e vengono attivate solo per l'amministratore di database quando necessario.(Questo processo di attivare e disattivare servizi viene in genere chiamato Configurazione superficie di attacco.)

Un primo esempio di una funzionalità che è opportuno disattivato è xp_cmdshell, che fornisce un modo di esecuzione dei comandi su host sistema Windows da all'interno del contesto di un'istanza SQL Server.Se compromessi un intruso l'istanza di SQL Server e l'account del servizio SQL Server con elevate privilegi Windows, xp_cmdshell utilizzabile per accedere al sistema di Windows, troppo.

Sono disponibili numerosi metodi per la configurazione superficie di attacco.SQL Server 2005 e SQL Server 2008 supporta la Gestione configurazione SQL Server per la configurazione di servizi e i protocolli di rete.Entrambi supportano anche la procedura di sp_configure memorizzati per la configurazione funzionalità del modulo di gestione di database e opzioni.Ad esempio, questo codice verrà disattivare la funzionalità di xp_cmdshell:

-- To allow advanced options to be changed
EXEC sp_configure 'show advanced options', 1;
GO
-- To update the currently configured value for -- advanced options
RECONFIGURE;
GO
-- To disable xp_cmdshell
EXEC sp_configure 'xp_cmdshell', 0;
GO
-- To update the currently configured value for this -- feature
RECONFIGURE;
GO

I metodi grafici di configurare le opzioni del modulo di gestione di database e le funzionalità sono molto diversi tra le due versioni. SQL Server 2005 ha introdotto lo strumento Configurazione superficie di SQL Server superficie area configurazione (ATTACCO). Consente di condividere facilmente le modifiche. Nella figura 2 , viene ad esempio illustrato come è possibile disattivare xp_cmdshell tramite Configurazione superficie di ATTACCO.

fig02.gif

Nella figura 2 xp_cmdshell disabilitazione mediante Configurazione superficie di ATTACCO di SQL Server 2005

In SQL Server 2008, Configurazione superficie di ATTACCO è stato completamente rimosso e la funzionalità incluso dalla funzionalità Gestione basata su criteri. È possibile trovare ulteriori informazioni su questo nell'argomento della documentazione in linea di SQL Server 2008 (informazioni in lingua inglese)" Amministrazione server tramite Gestione basata su criteri." Nella figura 3 di questo descritto come creare una condizione da verificare che tale xp_cmdshell è disattivato. Una volta configurato, i criteri possono assegnare istanze di SQL Server 2005 e SQL Server 2008 e possono anche essere "applicati," consente di modificare essenzialmente l'impostazione con un solo clic del mouse.

fig03.gif

Nella figura 3 di creazione di una condizione di gestione basata su criteri in SQL Server 2008

Account di servizio

SQL Server viene eseguito come uno o più servizi di Windows e ogni servizio deve dispone di un account di Windows viene utilizzato per eseguire il servizio. L'account deve poter accedere a varie risorse nel sistema di Windows (ad esempio la rete e diverse directory del file System). La procedura consigliata consiste per l'account dispone dei privilegi possibili almeno necessari per consentire il corretto funzionamento di SQL Server. Questo fa parte di ciò che viene chiamato il principio del privilegio minimo, quali stati di un sistema può avvenire più proteggere assegnando un utente o elaborare solo i privilegi necessari e niente più.

Di conseguenza, un account di servizio di SQL Server deve non essere un account con privilegi alta (come sistema locale o di amministratore locale) poiché se SQL Server è compromessa, è la possibilità che il sistema di Windows anche essere compromessa. I servizi è in genere eseguiti con un account incorporato denominato servizio di rete, ma se SQL Server richiede l'accesso alle altre risorse di dominio, deve essere creato un nuovo account utente di dominio i privilegi minimi e risorsa accesso richiesto. L'argomento nella documentazione in linea di SQL Server 2008" Impostazione degli account di servizio Windows"fornisce un elenco completo di account di servizio, dei privilegi necessari e risorse. Si noti che se è necessario modificare un account di servizio (o qualsiasi informazioni), si deve sempre utilizzare Gestione configurazione SQL Server per garantire che tutte le modifiche di configurazione necessarie vengono eseguite correttamente.

Limitare l'utilizzo di privilegi di amministratore

L'accesso di esposizione l'associazione di protezione più o il ruolo predefinito del server sysadmin dispone di, la possibilità più è disponibile per una violazione della protezione, o un caso. Esistono alcune procedure consigliate per seguire.

Ridurre al minimo il numero di persone che hanno accesso all'account dell'associazione di protezione e limitare l'appartenenza del ruolo sysadmin (e altri ruoli con privilegi) in modo solo le persone che effettivamente necessario privilegi sysadmin dispone. Non assegnare out la password SA a chiunque temporaneo di accedere a SQL Server o a un utente SQL che si desidera eseguire alcune attività rapido. In queste situazioni, creare un nuovo account di accesso SQL e concedere il privilegio è richiesto.

È preferibile persone come membri del ruolo sysadmin anziché l'account SA. In questo modo, è possibile rimuovere accesso un utente senza dover cambiare la password dell'account SA. Se assumere un vecchio server e non avere alcuna idea che aveva accesso prima modifica la password SA pertanto si è nel controllo.

Uno dei problemi che provokes polemica è se rimuovere il gruppo BUILTIN o Administrators di Windows dal ruolo sysadmin (per impostazione predefinita la aggiunta). Un amministratore di Windows sarà in grado query sul database personale? O come della società in modo esplicito attendibile tutti gli amministratori dell'integrità e honesty? Se si desidera rimuoverlo, procedere con cautela. Ciò è particolarmente vero in un ambiente cluster in cui se non eseguire la procedura corretta, SQL Server potrebbe non avviato. Per ulteriori informazioni su questo e altri problemi relativi al clustering, vedere l'articolo della Knowledge Base" Azioni del server SQL in cluster, Don'ts e avvisi di base."

Per coloro che si ha accesso sysadmin, incoraggiare non per l'accesso con privilegi elevati, a meno che non strettamente necessario, assegnare ciascuno di questi account di accesso agli utenti due, privilegiato uno e uno non. Utilizzando l'account nonprivileged per impostazione predefinita consente di ridurre al minimo il rischio di errori costosi e inoltre consente di ridurre la probabilità che un sbloccato Windows terminal avrà una finestra con i privilegi sysadmin aprire su esso. Ricordare difesa in profondità.

L'ultimo punto che verranno apportate in questo campo è per evitare di applicazioni che richiedono privilegi sysadmin. Sfortunatamente, questa è di norma errato comune e unavoidable con alcune applicazioni, ma deve evitare questa esercitazione in applicazioni personalizzate e reclamare presso di qualsiasi agli sviluppatori di applicazioni che richiedono privilegi sysadmin.

L'autenticazione

Sono disponibili due modalità di autenticazione: Autenticazione di Windows e a modalità mista (ovvero l'autenticazione di Windows combinato con l'autenticazione di SQL Server).

L'autenticazione di Windows utilizza gli account di dominio di rete e per convalidare l'account Windows utilizzato per la connessione a SQL Server. Se questa opzione è selezionata durante l'installazione, l'account SA è creato con una password casuale, ma disattivata in modo efficace. Immediatamente dopo l'installazione, è necessario modificare la password SA con una password complessa e protetta ma continuare a lasciare l'account disattivato, a meno che non strettamente necessario.

L'autenticazione di SQL Server si basa su ciascun utente con un account di SQL Server e la password memorizzata in SQL Server definito. E, naturalmente, ciò che l'account SA è attivata e deve avere una password definita. Con l'autenticazione di SQL Server, gli utenti hanno almeno due nomi utente e password (uno per la rete) e uno per SQL Server. In genere è consigliabile utilizzare solo l'autenticazione di Windows quando possibile, come nel caso di una soluzione più sicura. L'argomento nella documentazione in linea" Scegliere una modalità di autenticazioneviene " descritto in questo in dettaglio, insieme con le procedure cambiare la modalità di autenticazione.

Se viene utilizzata l'autenticazione di SQL, quindi tutti gli utenti devono hanno una password complessa, ovvero quella è sufficientemente complessa da resistente da individuata da un programma cracking password. Questo è particolarmente importante per gli account con privilegi alta, come associazione di protezione e i membri del ruolo sysadmin. (Uno dei più comuni ancora peggiore procedure utilizzata da una password SA vuota. Fortunatamente, come di SQL Server 2000 SP3, non è possibile.)

Password devono essere modificate anche regolarmente e la società deve pubblicare i criteri aziendali per i dipendenti attenersi alle password sicura e sicuro procedure consigliate per. Per una panoramica delle procedure consigliate per la creazione e la protezione password complesse, vedere l'articolo" Password complessa: come creare e utilizzare loro." È possibile incorporare questi criteri in un criterio azienda.

Se SQL Server 2005 o SQL Server 2008 è in esecuzione in Windows Server 2003 o versioni successive, è possibile rendere Utilizzo di Windows meccanismi dei criteri password per imporre i criteri di complessità e scadenza. La sezione della documentazione in linea di SQL Server 2008 (informazioni in lingua inglese) denominato" Criteri di password"presenta informazioni sul supporto per le password complesse e vari criteri di password in SQL Server.

Autorizzazione

Come HO già accennato, una delle seguenti dottrine della protezione dei sistemi ha utilizzare il principio del privilegio minimo. Mentre questo si applica direttamente ai privilegi di livello di amministratore, anche all'autorizzazioni per gli utenti database regolare. Un utente in un database sarà (probabilmente) non è in grado di accedere ai dati in un altro database. Il proprietario di una serie di tabelle non sarà in grado di mess con le tabelle di un altro utente. Gli utenti devono solo potranno accedere ai dati che si suppone di accedere a e quindi anche devono solo essere in grado di eseguire azioni necessarie sui dati (ad esempio SELECT, ma non UPDATE o DELETE).

Tutto ciò può essere eseguita all'interno di SQL Server da un sistema completo e gerarchicamente organizzata autorizzazioni in cui gli utenti o ruoli (denominati entità) vengono concesso o negati determinate autorizzazioni specifiche determinate risorse (denominato securables) ad esempio un oggetto, schema e database. Cenni preliminari della gerarchia di autorizzazioni di SQL Server sono illustrato nella Figura 4 . Questo implica inoltre di seguire il principio del privilegio minimo. Ad esempio, non impostare tutti i database gli sviluppatori di membri del ruolo db_owner. Limita autorizzazioni per il ruolo public e concedere solo autorizzazioni al livello più basso (utente o ruolo) per ridurre al minimo l'accesso diretto. Una descrizione completa di procedure consigliate per autorizzazioni esula dall'ambito di questo articolo, ma la documentazione in linea di SQL Server 2008 include una sezione denominata" Identità e il controllo di accesso (modulo di gestione di database)"che offre gli elenchi di espansione in tutti i concetti.

fig04.gif

Nella figura 4 gerarchia autorizzazioni il server SQL

Per consentire autorizzazioni più granulari e migliore separazione dei ruoli all'interno di un database, SQL Server 2005 ha introdotto la separazione tra utente-schema, in cui gli schemi sono indipendenti gli utenti del database e contenitori solo degli oggetti. In questo modo molte modifiche di comportamento, comprese maggiore precisione specifiche per la gestione autorizzazioni. (Quattro parti di denominazione segue server.database.schema.object il formato in SQL Server 2005 e SQL Server 2008, il formato in precedenza era server.database.owner.object.)

Ad esempio, è possibile creare uno schema con gli sviluppatori di database specificati autorizzazioni CTRL. Possono essere CREATE, ALTER e uno degli oggetti all'interno degli schemi controllo ma non presentano autorizzazioni implicite a schemi all'interno del database e non sono necessari diritti db_owner per DROP database lo sviluppo. Consente inoltre agli utenti di database di essere eliminato senza dover recode tutti gli oggetti correlati o l'applicazione con un nuovo nome utente di separazione tra utente e dello schema, gli oggetti sono membri di uno schema e non correlate al creatore dell'oggetto.

È consigliabile utilizzare gli schemi per la proprietà degli oggetti a causa dei seguenti motivi. Ulteriori informazioni sono reperibili nella documentazione in linea di SQL Server 2008 nell'argomento" Separazione di schema dall'utente."

Un altro di impedire agli utenti di eseguire operazioni che non è previsto per eseguire consiste nel disattivare accesso diretto alle tabelle di base. Questa operazione è possibile, fornendo le stored procedure e funzioni che vengono utilizzate per incapsulare, controllo e isolare operazioni come aggiornamenti ed eliminazioni e fornendo visualizzazioni controllato e ottimale seleziona.

Infiltrazione SQL

Uno dei metodi più comuni di ottenere l'accesso non autorizzato ai dati consiste nell'utilizzare un attacco SQL. SQL injection possibile utilizzare molti moduli, ma l'approccio primaria sfrutta codice che utilizza stringhe costruite in modo dinamico e inserisce codice imprevisto nel costrutto. Ad esempio, l'attacco seguenti sfrutta scarse prestazioni scritta logica di convalida input dell'utente a mano SQL Server in accetta input includendo caratteri di escape nella stringa di input. Sebbene contrived, in questo esempio evidenzia ciò che può verificarsi quando codice costruisce dinamicamente stringhe con input che non è completamente convalidati:

DECLARE @password VARCHAR (20);
DECLARE @input    VARCHAR (20);
DECLARE @ExecStr  VARCHAR (1000);

SELECT @password = 'SecretSecret';

-- assume application gets input 'OR''='
SELECT @input = '''OR''''=''';

SELECT @ExecStr = 'IF ''' + @password + ''' LIKE ''' + @input + ''' PRINT ''Password Accepted''';

EXEC (@ExecStr);
GO

Se si esegue questo codice, verrà stampata la frase "password accettato" anche se l'input dell'utente chiaramente non corrisponde la stringa della password. L'input dell'utente contiene una sequenza di escape modificare la logica di Transact-SQL perché l'input non corretto è stato analizzato e archiviato.

Intrusivo nel codice SQL non deve essere un problema per un'applicazione well-written e non esistono alcuni accorgimenti specifici come utilizzando QUOTENAME per da identificatori delimitati). Ma se si eredita un'applicazione precedente (o forse un progetto homebrew che è stata un'applicazione azienda), è necessario in particolare verificare per verificare se è vulnerabile a attacchi intrusivi nel codice SQL. Sono disponibili varie tecniche disponibili per ridurre attacchi intrusivi nel codice SQL. Documentazione in linea di SQL Server 2008 (informazioni in lingua inglese) è una sezione completa, inizia con l'argomento da denominato" Infiltrazione SQL."

Ripristino di emergenza

Quanto è necessario preoccuparsi di questo varia a seconda che cosa sono i requisiti di perdita di tempi di inattività e dei dati. (Se tali requisiti non sono già definite, è necessario!) Potrebbero verificarsi problemi di protezione a molti livelli. Esistono alcuni problemi di ripristino d'emergenza comporta il failover a un altro server di SQL o la necessità di ripristinare un database contenente i dati crittografati.

Nel primo caso, si verificano problemi quando gli account di accesso necessarie per accedere al database non sono stato duplicato sul server di failover, ad esempio, quando utilizzando distribuzione dei log o il mirroring del database. Se il failover del database all'istanza del server mirror e l'applicazione tenta di connettersi utilizzando un account di accesso specifico che non esiste sul server mirror, l'applicazione verrà visualizzato l'errore 18456 "accesso non riuscito". Gli account di accesso fanno parte di ecosistema l'applicazione e deve essere definito nell'istanza che ospita il database. Articolo della Knowledge base 918992" Procedura di trasferimento l'account di accesso e la password tra istanze di SQL Server 2005" viene descritto come eseguire questa operazione, e verrà discusso risoluzione dei problemi errore 18456 in un momento.

Nel secondo caso, i problemi si verificano quando il backup del database contiene dati crittografati e di crittografia chiave (o le chiavi) utilizzato per crittografare i dati non sono stati eseguito il backup o non sono disponibili in istanza di SQL Server in cui il database da ripristinare. Caso migliore è che solo alcuni dei dati nel database è crittografato e non è possibile accedere solo questo sottoinsieme di dati. Lo scenario di caso peggiore è l'intero database è stato crittografato utilizzando trasparente dati crittografia TDE in SQL Server 2008. In questo caso, se il certificato di server utilizzato per proteggere la chiave di crittografia del database non è stato eseguito il backup o non è disponibile, Impossibile ripristinare l'intero database e verranno restituiti i seguenti errori:

Msg 33111, Level 16, State 3, Line 1
Cannot find server certificate with thumbprint
'0xFBFF1103AF133C22231AE2DD1D0CC6777366AAF1'.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

Naturalmente, questo è il punto TDE, che qualcuno avvenga in un backup del database crittografato stray Impossibile ripristinarlo e accedere ai dati riservati. Se invece i dati sono proprio ed è necessario per accedervi, quindi è necessario disporre il certificato di server disponibile oppure i dati vengono persi.

Crittografia è un argomento notevole in sé e presenta la copertura completa nel 2008 documentazione in linea di SQL Server, a partire dal " Crittografia di SQL Server"della sezione. È inoltre possibile controllare mi illustrare TDE e ripristinare una seconda istanza in un relativo screencast di video disponibili in .com/suggerimenti.

Controllo

Uno degli aspetti più importanti che è necessario eseguire per migliorare la protezione di un sistema consiste nell'implementare controllo. Con questo, si saprà che eseguire cosa. Potrebbe anche trattarsi obbligatorio, a seconda della natura dell'azienda.

Minima, si deve controllare account di accesso non riuscito e riusciti in modo che sia possibile capire immediatamente se, ad esempio cinque tentativi di accesso non sono stati seguiti da una corretta. Quindi si sa quando un utente sta tentando interrompere nell'istanza di SQL Server e con quale account di accesso. Nella figura 5 Mostra configurazione di controllo di accesso tramite la finestra di dialogo Proprietà server in SQL Server 2005 Management Studio. Accessi non riusciti vengono controllati come 18456 nel log degli errori del messaggio e lo stato di errore fornisce il motivo dell'errore. La descrizione migliore che È Impossibile trovare di diversi stati, oltre ad una discussione lunga su risoluzione dei problemi, è in un post da guerra Il-Sung nel blog protocolli SQL intitolato" Informazioni sulle 'Accesso non Riuscito' (errore 18456) messaggi di errore in SQL Server 2005."

fig05.gif

Nella figura 5 Confi guring accesso controllo in SQL Server 2005 Management Studio

Controllo completo di tutte le azioni risulta difficile in SQL Server 2005 e anche rientra nello scopo di questo articolo. Prevede vari trigger e traccia SQL. In SQL Server 2008, controllo è stato notevolmente semplificato con l'introduzione di una nuova funzionalità: controllo di SQL Server. Questo è illustrato in un recente, molto dettagliati white paper intitolato" Controllo in SQL Server 2008." In screencast di video associata, illustrano controllo di SQL Server. È possibile ottenere ulteriori informazioni su altri strumenti controllo nella documentazione in linea di SQL Server 2008" Controllo (database Engine)"della sezione.

Riepilogo

Molti argomenti e numerosi collegamenti, ma che è il punto di questo articolo. Volevo fornire una panoramica degli argomenti di protezione importanti che è necessario considerare quando si è un amministratore di database che non viene utilizzato per gestire con la protezione.

Sono disponibili alcuni strumenti che consentono di controllare il sistema comuni vulnerabilità della protezione. Il primo è l'utilità Baseline Security Analyzer (MBSA) che verificherà la presenza di Windows, rete, file system e anche alcuni problemi di protezione di SQL Server 2000 e SQL Server 2005. È la versione più recente Microsoft Baseline Security Analyzer 2.1. Nuovamente per SQL Server 2000 e SQL Server 2005 solo, è disponibile uno strumento SQL Server–specific denominato la Analizzatore procedure consigliate(BPA). Questo utilizza un elenco predefinito di regole per controllare la configurazione di SQL Server e flag di eventuali problemi (ad esempio, una password vuota dell'associazione di protezione.

Nessuno di questi strumenti funziona con SQL Server 2008. In effetti, BPA non viene rilasciato per SQL Server 2008 affatto ed è stata sostituita, insieme con lo strumento di configurazione area superficie di SQL Server 2005 breve durato, dalla nuova caratteristica gestione basata su criteri che discusso in precedenza. Parte del motivo di tale sostituzione è che BPA e Configurazione superficie di ATTACCO sono disponibili strumenti di sola lettura che consentono di individuare i problemi, non può risolvere i problemi. Gestione basata su criteri offre numerose opzioni di correzione e può essere utilizzato anche ai server di destinazione SQL Server 2000 e SQL Server 2005.

Naturalmente, si deve sempre essere utilizzando Windows Update per verificare che le nuove patch di protezione e service pack vengono scaricati per poter installare in un momento appropriato, questo è il modo migliore per essere sempre aggiornato con gli aggiornamenti più recenti. Installazione di questi senza richiede tempi di inattività esula dall'ambito di questo articolo, ma alcune idee sono stati presentati nel Colonna di dicembre 2006 domande e risposte su SQL.

Se si tenta di trovare risorse di Microsoft generali sulla protezione, non vi sono molte le destinazioni che verranno visualizzata nel motore di ricerca preferito. Per salvare alcuni scegliendo tempo intorno, verrà suggerito due chiavi white paper che si consiglia di leggere.

" SQL Server 2005 protezione migliore Practices–Operational e attività di amministrazione"e" SQL Server 2008: Panoramica sulla protezione per amministratori di database."

Per SQL Server 2005, il punto di ingresso nella sezione Protezione della documentazione in linea è l'argomento" Considerazioni sulla protezione per database e applicazioni di database." Per SQL Server 2008, il punto di ingresso documentazione in linea equivalente è il " Protezione e protezione (modulo di gestione di database)."

Quanto sono riferisce takeaways da questo articolo, È necessario è possibile realizzare che non esistono alcuni passaggi che è necessario scorrere per verificare i dati che vengono archiviati in SQL Server siano protetto è necessario essere. Questo è particolarmente importante quando si eredita un'istanza di SQL Server che un altro utente gestisce. È esattamente come mutuo da un utente, è necessario chiedere se l'avviso funziona, se il metro è recintato in e abbia copie delle chiavi. In esecuzione tramite l'elenco che È fornite in questo articolo è un buon inizio, ma assicurarsi di che analisi più approfondita in aree sono relative ai è. E come sempre, se si dispone eventuali commenti e suggerimenti o domande, rilasciare più una riga Paul@SQLskills.com.

Paul s Randal è la gestione dei director di SQLskills.com e un MVP per SQL Server. Ha lavorato nel team motore di archiviazione di SQL Server in Microsoft da 1999 a 2007. Paul scritto DBCC CHECKDB e ripristino per SQL Server 2005 ed era responsabile per il motore di archiviazione principale durante lo sviluppo di SQL Server 2008. Paul è un esperto di ripristino di emergenza, disponibilità elevata e manutenzione dei database ed è in un normale relatore a conferenze di tutto il mondo. Blog ha in SQLskills.com/blogs/paul.