Playbook voor het voldoen aan algemene beveiligingsvereisten met Azure SQL Database en Azure SQL Managed Instance

  • Artikel
  • 41 minuten om te lezen

VAN TOEPASSING OP: Azure SQL Database Azure SQL Managed Instance

Dit artikel bevat best practices 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 u moet implementeren.

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 is ingedeeld op beveiligingsgebieden op hoog niveau. Raadpleeg de sectie Veelvoorkomende beveiligingsrisico's en mogelijke oplossingen voor het aanpakken van 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 in deze handleiding worden behandeld

  • Azure Synapse Analytics
  • Azure SQL-VM's (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 deze best practice zijn onder andere, maar niet beperkt tot:

  • Beveiligingsarchitecten
  • Beveiligingsmanagers
  • Nalevingsmedewerkers
  • Privacymedewerkers
  • Beveiligingstechnici

Met behulp 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 betreffende doel of de desbetreffende vereiste te bereiken. Om te voldoen aan specifieke beveiligingsstandaarden of best practices, worden belangrijke nalevingscontroles voor regelgeving vermeld in de sectie Vereisten of Doelstellingen, waar van toepassing. Dit zijn de beveiligingsstandaarden en -voorschriften waarnaar in dit artikel wordt verwezen:

We zijn van plan om door te gaan met het bijwerken van de aanbevelingen en aanbevolen procedures die hier worden vermeld. Geef invoer of eventuele correcties voor dit document op met behulp van de koppeling Feedback onder aan dit artikel.

Verificatie

Verificatie is het proces waarbij wordt bewezen dat de gebruiker is wie hij of zij claimt te zijn. Azure SQL Database en SQL Managed Instance ondersteunen twee typen verificatie:

  • SQL-verificatie
  • Verificatie via Azure Active Directory

Notitie

Azure Active Directory 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 op servers, databases en beheerde exemplaren te dupliceren.
  • Vereenvoudigd en flexibel machtigingsbeheer.
  • Beheer van toepassingen op schaal.

Implementeren:

  • Gebruik Azure Active Directory (Azure AD)-verificatie voor gecentraliseerd identiteitsbeheer.

Best practices:

  • Maak een Azure AD-tenant en maak gebruikers die menselijke gebruikers vertegenwoordigen en maak service-principals voor apps, services en automatiseringshulpprogramma's. Service-principals zijn gelijk aan serviceaccounts in Windows Linux.

  • Toegangsrechten toewijzen aan resources aan Azure AD-principals via groepstoewijzing: Maak Azure AD-groepen, verleen toegang tot groepen en voeg afzonderlijke leden toe aan de groepen. Maak in uw database ingesloten databasegebruikers die uw Azure AD-groepen in kaart brengen. Als u machtigingen in de database wilt toewijzen, moet u de gebruikers die zijn gekoppeld aan uw Azure AD-groepen, in databaserollen plaatsen met de juiste machtigingen.

    Notitie

    In SQL Managed Instance kunt u ook aanmeldingen maken die zijn toe te staan aan Azure AD-principals in de hoofddatabase. Zie CREATE LOGIN (Transact-SQL).

  • Het gebruik van Azure AD-groepen vereenvoudigt het machtigingsbeheer en zowel de groepseigenaar als de resource-eigenaar kan leden toevoegen aan/verwijderen uit de groep.

  • Maak een afzonderlijke groep voor Azure AD-beheerders voor elke server of elk beheerd exemplaar.

    • Zie het artikel Provision an Azure Active Directory administrator for your server (Een Azure Active Directory voor uw server inrichten).

  • Controleer wijzigingen in Azure AD-groepslidmaatschap met behulp van azure AD-controleactiviteitenrapporten.

  • Voor een beheerd exemplaar is een afzonderlijke stap vereist om een Azure AD-beheerder te maken.

Notitie

  • Azure AD-verificatie wordt vastgelegd in Azure SQL auditlogboeken, maar niet in azure AD-aanmeldingslogboeken.
  • Azure RBAC-machtigingen die in Azure worden verleend, zijn niet van toepassing op machtigingen Azure SQL Database of SQL managed instance. Dergelijke machtigingen moeten handmatig worden gemaakt/toewijst met behulp van bestaande SQL machtigingen.
  • Aan de clientzijde moet Azure AD-verificatie toegang hebben tot internet of via door de gebruiker gedefinieerde route (UDR) naar een virtueel netwerk.
  • Het Azure AD-toegang token wordt in de cache opgeslagen aan de clientzijde en de levensduur is afhankelijk van de tokenconfiguratie. Zie het artikel Configurable token lifetimes in Azure Active Directory
  • Zie de volgende blog voor hulp bij het oplossen van problemen met Azure AD-verificatie: Problemen met Azure AD oplossen.

Azure AD Multi-Factor Authentication

Vermeld in: OSA Practice #2, ISO Access Control (AC)

