Dela via

Spelbok för att hantera vanliga säkerhetskrav med Azure SQL Database och Azure SQL Managed Instance

  • Artikel

Gäller för:Azure SQL DatabaseAzure SQL Managed Instance

Den här artikeln innehåller metodtips för hur du löser vanliga säkerhetskrav. Alla krav gäller inte för alla miljöer och du bör kontakta databas- och säkerhetsteamet om vilka funktioner som ska implementeras.

Kommentar

Microsoft Entra-ID är det nya namnet för Azure Active Directory (Azure AD). Vi uppdaterar dokumentationen just nu.

Lösa vanliga säkerhetskrav

Det här dokumentet innehåller vägledning om hur du löser vanliga säkerhetskrav för nya eller befintliga program med hjälp av Azure SQL Database och Azure SQL Managed Instance. Den organiseras av säkerhetsområden på hög nivå. Information om hur du hanterar specifika hot finns i avsnittet Vanliga säkerhetshot och potentiella åtgärder . Även om vissa av de rekommendationer som presenteras gäller vid migrering av program från en lokal plats till Azure, är migreringsscenarier inte i fokus för det här dokumentet.

Azure SQL Database-distributionserbjudanden som beskrivs i den här guiden

Distributionserbjudanden som inte beskrivs i den här guiden

  • Azure Synapse Analytics
  • Virtuella Azure SQL-datorer (IaaS)
  • SQL Server

Målgrupp

Den avsedda målgruppen för den här guiden är kunder som har frågor om hur du skyddar Azure SQL Database. De roller som är intresserade av den här bästa praxis-artikeln omfattar, men inte begränsat till:

  • Säkerhetsarkitekter
  • Säkerhetsansvariga
  • Efterlevnadsansvariga
  • Sekretessansvariga
  • Säkerhetstekniker

Hur används den här handboken?

Det här dokumentet är avsett som ett komplement till vår befintliga Säkerhetsdokumentation för Azure SQL Database.

Om inget annat anges rekommenderar vi att du följer alla metodtips som anges i varje avsnitt för att uppnå respektive mål eller krav. För att uppfylla specifika standarder för säkerhetsefterlevnad eller bästa praxis visas viktiga regelefterlevnadskontroller under avsnittet Krav eller mål i tillämpliga fall. Det här är de säkerhetsstandarder och föreskrifter som refereras till i det här dokumentet:

Vi planerar att fortsätta att uppdatera rekommendationerna och bästa praxis som anges här. Ange indata eller eventuella korrigeringar för det här dokumentet med hjälp av feedbacklänken längst ned i den här artikeln.

Autentisering

Autentisering är en process där användare bevisar sin identitet. Azure SQL Database och SQL Managed Instance stöder två typer av autentisering:

  • SQL-autentisering
  • Microsoft Entra-autentisering

Kommentar

Microsoft Entra-autentisering kanske inte stöds för alla verktyg och program från tredje part.

Central hantering av identiteter

Central identitetshantering erbjuder följande fördelar:

  • Hantera gruppkonton och kontrollera användarbehörigheter utan att duplicera inloggningar mellan servrar, databaser och hanterade instanser.
  • Förenklad och flexibel behörighetshantering.
  • Hantering av program i stor skala.

Så här implementerar du

  • Använd Microsoft Entra-autentisering för centraliserad identitetshantering.

Bästa praxis

  • Skapa en Microsoft Entra-klientorganisation och skapa användare som representerar mänskliga användare och skapa tjänstens huvudnamn för att representera appar, tjänster och automatiseringsverktyg. Tjänstens huvudnamn motsvarar tjänstkonton i Windows och Linux.

  • Tilldela åtkomsträttigheter till resurser till Microsoft Entra-huvudkonton via grupptilldelning: Skapa Microsoft Entra-grupper, bevilja åtkomst till grupper och lägg till enskilda medlemmar i grupperna. Skapa oberoende databasanvändare som mappar till dina Microsoft Entra-grupper i databasen. Om du vill tilldela behörigheter i databasen lägger du till de oberoende databasanvändare som representerar dina grupper i databasroller eller beviljar behörigheter direkt till dem.

    Kommentar

    I SQL Managed Instance kan du också skapa inloggningar som mappar till Microsoft Entra-huvudkonton i master databasen. Se SKAPA INLOGGNING (Transact-SQL).

  • Med Hjälp av Microsoft Entra-grupper förenklas behörighetshanteringen och både gruppägaren och resursägaren kan lägga till/ta bort medlemmar i/från gruppen.

  • Skapa en separat grupp för Microsoft Entra-administratörer för varje server eller hanterad instans.

  • Övervaka ändringar i Microsoft Entra-gruppmedlemskap med hjälp av granskningsaktivitetsrapporter för Microsoft Entra-ID.

  • För en hanterad instans krävs ett separat steg för att skapa en Microsoft Entra-administratör.

Kommentar

  • Microsoft Entra-autentisering registreras i Azure SQL-granskningsloggar, men inte i Inloggningsloggar för Microsoft Entra.
  • Azure RBAC-behörigheter som beviljats i Azure gäller inte för Azure SQL Database- eller SQL Managed Instance-behörigheter. Sådana behörigheter måste skapas/mappas manuellt med befintliga SQL-behörigheter.
  • På klientsidan behöver Microsoft Entra-autentisering åtkomst till Internet eller via användardefinierad väg (UDR) till ett virtuellt nätverk.
  • Microsoft Entra-åtkomsttoken cachelagras på klientsidan och dess livslängd beror på tokenkonfigurationen. Se artikeln Configurable token lifetimes in Microsoft Entra ID (Konfigurerbar tokenlivslängd i Microsoft Entra-ID)
  • Information om hur du felsöker autentiseringsproblem med Microsoft Entra finns i följande blogg: Felsöka Microsoft Entra-ID.

Microsoft Entra multifaktorautentisering

Nämns i: OSA Practice #2, ISO Access Control (AC)

Microsoft Entra multifaktorautentisering ger ytterligare säkerhet genom att kräva mer än en form av autentisering.

