Delen via

Playbook voor het aanpakken van algemene beveiligingsvereisten met Azure SQL Database en Azure SQL Managed Instance

Van toepassing op:Azure SQL DatabaseAzure SQL Managed Instance

Dit artikel bevat aanbevolen procedures voor het oplossen van algemene beveiligingsvereisten. Niet alle vereisten zijn van toepassing op alle omgevingen en u moet uw database- en beveiligingsteam raadplegen over welke functies moeten worden geïmplementeerd.

Opmerking

Microsoft Entra-id werd voorheen Azure Active Directory (Azure AD) genoemd.

Algemene beveiligingsvereisten oplossen

Dit document bevat richtlijnen voor het oplossen van algemene beveiligingsvereisten voor nieuwe of bestaande toepassingen met behulp van Azure SQL Database en Azure SQL Managed Instance. Het wordt georganiseerd door beveiligingsgebieden van hoog niveau. Raadpleeg de sectie Veelvoorkomende beveiligingsrisico's en mogelijke oplossingen voor specifieke bedreigingen. Hoewel sommige van de gepresenteerde aanbevelingen van toepassing zijn bij het migreren van toepassingen van on-premises naar Azure, zijn migratiescenario's niet de focus van dit document.

Azure SQL Database-implementatieaanbiedingen die in deze handleiding worden behandeld

Implementatieaanbiedingen die niet worden behandeld in deze handleiding

  • Azure Synapse Analytics
  • Virtuele Azure SQL-machines (IaaS)
  • SQL Server

Audiëntie

De beoogde doelgroepen voor deze handleiding zijn klanten die vragen hebben over het beveiligen van Azure SQL Database. De rollen die geïnteresseerd zijn in dit artikel over aanbevolen procedures, omvatten, maar niet beperkt tot:

  • Beveiligingsarchitecten
  • Beveiligingsmanagers
  • Compliance officers
  • Privacyfunctionarissen
  • Beveiligingstechnici

Deze handleiding gebruiken

Dit document is bedoeld als een aanvulling op ons bestaande overzicht van de beveiligingsmogelijkheden van Azure SQL Database en SQL Managed Instance.

Tenzij anders vermeld, raden we u aan alle aanbevolen procedures in elke sectie te volgen om het respectieve doel of de desbetreffende vereiste te bereiken. Om te voldoen aan specifieke beveiligingsnalevingsstandaarden of best practices, worden belangrijke controles voor naleving van regelgeving vermeld in de sectie Vereisten of Doelstellingen, waar van toepassing. Dit zijn de beveiligingsnormen en voorschriften waarnaar wordt verwezen in dit document:

We zijn van plan om de aanbevelingen en aanbevolen procedures die hier worden vermeld, bij te werken. Geef invoer of eventuele correcties voor dit document op met behulp van de koppeling Feedback onderaan dit artikel.

Authenticatie

Verificatie is het proces om aan te tonen dat de gebruiker is wie hij of zij beweert te zijn. Azure SQL Database en SQL Managed Instance ondersteunen twee typen verificatie:

  • SQL-verificatie
  • Microsoft Entra-authenticatie

Opmerking

Microsoft Entra-verificatie wordt mogelijk niet ondersteund voor alle hulpprogramma's en toepassingen van derden.

Centraal beheer voor identiteiten

Centraal identiteitsbeheer biedt de volgende voordelen:

  • Groepsaccounts beheren en gebruikersmachtigingen beheren zonder aanmeldingen te dupliceren op servers, databases en beheerde exemplaren.
  • Vereenvoudigd en flexibel machtigingenbeheer.
  • Beheer van toepassingen op schaal.

Implementeren

  • Gebruik Microsoft Entra-verificatie voor gecentraliseerd identiteitsbeheer.

Beste praktijken

  • Maak een Microsoft Entra-tenant en maak gebruikers om menselijke gebruikers te vertegenwoordigen en service-principals te maken om apps, services en automatiseringshulpprogramma's te vertegenwoordigen. Service-principals zijn gelijk aan serviceaccounts in Windows en Linux.

  • Wijs toegangsrechten toe aan resources aan Microsoft Entra-principals via groepstoewijzing: Microsoft Entra-groepen maken, toegang verlenen tot groepen en afzonderlijke leden toevoegen aan de groepen. Maak in uw database ingesloten databasegebruikers die zijn toegewezen aan uw Microsoft Entra-groepen. Als u machtigingen in de database wilt toewijzen, voegt u de ingesloten databasegebruikers die uw groepen vertegenwoordigen aan databaserollen toe of verleent u ze rechtstreeks machtigingen.

    Opmerking

    In SQL Managed Instance kunt u ook logins maken die gekoppeld zijn aan Microsoft Entra-principals in de master-database. Zie CREATE LOGIN (Transact-SQL).

  • Het gebruik van Microsoft Entra-groepen vereenvoudigt het beheer van machtigingen en zowel de groepseigenaar als de resource-eigenaar kan leden toevoegen aan/verwijderen uit de groep.

  • Maak een afzonderlijke groep voor Microsoft Entra-beheerders voor elke server of elk beheerd exemplaar.

  • Bewaak microsoft Entra-groepslidmaatschapswijzigingen met behulp van auditactiviteitenrapporten van Microsoft Entra ID.

  • Voor een beheerd exemplaar is een afzonderlijke stap vereist voor het maken van een Microsoft Entra-beheerder.

Opmerking

  • Microsoft Entra-verificatie wordt vastgelegd in Azure SQL-auditlogboeken, maar niet in aanmeldingslogboeken van Microsoft Entra.
  • Azure RBAC-machtigingen die zijn verleend in Azure zijn niet van toepassing op machtigingen van Azure SQL Database of SQL Managed Instance. Dergelijke machtigingen moeten handmatig worden gemaakt/toegewezen met behulp van bestaande SQL-machtigingen.
  • Aan de clientzijde moet Microsoft Entra-verificatie toegang hebben tot internet of via door de gebruiker gedefinieerde route (UDR) naar een virtueel netwerk.
  • Het Microsoft Entra-toegangstoken wordt in de cache opgeslagen aan de clientzijde en de levensduur ervan is afhankelijk van de tokenconfiguratie. Zie het artikel Configureerbare levensduur van tokens in Microsoft Entra-id
  • Zie de volgende blog voor hulp bij het oplossen van problemen met Microsoft Entra-verificatie: Problemen met Microsoft Entra-id oplossen.

Meervoudige verificatie van Microsoft Entra

Vermeld in: OSA Practice #2, ISO-toegangsbeheer (AC)

Microsoft Entra multifactor authentication helpt extra beveiliging te bieden door meer dan één vorm van verificatie te vereisen.

Implementeren

  • Schakel meervoudige verificatie in microsoft Entra-id in met behulp van voorwaardelijke toegang en gebruik interactieve verificatie.

  • Het alternatief is om meervoudige verificatie in te schakelen voor het hele Microsoft Entra-tenant- of Active Directory-domein.

