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

  • Artikel
  • 37 minuter för att läsa

GÄLLER FÖR: Azure SQL Database Azure 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.

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 efter säkerhetsområden på hög nivå. Information om hur du åtgärdar 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 fokus i det här dokumentet.

Azure SQL Database distributionserbjudanden som tas upp i den här guiden

Distributionserbjudanden som inte omfattas av den här guiden

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

Målgrupp

Målgrupperna för den här guiden är kunder som har frågor om hur de ska skydda Azure SQL Database. Rollerna som är intresserade av den här bästa praxis-artikeln omfattar, men inte begränsat till:

  • Säkerhetsarkitekter
  • Säkerhetshanterare
  • Efterlevnadsansvariga
  • Sekretessansvariga
  • Säkerhetstekniker

Använda den här guiden

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

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, listas viktiga kontroller för regelefterlevnad under avsnittet Krav eller mål där det är tillämpligt. Det här är de säkerhetsstandarder och -föreskrifter som vi refererar 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 länken Feedback längst ned i den här artikeln.

Autentisering

Autentisering är processen att bevisa att användaren är den de utger sig för att vara. Azure SQL Database och SQL Managed Instance stöder två typer av autentisering:

  • SQL-autentisering
  • Azure Active Directory-autentisering

Anteckning

Azure Active Directory kanske inte stöds för alla verktyg och program från tredje part.

Central hantering av identiteter

Central identitetshantering ger 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 Azure Active Directory (Azure AD)-autentisering för centraliserad identitetshantering.

Metodtips:

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

  • Tilldela åtkomstbehörighet till resurser till Azure AD-huvudnamn via grupptilldelning: Skapa Azure AD-grupper, bevilja åtkomst till grupper och lägg till enskilda medlemmar i grupperna. I databasen skapar du inneslutna databasanvändare som mappar dina Azure AD-grupper. Om du vill tilldela behörigheter i databasen lägger du de användare som är associerade med dina Azure AD-grupper i databasroller med rätt behörigheter.

    Anteckning

    I SQL Managed Instance kan du också skapa inloggningar som mappar till Azure AD-huvudnamn i huvuddatabasen. Se CREATE LOGIN (Transact-SQL) ( Skapa inloggning (Transact-SQL).

  • Med hjälp av Azure AD-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 Azure AD-administratörer för varje server eller hanterad instans.

  • Övervaka ändringar av Azure AD-gruppmedlemskap med hjälp av granskningsaktivitetsrapporter i Azure AD.

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

Anteckning

  • Azure AD-autentisering registreras i Azure SQL-granskningsloggar, men inte i Azure AD-inloggningsloggar.
  • Azure RBAC-behörigheter som beviljas i Azure gäller inte för behörigheter Azure SQL Database eller SQL Hanterad instans. Sådana behörigheter måste skapas/mappas manuellt med befintliga SQL behörigheter.
  • På klientsidan behöver Azure AD-autentisering åtkomst till Internet eller via användardefinierad väg (UDR) till ett virtuellt nätverk.
  • Azure AD-åtkomsttoken cachelagras på klientsidan och dess livslängd beror på tokenkonfigurationen. Se artikeln Configurable token lifetimes in Azure Active Directory
  • Vägledning om hur du felsöker problem med Azure AD-autentisering finns i följande blogg: Felsöka Azure AD.

Azure AD-multifaktorautentisering

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

Azure AD Multi-Factor Authentication ger ytterligare säkerhet genom att kräva mer än en form av autentisering.

Så här implementerar du:

  • Aktivera Multi-Factor Authentication i Azure AD med villkorlig åtkomst och använd interaktiv autentisering.

  • Alternativet är att aktivera Multi-Factor Authentication för hela Azure AD- eller AD-domänen.

Metodtips:

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 en Azure AD-integrerad autentisering som eliminerar användningen av lösenord.

Metodtips:

  • Använd autentisering med enkel inloggning med hjälp Windows autentiseringsuppgifter. Federera den lokala AD-domänen med Azure AD och använd integrerad Windows -autentisering (för domän-ansluten datorer med Azure AD).

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.

Metodtips:

Skydda lösenord och hemligheter

I de fall då lösenord inte kan undvikas kontrollerar du att de är skyddade.

Så här implementerar du:

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

Metodtips:

  • Om det inte går att 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 ramverk för apputveckling kan också erbjuda ramverksspecifika mekanismer för att skydda hemligheter i appen. Exempel: ASP.NET kärnappen.

Använda SQL för äldre program

SQL autentisering syftar på 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 som skapas i varje databas.

Så här implementerar du:

  • Använd SQL autentisering.

Metodtips:

Åtkomsthantering

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

Implementera principen om minsta behörighet

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

Principen om minsta behörighet säger att användarna inte ska ha fler behörigheter än vad som behövs för att slutföra sina uppgifter. Mer information finns i artikeln Just enough administration (Precis tillräckligt med administration).

Så här implementerar du:

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

Metodtips:

Följande metodtips är valfria, men leder till bättre hanterbarhet och support för din säkerhetsstrategi:

  • Om möjligt kan du börja med minsta möjliga uppsättning behörigheter och börja lägga till behörigheter en i stället för en om det finns en verklig nödvändig (och motivering) – till skillnad från den motsatta metoden: ta bort behörigheter steg för steg.

  • Undvik att tilldela behörigheter till enskilda användare. Använd roller (databas- eller serverroller) konsekvent i stället. Roller hjälper till 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 behövs. Vanliga roller som används i praktiken:

    • Säkerhetsdistribution
    • Administratör
    • Utvecklare
    • Supportpersonal
    • Granskare
    • 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ånget är, desto mindre blir effekten av de behörigheter som beviljas):

    Anteckning

    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 väljer att använda behörigheter på objektnivå bör de vara tydligt dokumenterade. Samma sak gäller för behörigheter på kolumnnivå, som är ännu mindre rekommenderade av samma skäl. Tänk också på att en neka på tabellnivå som standard inte åsidosätter ett BEVILJANDE på kolumnnivå. Detta kräver att de vanliga kriterierna för serverkonfiguration för kompatibilitet aktiveras.

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

