Nieuwe DBA in de cloud: Azure SQL Database beheren na migratie

Van toepassing op: Azure SQL Database

Overstappen van de traditionele zelfbeheerde, zelfbeheerde omgeving naar een PaaS-omgeving kan in het begin een beetje overweldigend lijken. Als app-ontwikkelaar of een DBA wilt u weten wat de belangrijkste mogelijkheden zijn van het platform waarmee u uw toepassing altijd beschikbaar kunt houden, presterend, veilig en tolerant kunt houden. Dit artikel is erop gericht precies dat te doen. In het artikel worden resources beknopt georganiseerd en krijgt u enkele richtlijnen voor het optimaal gebruik van de belangrijkste mogelijkheden van Azure SQL Database met individuele en pooldatabases om uw toepassing efficiënt te beheren en te houden en optimale resultaten te behalen in de cloud. Typische doelgroep voor dit artikel zijn degenen die:

• Evalueer de migratie van hun toepassing(en) naar Azure SQL Database: uw toepassing(en) moderniseren.
• Zijn in het proces voor het migreren van hun toepassing(en) – Een on-going migratiescenario.
• Onlangs de migratie naar Azure SQL Database – Nieuwe DBA in de cloud voltooid.

In dit artikel worden enkele van de kernkenmerken van Azure SQL Database besproken als een platform dat u direct kunt gebruiken bij het werken met individuele databases en pooldatabases in elastische pools. Dit zijn de volgende:

• Databases bewaken via de Azure-portal
• Bedrijfscontinuïteit en herstel na noodgeval (BCDR)
• Beveiliging en naleving
• Intelligente databasebewaking en -onderhoud
• Gegevensverplaatsing

Notitie

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

Databases bewaken via de Azure-portal

In Azure Portal kunt u het gebruik van een afzonderlijke database bewaken door uw database te selecteren en op de bewakingsgrafiek te klikken. Nu wordt een venster Metrische gegevens geopend, dat u kunt wijzigen door op de knop Grafiek bewerken te klikken. Voeg de volgende metrische gegevens toe:

• CPU-percentage
• DTU-percentage
• Gegevens-I/O-percentage
• Databaseomvangpercentage

Zodra u deze metrische gegevens hebt toegevoegd, kunt u deze blijven bekijken in het bewakingsdiagram met meer informatie over het venster Metrische gegevens. De vier metrische gegevens tonen het gemiddelde gebruikspercentage ten opzichte van de DTU van uw database. Zie de artikelen over aankoopmodellen op basis van DTU en vCore-aankoopmodellen voor meer informatie over servicelagen.

U kunt ook meldingen configureren voor prestatiewaarden. Selecteer de knop Waarschuwing toevoegen in het venster Metrische gegevens . Volg de wizard om de melding te configureren. U hebt de keuze om een melding weer te geven als de metrische gegevens een bepaalde drempelwaarde overschrijden of als het meetpunt onder een bepaalde drempelwaarde komt.

Als u bijvoorbeeld verwacht dat de workload van de database zal toenemen, kunt u configureren dat er een e-mailmelding wordt verstuurd wanneer de database 80% van een van de prestatiewaarden heeft bereikt. U kunt dit als een vroege waarschuwing gebruiken om erachter te komen wanneer u mogelijk moet overschakelen naar de eerstvolgende hoogste rekenkracht.

Met de metrische prestatiegegevens kunt u ook bepalen of u een downgrade naar een lagere rekenkracht kunt uitvoeren. Stel dat u een Standard S2-database gebruikt en alle prestatiewaarden aangeven dat de database gemiddeld nooit meer dan 10% gebruikt. Het is dan waarschijnlijk dat de database in Standard S1 goed werkt. Houd echter rekening met workloads die pieken of fluctueren voordat u de beslissing neemt om over te stappen op een lagere rekenkracht.

Bedrijfscontinuïteit en herstel na noodgeval (BCDR)

Met mogelijkheden voor bedrijfscontinuïteit en herstel na noodgevallen kunt u uw bedrijf, zoals gebruikelijk, voortzetten in geval van een noodgeval. De ramp kan een gebeurtenis op databaseniveau zijn (bijvoorbeeld iemand die per ongeluk een cruciale tabel verwijdert) of een datacentrumgebeurtenis (regionale ramp, bijvoorbeeld een firewall).

Hoe kan ik back-ups maken en beheren in SQL Database

U maakt geen back-ups in Azure SQL Database en dat komt omdat u dat niet hoeft te doen. SQL Database maakt automatisch een back-up van databases voor u, zodat u zich geen zorgen meer hoeft te maken over het plannen, maken en beheren van back-ups. Het platform neemt elke week een volledige back-up, elke paar uur differentiële back-up en elke 5 minuten een logboekback-up om ervoor te zorgen dat het herstel na noodgevallen efficiënt is en het gegevensverlies minimaal. De eerste volledige back-up vindt plaats zodra u een database maakt. Deze back-ups zijn voor een bepaalde periode beschikbaar, de 'bewaarperiode' genoemd, en variëren afhankelijk van de servicelaag die u kiest. SQL Database biedt u de mogelijkheid om te herstellen naar een bepaald tijdstip binnen deze bewaarperiode met behulp van herstel naar een bepaald tijdstip met behulp van herstel naar een bepaald tijdstip (PITR).