Azure AD Multi-Factor Authentication biedt extra beveiliging door meer dan één vorm van verificatie te vereisen.

Implementeren:

  • Schakel Multi-Factor Authentication in Azure AD in met behulp van voorwaardelijke toegang en gebruik interactieve verificatie.

  • Het alternatief is om Multi-Factor Authentication in te schakelen voor het hele Azure AD- of AD-domein.

Best practices:

Het gebruik van verificatie op basis van wachtwoorden voor gebruikers minimaliseren

Vermeld in: OSA Practice #4, ISO Access Control (AC)

Verificatiemethoden op basis van wachtwoorden vormen een zwakkere vorm van verificatie. Referenties kunnen worden aangetast of per ongeluk worden opgegeven.

Implementeren:

  • Gebruik een geïntegreerde Azure AD-verificatie die het gebruik van wachtwoorden elimineert.

Best practices:

Het gebruik van verificatie op basis van wachtwoorden voor toepassingen minimaliseren

Vermeld in: OSA Practice #4, ISO Access Control (AC)

Implementeren:

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

Best practices:

Wachtwoorden en geheimen beveiligen

Voor gevallen waarin wachtwoorden niet te vermijden zijn, moet u ervoor zorgen dat ze zijn beveiligd.

Implementeren:

  • Gebruik Azure Key Vault om wachtwoorden en geheimen op te slaan. Gebruik, indien van toepassing, Multi-Factor Authentication voor Azure SQL Database met Azure AD-gebruikers.

Best practices:

  • Als het niet mogelijk is om wachtwoorden of geheimen te vermijden, kunt u gebruikerswachtwoorden en toepassingsgeheimen opslaan in Azure Key Vault en de toegang beheren via Key Vault toegangsbeleid.

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

Verificatie SQL oudere toepassingen gebruiken

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 gebruikersnaam en wachtwoord. Er moet een aanmelding worden gemaakt in elke server of elk beheerd exemplaar en er moet een gebruiker in elke database worden gemaakt.

Implementeren:

  • Gebruik SQL verificatie.

Best practices:

Toegangsbeheer

Toegangsbeheer (ook wel autorisatie genoemd) is het proces van het beheren en beheren van de toegang van gemachtigde gebruikers tot Azure SQL Database of SQL managed instance.

Het principe van de minste bevoegdheden implementeren

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

Het principe van de minste bevoegdheden geeft aan dat gebruikers niet meer bevoegdheden mogen hebben dan nodig is om hun taken uit te voeren. Zie het artikel Just enough administration (Just enough administration) voor meer informatie.

Implementeren:

Wijs alleen de benodigde machtigingen toe om de vereiste taken uit te voeren:

Best practices:

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

  • Begin, indien mogelijk, met de minst mogelijke set machtigingen en begin machtigingen een voor een toe te voegen als er een echte noodzaak (en reden) is, in tegenstelling tot de tegenovergestelde benadering: machtigingen stap voor stap weg nemen.

  • Wijs geen machtigingen toe aan afzonderlijke gebruikers. Gebruik in plaats daarvan consistent rollen (database- of serverrollen). Rollen helpen sterk bij het rapporteren en oplossen van problemen met machtigingen. (Azure RBAC ondersteunt alleen machtigingstoewijzing via rollen.)

  • Maak en gebruik aangepaste rollen met de exacte benodigde machtigingen. Typische rollen die in de praktijk worden gebruikt:

    • Beveiligingsimplementatie
    • Beheerder
    • Ontwikkelaar
    • Ondersteuningspersoneel
    • Accountant
    • Geautomatiseerde processen
    • Eindgebruiker

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

  • Vergeet niet dat machtigingen in de database-engine kunnen worden toegepast binnen de volgende scopes (hoe kleiner het bereik, hoe kleiner de impact van de verleende machtigingen):

    Notitie

    Het wordt afgeraden om machtigingen toe te passen op objectniveau, omdat dit niveau onnodige complexiteit toevoegt aan de algehele implementatie. Als u besluit om machtigingen op objectniveau te gebruiken, moeten deze duidelijk worden gedocumenteerd. Hetzelfde geldt voor machtigingen op kolomniveau, die om dezelfde redenen nog minder aan te bevelen zijn. Let er ook op dat een GRANT op tabelniveau standaard geen GRANT op kolomniveau overschrijven. Hiervoor moeten de algemene criteria voor naleving serverconfiguratie worden geactiveerd.

  • Voer regelmatig controles uit met behulp van Evaluatie van beveiligingsleed (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 zijn toegewezen aan verschillende gebruikers. Scheiding van taken helpt gegevensschending te voorkomen.

Implementeren:

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

    • Tussen ontwikkel-/test- en productieomgevingen
    • Gevoelige taken op beveiligingsniveau versus Databasebeheerder taken op beheerniveau (DBA) versus ontwikkelaarstaken.
      • Voorbeelden: Auditor, maken van beveiligingsbeleid voor beveiliging op rolniveau (RLS), implementeren 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 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
    • Serverfuncties maken voor serverbrede taken (nieuwe aanmeldingen, databases maken) in een beheerd exemplaar.
    • Databaserollen maken voor taken op databaseniveau.

  • Voor bepaalde gevoelige taken kunt u overwegen speciale opgeslagen procedures te 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 zijn verleend aan de vorige versie van de procedure onmiddellijk worden verwijderd.

  • Implement 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 kunnen uitvoeren, kunt u Always Encrypted met scheiding van rollen.

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

    • Menselijke tussenkomst in processen.
    • Audittrails: zie Audit critical security events (Kritieke beveiligingsgebeurtenissencontroleren) voor meer informatie over controle.

Best practices:

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

  • Wijs geen machtigingen toe aan afzonderlijke gebruikers. Gebruik in plaats daarvan consistent rollen (database- of serverrollen). Het hebben van rollen helpt enorm bij het rapporteren en oplossen van problemen met machtigingen.

  • Gebruik ingebouwde rollen wanneer de machtigingen exact overeenkomen met de benodigde machtigingen. Als de samenving van alle machtigingen van meerdere ingebouwde rollen tot een overeenkomst van 100% leidt, 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 dynamische scheiding van taken (DSD) genoemd, binnen de taakstappen van de SQL-agent in T-SQL of met behulp van Azure PIM voor Azure-rollen.

  • Zorg ervoor dat DAF's geen toegang hebben tot de versleutelingssleutels of sleutelopslag en dat beveiligingsbeheerders met toegang tot de sleutels op hun beurt geen toegang hebben tot de database. Het gebruik van Extensible Key Management (EKM) kan deze scheiding gemakkelijker te realiseren. Azure Key Vault kunnen worden gebruikt voor het implementeren van EKM.

  • 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 ervan via PowerShell.

  • Omdat elk lid van de db_owner-databaserol beveiligingsinstellingen zoals Transparent Data Encryption (TDE) kan wijzigen of de SLO kan wijzigen, moet dit lidmaatschap met zorg worden verleend. Er zijn echter veel taken waarvoor de db_owner 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 kan weergeven. Als een database zeer gevoelige gegevens bevat, kunnen Always Encrypted worden gebruikt om te voorkomen dat db_owners of een andere DBA deze kan weergeven.

Notitie

Het bereiken van Scheiding van taken (SoD) is een uitdaging voor beveiligingsgerelateerde taken of probleemoplossingstaken. Andere gebieden, zoals ontwikkeling en rollen voor eindgebruikers, zijn eenvoudiger te scheiden. De meeste nalevingsgerelateerde besturingselementen maken het gebruik van alternatieve besturingsfuncties, zoals Controle, mogelijk wanneer andere oplossingen niet praktisch zijn.

Voor lezers die meer willen weten over SoD, raden we de volgende resources 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 beveiligingscontroles mogelijk omzeilen. Voordat u aangepaste code naar productie implementeert, is het essentieel om te controleren wat er wordt geïmplementeerd.

Implementeren:

  • Gebruik een databasehulpprogramma zoals Azure Data Studio ondersteuning biedt voor broncodebeheer.

  • Implementeert een implementatieproces van gescheiden code.

  • Voordat iemand main branch tot main branch, moet een persoon (anders dan de auteur van de code zelf) de code controleren op mogelijke verhoging van bevoegdhedensrisico's en op schadelijke gegevenswijzigingen ter bescherming tegen fraude en rogue toegang. Dit kan worden gedaan met behulp van mechanismen voor broncodebeheer.

Best practices:

  • 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 binnen 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 waar u op moet kijken:

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

  • Zorg ervoor dat de persoon die de beoordeling doet een andere persoon is dan de oorspronkelijke codeauteur en kennis heeft in codebeoordelingen en veilige codering.

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

Gegevensbeveiliging

Gegevensbeveiliging is een set mogelijkheden voor het beveiligen van belangrijke informatie tegen compromitteerd gebruik van versleuteling of versleuteling.

Notitie

Microsoft bevestigt dat Azure SQL Database managed instance SQL als FIPS 140-2 Niveau 1-compatibel. Dit wordt gedaan na het controleren van het strikte gebruik van acceptabele FIPS 140-2 Niveau 1-algoritmen en fips 140-2 niveau 1 gevalideerde exemplaren van deze algoritmen, waaronder consistentie met de vereiste sleutellengten, sleutelbeheer, sleutelgeneratie en sleutelopslag. Deze attestation is bedoeld om onze klanten in staat te stellen te reageren op de noodzaak of vereiste voor het gebruik van met FIPS 140-2 Niveau 1 gevalideerde instanties bij de verwerking van gegevens of de 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 instructie worden gebruikt om aan te tonen dat ze van toepassing zijn op het gebruik van fips 140-2 niveau 1 voor de Amerikaanse overheid en het gebruik van de andere term FIPS 140-2 Niveau 1 gevalideerd.

Actieve gegevens versleutelen

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

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

Data-at-rest versleutelen

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

Versleuteling-at-rest is de cryptografische beveiliging van gegevens wanneer deze worden opgeslagen in database-, logboek- en back-upbestanden.

Implementeren:

  • Transparent Database 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 stellen voor het beheerde exemplaar.

Best practices:

  • Sla geen gegevens op die versleuteling in rust vereisen in de hoofddatabase. De hoofddatabase 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. Azure Key Vault kunt machtigingen op elk moment intrekken om de database ontoegankelijk te maken. U kunt TDE-beveiligingen samen met andere sleutels centraal beheren of de TDE-beveiliging volgens uw eigen schema roteren met behulp van Azure Key Vault.

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

Gevoelige gegevens in gebruik beveiligen tegen onbevoegde gebruikers met hoge bevoegdheden

Gegevens in gebruik zijn de gegevens die zijn opgeslagen in het geheugen van het databasesysteem tijdens het uitvoeren van SQL query's. Als in uw database gevoelige gegevens worden opgeslagen, moet uw organisatie er mogelijk voor zorgen dat gebruikers met hoge bevoegdheden geen gevoelige gegevens in uw database kunnen weergeven. Gebruikers met hoge bevoegdheden, zoals Microsoft-operators of DAF'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.

De beleidsregels die bepalen welke gegevens gevoelig zijn en of de gevoelige gegevens in het geheugen moeten worden versleuteld en niet in gewone tekst toegankelijk moeten zijn voor beheerders, zijn specifiek voor uw organisatie en de nalevingsvoorschriften waaraan u zich moet houden. Raadpleeg de gerelateerde vereiste: Gevoelige gegevens identificeren en taggen.

Implementeren:

  • Gebruik Always Encrypted om ervoor te zorgen dat gevoelige gegevens niet als tekst zonder tekst worden blootgesteld in Azure SQL Database of SQL Managed Instance, zelfs niet in het geheugen of in gebruik. Always Encrypted beschermt de gegevens tegen databasebeheerders (DDE's) en cloudbeheerders (of kwaadbevoorrechte personen die zich kunnen voordoen als gebruikers met een hoge bevoegdheden maar niet-gemachtigde gebruiker) en geeft u meer controle over wie toegang heeft tot uw gegevens.

Best practices:

  • 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 impact op de prestaties en functionaliteit te minimaliseren. Het Always Encrypted in combinatie met TDE en Transport Layer Security (TLS) wordt aanbevolen voor uitgebreide beveiliging van data-at-rest, in-transit en in-use.

  • Evalueer de impact van het versleutelen van de geïdentificeerde gevoelige gegevenskolommen voordat Always Encrypted implementeert in een productiedatabase. Over het algemeen Always Encrypted de functionaliteit van query's op versleutelde kolommen beperkt en heeft het andere beperkingen, zoals vermeld in Always Encrypted - Functiedetails. Daarom moet u uw toepassing mogelijk opnieuw ontwerpen om de functionaliteit opnieuw te implementeren. Een query biedt geen ondersteuning, aan de clientzijde of/en herfactoreert uw databaseschema, met inbegrip van 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 Always Encrypted, werkt een aantal ervan niet met versleutelde kolommen. Het versleutelen van een kolom kan ook invloed hebben op de queryprestaties, afhankelijk van de kenmerken van uw workload.

  • Beheer Always Encrypted sleutels met scheiding van rollen als u gebruik Always Encrypted gegevens te beschermen tegen schadelijke DAF's. Met scheiding van rollen maakt een beveiligingsbeheerder de fysieke sleutels. De DBA maakt de metagegevensobjecten van de kolommastersleutel en kolomversleutelingssleutel 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 tot de fysieke sleutels in niet-gecodeerde tekst nodig.

  • Sla uw kolomsleutels op in Azure Key Vault voor een eenvoudig beheer. Vermijd het Windows certificaatopslag (en in het algemeen gedistribueerde sleutelopslagoplossingen, in tegenstelling tot centrale oplossingen voor sleutelbeheer) die het sleutelbeheer moeilijk maken.

  • Denk zorgvuldig na over het gebruik van meerdere sleutels (hoofdsleutel voor kolommen of versleutelingssleutels voor kolommen). Houd het aantal sleutels klein om de kosten voor sleutelbeheer te verlagen. Eén hoofdsleutel voor kolommen 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, die elk verschillende sleutels gebruiken en toegang hebben tot verschillende gegevens.

  • Kolomsleutels roteren volgens uw nalevingsvereisten. Als u ook kolomversleutelingssleutels wilt roteren, kunt u online versleuteling gebruiken om downtime van toepassingen te minimaliseren.

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

  • Als u zich zorgen maakt over derden die uw gegevens juridisch openen zonder uw toestemming, zorg er dan voor dat alle toepassingen en hulpprogramma's die toegang hebben tot de sleutels en gegevens in niet-gecodete tekst buiten Microsoft Azure Cloud worden uitgevoerd. Zonder toegang tot de sleutels kan de derde partij de gegevens niet ontsleutelen, tenzij de versleuteling wordt omzeild.

  • 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 enkele opschoningsbewerkingen kan uitvoeren op gevoelige en versleutelde gegevens. De enige manier om de toegang tot de gegevens van de DBA in te trekken, is door zowel de kolomversleutelingssleutels als de kolomsleutels die de gegevens beveiligen te roteren. Dit is een dure bewerking.

  • Voor toegang tot de niet-versleutelde tekstwaarden in versleutelde kolommen moet een gebruiker toegang hebben tot de CmK (Column Master Key) die kolommen bebeveiligen, die is geconfigureerd in het sleutelopslag met de CMK. De gebruiker moet ook de databasemachtigingen VIEW ANY COLUMN MASTER KEY DEFINITION en VIEW ANY COLUMN ENCRYPTION KEY DEFINITION hebben.

Toegang van toepassingsgebruikers tot gevoelige gegevens via versleuteling controleren

Versleuteling kan worden gebruikt 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 let op de beperking. De beperkingen worden hieronder vermeld.

Aanbevolen procedures

Bij gebruik van CLE:

  • Beheer de toegang tot sleutels via SQL machtigingen en rollen.

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

  • Symmetrische sleutels beveiligen met asymmetrische sleutels/certificaten (geen wachtwoorden) om het gebruik van 3DES te voorkomen.

  • Wees voorzichtig bij het migreren van een database met Cell-Level-versleuteling via exporteren/importeren (bacpac-bestanden).

    • Zie het artikel Aanbevelingen het gebruik van versleuteling op celniveau in Azure SQL Database informatie over het voorkomen dat sleutels verloren gaan bij het migreren van gegevens en voor andere best practice informatie.

Houd er rekening mee dat Always Encrypted voornamelijk is ontworpen om gevoelige gegevens die worden gebruikt te beschermen tegen gebruikers met hoge bevoegdheden van Azure SQL Database (cloudoperators, DDE's). Zie Gevoelige gegevens beveiligen dieworden gebruikt tegen onbevoegde gebruikers met hoge bevoegdheden. Let op de volgende uitdagingen bij het gebruik van Always Encrypted gegevens te beveiligen tegen toepassingsgebruikers:

  • Standaard onderhouden alle Stuurprogramma's van Microsoft-Always Encrypted een globale cache (één per toepassing) met kolomversleutelingssleutels. Zodra een client-stuurprogramma een versleutelingssleutel voor een kolom zonder tekst heeft verkregen door contact op te nemen met een sleutelopslag met een kolomsleutel, wordt de versleutelingssleutel voor de platte tekst in de cache opgeslagen. Dit maakt het isoleren van gegevens van gebruikers van een toepassing met meerdere gebruikers lastig. Als uw toepassing eindgebruikers imiteert bij interactie met een sleutelopslag (zoals Azure Key Vault), gebruikt een volgende query die dezelfde sleutel vereist, maar wordt geactiveerd door een andere gebruiker, de sleutel in de cache, nadat de query van een gebruiker de cachesleutel heeft gevuld. Het stuurprogramma roept het sleutelopslagaccount 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 realiseren, kunt u de caching van kolomversleutelingssleutels uitschakelen. Het uitschakelen van caching veroorzaakt extra prestatieoverhead, omdat het stuurprogramma contact moet opnemen met het sleutelopslag voor elke gegevensversleutelings- of ontsleutelingsbewerking.

Gegevens beveiligen tegen onbevoegde weergave door toepassingsgebruikers met behoud van de gegevensindeling

Een andere techniek om te voorkomen dat onbevoegde gebruikers gegevens weergeven, is om de gegevens te ontmaskeren of te maskeren met behoud van gegevenstypen en -indelingen 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 te maskeren, wat inhoudt 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.

Best practices:

Notitie

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

  • Niet toestaan dat app-gebruikers ad-hocquery's uitvoeren (omdat ze mogelijk dynamische gegevensmaskering kunnen gebruiken).

    • Zie het artikel Maskering omzeilen met behulp van de deferentie- of beveiligingstechnieken voor meer informatie.

  • Gebruik een correct toegangsbeheerbeleid (via SQL, rollen, RLS) om gebruikersmachtigingen te beperken voor het maken van updates in de gemaskeerde kolommen. Als u een masker maakt voor een kolom, worden updates van die kolom niet voorkomen. Gebruikers die gemaskeerde gegevens ontvangen wanneer ze een query uitvoeren op de gemaskeerde kolom, kunnen de gegevens bijwerken als ze schrijfmachtigingen hebben.

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

Netwerkbeveiliging

Netwerkbeveiliging verwijst naar toegangsbesturingselementen en best practices voor het beveiligen van uw gegevens tijdens de overdracht naar Azure SQL Database.

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

Best practices voor het voorkomen dat clientmachines en toepassingen met bekende beveiligingsproblemen (bijvoorbeeld met oudere TLS-protocollen en coderingssuites) verbinding maken met Azure SQL Database en SQL Managed Instance.

Implementeren:

  • Zorg ervoor dat clientmachines die verbinding maken met Azure SQL Database en SQL Managed Instance de nieuwste Transport Layer Security (TLS) gebruiken.

Best practices:

  • Dwing een minimale TLS-versie af op SQL Database-server of SQL Managed Instance met behulp van de minimale TLS-versie-instelling. We raden u aan de minimale TLS-versie in te stellen op 1.2, na het testen om te bevestigen dat uw toepassingen dit 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

    • Versleutelen = Aan, TrustServerCertificate = Uit (of gelijk aan stuurprogramma's die niet van Microsoft zijn).

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

Aanvalsoppervlak minimaliseren

Minimaliseer het aantal functies dat kan worden aangevallen door een kwaadwillende gebruiker. Netwerktoegangsbesturingselementen implementeren voor Azure SQL Database.

Vermeld in: OSA-oefening #5

Implementeren:

In SQL Database:

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

In SQL Managed Instance:

Best practices:

  • De toegang tot Azure SQL Database en SQL beheerd exemplaar 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 virtuele netwerk of een virtueel peernetwerk in dezelfde regio hebben, hebben rechtstreeks toegang tot het netwerk. Toepassingen en hulpprogramma's in een andere regio kunnen gebruikmaken van virtual-network-to-virtual-network connection of ExpressRoute circuit peering om verbinding te maken. De klant moet netwerkbeveiligingsgroepen (NSG's) gebruiken om de toegang via poort 1433 te beperken tot resources waarvoor toegang tot een beheerd exemplaar is vereist.
    • Gebruik voor SQL Database een Private Link functie die een toegewezen privé-IP-adres biedt voor de server in uw virtuele netwerk. U kunt ook service-eindpunten voor virtuele netwerken 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 een site-naar-site-VPN-verbinding of ExpressRoute gebruiken om verbinding te maken via het gegevenspad.

  • U kunt toegang Azure SQL Database en SQL managed instance door verbinding te maken met een openbaar eindpunt (bijvoorbeeld via een openbaar gegevenspad). De volgende best practices moeten worden overwogen:

    • Gebruik voor een server in SQL Database IP-firewallregels om de toegang te beperken tot alleen geautoriseerde IP-adressen.
    • Gebruik SQL Managed Instance netwerkbeveiligingsgroepen (NSG) om de toegang via poort 3342 te beperken tot de vereiste resources. Zie Een beheerd exemplaar veilig gebruiken met openbare eindpuntenvoor meer informatie.

Notitie

Het SQL managed instance is niet standaard ingeschakeld en moet expliciet worden ingeschakeld. Als het bedrijfsbeleid het gebruik van openbare eindpunten niet voorkomt, gebruikt u Azure Policy om te voorkomen dat openbare eindpunten worden inschakelen.

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

Best practices:

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

Best practices:

  • Voor een eenvoudige web-app is voor het maken van verbinding via een openbaar eindpunt de instelling Azure-services toestaan op AAN vereist.

  • Integreer uw app met een Azure-Virtual Network voor connectiviteit van het privégegevenspad naar een beheerd exemplaar. U kunt eventueel ook een web-app implementeren met App Service Environments (ASE).

  • Voor web-app met ASE of virtueel netwerk Geïntegreerde web-app die verbinding maakt met een database in SQL Database, kunt u service-eindpunten voor virtuele netwerken en firewallregels voor virtuele netwerken gebruiken om de toegang vanaf een specifiek virtueel netwerk en subnet te beperken. Stel vervolgens Azure-services toestaan in op UIT. U kunt ASE ook verbinden met een beheerd exemplaar in SQL Managed Instance via een privégegevenspad.

  • Zorg ervoor dat uw web-app is geconfigureerd volgens het artikel Best practices for securing platform as a service (PaaS) weband mobile applications using Azure App Service .

  • Installeer Web Application Firewall (WAF) om uw web-app te beschermen tegen veelvoorkomende aanvallen en beveiligingsproblemen.

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

Best practices:

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

  • Zorg ervoor dat uw VM is geconfigureerd volgens het artikel Security best practices for IaaS workloads in Azure (Best practices voor beveiliging 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 in over geforceerd tunnelen.

    • Zo ja, bijvoorbeeld front-endsubnet, laat u de standaardroute staan.
    • Als dat niet zo is, bijvoorbeeld de middelste laag of het back-endsubnet, moet u geforceerde tunneling inschakelen, zodat er geen verkeer via internet wordt om on-premises te bereiken (ook wel cross-premises genoemd).

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

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

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

Bescherming tegen DDoS-aanvallen (Distributed Denial of Service)

DDoS-aanvallen (Distributed Denial of Service) zijn pogingen van een kwaadwillende gebruiker om een grote stroom netwerkverkeer naar Azure SQL Database te verzenden met als doel de Azure-infrastructuur te overweldigen en ervoor te zorgen dat geldige aanmeldingen en workloads worden geweigerd.

Vermeld in: OSA-oefening #9

Implementeren:

DDoS-beveiliging wordt automatisch ingeschakeld als onderdeel van het Azure-platform. Het omvat bewaking van altijd aan verkeer en realtime beperking van aanvallen op netwerkniveau op openbare eindpunten.

Best practices:

  • Volg de procedures die worden beschreven in Aanvalsoppervlak minimaliseren helpt DDoS-aanvalsbedreigingen te minimaliseren.

  • De waarschuwing Advanced Threat Protection Brute force SQL referenties helpt bij het detecteren van beveiligingsaanvallen. 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 internet-gerichte eindpunten in Microsoft Defender for Cloud.
    • Gebruik virtuele-machineschaalsets om meerdere exemplaren van uw toepassing uit te voeren op azure-VM's.
    • Schakel RDP en SSH van internet uit om een brute force-aanval te voorkomen.

Bewaking, logboekregistratie en controle

Deze sectie verwijst naar mogelijkheden om u te helpen afwijkende activiteiten te detecteren die duiden op ongebruikelijke en mogelijk schadelijke pogingen om toegang te krijgen tot of misbruik te maken van databases. Ook worden de best practices beschreven voor het configureren van databasecontrole om databasegebeurtenissen bij te houden en vast te leggen.

Databases beveiligen tegen aanvallen

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

Implementeren:

  • Gebruik Advanced Threat Protection voor SQL ongebruikelijke en mogelijk schadelijke pogingen om toegang te krijgen tot of misbruik te maken van databases, waaronder:
    • SQL injectieaanval.
    • Diefstal/lekken van referenties.
    • Misbruik van bevoegdheden.
    • Gegevens exfiltratie.

Best practices:

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

  • Voor een volledig onderzoek is het raadzaam om de controle SQL Database in te stellen. Met controle kunt u databasegebeurtenissen bijhouden en deze schrijven naar een auditlogboek in een Azure Storage-account of Azure Log Analytics-werkruimte.

Kritieke beveiligingsgebeurtenissen controleren

Het bijhouden van databasegebeurtenissen helpt u bij het begrijpen van databaseactiviteit. U kunt inzicht krijgen in discrepanties en afwijkingen die kunnen duiden op problemen met het bedrijf of vermoedelijke schendingen van de beveiliging. Het maakt ook naleving van nalevingsstandaarden mogelijk en gefaciliiliteert.

Implementeren:

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

  • Auditlogboeken kunnen worden geschreven naar een Azure Storage-account, naar een Log Analytics-werkruimte voor gebruik 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 elk van deze opties geschreven.

Best practices:

  • Door het configureren SQL Database Controle op uw server of Controle van beheerde exemplaren om gebeurtenissen te controleren, worden alle bestaande en nieuwe databases op die server gecontroleerd.
  • Standaard bevat het controlebeleid alle acties (query's, opgeslagen procedures en geslaagde en mislukte aanmeldingen) voor de databases, wat kan leiden tot een groot aantal auditlogboeken. Klanten wordt aangeraden controle te configureren voor verschillende soorten acties en actiegroepen met behulp van PowerShell. Als u dit configureert, kunt u het aantal gecontroleerde acties bepalen en het risico op gebeurtenisverlies minimaliseren. Met aangepaste controleconfiguraties kunnen klanten alleen de controlegegevens vastleggen die nodig zijn.
  • Auditlogboeken kunnen rechtstreeks in de Azure Portal ofvanuit de opslaglocatie die is geconfigureerd.

Notitie

Het inschakelen van controle voor Log Analytics kost kosten op basis van opnamesnelheden. Houd rekening met de bijbehorende kosten bij het gebruik van deze optieof overweeg de auditlogboeken op te slaan in een Azure-opslagaccount.

Meer bronnen:

Auditlogboeken beveiligen

Beperk de toegang tot het opslagaccount ter ondersteuning van Scheiding van taken en om DBA te scheiden van auditors.

Implementeren:

  • Wanneer u auditlogboeken op een Azure Storage, moet u ervoor zorgen dat de toegang tot het Storage-account is beperkt tot de minimale beveiligingsprincipes. Bepalen wie toegang heeft tot het opslagaccount.
  • Zie Autoriseren van toegang tot Azure Storage voor meer Azure Storage.

Best practices:

  • Het beheren van de toegang tot het controledoel is een belangrijk concept bij het scheiden van DBA van auditors.

  • Wanneer u de toegang tot gevoelige gegevens controleert, kunt u overwegen de gegevens te beveiligen met gegevensversleuteling om te voorkomen dat informatie naar de auditor wordt gelekt. Zie de sectie Gevoelige gegevens beveiligen die worden gebruikt tegen onbevoegde gebruikers met een hoge bevoegdheden voor meer informatie.

Beveiligingsbeheer

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

Zorg ervoor dat de databases zijn geconfigureerd om te voldoen aan de best practices voor beveiliging

Verbeter de beveiliging van uw database proactief door potentiële beveiligingsproblemen in de database te detecteren en op te verhelpen.

Implementeren:

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

Best practices:

  • Voer in eerste instantie VA uit op uw databases en voer deze uit door mislukte controles te herstellen die de best practices voor beveiliging schenden. Stel basislijnen in voor acceptabele configuraties totdat de scan clean wordt weergegeven, of alle controles zijn geslaagd.

  • Configureer periodiek terugkerende scans om eenmaal per week te worden uitgevoerd en configureer de relevante persoon voor het ontvangen van e-mailberichten met een samenvatting.

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

  • Controles oplossen en basislijnen bijwerken, indien relevant. Maak ticketitems voor het oplossen van acties en volg deze totdat ze zijn opgelost.

Meer bronnen:

Gevoelige gegevens identificeren en taggen

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

Implementeren:

  • Gebruik SQL detectie en classificatie van gegevens om gevoelige gegevens in uw databases te ontdekken, classificeren, labelen en beveiligen.
    • Bekijk de classificatieaanbevelingen die zijn gemaakt door de geautomatiseerde detectie in SQL dashboard Gegevensdetectie en -classificatie. Accepteer de relevante classificaties, zodat uw gevoelige gegevens permanent worden getagd met classificatielabels.
    • Voeg handmatig classificaties toe voor aanvullende gevoelige gegevensvelden die niet zijn ontdekt door het geautomatiseerde mechanisme.
  • Zie Gegevensdetectie en -SQL voor meer informatie.

Best practices:

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

  • Continu de status van aanbevolen gevoelige gegevens controleren in SQL Evaluatie van beveiligingsle gegevens. Houd de detectieregel voor gevoelige gegevens bij en identificeer eventuele afwijking 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 aan (gevoeligheidslabels, informatietypen, detectielogica) in het SQL Information Protection in Microsoft Defender for Cloud.

Toegang tot gevoelige gegevens bijhouden

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

Implementeren:

  • Gebruik een combinatie van SQL Audit en de gegevensclassificatie.

Best practices:

Beveiligings- en nalevingsstatus visualiseren

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

Implementeren:

Veelvoorkomende beveiligingsrisico's en mogelijke oplossingen

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

Beveiligingsrisico: Gegevens exfiltratie

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

Verbinding maken met de server via een openbaar eindpunt brengt een risico met zich mee voor gegevens exfiltratie omdat klanten hun firewalls moeten openen voor openbare IP's.

Scenario 1: Een toepassing op een Virtuele Azure-VM maakt verbinding met een database in Azure SQL Database. Een rogue actor krijgt toegang tot de VM en maakt er een compromis mee. In dit scenario betekent gegevens exfiltratie dat een externe entiteit die de rogue VM gebruikt, verbinding maakt met de database, persoonlijke gegevens kopieert en opgeslagen in een blobopslag of een ander SQL Database in een ander abonnement.

Scenario 2: een DBA. Dit scenario wordt vaak veroorzaakt door beveiligingsgevoelige klanten uit gereguleerde 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:

Momenteel biedt Azure SQL Database en SQL Managed Instance de volgende technieken voor het verminderen van bedreigingen voor gegevens exfiltratie:

  • Gebruik een combinatie van regels voor toestaan en weigeren op de NSG's van azure-VM's om te bepalen welke regio's toegankelijk zijn vanaf de VM.
  • Als u een server in SQL Database, stelt u de volgende opties in:
    • Sta Azure-services toe op UIT.
    • Sta alleen verkeer van het subnet met uw Azure-VM toe door een VNet-firewallregel in te stellen.
    • Gebruik Private Link
  • Voor SQL Managed Instance is het gebruik van privé-IP-toegang standaard het eerste probleem met gegevens exfiltratie van een rogue VM. Schakel de functie voor delegering van subnetten in op een subnet om automatisch het meest beperkende beleid in te stellen op een SQL managed instance-subnet.
  • Het rogue DBA-probleem is meer zichtbaar bij SQL Managed Instance, omdat het een groter surface area en netwerkvereisten zichtbaar zijn voor klanten. De beste oplossing hiervoor is het toepassen van alle procedures in deze beveiligingshandleiding om het Rogue DBA-scenario te voorkomen (niet alleen voor gegevens exfiltratie). Always Encrypted is een methode om gevoelige gegevens te beveiligen door deze te versleutelen en de sleutel niet toegankelijk 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 fail-overmogelijkheden te implementeren om single points of failure te voorkomen. Voor noodscenario's is het gebruikelijk om back-ups van gegevens- en logboekbestanden te bewaren.De volgende sectie biedt 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