Implementera uppdelning av skyldigheter

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

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

Så här implementerar du:

  • Identifiera den nivå av aparering av uppgifter som krävs. Exempel:

    • Mellan utvecklings-/test- och produktionsmiljöer
    • Säkerhetskänsliga uppgifter jämfört med Databasadministratör (DBA)-hanteringsnivå och utvecklaruppgifter.
      • Exempel: Granskare, skapande av säkerhetsprincip för säkerhet på rollnivå (RLS), implementera 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 en Azure Portal via PowerShell-automatisering 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 aktiviteter 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 uppgifter för användarnas räkning. En viktig fördel med digitalt signerade lagrade procedurer är att om proceduren ändras så tas de behörigheter som beviljats till den tidigare versionen av proceduren bort omedelbart.

  • Implementera transparent datakryptering (TDE) med kund-hanterade 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 databasadministratör inte kan se data som anses vara mycket känsliga och fortfarande kan utföra DBA-uppgifter kan du använda Always Encrypted med rollseparering.

  • I fall där det inte är möjligt att använda Always Encrypted, eller åtminstone inte utan större kostnader och arbete som till och med kan göra systemet oanvändbart, kan komprometteringar göras och undvikas med hjälp av kompenserande kontroller som:

Metodtips:

  • Se till 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.

  • Undvik 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 behövs – om en union av alla behörigheter från flera inbyggda roller leder till en 100 % matchning kan du även tilldela flera roller samtidigt.

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

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

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

  • Se alltid till att ha en granskningslogg 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 ackumulerade 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 valfri databasinställning, till exempel ändra DB-alternativ. 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 ett administrativt konto från att visa 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 andra databasadministratörer från att visa dem.

Anteckning

Att uppnå uppdelning av skyldigheter (SoD) är en utmaning för säkerhetsrelaterade uppgifter eller felsökningsuppgifter. Andra områden som utveckling och slutanvändarroller är enklare att åtsega. 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 vanliga kodgranskningar

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

