Aanbevolen beveiligingsprocedures met ingesloten databases

van toepassing op:SQL ServerAzure SQL Managed Instance

Ingesloten databases hebben enkele unieke bedreigingen die moeten worden begrepen en beperkt door SQL Server Database Engine-beheerders. De meeste bedreigingen zijn gerelateerd aan het USER WITH PASSWORD verificatieproces, waardoor de verificatiegrens van het database-engineniveau wordt verplaatst naar het databaseniveau.

Bedreigingen met betrekking tot gebruikers

Gebruikers in een ingesloten database met de ALTER ANY USER machtiging, zoals leden van de db_owner en db_accessadmin vaste databaserollen, kunnen zonder de kennis of machtiging van de SQL Server-beheerder toegang verlenen tot de database. Als u gebruikers toegang geeft tot een ingesloten database, neemt het potentiële kwetsbaarheid voor aanvallen toe voor het hele SQL Server-exemplaar. Beheerders moeten deze overdracht van toegangsbeheer begrijpen en wees voorzichtig met het verlenen van gebruikers in de ingesloten database de ALTER ANY USER machtiging. Alle database-eigenaren hebben de machtiging ALTER ANY USER. SQL Server-beheerders moeten regelmatig de gebruikers in een ingesloten database controleren.

Toegang tot andere databases met behulp van het gastaccount

Database-eigenaren en databasegebruikers met de ALTER ANY USER machtiging kunnen ingesloten databasegebruikers maken. Nadat u verbinding hebt gemaakt met een ingesloten database op een exemplaar van SQL Server, heeft een ingesloten databasegebruiker toegang tot andere databases in de database-engine als de andere databases het gastaccount-account hebben ingeschakeld.

Een dubbele gebruiker maken in een andere database

Voor sommige toepassingen is mogelijk vereist dat een gebruiker toegang heeft tot meer dan één database. Dit kan worden gedaan door identieke ingesloten databasegebruikers in elke database te maken. Gebruik de SID-optie bij het maken van de tweede gebruiker met een wachtwoord. In het volgende voorbeeld worden twee identieke gebruikers in twee databases gemaakt.

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  

Als u een query voor meerdere databases wilt uitvoeren, moet u de optie TRUSTWORTHY instellen voor de aanroepende database. Als de hierboven gedefinieerde gebruiker (Carlo) bijvoorbeeld in DB1 staat, moet de instelling TRUSTWORTHY zijn ingeschakeld voor database DB1 om SELECT * FROM db2.dbo.Table1; uit te voeren. Voer de volgende code uit om de instelling TRUSTWORTHY in te stellen.

ALTER DATABASE DB1 SET TRUSTWORTHY ON;  

Een gebruiker maken die een aanmelding dupliceren

Als een ingesloten databasegebruiker met een wachtwoord wordt aangemaakt met dezelfde naam als een SQL Server-aanmelding, en als de SQL Server-aanmelding verbinding maakt waarbij de ingesloten database als initiële catalogus wordt opgegeven, dan kan de SQL Server-aanmelding geen verbinding maken. De verbinding wordt geëvalueerd als de ingesloten databasegebruiker met wachtwoordprincipaal in de ingesloten database in plaats van als gebruiker op basis van de SQL Server-aanmelding. Dit kan leiden tot een opzettelijke of onbedoelde denial of service voor de SQL Server-aanmelding.

• Als best practice moeten leden van de sysadmin vaste serverfunctie altijd verbinding maken zonder de eerste catalogusoptie te gebruiken. Dit verbindt de aanmelding met de hoofddatabase en voorkomt pogingen van een database-eigenaar om de aanmeldingspoging te misbruiken. Vervolgens kan de beheerder overschakelen naar de ingesloten database met behulp van de instructie USE<database>. U kunt ook de standaarddatabase van de aanmelding instellen op de ingesloten database, waarmee de aanmelding bij hoofd-wordt voltooid en vervolgens de aanmelding wordt overgedragen naar de ingesloten database.

• Als goede praktijk, moet u geen geïsoleerde databasegebruikers met bijbehorende wachtwoorden aanmaken die dezelfde naam hebben als SQL Server-aanmeldingen.

• Als de dubbele aanmelding bestaat, maakt u verbinding met de hoofddatabase zonder een initiële catalogus op te geven en voert u vervolgens de opdracht USE uit om over te schakelen naar de ingesloten database.