Servicelaag	Bewaarperiode in dagen
Basis	7
Standaard	35
Premium	35

Bovendien kunt u met de functie Langetermijnretentie (LTR) uw back-upbestanden gedurende een veel langere periode bewaren, met name gedurende maximaal 10 jaar, en gegevens van deze back-ups herstellen op elk moment binnen die periode. Bovendien worden de databaseback-ups bewaard in geografisch gerepliceerde opslag om tolerantie van regionale rampen te garanderen. U kunt deze back-ups ook op elk gewenst moment binnen de bewaarperiode herstellen in elke Azure-regio. Zie het overzicht van bedrijfscontinuïteit voor meer informatie.

Hoe kan ik zorgen voor bedrijfscontinuïteit in geval van een noodgeval of regionale ramp op datacenterniveau

Uw databaseback-ups worden opgeslagen in geografisch gerepliceerde opslag om ervoor te zorgen dat u de back-up tijdens een regionale noodgeval kunt herstellen naar een andere Azure-regio. Dit wordt geo-herstel genoemd. De RPO (Recovery Point Objective) voor geo-herstel is over het algemeen < 1 uur en de ERT (Geschatte hersteltijd) – enkele minuten tot uren.

Voor bedrijfskritieke databases biedt Azure SQL Database actieve geo-replicatie, waarmee een secundaire kopie met geo-replicatie van uw oorspronkelijke database in een andere regio wordt gemaakt. Als uw database bijvoorbeeld in eerste instantie wordt gehost in de Regio VS - west en u regionale noodtolerantie wilt, maakt u een actieve geo-replica van de database in VS - west naar VS - oost. Wanneer de ramp op US - west toeslaat, kunt u een failover uitvoeren naar de regio VS - oost.

Naast actieve geo-replicatie bieden failovergroepen een handige manier om replicatie en failover van een groep databases te beheren. U kunt een failovergroep maken die meerdere databases in dezelfde of verschillende regio's bevat. Vervolgens kunt u een failover van alle databases in de failovergroep naar de secundaire regio initiëren. Zie Failover-groepen voor meer informatie.

Zorg ervoor dat zoneredundantie is ingeschakeld voor de database of elastische pool om tolerantie te bereiken voor storingen in datacenters of beschikbaarheidszones.

Bewaak uw toepassing actief voor een noodgeval en initieer een failover naar de secundaire. U kunt maximaal 4 actieve geo-replica's maken in verschillende Azure-regio's. Het wordt nog beter. U hebt ook toegang tot deze secundaire actieve geo-replica's voor alleen-lezentoegang. Dit is erg handig om de latentie voor een geografisch gedistribueerd toepassingsscenario te verminderen.

Hoe ziet herstel na noodgevallen eruit met SQL Database

Configuratie en beheer van herstel na noodgevallen kunnen met slechts een paar klikken in Azure SQL Database worden uitgevoerd wanneer u actieve geo-replicatie of failovergroepen gebruikt. U moet de toepassing en de bijbehorende database nog steeds controleren op een regionale ramp en een failover naar de secundaire regio uitvoeren om de bedrijfscontinuïteit te herstellen.

Zie Azure SQL Database Disaster Recovery 101 voor meer informatie.

Beveiliging en naleving

SQL Database neemt beveiliging en privacy zeer serieus. Beveiliging binnen SQL Database is beschikbaar op databaseniveau en op platformniveau en wordt het beste begrepen wanneer ze in verschillende lagen zijn gecategoriseerd. Op elke laag krijgt u controle en optimale beveiliging voor uw toepassing. De lagen zijn:

• Identiteits- en verificatie (SQL-verificatie en -verificatie met Microsoft Entra ID (voorheen Azure Active Directory).
• Bewakingsactiviteit (controle en detectie van bedreigingen).
• Werkelijke gegevens beveiligen (Transparent Data Encryption [TDE] en Always Encrypted [AE]).
• Toegang tot gevoelige en bevoegde gegevens beheren (beveiliging op rijniveau en dynamische gegevensmaskering).

Microsoft Defender voor Cloud biedt gecentraliseerd beveiligingsbeheer voor workloads die worden uitgevoerd in Azure, on-premises en in andere clouds. U kunt bekijken of essentiële SQL Database-beveiliging, zoals Controle en Transparent Data Encryption [TDE] zijn geconfigureerd voor alle resources en beleidsregels maken op basis van uw eigen vereisten.

Welke methoden voor gebruikersverificatie worden aangeboden in SQL Database

Er worden twee verificatiemethoden aangeboden in SQL Database:

• Microsoft Entra-verificatie
• SQL-verificatie

Windows-verificatie wordt niet ondersteund. Microsoft Entra ID is een gecentraliseerde service voor identiteits- en toegangsbeheer. Hierdoor kunt u zeer handig eenmalige aanmelding (SSO) bieden tot het personeel in uw organisatie. Dit betekent dat de referenties worden gedeeld tussen Azure-services voor eenvoudigere verificatie.

Microsoft Entra ID ondersteunt meervoudige verificatie en kan eenvoudig worden geïntegreerd met Windows Server Active Directory. Hierdoor kunnen SQL Database en Azure Synapse Analytics ook meervoudige verificatie- en gastgebruikersaccounts bieden binnen een Microsoft Entra-domein. Als u al een on-premises Active Directory hebt, kunt u de directory federeren met Microsoft Entra-id om uw directory uit te breiden naar Azure.

SQL-verificatie ondersteunt alleen gebruikersnaam en wachtwoord om gebruikers te verifiëren bij elke database op een bepaalde server.

Als u...	SQL Database/Azure Synapse Analytics
Gebruik liever geen Microsoft Entra-id in Azure	SQL-verificatie gebruiken
Ad on-premises gebruikt in SQL Server	Federatieve AD met Microsoft Entra-id en gebruik Microsoft Entra-verificatie. Hiermee kunt u eenmalige aanmelding gebruiken.
Meervoudige verificatie afdwingen	Meervoudige verificatie vereisen als beleid via voorwaardelijke toegang van Microsoft en meervoudige verificatie van Microsoft Gebruiken.
Gastaccounts van Microsoft-accounts (live.com, outlook.com) of andere domeinen (gmail.com) hebben	Gebruik universele Microsoft Entra-verificatie in SQL Database of toegewezen SQL-pool, die gebruikmaakt van Microsoft Entra B2B Collaboration.
Zijn aangemeld bij Windows met uw Microsoft Entra-referenties van een federatief domein	Geïntegreerde Microsoft Entra-verificatie gebruiken.
Worden aangemeld bij Windows met behulp van referenties van een domein dat niet is gefedereerd met Azure	Geïntegreerde Microsoft Entra-verificatie gebruiken.
Beschikken over services in de middelste laag die verbinding moeten maken met SQL Database of Azure Synapse Analytics	Geïntegreerde Microsoft Entra-verificatie gebruiken.

Hoe kan ik connectiviteitstoegang tot mijn database beperken of beheren

Er zijn meerdere technieken die u kunt gebruiken om een optimale connectiviteitsorganisatie voor uw toepassing te bereiken.

• Firewallregels
• VNeT-service-eindpunten
• Gereserveerde IP-adressen

Firewall

Een firewall voorkomt toegang tot uw server vanuit een externe entiteit door alleen specifieke entiteiten toegang tot uw server toe te staan. Standaard zijn alle verbindingen met databases binnen de server niet toegestaan, behalve (optioneel7) verbindingen die afkomstig zijn van andere Azure-services. Met een firewallregel kunt u alleen toegang tot uw server openen voor entiteiten (bijvoorbeeld een ontwikkelcomputer) waarvan u goedkeuring geeft door het IP-adres van die computer toe te staan via de firewall. Hiermee kunt u ook een bereik van IP-adressen opgeven dat u toegang tot de server wilt toestaan. Ip-adressen van ontwikkelaarscomputers in uw organisatie kunnen bijvoorbeeld tegelijk worden toegevoegd door een bereik op te geven op de pagina Firewallinstellingen.

U kunt firewallregels maken op serverniveau of op databaseniveau. IP-firewallregels op serverniveau kunnen worden gemaakt met behulp van Azure Portal of met SSMS. Zie voor meer informatie over het instellen van een firewallregel op server- en databaseniveau: IP-firewallregels maken in SQL Database.

Service-eindpunten

Uw database is standaard geconfigureerd voor 'Toestaan dat Azure-services toegang krijgen tot de server'. Dit betekent dat elke virtuele machine in Azure verbinding kan maken met uw database. Deze pogingen moeten nog steeds worden geverifieerd. Als u echter niet wilt dat uw database toegankelijk is voor azure-IP's, kunt u 'Azure-services toegang geven tot de server' uitschakelen. Daarnaast kunt u VNet-service-eindpunten configureren.

Met service-eindpunten (SE) kunt u uw kritieke Azure-resources alleen beschikbaar maken voor uw eigen virtuele privénetwerk in Azure. Door dit te doen, elimineert u in feite openbare toegang tot uw resources. Het verkeer tussen uw virtuele netwerk naar Azure blijft in het Backbone-netwerk van Azure. Zonder SE krijgt u pakketroutering met geforceerde tunneling. Uw virtuele netwerk dwingt het internetverkeer naar uw organisatie en het Azure Service-verkeer via dezelfde route te doorlopen. Met service-eindpunten kunt u dit optimaliseren omdat de pakketten rechtstreeks van uw virtuele netwerk naar de service in het Backbone-netwerk van Azure stromen.

Gereserveerde IP-adressen

Een andere optie is het inrichten van gereserveerde IP-adressen voor uw VM's en het toevoegen van deze specifieke IP-adressen van vm's in de firewallinstellingen van de server. Door gereserveerde IP-adressen toe te wijzen, hoeft u de firewallregels niet bij te werken met het wijzigen van IP-adressen.

Op welke poort maak ik verbinding met SQL Database op

Poort 1433. SQL Database communiceert via deze poort. Als u verbinding wilt maken vanuit een bedrijfsnetwerk, moet u een uitgaande regel toevoegen in de firewallinstellingen van uw organisatie. Vermijd als richtlijn poort 1433 buiten de Azure-grens bloot te stellen.

Hoe kan ik activiteiten op mijn server en database in SQL Database bewaken en reguleren

SQL Database Auditing

Met SQL Database kunt u Controle inschakelen om database-gebeurtenissen bij te houden. Sql Database Auditing registreert databasegebeurtenissen en schrijft deze naar een auditlogboekbestand in uw Azure Storage-account. Controle is vooral handig als u inzicht wilt krijgen in mogelijke schendingen van beveiliging en beleid, naleving van regelgeving onderhouden, enzovoort. Hiermee kunt u bepaalde categorieën gebeurtenissen definiëren en configureren waarvan u denkt dat u controle nodig hebt en op basis hiervan kunt u vooraf geconfigureerde rapporten en een dashboard krijgen om een overzicht te krijgen van gebeurtenissen die in uw database plaatsvinden. U kunt dit controlebeleid toepassen op databaseniveau of op serverniveau. Een handleiding over het inschakelen van controle voor uw server/database, zie: SQL Database Auditing inschakelen.

Detectie van bedreigingen

Met detectie van bedreigingen krijgt u de mogelijkheid om te reageren op beveiligings- of beleidsschendingen die door Controle zijn gedetecteerd. U hoeft geen beveiligingsexpert te zijn om potentiële bedreigingen of schendingen in uw systeem aan te pakken. Detectie van bedreigingen heeft ook een aantal ingebouwde mogelijkheden, zoals DETECTIE van SQL-injectie. SQL-injectie is een poging om de gegevens te wijzigen of in gevaar te brengen en een vrij gangbare manier om een databasetoepassing in het algemeen aan te vallen. Detectie van bedreigingen voert meerdere sets algoritmen uit waarmee potentiële beveiligingsproblemen en SQL-injectieaanvallen worden gedetecteerd, evenals afwijkende databasetoegangspatronen (zoals toegang vanaf een ongebruikelijke locatie of door een onbekende principal). Beveiligingsfunctionarissen of andere aangewezen beheerders ontvangen een e-mailmelding als er een bedreiging wordt gedetecteerd in de database. Elke melding bevat details van de verdachte activiteiten en aanbevelingen voor het verder onderzoeken en beperken van de bedreiging. Zie voor meer informatie over het inschakelen van detectie van bedreigingen: Detectie van bedreigingen inschakelen.

Hoe kan ik mijn gegevens in het algemeen beveiligen in SQL Database

Versleuteling biedt een sterk mechanisme voor het beveiligen en beveiligen van uw gevoelige gegevens tegen indringers. Uw versleutelde gegevens zijn niet van toepassing op de indringer zonder de ontsleutelingssleutel. Er wordt dus een extra beveiligingslaag toegevoegd boven op de bestaande beveiligingslagen die zijn gebouwd in SQL Database. Er zijn twee aspecten voor het beveiligen van uw gegevens in SQL Database:

• Uw gegevens die inactief zijn in de gegevens en logboekbestanden
• Uw gegevens die onderweg zijn

In SQL Database zijn uw data-at-rest in de gegevens- en logboekbestanden in het opslagsubsysteem standaard volledig en altijd versleuteld via Transparent Data Encryption [TDE].. Uw back-ups worden ook versleuteld. Met TDE zijn er geen wijzigingen vereist aan de toepassingszijde die toegang hebben tot deze gegevens. De versleuteling en ontsleuteling gebeuren transparant; vandaar de naam. Sql Database biedt een functie met de naam Always Encrypted (AE) voor het beveiligen van uw gevoelige gegevens tijdens de vlucht en at-rest. AE is een vorm van versleuteling aan de clientzijde die gevoelige kolommen in uw database versleutelt (zodat ze zich in coderingstekst bevinden voor databasebeheerders en onbevoegde gebruikers). De server ontvangt de versleutelde gegevens om mee te beginnen. De sleutel voor Always Encrypted wordt ook opgeslagen aan de clientzijde, zodat alleen geautoriseerde clients de gevoelige kolommen kunnen ontsleutelen. De server- en gegevensbeheerders kunnen de gevoelige gegevens niet zien omdat de versleutelingssleutels op de client zijn opgeslagen. AE versleutelt gevoelige kolommen in de tabel end-to-end, van niet-geautoriseerde clients naar de fysieke schijf. AE ondersteunt tegenwoordig gelijkheidsvergelijkingen, zodat DBA's versleutelde kolommen kunnen blijven doorzoeken als onderdeel van hun SQL-opdrachten. Always Encrypted kan worden gebruikt met verschillende opties voor sleutelarchief, zoals Azure Key Vault, Windows-certificaatarchief en lokale hardwarebeveiligingsmodules.

Kenmerken	Altijd versleuteld	Transparante gegevensversleuteling
Versleutelingsspanne	End-to-end	At-rest-gegevens
Server heeft toegang tot gevoelige gegevens	Nee	Ja, omdat versleuteling voor de data-at-rest is
Toegestane T-SQL-bewerkingen	Gelijkheidsvergelijking	Alle T-SQL-surface area is beschikbaar
App-wijzigingen die vereist zijn voor het gebruik van de functie	Minimaal	Zeer minimaal
Versleutelingsgranulariteit	Kolomniveau	Databaseniveau

Hoe kan ik de toegang tot gevoelige gegevens in mijn database beperken

Elke toepassing heeft een bepaald deel van gevoelige gegevens in de database die moet worden beveiligd tegen zichtbaar zijn voor iedereen. Bepaalde medewerkers binnen de organisatie moeten deze gegevens bekijken, maar anderen mogen deze gegevens niet bekijken. Een voorbeeld hiervan is werknemersloon. Een manager zou echter toegang nodig hebben tot de looninformatie voor hun direct ondergeschikten, maar de individuele teamleden mogen geen toegang hebben tot de looninformatie van hun collega's. Een ander scenario is gegevensontwikkelaars die mogelijk interactie hebben met gevoelige gegevens tijdens ontwikkelingsfasen of tests, bijvoorbeeld SSN's van klanten. Deze informatie hoeft niet opnieuw beschikbaar te worden gesteld aan de ontwikkelaar. In dergelijke gevallen moeten uw gevoelige gegevens worden gemaskeerd of helemaal niet worden weergegeven. SQL Database biedt twee methoden om te voorkomen dat onbevoegde gebruikers gevoelige gegevens kunnen weergeven:

Dynamische gegevensmaskering is een functie voor gegevensmaskering waarmee u de blootstelling van gevoelige gegevens kunt beperken door deze te maskeren voor niet-bevoegde gebruikers op de toepassingslaag. U definieert een maskeringsregel die een maskeringspatroon kan maken (bijvoorbeeld om alleen de laatste vier cijfers van een nationale id-SSN weer te geven: XXX-XX-0000 en het grootste deel ervan als Xs te markeren) en te bepalen welke gebruikers moeten worden uitgesloten van de maskeringsregel. De maskering vindt on-the-fly plaats en er zijn verschillende maskeringsfuncties beschikbaar voor verschillende gegevenscategorieën. Met dynamische gegevensmaskering kunt u automatisch gevoelige gegevens in uw database detecteren en maskering hierop toepassen.

Met beveiliging op rijniveau kunt u de toegang op rijniveau beheren. Dit betekent dat bepaalde rijen in een databasetabel op basis van de gebruiker die de query uitvoert (groepslidmaatschap of uitvoeringscontext) verborgen zijn. De toegangsbeperking wordt uitgevoerd op de databaselaag in plaats van in een toepassingslaag om uw app-logica te vereenvoudigen. U begint met het maken van een filterpredicaat, het filteren van rijen die niet beschikbaar zijn en het beveiligingsbeleid vervolgens definieert wie toegang heeft tot deze rijen. Ten slotte voert de eindgebruiker de query uit en, afhankelijk van de bevoegdheid van de gebruiker, bekijken ze deze beperkte rijen of kunnen ze ze helemaal niet zien.

Hoe kan ik versleutelingssleutels beheren in de cloud

Er zijn opties voor sleutelbeheer voor zowel Always Encrypted (versleuteling aan de clientzijde) als Transparent Data Encryption (versleuteling at rest). Het is raadzaam om versleutelingssleutels regelmatig te roteren. De rotatiefrequentie moet overeenkomen met zowel uw interne organisatievoorschriften als nalevingsvereisten.

TDE (Transparent Data Encryption)

Er is een hiërarchie met twee sleutels in TDE: de gegevens in elke gebruikersdatabase worden versleuteld door een symmetrische AES-256 database-unieke databaseversleutelingssleutel (DEK), die op zijn beurt wordt versleuteld door een server-unieke asymmetrische RSA 2048-hoofdsleutel. De hoofdsleutel kan worden beheerd:

• Automatisch door het platform - SQL Database.
• Of door u Azure Key Vault als sleutelarchief te gebruiken.

De hoofdsleutel voor Transparent Data Encryption wordt standaard voor het gemak beheerd door de SQL Database-service. Als uw organisatie controle wil over de hoofdsleutel, is er een optie voor het gebruik van Azure Key Vault](always-encrypted-azure-key-vault-configure.md) als sleutelarchief. Met behulp van Azure Key Vault gaat uw organisatie ervan uit dat de controle wordt over sleutelinrichting, rotatie en machtigingsbeheer. Het type TDE-hoofdsleutel roteren of schakelen is snel, omdat de DEK alleen opnieuw wordt versleuteld. Voor organisaties met scheiding van rollen tussen beveiliging en gegevensbeheer kan een beveiligingsbeheerder het sleutelmateriaal inrichten voor de TDE-hoofdsleutel in Azure Key Vault en een Azure Key Vault-sleutel-id opgeven aan de databasebeheerder die moet worden gebruikt voor versleuteling in rust op een server. Key Vault is zodanig ontworpen dat Microsoft geen versleutelingssleutels ziet of extraheert. U krijgt ook een gecentraliseerd beheer van sleutels voor uw organisatie.

Altijd versleuteld

Er is ook een hiërarchie met twee sleutels in Always Encrypted: een kolom met gevoelige gegevens wordt versleuteld door een AES 256-kolomversleutelingssleutel (CEK), die op zijn beurt wordt versleuteld door een kolomhoofdsleutel (CMK). De clientstuurprogramma's voor Always Encrypted hebben geen beperkingen voor de lengte van CMK's. De versleutelde waarde van de CEK wordt opgeslagen in de database en de CMK wordt opgeslagen in een vertrouwd sleutelarchief, zoals Windows Certificate Store, Azure Key Vault of een hardwarebeveiligingsmodule.

• Zowel de CEK als de CMK kunnen worden gedraaid.
• CEK-rotatie is een grootte van de gegevensbewerking en kan tijdintensief zijn, afhankelijk van de grootte van de tabellen die de versleutelde kolommen bevatten. Daarom is het verstandig om CEK-rotaties dienovereenkomstig te plannen.
• CMK-rotatie heeft echter geen invloed op databaseprestaties en kan worden uitgevoerd met gescheiden rollen.

In het volgende diagram ziet u de opties voor het sleutelarchief voor de kolomhoofdsleutels in Always Encrypted

Hoe kan ik het verkeer tussen mijn organisatie en SQL Database optimaliseren en beveiligen