Uppdelningen av uppgifter är inte begränsad till data i en databas, utan omfattar programkod. Skadlig kod kan potentiellt 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 åtskild koddistributionsprocess.

  • Innan de börjar använda huvudgrenen måste en person (förutom författaren till själva koden) inspektera koden för att se om det finns risk för utökade privilegier samt ändringar av skadliga data för att skydda mot bedrägerier och falsk åtkomst. Detta kan göras med hjälp av källkontrollmekanismer.

Metodtips:

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

  • Sårbarhetsbedömning innehåller regler som kontrollerar om det finns för många behörigheter, använder 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-ktion.

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

    • Skapa en användare eller ändra säkerhetsinställningar från en automatiserad SQL-koduppdateringsdistribution.
    • En lagrad procedur, som, beroende på de parametrar som tillhandahålls, uppdaterar ett penningvärde i en cell på ett sätt som inte överensstämmer.

  • Se till att personen som genomför granskningen är en annan person än den ursprungliga kodförfattaren och kan läsa 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 form av vyer, funktioner, utlösare och lagrade procedurer. Det kan vara en del SQL definitioner för agentjobb (steg). Det 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 mot kompromettering genom kryptering eller förvirring.

Anteckning

Microsoft intygar att Azure SQL Database och SQL Managed Instance är FIPS 140-2 Level 1-kompatibel. Detta görs efter att du har verifierat den strikta användningen av godkända FIPS 140-2 Level 1-algoritmer och FIPS 140-2 Level 1-verifierade instanser av dessa algoritmer, inklusive konsekvens med nödvändiga nyckellängder, nyckelhantering, nyckelgenerering och nyckellagring. Den här attestation är avsedd att låta våra kunder svara på behovet eller kravet på användning av FIPS 140-2 Level 1-verifierade instanser vid bearbetning av data eller leverans av system eller program. Vi definierar termerna "FIPS 140-2 Level 1-kompatibel" och "FIPS 140-2 Level 1-efterlevnad" som används i ovanstående instruktion för att demonstrera deras avsedda tillämplighet för användning av den amerikanska och amerikanska myndigheter av den andra termen "FIPS 140-2 Level 1-verifierad".

Kryptera data under överföring

Nämndes 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ämndes i: OSA Practice #6, ISO Control Family: Cryptography

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

Så här implementerar du:

  • Transparent databaskryptering (TDE) med tjänst hanterade nycklar är aktiverade som standard för databaser som skapats efter 2017 i Azure SQL Database och SQL Managed Instance.
  • Om databasen i en hanterad instans skapas från en återställningsåtgärd med hjälp av en lokal server, 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.

Metodtips:

  • Lagra inte data som kräver kryptering i vila i huvuddatabasen. Huvuddatabasen kan inte krypteras med TDE.

  • Använd kund hanterade nycklar i Azure Key Vault om du behöver ökad transparens och detaljerad kontroll över TDE-skyddet. Azure Key Vault kan återkalla behörigheter när som helst 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 Azure Key Vault.

  • Om du använder kund hanterade nycklar i Azure Key Vault följer du artiklarna Riktlinjer för att konfigurera TDE med Azure Key Vault och Så här konfigurerar du geo-dr med Azure Key Vault.

Skydda känsliga data som används mot hög privilegierade och obehöriga användare

Data som används är data som lagras i minnet i databassystemet under körning av SQL frågor. Om databasen lagrar känsliga data kan din organisation behöva se till att hög privilegierade användare hindras från att visa känsliga data i databasen. Användare med hög behörighet, till exempel Microsoft-operatörer eller DBA:er i din organisation, ska kunna hantera databasen, men förhindras från att visa och potentiellt exfiltrera känsliga data från minnet i SQL-processen 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 vara 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, även i minnet/används. Always Encrypted skyddar data från databasadministratörer (DBA) och molnadministratörer (eller obehöriga aktörer som kan personifiera privilegierade men obehöriga användare) och ger dig större kontroll över vem som kan komma åt dina data.