Så här implementerar du

  • Aktivera multifaktorautentisering i Microsoft Entra-ID med villkorlig åtkomst och använd interaktiv autentisering.

  • Alternativet är att aktivera multifaktorautentisering för hela Microsoft Entra-klientorganisationen eller Active Directory-domänen.

Bästa praxis

Minimera användningen av lösenordsbaserad autentisering för användare

Nämns i: OSA Practice #4, ISO Access Control (AC)

Lösenordsbaserade autentiseringsmetoder är en svagare form av autentisering. Autentiseringsuppgifter kan komprometteras eller av misstag ges bort.

Så här implementerar du

  • Använd Microsoft Entra-integrerad autentisering som eliminerar användningen av lösenord.

Bästa praxis

  • Använd enkel inloggningsautentisering med Windows-autentiseringsuppgifter. Federera den lokal Active Directory domänen med Microsoft Entra-ID och använd integrerad Windows-autentisering (för domänanslutna datorer med Microsoft Entra-ID).

Minimera användningen av lösenordsbaserad autentisering för program

Nämns i: OSA Practice #4, ISO Access Control (AC)

Så här implementerar du

  • Aktivera Azure Managed Identity. Du kan också använda integrerad eller certifikatbaserad autentisering.

Bästa praxis

Skydda lösenord och hemligheter

Om lösenord inte kan undvikas kontrollerar du att de är skyddade.

Så här implementerar du

  • Använd Azure Key Vault för att lagra lösenord och hemligheter. När det är tillämpligt använder du multifaktorautentisering för Azure SQL Database med Microsoft Entra-användare.

Bästa praxis

  • Om du inte kan undvika lösenord eller hemligheter kan du lagra användarlösenord och programhemligheter i Azure Key Vault och hantera åtkomst via Key Vault-åtkomstprinciper.

  • Olika apputvecklingsramverk kan också erbjuda ramverksspecifika mekanismer för att skydda hemligheter i appen. Till exempel: ASP.NET kärnapp.

Använda SQL-autentisering för äldre program

SQL-autentisering avser autentisering av en användare vid anslutning till Azure SQL Database eller SQL Managed Instance med användarnamn och lösenord. En inloggning måste skapas på varje server eller hanterad instans och en användare skapas i varje databas.

Så här implementerar du

  • Använd SQL-autentisering.

Bästa praxis

Åtkomsthantering

Åtkomsthantering (kallas även auktorisering) är processen för att kontrollera och hantera behöriga användares åtkomst och behörigheter till Azure SQL Database eller SQL Managed Instance.

Implementera principen om lägsta behörighet

Nämns i: FedRamp kontrollerar AC-06, NIST: AC-6, OSA Practice #3

Principen för lägsta behörighet säger att användarna inte ska ha fler privilegier än vad som krävs för att slutföra sina uppgifter. Mer information finns i artikeln Precis tillräckligt med administration.

Så här implementerar du

Tilldela endast de behörigheter som krävs för att utföra de uppgifter som krävs:

  • I SQL-databaser:

    • Använd detaljerade behörigheter och användardefinierade databasroller (eller serverroller i SQL Managed Instance):
      1. Skapa de roller som krävs
      2. Skapa nödvändiga användare
      3. Lägga till användare som medlemmar i roller
      4. Tilldela sedan behörigheter till roller.
    • Se till att inte tilldela användare till onödiga roller.

  • I Azure Resource Manager:

Bästa praxis

Följande metodtips är valfria men resulterar i bättre hanterbarhet och support för din säkerhetsstrategi:

  • Börja om möjligt med minsta möjliga uppsättning behörigheter och börja lägga till behörigheter en i taget om det finns en verklig nödvändighet (och motivering) – i motsats till den motsatta metoden: att ta bort behörigheter steg för steg.

  • Avstå från att tilldela behörigheter till enskilda användare. Använd roller (databas- eller serverroller) konsekvent i stället. Roller hjälper mycket med rapporterings- och felsökningsbehörigheter. (Azure RBAC stöder endast behörighetstilldelning via roller.)

  • Skapa och använda anpassade roller med de exakta behörigheter som krävs. Vanliga roller som används i praktiken:

    • Säkerhetsdistribution
    • Administratör
    • Utvecklare
    • Supportpersonal
    • Revisor
    • Automatiserade processer
    • Slutanvändare

  • Använd endast inbyggda roller när behörigheterna för rollerna matchar exakt de behörigheter som krävs för användaren. Du kan tilldela användare till flera roller.

  • Kom ihåg att behörigheter i databasmotorn kan tillämpas inom följande omfång (ju mindre omfång, desto mindre påverkan av de beviljade behörigheterna):

    • Server (särskilda roller i master databasen) i Azure
    • Databas
    • Schemat
      • Det är en bra idé att använda scheman för att bevilja behörigheter i en databas.
    • Objekt (tabell, vy, procedur och så vidare)

    Kommentar

    Vi rekommenderar inte att du tillämpar behörigheter på objektnivå eftersom den här nivån lägger till onödig komplexitet i den övergripande implementeringen. Om du bestämmer dig för att använda behörigheter på objektnivå bör de vara tydligt dokumenterade. Detsamma gäller för kolumnnivåbehörigheter, som är ännu mindre rekommenderade av samma skäl. Tänk också på att deny på tabellnivå som standard inte åsidosätter ett GRANT på kolumnnivå. Detta skulle kräva att de vanliga kriterierna för serverkonfiguration för efterlevnad aktiveras.

  • Utför regelbundna kontroller med hjälp av Sårbarhetsbedömning (VA) för att testa för många behörigheter.

Implementera ansvarsfördelning

Nämns i: FedRamp: AC-04, NIST: AC-5, ISO: A.6.1.2, PCI 6.4.2, SOC: CM-3, SDL-3

Uppdelning av uppgifter, även kallat Segregering av uppgifter, beskriver kravet på att dela upp känsliga uppgifter i flera uppgifter som har tilldelats till olika användare. Ansvarsfördelning hjälper till att förhindra dataintrång.