• Wanneer ingesloten databases aanwezig zijn, moeten gebruikers van databases die geen ingesloten databases zijn, verbinding maken met de database-engine zonder een initiële catalogus te gebruiken of door de databasenaam van een niet-ingesloten database op te geven als de oorspronkelijke catalogus. Dit voorkomt dat er verbinding wordt gemaakt met de ingesloten database die minder direct wordt beheerd door de beheerders van de database-engine.

Toegang vergroten door de insluitingsstatus van een database te wijzigen

Aanmeldingen met de machtiging ALTER ANY DATABASE, zoals leden van de dbcreator vaste serverrol, en gebruikers in een niet-ingesloten database met de machtiging CONTROL DATABASE, zoals leden van de db_owner vaste databaserol, kunnen de insluitingsinstelling van een database wijzigen. Als de insluitingsinstelling van een database wordt gewijzigd van NONE- in GEDEELTELIJKE of VOLLEDIGE, kan gebruikerstoegang worden verleend door ingesloten databasegebruikers met wachtwoorden te maken. Dit kan toegang bieden zonder de kennis of toestemming van de SQL Server-beheerders. Als u wilt voorkomen dat databases worden opgenomen, stelt u de database-engine iningesloten databaseverificatie optie op 0. Als u verbindingen wilt voorkomen door ingesloten databasegebruikers met wachtwoorden voor geselecteerde ingesloten databases, gebruikt u aanmeldingstriggers om aanmeldingspogingen door ingesloten databasegebruikers met wachtwoorden te annuleren.

Een ingesloten database koppelen

Door een ingesloten database te koppelen, kan een beheerder ongewenste gebruikers toegang geven tot het exemplaar van de database-engine. Een beheerder die zich zorgen maakt over dit risico, kan de database online brengen in RESTRICTED_USER modus, waardoor verificatie voor ingesloten databasegebruikers met wachtwoorden wordt voorkomen. Alleen principals die zijn geautoriseerd via aanmeldingen, hebben toegang tot de database-engine.

Gebruikers worden gemaakt met behulp van de wachtwoordvereisten die van kracht zijn op het moment dat ze worden gemaakt en wachtwoorden worden niet opnieuw gecontroleerd wanneer een database is gekoppeld. Door een ingesloten database toe te voegen waarvoor zwakke wachtwoorden aan een systeem zijn toegestaan met een strenger wachtwoordbeleid, kan een beheerder wachtwoorden toestaan die niet voldoen aan het huidige wachtwoordbeleid voor de koppelende database-engine. Beheerders kunnen voorkomen dat de zwakke wachtwoorden behouden blijven door te vereisen dat alle wachtwoorden opnieuw worden ingesteld voor de gekoppelde database.

Wachtwoordbeleid

Wachtwoorden in een database kunnen sterke wachtwoorden zijn, maar kunnen niet worden beveiligd door robuust wachtwoordbeleid. Gebruik Waar mogelijk Windows-verificatie om te profiteren van het uitgebreidere wachtwoordbeleid dat beschikbaar is in Windows.

Kerberos-verificatie

Ingesloten databasegebruikers met wachtwoorden kunnen geen Kerberos-verificatie gebruiken. Gebruik waar mogelijk Windows-verificatie om te profiteren van Windows-functies zoals Kerberos.

Offline woordenlijstaanval

De wachtwoordhashes voor ingesloten databasegebruikers met wachtwoorden worden opgeslagen in de ingesloten database. Iedereen met toegang tot de databasebestanden kan een woordenlijstaanval uitvoeren op de ingesloten databasegebruikers met wachtwoorden op een niet-gecontroleerde systeem. Als u deze bedreiging wilt beperken, beperkt u de toegang tot de databasebestanden of staat u alleen verbindingen met ingesloten databases toe met behulp van Windows-verificatie.

Ontsnappen aan een ingesloten database

Als een database gedeeltelijk is opgenomen, moeten SQL Server-beheerders regelmatig de mogelijkheden van de gebruikers en modules in ingesloten databases controleren.

Dienstweigering door AUTO_CLOSE

Configureer geen ingesloten databases om automatisch te sluiten. Als de database is gesloten, verbruikt het openen van de database om een gebruiker te verifiëren aanvullende resources en kan dit bijdragen aan een Denial of Service-aanval.

Zie ook

ingesloten databases
migreren naar een gedeeltelijk ingesloten database