Beste praktijken

  • Activeer voorwaardelijke toegang in Microsoft Entra ID (hiervoor is een Premium-abonnement vereist).

  • Maak Microsoft Entra-groepen en schakel meervoudig verificatiebeleid in voor geselecteerde groepen met behulp van voorwaardelijke toegang van Microsoft Entra.

  • Meervoudige verificatie kan worden ingeschakeld voor de volledige Microsoft Entra-tenant of voor Active Directory die is gefedereerd met Microsoft Entra-id.

  • Gebruik de interactieve verificatiemodus van Microsoft Entra voor Azure SQL Database en Azure SQL Managed Instance waarbij interactief een wachtwoord wordt aangevraagd, gevolgd door meervoudige verificatie:

  • Implementeer uw toepassingen om verbinding te maken met Azure SQL Database of Azure SQL Managed Instance met behulp van interactieve verificatie met ondersteuning voor meervoudige verificatie.

    Opmerking

    Voor deze verificatiemodus zijn gebruikersidentiteiten vereist. In gevallen waarin een vertrouwd identiteitsmodel wordt gebruikt dat afzonderlijke Microsoft Entra-gebruikersverificatie overzeilt (bijvoorbeeld het gebruik van een beheerde identiteit voor Azure-resources), is meervoudige verificatie niet van toepassing.

Het gebruik van verificatie op basis van wachtwoorden voor gebruikers minimaliseren

Vermeld in: OSA Practice #4, ISO-toegangsbeheer (AC)

Verificatiemethoden op basis van wachtwoorden zijn een zwakkere vorm van verificatie. Inloggegevens kunnen worden aangetast of per ongeluk worden weggegeven.

Implementeren

  • Gebruik geïntegreerde Microsoft Entra-verificatie die het gebruik van wachtwoorden elimineert.

Beste praktijken

  • Gebruik verificatie voor eenmalige aanmelding met behulp van Windows-referenties. Federeer het on-premises Active Directory-domein met Microsoft Entra ID en gebruik geïntegreerde Windows-verificatie (voor computers die lid zijn van een domein met Microsoft Entra ID).

Het gebruik van verificatie op basis van wachtwoorden voor toepassingen minimaliseren

Vermeld in: OSA Practice #4, ISO-toegangsbeheer (AC)

Implementeren

  • Schakel Azure Managed Identity in. U kunt ook geïntegreerde verificatie of verificatie op basis van certificaten gebruiken.

Beste praktijken

Wachtwoorden en geheimen beveiligen

Voor gevallen waarin wachtwoorden niet kunnen worden vermeden, moet u ervoor zorgen dat ze zijn beveiligd.

Implementeren

  • Gebruik Azure Key Vault om wachtwoorden en geheimen op te slaan. Gebruik, indien van toepassing, meervoudige verificatie voor Azure SQL Database met Microsoft Entra-gebruikers.

Beste praktijken

  • Als het niet mogelijk is om wachtwoorden of geheimen te vermijden, sla dan gebruikerswachtwoorden en toepassingsgeheimen op in Azure Key Vault en beheer de toegang via de toegangsbeleid van Key Vault.

  • Verschillende frameworks voor app-ontwikkeling bieden mogelijk ook frameworkspecifieke mechanismen voor het beveiligen van geheimen in de app. Bijvoorbeeld: ASP.NET kern-app.

SQL-verificatie gebruiken voor verouderde toepassingen

SQL-verificatie verwijst naar de verificatie van een gebruiker bij het maken van verbinding met Azure SQL Database of SQL Managed Instance met behulp van een gebruikersnaam en wachtwoord. Er moet een login worden aangemaakt in elke server of elk beheerd exemplaar en een gebruiker worden gemaakt in elke database.

Implementeren

  • GEBRUIK SQL-verificatie.

Beste praktijken

Toegangsbeheer

Toegangsbeheer (ook wel Autorisatie genoemd) is het proces van het beheren en beheren van de toegang en bevoegdheden van geautoriseerde gebruikers tot Azure SQL Database of SQL Managed Instance.

Principe van minimale bevoegdheid implementeren

Vermeld in: FedRamp regelt AC-06, NIST: AC-6, OSA Practice #3

Het principe van minimale bevoegdheden geeft aan dat gebruikers niet meer bevoegdheden moeten hebben dan nodig is om hun taken te voltooien. Zie Precies genoeg administratie voor meer informatie.

Implementeren

Wijs alleen de benodigde machtigingen toe om de vereiste taken te voltooien:

Beste praktijken

De volgende aanbevolen procedures zijn optioneel, maar leiden tot betere beheerbaarheid en ondersteuning van uw beveiligingsstrategie:

  • Begin indien mogelijk met de minst mogelijke set machtigingen en begin met het toevoegen van machtigingen één voor één als er een echte noodzaak (en reden) is, in tegenstelling tot de tegenovergestelde benadering: machtigingen stap voor stap verwijderen.

  • Wijs geen machtigingen toe aan afzonderlijke gebruikers. Gebruik in plaats daarvan consistent rollen (database- of serverfuncties). Rollen helpen aanzienlijk bij rapportage en het oplossen van problemen met machtigingen. (Azure RBAC biedt alleen ondersteuning voor machtigingstoewijzing via rollen.)

  • Aangepaste rollen maken en gebruiken met de exacte benodigde machtigingen. Typische rollen die in de praktijk worden gebruikt:

    • Beveiligingsimplementatie
    • Administrateur
    • Ontwikkelaar
    • Ondersteuningspersoneel
    • Auditeur
    • Geautomatiseerde processen
    • Eindgebruiker

  • Gebruik alleen ingebouwde rollen wanneer de machtigingen van de rollen exact overeenkomen met de benodigde machtigingen voor de gebruiker. U kunt gebruikers toewijzen aan meerdere rollen.

  • Houd er rekening mee dat machtigingen in de database-engine kunnen worden toegepast binnen de volgende bereiken (hoe kleiner het bereik, hoe kleiner de impact van de verleende machtigingen):

    • Server (speciale rollen in de master databank) in Azure
    • gegevensbank
    • Schema
      • Het is een best practice om schema's te gebruiken om machtigingen in een database te verlenen.
    • Object (tabel, weergave, procedure, enzovoort)

    Opmerking

    Het wordt niet aanbevolen om machtigingen toe te passen op objectniveau, omdat dit niveau onnodige complexiteit toevoegt aan de algehele implementatie. Als u besluit machtigingen op objectniveau te gebruiken, moeten deze duidelijk worden gedocumenteerd. Hetzelfde geldt voor machtigingen op kolomniveau, die om dezelfde redenen nog minder worden aanbevolen. Houd er ook rekening mee dat standaard een DENY op tabelniveau geen GRANT op kolomniveau overschrijft. Hiervoor moet de Common Criteria-conforme serverconfiguratie worden geactiveerd.

  • Voer regelmatig controles uit met behulp van Evaluatie van beveiligingsproblemen (VA) om te testen op te veel machtigingen.

Scheiding van taken implementeren

Vermeld in: FedRamp: AC-04, NIST: AC-5, ISO: A.6.1.2, PCI 6.4.2, SOC: CM-3, SDL-3

Scheiding van taken, ook wel Scheiding van taken genoemd, beschrijft de vereiste om gevoelige taken op te splitsen in meerdere taken die aan verschillende gebruikers zijn toegewezen. Scheiding van taken helpt gegevensschendingen te voorkomen.

Implementeren

  • Bepaal het vereiste niveau van scheiding van taken. Voorbeelden:

    • Tussen ontwikkel-/test- en productieomgevingen
    • Beveiligingsbewuste gevoelige taken versus DBA-beheertaken (Database Administrator) versus ontwikkelaarstaken.
      • Voorbeelden: Auditor, het maken van beveiligingsbeleid voor beveiliging op rollenniveau (RLS), het implementeren van SQL Database-objecten met DDL-machtigingen.

  • Identificeer een uitgebreide hiërarchie van gebruikers (en geautomatiseerde processen) die toegang hebben tot het systeem.

  • Maak rollen op basis van de benodigde gebruikersgroepen en wijs machtigingen toe aan rollen.

    • Gebruik Azure-rollen voor taken op beheerniveau in de Azure-portal of via PowerShell-automatisering. Zoek een ingebouwde rol die overeenkomt met de vereiste of maak een aangepaste Azure-rol met behulp van de beschikbare machtigingen
    • Maak serverfuncties voor serverbrede taken (nieuwe aanmeldingen, databases maken) in een beheerd exemplaar.
    • Databaserollen maken voor taken op databaseniveau.

  • Voor bepaalde gevoelige taken kunt u speciale opgeslagen procedures maken die zijn ondertekend door een certificaat om de taken namens de gebruikers uit te voeren. Een belangrijk voordeel van digitaal ondertekende opgeslagen procedures is dat als de procedure wordt gewijzigd, de machtigingen die aan de vorige versie van de procedure zijn verleend, onmiddellijk worden verwijderd.

  • Implementeer Transparent Data Encryption (TDE) met door de klant beheerde sleutels in Azure Key Vault om scheiding van taken tussen gegevenseigenaar en beveiligingseigenaar mogelijk te maken.

  • Om ervoor te zorgen dat een DBA geen gegevens kan zien die als zeer gevoelig worden beschouwd en nog steeds DBA-taken kan uitvoeren, kunt u Always Encrypted gebruiken met functiescheiding.

  • In gevallen waarin het gebruik van Always Encrypted niet haalbaar is, of in ieder geval niet zonder grote kosten en inspanningen die het systeem bijna onbruikbaar kunnen maken, kunnen er compromissen worden gemaakt en beperkt door het gebruik van compenserende controles zoals:

Beste praktijken

  • Zorg ervoor dat verschillende accounts worden gebruikt voor ontwikkel-/test- en productieomgevingen. Verschillende accounts helpen om te voldoen aan de scheiding van test- en productiesystemen.

  • Wijs geen machtigingen toe aan afzonderlijke gebruikers. Gebruik in plaats daarvan consistent rollen (database- of serverfuncties). Het gebruik van rollen helpt aanzienlijk bij rapportage- en probleemoplossingsmachtigingen.

  • Gebruik ingebouwde rollen wanneer de machtigingen exact overeenkomen met de benodigde machtigingen. Als de samenvoeging van alle machtigingen van meerdere ingebouwde rollen leidt tot een overeenkomst van 100%, kunt u ook meerdere rollen tegelijk toewijzen.

  • Door de gebruiker gedefinieerde rollen maken en gebruiken wanneer ingebouwde rollen te veel machtigingen of onvoldoende machtigingen verlenen.

  • Roltoewijzingen kunnen ook tijdelijk worden uitgevoerd, ook wel bekend als Dynamische scheiding van taken (DSD), binnen de stappen van de SQL Agent-taak in T-SQL of het gebruik van Azure PIM voor Azure-rollen.

  • Zorg ervoor dat DBA's geen toegang hebben tot de versleutelingssleutels of sleutelarchieven en dat beveiligingsbeheerders met toegang tot de sleutels geen toegang hebben tot de database. Door het gebruik van Extensible Key Management (EKM) is deze scheiding gemakkelijker te bereiken. Azure Key Vault kan worden gebruikt om EKM te implementeren.

  • Zorg er altijd voor dat u een audittrail hebt voor beveiligingsgerelateerde acties.

  • U kunt de definitie van de ingebouwde Azure-rollen ophalen om de gebruikte machtigingen te bekijken en een aangepaste rol te maken op basis van fragmenten en cumulaties hiervan via PowerShell.

  • Omdat elk lid van de databaserol db_owner beveiligingsinstellingen zoals Transparent Data Encryption (TDE) kan wijzigen of de SLO kan wijzigen, moet dit lidmaatschap zorgvuldig worden verleend. Er zijn echter veel taken waarvoor db_owner bevoegdheden zijn vereist. Taak zoals het wijzigen van een database-instelling, zoals het wijzigen van DB-opties. Controle speelt een belangrijke rol in elke oplossing.

  • Het is niet mogelijk om machtigingen van een db_owner te beperken en daarom te voorkomen dat een beheerdersaccount gebruikersgegevens weergeeft. Als er zeer gevoelige gegevens in een database staan, kan Always Encrypted worden gebruikt om veilig te voorkomen dat db_owners of andere DBA deze kunnen bekijken.

Opmerking

Het bereiken van scheiding van taken (SoD) is lastig voor beveiligingsgerelateerde of probleemoplossingstaken. Andere gebieden, zoals ontwikkelings- en eindgebruikersrollen, zijn gemakkelijker te scheiden. De meeste besturingselementen met betrekking tot naleving maken het gebruik van alternatieve besturingsfuncties mogelijk, zoals Controle wanneer andere oplossingen niet praktisch zijn.

Voor de lezers die dieper willen ingaan op SoD, raden we de volgende bronnen aan:

Reguliere codebeoordelingen uitvoeren

Vermeld in: PCI: 6.3.2, SOC: SDL-3

Scheiding van taken is niet beperkt tot de gegevens in een database, maar bevat toepassingscode. Schadelijke code kan mogelijk beveiligingscontroles omzeilen. Voordat u aangepaste code in productie implementeert, is het essentieel om te controleren wat er wordt geïmplementeerd.

Implementeren

  • Gebruik een databasehulpprogramma zoals Azure Data Studio dat broncodebeheer ondersteunt.

  • Implementeer een gescheiden code-implementatieproces.

  • Voordat naar de hoofdvertakking wordt gecommitteerd, moet een persoon (anders dan de auteur van de code zelf) de code inspecteren op mogelijke verhoging van bevoegdheidsrisico's en kwaadaardige gegevenswijzigingen om tegen fraude en ongewenste toegang te beschermen. Dit kan worden gedaan met behulp van mechanismen voor broncodebeheer.

Beste praktijken

  • Standaardisatie: Het helpt bij het implementeren van een standaardprocedure die moet worden gevolgd voor eventuele code-updates.

  • Evaluatie van beveiligingsproblemen bevat regels die controleren op overmatige machtigingen, het gebruik van oude versleutelingsalgoritmen en andere beveiligingsproblemen in een databaseschema.

  • Verdere controles kunnen worden uitgevoerd in een QA- of testomgeving met behulp van Advanced Threat Protection die scant op code die kwetsbaar is voor SQL-injectie.

  • Voorbeelden van wat u moet bekijken:

    • Het maken van een gebruiker of het wijzigen van beveiligingsinstellingen vanuit een geautomatiseerde SQL-code-update-implementatie.
    • Een opgeslagen procedure, die, afhankelijk van de opgegeven parameters, een monetaire waarde in een cel op een niet-conforme manier bijwerkt.

  • Zorg ervoor dat de persoon die de beoordeling uitvoert een andere persoon is dan de auteur van de oorspronkelijke code en kennis heeft van veilige codering en codebeoordelingen.

  • Zorg ervoor dat u alle bronnen van codewijzigingen kent. Code kan zich in T-SQL-scripts bevindt. Het kan ad-hocopdrachten zijn die moeten worden uitgevoerd of geïmplementeerd in vormen van weergaven, functies, triggers en opgeslagen procedures. Het kan deel uitmaken van SQL Agent-taakdefinities (stappen). Het kan ook worden uitgevoerd vanuit SSIS-pakketten, Azure Data Factory en andere services.