Så här implementerar du

  • Identifiera vilken nivå av ansvarsfördelning som krävs. Exempel:

    • Mellan utvecklings-/test- och produktionsmiljöer
    • Säkerhetsmässigt känsliga uppgifter jämfört med uppgifter på databasadministratörsnivå (DBA) jämfört med utvecklaruppgifter.
      • Exempel: Revisor, skapande av säkerhetsprincip för säkerhet på rollnivå (RLS), implementering av SQL Database-objekt med DDL-behörigheter.

  • Identifiera en omfattande hierarki med användare (och automatiserade processer) som har åtkomst till systemet.

  • Skapa roller enligt de användargrupper som behövs och tilldela behörigheter till roller.

    • För uppgifter på hanteringsnivå i Azure-portalen eller via PowerShell-automation använder du Azure-roller. Hitta antingen en inbyggd roll som matchar kravet eller skapa en anpassad Azure-roll med hjälp av de tillgängliga behörigheterna
    • Skapa serverroller för serveromfattande uppgifter (skapa nya inloggningar, databaser) i en hanterad instans.
    • Skapa databasroller för uppgifter på databasnivå.

  • För vissa känsliga uppgifter bör du överväga att skapa särskilda lagrade procedurer som signeras av ett certifikat för att utföra uppgifterna för användarnas räkning. En viktig fördel med digitalt signerade lagrade procedurer är att om proceduren ändras tas de behörigheter som beviljades till den tidigare versionen av proceduren omedelbart bort.

  • Implementera transparent datakryptering (TDE) med kundhanterade nycklar i Azure Key Vault för att möjliggöra uppdelning av uppgifter mellan dataägare och säkerhetsägare.

  • För att säkerställa att en dba inte kan se data som anses vara mycket känsliga och fortfarande kan utföra DBA-uppgifter kan du använda Always Encrypted med rollavgränsning.

  • I fall där användningen av Always Encrypted inte är möjlig, eller åtminstone inte utan större kostnader och ansträngningar som till och med kan göra systemet nästan oanvändbart, kan kompromisser göras och minimeras genom användning av kompenserande kontroller, till exempel:

Bästa praxis

  • Kontrollera att olika konton används för utvecklings-/test- och produktionsmiljöer. Olika konton hjälper till att följa separationen av test- och produktionssystem.

  • Avstå från att tilldela behörigheter till enskilda användare. Använd roller (databas- eller serverroller) konsekvent i stället. Att ha roller hjälper mycket med rapporterings- och felsökningsbehörigheter.

  • Använd inbyggda roller när behörigheterna matchar exakt de behörigheter som krävs – om en union av alla behörigheter från flera inbyggda roller leder till en matchning på 100 % kan du även tilldela flera roller samtidigt.

  • Skapa och använda användardefinierade roller när inbyggda roller beviljar för många behörigheter eller otillräckliga behörigheter.

  • Rolltilldelningar kan också utföras tillfälligt, även kallat dynamisk uppdelning av uppgifter (DSD), antingen inom SQL Agent-jobbsteg i T-SQL eller med Hjälp av Azure PIM för Azure-roller.

  • Kontrollera att databasadministratörer inte har åtkomst till krypteringsnycklarna eller nyckelarkiven och att säkerhetsadministratörer med åtkomst till nycklarna inte har någon åtkomst till databasen i sin tur. Användningen av Extensible Key Management (EKM) kan göra denna separation enklare att uppnå. Azure Key Vault kan användas för att implementera EKM.

  • Se alltid till att ha en spårningslogg för säkerhetsrelaterade åtgärder.

  • Du kan hämta definitionen av de inbyggda Azure-rollerna för att se vilka behörigheter som används och skapa en anpassad roll baserat på utdrag och kumuleringar av dessa via PowerShell.

  • Eftersom alla medlemmar i db_owner-databasrollen kan ändra säkerhetsinställningar som transparent datakryptering (TDE) eller ändra SLO bör det här medlemskapet beviljas med försiktighet. Det finns dock många uppgifter som kräver db_owner privilegier. Uppgift som att ändra databasinställningar, till exempel ändra databasalternativ. Granskning spelar en viktig roll i alla lösningar.

  • Det går inte att begränsa behörigheter för en db_owner och därför förhindra att ett administrativt konto visar användardata. Om det finns mycket känsliga data i en databas kan Always Encrypted användas för att på ett säkert sätt förhindra db_owners eller andra DBA från att visa dem.

Kommentar

Det är svårt att uppnå ansvarsfördelning (SoD) för säkerhetsrelaterade uppgifter eller felsökningsuppgifter. Andra områden som utveckling och slutanvändarroller är lättare att separera. De flesta efterlevnadsrelaterade kontroller tillåter användning av alternativa kontrollfunktioner, till exempel granskning när andra lösningar inte är praktiska.

För läsare som vill fördjupa sig i SoD rekommenderar vi följande resurser:

Utföra regelbundna kodgranskningar

Nämns i: PCI: 6.3.2, SOC: SDL-3

Separation av uppgifter är inte begränsat till data i en databas, men innehåller programkod. Skadlig kod kan eventuellt kringgå säkerhetskontroller. Innan du distribuerar anpassad kod till produktion är det viktigt att granska vad som distribueras.

Så här implementerar du

  • Använd ett databasverktyg som Azure Data Studio som stöder källkontroll.

  • Implementera en separat koddistributionsprocess.

  • Innan du förbinder dig till huvudgrenen måste en person (förutom författaren till själva koden) inspektera koden för potentiella utökade privilegier samt ändringar av skadliga data för att skydda mot bedrägeri och obehörig åtkomst. Detta kan göras med hjälp av källkontrollmekanismer.

Bästa praxis

  • Standardisering: Det hjälper till att implementera en standardprocedur som ska följas för alla koduppdateringar.

  • Sårbarhetsbedömning innehåller regler som söker efter för höga behörigheter, användning av gamla krypteringsalgoritmer och andra säkerhetsproblem i ett databasschema.

  • Ytterligare kontroller kan göras i en QA- eller testmiljö med Advanced Threat Protection som söker efter kod som är sårbar för SQL-inmatning.

  • Exempel på vad du bör hålla utkik efter:

    • Skapa en användare eller ändra säkerhetsinställningar inifrån en automatiserad SQL-koduppdateringsdistribution.
    • En lagrad procedur som, beroende på de angivna parametrarna, uppdaterar ett monetärt värde i en cell på ett icke-överensstämmande sätt.

  • Kontrollera att personen som utför granskningen är en annan person än den ursprungliga kodförfattaren och kunnig i kodgranskningar och säker kodning.

  • Se till att känna till alla källor till kodändringar. Koden kan finnas i T-SQL-skript. Det kan vara ad hoc-kommandon som ska köras eller distribueras i former av vyer, funktioner, utlösare och lagrade procedurer. Det kan vara en del av SQL Agent-jobbdefinitioner (steg). Den kan också köras inifrån SSIS-paket, Azure Data Factory och andra tjänster.

Dataskydd

Dataskydd är en uppsättning funktioner för att skydda viktig information från att komprometteras genom kryptering eller fördunkling.

Kommentar

Microsoft intygar att Azure SQL Database och SQL Managed Instance är FIPS 140-2 Level 1-kompatibla. Detta görs efter att ha verifierat den strikta användningen av FIPS 140-2 nivå 1 acceptabla algoritmer och FIPS 140-2 Level 1 verifierade instanser av dessa algoritmer, inklusive konsekvens med nödvändiga nyckellängder, nyckelhantering, nyckelgenerering och nyckellagring. Detta attestering är avsett att göra det möjligt för våra kunder att svara på behovet eller kravet på användning av FIPS 140-2 Nivå 1-verifierade instanser vid bearbetning av data eller leverans av system eller program. Vi definierar termerna "FIPS 140-2 Level 1 compliant" och "FIPS 140-2 Level 1 compliance" (FIPS 140-2 Level 1 compliance) som används i ovanstående instruktion för att demonstrera deras avsedda tillämplighet för amerikanska och kanadensiska myndigheters användning av den olika termen "FIPS 140-2 Level 1 validated".

Kryptera data under överföring

Nämns i: OSA Practice #6, ISO Control Family: Cryptography

Skyddar dina data när data flyttas mellan klienten och servern. Se Nätverkssäkerhet.

Kryptera data i vila

Nämns i: OSA Practice #6, ISO Control Family: Cryptography

Kryptering i vila är kryptografiskt skydd av data när de sparas i databas-, logg- och säkerhetskopieringsfiler.

Så här implementerar du

  • Transparent datakryptering (TDE) med tjänsthanterade nycklar aktiveras som standard för alla databaser som skapats efter 2017 i Azure SQL Database och SQL Managed Instance.
  • Om databasen skapas från en återställningsåtgärd med hjälp av en lokal server i en hanterad instans, kommer TDE-inställningen för den ursprungliga databasen att respekteras. Om den ursprungliga databasen inte har TDE aktiverat rekommenderar vi att TDE aktiveras manuellt för den hanterade instansen.

Bästa praxis

  • Lagra inte data som kräver kryptering i vila i master databasen. Databasen master kan inte krypteras med TDE.

  • Använd kundhanterade nycklar i Azure Key Vault om du behöver ökad transparens och detaljerad kontroll över TDE-skyddet. Med Azure Key Vault kan du när som helst återkalla behörigheter för att göra databasen otillgänglig. Du kan centralt hantera TDE-skydd tillsammans med andra nycklar eller rotera TDE-skyddet enligt ditt eget schema med hjälp av Azure Key Vault.

  • Om du använder kundhanterade nycklar i Azure Key Vault följer du artiklarna Riktlinjer för att konfigurera TDE med Azure Key Vault och Konfigurera Geo-DR med Azure Key Vault.

Kommentar

Vissa objekt som anses vara kundinnehåll, till exempel tabellnamn, objektnamn och indexnamn, kan överföras i loggfiler för support och felsökning av Microsoft.

Skydda känsliga data som används från högprivilegierade, obehöriga användare

Data som används är de data som lagras i databassystemets minne under körningen av SQL-frågor. Om din databas lagrar känsliga data kan din organisation behöva se till att högprivilegierade användare hindras från att visa känsliga data i databasen. Användare med hög behörighet, till exempel Microsoft-operatorer eller DBA:er i din organisation, bör kunna hantera databasen, men hindras från att visa och potentiellt exfiltratera känsliga data från SQL-processens minne eller genom att fråga databasen.

De principer som avgör vilka data som är känsliga och om känsliga data måste krypteras i minnet och inte är tillgängliga för administratörer i klartext är specifika för din organisation och efterlevnadsregler som du måste följa. Se det relaterade kravet: Identifiera och tagga känsliga data.

Så här implementerar du

  • Använd Always Encrypted för att säkerställa att känsliga data inte exponeras i klartext i Azure SQL Database eller SQL Managed Instance, inte ens i minnet/används. Always Encrypted skyddar data från databasadministratörer (DBA) och molnadministratörer (eller dåliga aktörer som kan personifiera högprivilegierade men obehöriga användare) och ger dig mer kontroll över vem som kan komma åt dina data.

