Beheerders van SQL-services moeten bij het instellen van de minimum TLS-versie rekening houden met de mogelijkheden van de clientapplicaties, omdat deze mogelijk niet de nieuwste TLS-versie ondersteunen. Het is essentieel om de clientapplicaties grondig te testen om ervoor te zorgen dat ze in staat zijn verbinding te maken met de SQL-service. Als de Azure SQL-database is geconfigureerd om een TLS-versie te vereisen die de applicatie niet ondersteunt, zal de client een foutmelding ontvangen, bijvoorbeeld: "Error 47072 Login failed with invalid TLS version". Alleen de Azure SQL-database heeft een grafische instelling voor de minimale TLS-waarde. In Azure SQL Managed Instance en SQL Server op een Azure virtuele machine moeten beheerders Azure CLI of PowerShell gebruiken om de waarde van een parameter genaamd MinimalTlsVersion in te stellen.

Beheerders kunnen de volgende commando’s gebruiken om de TLS-instellingen aan te passen:

  • Azure CLI: az sql mi update -n instancename -g groupname --set minimalTlsVer

  • PowerShell: Set-AzSqlInstance -Name instancename -ResourceGroupName groupname "1.2"

Daarnaast is compliance voor gevoelige gegevens in SQL-servers en -databases een belangrijk aspect. Compliance-beheersmaatregelen zijn bedoeld om te zorgen voor een adequate bescherming van de gegevens die zijn opgeslagen in databases. Deze maatregelen kunnen de databases in lijn brengen met bestaande juridische, contractuele en bedrijfsbeleid. Dit hoofdstuk behandelt hoe een strategie voor gegevensclassificatie kan worden toegepast, server- en database-audits geconfigureerd kunnen worden, dynamische gegevensmaskering kan worden geïmplementeerd, en hoe database resources beheerd kunnen worden met Azure Purview.

Gegevensclassificatie is een proces waarbij specifieke datatypes worden gemarkeerd met een aanduiding die de vertrouwelijkheid aangeeft. In een database voor bestellingen bijvoorbeeld, kan de informatie over klanten zoals e-mailadressen en telefoonnummers mogelijk geen speciale bescherming vereisen, terwijl de creditcardnummers van klanten duidelijk meer bescherming nodig hebben. Azure SQL Database, Azure SQL Managed Instance en SQL Server ondersteunen de toepassing van gegevensclassificatielabels op specifieke kolommen in een tabel.

In de Data Discovery & Classification pagina van een Azure SQL-database kunnen beheerders de classificaties van de kolommen bekijken. Ze kunnen ook nieuwe classificaties maken door gebruik te maken van de voorgestelde gevoeligheidslabels die het systeem aanbeveelt, zoals ‘Confidential’ of ‘Highly Confidential’, afhankelijk van de gevoeligheid van de gegevens.

Het is belangrijk te weten dat de aanbevelingen van SQL Information Protection alleen gebaseerd zijn op de kolomlabels die al in de database aanwezig zijn. Als de kolomlabels onduidelijk of onregelmatig zijn, kan het systeem bepaalde gevoelige gegevens niet herkennen, hoewel ze wel degelijk gevoelige informatie bevatten. Beheerders kunnen altijd nieuwe classificaties toevoegen door de naam van het schema, de tabel en de kolom in te voeren en een gevoeligheidslabel toe te wijzen.

Een andere belangrijke functie is de server- en database-audit. Auditing in Azure SQL is de praktijk van het volgen van database-gebeurtenissen en deze documenteren in een logboek voor latere analyse. Auditing kan zowel op server- als database-niveau worden ingeschakeld. Wanneer server-auditing is geconfigureerd, worden alle databases op die server automatisch geaudit, ongeacht de individuele database-instellingen.

Beheerders kunnen kiezen waar ze de auditlogs willen opslaan, bijvoorbeeld in Azure Storage, een Log Analytics Workspace, of in de Event Hub. Dit zorgt ervoor dat alle relevante gegevens veilig kunnen worden geanalyseerd voor compliance-doeleinden. Azure biedt ook vooraf ingestelde auditgroepen die verschillende actieclusters bevatten, zoals succesvolle of mislukte authenticaties.

Auditing kan worden geconfigureerd via de Azure CLI of PowerShell, met behulp van commando's zoals:

  • Azure CLI: az sql server audit-policy update -g group1 -n beebesql4 --state Enabled

  • PowerShell: Set-AzSqlServerAudit -ResourceGroupName group1 -ServerName beebesql4 -State Enabled

Naast auditing biedt Azure SQL Database verschillende functies voor het beheer van gegevensbeveiliging en bescherming van gevoelige gegevens. Het gebruik van Microsoft Defender voor SQL biedt extra beveiliging tegen dreigingen door actief te monitoren op ongebruikelijke activiteit en potentiële aanvallen. Dit is vooral relevant voor compliance binnen sectoren die strenge wet- en regelgeving vereisen, zoals de gezondheidszorg en de financiële sector.

Het is van cruciaal belang dat beheerders niet alleen de standaardinstellingen gebruiken, maar actief hun databases scannen en de noodzakelijke maatregelen treffen om gevoelige gegevens adequaat te beschermen. De juiste implementatie van rolgebaseerde beveiliging en row-level security kan ervoor zorgen dat gegevens enkel toegankelijk zijn voor degenen die specifieke machtigingen hebben, wat bijdraagt aan zowel de beveiliging als de naleving van regelgeving zoals de GDPR.

De integratie van Azure Purview kan ook helpen bij het beheren van de gegevensbronnen door een beter inzicht te geven in de herkomst van gegevens en hoe deze door de verschillende systemen heen stromen. Dit is bijzonder belangrijk voor organisaties die hun gegevensbeheer willen stroomlijnen en beter willen begrijpen waar gevoelige informatie zich bevindt.

Hoe de Always On Availability Groups en Failover Groepen Werken in SQL Server

De Always On Availability Groups (AOAG) in SQL Server vormen een robuuste oplossing voor het beheer van databasebeschikbaarheid en -failover. Deze technologie stelt bedrijven in staat om databases te repliceren en continuïteit van hun systemen te waarborgen, zelfs in het geval van server- of netwerkuitvallen. De configuratie van een AOAG begint met de instelling van een primaire replica die de actieve, lees- en schrijvende databases bevat. Dit wordt ondersteund door secundaire replica's die de databases repliceren, en die zowel lees- als schrijfoperaties kunnen ondersteunen, of in sommige gevallen alleen leesoperaties.

In een AOAG kunnen maximaal acht secundaire replica's aanwezig zijn, die allemaal functioneren als potentiële failoverdoelen. Dit betekent dat, mocht de primaire replica falen, een secundaire replica onmiddellijk de rol van primaire replica kan overnemen, wat leidt tot minimale downtime. De primaire replica behandelt alle klantverbindingen en voert de noodzakelijke synchronisatie van gegevens uit naar de secundaire replica's. Deze synchronisatie garandeert dat de secundaire replica's altijd up-to-date blijven met de meest recente wijzigingen in de primaire database.

Voor de implementatie van een AOAG is een clusteringomgeving vereist. Dit kan een Windows Server Failover Cluster (WSFC) zijn voor omgevingen die draaien op Windows, of Pacemaker voor Linux. Het is essentieel dat elke replica op een andere node binnen het cluster wordt gehost, zodat er een echte redundantie en failoverbeschikbaarheid kan worden gerealiseerd. Het opzetten van een WSFC vereist eerst het toevoegen van de Failover Clustering-feature aan de servers die als replica's gaan functioneren, gevolgd door een configuratie van de cluster via de Failover Cluster Manager.

Het inschakelen van Always On Availability Groups op SQL Server gebeurt via de SQL Server Configuration Manager. Administrators moeten ervoor zorgen dat de optie "Enable Always On Availability Groups" is ingeschakeld in het dialoogvenster Eigenschappen van elke replica-server. Na het inschakelen van deze optie wordt de server herstart om de wijzigingen van kracht te laten worden. Na het herstarten kunnen de beheerders via SQL Server Management Studio (SSMS) het proces starten om een nieuwe Always On Availability Group te maken. De wizard begeleidt de beheerder door de stappen van het aanmaken van de groep, het selecteren van de databases en het verbinden met de secundaire replica's.

Een alternatieve oplossing voor het beheren van database-replicatie tussen logische servers in verschillende geografische regio's is de failovergroep. Dit mechanisme is beschikbaar in Azure SQL Database en Azure SQL Managed Instances. De failovergroep maakt gebruik van een soortgelijke benadering als de actieve geo-replicatie, waarbij het mogelijk is om een standby-replica te configureren voor gebruik bij rampenherstel. Voor het creëren van een failovergroep in Azure moet een beheerder de instellingen via de Azure Portal configureren. Het is hierbij belangrijk dat de naam van de failovergroep uniek is binnen het domein en dat de in de groep toegevoegde databases al bestaan.

Een belangrijk concept binnen een Windows Server Failover Cluster is het quorum. Het quorum voorkomt dat een cluster zichzelf in tweeën splitst, bijvoorbeeld door een netwerkstoring, wat leidt tot een gevaarlijke split-brain situatie. In een split-brain situatie kunnen beide clusteronderdelen hun eigen transacties verwerken, wat leidt tot inconsistente gegevens in de databases. Het quorum is een stemmechanisme waarbij elke node in het cluster een stem uitbrengt en luistert naar de stemmen van andere nodes. Als het aantal stemmen gelijk of minder is dan de meerderheid van de clusterleden, wordt de node uit het cluster verwijderd. Dit voorkomt dat een split-brain situatie zich voordoet.

Wanneer er een gelijke verdeling van stemmen zou kunnen optreden, bijvoorbeeld in een cluster met een even aantal nodes, wordt een 'tiebreaker' toegevoegd in de vorm van een getuige (witness). Deze getuige kan een schijf, een bestandsshare of een opslaglocatie in de cloud zijn. De getuige maakt de uiteindelijke beslissing in het geval van een netwerkstoring, waardoor één van de clusteronderdelen de meerderheid van de stemmen krijgt en het cluster operationeel blijft. Dit voorkomt dat het cluster zichzelf afsluit.

Voor een failovercluster op virtuele machines in Azure vereist de configuratie van een Always On Failover Cluster Instance (FCI) dezelfde aanpak als op fysieke machines, namelijk het gebruik van een Windows Server Failover Cluster. Het FCI wordt gezien als één enkele SQL Server-instantie, zelfs als deze op meerdere nodes wordt uitgevoerd. Dit maakt het mogelijk om SQL Server te laten failoveren van de ene node naar de andere, zonder dat de applicaties of gebruikers hier iets van merken. De FCI zorgt ervoor dat er altijd maar één actieve kopie van de database bestaat, zelfs wanneer de serveromgeving verandert.

Het instellen van een Always On Failover Cluster Instance op een Azure VM is vergelijkbaar met de configuratie op lokale machines, maar met enkele Azure-specifieke aanpassingen. De beheerders moeten ervoor zorgen dat de VMs correct geconfigureerd zijn om als clusterknooppunten te functioneren en dat de vereiste netwerkconfiguraties en opslaginstellingen op de juiste manier zijn ingesteld.

Bij het configureren van de quoruminstellingen in een Windows Server Failover Cluster, bijvoorbeeld via de Failover Cluster Manager, kunnen beheerders verschillende configuraties kiezen afhankelijk van hun behoeften. Zo kan er gekozen worden voor een cloud witness, die gebruik maakt van een Azure blob-opslaglocatie, of een bestandsshare witness, die gebruik maakt van een netwerk share.

Het is cruciaal om een goed begrip te hebben van de onderliggende infrastructuur en hoe deze geconfigureerd moet worden om een effectieve en robuuste failover-oplossing te realiseren. De fouttolerantie en hoge beschikbaarheid die AOAG's en failovergroepen bieden, zijn van essentieel belang voor moderne, bedrijfskritische toepassingen die continuïteit en minimale downtime vereisen.

Hoe Biedt Automatisering Bescherming tegen Gegevensverlies in Azure SQL Oplossingen?

Het inschakelen van automatische back-ups activeert instellingen waarmee de gebruiker een retentieperiode kan kiezen, een opslagcontainer kan selecteren en een back-upschema handmatig kan configureren. Beheerders kunnen SQL-databases herstellen via SQL Server Management Studio (SSMS) door in het menu 'Taken' de optie 'Herstel database' te selecteren. In het venster 'Herstel database' kunnen ze de te herstellen database kiezen, evenals de datum en tijd van de voltooide back-up.

