Autentisering är en kritisk komponent i alla säkerhetsstrategier. Idag ska vi diskutera SQL Server-autentisering och hur det är viktigt för att säkra din SQL Server-miljö, och vilken roll Windows-autentisering spelar.
Etablera en anslutning
Allt börjar med en koppling. För att upprätta en framgångsrik databasanslutning kräver klienten eller applikationen följande information:
- SQL Server fullt kvalificerat domännamn
- Inkomstnamn
- Portnummer
- Autentiseringsuppgifter (användarnamn och lösenord) för autentisering
Anta till exempel att du använder internetbank. För att komma åt ditt konto måste du ange autentiseringsuppgifter för autentiseringsändamål. Banken identifierar dig när du tillhandahåller giltiga referenser och ger åtkomst till sina tjänster vid verifiering.
På samma sätt måste användarna ange giltiga referenser när de loggar in på SQL Server så att SQL Server kan autentisera sin identitet och ge lämplig åtkomst.
SQL Server tillhandahåller två sätt för serverautentisering:
- Windows-autentisering
- SQL Server och Windows-autentiseringsläge (blandat läge)
Du kan definiera dessa autentiseringsmetoder under installationen av SQL Server, eller ändra dem senare via en omstart. Det är avgörande för databasadministratörer att förstå skillnaderna mellan dessa autentiseringsmetoder och implementera dem enligt deras organisations specifika krav.
Låt oss dyka in ytterligare för att förstå fördelarna och nackdelarna med både SQL Server- och Windows-autentisering.
En översikt över SQL Server-autentisering
Databasadministratörer skapar SQL-inloggningar och ger lämpliga behörigheter för användare att autentisera sig till SQL Server. Användare måste ange inloggning och lösenord när de ansluter till SQL Server som visas nedan.
Användarens referenser valideras genom informationen som lagras i huvuddatabasen. Du kan tillämpa följande principer för SQL Server-inloggningar.
- Tillämpa lösenordspolicy :Administratörer kan markera det här alternativet för att implementera Windows lösenordspolicy för SQL Server-inloggningar. Det inkluderar att ange lösenordslängd och komplexitet.
- Tvinga upp lösenordsförfall :Du kan genomdriva den maximala åldern för ett lösenord. Lösenordet kommer att löpa ut och måste ändras enligt ålderskriterierna.
- Användaren måste byta lösenord vid nästa inloggning :Administratören tilldelar ett lösenord när SQL-inloggning skapas. När användaren har loggat in med sina autentiseringsuppgifter måste de ange ett nytt lösenord, och administratörerna kommer inte att vara medvetna om detta nya lösenord.
Obs:Alla dessa konfigurationer är på individuell SQL-inloggningsnivå. Därför, om du behöver skapa flera SQL-inloggningar, måste du konfigurera varje konto med den policy som krävs.
Vi kan inte bara aktivera SQL-autentisering. För att aktivera det, använd det blandade autentiseringsalternativet som inkluderar både Windows- och SQL-autentisering.
Nackdelar med SQL Server-autentisering
Det finns en hel del begränsningar och nackdelar med att bara använda SQL Server-autentisering.
- Användare måste komma ihåg SQL-inloggningsuppgifterna och ange dem i anslutningssträngen varje gång de ansluter till SQL Server. Om du har flera SQL-servrar kan det vara svårt för användaren att hålla reda på lösenorden för varje instans.
- SQL Server lagrar lösenordet i huvuddatabasen i krypterad (hash) form. Hackare kan stjäla informationen genom att komma åt databasen. Eftersom dessa krypterade autentiseringsuppgifter måste skickas över nätverket kan detta öka risken för att användaruppgifterna blir stulna.
- Du kan inte implementera ytterligare (anpassade) kontopolicyer med SQL Server-autentiseringsinloggningar.
- Det ökar uppgiften med inloggningshantering för databasadministratörer. Databasadministratörer har inte en central hanteringskonsol för att hantera inloggningar i alla instanser.
Anta att du har 500+ SQL-instanser och en användare kräver åtkomst till alla dessa instanser. I det här fallet skulle det vara en tråkig uppgift för databasadministratören att ansluta till varje instans och skapa användarinloggningar. På liknande sätt, om en person lämnade organisationen, måste databasadministratören ta reda på den personens SQL-inloggningar och ta bort dem från alla dessa instanser. Detta kan vara en mycket tidskrävande process.
- Du kan få problem med föräldralösa användare när du flyttar en databas till olika instanser, och det kan hända på grund av en SID-felmatchning i huvud- och användardatabasen på den nya instansen.
- Du måste hantera säkerhetspolicyerna för varje SQL-inloggning. Du kan inte definiera en universell policy för alla konton i din organisation. För ett stort databasfotavtryck är det en mödosam uppgift att definiera policyn för varje enskild inloggning.
Bästa användningsfall för SQL Server-autentisering
- Det kan hjälpa äldre applikationer och programvara från tredje part att ansluta databaser om de inte stöder Windows (AD)-autentisering.
- Du kan kräva att användare från opålitliga domäner ansluter till SQL Server. I det här fallet kan applikationen ange SQL-inloggningar i anslutningssträngarna och ansluta till databasen.
- För att ansluta fristående SQL-instanser som inte ingår i Active Directory-grupper (AD).
- Det kan hjälpa SQL Server att stödja webbapplikationer där användare skapar sina egna identiteter.
- Administratörerna delar ett gemensamt ID för anslutning till SQL Server med Active Directory-autentisering i några fall. Denna anslutningspoolning är inte en bra praxis. I det här fallet kan du skapa separata inloggningar för varje användare och ansluta till databasen med deras autentiseringsuppgifter.
- Om du implementerar SQL Database i molnet, t.ex. Azure SQL Database eller AWS RDS, får du som standard inloggningsuppgifter för SQL Server-autentisering. Senare, om det behövs, kan du konfigurera AD-baserad autentisering.
- Du kan använda den för att ansluta från korsoperativa system som Linux och macOS.
En översikt över Windows-autentisering
I Windows-autentisering bör användaren först autentisera sig i Active Directory. SQL Server autentiserar användare genom Windows-huvudtoken i operativsystemet. Med det begär inte SQL Server ett lösenord för identitetsvalidering. Därför bekräftar Windows användarnas identiteter för autentisering. SQL Server lagrar inte autentiseringsuppgifterna i Windows-autentiseringen. Anslutningen som använder Windows-autentisering kallas en betrodd eller integrerad anslutning.
Obs:Windows-autentisering är standardautentiseringsmetoden när du installerar SQL Server.
Fördelar med Windows-autentisering
- Windows-autentisering är ett säkert sätt att ansluta till SQL Server, och den använder tokens och SPN:er för autentiseringsändamål med Kerberos-autentiseringsprotokollet. Därför skickar den inte lösenord över nätverket, och det skyddar mot att stjäla lösenord över nätverket.
- SQL Server lagrar inte användarens autentiseringsuppgifter.
- Den använder Kerberos säkerhetsprotokoll och du kan implementera lösenordspolicyer som komplexa lösenord, kontolåsningar och lösenordsförfall. Denna lösenordspolicy kan implementeras på organisationsnivå på alla servrar. Därför kan du kontrollera användarsäkerhetspolicyer på organisationsnivå istället för på individuell inloggningsnivå som med SQL Server-autentisering.
- Windows-autentisering möjliggör åtskillnad av uppgifter. Active Directory (AD)-teamet hanterar AD-användarna. Medan DBA lägger till AD-användare i SQL-instanserna och ger lämpliga behörigheter.
- Active Directory hjälper till att skapa Windows-grupper. AD-teamet kan lägga till flera personer som kräver lika åtkomst i en AD-grupp. Senare kan du lägga till gruppen i SQL-instansen och ge behörigheter på gruppnivå. Därför, om en ny person ansluter sig, när han väl är en del av AD-gruppen, beviljas databasåtkomst automatiskt över servern där denna AD-grupp finns. På liknande sätt, när en användare flyttar från organisationen och deras ID har tagits bort från dessa AD-grupper, kan de inte längre komma åt databasen.
Nackdelar med Windows-autentisering
- Om du bara använder Windows-autentisering för SQL Server bör alla användare vara en del av Active Directory.
- DBA:er har inte kontroll över AD-inloggningar och grupper.
- AD-gruppmedlemskapet är inte känt för DBA. Du får inget meddelande om en användare läggs till eller tas bort från AD-grupperna.
Sammanfattning
Det här blogginlägget beskriver nyckelkomponenterna i SQL Server-autentisering och Windows-autentisering. Jag hoppas att det hjälper dig att förstå skillnaderna mellan dessa autentiseringsmetoder för att avgöra vilken som fungerar bäst för ditt företag och dina omständigheter.
SQL Server-autentisering kan användas på samma maskin som SQL Server eller på en fjärranslutning. Om du arbetar i en Active Directory-miljö rekommenderas Windows-autentisering att använda. Om du arbetar i en icke-Active Directory-miljö kan du använda SQL Server-autentisering för databasanslutningar.
Windows-autentisering ger mer säkerhet och flexibilitet för hantering av inloggningar i SQL Server. Därför bör du använda den när det är möjligt.