Bewerken

Sql Managed Instance met door de klant beheerde sleutels

Azure SQL Managed Instance
Azure Key Vault
Azure Private Link

In dit artikel wordt beschreven hoe u uw eigen TDE-sleutels (Transparent Data Encryption) kunt beheren voor met SQL beheerde exemplaren in een groep voor automatische failover in meerdere regio's met behulp van Azure Key Vault.

Architectuur

Diagram that shows an architecture for managing TDE keys.

Een Visio-bestand van deze architectuur downloaden.

Voor meer redundantie van de TDE-sleutels is Azure SQL Managed Instance geconfigureerd voor het gebruik van de sleutelkluis in een eigen regio als de primaire en de sleutelkluis in de externe regio als secundaire regio.

Het secundaire sleutelkluisexemplaren in een externe regio hebben een privé-eindpunt in dezelfde regio als het beheerde SQL-exemplaar. Wat een met SQL beheerd exemplaar betreft, zijn aanvragen voor zowel primaire als secundaire sleutelkluizen logisch binnen hetzelfde virtuele netwerk en dezelfde regio. Dit ontwerp maakt eenvoudigere firewall- of netwerkbeveiligingsgroepsregels mogelijk. Veel organisaties gebruiken een privé-eindpunt in plaats van toegang te krijgen tot het openbare eindpunt. U wordt aangeraden een privé-eindpunt te gebruiken.

Gegevensstroom

  1. Elke 10 minuten controleert SQL Managed Instance of het toegang heeft tot de TDE-wrapper in de sleutelkluis die is gedefinieerd als primair.

  2. Als de primaire sleutelkluis van SQL Managed Instance niet meer beschikbaar is, controleert dat exemplaar de sleutelkluis die is ingesteld als secundair. Als deze sleutelkluis ook niet beschikbaar is, markeert SQL Managed Instance de databases als 'niet toegankelijk'.

Onderdelen

  • Key Vault is een cloudservice voor het opslaan en openen van geheimen met verbeterde beveiliging. In deze architectuur wordt het gebruikt om sleutels op te slaan die worden gebruikt door TDE. U kunt deze ook gebruiken om sleutels te maken.
  • SQL Managed Instance is een beheerd exemplaar in Azure dat is gebaseerd op de nieuwste stabiele versie van SQL Server. In deze architectuur wordt het sleutelbeheerproces toegepast op gegevens die zijn opgeslagen in SQL Managed Instance.
  • Met Azure Private Link hebt u toegang tot Azure PaaS-services en door Azure gehoste services via een privé-eindpunt in uw virtuele netwerk.

Alternatieven

  • In plaats van door de klant beheerde TDE-sleutels te gebruiken, kunt u door de service beheerde TDE-sleutels gebruiken. Wanneer u door de service beheerde sleutels gebruikt, zorgt Microsoft voor het beveiligen en roteren van de sleutels. Het hele proces wordt van u weggeabstraheerd.

  • Een alternatief voor het gebruik van sleutelkluizen in twee regio's is om er slechts één in één regio te hebben. SQL Managed Instance heeft toegang tot sleutels vanuit een kluis die zich in een andere regio bevindt. U kunt nog steeds een privé-eindpunt gebruiken. Het verkeer naar Key Vault is laag en niet vaak, dus eventuele latentie is niet merkbaar. Sql Managed Instance voert alleen query's uit op de kluis om te zien of de sleutel bestaat. Het materiaal wordt niet gekopieerd.

Scenariodetails

Wanneer u door de klant beheerde sleutels (CMK) gebruikt, ook wel BYOK (Bring Your Own Key genoemd), bent u verantwoordelijk voor de beveiliging, beschikbaarheid en optionele rotatie van de sleutels. Deze verantwoordelijkheden zijn essentieel omdat als de sleutel verloren gaat, de databases en back-ups ook permanent verloren gaan. In dit artikel wordt het sleutelbeheerproces beschreven en vindt u opties, zodat u over de informatie beschikt die u nodig hebt om een weloverwogen beslissing te nemen over het beste proces voor uw bedrijf.

Potentiële gebruikscases

Veel organisaties hebben beleidsregels die vereisen dat certificaten of versleutelingssleutels intern worden gemaakt en beheerd. Als uw organisatie een vergelijkbaar beleid heeft, is deze architectuur mogelijk van toepassing op u. Als uw klanten intern beheer van deze items vereisen, kan de architectuur ook op u van toepassing zijn. Als geen van deze situaties van toepassing is, kunt u overwegen om door het systeem beheerde sleutels te gebruiken.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Algemene aanbevelingen

Zie de volgende artikelen:

Sleutelbeheer