Metodtips:

  • Always Encrypted ersätter inte kryptering av vilodata (TDE) eller under överföring (SSL/TLS). Always Encrypted bör inte användas för icke-känsliga data för att minimera påverkan på prestanda och funktioner. Användning Always Encrypted tillsammans med TDE och Transport Layer Security (TLS) rekommenderas för omfattande skydd av data i vila, under överföring och under 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 funktioner för frågor på krypterade kolumner och har andra begränsningar, som anges i Always Encrypted - Funktionsinformation. Därför kan du behöva göra om arkitekturen för ditt program för att implementera om funktionerna, en fråga stöder inte, på klientsidan eller/och omstrukturerar ditt databasschema, 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 och 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 rollseparering om du använder Always Encrypted för att skydda data från skadliga DBA:er. Med rollseparering skapar en säkerhetsadministratör de fysiska nycklarna. DATABASADMINISTRATÖRen skapar metadataobjekten för kolumnens huvudnyckel och kolumnkrypteringsnyckel som beskriver de fysiska nycklarna i databasen. Under den här processen behöver säkerhetsadministratören inte åtkomst till databasen och databasadministratören behöver inte åtkomst till de fysiska nycklarna i klartext.

  • Lagra dina kolumnnycklar i Azure Key Vault för enkel hantering. Undvik att Windows ett certifikatarkiv (och i allmänhet distribuerade lösningar för nyckelarkiv, till skillnad från centrala lösningar för nyckelhantering) som gör nyckelhanteringen hård.

  • Tänk noga igenom kompromisserna med att använda flera nycklar (kolumnhanterare eller kolumnkrypteringsnycklar). Håll antalet nycklar litet för att minska kostnaderna för nyckelhantering. En kolumns huvudnyckel 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, där var och en använder olika nycklar och har åtkomst till olika data.

  • Rotera kolumnnycklar enligt dina efterlevnadskrav. Om du även behöver rotera kolumnkrypteringsnycklar bör du överväga att använda onlinekryptering för att minimera programmets stilleståndstid.

  • Använd deterministisk kryptering om beräkningar (likhet) av data måste stödjas. Annars använder du slumpmässig 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 tredje part som har åtkomst till dina data juridiskt utan ditt medgivande ska du se till att alla program och verktyg som har åtkomst till nycklarna och data i klartext körs utanför Microsoft Azure Cloud. Utan åtkomst till nycklarna har tredje part inget sätt att dekryptera data om de inte kringgår krypteringen.

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

  • För att komma åt oformaterade värden i krypterade kolumner måste en användare ha åtkomst till den kolumnhanterare (CMK) som skyddar kolumner, som har konfigurerats i nyckellagret som innehåller CMK. Användaren måste också ha databasbehörigheterna VISA HUVUDNYCKEL FÖR VALFRI KOLUMN OCH VISA VALFRI KOLUMNKRYPTERINGSNYCKELDEFINITION.

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

Kryptering kan användas som ett sätt att säkerställa 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 kolumn med data.
  • Använd Always Encrypted, men tänk på dess begränsning. Begränsningarna visas nedan.

Bästa praxis

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, till exempel RC4, DES och TripleDES, är inaktuella och bör inte användas på grund av kända sårbarheter.

  • 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 Cell-Level kryptering via export/import (bacpac-filer).

    • Se artikeln, Rekommendationer för att använda kryptering på cellnivå i Azure SQL Database om hur du förhindrar att nycklar förloras vid migrering av data och för andra metodvägledning.

Tänk på att Always Encrypted främst har utformats för att skydda känsliga data som används från högpriviligierade användare av Azure SQL Database (molnoperatörer, DBA:er) – se Skydda känsliga data som används mot högpriviligierade och 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 i klartext genom att kontakta ett nyckelarkiv som innehåller en kolumnhanterare, cachelagras krypteringsnyckeln i klartext. Detta gör det svårt att isolera data från användare i ett program med flera användare. Om ditt program personifierar slutanvändare när det interagerar med ett nyckelarkiv (till exempel Azure Key Vault) kommer en efterföljande fråga som kräver samma nyckel men som utlöses av en annan användare att använda den cachelagrade nyckeln när en användare fyller cachen med en kolumnkrypteringsnyckel. 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. Om du vill isolera användare i ett program för flera användare kan du inaktivera cachelagring av kolumnkrypteringsnycklar. Om du inaktiverar cachelagring medför det 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 teknik för att hindra obehöriga användare från att visa data är att dölja eller dölja data samtidigt som datatyper och format bevaras så att användarprogrammen kan fortsätta att hantera och visa data.

