Dela via

Metodtips för SQL Server-säkerhet

  • Artikel

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Den här artikeln innehåller information om metodtips och riktlinjer som hjälper dig att skapa säkerhet för SQL Server. En omfattande genomgång av SQL Server-säkerhetsfunktioner finns i Skydda SQL Server-.

Specifika metodtips för produktsäkerhet finns i Azure SQL Database och SQL Managed Instance och SQL Server på virtuella Azure-datorer.

Överblick

En nivåindelad säkerhetsmetod ger en djupskyddslösning med hjälp av flera säkerhetsfunktioner som är inriktade på olika säkerhetsomfattningar. Säkerhetsfunktionerna som görs tillgängliga i SQL Server 2016 och förbättrades i efterföljande versioner, hjälper till att motverka säkerhetshot och tillhandahålla väl skyddade databasprogram.

Azure uppfyller flera branschregler och standarder som gör att du kan skapa en kompatibel lösning med SQL Server som körs på en virtuell dator. Information om regelefterlevnad med Azure finns i Azure Trust Center.

Skydd på kolumnnivå

Organisationer behöver ofta skydda data på kolumnnivå som data om kunder, anställda, affärshemligheter, produktdata, sjukvård, ekonomi och andra känsliga data lagras ofta i SQL Server-databaser. Känsliga kolumner omfattar ofta identifierings-/personnummer, mobiltelefonnummer, förnamn, familjenamn, kontoidentifiering och andra uppgifter som kan anses vara personuppgifter.

De metoder och funktioner som nämns i det här avsnittet höjer skyddsnivån på kolumnnivå med minimala omkostnader och utan att kräva omfattande ändringar i programkoden.

Använd Always Encrypted för att kryptera vilande data och över kabeln. Krypterade data dekrypteras endast av klientbibliotek på programklientnivå. Använd randomiserad kryptering över deterministiska där det är möjligt. Always Encrypted med säkra enklaver kan förbättra prestanda för jämförelseåtgärder som BETWEEN, IN, LIKE, DISTINCT, Kopplingar och mer för slumpmässiga krypteringsscenarier.

Använd DDM (Dynamic Data Masking) för att dölja data på kolumnnivå när Always Encrypted inte är ett tillgängligt alternativ. DDM-(Dynamic Data Masking) är inte kompatibelt med Always Encrypted. Använd Always Encrypted via dynamisk datamaskering när det är möjligt.

Du kan också tilldela behörigheter på kolumnnivå för en tabell, vy eller tabellvärdesfunktion. Tänk på följande: – Endast SELECT, REFERENCESoch UPDATE behörigheter kan beviljas för en kolumn. – En DENY på tabellnivå har inte företräde framför en GRANTpå kolumnnivå.

Skydd på radnivå

Row-Level Security (RLS) gör det möjligt att använda användarkörningskontext för att styra åtkomsten till rader i en databastabell. RLS ser till att användarna bara kan se den post som gäller för dem. Detta ger ditt program "postnivå" säkerhet utan att behöva göra betydande ändringar i ditt program.

Affärslogik kapslas in i tabellvärdesfunktioner som styrs av en säkerhetsprincip som aktiverar och inaktiverar RLS-funktionerna. Säkerhetsprincipen styr även de FILTER och BLOCK predikat som är bundna till tabellerna som RLS arbetar mot. Använd Row-Level Security (RLS) för att begränsa de poster som returneras till den användare som gör anropet. Använd SESSION_CONTEXT (T-SQL) för användare som ansluter till databasen via ett mellannivåprogram där programanvändare delar samma SQL Server-användarkonto. För optimal prestanda och hanterbarhet följer du metodtipsen för Row-Level Säkerhet.

Tips

Använd Row-Level Security (RLS) tillsammans med antingen Always Encrypted eller Dynamic Data Masking (DDM) för att maximera organisationens säkerhetsstatus.

Filkryptering

Transparent datakryptering (TDE) skyddar data på filnivå genom att tillhandahålla kryptering av stillastående data till databasfilerna. Transparent datakryptering (TDE) säkerställer att databasfiler, säkerhetskopieringsfiler och tempdb filer inte kan bifogas och läsas utan att rätt certifikat dekrypterar databasfiler. Utan transparent datakryptering (TDE) är det möjligt för en angripare att ta det fysiska mediet (enheter eller säkerhetskopieringsband) och återställa eller bifoga databasen för att läsa innehållet. Transparent datakryptering (TDE) stöds för att fungera med alla andra säkerhetsfunktioner i SQL Server. Transparent datakryptering (TDE) ger I/O-kryptering i realtid och dekryptering av data och loggfiler. TDE-kryptering använder en databaskrypteringsnyckel (DEK) som lagras i användardatabasen. Databaskrypteringsnyckeln kan också skyddas med hjälp av ett certifikat, som skyddas av databashuvudnyckeln för master-databasen.

Använd TDE för att skydda vilande data, säkerhetskopior och tempdb.

Granskning och rapportering

För att granska SQL Serverskapar du en granskningsprincip på server- eller databasnivå. Serverprinciper gäller för alla befintliga och nyligen skapade databaser på servern. För enkelhetens skull aktiverar du granskning på servernivå och tillåter granskning på databasnivå att ärva egenskapen på servernivå för alla databaser.

Granska tabeller och kolumner med känslig information som har tillämpats säkerhetsåtgärder på. Om en tabell eller kolumn är tillräckligt viktig för att behöva skydd med en säkerhetsfunktion bör den anses vara tillräckligt viktig för granskning. Det är särskilt viktigt att granska och regelbundet granska tabeller som innehåller känslig information, men där det inte går att tillämpa önskade säkerhetsåtgärder på grund av någon form av program- eller arkitekturbegränsning.

Identiteter och autentisering

SQL Server stöder två autentiseringslägen, Windows-autentiseringsläge och "SQL Server- och Windows-autentiseringsläge" (blandat läge).

Inloggningar är separata från databasanvändare. Först mappar du inloggningar eller Windows-grupper till databasanvändare eller roller separat. Bevilja sedan behörigheter till användare, serverrolleroch/eller databasroller för åtkomst till databasobjekt.

SQL Server stöder följande typer av inloggningar:

  • Ett lokalt Windows-användarkonto eller Active Directory-domänkonto – SQL Server förlitar sig på Windows för att autentisera Windows-användarkontona.
  • Windows-grupp – Om du beviljar åtkomst till en Windows-grupp får du åtkomst till alla Windows-användarinloggningar som är medlemmar i gruppen. Om du tar bort en användare från en grupp tas rättigheterna bort från användaren som kom från gruppen. Gruppmedlemskap är den föredragna strategin.
  • SQL Server-inloggning – SQL Server lagrar användarnamnet och en hash för lösenordet i master-databasen.
  • Inneslutna databasanvändare autentiserar SQL Server-anslutningar på databasnivå. En innesluten databas är en databas som är isolerad från andra databaser och från instansen av SQL Server (och den master databas) som är värd för databasen. SQL Server stöder oberoende databasanvändare för både Windows- och SQL Server-autentisering.

Följande rekommendationer och metodtips hjälper dig att skydda dina identiteter och autentiseringsmetoder:

  • Använd rollbaserade säkerhetsstrategier med minst privilegier för att förbättra säkerhetshanteringen.

    • Det är standard att placera Active Directory-användare i AD-grupper, AD-grupper bör finnas i SQL Server-roller och SQL Server-roller bör beviljas de minsta behörigheter som krävs av programmet.

  • I Azure använder du kontroller med lägsta behörighet med hjälp av rollbaserad åtkomst (RBAC)

  • Välj Active Directory framför SQL Server-autentisering när det är möjligt och välj särskilt Active Directory framför lagring av säkerheten på program- eller databasnivå.

    • Om en användare lämnar företaget är det enkelt att inaktivera kontot.
    • Det är också enkelt att ta bort användare från grupper när användare ändrar roller eller lämnar organisationen. Gruppsäkerhet anses vara bästa praxis.

  • Använd multifaktorautentisering för konton som har åtkomst på datornivå, inklusive konton som använder RDP för att logga in på datorn. Detta skyddar mot stöld eller läckor av autentiseringsuppgifter, eftersom lösenordsbaserad autentisering med en faktor är en svagare form av autentisering med autentiseringsuppgifter som riskerar att komprometteras eller av misstag ges bort.

  • Kräv starka och komplexa lösenord som inte är lätta att gissa och som inte används för andra konton eller syften. Uppdatera regelbundet lösenord och tillämpa Active Directory-principer.

  • Group-Managed servicekonton (gMSA) tillhandahåller automatisk lösenordshantering, förenklad SPN-hantering (Service Principal Name) och delegerar hanteringen till andra administratörer.

    • Med gMSA hanterar Windows-operativsystemet lösenord för kontot i stället för att förlita sig på att administratören hanterar lösenordet.
    • gMSA uppdaterar automatiskt kontolösenorden utan att starta om tjänsterna.
    • gMSA minskar den administrativa ytan och förbättrar ansvarsfördelningen.

  • Minimera de rättigheter som beviljas till AD-kontot för DBA; Överväg en uppdelning av uppgifter som begränsar åtkomsten till den virtuella datorn, möjligheten att logga in på operativsystemet, möjligheten att ändra fel- och granskningsloggar samt möjligheten att installera program och/eller funktioner.

  • Överväg att ta bort DBA-konton från sysadmin-rollen och bevilja CONTROL SERVER- till DBA-konton i stället för att göra dem till medlemmar i sysadmin-rollen. Systemadministratörsrollen respekterar inte DENY medan CONTROL SERVER- gör det.

Data härkomst och dataintegritet

Att föra historiska register över dataändringar över tid kan vara fördelaktigt för att åtgärda oavsiktliga ändringar av data. Det kan också vara användbart för granskning av programändringar och kan återställa dataelement när en felaktig aktör introducerar dataändringar som inte har behörighet.

  • Använd temporala tabeller för att bevara postversioner över tid och se data som de såg ut under postens livslängd, för att ge en historisk vy över applikationens data.
  • Temporala tabeller kan användas för att ange en version av den aktuella tabellen när som helst.

Verktyg för säkerhetsutvärdering och utvärdering

Följande konfigurations- och utvärderingsverktyg hanterar säkerhet på ytan, identifierar datasäkerhetsmöjligheter och ger en metodutvärdering av säkerheten i SQL Server-miljön på instansnivå.

  • Surface area configuration – Du bör endast aktivera de funktioner som krävs av din miljö för att minimera antalet funktioner som kan attackeras av en illvillig användare.
  • Sårbarhetsbedömning för SQL Server (SSMS) – SQL-sårbarhetsbedömning är ett verktyg i SSMS v17.4+ som hjälper till att upptäcka, spåra och åtgärda potentiella databassårbarheter. Sårbarhetsbedömningen är ett värdefullt verktyg för att förbättra databassäkerheten och körs på databasnivå, per databas.
  • SQL Data Discovery and Classification (SSMS) – Det är vanligt att databasadministratörer hanterar servrar och databaser och inte är medvetna om känsligheten för de data som finns i databasen. Data Discovery & Classification lägger till möjligheten att identifiera, klassificera, märka och rapportera på känslighetsnivån för dina data. Data Discovery & Classification stöds från och med SSMS 17.5.

De vanliga SQL-hot

Det hjälper dig att veta vilka är några vanliga hot som riskerar SQL Server:

  • SQL-inmatning – SQL-inmatning är en typ av attack där skadlig kod infogas i strängar som skickas till en instans av SQL Server för körning.
    • Inmatningsprocessen fungerar genom att avsluta en textsträng och lägga till ett nytt kommando. Eftersom det infogade kommandot kan innehålla fler strängar innan det körs avslutar angriparen den inmatade strängen med ett kommentarstecken --.
    • SQL Server kör alla syntaktiskt giltiga frågor som tas emot.
  • Var medveten om sidokanalattacker, skadlig kod & andra hot.

SQL-inmatningsrisker

Tänk på följande för att minimera risken för en SQL-inmatning:

  • Granska alla SQL-processer som konstruerar SQL-instruktioner för sårbarheter vid inmatning.
  • Konstruera dynamiskt genererade SQL-instruktioner på ett parametriserat sätt.
  • Utvecklare och säkerhetsadministratörer bör granska all kod som anropar EXECUTE, EXECeller sp_executesql.
  • Tillåt inte följande indatatecken:
    • ;: Frågegränsare
    • ': Avgränsare för teckendatasträngar
    • --: Avgränsare för enradskommentar.
    • /* ... */: Kommentera avgränsare.
    • xp_: Katalogförlängda lagrade procedurer, till exempel xp_cmdshell.
      • Vi rekommenderar inte att du använder xp_cmdshell i någon SQL Server-miljö. Använd SQLCLR i stället eller leta efter andra alternativ på grund av de risker som xp_cmdshell kan introducera.
  • Verifiera alltid användarindata och sanera felutdata för att förhindra att de spills ut och exponeras för angriparen.

Sidokanalsrisker

Tänk på följande för att minimera risken för en sidokanalattack:

  • Se till att de senaste program- och operativsystemkorrigeringarna tillämpas.
  • För hybridarbetsbelastningar ska du se till att de senaste korrigeringarna av inbyggd programvara tillämpas för all lokal maskinvara.
  • För mycket känsliga program och arbetsbelastningar i Azure kan du lägga till ytterligare skydd mot sidokanalattacker med isolerade virtuella datorer, dedikerade värdar eller med hjälp av virtuella datorer för konfidentiell beräkning, till exempel DC-serien och virtuella datorer som använder EPYC-processorer från tredje generationens AMD.

Hot mot infrastrukturen

Överväg följande vanliga infrastrukturhot:

  • Brute force access – angriparen försöker autentisera med flera lösenord på olika konton tills ett korrekt lösenord hittas.
  • Lösenordssprickor/lösenordsspray – angripare provar ett enda noggrant utformat lösenord mot alla kända användarkonton (ett lösenord till många konton). Om den första lösenordssprayen misslyckas försöker de igen och använder ett annat noggrant utformat lösenord och väntar normalt en viss tid mellan försök att undvika identifiering.
  • Utpressningstrojanattacker är en typ av riktad attack där skadlig kod används för att kryptera data och filer, vilket förhindrar åtkomst till viktigt innehåll. Angriparna försöker sedan utpressa pengar från offer, vanligtvis i form av kryptovalutor, i utbyte mot dekrypteringsnyckeln. De flesta utpressningstrojaninfektioner börjar med e-postmeddelanden med bifogade filer som försöker installera utpressningstrojaner eller webbplatser som är värdar för exploateringspaket som försöker använda sårbarheter i webbläsare och annan programvara för att installera utpressningstrojaner.

Lösenordsrisker

Eftersom du inte vill att angripare enkelt ska gissa kontonamn eller lösenord kan följande steg minska risken för att lösenord identifieras:

  • Skapa ett unikt lokalt administratörskonto som inte heter Administrator.
  • Använd komplexa starka lösenord för alla dina konton. Mer information om hur du skapar ett starkt lösenord finns i artikeln Skapa ett starkt lösenord.
  • Som standard väljer Azure Windows-autentisering under konfigurationen av den virtuella SQL Server-datorn. Därför inaktiveras SA- inloggning och ett lösenord tilldelas av konfigurationen. Vi rekommenderar att SA- inloggning inte ska användas eller aktiveras. Om du måste ha en SQL-inloggning använder du någon av följande strategier:

    • Skapa ett SQL-konto med ett unikt namn som har sysadmin medlemskap. Du kan göra detta från portalen genom att aktivera SQL-autentisering under etableringen.

      Tips

      Om du inte aktiverar SQL-autentisering under etableringen måste du manuellt ändra autentiseringsläget till SQL Server- och Windows-autentiseringsläge. Mer information finns i Ändra serverautentiseringsläge.

    • Om du måste använda SA inloggning aktiverar du inloggningen efter etableringen och tilldelar ett nytt starkt lösenord.

Utpressningstrojanrisker

Överväg följande för att minimera riskerna med utpressningstrojaner:

  • Den bästa strategin för att skydda mot utpressningstrojaner är att ägna särskild uppmärksamhet åt RDP- och SSH-sårbarheter. Tänk också på följande rekommendationer:
    • Använda brandväggar och låsa portar
    • Se till att de senaste uppdateringarna för operativsystem och programsäkerhet tillämpas
    • Använd grupphanterade tjänstkonton (gMSA)
    • Begränsa åtkomsten till de virtuella datorerna
    • Kräv JIT-åtkomst (just-in-time) och Azure Bastion
    • Förbättra surface area security genom att undvika att installera verktyg som sysinternals och SSMS på den lokala datorn
    • Undvik att installera Windows-funktioner, roller och aktivera tjänster som inte krävs
    • Dessutom bör det finnas en regelbunden fullständig säkerhetskopiering som är separat skyddad från ett gemensamt administratörskonto så att det inte kan ta bort kopior av databaserna.

Relaterat innehåll