Uw sleutelrotatiemethode verschilt, afhankelijk van wat u gebruikt om uw Asymmetrische TDE-sleutels te maken. Wanneer u uw eigen TDE-wrappersleutel meebrengt, moet u beslissen hoe u deze sleutel gaat maken. U hebt de volgende opties:

  • Gebruik Key Vault om de sleutels te maken. Deze optie zorgt ervoor dat het persoonlijke sleutelmateriaal key vault nooit verlaat en niet kan worden gezien door een mens of systeem. De persoonlijke sleutels kunnen niet worden geëxporteerd, maar er kan een back-up van worden gemaakt en hersteld naar een andere sleutelkluis. Dit punt is belangrijk. Als u hetzelfde sleutelmateriaal in meerdere sleutelkluizen wilt hebben, zoals vereist in dit ontwerp, moet u de functie voor back-up en herstel gebruiken. Deze optie heeft verschillende beperkingen. Beide sleutelkluizen moeten zich in hetzelfde Azure-geografie en -abonnement bevinden. Als dat niet zo is, werkt het herstellen niet. De enige manier om deze beperking te omzeilen, is door de sleutelkluizen in afzonderlijke abonnementen te behouden en één abonnement naar een andere regio te verplaatsen.

  • Genereer de asymmetrische sleutels offline met behulp van een hulpprogramma zoals OpenSSL en importeer vervolgens de sleutels in Key Vault. Wanneer u een sleutel in Key Vault importeert, kunt u deze markeren als exporteerbaar. Als u dat doet, kunt u de sleutels weggooien nadat u ze in Key Vault hebt geïmporteerd of u kunt ze ergens anders opslaan, zoals on-premises of in een andere sleutelkluis. Deze optie biedt u de meeste flexibiliteit. Het kan echter het minst veilig zijn als u er niet goed voor zorgt dat de sleutels niet in de verkeerde handen komen. Het systeem dat de sleutels genereert en de methode die wordt gebruikt om de sleutels in Key Vault te plaatsen, wordt niet beheerd door Azure. U kunt dit proces automatiseren met behulp van Azure DevOps, Azure Automation of een ander indelingsprogramma.

  • Gebruik een ondersteunde on-premises HSM (Hardware Security Module) om uw sleutels te genereren. Met behulp van een ondersteunde HSM kunt u sleutels importeren in Key Vault met verbeterde beveiliging. De eerder beschreven beperking voor dezelfde geografie is niet van toepassing wanneer u een HSM gebruikt. Deze optie biedt een hoog veiligheidsniveau voor uw sleutels omdat het sleutelmateriaal zich op drie afzonderlijke plaatsen bevindt (twee sleutelkluizen in Azure en on-premises). Deze optie biedt ook hetzelfde flexibiliteitsniveau als u een ondersteunde HSM gebruikt.

Beschikbaarheid

Wanneer u Key Vault aan uw architectuur toevoegt, wordt dit een essentieel onderdeel. Ten minste één van de sleutelkluizen in het ontwerp moet toegankelijk zijn. Daarnaast moeten de sleutels die nodig zijn voor TDE toegankelijk zijn. Azure Monitor Insights biedt uitgebreide bewaking van Key Vault. Zie Uw sleutelkluisservice bewaken voor meer informatie.

Operationele uitmuntendheid

Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie Overzicht van de operationele uitmuntendheidpijler voor meer informatie.

Wanneer u overstapt van door de service beheerde sleutels naar door de klant beheerde sleutels, zijn uw bewerkingen:

DevOps

U kunt Azure Pipelines in Azure DevOps gebruiken om het sleutelrotatieproces te automatiseren.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie overzicht van de pijler Prestatie-efficiëntie voor meer informatie.

Automatische failovergroepen van SQL Managed Instance presteren aanzienlijk beter wanneer u gekoppelde regio's gebruikt.

Sql Managed Instance controleert alleen of de sleutel bestaat en doet dat slechts om de 10 minuten. Daarom is voor SQL Managed Instances geen regioaffiniteit met Key Vault vereist. De locatie van uw TDE-sleutels heeft geen invloed op de prestaties.

Schaalbaarheid

Als het gaat om het beheren van uw TDE-sleutels, is schalen geen probleem. De aanvraaggrootte en -frequentie zijn zo klein dat u niet hoeft te schalen.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

De grootste beveiligingsoverweging is ervoor te zorgen dat u uw TDE-wrappersleutel veilig en altijd beschikbaar houdt voor SQL Managed Instances. Elke database die via TDE is versleuteld, is niet toegankelijk als deze geen toegang heeft tot de vereiste sleutel in Key Vault. Als u door de service beheerde sleutels gebruikt, hoeft u zich geen zorgen te maken over deze overweging.

Tolerantie

Elk met SQL beheerd exemplaar is geconfigureerd voor het gebruik van twee sleutelkluizen. Als de primaire TDE-sleutel van het beheerde SQL-exemplaar niet beschikbaar of niet toegankelijk is, probeert het exemplaar een sleutel te vinden met een overeenkomende vingerafdruk in de secundaire sleutelkluis.

Kostenoptimalisatie

Zie deze resources voor meer informatie over de extra kosten voor het beheren van uw eigen TDE-sleutels, buiten extra operationele kosten:

Zie deze resources voor meer informatie over de optionele onderdelen:

Dit scenario implementeren

U kunt dit scenario implementeren met behulp van deze ARM-sjablonen:

Bijdragers

Dit artikel wordt bijgewerkt en onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen