Share via

Procedure consigliate per la sicurezza in database indipendenti

  • Articolo

I database indipendenti presentano alcune minacce univoce che devono essere comprese e mitigate dagli amministratori del motore di database di 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.

Gli utenti di un database indipendente che dispongono dell'autorizzazioneALTER ANY USER, ad esempio i membri del db_owner e db_securityadmin ruoli predefiniti del database, possono concedere l'accesso al database senza la conoscenza o l'autorizzazione se l'amministratore SQL Server. Concedere agli utenti l'accesso a un database indipendente aumenta la superficie di attacco potenziale contro l'intera istanza di SQL Server. È necessario che gli amministratori comprendano le implicazioni di questa delega del controllo di accesso e concedano con cautela l'autorizzazione ALTER ANY USER agli utenti del database indipendente. Tutti i proprietari del database dispongono dell'autorizzazione ALTER ANY USER. SQL Server gli amministratori devono controllare periodicamente gli utenti in un database indipendente.

Accesso ad altri database con l'account Guest

Proprietari e utenti di database che dispongono dell'autorizzazione ALTER ANY USER possono creare utenti del database indipendente. 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

In alcune applicazioni potrebbe essere richiesto che un utente possa accedere a più database. Questo requisito può essere soddisfatto creando utenti identici del database indipendente in ogni database. Quando si crea il secondo utente con la password, utilizzare l'opzione SID. 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 sul database chiamante. Se, ad esempio, l'utente (Carlo) definito in precedenza si trova in DB1, per eseguire SELECT * FROM db2.dbo.Table1; l'impostazione TRUSTWORTHY deve essere attiva per il database DB1. Eseguire il codice seguente per attivare l'impostazione TRUSTWORHTY.

ALTER DATABASE DB1 SET TRUSTWORTHY ON;

Creazione di un utente che duplica un account di accesso

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

  • Come procedura consigliata, è opportuno che i membri del ruolo predefinito del server sysadmin considerino la possibilità di connettersi sempre senza usare l'opzione relativa al catalogo iniziale. In questo modo l'account di accesso viene connesso al database master, evitando qualsiasi tentativo da parte del proprietario di un database di utilizzare l'accesso in modo improprio. L'amministratore può quindi passare al database indipendente usando l'istruzione del USE<database> . È anche possibile impostare il database indipendente come database predefinito dell'account di accesso, in modo da consentire il completamento dell'accesso al database mastere il successivo trasferimento dell'account di accesso al database indipendente.

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

  • Se l'account di accesso duplicato esiste, connettersi al database master senza specificare un catalogo iniziale e quindi eseguire il USE comando per passare al database indipendente.

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

Aumento del livello di accesso mediante la modifica dello stato di indipendenza 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 tale impostazione viene modificata da NONE in PARTIAL o FULL, l'accesso utente può essere concesso creando utenti del database indipendente con password. Ciò potrebbe fornire l'accesso senza conoscere o fornire il consenso degli amministratori SQL Server. Per evitare che i database siano contenuti, impostare l'opzione Motorecontained database authentication di database su 0. Per impedire connessioni da parte degli utenti del database indipendente con password a determinati database indipendenti, utilizzare trigger di accesso per annullare i tentativi di accesso da parte di tali utenti.

Collegamento di un database indipendente

Collegando un database indipendente, un amministratore potrebbe concedere agli utenti indesiderati l'accesso all'istanza del motore di database. Un amministratore che desidera evitare questo rischio può portare il database online in modalità RESTRICTED_USER, in modo da impedire l'autenticazione per gli utenti del database indipendente con password. Solo le entità autorizzate tramite account di accesso potranno accedere al motore di database.

Gli utenti vengono creati utilizzando i requisiti per le password validi al momento della creazione e le password non vengono verificate di nuovo quando si collega il 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 mantenere le password vulnerabili richiedendo la reimpostazione di tutte le password per il database collegato.

Criteri password

Le password in un database possono essere obbligatoriamente di tipo complesso, ma non possono essere protette da criteri password attendibili. Utilizzare, quando possibile, l'autenticazione di Windows per sfruttare i criteri password più estesi disponibili in Windows.

Autenticazione Kerberos

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

Attacco con dizionario offline

Gli hash delle password per gli utenti del database indipendente con password vengono archiviati nel database indipendente. Chiunque disponga dell'accesso ai file di database potrebbe effettuare un attacco con dizionario nei confronti degli utenti del database indipendente con password in un sistema non controllato. Per contrastare questa minaccia, limitare l'accesso ai file di database o consentire connessioni ai database indipendenti solo utilizzando l'autenticazione di Windows.

Escape di un database indipendente

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

Denial of Service tramite AUTO_CLOSE

Evitare di configurare la chiusura automatica di database indipendenti. Se viene chiuso, l'apertura del database per autenticare un utente utilizza risorse aggiuntive e potrebbe contribuire a un attacco Denial of Service.

Vedere anche

Database indipendenti
Eseguire la migrazione in un database parzialmente indipendente