Het netwerkverkeer tussen uw organisatie en SQL Database wordt over het algemeen gerouteerd via het openbare netwerk. Als u echter ervoor kiest dit pad te optimaliseren en het veiliger te maken, kunt u azure ExpressRoute bekijken. Met ExpressRoute kunt u uw bedrijfsnetwerk in wezen uitbreiden naar het Azure-platform via een privéverbinding. Door dit te doen, gaat u niet via het openbare internet. U krijgt ook een hogere beveiliging, betrouwbaarheid en routeringsoptimalisatie die vertaalt in lagere netwerklatenties en veel snellere snelheden dan normaal gesproken via het openbare internet. Als u van plan bent een aanzienlijk deel van de gegevens over te brengen tussen uw organisatie en Azure, kan het gebruik van ExpressRoute kostenvoordelen opleveren. U kunt kiezen uit drie verschillende connectiviteitsmodellen voor de verbinding van uw organisatie met Azure:

• Co-locatie voor Cloud Exchange
• Any-to-any
• Point-to-point

Met ExpressRoute kunt u ook maximaal 2x de bandbreedtelimiet die u aanschaft bursten zonder extra kosten. Het is ook mogelijk om connectiviteit tussen regio's te configureren met behulp van ExpressRoute. Zie: ExpressRoute-partners en peeringlocaties voor een lijst met ExpressRoute-connectiviteitsproviders. In de volgende artikelen wordt Express Route gedetailleerder beschreven:

• Inleiding op Express Route
• Vereisten
• Werkstromen

Voldoet SQL Database aan alle wettelijke vereisten en hoe kan dat helpen met de naleving van mijn eigen organisatie

SQL Database voldoet aan een reeks regelgevingscomplianties. Als u de nieuwste set compatibiliteiten wilt bekijken die door SQL Database zijn voldaan, gaat u naar het Vertrouwenscentrum van Microsoft en zoomt u in op de compatibiliteit die belangrijk zijn voor uw organisatie om te zien of SQL Database is opgenomen in de compatibele Azure-services. Het is belangrijk te weten dat HOEWEL SQL Database kan worden gecertificeerd als een compatibele service, het helpt bij de naleving van de service van uw organisatie, maar niet automatisch garandeert.

Intelligente databasebewaking en -onderhoud na migratie

Zodra u uw database naar SQL Database hebt gemigreerd, wilt u uw database bewaken (bijvoorbeeld controleren hoe het resourcegebruik eruitziet of DBCC-controles) en regelmatig onderhoud uitvoeren (bijvoorbeeld indexen, statistieken, enzovoort) herbouwen of opnieuw ordenen. Gelukkig is SQL Database intelligent in de zin dat deze gebruikmaakt van de historische trends en vastgelegde metrische gegevens en statistieken om u proactief te helpen bij het bewaken en onderhouden van uw database, zodat uw toepassing altijd optimaal wordt uitgevoerd. In sommige gevallen kan Azure SQL Database automatisch onderhoudstaken uitvoeren, afhankelijk van uw configuratie-instelling. Er zijn drie facetten voor het bewaken van uw database in SQL Database:

• Prestatiebewaking en optimalisatie.
• Optimalisatie van beveiliging.
• Kostenoptimalisatie.

Prestatiebewaking en optimalisatie

Met Query Performance Insights kunt u op maat gemaakte aanbevelingen krijgen voor uw databaseworkload, zodat uw toepassingen altijd op een optimaal niveau kunnen blijven werken. U kunt deze ook zo instellen dat deze aanbevelingen automatisch worden toegepast en u geen moeite hoeft te doen met het uitvoeren van onderhoudstaken. Met SQL Database Advisor kunt u automatisch indexaanbeveling implementeren op basis van uw workload. Dit wordt automatisch afstemmen genoemd. De aanbevelingen veranderen naarmate uw toepassingsworkload verandert, zodat u de meest relevante suggesties krijgt. U krijgt ook de mogelijkheid om deze aanbevelingen handmatig te bekijken en deze naar eigen goeddunken toe te passen.

Optimalisatie van beveiliging

SQL Database biedt bruikbare beveiligingsaanbeveling om uw gegevens en bedreigingsdetectie te beveiligen voor het identificeren en onderzoeken van verdachte databaseactiviteiten die mogelijk een potentiële thread vormen voor de database. Evaluatie van beveiligingsproblemen is een databasescan- en rapportageservice waarmee u de beveiligingsstatus van uw databases op schaal kunt bewaken en beveiligingsrisico's kunt identificeren en afdrijft van een door u gedefinieerde beveiligingsbasislijn. Na elke scan wordt een aangepaste lijst met bruikbare stappen en herstelscripts verstrekt, evenals een evaluatierapport dat kan worden gebruikt om te voldoen aan de nalevingsvereisten.

Met Microsoft Defender voor Cloud identificeert u de aanbevelingen voor beveiliging aan de hele linie en past u deze snel toe.

Kostenoptimalisatie