De actieve geo-replicatie creëert een secundaire replica van een SQL-database in een andere geografische regio, wat de continuïteit van de database waarborgt, zelfs in het geval van een grootschalige ramp in de primaire regio. Deze functionaliteit is beschikbaar in Azure SQL Database, maar niet in Azure SQL Managed Instance. Active geo-replication biedt dus een robuuste oplossing voor scenario's waarin de primaire regio niet beschikbaar is, maar de secundaire replica een kopie van de gegevens kan blijven bieden. De replicatie vindt plaats zonder de gebruiker extra handelingen te laten uitvoeren, wat de bedrijfscontinuïteit in kritieke situaties ten goede komt.

Een failovergroep is een mechanisme dat lijkt op actieve geo-replicatie, maar het stelt beheerders in staat de replicatie van SQL-databases tussen logische servers in verschillende geografische regio's te beheren. Dit mechanisme is beschikbaar in zowel Azure SQL Database als Azure SQL Managed Instance, waarbij voor Managed Instance een beperking geldt tot één failovergroep. Het doel van een failovergroep is om de beschikbaarheid van databases te garanderen bij storingen in de primaire regio, waarbij de secundaire regio automatisch de rol van de primaire regio overneemt. Dit gebeurt vaak zonder enige merkbare onderbreking voor eindgebruikers, wat essentieel is voor de bedrijfsvoering.

SQL Server logshipping is een geautomatiseerd proces waarbij transactie-logback-ups worden uitgevoerd op een primaire serverdatabase, de back-ups naar een of meer secundaire servers worden gekopieerd, en vervolgens op de secundaire databases worden hersteld. Dit biedt een eenvoudige oplossing voor disaster recovery van de primaire database, waarbij de secundaire database als herstelpunt fungeert bij uitval van de primaire. Logshipping is bijzonder nuttig in scenario’s waarbij continue back-up en herstel van gegevens noodzakelijk zijn.

De incidenten die zich voordeden tijdens de storing in de geografische regio's kunnen worden aangeduid als een 'split-brain'. Dit houdt in dat beide zijden van het cluster onafhankelijk van elkaar werkten tijdens de netwerkstoring, zonder enige synchronisatie van gegevens. Hierdoor ontstonden twee verschillende databases, met eigen nieuwe bestellingen en andere updates, wat leidde tot inconsistenties tussen de databases die veel tijd en moeite kostten om op te lossen. Het voorkomen van dergelijke problemen vereist dat beheerders een quantum vote implementeren, waarbij een 'witness' fungeert als beslisser in het geval van een split. Dit voorkomt dat beide clusterkanten gelijktijdig opereren en biedt een manier om de gegevensconsistentie te waarborgen.

Het is essentieel dat de infrastructuur voor back-up en replicatie in Azure goed wordt geconfigureerd om de bedrijfscontinuïteit te garanderen. Het gebruik van geo-replicatie en failovergroepen biedt robuuste en efficiënte oplossingen voor disaster recovery, maar de juiste configuratie en monitoring zijn cruciaal om te voorkomen dat er inconsistente gegevens ontstaan, zoals in het scenario van het split-brain. Het gebruik van moderne technieken zoals quantum votes en witnesses kan een grote rol spelen in het voorkomen van dergelijke incidenten, zodat de integriteit van gegevens niet verloren gaat bij onverwachte storingen.

Bovendien moeten beheerders ervoor zorgen dat ze beschikken over gedegen herstelplannen en procedures die regelmatig worden getest. Naast de actieve replicatie moet er ook aandacht zijn voor de daadwerkelijke integriteit van de gegevens tijdens het herstelproces. Dit omvat het zorgvuldig controleren van databases na een failover om te garanderen dat alle gegevens correct zijn gerepliceerd en geen discrepanties optreden tussen de verschillende versies van de database. Geavanceerde monitoringtools kunnen helpen om mogelijke problemen vroegtijdig te identificeren, waardoor ze sneller kunnen worden opgelost voordat ze grote gevolgen hebben voor de bedrijfsvoering.