Bästa praxis

  • Always Encrypted är inte en ersättning för kryptering av vilande data (TDE) eller under överföring (SSL/TLS). Always Encrypted ska inte användas för icke-känsliga data för att minimera prestanda- och funktionspåverkan. Användning av Always Encrypted tillsammans med TDE och TLS (Transport Layer Security) rekommenderas för omfattande skydd av vilande data, under överföring och användning.

  • Utvärdera effekten av att kryptera identifierade känsliga datakolumner innan du distribuerar Always Encrypted i en produktionsdatabas. I allmänhet minskar Always Encrypted funktionerna i frågor i krypterade kolumner och har andra begränsningar som anges i Always Encrypted – Funktionsinformation. Därför kan du behöva göra om programmet för att implementera funktionen igen, en fråga stöder inte, på klientsidan eller/och omstrukturera databasschemat, inklusive definitionerna av lagrade procedurer, funktioner, vyer och utlösare. Befintliga program kanske inte fungerar med krypterade kolumner om de inte följer begränsningarna i Always Encrypted. Ekosystemet med Microsoft-verktyg, produkter och tjänster som stöder Always Encrypted växer, men ett antal av dem fungerar inte med krypterade kolumner. Kryptering av en kolumn kan också påverka frågeprestanda, beroende på arbetsbelastningens egenskaper.

  • Hantera Always Encrypted-nycklar med rollavgränsning om du använder Always Encrypted för att skydda data från skadliga DBA:er. Med rollavgränsning skapar en säkerhetsadministratör de fysiska nycklarna. DBA skapar metadataobjekten för kolumnhuvudnyckeln och kolumnkrypteringsnyckeln som beskriver de fysiska nycklarna i databasen. Under den här processen behöver säkerhetsadministratören inte åtkomst till databasen och DBA behöver inte åtkomst till de fysiska nycklarna i klartext.

  • Lagra dina kolumnhuvudnycklar i Azure Key Vault för enkel hantering. Undvik att använda Windows Certificate Store (och i allmänhet distribuerade nyckellagringslösningar i stället för centrala nyckelhanteringslösningar) som gör nyckelhantering svårt.

  • Tänk igenom kompromisserna med att använda flera nycklar (kolumnhuvudnyckel eller kolumnkrypteringsnycklar). Håll antalet nycklar litet för att minska kostnaden för nyckelhantering. En kolumnhuvudnyckel och en kolumnkrypteringsnyckel per databas räcker vanligtvis i miljöer med stabilt tillstånd (inte mitt i en nyckelrotation). Du kan behöva ytterligare nycklar om du har olika användargrupper, var och en med olika nycklar och åtkomst till olika data.

  • Rotera kolumnhuvudnycklar enligt dina efterlevnadskrav. Om du också behöver rotera kolumnkrypteringsnycklar bör du överväga att använda onlinekryptering för att minimera programavbrott.

  • Använd deterministisk kryptering om beräkningar (likhet) på data måste stödjas. Annars använder du randomiserad kryptering. Undvik att använda deterministisk kryptering för datauppsättningar med låg entropi eller datauppsättningar med offentligt känd distribution.

  • Om du är orolig för att tredje part ska få åtkomst till dina data lagligt utan ditt medgivande ska du se till att alla program och verktyg som har åtkomst till nycklar och data i klartext körs utanför Microsoft Azure Cloud. Utan åtkomst till nycklarna kan tredje part inte dekryptera data om de inte kringgår krypteringen.

  • Always Encrypted stöder inte enkelt att bevilja tillfällig åtkomst till nycklarna (och skyddade data). Om du till exempel behöver dela nycklarna med en DBA så att DBA kan utföra vissa rensningsåtgärder på känsliga och krypterade data. Det enda sättet att på ett tillförlitligt sätt återkalla åtkomsten till data från DBA är att rotera både kolumnkrypteringsnycklarna och kolumnhuvudnycklarna som skyddar data, vilket är en dyr åtgärd.

  • För att få åtkomst till klartextvärdena i krypterade kolumner måste en användare ha åtkomst till den kolumnhuvudnyckel (CMK) som skyddar kolumner, som är konfigurerad i nyckelarkivet som innehåller CMK:t. Användaren måste också ha behörigheten VISA VALFRI KOLUMNHUVUDNYCKELDEFINITION OCH VISA ALLA BEHÖRIGHETER FÖR KOLUMNKRYPTERINGSNYCKELDEFINITION .

Kontrollera åtkomsten för programanvändare till känsliga data via kryptering

Kryptering kan användas som ett sätt att se till att endast specifika programanvändare som har åtkomst till kryptografiska nycklar kan visa eller uppdatera data.

Så här implementerar du

  • Använd kryptering på cellnivå (CLE). Mer information finns i artikeln Kryptera en datakolumn .
  • Använd Always Encrypted, men var medveten om dess begränsning. Begränsningarna visas nedan.

Metodtips:

När du använder CLE:

  • Kontrollera åtkomsten till nycklar via SQL-behörigheter och -roller.

  • Använd AES (AES 256 rekommenderas) för datakryptering. Algoritmer som RC4, DES och TripleDES är inaktuella och bör inte användas på grund av kända säkerhetsrisker.

  • Skydda symmetriska nycklar med asymmetriska nycklar/certifikat (inte lösenord) för att undvika att använda 3DES.

  • Var försiktig när du migrerar en databas med hjälp av kryptering på cellnivå via export/import (bacpac-filer).

Tänk på att Always Encrypted främst är utformat för att skydda känsliga data som används från högprivilegierade användare av Azure SQL Database (molnoperatörer, DBAs) – se Skydda känsliga data som används från högprivilegierade, obehöriga användare. Tänk på följande utmaningar när du använder Always Encrypted för att skydda data från programanvändare:

  • Som standard underhåller alla Microsoft-klientdrivrutiner som stöder Always Encrypted en global cache (en per program) med kolumnkrypteringsnycklar. När en klientdrivrutin hämtar en krypteringsnyckel för oformaterad kolumn genom att kontakta ett nyckelarkiv med en kolumnhuvudnyckel cachelagras krypteringsnyckeln för oformaterad kolumn. Detta gör det svårt att isolera data från användare av ett program med flera användare. Om ditt program personifierar slutanvändare när de interagerar med ett nyckelarkiv (till exempel Azure Key Vault), efter att en användares fråga fyllt cachen med en kolumnkrypteringsnyckel, kommer en efterföljande fråga som kräver samma nyckel men utlöses av en annan användare att använda den cachelagrade nyckeln. Drivrutinen anropar inte nyckelarkivet och kontrollerar inte om den andra användaren har behörighet att komma åt kolumnkrypteringsnyckeln. Därför kan användaren se krypterade data även om användaren inte har åtkomst till nycklarna. För att uppnå isolering av användare i ett program med flera användare kan du inaktivera cachelagring av kolumnkrypteringsnyckel. Om du inaktiverar cachelagring orsakas ytterligare prestandakostnader, eftersom drivrutinen måste kontakta nyckellagret för varje datakrypterings- eller dekrypteringsåtgärd.

Skydda data mot obehörig visning av programanvändare samtidigt som dataformatet bevaras

En annan metod för att förhindra obehöriga användare från att visa data är att dölja eller maskera data samtidigt som datatyper och format bevaras för att säkerställa att användarprogram kan fortsätta att hantera och visa data.

Så här implementerar du

Kommentar

Always Encrypted fungerar inte med dynamisk datamaskering. Det går inte att kryptera och maskera samma kolumn, vilket innebär att du måste prioritera att skydda data som används jämfört med att maskera data för dina appanvändare via dynamisk datamaskering.

Bästa praxis

Kommentar

Dynamisk datamaskering kan inte användas för att skydda data från högprivilegier. Maskeringsprinciper gäller inte för användare med administrativ åtkomst som db_owner.

  • Tillåt inte appanvändare att köra ad hoc-frågor (eftersom de kanske kan kringgå dynamisk datamaskering).

  • Använd en korrekt åtkomstkontrollprincip (via SQL-behörigheter, roller, RLS) för att begränsa användarbehörigheter för att göra uppdateringar i de maskerade kolumnerna. Att skapa en mask i en kolumn förhindrar inte uppdateringar av den kolumnen. Användare som tar emot maskerade data när de frågar efter den maskerade kolumnen kan uppdatera data om de har skrivbehörighet.

  • Dynamisk datamaskering bevarar inte de statistiska egenskaperna för de maskerade värdena. Detta kan påverka frågeresultaten (till exempel frågor som innehåller filtreringspredikat eller kopplingar till maskerade data).

Nätverkssäkerhet

Nätverkssäkerhet avser åtkomstkontroller och metodtips för att skydda dina data under överföring till Azure SQL Database.

Konfigurera min klient för säker anslutning till SQL Database/SQL Managed Instance

Metodtips för hur du förhindrar att klientdatorer och program med välkända sårbarheter (till exempel att använda äldre TLS-protokoll och chiffersviter) ansluter till Azure SQL Database och SQL Managed Instance.

Så här implementerar du

  • Se till att klientdatorer som ansluter till Azure SQL Database och SQL Managed Instance använder den senaste TLS-versionen (Transport Layer Security).

Bästa praxis

  • Framtvinga en minimal TLS-version på SQL Database-servern eller SQL Managed Instance-nivån med hjälp av den minimala TLS-versionsinställningen. Vi rekommenderar att du anger den minimala TLS-versionen till 1.2 efter testningen för att bekräfta att dina program stöder den. TLS 1.2 innehåller korrigeringar för säkerhetsrisker som hittades i tidigare versioner.

  • Konfigurera alla dina appar och verktyg för att ansluta till SQL Database med kryptering aktiverat

    • Encrypt = On, TrustServerCertificate = Off (eller motsvarande med icke-Microsoft-drivrutiner).

  • Om din app använder en drivrutin som inte stöder TLS eller stöder en äldre version av TLS ersätter du drivrutinen om möjligt. Om det inte är möjligt bör du noggrant utvärdera säkerhetsriskerna.

Minimera attackytan

Minimera antalet funktioner som kan attackeras av en obehörig användare. Implementera nätverksåtkomstkontroller för Azure SQL Database.

Nämns i: OSA Practice #5

Så här implementerar du

I SQL Database:

  • Ställ in Tillåt åtkomst till Azure-tjänster till AV på servernivå
  • Använd VNet-tjänstslutpunkter och VNet-brandväggsregler.
  • Använd Private Link.

I SQL Managed Instance:

Bästa praxis

  • Begränsa åtkomsten till Azure SQL Database och SQL Managed Instance genom att ansluta på en privat slutpunkt (till exempel med hjälp av en privat datasökväg):

    • En hanterad instans kan isoleras i ett virtuellt nätverk för att förhindra extern åtkomst. Program och verktyg som finns i samma eller peer-kopplade virtuella nätverk i samma region kan komma åt det direkt. Program och verktyg som finns i olika regioner kan använda anslutning mellan virtuella nätverk eller ExpressRoute-kretspeering för att upprätta anslutning. Kunden bör använda nätverkssäkerhetsgrupper (NSG) för att begränsa åtkomst via port 1433 endast till resurser som kräver åtkomst till en hanterad instans.
    • För en SQL Database använder du funktionen Private Link som tillhandahåller en dedikerad privat IP-adress för servern i det virtuella nätverket. Du kan också använda tjänstslutpunkter för virtuellt nätverk med brandväggsregler för virtuella nätverk för att begränsa åtkomsten till dina servrar.
    • Mobila användare bör använda punkt-till-plats-VPN-anslutningar för att ansluta via datasökvägen.
    • Användare som är anslutna till sitt lokala nätverk bör använda plats-till-plats VPN-anslutning eller ExpressRoute för att ansluta via datasökvägen.

  • Du kan komma åt Azure SQL Database och SQL Managed Instance genom att ansluta till en offentlig slutpunkt (till exempel med hjälp av en offentlig datasökväg). Följande metodtips bör övervägas:

    Kommentar

    Den offentliga SQL Managed Instance-slutpunkten är inte aktiverad som standard och måste vara explicit aktiverad. Om företagspolicyn inte tillåter användning av offentliga slutpunkter använder du Azure Policy för att förhindra att offentliga slutpunkter aktiveras i första hand.

  • Konfigurera Azure Networking-komponenter:

Konfigurera Power BI för säkra anslutningar till SQL Database/SQL Managed Instance

Bästa praxis

Konfigurera App Service för säkra anslutningar till SQL Database/SQL Managed Instance

Bästa praxis

Konfigurera Azure Virtual Machine-värd för säkra anslutningar till SQL Database/SQL Managed Instance

Bästa praxis

  • Använd en kombination av reglerna Tillåt och Neka på NSG:erna för virtuella Azure-datorer för att styra vilka regioner som kan nås från den virtuella datorn.

  • Se till att den virtuella datorn har konfigurerats enligt artikeln Säkerhetsmetoder för IaaS-arbetsbelastningar i Azure.

  • Kontrollera att alla virtuella datorer är associerade med ett specifikt virtuellt nätverk och undernät.

  • Utvärdera om du behöver standardvägen 0.0.0.0/Internet enligt vägledningen om tvingad tunneltrafik.

    • Om ja – till exempel klientdelsundernät – behåller du standardvägen.
    • Om nej, till exempel mellannivå eller serverdelsundernät, aktiverar du tvingad tunneltrafik så att ingen trafik går via Internet för att nå lokalt (även lokalt).

  • Implementera valfria standardvägar om du använder peering eller ansluter till en lokal plats.

  • Implementera användardefinierade vägar om du behöver skicka all trafik i det virtuella nätverket till en virtuell nätverksinstallation för paketgranskning.

  • Använd tjänstslutpunkter för virtuellt nätverk för säker åtkomst till PaaS-tjänster som Azure Storage via Azure-stamnätverket.

