Procedure consigliate per la sicurezza con database contenuti

I database indipendenti sono soggetti ad alcune minacce univoche che devono essere comprese e contrastate dagli amministratori del motore di database SQL Server. La maggior parte delle minacce è correlata al USER WITH PASSWORD processo di autenticazione, che sposta il limite di autenticazione dal livello del motore di database al livello del database.

Minacce correlate agli utenti

Gli utenti di un database contenuto che dispongono dell'autorizzazione ALTER ANY USER, ad esempio i membri dei ruoli predefiniti di database db_owner e db_securityadmin, possono concedere l'accesso al database senza la conoscenza o l'autorizzazione dell'amministratore di SQL Server. Concedere agli utenti l'accesso a un database indipendente aumenta la potenziale superficie di attacco contro l'intera istanza di SQL Server. Gli amministratori devono comprendere questa delega del controllo di accesso e prestare molta attenzione nella concessione dell'autorizzazione ALTER ANY USER agli utenti nel database contenuto. Tutti i proprietari di database dispongono dell'autorizzazione ALTER ANY USER . Gli amministratori di SQL Server devono controllare periodicamente gli utenti in un database indipendente.

Accesso ad altri database tramite l'account guest

I proprietari di database e gli utenti del database con l'autorizzazione ALTER ANY USER possono creare utenti di database indipendenti. Dopo la connessione a un database indipendente in un'istanza di SQL Server, un utente del database indipendente può accedere ad altri database nel motore di database, se gli altri database hanno abilitato l'account guest .

Creazione di un utente duplicato in un altro database

Alcune applicazioni potrebbero richiedere che un utente abbia accesso a più database. Questo può essere fatto creando utenti di database contenuti identici in ciascun database. Usare l'opzione SID quando si crea il secondo utente con password. Nell'esempio seguente vengono creati due utenti identici in due database.

USE DB1;  
GO  
CREATE USER Carlo WITH PASSWORD = '<strong password>';   
-- Return the SID of the user  
SELECT SID FROM sys.database_principals WHERE name = 'Carlo';  
  
-- Change to the second database  
USE DB2;  
GO  
CREATE USER Carlo WITH PASSWORD = '<same password>', SID = <SID from DB1>;  
GO  

Per eseguire una query tra database, è necessario impostare l'opzione TRUSTWORTHY nel database chiamante. Ad esempio, se l'utente (Carlo) definito in precedenza è in DB1, per eseguire SELECT * FROM db2.dbo.Table1; l'impostazione deve essere attivata per il TRUSTWORTHY database DB1. Eseguire il codice seguente per impostare l'impostazione TRUSTWORHTY su .

ALTER DATABASE DB1 SET TRUSTWORTHY ON;  

Creare un utente che replica un login

Se viene creato un utente del database indipendente con password, usando lo stesso nome di un account di accesso di SQL Server e se l'account di accesso di SQL Server si connette specificando il database indipendente come catalogo iniziale, l'account di accesso di SQL Server non sarà in grado di connettersi. La connessione verrà valutata come utente contenuto nel database con principale password nel database contenuto anziché come utente basato sull'accesso di SQL Server. Ciò potrebbe causare un denial of service intenzionale o accidentale per l'account di accesso di SQL Server.

• Come procedura consigliata, i membri del ruolo predefinito del server sysadmin devono considerare la possibilità di connettersi sempre senza usare l'opzione di catalogo iniziale. In questo modo si connette l'account di accesso al database master ed evita eventuali tentativi da parte di un proprietario del database di usare in modo improprio il tentativo di accesso. L'amministratore può quindi passare al database contenuto utilizzando l'istruzione USE<database>. È anche possibile impostare il database predefinito per l'account di accesso al database contenuto, completando così l'accesso a master e trasferendo quindi l'account di accesso al database contenuto.

• Come procedura consigliata, non creare utenti di database indipendenti con password con lo stesso nome degli account di accesso di SQL Server.

• Se il login duplicato esiste, connettersi al database master senza specificare un catalogo iniziale e quindi eseguire USE comando per passare al database contenuto.

• Quando sono presenti database contenuti, gli utenti di database non contenuti devono connettersi al Motore di database senza usare un catalogo iniziale o specificando il nome del database di un database non contenuto come catalogo iniziale. In questo modo si evita di connettersi al database indipendente, che è sotto controllo meno diretto dagli amministratori del motore di database.

Aumento dell'accesso modificando lo stato di contenimento di un database

Gli account di accesso che dispongono dell'autorizzazione ALTER ANY DATABASE , ad esempio i membri del ruolo predefinito del server dbcreator , e gli utenti in un database non indipendente che dispongono dell'autorizzazione CONTROL DATABASE , ad esempio i membri del ruolo predefinito del database db_owner , possono modificare l'impostazione di contenimento di un database. Se l'impostazione di contenimento di un database viene modificata da NONE a PARTIAL o FULL, l'accesso utente può essere concesso creando utenti di database indipendenti con password. Ciò potrebbe fornire l'accesso senza conoscere o fornire il consenso degli amministratori di SQL Server. Per impedire che i database siano racchiusi, impostare l'opzione Motore di Databasecontained database authentication su 0. Per impedire connessioni da parte di utenti di database indipendenti con password nei database indipendenti selezionati, usare i trigger di accesso per annullare i tentativi di accesso da parte di utenti di database indipendenti con password.

Collegamento di un database contenuto

Collegando un database indipendente, un amministratore potrebbe concedere agli utenti indesiderati l'accesso all'istanza del motore di database. Un amministratore preoccupato per questo rischio può portare online il database nella modalità RESTRICTED_USER, che impedisce l'autenticazione per gli utenti del database contenuto con password. Solo i principali autorizzati tramite login potranno accedere al motore di database.

Gli utenti vengono creati usando i requisiti delle password in vigore al momento della creazione e le password non vengono ricontrollate quando viene collegato un database. Collegando un database indipendente che consentiva password deboli a un sistema con criteri password più rigorosi, un amministratore potrebbe consentire password che non soddisfano i criteri password correnti nel motore di database collegato. Gli amministratori possono evitare di conservare le password deboli richiedendo la reimpostazione di tutte le password per il database collegato.

Politiche delle password

Le password in un database possono essere richieste come password complesse, ma non possono essere protette da politiche di gestione delle password robuste. Usare l'autenticazione di Windows, quando possibile, per sfruttare i criteri password più estesi disponibili in Windows.

Autenticazione Kerberos

Gli utenti di database indipendenti con password non possono usare l'autenticazione Kerberos. Quando possibile, usare l'autenticazione di Windows per sfruttare le funzionalità di Windows, ad esempio Kerberos.

Attacco al dizionario offline

Gli hash delle password per gli utenti del database indipendente con password vengono archiviati nel database indipendente. Chiunque abbia accesso ai file di database potrebbe eseguire un attacco a dizionario contro gli utenti del database contenuti, usando le loro password, in un sistema senza controllo. Per attenuare questa minaccia, limitare l'accesso ai file di database o consentire solo le connessioni ai database indipendenti tramite l'autenticazione di Windows.

Fuga da un database contenuto

Se un database è parzialmente contenuto, gli amministratori di SQL Server devono controllare periodicamente le funzionalità degli utenti e dei moduli nei database indipendenti.

Negazione del Servizio tramite AUTO_CLOSE

Non configurare i database contenuti per la chiusura automatica. Se chiuso, aprire il database per autenticare un utente utilizza risorse aggiuntive e potrebbe contribuire a un attacco Denial of Service.

Vedere anche

Database contenuti
Eseguire la migrazione in un database parzialmente indipendente