Authenticatie is een essentieel onderdeel van elke beveiligingsstrategie. Vandaag gaan we het hebben over SQL Server-authenticatie en hoe dit essentieel is voor het beveiligen van uw SQL Server-omgeving, en de rol die Windows-authenticatie speelt.
Een verbinding tot stand brengen
Het begint allemaal met een verbinding. Om een succesvolle databaseverbinding tot stand te brengen, heeft de client of applicatie de volgende informatie nodig:
- SQL Server volledig gekwalificeerde domeinnaam
- Instantienaam
- Poortnummer
- Inloggegevens (gebruikersnaam en wachtwoord) voor authenticatie
Stel dat u gebruik maakt van internetbankieren. Om toegang te krijgen tot uw account, moet u inloggegevens invoeren voor authenticatiedoeleinden. De bank identificeert u wanneer u geldige inloggegevens verstrekt en geeft toegang tot haar diensten na verificatie.
Evenzo moeten gebruikers bij het inloggen op SQL Server geldige referenties opgeven, zodat SQL Server hun identiteit kan verifiëren en de juiste toegang kan verlenen.
SQL Server biedt twee manieren van serververificatie:
- Windows-verificatie
- SQL Server- en Windows-verificatiemodus (gemengde modus)
U kunt deze authenticatiemethoden definiëren tijdens de installatie van SQL Server, of ze later wijzigen via een herstart. Het is van cruciaal belang voor databasebeheerders om de verschillen tussen deze authenticatiemethoden te begrijpen en ze te implementeren volgens de specifieke vereisten van hun organisatie.
Laten we er verder in duiken om de voor- en nadelen van zowel SQL Server- als Windows-authenticatie te begrijpen.
Een overzicht van SQL Server-authenticatie
Databasebeheerders maken SQL-aanmeldingen en bieden gebruikers de juiste machtigingen om zichzelf te verifiëren bij SQL Server. Gebruikers moeten de login en het wachtwoord opgeven terwijl ze verbinding maken met SQL Server, zoals hieronder weergegeven.
De inloggegevens van de gebruiker worden gevalideerd door de informatie die is opgeslagen in de hoofddatabase. U kunt het volgende beleid afdwingen voor aanmeldingen bij SQL Server.
- Wachtwoordbeleid afdwingen :De beheerders kunnen deze optie aanvinken om het Windows-wachtwoordbeleid voor SQL Server-aanmeldingen te implementeren. Het omvat het specificeren van de lengte en complexiteit van het wachtwoord.
- Verval van wachtwoord afdwingen :U kunt de maximale leeftijd van een wachtwoord afdwingen. Het wachtwoord is verlopen en moet worden gewijzigd volgens de leeftijdscriteria.
- Gebruiker moet wachtwoord wijzigen bij volgende login :De beheerder wijst een wachtwoord toe tijdens het maken van SQL-aanmeldingen. Zodra de gebruiker inlogt met zijn inloggegevens, moet hij een nieuw wachtwoord opgeven, en de beheerders zullen dit nieuwe wachtwoord niet weten.
Opmerking:al deze configuraties bevinden zich op het individuele SQL-aanmeldingsniveau. Daarom, als u meerdere SQL-aanmeldingen moet maken, moet u elk account configureren met het vereiste beleid.
We kunnen niet alleen SQL-authenticatie inschakelen. Om het in te schakelen, gebruikt u de gemengde authenticatie-optie die zowel Windows- als SQL-authenticatie omvat.
Nadelen van SQL Server-authenticatie
Er zijn nogal wat beperkingen en nadelen aan het gebruik van alleen SQL Server-authenticatie.
- Gebruikers moeten de inloggegevens voor SQL onthouden en deze elke keer dat ze verbinding maken met SQL Server in de verbindingsreeks opgeven. Als u meerdere SQL-servers heeft, kan het voor de gebruiker moeilijk zijn om de wachtwoorden voor elke instantie bij te houden.
- SQL Server slaat het wachtwoord op in de hoofddatabase in versleutelde (hash) vorm. Hackers kunnen de informatie stelen door toegang te krijgen tot de database. Aangezien deze versleutelde inloggegevens via het netwerk moeten worden doorgegeven, kan dit de kans vergroten dat gebruikersgegevens worden gestolen.
- U kunt geen extra (aangepast) accountbeleid implementeren met de SQL Server-authenticatieaanmeldingen.
- Het vergroot de taak van inlogbeheer voor databasebeheerders. Databasebeheerders hebben geen centrale beheerconsole voor het beheren van aanmeldingen voor alle instanties.
Stel dat u 500+ SQL-instanties heeft en een gebruiker toegang tot al deze instanties nodig heeft. In dit geval zou het een vervelende taak zijn voor de databasebeheerder om verbinding te maken met elke instantie en gebruikersaanmeldingen te maken. Evenzo, als een persoon de organisatie verlaat, moet de databasebeheerder de SQL-aanmeldingen van die persoon achterhalen en deze uit al deze instanties verwijderen. Dit kan een zeer tijdrovend proces zijn.
- U kunt problemen krijgen met verweesde gebruikers wanneer u een database naar verschillende instanties verplaatst, en dit kan gebeuren als gevolg van een SID-mismatch in de hoofd- en gebruikersdatabase op de nieuwe instantie.
- U moet het beveiligingsbeleid voor elke SQL-aanmelding beheren. U kunt geen universeel beleid definiëren voor alle accounts in uw organisatie. Voor een grote databasevoetafdruk is het een lastige taak om het beleid voor elke individuele login te definiëren.
Beste use-cases voor SQL Server-verificatie
- Het kan oudere applicaties en software van derden helpen om databases te verbinden als ze geen Windows (AD)-authenticatie ondersteunen.
- Het kan zijn dat gebruikers van niet-vertrouwde domeinen verbinding moeten maken met SQL Server. In dit geval kan de toepassing SQL-aanmeldingen specificeren in de verbindingsreeksen en verbinding maken met de database.
- Om standalone SQL-instanties te verbinden die geen deel uitmaken van Active Directory (AD)-groepen.
- Het kan SQL Server helpen bij het ondersteunen van webapplicaties waarbij gebruikers hun eigen identiteit creëren.
- De beheerders delen in enkele gevallen een gemeenschappelijke ID om verbinding te maken met SQL Server met behulp van Active Directory-verificatie. Deze verbindingspooling is geen goede gewoonte. In dit geval kunt u voor elke gebruiker afzonderlijke aanmeldingen maken en verbinding maken met de database met behulp van hun inloggegevens.
- Als u SQL Database in de cloud implementeert, d.w.z. Azure SQL Database of AWS RDS, krijgt u standaard inloggegevens voor SQL Server-verificatie. Later, indien nodig, kunt u op AD gebaseerde authenticatie configureren.
- Je kunt het gebruiken om verbinding te maken vanaf verschillende besturingssystemen zoals Linux en macOS.
Een overzicht van Windows-verificatie
Bij Windows-authenticatie moet de gebruiker zich eerst authenticeren in Active Directory. SQL Server verifieert gebruikers via het Windows-principaltoken in het besturingssysteem. Daarbij vraagt SQL Server niet om een wachtwoord voor identiteitsvalidatie. Daarom bevestigt Windows de identiteit van gebruikers voor authenticatie. SQL Server slaat de referenties niet op in de Windows-verificatie. De verbinding met Windows-verificatie wordt een vertrouwde of geïntegreerde verbinding genoemd.
Opmerking:Windows-verificatie is de standaardverificatiemethode wanneer u SQL Server installeert.
Voordelen van Windows-verificatie
- Windows-verificatie is een veilige manier om verbinding te maken met SQL Server en gebruikt de tokens en SPN's voor verificatiedoeleinden met behulp van het Kerberos-verificatieprotocol. Daarom verzendt het geen wachtwoorden over het netwerk en beschermt het het stelen van wachtwoorden over het netwerk.
- SQL Server slaat de inloggegevens van de gebruiker niet op.
- Het maakt gebruik van het Kerberos-beveiligingsprotocol en u kunt wachtwoordbeleid implementeren, zoals complexe wachtwoorden, accountvergrendelingen en het verlopen van wachtwoorden. Dit wachtwoordbeleid kan op organisatieniveau op alle servers worden geïmplementeerd. Daarom kunt u het gebruikersbeveiligingsbeleid op organisatieniveau beheren in plaats van op individueel inlogniveau, zoals bij SQL Server-authenticatie.
- Windows-authenticatie maakt scheiding van taken mogelijk. Het Active Directory (AD)-team beheert de AD-gebruikers. Terwijl de DBA AD-gebruikers toevoegt aan de SQL-instanties en de juiste machtigingen biedt.
- Active Directory helpt bij het maken van Windows-groepen. Het AD-team kan meerdere mensen toevoegen die gelijke toegang nodig hebben in een AD-groep. Later kunt u de groep toevoegen aan het SQL-exemplaar en machtigingen geven op groepsniveau. Daarom wordt, als een nieuwe persoon lid wordt, zodra hij deel uitmaakt van de AD-groep, automatisch toegang tot de database verleend via de server waarop deze AD-groep bestaat. Evenzo, zodra een gebruiker de organisatie verlaat en zijn ID wordt verwijderd uit deze AD-groepen, heeft hij geen toegang meer tot de database.
Nadelen van Windows-authenticatie
- Als u alleen Windows-verificatie voor SQL Server gebruikt, moeten alle gebruikers deel uitmaken van de Active Directory.
- DBA's hebben geen controle over de AD-logins en -groepen.
- Het lidmaatschap van de AD-groep is niet bekend bij de DBA. U krijgt geen melding als een gebruiker wordt toegevoegd aan of verwijderd uit de AD-groepen.
Samenvatting
In deze blogpost worden de belangrijkste componenten van SQL Server-authenticatie en Windows-authenticatie uiteengezet. Ik hoop dat het u helpt de verschillen tussen deze authenticatiemethoden te begrijpen om te beslissen welke het beste werkt voor uw bedrijf en omstandigheden.
SQL Server-verificatie kan worden gebruikt op dezelfde machine als SQL Server of op een externe verbinding. Als u in een Active Directory-omgeving werkt, wordt het gebruik van Windows-verificatie aanbevolen. Als u in een niet-Active Directory-omgeving werkt, kunt u SQL Server-verificatie gebruiken voor databaseverbindingen.
Windows-verificatie biedt meer beveiliging en flexibiliteit voor het beheren van aanmeldingen in SQL Server. Gebruik het daarom waar mogelijk.