Gegevensbescherming

Gegevensbescherming is een set mogelijkheden voor het beveiligen van belangrijke informatie tegen inbreuk door versleuteling of verdoofing.

Opmerking

Microsoft attesteert aan Azure SQL Database en Azure SQL Managed Instance als compatibel met FIPS 140-2 Level 1. Dit wordt gedaan na verificatie van het strikte gebruik van FIPS 140-2 Niveau 1 acceptabele algoritmen en FIPS 140-2 Niveau 1 gevalideerde toepassingen van deze algoritmen, inclusief consistentie met vereiste sleutellengten, sleutelbeheer, sleutelgeneratie, en sleutelopslag. Deze attestation is bedoeld om onze klanten in staat te stellen te reageren op de behoefte of vereiste voor het gebruik van gevalideerde FIPS 140-2 Level 1-exemplaren bij de verwerking van gegevens of levering van systemen of toepassingen. We definiëren de termen "FIPS 140-2 Level 1 compliant" en "FIPS 140-2 Level 1 compliance" die in de bovenstaande verklaring worden gebruikt om hun beoogde toepasbaarheid voor gebruik door de Amerikaanse en Canadese overheid van de andere term "FIPS 140-2 Level 1 gevalideerd" te demonstreren.

Actieve gegevens versleutelen

Vermeld in: OSA Practice #6, ISO Control Family: Cryptografie

Beveiligt uw gegevens terwijl gegevens worden verplaatst tussen uw client en server. Raadpleeg Netwerkbeveiliging.

Gegevens die zich in rust bevinden versleutelen

Vermeld in: OSA Practice #6, ISO Control Family: Cryptografie

Versleuteling bij opslag is de cryptografische beveiliging van gegevens wanneer deze worden opgeslagen in database-, log- en back-upbestanden.

Implementeren

  • Transparent Data Encryption (TDE) met door de service beheerde sleutels zijn standaard ingeschakeld voor databases die na 2017 zijn gemaakt in Azure SQL Database en SQL Managed Instance.
  • Als in een beheerd exemplaar de database wordt gemaakt op basis van een herstelbewerking met behulp van een on-premises server, wordt de TDE-instelling van de oorspronkelijke database gehonoreerd. Als TDE niet is ingeschakeld voor de oorspronkelijke database, raden we u aan om TDE handmatig in te schakelen voor het beheerde exemplaar.

Beste praktijken

  • Sla geen gegevens op waarvoor in rust versleuteling is vereist in de master database. De master database kan niet worden versleuteld met TDE.

  • Gebruik door de klant beheerde sleutels in Azure Key Vault als u meer transparantie en gedetailleerde controle over de TDE-beveiliging nodig hebt. Met Azure Key Vault kunt u machtigingen op elk gewenst moment intrekken om de database ontoegankelijk te maken. U kunt TDE-protectors centraal beheren, samen met andere sleutels, of de TDE-protector op uw eigen schema roteren met behulp van Azure Key Vault.

  • Als u door de klant beheerde sleutels in Azure Key Vault gebruikt, volgt u de artikelen, Richtlijnen voor het configureren van TDE met Azure Key Vault en het configureren van Geo-DR met Azure Key Vault.

Opmerking

Sommige items die als klantinhoud worden beschouwd, zoals tabelnamen, objectnamen en indexnamen, kunnen worden verzonden in logboekbestanden voor ondersteuning en probleemoplossing door Microsoft.

Gevoelige gegevens beschermen die worden gebruikt tegen onbevoegde gebruikers met hoge bevoegdheden

Gegevens die in gebruik zijn, zijn de gegevens die zijn opgeslagen in het geheugen van het databasesysteem tijdens de uitvoering van SQL-query's. Als uw database gevoelige gegevens opslaat, kan uw organisatie zijn vereist om ervoor te zorgen dat gebruikers met hoge bevoegdheden geen gevoelige gegevens in uw database kunnen weergeven. Gebruikers met hoge bevoegdheden, zoals Microsoft-operators of DBA's in uw organisatie, moeten de database kunnen beheren, maar kunnen geen gevoelige gegevens weergeven en mogelijk exfiltreren uit het geheugen van het SQL-proces of door query's uit te voeren op de database.

Het beleid dat bepaalt welke gegevens gevoelig zijn en of de gevoelige gegevens in het geheugen moeten worden versleuteld en niet toegankelijk zijn voor beheerders in tekst zonder opmaak, zijn specifiek voor uw organisatie en nalevingsregels waaraan u moet voldoen. Raadpleeg de gerelateerde vereiste: gevoelige gegevens identificeren en taggen.

Implementeren

  • Gebruik Always Encrypted om ervoor te zorgen dat gevoelige gegevens niet worden weergegeven in platte tekst in Azure SQL Database of SQL Managed Instance, zelfs in geheugen/in gebruik. Always Encrypted beveiligt de gegevens tegen databasebeheerders (DBA's) en cloudbeheerders (of slechte actoren die zich kunnen voordoen als gebruikers met hoge bevoegdheden, maar niet-geautoriseerde gebruikers) en geeft u meer controle over wie toegang heeft tot uw gegevens.

Beste praktijken

  • Always Encrypted is geen vervanging voor het versleutelen van gegevens die in rust zijn (TDE) of tijdens overdracht (SSL/TLS). Always Encrypted mag niet worden gebruikt voor niet-gevoelige gegevens om de invloed van de prestaties en functionaliteit te minimaliseren. Het gebruik van Always Encrypted in combinatie met TDE en TLS (Transport Layer Security) wordt aanbevolen voor uitgebreide beveiliging van data-at-rest, in transit en in gebruik.

  • Beoordeel de impact van het versleutelen van de geïdentificeerde kolommen met gevoelige gegevens voordat u Always Encrypted implementeert in een productiedatabase. Over het algemeen vermindert Always Encrypted de functionaliteit van query's op versleutelde kolommen en heeft andere beperkingen, vermeld in Always Encrypted - Functiedetails. Daarom moet u uw toepassing mogelijk opnieuw ontwerpen om de functionaliteit opnieuw in te stellen. Een query biedt geen ondersteuning voor het databaseschema aan de clientzijde of/en het herstructureren van uw databaseschema, inclusief de definities van opgeslagen procedures, functies, weergaven en triggers. Bestaande toepassingen werken mogelijk niet met versleutelde kolommen als ze niet voldoen aan de beperkingen en beperkingen van Always Encrypted. Hoewel het ecosysteem van Microsoft-hulpprogramma's, producten en services die Always Encrypted ondersteunen, groeit, werken een aantal ervan niet met versleutelde kolommen. Het versleutelen van een kolom kan ook van invloed zijn op de queryprestaties, afhankelijk van de kenmerken van uw workload.

  • Beheer Always Encrypted-sleutels met functiescheiding als u Always Encrypted gebruikt om gegevens te beschermen tegen schadelijke DBA's. Met functiescheiding maakt een beveiligingsbeheerder de fysieke sleutels. De DBA maakt de metagegevensobjecten voor kolomhoofdsleutels en kolomversleutelingssleutels die de fysieke sleutels in de database beschrijven. Tijdens dit proces heeft de beveiligingsbeheerder geen toegang nodig tot de database en heeft de DBA geen toegang nodig tot de fysieke sleutels in tekst zonder opmaak.

  • Sla uw kolomhoofdsleutels op in Azure Key Vault voor eenvoudig beheer. Vermijd het gebruik van Windows Certificate Store (en in het algemeen gedistribueerde oplossingen voor sleutelarchief, in tegenstelling tot oplossingen voor centraal sleutelbeheer) die sleutelbeheer hard maken.

  • Denk zorgvuldig na over de afwegingen van het gebruik van meerdere sleutels (kolomhoofdsleutel of kolomversleutelingssleutels). Houd het aantal sleutels klein om de kosten voor sleutelbeheer te verlagen. Eén kolomhoofdsleutel en één kolomversleutelingssleutel per database is doorgaans voldoende in omgevingen met een stabiele status (niet in het midden van een sleutelrotatie). Mogelijk hebt u extra sleutels nodig als u verschillende gebruikersgroepen hebt, elk met verschillende sleutels en toegang tot verschillende gegevens.

  • Draai kolomhoofdsleutels volgens uw nalevingsvereisten. Als u ook kolomversleutelingssleutels moet roteren, kunt u online-versleuteling gebruiken om de uitvaltijd van applicaties te minimaliseren.

  • Gebruik deterministische versleuteling als berekeningen (gelijkheid) voor gegevens moeten worden ondersteund. Gebruik anders willekeurige versleuteling. Vermijd het gebruik van deterministische versleuteling voor gegevenssets met lage entropie of gegevenssets met openbaar bekende distributie.

  • Als u zich zorgen maakt over derden die uw gegevens juridisch openen zonder uw toestemming, moet u ervoor zorgen dat alle toepassingen en hulpprogramma's die toegang hebben tot de sleutels en gegevens in tekst zonder opmaak, buiten Microsoft Azure Cloud worden uitgevoerd. Zonder toegang tot de sleutels heeft de derde partij geen manier om de gegevens te ontsleutelen, tenzij ze de versleuteling omzeilen.

  • Always Encrypted biedt niet eenvoudig ondersteuning voor het verlenen van tijdelijke toegang tot de sleutels (en de beveiligde gegevens). Als u bijvoorbeeld de sleutels wilt delen met een DBA, zodat de DBA bepaalde opschoningsbewerkingen kan uitvoeren op gevoelige en versleutelde gegevens. De enige manier om de toegang tot de gegevens van de DBA betrouwbaar in te trekken, is door zowel de kolomversleutelingssleutels als de kolomhoofdsleutels die de gegevens beschermen te roteren, wat een kostbare bewerking is.

  • Voor toegang tot de waarden voor tekst zonder opmaak in versleutelde kolommen moet een gebruiker toegang hebben tot de CMK (Column Master Key) die kolommen beveiligt, die is geconfigureerd in het sleutelarchief met de CMK. nl-NL: De gebruiker moet ook de ELKE KOLOMHOOFDSLEUTELDEFINITIE WEERGEVEN en ELKE KOLOMVERSLEUTELINGSSLEUTELDEFINITIE WEERGEVEN database machtigingen.

Toegang van toepassingsgebruikers tot gevoelige gegevens beheren via versleuteling

Versleuteling kan worden gebruikt als een manier om ervoor te zorgen dat alleen specifieke toepassingsgebruikers die toegang hebben tot cryptografische sleutels de gegevens kunnen bekijken of bijwerken.

Implementeren

  • Versleuteling op celniveau (CLE) gebruiken. Zie het artikel Een kolom met gegevens versleutelen voor meer informatie.
  • Gebruik Always Encrypted, maar wees op de hoogte van de beperking. Hieronder vindt u de beperkingen.

Beste praktijken:

Wanneer u CLE gebruikt:

  • Toegang tot sleutels beheren via SQL-machtigingen en -rollen.

  • Gebruik AES (AES 256 aanbevolen) voor gegevensversleuteling. Algoritmen, zoals RC4, DES en TripleDES, zijn afgeschaft en mogen niet worden gebruikt vanwege bekende beveiligingsproblemen.

  • Beveilig symmetrische sleutels met asymmetrische sleutels/certificaten (geen wachtwoorden) om 3DES te voorkomen.

  • Wees voorzichtig bij het migreren van een database met behulp van Cell-Level Encryption via export/import (bacpac-bestanden).

Houd er rekening mee dat Always Encrypted voornamelijk is ontworpen om gevoelige gegevens in gebruik te beschermen tegen gebruikers met hoge bevoegdheden van Azure SQL Database (cloudoperators, DBA's). Zie Gevoelige gegevens beschermen tegen ongeautoriseerde gebruikers met hoge bevoegdheden voor meer informatie. Houd rekening met de volgende uitdagingen bij het gebruik van Always Encrypted om gegevens te beschermen tegen toepassingsgebruikers:

  • Standaard onderhouden alle Microsoft-clientstuurprogramma's die Always Encrypted ondersteunen een globale cache (één per toepassing) van kolomversleutelingssleutels. Zodra een clientstuurprogramma een onversleutelde kolomversleutelingssleutel verkrijgt door contact op te nemen met een sleutelarchief met een kolommeestersleutel, wordt de onversleutelde kolomversleutelingssleutel in de cache opgeslagen. Dit maakt het isoleren van gegevens van gebruikers van een toepassing voor meerdere gebruikers lastig. Als uw toepassing de identiteit van eindgebruikers aanneemt bij interactie met een sleutelarchief (zoals Azure Key Vault), zal een query van een gebruiker die de cache vult met een kolomversleutelingssleutel ertoe leiden dat een volgende query die dezelfde sleutel vereist maar door een andere gebruiker wordt geactiveerd, de gecachede sleutel gebruikt. Het stuurprogramma roept het sleutelarchief niet aan en controleert niet of de tweede gebruiker toegang heeft tot de kolomversleutelingssleutel. Als gevolg hiervan kan de gebruiker de versleutelde gegevens zien, zelfs als de gebruiker geen toegang heeft tot de sleutels. Als u de isolatie van gebruikers binnen een toepassing met meerdere gebruikers wilt bereiken, kunt u caching van kolomversleutelingssleutels uitschakelen. Het uitschakelen van caching veroorzaakt extra overhead voor prestaties, omdat het stuurprogramma contact moet opnemen met het sleutelarchief voor elke gegevensversleutelings- of ontsleutelingsbewerking.

Gegevens beschermen tegen onbevoegde weergave door toepassingsgebruikers terwijl de gegevensindeling behouden blijft

Een andere techniek om te voorkomen dat onbevoegde gebruikers gegevens bekijken, is door de gegevens te verdoezelen of te maskeren terwijl gegevenstypen en -indelingen behouden blijven om ervoor te zorgen dat gebruikerstoepassingen de gegevens kunnen blijven verwerken en weergeven.

Implementeren

Opmerking

Always Encrypted werkt niet met dynamische gegevensmaskering. Het is niet mogelijk om dezelfde kolom te versleutelen en maskeren. Dit houdt in dat u prioriteit moet geven aan het beveiligen van gegevens in gebruik versus het maskeren van de gegevens voor uw app-gebruikers via dynamische gegevensmaskering.

Beste praktijken

Opmerking

Dynamische gegevensmaskering kan niet worden gebruikt om gegevens te beschermen tegen gebruikers met hoge bevoegdheden. Maskeringsbeleid is niet van toepassing op gebruikers met beheerderstoegang, zoals db_owner.

  • Sta niet toe dat app-gebruikers ad-hocquery's uitvoeren (omdat ze mogelijk dynamische gegevensmaskering kunnen omzeilen). Zie Maskering overslaan met behulp van deductie- of brute-force technieken voor meer informatie.

  • Gebruik een juist toegangsbeheerbeleid (via SQL-machtigingen, rollen, RLS) om gebruikersmachtigingen te beperken om updates in de gemaskeerde kolommen te maken. Het maken van een masker op een kolom voorkomt geen updates voor die kolom. Gebruikers die gemaskeerde gegevens ontvangen bij het uitvoeren van query's op de gemaskeerde kolom, kunnen de gegevens bijwerken als ze schrijfmachtigingen hebben.

  • Dynamische gegevensmaskering behoudt niet de statistische eigenschappen van de gemaskeerde waarden. Dit kan van invloed zijn op queryresultaten (bijvoorbeeld query's met filterpredicaten of joins op de gemaskeerde gegevens).

Netwerkbeveiliging

Netwerkbeveiliging verwijst naar toegangsbeheer en aanbevolen procedures voor het beveiligen van uw gegevens tijdens overdracht naar Azure SQL Database.

Mijn client configureren om veilig verbinding te maken met SQL Database/SQL Managed Instance

Aanbevolen procedures voor het voorkomen van clientcomputers en toepassingen met bekende beveiligingsproblemen (bijvoorbeeld het gebruik van oudere TLS-protocollen en coderingssuites) om verbinding te maken met Azure SQL Database en SQL Managed Instance.

Implementeren

Beste praktijken

  • Dwing een minimale TLS-versie af op de logische server in Azure SQL Database of Azure SQL Managed Instance met behulp van de minimale TLS-versie-instelling. We raden u aan om de minimale TLS-versie in te stellen op 1.2 nadat u hebt getest of uw toepassingen deze ondersteunen. TLS 1.2 bevat oplossingen voor beveiligingsproblemen die in eerdere versies zijn gevonden.

  • Al uw apps en hulpprogramma's configureren om verbinding te maken met SQL Database met versleuteling ingeschakeld

    • Encrypt = On, TrustServerCertificate = Off (of equivalent met niet-Microsoft-stuurprogramma's).

  • Als uw app gebruikmaakt van een stuurprogramma dat geen ondersteuning biedt voor TLS of een oudere versie van TLS ondersteunt, vervangt u indien mogelijk het stuurprogramma. Indien niet mogelijk, moet u de beveiligingsrisico's zorgvuldig evalueren.

Aanvalsoppervlak minimaliseren

Minimaliseer het aantal functies dat kan worden aangevallen door een kwaadwillende gebruiker. Implementeer besturingselementen voor netwerktoegang voor Azure SQL Database.

Vermeld in: OSA Practice #5

Implementeren

In Azure SQL Database:

  • Stel "Toegang tot Azure-services toestaan" op serverniveau in op UIT.
  • VNet-service-eindpunten en VNet-firewallregels gebruiken.
  • Gebruik Private Link.

In SQL Managed Instance:

Beste praktijken

  • Toegang tot Azure SQL Database en SQL Managed Instance beperken door verbinding te maken op een privé-eindpunt (bijvoorbeeld met behulp van een privégegevenspad):

    • Een beheerd exemplaar kan worden geïsoleerd binnen een virtueel netwerk om externe toegang te voorkomen. Toepassingen en hulpprogramma's die zich in hetzelfde of gekoppeld virtueel netwerk in dezelfde regio bevinden, hebben rechtstreeks toegang tot het netwerk. Toepassingen en hulpprogramma's die zich in een andere regio bevinden, kunnen gebruikmaken van een virtual-network-naar-virtual-network-verbinding of ExpressRoute-circuitpeering om verbinding te maken. De klant moet netwerkbeveiligingsgroepen (NSG) gebruiken om de toegang via poort 1433 alleen te beperken tot resources die toegang tot een beheerd exemplaar vereisen.
    • Voor Azure SQL Database gebruikt u Private Link, dat een toegewezen privé-IP biedt voor de server in uw virtuele netwerk. U kunt ook service-eindpunten voor virtuele netwerken gebruiken om de toegang tot uw logische servers te beperken.
    • Mobiele gebruikers moeten punt-naar-site-VPN-verbindingen gebruiken om verbinding te maken via het gegevenspad.
    • Gebruikers die zijn verbonden met hun on-premises netwerk, moeten site-naar-site-VPN-verbinding of ExpressRoute gebruiken om verbinding te maken via het gegevenspad.

  • U hebt toegang tot Azure SQL Database en SQL Managed Instance door verbinding te maken met een openbaar eindpunt (bijvoorbeeld via een openbaar gegevenspad). De volgende aanbevolen procedures moeten worden overwogen:

    Opmerking

    Het openbare eindpunt van SQL Managed Instance is niet standaard ingeschakeld en moet expliciet worden ingeschakeld. Als het bedrijfsbeleid het gebruik van openbare eindpunten niet toekent, gebruikt u Azure Policy om te voorkomen dat openbare eindpunten in de eerste plaats worden ingeschakeld.

  • Azure-netwerkonderdelen instellen:

Power BI configureren voor beveiligde verbindingen met SQL Database/SQL Managed Instance

Beste praktijken

  • Gebruik waar mogelijk het privégegevenspad voor Power BI Desktop.

  • Zorg ervoor dat Power BI Desktop verbinding maakt met TLS1.2 door de registersleutel op de clientcomputer in te stellen volgens de registerinstellingen voor Transport Layer Security (TLS ).

  • Beperk de toegang tot gegevens voor specifieke gebruikers via beveiliging op rijniveau (RLS) met Power BI.

  • Voor de Power BI-service gebruikt u de on-premises gegevensgateway, rekening houdend met beperkingen en overwegingen.

App Service configureren voor beveiligde verbindingen met SQL Database/SQL Managed Instance

Beste praktijken

Configureren van virtuele Azure-machines voor beveiligde verbindingen met SQL Database/SQL Managed Instance

Beste praktijken

  • Gebruik een combinatie van regels voor toestaan en weigeren op de NSG's van virtuele Azure-machines om te bepalen welke regio's toegankelijk zijn vanaf de virtuele machine.

  • Zorg ervoor dat uw VIRTUELE machine is geconfigureerd volgens het artikel, aanbevolen beveiligingsprocedures voor IaaS-workloads in Azure.

  • Zorg ervoor dat alle VM's zijn gekoppeld aan een specifiek virtueel netwerk en subnet.

  • Evalueer of u de standaardroute 0.0.0.0/Internet nodig hebt volgens de richtlijnen voor geforceerde tunneling.

    • Zo ja, bijvoorbeeld front-endsubnet, houdt u de standaardroute.
    • Als er geen sprake is van bijvoorbeeld een middelste laag of back-endsubnet, schakelt u geforceerde tunneling in, zodat er geen verkeer via internet naar on-premises, ook wel cross-premises, gaat.

  • Implementeer optionele standaardroutes als u peering gebruikt of verbinding maakt met on-premises.

  • Implementeer door de gebruiker gedefinieerde routes als u al het verkeer in het virtuele netwerk wilt verzenden naar een virtueel netwerkapparaat voor pakketinspectie.

  • Gebruik service-eindpunten voor virtuele netwerken voor beveiligde toegang tot PaaS-services zoals Azure Storage via het Azure backbone-netwerk.

Bescherming tegen DDoS-aanvallen (Distributed Denial of Service)

DDoS-aanvallen (Distributed Denial of Service) zijn pogingen van een kwaadwillende gebruiker om een stroom netwerkverkeer naar Azure SQL Database te verzenden, met als doel de Azure-infrastructuur te overspoelen en ervoor te zorgen dat deze geldige aanmeldingen en workload weigert.

Vermeld in: OSA Praktijk #9

Implementeren

DDoS-beveiliging wordt automatisch ingeschakeld als onderdeel van het Azure-platform. Het omvat always-on-verkeersbewaking en realtime-beperking van aanvallen op netwerkniveau op openbare eindpunten.

  • Gebruik Azure DDoS Protection om openbare IP-adressen te bewaken die zijn gekoppeld aan resources die zijn geïmplementeerd in virtuele netwerken.

  • Gebruik SQL Advanced Threat Protection om DoS-aanvallen (Denial of Service) tegen databases te detecteren.

Beste praktijken

  • Volg de procedures die worden beschreven in Attack Surface minimaliseren om DDoS-aanvalsrisico's te minimaliseren.

  • Met de waarschuwing van Advanced Threat Protection Brute force SQL-referenties kunt u brute force-aanvallen detecteren. In sommige gevallen kan de waarschuwing zelfs penetratietestworkloads onderscheiden.

  • Voor Azure VM-hostingtoepassingen die verbinding maken met SQL Database:

    • Volg de aanbeveling om de toegang te beperken via internetgerichte eindpunten in Microsoft Defender voor Cloud.
    • Gebruik virtuele-machineschaalsets om meerdere exemplaren van uw toepassing uit te voeren op Virtuele Azure-machines.
    • Schakel RDP en SSH van internet uit om beveiligingsaanvallen te voorkomen.

Bewaking, logboekregistratie en controle

Deze sectie verwijst naar mogelijkheden waarmee u afwijkende activiteiten kunt detecteren die duiden op ongebruikelijke en mogelijk schadelijke pogingen om toegang te krijgen tot of misbruik te maken van databases. Ook worden aanbevolen procedures beschreven voor het configureren van databasecontrole om database-gebeurtenissen bij te houden en vast te leggen.

Databases beschermen tegen aanvallen

Met Advanced Threat Protection kunt u potentiële bedreigingen detecteren en erop reageren wanneer deze zich voordoen door beveiligingswaarschuwingen te bieden voor afwijkende activiteiten.

Implementeren

  • Gebruik Advanced Threat Protection voor SQL om ongebruikelijke en mogelijk schadelijke pogingen te detecteren om toegang te krijgen tot of misbruik te maken van databases, waaronder:
    • SQL-injectieaanval.
    • Diefstal/lek van inloggegevens.
    • Misbruik van bevoegdheden.
    • Gegevensexfiltratie.

Beste praktijken

Kritieke beveiligingsgebeurtenissen controleren

Het bijhouden van database-gebeurtenissen helpt u inzicht te hebben in databaseactiviteit. U kunt inzicht krijgen in verschillen en afwijkingen die kunnen duiden op zakelijke problemen of vermoedelijke schendingen van de beveiliging. Het maakt ook naleving van nalevingsstandaarden mogelijk en vergemakkelijkt.

Implementeren

  • Inschakelen van Azure SQL Database-auditing of SQL Managed Instance-auditing om databasegebeurtenissen bij te houden en deze te schrijven naar een auditlogboek in uw Azure Storage-account, Log Analytics-werkruimte (preview) of Event Hubs (preview).

  • Auditlogboeken kunnen worden geschreven naar een Azure Storage-account, naar een Log Analytics-werkruimte voor verbruik door Azure Monitor-logboeken of naar Event Hub voor verbruik met behulp van Event Hub. U kunt elke combinatie van deze opties configureren en auditlogboeken worden naar elke optie geschreven.

Beste praktijken

  • Door controle voor Azure SQL Database of Azure SQL Managed Instance te configureren om gebeurtenissen te controleren, worden alle bestaande en nieuw gemaakte databases op die server gecontroleerd.
  • Standaard omvat het controlebeleid alle acties (query's, opgeslagen procedures en geslaagde en mislukte aanmeldingen) voor de databases, wat kan leiden tot een groot aantal auditlogboeken. Het wordt aanbevolen voor klanten om controle te configureren voor verschillende soorten acties en actiegroepen met behulp van PowerShell. Als u dit configureert, kunt u het aantal gecontroleerde acties beheren en het risico op verlies van gebeurtenissen minimaliseren. Met aangepaste controleconfiguraties kunnen klanten alleen de controlegegevens vastleggen die nodig zijn.
  • Auditlogboeken kunnen rechtstreeks worden gebruikt in Azure Portal of vanuit de opslaglocatie die is geconfigureerd.

Opmerking

Voor het inschakelen van controle voor Log Analytics worden kosten in rekening gebracht op basis van opnametarieven. Houd rekening met de bijbehorende kosten voor het gebruik van deze optie of overweeg de auditlogboeken op te slaan in een Azure-opslagaccount.

Meer informatiebronnen

Auditlogboeken beveiligen

Beperk de toegang tot het opslagaccount om scheiding van taken te ondersteunen en DBA van Auditors te scheiden.

Implementeren

  • Wanneer u auditlogboeken opslaat in Azure Storage, moet u ervoor zorgen dat de toegang tot het opslagaccount wordt beperkt tot de minimale beveiligingsprincipes. Bepalen wie toegang heeft tot het opslagaccount.
  • Zie Toegang tot Azure Storage autoriseren voor meer informatie.

Beste praktijken

Beveiligingsbeheer

In deze sectie worden de verschillende aspecten en aanbevolen procedures beschreven voor het beheren van uw beveiligingspostuur voor databases. Het bevat aanbevolen procedures om ervoor te zorgen dat uw databases zijn geconfigureerd om te voldoen aan beveiligingsstandaarden, voor het detecteren en bijhouden van toegang tot mogelijk gevoelige gegevens in uw databases.

Zorg ervoor dat de databases zijn geconfigureerd om te voldoen aan aanbevolen beveiligingsprocedures

Verbeter uw databasebeveiliging proactief door potentiële beveiligingsproblemen in de database te detecteren en op te slaan.

Implementeren

  • Schakel SQL Vulnerability Assessment (VA) in om uw database te scannen op beveiligingsproblemen en om automatisch periodiek op uw databases uit te voeren.

Beste praktijken

  • Voer in eerste instantie VA uit op uw databases en herhaal het proces door mislukte controles te herstellen die in strijd zijn met de beste beveiligingspraktijken. Stel basislijnen in voor acceptabele configuraties totdat de scan schoon is of alle controles zijn geslaagd.

  • Configureer periodieke terugkerende scans om eenmaal per week uit te voeren en configureer de relevante persoon voor het ontvangen van samenvattingsmails.

  • Bekijk de VA-samenvatting na elke wekelijkse scan. Voor eventuele gevonden beveiligingsproblemen evalueert u de afwijking van het vorige scanresultaat en bepaalt u of de controle moet worden opgelost. Controleer of er een legitieme reden is voor de wijziging in de configuratie.

  • Los problemen met controles op en werk basislijnen bij, indien relevant. Maak ticketitems voor het oplossen van acties en volg deze totdat ze zijn opgelost.

Meer informatiebronnen

Gevoelige gegevens identificeren en taggen

Kolommen detecteren die mogelijk gevoelige gegevens bevatten. Wat als gevoelige gegevens wordt beschouwd, is sterk afhankelijk van de klant, nalevingsregelgeving, enzovoort, en moet worden geëvalueerd door de gebruikers die verantwoordelijk zijn voor die gegevens. Classificeer de kolommen om geavanceerde controle- en beveiligingsscenario's op basis van gevoeligheid te gebruiken.

Implementeren

  • Gebruik Gegevensdetectie en -classificatie om gevoelige gegevens in uw databases te detecteren, classificeren, labelen en beveiligen.
    • Bekijk de classificatie-aanbevelingen die zijn gemaakt door de geautomatiseerde detectie in het SQL Data Discovery en Classificatie-dashboard. Accepteer de relevante classificaties, zodat uw gevoelige gegevens permanent worden gelabeld met classificatielabels.
    • Voeg handmatig classificaties toe voor aanvullende gevoelige gegevensvelden die niet zijn gedetecteerd door het geautomatiseerde mechanisme.
  • Zie SQL Data Discovery en Classification voor meer informatie.

Beste praktijken

  • Bewaak het classificatiedashboard regelmatig voor een nauwkeurige beoordeling van de classificatiestatus van de database. Een rapport over de classificatiestatus van de database kan worden geëxporteerd of afgedrukt om te delen voor nalevings- en controledoeleinden.

  • Controleer continu de status van aanbevolen gevoelige gegevens in sql Vulnerability Assessment. Volg de detectieregel voor gevoelige gegevens en identificeer eventuele veranderingen van de aanbevolen kolommen voor classificatie.

  • Gebruik classificatie op een manier die is afgestemd op de specifieke behoeften van uw organisatie. Pas uw Information Protection-beleid (vertrouwelijkheidslabels, informatietypen, detectielogica) aan in het SQL Information Protection-beleid in Microsoft Defender voor Cloud.

Toegang tot gevoelige gegevens bijhouden

Bewaak wie toegang heeft tot gevoelige gegevens en leg query's vast op gevoelige gegevens in auditlogboeken.

Implementeren

Beste praktijken

Beveiligings- en nalevingsstatus visualiseren

Gebruik een geïntegreerd beveiligingsbeheersysteem voor infrastructuur dat de beveiligingspostuur van uw datacenters (inclusief databases in SQL Database) versterkt. Bekijk een lijst met aanbevelingen met betrekking tot de beveiliging van uw databases en nalevingsstatus.

Implementeren

Veelvoorkomende beveiligingsrisico's en mogelijke oplossingen

In deze sectie vindt u beveiligingsmaatregelen ter bescherming tegen bepaalde aanvalsvectoren. Er wordt verwacht dat de meeste oplossingen kunnen worden bereikt door een of meer van de bovenstaande beveiligingsrichtlijnen te volgen.

Beveiligingsrisico: Gegevensexfiltratie

Gegevensexfiltratie is het niet-geautoriseerd kopiëren, overdragen of ophalen van gegevens van een computer of server. Bekijk een definitie voor gegevensexfiltratie op Wikipedia.

Als u verbinding maakt met de server via een openbaar eindpunt, loopt u een risico op gegevensexfiltratie, omdat klanten hun firewalls moeten openen naar openbare IP-adressen.

Scenario 1: Een toepassing op een Azure-VM maakt verbinding met een database in Azure SQL Database. Een rogue actor krijgt toegang tot de virtuele machine en maakt inbreuk op de VM. In dit scenario betekent gegevensexfiltratie dat een externe entiteit die gebruikmaakt van de rogue VM verbinding maakt met de database, persoonlijke gegevens kopieert en opslaat in een blobopslag of een andere SQL Database in een ander abonnement.

Scenario 2: Een onbetrouwbare DBA. Dit scenario wordt vaak veroorzaakt door beveiligingsgevoelige klanten uit gereglementeerde branches. In dit scenario kan een gebruiker met hoge bevoegdheden gegevens kopiëren van Azure SQL Database naar een ander abonnement dat niet wordt beheerd door de eigenaar van de gegevens.

Mogelijke oplossingen

Tegenwoordig bieden Azure SQL Database en SQL Managed Instance de volgende technieken voor het beperken van bedreigingen voor gegevensexfiltratie:

  • Gebruik een combinatie van regels voor toestaan en weigeren op de NSG's van Virtuele Azure-machines om te bepalen welke regio's toegankelijk zijn vanaf de VIRTUELE machine.
  • Als u een server in SQL Database gebruikt, stelt u de volgende opties in:
    • Toestaan dat Azure-services worden uitgeschakeld.
    • Sta alleen verkeer toe vanuit het subnet met uw Azure-VM door een VNet-firewallregel in te stellen.
    • Private Link gebruiken
  • Voor SQL Managed Instance is het gebruik van privé-IP-toegang standaard gericht op het eerste probleem van gegevensexfiltratie van een frauduleuze VM. Schakel de functie voor subnetdelegering in op een subnet om automatisch het meest beperkende beleid in te stellen voor een subnet met SQL Managed Instance.
  • De zorg over een schadelijke DBA wordt meer blootgesteld bij SQL Managed Instance omdat het een groter aanvalsoppervlak heeft en netwerkvereisten inzichtelijk zijn voor klanten. De beste oplossing hiervoor is het toepassen van alle procedures in deze beveiligingshandleiding om het Rogue DBA-scenario in de eerste plaats te voorkomen (niet alleen voor gegevensexfiltratie). Always Encrypted is één methode om gevoelige gegevens te beveiligen door deze te versleutelen en de sleutel ontoegankelijk te houden voor de DBA.

Beveiligingsaspecten van bedrijfscontinuïteit en beschikbaarheid

De meeste beveiligingsstandaarden hebben betrekking op de beschikbaarheid van gegevens in termen van operationele continuïteit, bereikt door redundantie en failovermogelijkheden te implementeren om single points of failure te voorkomen. Voor noodscenario's is het gebruikelijk om back-ups van gegevens- en logboekbestanden te bewaren. In de volgende sectie vindt u een overzicht op hoog niveau van de mogelijkheden die zijn ingebouwd in Azure. Het biedt ook aanvullende opties die kunnen worden geconfigureerd om te voldoen aan specifieke behoeften:

Volgende stap

Een overzicht van de beveiligingsmogelijkheden van Azure SQL Database en SQL Managed Instance