Het Azure SQL-platform analyseert de gebruiksgeschiedenis in de databases op een server om opties voor kostenoptimalisatie voor u te evalueren en aan te bevelen. Deze analyse duurt meestal twee weken om bruikbare aanbevelingen te analyseren en op te bouwen. Elastische pool is een dergelijke optie. De aanbeveling wordt in de portal weergegeven als een banner:

U kunt deze analyse ook bekijken onder de sectie Advisor:

Hoe kan ik de prestaties en het resourcegebruik in SQL Database bewaken

In SQL Database kunt u gebruikmaken van de intelligente inzichten van het platform om de prestaties te bewaken en dienovereenkomstig af te stemmen. U kunt de prestaties en het resourcegebruik in SQL Database bewaken met behulp van de volgende methoden:

Azure Portal

In Azure Portal wordt het gebruik van een database weergegeven door de database te selecteren en op de grafiek in het deelvenster Overzicht te klikken. U kunt de grafiek wijzigen om meerdere metrische gegevens weer te geven, waaronder CPU-percentage, DTU-percentage, Data IO-percentage, Sessiepercentage en Databasegroottepercentage.

In deze grafiek kunt u ook waarschuwingen per resource configureren. Met deze waarschuwingen kunt u reageren op resourcevoorwaarden met een e-mailbericht, schrijven naar een HTTPS/HTTP-eindpunt of een actie uitvoeren. Zie Waarschuwingen maken voor meer informatie.

Dynamische beheerweergaven

U kunt een query uitvoeren op de sys.dm_db_resource_stats dynamische beheerweergave om de geschiedenis van statistieken over resourceverbruik van het afgelopen uur en de sys.resource_stats systeemcatalogusweergave te retourneren om de geschiedenis van de afgelopen 14 dagen te retourneren.

Inzicht in queryprestaties

Met Query Performance Insight kunt u een geschiedenis bekijken van de meestgebruikte query's en langlopende query's voor een specifieke database. U kunt topquery's snel identificeren op basis van resourcegebruik, duur en uitvoeringsfrequentie. U kunt query's bijhouden en regressie detecteren. Voor deze functie moet Query Store zijn ingeschakeld en actief zijn voor de database.

Azure SQL Analytics (preview) in Azure Monitor-logboeken

Met Azure Monitor-logboeken kunt u belangrijke metrische gegevens over de prestaties van Azure SQL Database verzamelen en visualiseren, die maximaal 150.000 databases en 5000 elastische SQL-pools per werkruimte ondersteunen. U kunt deze gebruiken om meldingen te bewaken en te ontvangen. U kunt metrische gegevens van SQL Database en elastische pools bewaken in meerdere Azure-abonnementen en elastische pools en kunnen worden gebruikt om problemen op elke laag van een toepassingsstack te identificeren.

Ik ondervind prestatieproblemen: Hoe verschilt mijn SQL Database-probleemoplossingsmethodologie van SQL Server

Een belangrijk deel van de technieken voor probleemoplossing die u zou gebruiken voor het diagnosticeren van query- en databaseprestaties, blijft hetzelfde. Nadat dezelfde database-engine de cloud mogelijk maakt. Het platform - Azure SQL Database heeft echter ingebouwde 'intelligentie'. Het kan u helpen om prestatieproblemen nog gemakkelijker op te lossen en te diagnosticeren. Het kan ook enkele van deze corrigerende acties namens u uitvoeren en in sommige gevallen proactief corrigeren - automatisch.

Uw aanpak voor het oplossen van prestatieproblemen kan aanzienlijk profiteren door intelligente functies zoals Query Performance Insight (QPI) en Database Advisor in combinatie te gebruiken. Het verschil in de methodologie verschilt dus in dat opzicht. U hoeft niet langer het handmatige werk uit te voeren om de essentiële details op te lossen die u kunnen helpen bij het oplossen van het probleem. Het platform doet het harde werk voor u. Een voorbeeld hiervan is QPI. Met QPI kunt u helemaal omlaag inzoomen op het queryniveau en de historische trends bekijken en achterhalen wanneer de query precies is teruggedraaid. De Database Advisor geeft u aanbevelingen voor zaken die u kunnen helpen uw algehele prestaties in het algemeen te verbeteren, zoals ontbrekende indexen, het verwijderen van indexen, het parameteriseren van uw query's, enzovoort.

Bij het oplossen van prestatieproblemen is het belangrijk om te bepalen of het alleen de toepassing is of de database die er back-ups van maakt, wat van invloed is op de prestaties van uw toepassing. Vaak ligt het prestatieprobleem in de toepassingslaag. Dit kan de architectuur of het patroon voor gegevenstoegang zijn. Stel dat u een chatty-toepassing hebt die gevoelig is voor netwerklatentie. In dit geval lijdt uw toepassing omdat er veel korte aanvragen tussen de toepassing en de server en op een overbelast netwerk zijn. Deze retouren zijn dan snel. Als u de prestaties in dit geval wilt verbeteren, kunt u Batch-query's gebruiken. Het gebruik van batches helpt u enorm omdat uw aanvragen nu in een batch worden verwerkt; Zo kunt u de latentie van de roundtrip verminderen en de prestaties van uw toepassing verbeteren.

Als u bovendien merkt dat de algehele prestaties van uw database afnemen, kunt u de sys.dm_db_resource_stats en sys.resource_stats dynamische beheerweergaven bewaken om inzicht te krijgen in CPU, I/O en geheugenverbruik. Uw prestaties zijn mogelijk beïnvloed omdat uw database overstuur is van resources. Het kan zijn dat u de rekenkracht en/of servicelaag moet wijzigen op basis van de groeiende en afnemende workloadvereisten.

Zie voor een uitgebreide set aanbevelingen voor het afstemmen van prestatieproblemen: Uw database afstemmen.

Hoe kan ik ervoor zorgen dat ik de juiste servicelaag en rekenkracht gebruik

SQL Database biedt verschillende servicelagen Basic, Standard en Premium. Elke servicelaag krijgt een gegarandeerd voorspelbare prestaties die zijn gekoppeld aan die servicelaag. Afhankelijk van uw werkbelasting hebt u mogelijk bursts met activiteiten waarbij uw resourcegebruik het plafond van de huidige rekenkracht bereikt waarin u zich bevindt. In dergelijke gevallen is het handig om eerst te beginnen met het evalueren of afstemmen kan helpen (bijvoorbeeld het toevoegen of wijzigen van een index, enzovoort). Als u nog steeds limietproblemen ondervindt, kunt u overwegen om over te stappen op een hogere servicelaag of rekenkracht.

Servicelaag	Veelvoorkomende use-casescenario's
Basic	Toepassingen met een handvol gebruikers en een database die geen hoge gelijktijdigheid, schaal en prestatievereisten heeft.
Standaard	Toepassingen met een aanzienlijke gelijktijdigheid, schaal en prestatievereisten in combinatie met lage tot gemiddelde IO-vereisten.
Premium	Toepassingen met veel gelijktijdige gebruikers, hoge CPU/geheugen en hoge I/O-vereisten. Gevoelige apps met hoge gelijktijdigheid, hoge doorvoer en latentie kunnen gebruikmaken van het Premium-niveau.

Om ervoor te zorgen dat u de juiste rekenkracht hebt, kunt u het verbruik van uw query- en databaseresources bewaken op een van de hierboven genoemde manieren in 'Hoe kan ik de prestaties en het resourcegebruik in SQL Database bewaken'. Als u merkt dat uw query's/databases consistent dynamisch worden uitgevoerd op CPU/geheugen, enzovoort, kunt u overwegen om omhoog te schalen naar een hogere rekenkracht. Als u er ook rekening mee houdt dat u zelfs tijdens piekuren niet zoveel resources gebruikt; overweeg om omlaag te schalen vanaf de huidige rekenkracht.

Als u een SaaS-app-patroon of een scenario voor databaseconsolidatie hebt, kunt u overwegen om een elastische pool te gebruiken voor kostenoptimalisatie. Elastische pool is een uitstekende manier om databaseconsolidatie en kostenoptimalisatie te bereiken. Zie voor meer informatie over het beheren van meerdere databases met een elastische pool: Pools en databases beheren.

Hoe vaak moet ik databaseintegriteitscontroles uitvoeren voor mijn database

SQL Database maakt gebruik van enkele slimme technieken waarmee bepaalde klassen gegevensbeschadiging automatisch en zonder gegevensverlies kunnen worden verwerkt. Deze technieken zijn ingebouwd in de service en worden gebruikt door de service wanneer dat nodig is. Regelmatig worden uw databaseback-ups in de service getest door ze te herstellen en DBCC CHECKDB erop uit te voeren. Als er problemen zijn, lost SQL Database deze proactief op. Automatisch paginaherstel wordt gebruikt voor het herstellen van pagina's die beschadigd zijn of problemen met de gegevensintegriteit hebben. De databasepagina's worden altijd gecontroleerd met de standaard-CHECKSUM-instelling waarmee de integriteit van de pagina wordt gecontroleerd. SQL Database controleert en controleert proactief de gegevensintegriteit van uw database en, als er problemen optreden, worden deze met de hoogste prioriteit opgelost. Daarnaast kunt u ervoor kiezen om desgewenst uw eigen integriteitscontroles uit te voeren. Zie Gegevensintegriteit in SQL Database voor meer informatie

Gegevensverplaatsing na migratie

Hoe kan ik gegevens exporteren en importeren als BACPAC-bestanden uit SQL Database met behulp van Azure Portal

• Exporteren: U kunt uw database in Azure SQL Database exporteren als een BACPAC-bestand vanuit Azure Portal

  

• Importeren: U kunt gegevens ook importeren als een BACPAC-bestand in uw database in Azure SQL Database met behulp van Azure Portal.

  

Hoe kan ik gegevens synchroniseren tussen SQL Database en SQL Server

U hebt verschillende manieren om dit te bereiken:

• Data Sync : met deze functie kunt u gegevens bidirectioneel synchroniseren tussen meerdere SQL Server-databases en SQL Database. Als u wilt synchroniseren met SQL Server-databases, moet u de synchronisatieagent installeren en configureren op een lokale computer of een virtuele machine en de uitgaande TCP-poort 1433 openen.
• Transactiereplicatie : met transactiereplicatie kunt u uw gegevens vanuit een SQL Server-database synchroniseren naar Azure SQL Database met het SQL Server-exemplaar als uitgever en de Azure SQL Database als abonnee. Voorlopig wordt alleen deze installatie ondersteund. Zie voor meer informatie over het migreren van uw gegevens van een SQL Server-database naar Azure SQL met minimale downtime: Transactiereplicatie gebruiken

Volgende stappen

Meer informatie over SQL Database.