Så här implementerar du:

Anteckning

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.

Metodtips:

Anteckning

Dynamisk datamaskering kan inte användas för att skydda data från användare med hög behörighet. 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 komma runt dynamisk datamaskering).

  • Använd en lämplig princip för åtkomstkontroll (via SQL, roller, RLS) för att begränsa användarbehörigheter för att göra uppdateringar i de maskerade kolumnerna. Om du skapar en mask för en kolumn förhindras inte uppdateringar av den kolumnen. Användare som tar emot maskerade data när de frågar den maskerade kolumnen kan uppdatera data om de har skrivbehörighet.

  • Dynamisk datamaskning bevarar inte de maskerade värdenas statistiska egenskaper. Detta kan påverka frågeresultat (till exempel frågor som innehåller filtrerings predikat 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äkerhetsrisker (till exempel med äldre TLS-protokoll och chiffersviter) ansluter till Azure SQL Database och SQL Managed Instance.

Så här implementerar du:

Metodtips:

  • Framtvinga en minimal TLS-version SQL Database servern eller SQL hanterad instans med den lägsta TLS-versionsinställningen. Vi rekommenderar att du ställer in den lägsta TLS-versionen på 1.2 efter testningen för att bekräfta att dina program stöder det. TLS 1.2 innehåller korrigeringar av sårbarheter som hittats i tidigare versioner.

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

    • Encrypt = On, TrustServerCertificate = Av (eller motsvarande med drivrutiner som inte kommer från Microsoft).

  • 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 angripas 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 på AV på servernivå
  • Använd VNet-tjänstslutpunkter och VNet-brandväggsregler.
  • Använd Private Link.

I SQL Managed Instance:

Metodtips:

  • 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-krets för att upprätta en anslutning. Kunden bör använda nätverkssäkerhetsgrupper (NSG) för att begränsa åtkomsten via port 1433 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 ditt virtuella nätverk. 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 Azure SQL Database och SQL Hanterad instans 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:

Anteckning

Den SQL offentliga slutpunkten för Managed Instance är inte aktiverad som standard och måste aktiveras explicit. Om företagets policy inte tillåter användning av offentliga slutpunkter använder du Azure Policy för att förhindra aktivering av offentliga slutpunkter från början.

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

Metodtips:

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

Metodtips:

  • För en enkel webbapp kräver anslutning via offentlig slutpunkt inställningen Tillåt Azure-tjänster till PÅ.

  • Integrera din app med en Azure Virtual Network för privat datasökvägsanslutning till en hanterad instans. Du kan också distribuera en webbapp med App Service (ASE).

  • För webbapp med ASE eller virtuellt nätverksintegrerad webbapp som ansluter till en databas i SQL Database kan du använda tjänstslutpunkter för virtuellt nätverk och brandväggsregler för virtuella nätverk för att begränsa åtkomsten från ett specifikt virtuellt nätverk och undernät. Ange sedan Tillåt Azure-tjänster till AV. Du kan också ansluta ASE till en hanterad instans i SQL Managed Instance via en privat datasökväg.

  • Se till att webbappen har konfigurerats enligt artikeln Metodtips för att skydda PaaS-webb- ochmobilprogram (plattform som en tjänst) med hjälp av Azure App Service .

  • Installera Web Application Firewall (WAF) för att skydda din webbapp mot vanliga kryphål och sårbarheter.

Konfigurera värdtjänster för virtuella Azure-datorer för säkra anslutningar till SQL Database/SQL Managed Instance

Metodtips:

  • Använd en kombination av tillåt- och neka-regler 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 är konfigurerad enligt artikeln Metodtips för säkerhet för IaaS-arbetsbelastningar i Azure.

  • Se till 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 tunnel.

    • Om ja – till exempel frontend-undernät – behåller du standardvägen.
    • Om nej – till exempel mellannivå eller backend-undernät – aktiverar du tvingad tunneltrafik så att ingen trafik går via Internet för att nå lokalt (dvs. mellan platser).

  • Implementera valfria standardvägar om du använder peering eller ansluter till lokalt.

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

  • Använd tjänstslutpunkter för virtuella 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 mängd nätverkstrafik till Azure SQL Database i syfte att överväldiga 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-plattformen. Den omfattar alltid trafikövervakning och realtidsminskning av attacker på nätverksnivå på offentliga slutpunkter.

Metodtips:

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

  • Aviseringen Om Advanced Threat Protection brute force SQL autentiseringsuppgifter kan du identifiera brute force-attacker. I vissa fall kan aviseringen till och med särskilja arbetsbelastningar för intrångstestning.

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

    • Följ rekommendationen för att begränsa åtkomsten via Internetriktade 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åstyrkattacker.

Ö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 avbilda databashändelser.

Skydda databaser mot attacker

Med avancerat skydd kan du identifiera och svara på potentiella hot när de inträffar genom att tillhandahålla säkerhetsaviseringar om 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 en ktionsattack.
    • Stöld/läckage av autentiseringsuppgifter.
    • Privilegierad missbruk.
    • Data exfiltrering.

Metodtips:

  • Konfigurera Microsoft Defender för SQLfö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ökningsupplevelse rekommenderar vi att du aktiverar SQL Database Granskning. Med granskning kan du spåra databashändelser och skriva dem till en granskningslogg i 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å insyn i avvikelser och avvikelser som kan tyda på affärsproblem eller misstänkta säkerhetsöverträdelser. Det möjliggör och underlättar även efterlevnad av 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 användning av Azure Monitor loggar eller till händelsehubb för användning med händelsehubb. Du kan konfigurera valfri kombination av dessa alternativ så skrivs granskningsloggar till var och en.

Metodtips:

  • Genom att SQL Database granskning på servern eller granskning av hanterad instans för att granska händelser granskas alla befintliga och nyligen skapade databaser på den servern.
  • Som standard omfattar granskningsprincipen alla åtgärder (frågor, lagrade procedurer och lyckade och misslyckade inloggningar) mot databaserna, vilket kan resultera i ett stort antal granskningsloggar. Vi rekommenderar att kunder konfigurerar granskning för olika typer av åtgärder och åtgärdsgrupper med hjälp av PowerShell. Om du konfigurerar detta kan du kontrollera antalet granskade åtgärder och minimera risken för händelseförlust. Med anpassade granskningskonfigurationer kan kunderna endast samla in de granskningsdata som behövs.
  • Granskningsloggar kan användas direkt i Azure Portal, eller från den lagringsplats som konfigurerades.

Anteckning

Om du aktiverar granskning i Log Analytics uppstår kostnader baserat på inmatningspriser. Tänk på kostnaden för det här alternativet, elleröverväg att lagra granskningsloggarna i ett Azure Storage-konto.

Ytterligare resurser:

Skydda granskningsloggar

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

Så här implementerar du:

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

Metodtips:

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 se till att dina databaser är konfigurerade för att uppfylla säkerhetsstandarder, för identifiering och för klassificering och spårning av åtkomst till potentiellt känsliga data i dina databaser.

Se till att databaserna är konfigurerade för att uppfylla de bästa säkerhetsmetoderna

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

Så här implementerar du:

  • Aktivera SQL för sårbarhetsbedömning (VA) för att söka igenom databasen efter säkerhetsproblem och automatiskt köra regelbundet på dina databaser.

Metodtips:

  • Börja med att köra VA på dina databaser och iterera genom att åtgärda misslyckade kontroller som går i motsatta säkerhetsmetoder. Konfigurera baslinjer för godkända konfigurationer tills genomsökningen blir ren, eller alla kontroller har passerat.

  • Konfigurera periodiska återkommande genomsökningar så att de körs en gång i veckan och konfigurera den relevanta personen så att den får e-postmeddelanden med sammanfattningar.

  • Granska VA-sammanfattningen efter varje veckovis genomsökning. För eventuella sårbarheter kan du utvärdera avvikelserna från föregående genomsökningsresultat och avgöra om kontrollen ska åtgärdas. Kontrollera om det finns en giltig orsak till ändringen av konfigurationen.

  • Lös kontroller och uppdateringsbaslinjer där det är relevant. Skapa biljettobjekt 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 mycket på kunden, efterlevnadsförordning osv. och måste utvärderas av de användare som ansvarar för dessa data. Klassificera kolumnerna för att använda avancerad känslighetsbaserad granskning och skyddsscenarier.

Så här implementerar du:

  • Använd SQL dataidentifiering och -klassificering 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 SQL dataidentifiering och klassificering. Acceptera relevanta klassificeringar så att dina känsliga data märks med klassificeringsetiketter.
    • Lägg till klassificeringar manuellt för ytterligare känsliga datafält som inte har identifierats av den automatiserade mekanismen.
  • Mer information finns i SQL dataidentifiering och -klassificering.

Metodtips:

  • Övervaka instrumentpanelen för klassificering regelbundet för att få en korrekt utvärdering av databasens klassificeringstillstånd. En rapport om databasens klassificeringstillstånd kan exporteras eller skrivas ut för delning i efterlevnads- och granskningssyfte.

  • Övervaka kontinuerligt status för rekommenderade känsliga data i SQL Sårbarhetsbedömning. Spåra identifieringsregeln för känsliga data och identifiera eventuella avdrifter i de rekommenderade kolumnerna för klassificering.

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

Spåra åtkomst till känsliga data

Övervaka vem som kommer åt känsliga data och samla in frågor om känsliga data i granskningsloggar.

Så här implementerar du:

Metodtips:

Visualisera säkerhets- och efterlevnadsstatus

Använd ett enhetligt säkerhetshanteringssystem för infrastruktur som förstärker dina datacenters säkerhetsstatus (inklusive databaser i SQL Database). Visa en lista med rekommendationer om säkerheten för dina databaser och kompatibilitetsstatus.

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: Data exfiltrering

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

Att ansluta till servern via en offentlig slutpunkt medför en risk för data exfiltrering eftersom det kräver att kunderna öppnar 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 obehörig aktör får åtkomst till den virtuella datorn och komprometterar den. I det här scenariot innebär data exfiltrering att en extern entitet som använder den falska 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: A DbA För En dba. Det här scenariot utlöses 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:

I dag Azure SQL Database och SQL Managed Instance följande tekniker för att minimera hot från data exfiltrering:

  • Använd en kombination av tillåt- och neka-regler 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 SQL Database anger du följande alternativ:
    • Tillåt Azure-tjänster till AV.
    • Tillåt endast trafik från undernätet som innehåller den virtuella Azure-datorn genom att konfigurera en VNet-brandväggsregel.
    • Använda Private Link
  • Till SQL hanterad instans adresserar användningen av privat IP-åtkomst som standard det första data exfiltrerings problemet för en falsk virtuell dator. Aktivera funktionen för undernätsdelegering i ett undernät för att automatiskt ange den mest restriktiva principen för SQL undernät för hanterad instans.
  • Rogue DBA-problemet är mer exponerat med SQL Managed Instance eftersom det har ett större ytaområde och nätverkskraven är synliga för kunderna. Den bästa begränsningen för detta är att tillämpa alla metoder i den här säkerhetsguiden för att förhindra Rogue DBA-scenariot från början (inte bara för data exfiltrering). 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 för affärskontinui och tillgänglighet

De flesta säkerhetsstandarder behandlar datatillgänglighet vad gäller driftskontinui, vilket uppnås genom att implementera 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 över de inbyggda funktionerna i Azure. Den innehåller också ytterligare alternativ som kan konfigureras för att uppfylla specifika behov:

Nästa steg