Door de klant beheerde sleutels voor meerdere tenants configureren voor een bestaand opslagaccount
Azure Storage versleutelt alle gegevens in een opslagaccount-at-rest. Standaard worden gegevens versleuteld met door Microsoft beheerde sleutels. Voor extra controle over versleutelingssleutels kunt u uw eigen sleutels beheren. Door de klant beheerde sleutels moeten worden opgeslagen in een Azure Key Vault of in een azure Key Vault Managed Hardware Security Model (HSM).
In dit artikel wordt beschreven hoe u versleuteling configureert met door de klant beheerde sleutels voor een bestaand opslagaccount. In het scenario voor meerdere tenants bevindt het opslagaccount zich in een tenant die wordt beheerd door een ISV, terwijl de sleutel die wordt gebruikt voor versleuteling van dat opslagaccount zich in een sleutelkluis bevindt in een tenant die wordt beheerd door de klant.
Notitie
Azure Key Vault en Azure Key Vault Managed HSM ondersteunen dezelfde API's en beheerinterfaces voor de configuratie van door de klant beheerde sleutels. Elke actie die wordt ondersteund voor Azure Key Vault, wordt ook ondersteund voor beheerde HSM van Azure Key Vault.
Over door de klant beheerde sleutels voor meerdere tenants
Veel serviceproviders die SaaS-aanbiedingen (Software as a Service) bouwen in Azure willen hun klanten de mogelijkheid bieden om hun eigen versleutelingssleutels te beheren. Met door de klant beheerde sleutels kan een serviceprovider de gegevens van de klant versleutelen met behulp van een versleutelingssleutel die wordt beheerd door de klant van de serviceprovider en die niet toegankelijk is voor de serviceprovider. In Azure kan de klant van de serviceprovider Azure Key Vault gebruiken om hun versleutelingssleutels te beheren in hun eigen Microsoft Entra-tenant en -abonnement.
Azure-platformservices en -resources die eigendom zijn van de serviceprovider en die zich in de tenant van de serviceprovider bevinden, vereisen toegang tot de sleutel van de tenant van de klant om de versleutelings-/ontsleutelingsbewerkingen uit te voeren.
In de onderstaande afbeelding ziet u een data-at-rest-versleuteling met federatieve identiteit in een CMK-werkstroom voor meerdere tenants voor een serviceprovider en de klant.
In het bovenstaande voorbeeld zijn er twee Microsoft Entra-tenants: de tenant van een onafhankelijke serviceprovider (tenant 1) en de tenant van een klant (tenant 2). Tenant 1 fungeert als host voor Azure-platformservices en Tenant 2 als host voor de sleutelkluis van de klant.
Er wordt een registratie van meerdere tenants gemaakt door de serviceprovider in Tenant 1. Er wordt een federatieve identiteitsreferentie voor deze toepassing gemaakt met behulp van een door de gebruiker toegewezen beheerde identiteit. Vervolgens wordt de naam en toepassings-id van de app gedeeld met de klant.
Een gebruiker met de juiste machtigingen installeert de toepassing van de serviceprovider in de tenant van de klant, Tenant 2. Een gebruiker verleent vervolgens de service-principal die is gekoppeld aan de geïnstalleerde toepassing toegang tot de sleutelkluis van de klant. De klant slaat ook de versleutelingssleutel of door de klant beheerde sleutel op in de sleutelkluis. De klant deelt de sleutellocatie (de URL van de sleutel) met de serviceprovider.
De serviceprovider heeft nu:
- Een toepassings-id voor een toepassing met meerdere tenants die is geïnstalleerd in de tenant van de klant, die toegang heeft gekregen tot de door de klant beheerde sleutel.
- Een beheerde identiteit die is geconfigureerd als de referentie in de multitenant-toepassing.
- De locatie van de sleutel in de sleutelkluis van de klant.
Met deze drie parameters richt de serviceprovider Azure-resources in tenant 1 in die kunnen worden versleuteld met de door de klant beheerde sleutel in Tenant 2.
Laten we de bovenstaande end-to-end-oplossing in drie fasen verdelen:
- De serviceprovider configureert identiteiten.
- De klant verleent de multitenant-app van de serviceprovider toegang tot een versleutelingssleutel in Azure Key Vault.
- De serviceprovider versleutelt gegevens in een Azure-resource met behulp van de CMK.
Bewerkingen in fase 1 zijn een eenmalige installatie voor de meeste serviceprovidertoepassingen. Bewerkingen in fase 2 en 3 worden voor elke klant herhaald.
Fase 1: de serviceprovider configureert een Microsoft Entra-toepassing
| Stap | Beschrijving | Minimale rol in Azure RBAC | Minimale rol in Microsoft Entra RBAC |
|---|---|---|---|
| 1. | Maak een nieuwe multitenant Microsoft Entra-toepassingsregistratie of begin met een bestaande toepassingsregistratie. Noteer de toepassings-id (client-id) van de toepassingsregistratie met behulp van Azure Portal, Microsoft Graph API, Azure PowerShell of Azure CLI | Geen | Toepassingsontwikkelaar |
| 2. | Maak een door de gebruiker toegewezen beheerde identiteit (te gebruiken als federatieve identiteitsreferentie). Azure Portal / Azure CLI / Azure PowerShell/ Azure Resource Manager-sjablonen |
Inzender voor beheerde identiteit | Geen |
| 3. | Configureer door de gebruiker toegewezen beheerde identiteit als federatieve identiteitsreferentie voor de toepassing, zodat deze de identiteit van de toepassing kan imiteren. Graph API-verwijzing naar Azure Portal/ Azure CLI/ Azure PowerShell/ |
Geen | Eigenaar van de toepassing |
| 4. | Deel de naam en toepassings-id van de toepassing met de klant, zodat ze de toepassing kunnen installeren en autoriseren. | Geen | Geen |
Overwegingen voor serviceproviders
- Arm-sjablonen (Azure Resource Manager) worden niet aanbevolen voor het maken van Microsoft Entra-toepassingen.
- Dezelfde multitenant-toepassing kan worden gebruikt voor toegang tot sleutels in een willekeurig aantal tenants, zoals Tenant 2, Tenant 3, Tenant 4, enzovoort. In elke tenant wordt een onafhankelijk exemplaar van de toepassing gemaakt met dezelfde toepassings-id, maar een andere object-id. Elk exemplaar van deze toepassing wordt dus onafhankelijk geautoriseerd. Overweeg hoe het toepassingsobject dat voor deze functie wordt gebruikt om uw toepassing te partitioneren voor alle klanten.
- De toepassing kan maximaal 20 federatieve identiteitsreferenties hebben. Hiervoor moet een serviceprovider federatieve identiteiten delen tussen de klanten. Zie Een app configureren om een externe id-provider te vertrouwen voor meer informatie over ontwerpoverwegingen en -beperkingen voor federatieve identiteiten
- In zeldzame scenario's kan een serviceprovider één toepassingsobject per klant gebruiken, maar waarvoor aanzienlijke onderhoudskosten nodig zijn om toepassingen op schaal te beheren voor alle klanten.
- In de tenant van de serviceprovider is het niet mogelijk om de verificatie van de uitgever te automatiseren.
Fase 2: de klant autoriseert toegang tot de sleutelkluis
| Stap | Beschrijving | Minst bevoegde Azure RBAC-rollen | Microsoft Entra-rollen met minimale bevoegdheden |
|---|---|---|---|
| 1. | Geen | Gebruikers met machtigingen voor het installeren van toepassingen | |
| 2. | Maak een Azure Key Vault en een sleutel die wordt gebruikt als de door de klant beheerde sleutel. | Aan een gebruiker moet de rol Key Vault-inzender zijn toegewezen om de sleutelkluis te maken Aan een gebruiker moet de rol Key Vault Crypto Officer worden toegewezen om een sleutel toe te voegen aan de sleutelkluis |
Geen |
| 3. | Versleutelingsgebruiker van Key Vault cryptoserviceversleutelingsgebruiker toewijzen aan de toepassings-id met toestemming voor de Azure-sleutelkluis | Als u de key vault cryptoserviceversleutelingsgebruikersrol wilt toewijzen aan de toepassing, moet u de rol Gebruikerstoegang Beheer istrator hebben toegewezen. | Geen |
| 4. | Kopieer de URL en sleutelnaam van de sleutelkluis naar de configuratie van door de klant beheerde sleutels van de SaaS-aanbieding. | Geen | Geen |
Notitie
Als u toegang tot de beheerde HSM wilt autoriseren voor versleuteling met behulp van CMK, raadpleegt u hier het voorbeeld voor het opslagaccount. Zie Een beheerde HSM beheren met de Azure CLI voor meer informatie over het beheren van sleutels met beheerde HSM
Overwegingen voor klanten van serviceproviders
- In de tenant van de klant, Tenant 2, kan een beheerder beleidsregels instellen om te voorkomen dat niet-beheerders toepassingen installeren. Deze beleidsregels kunnen voorkomen dat niet-beheerders service-principals maken. Als een dergelijk beleid is geconfigureerd, moeten gebruikers met machtigingen voor het maken van service-principals betrokken zijn.
- Toegang tot Azure Key Vault kan worden geautoriseerd met behulp van Azure RBAC of toegangsbeleid. Wanneer u toegang verleent tot een sleutelkluis, moet u het actieve mechanisme voor uw sleutelkluis gebruiken.
- Een Registratie van een Microsoft Entra-toepassing heeft een toepassings-id (client-id). Wanneer de toepassing in uw tenant is geïnstalleerd, wordt er een service-principal gemaakt. De service-principal deelt dezelfde toepassings-id als de app-registratie, maar genereert een eigen object-id. Wanneer u de toepassing machtigt om toegang te hebben tot resources, moet u mogelijk de service-principal
NameofObjectIDeigenschap gebruiken.
Fase 3: de serviceprovider versleutelt gegevens in een Azure-resource met behulp van de door de klant beheerde sleutel
Nadat fase 1 en 2 zijn voltooid, kan de serviceprovider versleuteling voor de Azure-resource configureren met de sleutel en sleutelkluis in de tenant van de klant en de Azure-resource in de tenant van de ISV. De serviceprovider kan door de klant beheerde sleutels voor meerdere tenants configureren met de clienthulpprogramma's die door die Azure-resource worden ondersteund, met een ARM-sjabloon of met de REST API.
Door de klant beheerde sleutels voor meerdere tenants configureren
In deze sectie wordt beschreven hoe u een door de klant beheerde sleutel (CMK) voor meerdere tenants configureert en klantgegevens versleutelt. U leert hoe u klantgegevens in een resource in Tenant1 versleutelt met behulp van een CMK die is opgeslagen in een sleutelkluis in Tenant2. U kunt Azure Portal, Azure PowerShell of Azure CLI gebruiken.
Meld u aan bij Azure Portal en volg deze stappen.
De serviceprovider configureert identiteiten
De volgende stappen worden uitgevoerd door de serviceprovider in de tenant tenant1 van de serviceprovider.
De serviceprovider maakt een nieuwe app-registratie voor meerdere tenants
U kunt een nieuwe Microsoft Entra-toepassingsregistratie voor meerdere tenants maken of beginnen met een bestaande toepassingsregistratie met meerdere tenants. Als u begint met een bestaande toepassingsregistratie, noteert u de toepassings-id (client-id) van de toepassing.
Ga als volgt te werk om een nieuwe registratie te maken:
Zoek in het zoekvak naar Microsoft Entra-id. Zoek en selecteer de Extensie Microsoft Entra-id .
Selecteer App-registraties beheren > in het linkerdeelvenster.
Selecteer + Nieuwe registratie.
Geef de naam op voor de registratie van de toepassing en selecteer Account in een organisatiemap (Elke Microsoft Entra-directory – Multitenant).a0>
Selecteer Registreren.
Noteer de ApplicationId/ClientId van de toepassing.
De serviceprovider maakt een door de gebruiker toegewezen beheerde identiteit
Maak een door de gebruiker toegewezen beheerde identiteit die moet worden gebruikt als federatieve identiteitsreferentie.
Zoek in het zoekvak naar beheerde identiteiten . Zoek en selecteer de extensie Beheerde identiteiten .
Selecteer + Maken.
Geef de resourcegroep, regio en naam op voor de beheerde identiteit.
Selecteer Controleren + maken.
Let bij een geslaagde implementatie op de Azure ResourceId van de door de gebruiker toegewezen beheerde identiteit, die beschikbaar is onder Eigenschappen. Voorbeeld:
/subscriptions/tttttttt-0000-tttt-0000-tttt0000tttt/resourcegroups/XTCMKDemo/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ConsotoCMKDemoUA
De serviceprovider configureert de door de gebruiker toegewezen beheerde identiteit als federatieve referentie voor de toepassing
Configureer een door de gebruiker toegewezen beheerde identiteit als federatieve identiteitsreferentie voor de toepassing, zodat deze de identiteit van de toepassing kan imiteren.
Navigeer naar Microsoft Entra ID > App-registraties > uw toepassing.
Selecteer Certificaten en geheimen.
Selecteer Federatieve referenties.
Selecteer + Referentie toevoegen.
Selecteer onder Scenario met federatieve referenties de optie Door klant beheerde sleutels.
Klik op Een beheerde identiteit selecteren. Selecteer het abonnement in het deelvenster. Selecteer onder Beheerde identiteit de door de gebruiker toegewezen beheerde identiteit. Zoek in het vak Selecteren naar de beheerde identiteit die u eerder hebt gemaakt en klik vervolgens onderaan het deelvenster op Selecteren .
Geef onder Referentiegegevens een naam en een optionele beschrijving op voor de referentie en selecteer Toevoegen.
De serviceprovider deelt de toepassings-id met de klant
Zoek de toepassings-id (client-id) van de toepassing met meerdere tenants en deel deze met de klant.
De klant verleent de app van de serviceprovider toegang tot de sleutel in de sleutelkluis
De volgende stappen worden uitgevoerd door de klant in de tenant tenant2 van de klant. De klant kan Azure Portal, Azure PowerShell of Azure CLI gebruiken.
De gebruiker die de stappen uitvoert, moet een beheerder zijn met een bevoorrechte rol, zoals Application Beheer istrator, Cloud Application Beheer istrator of Global Beheer istrator.
Meld u aan bij Azure Portal en volg deze stappen.
De klant installeert de toepassing van de serviceprovider in de tenant van de klant
Als u de geregistreerde toepassing van de serviceprovider in de tenant van de klant wilt installeren, maakt u een service-principal met de toepassings-id van de geregistreerde app. U kunt de service-principal op een van de volgende manieren maken:
- Gebruik Microsoft Graph, Microsoft Graph PowerShell, Azure PowerShell of Azure CLI om de service-principal handmatig te maken.
- Maak een URL voor beheerderstoestemming en ververleent tenantbrede toestemming om de service-principal te maken. U moet ze voorzien van uw AppId.
De klant maakt een sleutelkluis
Als u de sleutelkluis wilt maken, moet het account van de gebruiker de rol Key Vault-inzender of een andere rol hebben waarmee een sleutelkluis kan worden gemaakt.
Selecteer + Een resource maken in het menu van Azure Portal of op de startpagina. Voer sleutelkluizen in het zoekvak in. Selecteer sleutelkluizen in de lijst met resultaten. Selecteer Maken op de pagina Sleutelkluizen.
Kies een abonnement op het tabblad Basisbeginselen . Selecteer onder Resourcegroep Nieuwe maken en voer de naam van een resourcegroep in.
Voer een unieke naam in voor de sleutelkluis.
Selecteer een regio en prijscategorie.
Schakel beveiliging tegen opschonen in voor de nieuwe sleutelkluis.
Selecteer op het tabblad Toegangsbeleid het op rollen gebaseerde toegangsbeheer van Azure voor het machtigingsmodel.
Selecteer Controleren en maken en vervolgens Maken.
Noteer de naam van de sleutelkluis en de URI-toepassingen die toegang hebben tot uw sleutelkluis, moeten deze URI gebruiken.
Zie Quickstart: Een Azure Key Vault maken met Azure Portal voor meer informatie.
De klant wijst de rol Crypto Officer van Key Vault toe aan een gebruikersaccount
Deze stap zorgt ervoor dat u versleutelingssleutels kunt maken.
- Navigeer naar uw sleutelkluis en selecteer Toegangsbeheer (IAM) in het linkerdeelvenster.
- Onder Toegang verlenen tot deze bron, selecteert u Roltoewijzing toevoegen.
- Zoek en selecteer Key Vault Crypto Officer.
- Selecteer onder Leden de optie Gebruiker, groep of service-principal.
- Selecteer Leden en zoek uw gebruikersaccount.
- Selecteer Controleren + Toewijzen.
De klant maakt een versleutelingssleutel
Als u de versleutelingssleutel wilt maken, moet aan het account van de gebruiker de rol Crypto Officer van key vault of een andere rol worden toegewezen waarmee een sleutel kan worden gemaakt.
- Selecteer Sleutels op de eigenschappenpagina van Key Vault.
- Selecteer Genereren/Importeren.
- Geef in het scherm Een sleutel maken een naam op voor de sleutel. Houd voor de overige waarden de standaardwaarden aan.
- Selecteer Maken.
- Kopieer de sleutel-URI.
De klant verleent de toepassing van de serviceprovider toegang tot de sleutelkluis
Wijs de Azure RBAC-rol Key Vault Crypto Service Encryption-gebruiker toe aan de geregistreerde toepassing van de serviceprovider, zodat deze toegang heeft tot de sleutelkluis.
- Navigeer naar uw sleutelkluis en selecteer Toegangsbeheer (IAM) in het linkerdeelvenster.
- Onder Toegang verlenen tot deze bron, selecteert u Roltoewijzing toevoegen.
- Zoek en selecteer Key Vault Crypto Service Encryption User.
- Selecteer onder Leden de optie Gebruiker, groep of service-principal.
- Selecteer Leden en zoek de toepassingsnaam van de toepassing die u hebt geïnstalleerd bij de serviceprovider.
- Selecteer Controleren + Toewijzen.
U kunt nu door de klant beheerde sleutels configureren met de sleutelkluis-URI en sleutel.
Door de klant beheerde sleutels configureren voor een bestaand account
Tot nu toe hebt u de toepassing met meerdere tenants geconfigureerd op de tenant van de ISV, de toepassing op de tenant van de klant geïnstalleerd en de sleutelkluis en sleutel geconfigureerd op de tenant van de klant. Vervolgens kunt u door de klant beheerde sleutels configureren voor een bestaand opslagaccount met de sleutel van de tenant van de klant.
De voorbeelden in dit artikel laten zien hoe u door de klant beheerde sleutels configureert voor een bestaand opslagaccount met behulp van een door de gebruiker toegewezen beheerde identiteit om toegang tot de sleutelkluis te autoriseren. U kunt ook een door het systeem toegewezen beheerde identiteit gebruiken om door de klant beheerde sleutels te configureren voor een bestaand opslagaccount. In beide gevallen moet de beheerde identiteit over de juiste machtigingen beschikken om toegang te krijgen tot de sleutelkluis. Zie Verifiëren bij Azure Key Vault voor meer informatie.
Wanneer u versleuteling configureert met door de klant beheerde sleutels voor een bestaand opslagaccount, kunt u ervoor kiezen om automatisch de sleutelversie bij te werken die wordt gebruikt voor Azure Storage-versleuteling wanneer er een nieuwe versie beschikbaar is in de bijbehorende sleutelkluis. Laat hiervoor de sleutelversie weg van de sleutel-URI. U kunt ook expliciet een sleutelversie opgeven die moet worden gebruikt voor versleuteling totdat de sleutelversie handmatig wordt bijgewerkt. Inclusief de sleutelversie op de sleutel-URI configureert door de klant beheerde sleutels voor het handmatig bijwerken van de sleutelversie.
Belangrijk
Als u een sleutel wilt draaien, maakt u een nieuwe versie van de sleutel in Azure Key Vault. Azure Storage verwerkt geen sleutelrotatie, dus u moet de rotatie van de sleutel in de sleutelkluis beheren. U kunt automatische rotatie van sleutels configureren in Azure Key Vault of uw sleutel handmatig draaien.
Azure Storage controleert de sleutelkluis slechts eenmaal per dag op een nieuwe sleutelversie. Wanneer u een sleutel roteert in Azure Key Vault, wacht u 24 uur voordat u de oudere versie uitschakelt.
Voer de volgende stappen uit om door de klant beheerde sleutels voor een bestaand opslagaccount in Azure Portal te configureren:
Navigeer naar uw opslagaccount.
Selecteer Versleuteling in de optie Onder Beveiliging en netwerken. Sleutelbeheer is standaard ingesteld op door Microsoft beheerde sleutels, zoals wordt weergegeven in de volgende afbeelding.
Selecteer de optie Door de klant beheerde sleutels .
Kies de optie Selecteren uit Key Vault .
Selecteer Enter-sleutel-URI en geef de sleutel-URI op. Laat de sleutelversie van de URI weg als u wilt dat Azure Storage automatisch controleert op een nieuwe sleutelversie en deze bijwerkt.
Selecteer het abonnement dat de sleutelkluis en sleutel bevat.
Selecteer in het veld Identiteitstype de optie Door de gebruiker toegewezen en geef vervolgens de beheerde identiteit op met de federatieve identiteitsreferenties die u eerder hebt gemaakt.
Vouw de sectie Geavanceerd uit en selecteer de geregistreerde toepassing met meerdere tenants die u eerder hebt gemaakt in de tenant van de ISV.
Sla uw wijzigingen op.
Nadat u de sleutel hebt opgegeven uit de sleutelkluis in de tenant van de klant, geeft Azure Portal aan dat door de klant beheerde sleutels met die sleutel zijn geconfigureerd. Het geeft ook aan dat automatisch bijwerken van de sleutelversie is ingeschakeld en dat de sleutelversie wordt weergegeven die momenteel wordt gebruikt voor versleuteling. In de portal wordt ook het type beheerde identiteit weergegeven dat wordt gebruikt voor het autoriseren van toegang tot de sleutelkluis, de principal-id voor de beheerde identiteit en de toepassings-id van de toepassing met meerdere tenants.
De sleutel wijzigen
U kunt de sleutel die u gebruikt voor Azure Storage-versleuteling op elk gewenst moment wijzigen.
Notitie
Wanneer u de sleutel of sleutelversie wijzigt, wordt de beveiliging van de hoofdversleutelingssleutel gewijzigd, maar blijven de gegevens in uw Azure Storage-account altijd versleuteld. Er zijn geen aanvullende acties van uw kant vereist om ervoor te zorgen dat uw gegevens worden beschermd. Het wijzigen van de sleutel of het roteren van de sleutelversie heeft geen invloed op de prestaties. Er is geen downtime verbonden aan het wijzigen van de sleutel of het roteren van de sleutelversie.
Voer de volgende stappen uit om de sleutel te wijzigen met Azure Portal:
- Navigeer naar uw opslagaccount en geef de versleutelingsinstellingen weer.
- Selecteer de sleutelkluis en kies een nieuwe sleutel.
- Sla uw wijzigingen op.
Toegang intrekken tot een opslagaccount dat gebruikmaakt van door de klant beheerde sleutels
Als u de toegang tot een opslagaccount dat gebruikmaakt van door de klant beheerde sleutels tijdelijk wilt intrekken, schakelt u de sleutel uit die momenteel wordt gebruikt in de sleutelkluis. Er is geen invloed op de prestaties of downtime die is gekoppeld aan het uitschakelen en opnieuw inschakelen van de sleutel.
Nadat de sleutel is uitgeschakeld, kunnen clients geen bewerkingen aanroepen die lezen van of schrijven naar een blob of de metagegevens ervan. Zie Toegang intrekken tot een opslagaccount dat gebruikmaakt van door de klant beheerde sleutels voor informatie over welke bewerkingen mislukken.
Let op
Wanneer u de sleutel in de sleutelkluis uitschakelt, blijven de gegevens in uw Azure Storage-account versleuteld, maar worden deze niet meer toegankelijk totdat u de sleutel opnieuw kunt activeren.
Voer de volgende stappen uit om een door de klant beheerde sleutel uit te schakelen met Azure Portal:
Navigeer naar de sleutelkluis die de sleutel bevat.
Selecteer Onder Objecten de optie Sleutels.
Klik met de rechtermuisknop op de toets en selecteer Uitschakelen.
Overschakelen naar door Microsoft beheerde sleutels
U kunt op elk gewenst moment overschakelen van door de klant beheerde sleutels naar door Microsoft beheerde sleutels met behulp van Azure Portal, PowerShell of De Azure CLI.
Als u wilt overschakelen van door de klant beheerde sleutels naar door Microsoft beheerde sleutels in Azure Portal, voert u de volgende stappen uit:
Navigeer naar uw opslagaccount.
Selecteer Versleuteling onder Beveiliging en netwerken.
Wijzig het versleutelingstype in door Microsoft beheerde sleutels.
