Delen via

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

  • Artikel

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.

Notitie

Microsoft Entra-id is de nieuwe naam voor Azure Active Directory (Azure AD). Op dit moment wordt de documentatie bijgewerkt.

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 op beveiligingsgebieden op 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

Doelgroep

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 officer
  • Privacyfunctionarissen
  • Beveiligingstechnici

Gebruik van deze handleiding

Dit document is bedoeld als aanvulling op onze bestaande Azure SQL Database-beveiligingsdocumentatie .

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.

Verificatie

Verificatie is het proces waarmee kan worden bewezen 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-verificatie

Notitie

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.

Aanbevolen procedures

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

    Notitie

    In SQL Managed Instance kunt u ook aanmeldingen maken die zijn toegewezen 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.

Notitie

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

Aanbevolen procedures

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

    Notitie

    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. Referenties kunnen worden aangetast of per ongeluk worden weggegeven.

Implementeren

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

Aanbevolen procedures

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

Aanbevolen procedures

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.

Aanbevolen procedures

  • Als wachtwoorden of geheimen niet mogelijk zijn, slaat u gebruikerswachtwoorden en toepassingsgeheimen op in Azure Key Vault en beheert u de toegang via key Vault-toegangsbeleid.

  • Verschillende frameworks voor app-ontwikkeling kunnen ook frameworkspecifieke mechanismen bieden 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 aanmelding worden gemaakt in elke server of elk beheerd exemplaar en een gebruiker die in elke database is gemaakt.

Implementeren

  • GEBRUIK SQL-verificatie.

Aanbevolen procedures

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 het artikel Just enough administration voor meer informatie.

Implementeren

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

  • In SQL Databases:

    • Gebruik gedetailleerde machtigingen en door de gebruiker gedefinieerde databaserollen (of serverrollen in SQL Managed Instance):
      1. De vereiste rollen maken
      2. Vereiste gebruikers maken
      3. Gebruikers toevoegen als leden aan rollen
      4. Wijs vervolgens machtigingen toe aan rollen.
    • Zorg ervoor dat u geen gebruikers toewijst aan onnodige rollen.

  • In Azure Resource Manager:

Aanbevolen procedures

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 met rapportage- en probleemoplossingsmachtigingen. (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
    • Beheerder
    • Ontwikkelaar
    • Ondersteuningspersoneel
    • Auditor
    • 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 database) in Azure
    • Database
    • Schema
      • Het is een best practice om schema's te gebruiken om machtigingen in een database te verlenen.
    • Object (tabel, weergave, procedure, enzovoort)

    Notitie

    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 configuratie van de algemene criteria van de server voor naleving 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 Database Beheer istrator -beheerniveautaken (DBA) 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 tenminste niet zonder grote kosten en inspanningen die het systeem zelfs onbruikbaar kunnen maken, kunnen compromissen worden gemaakt en beperkt door het gebruik van compenserende controles zoals:

Aanbevolen procedures

  • 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 Beveiliging Beheer istrators 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.

Notitie

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 een persoon (anders dan de auteur van de code zelf) zich verbindt met de hoofdvertakking, moet hij de code inspecteren op mogelijke uitbreiding van bevoegdhedenrisico's, evenals wijzigingen in schadelijke gegevens ter bescherming tegen fraude en frauduleuze toegang. Dit kan worden gedaan met behulp van mechanismen voor broncodebeheer.

Aanbevolen procedures

  • 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 in codebeoordelingen en veilige codering.

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

Notitie

Microsoft attesteert aan Azure SQL Database en SQL Managed Instance als compatibel met FIPS 140-2 Level 1. Dit wordt gedaan nadat het strikte gebruik van algoritmen op FIPS 140-2 niveau 1 en fips 140-2 op niveau 1 gevalideerde exemplaren van deze algoritmen is gecontroleerd, 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" gebruikt in de bovenstaande instructie om de beoogde toepasbaarheid voor amerikaanse en Canadese overheid gebruik van de verschillende 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.

Data-at-rest versleutelen

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

Versleuteling-at-rest is de cryptografische beveiliging van gegevens wanneer deze worden bewaard in database-, logboek- 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.

Aanbevolen procedures

  • Sla geen gegevens op waarvoor versleuteling-at-rest in de master database is vereist. 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.

Notitie

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 in uw database gevoelige gegevens worden opgeslagen, is uw organisatie mogelijk 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 Database Beheer istrators (DBA's) en cloudbeheerders (of slechte actoren die zich kunnen voordoen als onbevoegde gebruikers) en geeft u meer controle over wie toegang heeft tot uw gegevens.

Aanbevolen procedures

  • Always Encrypted is geen vervanging voor het versleutelen van data-at-rest (TDE) of in transit (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 te implementeren. 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 draaien, kunt u onlineversleuteling gebruiken om de downtime van toepassingen 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 de gegevens te beveiligen, wat een dure 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. De gebruiker moet ook de MACHTIGING KOLOMHOOFDSLEUTELDEFINITIE WEERGEVEN en ELKE DATABASE MET KOLOMVERSLEUTELINGSSLEUTELDEFINITIES WEERGEVEN.

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.

Best practices:

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 celversleuteling 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 beveiligen die worden gebruikt voor onbevoegde gebruikers met hoge bevoegdheden. 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 versleutelingssleutel voor kolommen zonder tekst verkrijgt door contact op te nemen met een sleutelarchief met een hoofdsleutel voor kolommen, wordt de versleutelingssleutel voor kolom zonder opmaak in de cache opgeslagen. Dit maakt het isoleren van gegevens van gebruikers van een toepassing voor meerdere gebruikers lastig. Als uw toepassing eindgebruikers nabootst bij interactie met een sleutelarchief (zoals Azure Key Vault), gebruikt een volgende query die dezelfde sleutel vereist, nadat de query van een gebruiker de cache heeft gevuld met een kolomversleutelingssleutel, een volgende query waarvoor dezelfde sleutel is vereist, maar wordt geactiveerd door een andere gebruiker de sleutel in de cache. 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

Notitie

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.

Aanbevolen procedures

Notitie

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).

  • 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

  • Zorg ervoor dat clientcomputers die verbinding maken met Azure SQL Database en SQL Managed Instance gebruikmaken van de nieuwste TLS-versie (Transport Layer Security).

Aanbevolen procedures

  • Dwing een minimale TLS-versie af op sql Database-server of SQL Managed Instance-niveau 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.

Kwetsbaarheid voor aanvallen 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 SQL Database:

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

In SQL Managed Instance:

Aanbevolen procedures

  • 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 een SQL Database gebruikt u de Private Link-functie die een toegewezen privé-IP-adres biedt voor de server in uw virtuele netwerk. U kunt service-eindpunten voor virtuele netwerken ook gebruiken met firewallregels voor virtuele netwerken om de toegang tot uw 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:

    Notitie

    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

Aanbevolen procedures

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

Aanbevolen procedures

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

Aanbevolen procedures

  • 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 ( bijvoorbeeld middelste laag of back-endsubnet) is, schakelt u geforceerde tunneling in, zodat er geen verkeer via internet on-premises (bijvoorbeeld cross-premises) kan worden bereikt.

  • 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 Practice #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.

Aanbevolen procedures

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

  • Met de beveiligingswaarschuwing voor Beveiligingsproblemen van Advanced Threat Protection voor SQL-referenties kunt u beveiligingsaanvallen 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 via internetgerichte eindpunten in Microsoft Defender voor Cloud te beperken.
    • 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 referenties.
    • Misbruik van bevoegdheden.
    • Gegevensexfiltratie.

Aanbevolen procedures

  • Configureer Microsoft Defender voor SQL voor een specifieke server of een beheerd exemplaar. U kunt Microsoft Defender voor SQL ook configureren voor alle servers en beheerde exemplaren in een abonnement door Microsoft Defender voor Cloud in te schakelen.

  • Voor een volledige onderzoekservaring is het raadzaam om SQL Database Auditing in te schakelen. Met controle kunt u databasegebeurtenissen bijhouden en naar een auditlogboek schrijven in een Azure Storage-account of Azure Log Analytics-werkruimte.

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

  • Schakel SQL Database Auditing of Managed Instance Auditing in om databasegebeurtenissen bij te houden en naar een auditlogboek te schrijven 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.

Aanbevolen procedures

  • Door SQL Database Auditing op uw server of Managed Instance Auditing te configureren om gebeurtenissen te controleren, worden alle bestaande en zojuist gemaakte databases op die server gecontroleerd.
  • Standaard omvat 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.

Notitie

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.

Aanbevolen procedures

  • Toegang tot het controledoel beheren is een belangrijk concept bij het scheiden van DBA van Auditors.

  • Wanneer u de toegang tot gevoelige gegevens controleert, kunt u overwegen om de gegevens te beveiligen met gegevensversleuteling om te voorkomen dat informatie naar de Auditor lekken. Zie de sectie Gevoelige gegevens beveiligen die worden gebruikt voor onbevoegde gebruikers voor meer informatie.

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.

Aanbevolen procedures

  • Voer in eerste instantie VA uit op uw databases en voer deze uit door mislukte controles te herstellen die zich tegen best practices voor beveiliging verzetten. 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 controles en updatebasislijnen op, 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 SQL Data Discovery en -classificatie om gevoelige gegevens in uw databases te detecteren, classificeren, labelen en beveiligen.
    • Bekijk de classificatieaankopen die zijn gemaakt door de geautomatiseerde detectie in het SQL Data Discovery- en classificatiedashboard. 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.

Aanbevolen procedures

  • 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. Houd de detectieregel voor gevoelige gegevens bij en identificeer eventuele afwijkingen in 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

Aanbevolen procedures

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.

Verbinding maken naar een server via een openbaar eindpunt vormt een risico voor gegevensexfiltratie, omdat klanten hun firewalls moeten openen voor 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 rogue 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 biedt Azure SQL Database en SQL Managed Instance de volgende technieken voor het beperken van gegevensexfiltratiebedreigingen:

  • 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 rogue DBA-zorg wordt meer blootgesteld aan SQL Managed Instance omdat het een groter oppervlak heeft en netwerkvereisten zichtbaar 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 stappen