Skydda mot DDoS-attacker (Distributed Denial of Service)

DDoS-attacker (Distributed Denial of Service) är försök av en obehörig användare att skicka en flod av nätverkstrafik till Azure SQL Database i syfte att överbelasta Azure-infrastrukturen och få den att avvisa giltiga inloggningar och arbetsbelastningar.

Nämns i: OSA Practice #9

Så här implementerar du

DDoS-skydd aktiveras automatiskt som en del av Azure Platform. Den innehåller alltid på trafikövervakning och realtidsreducering av attacker på nätverksnivå på offentliga slutpunkter.

Bästa praxis

  • Följ de metoder som beskrivs i Minimera attackytan för att minimera DDoS-attackhot.

  • Aviseringen Advanced Threat Protection Brute force SQL-autentiseringsuppgifter hjälper till att identifiera råstyrkeattacker. I vissa fall kan aviseringen till och med skilja mellan arbetsbelastningar för intrångstestning.

  • För värdprogram för virtuella Azure-datorer som ansluter till SQL Database:

    • Följ rekommendationen för att begränsa åtkomst via Internetuppkopplade slutpunkter i Microsoft Defender för molnet.
    • Använd vm-skalningsuppsättningar för att köra flera instanser av ditt program på virtuella Azure-datorer.
    • Inaktivera RDP och SSH från Internet för att förhindra råstyrkeattacker.

Övervakning, loggning och granskning

Det här avsnittet refererar till funktioner som hjälper dig att identifiera avvikande aktiviteter som indikerar ovanliga och potentiellt skadliga försök att komma åt eller utnyttja databaser. Den beskriver också metodtips för att konfigurera databasgranskning för att spåra och samla in databashändelser.

Skydda databaser mot attacker

Med avancerat skydd mot hot kan du identifiera och svara på potentiella hot när de inträffar genom att tillhandahålla säkerhetsaviseringar för avvikande aktiviteter.

Så här implementerar du

  • Använd Advanced Threat Protection för SQL för att identifiera ovanliga och potentiellt skadliga försök att komma åt eller utnyttja databaser, inklusive:
    • SQL-inmatningsattack.
    • Autentiseringsuppgifter stöld/läcka.
    • Missbruk av privilegier.
    • Dataexfiltrering.

Bästa praxis

  • Konfigurera Microsoft Defender för SQL för en specifik server eller en hanterad instans. Du kan också konfigurera Microsoft Defender för SQL för alla servrar och hanterade instanser i en prenumeration genom att aktivera Microsoft Defender för molnet.

  • För en fullständig undersökning rekommenderar vi att du aktiverar SQL Database-granskning. Med granskning kan du spåra databashändelser och skriva dem till en granskningslogg på ett Azure Storage-konto eller En Azure Log Analytics-arbetsyta.

Granska kritiska säkerhetshändelser

Spårning av databashändelser hjälper dig att förstå databasaktivitet. Du kan få insikter om avvikelser och avvikelser som kan tyda på affärsproblem eller misstänkta säkerhetsöverträdelser. Det möjliggör också och underlättar efterlevnadsstandarder.

Så här implementerar du

  • Aktivera SQL Database-granskning eller granskning av hanterad instans för att spåra databashändelser och skriva dem till en granskningslogg i ditt Azure Storage-konto, Log Analytics-arbetsyta (förhandsversion) eller Event Hubs (förhandsversion).

  • Granskningsloggar kan skrivas till ett Azure Storage-konto, till en Log Analytics-arbetsyta för förbrukning av Azure Monitor-loggar eller till händelsehubben för förbrukning med hjälp av händelsehubben. Du kan konfigurera valfri kombination av dessa alternativ och granskningsloggar skrivs till var och en.

Bästa praxis

Kommentar

Aktivering av granskning till Log Analytics medför kostnader baserat på inmatningshastigheter. Tänk på den tillhörande kostnaden för att använda det här alternativet eller överväg att lagra granskningsloggarna på ett Azure-lagringskonto.

Ytterligare resurser

Säkra granskningsloggar

Begränsa åtkomsten till lagringskontot för att stödja separation av uppgifter och för att skilja DBA från granskare.

Så här implementerar du

  • När du sparar granskningsloggar i Azure Storage kontrollerar du att åtkomsten till lagringskontot är begränsad till de minsta säkerhetsprinciperna. Kontrollera vem som har åtkomst till lagringskontot.
  • Mer information finns i Auktorisera åtkomst till Azure Storage.

Bästa praxis

Säkerhetshantering

I det här avsnittet beskrivs de olika aspekterna och metodtipsen för att hantera dina databasers säkerhetsstatus. Den innehåller metodtips för att säkerställa att dina databaser är konfigurerade för att uppfylla säkerhetsstandarder, för identifiering och för att klassificera och spåra åtkomst till potentiellt känsliga data i dina databaser.

Se till att databaserna är konfigurerade för att uppfylla rekommenderade säkerhetsmetoder

Förbättra databassäkerheten proaktivt genom att identifiera och åtgärda potentiella sårbarheter i databasen.

Så här implementerar du

  • Aktivera SQL Vulnerability Assessment (VA) för att genomsöka databasen efter säkerhetsproblem och för att automatiskt köras regelbundet på dina databaser.

Bästa praxis

  • Kör först VA på dina databaser och iterera genom att åtgärda misslyckade kontroller som motsätter sig bästa praxis för säkerhet. Konfigurera baslinjer för godtagbara konfigurationer tills genomsökningen är klar eller alla kontroller har godkänts.

  • Konfigurera periodiska återkommande genomsökningar så att de körs en gång i veckan och konfigurera den relevanta personen att ta emot sammanfattningsmeddelanden.

  • Granska VA-sammanfattningen efter varje veckogenomsökning. För eventuella sårbarheter som hittas utvärderar du avvikelsen från det tidigare genomsökningsresultatet och avgör om kontrollen ska lösas. Granska om det finns en legitim orsak till ändringen i konfigurationen.

  • Lös kontroller och uppdatera baslinjer där det är relevant. Skapa ärendeobjekt för att lösa åtgärder och spåra dem tills de har lösts.

Ytterligare resurser

Identifiera och tagga känsliga data

Identifiera kolumner som potentiellt innehåller känsliga data. Vad som anses vara känsliga data beror i hög grad på kunden, efterlevnadsreglering osv., och måste utvärderas av de användare som ansvarar för dessa data. Klassificera kolumnerna så att de använder avancerade känslighetsbaserade gransknings- och skyddsscenarier.

Så här implementerar du

  • Använd SQL Data Discovery and Classification för att identifiera, klassificera, märka och skydda känsliga data i dina databaser.
    • Visa klassificeringsrekommendationerna som skapas av den automatiserade identifieringen på instrumentpanelen för SQL Data Discovery och klassificering. Acceptera relevanta klassificeringar, så att dina känsliga data är beständigt märkta med klassificeringsetiketter.
    • Lägg till klassificeringar manuellt för eventuella ytterligare känsliga datafält som inte har identifierats av den automatiserade mekanismen.
  • Mer information finns i SQL Data Discovery and Classification (Identifiering och klassificering av SQL Data).

Bästa praxis

  • Övervaka klassificeringsinstrumentpanelen regelbundet för en korrekt bedömning av databasens klassificeringstillstånd. En rapport om databasklassificeringstillståndet kan exporteras eller skrivas ut för att dela i efterlevnads- och granskningssyfte.

  • Övervaka kontinuerligt statusen för rekommenderade känsliga data i SQL Vulnerability Assessment. Spåra regeln för identifiering av känsliga data och identifiera eventuella avvikelser i de rekommenderade kolumnerna för klassificering.

  • Använd klassificering på ett sätt som är anpassat efter organisationens specifika behov. Anpassa din informationsskyddsprincip (känslighetsetiketter, informationstyper, identifieringslogik) i SQL Information Protection-principen i Microsoft Defender för molnet.

Spåra åtkomst till känsliga data

Övervaka vem som har åtkomst till känsliga data och samla in frågor om känsliga data i granskningsloggar.

Så här implementerar du

Bästa praxis

Visualisera säkerhets- och efterlevnadsstatus

Använd ett enhetligt säkerhetshanteringssystem för infrastruktur som stärker säkerhetsstatusen för dina datacenter (inklusive databaser i SQL Database). Visa en lista med rekommendationer om säkerheten för dina databaser och efterlevnadsstatus.

Så här implementerar du

Vanliga säkerhetshot och potentiella åtgärder

Det här avsnittet hjälper dig att hitta säkerhetsåtgärder för att skydda mot vissa attackvektorer. Det förväntas att de flesta åtgärder kan uppnås genom att följa en eller flera av säkerhetsriktlinjerna ovan.

Säkerhetshot: Dataexfiltrering

Dataexfiltrering är obehörig kopiering, överföring eller hämtning av data från en dator eller server. Se en definition för dataexfiltrering på Wikipedia.

Anslut till servern via en offentlig slutpunkt utgör en dataexfiltreringsrisk eftersom kunderna måste öppna sina brandväggar för offentliga IP-adresser.

Scenario 1: Ett program på en virtuell Azure-dator ansluter till en databas i Azure SQL Database. En oseriös aktör får åtkomst till den virtuella datorn och komprometterar den. I det här scenariot innebär dataexfiltrering att en extern entitet som använder den oseriösa virtuella datorn ansluter till databasen, kopierar personliga data och lagrar dem i en bloblagring eller en annan SQL Database i en annan prenumeration.

Scenario 2: En falsk DBA. Det här scenariot uppstår ofta av säkerhetskänsliga kunder från reglerade branscher. I det här scenariot kan en användare med hög behörighet kopiera data från Azure SQL Database till en annan prenumeration som inte styrs av dataägaren.

Potentiella åtgärder

Idag erbjuder Azure SQL Database och SQL Managed Instance följande tekniker för att minimera dataexfiltreringshot:

  • Använd en kombination av reglerna Tillåt och Neka på NSG:erna för virtuella Azure-datorer för att styra vilka regioner som kan nås från den virtuella datorn.
  • Om du använder en server i SQL Database anger du följande alternativ:
    • Tillåt Att Azure-tjänster inaktiveras.
    • Tillåt endast trafik från undernätet som innehåller den virtuella Azure-datorn genom att konfigurera en brandväggsregel för virtuellt nätverk.
    • Använda Private Link
  • För SQL Managed Instance adresserar användning av privat IP-åtkomst som standard det första problemet med dataexfiltrering för en oseriös virtuell dator. Aktivera funktionen för delegering av undernät i ett undernät för att automatiskt ange den mest restriktiva principen i ett SQL Managed Instance-undernät.
  • Rogue DBA-problemet är mer exponerat med SQL Managed Instance eftersom det har en större yta och nätverkskraven är synliga för kunderna. Den bästa lösningen för detta är att tillämpa alla metoder i den här säkerhetsguiden för att förhindra Rogue DBA-scenariot i första hand (inte bara för dataexfiltrering). Always Encrypted är en metod för att skydda känsliga data genom att kryptera dem och hålla nyckeln otillgänglig för DBA.

Säkerhetsaspekter av affärskontinuitet och tillgänglighet

De flesta säkerhetsstandarder hanterar datatillgänglighet när det gäller driftkontinuitet, vilket uppnås genom implementering av redundans- och redundansfunktioner för att undvika enskilda felpunkter. För katastrofscenarier är det vanligt att behålla säkerhetskopior av data och loggfiler. Följande avsnitt innehåller en översikt på hög nivå över de funktioner som är inbyggda i Azure. Den innehåller även ytterligare alternativ som kan konfigureras för att uppfylla specifika behov:

Nästa steg