Hoe werkt Azure RMS? Onder de motorkap

Een belangrijk punt om te begrijpen hoe Azure RMS werkt, is dat deze gegevensbeveiligingsservice van Azure Information Protection uw gegevens niet ziet of opslaat als onderdeel van het beveiligingsproces. Gegevens die u beveiligt, worden nooit verzonden naar of opgeslagen in Azure, tenzij u deze expliciet opslaat in Azure of een andere cloudservice gebruikt die deze opslaat in Azure. Azure RMS maakt de gegevens in een document onleesbaar voor iedereen anders dan geautoriseerde gebruikers en services:

• De gegevens worden versleuteld op toepassingsniveau en bevatten een beleid dat het geautoriseerde gebruik voor dat document definieert.

• Wanneer een beveiligd document wordt gebruikt door een legitieme gebruiker of door een geautoriseerde service wordt verwerkt, worden de gegevens in het document ontsleuteld en worden de rechten afgedwongen die in het beleid zijn gedefinieerd.

Op hoog niveau kunt u zien hoe dit proces werkt in de volgende afbeelding. Een document met de geheime formule wordt beveiligd en vervolgens geopend door een geautoriseerde gebruiker of service. Het document wordt beveiligd met een inhoudssleutel (de groene sleutel in deze afbeelding). Het is uniek voor elk document en wordt in de bestandskoptekst geplaatst waar deze wordt beveiligd door de hoofdsleutel van uw Azure Information Protection-tenant (de rode sleutel in deze afbeelding). Uw tenantsleutel kan worden gegenereerd en beheerd door Microsoft, of u kunt uw eigen tenantsleutel genereren en beheren.

Tijdens het beveiligingsproces wanneer Azure RMS beperkingen versleutelt en ontsleutelt, autoriseert en afdwingt, wordt de geheime formule nooit naar Azure verzonden.

Voor een gedetailleerde beschrijving van wat er gebeurt, raadpleegt u het overzicht van de werking van Azure RMS: Eerste gebruik, inhoudsbeveiliging, sectie inhoudsverbruik in dit artikel.

Zie de volgende sectie voor technische informatie over de algoritmen en sleutellengten die azure RMS gebruikt.

Cryptografische besturingselementen die worden gebruikt door Azure RMS: algoritmen en sleutellengten

Zelfs als u niet in detail hoeft te weten hoe deze technologie werkt, wordt u mogelijk gevraagd over de cryptografische besturingselementen die worden gebruikt. Als u bijvoorbeeld wilt controleren of de beveiligingsbeveiliging industriestandaard is.

Cryptografische besturingselementen	Gebruiken in Azure RMS
Algoritme: AES Sleutellengte: 128 bits en 256 bits [1]	Inhoudsbeveiliging
Algoritme: RSA Sleutellengte: 2048 bits [2]	Sleutelbeveiliging
SHA-256	Certificaatondertekening

Voetnoot 1

In de volgende scenario's worden 256 bits gebruikt door de Azure Information Protection-client:

• Algemene beveiliging (.pfile).

• Systeemeigen beveiliging voor PDF-documenten wanneer het document is beveiligd met de ISO-standaard voor PDF-versleuteling, of het resulterende beveiligde document heeft de bestandsnaamextensie .ppdf.

• Systeemeigen beveiliging voor tekst- of afbeeldingsbestanden (zoals .ptxt of .pjpg).

Voetnoot 2

2048 bits is de sleutellengte wanneer de Azure Rights Management-service wordt geactiveerd. 1024 bits wordt ondersteund voor de volgende optionele scenario's:

• Tijdens een migratie vanaf on-premises als het AD RMS-cluster wordt uitgevoerd in cryptografische modus 1.

• Voor gearchiveerde sleutels die on-premises zijn gemaakt vóór de migratie, zodat inhoud die eerder is beveiligd door AD RMS, na de migratie nog steeds kan worden geopend door de Azure Rights Management-service.

Hoe de cryptografische sleutels van Azure RMS worden opgeslagen en beveiligd

Voor elk document of e-mailbericht dat wordt beveiligd door Azure RMS, maakt Azure RMS één AES-sleutel (de 'inhoudssleutel') en die sleutel wordt ingesloten in het document en blijft behouden via edities van het document.

De inhoudssleutel wordt beveiligd met de RSA-sleutel van de organisatie (de 'Azure Information Protection-tenantsleutel') als onderdeel van het beleid in het document en het beleid wordt ook ondertekend door de auteur van het document. Deze tenantsleutel is gebruikelijk voor alle documenten en e-mailberichten die worden beveiligd door de Azure Rights Management-service voor de organisatie en deze sleutel kan alleen worden gewijzigd door een Azure Information Protection-beheerder als de organisatie een tenantsleutel gebruikt die door de klant wordt beheerd (ook wel 'Bring Your Own Key' of BYOK genoemd).

Deze tenantsleutel wordt beveiligd in de onlineservices van Microsoft, in een zeer gecontroleerde omgeving en onder nauwe bewaking. Wanneer u een door de klant beheerde tenantsleutel (BYOK) gebruikt, wordt deze beveiliging verbeterd door het gebruik van een matrix met high-end HSM's (Hardware Security Modules) in elke Azure-regio, zonder dat de sleutels in elke Azure-regio kunnen worden geëxtraheerd, geëxporteerd of gedeeld. Zie Uw Azure Information Protection-tenantsleutel plannen en implementeren voor meer informatie over de tenantsleutel en BYOK.

Licenties en certificaten die naar een Windows-apparaat worden verzonden, worden beveiligd met de persoonlijke sleutel van de client, die wordt gemaakt wanneer een gebruiker op het apparaat voor het eerst Gebruikmaakt van Azure RMS. Deze persoonlijke sleutel wordt op zijn beurt beveiligd met DPAPI op de client, waardoor deze geheimen worden beschermd met behulp van een sleutel die is afgeleid van het wachtwoord van de gebruiker. Op mobiele apparaten worden de sleutels slechts één keer gebruikt, dus omdat ze niet op de clients worden opgeslagen, hoeven deze sleutels niet op het apparaat te worden beveiligd.

Overzicht van hoe Azure RMS werkt: Eerste gebruik, inhoudsbeveiliging, inhoudsverbruik

Voor meer informatie over hoe Azure RMS werkt, doorlopen we een typische stroom nadat de Azure Rights Management-service is geactiveerd en wanneer een gebruiker de Rights Management-service voor het eerst op zijn Windows-computer gebruikt (een proces dat ook wel bekend staat als het initialiseren van de gebruikersomgeving of bootstrapping), inhoud (een document of e-mail) beveiligt en vervolgens inhoud verbruikt (opent en gebruikt) die door iemand anders is beveiligd.

Nadat de gebruikersomgeving is geïnitialiseerd, kan die gebruiker vervolgens documenten beveiligen of beveiligde documenten op die computer gebruiken.

Notitie

Als deze gebruiker overgaat naar een andere Windows-computer of een andere gebruiker dezelfde Windows-computer gebruikt, wordt het initialisatieproces herhaald.

De gebruikersomgeving initialiseren

Voordat een gebruiker inhoud kan beveiligen of beveiligde inhoud op een Windows-computer kan gebruiken, moet de gebruikersomgeving worden voorbereid op het apparaat. Dit is een eenmalig proces en gebeurt automatisch zonder tussenkomst van de gebruiker wanneer een gebruiker probeert beveiligde inhoud te beveiligen of te gebruiken:

Wat er gebeurt in stap 1: De RMS-client op de computer maakt eerst verbinding met de Azure Rights Management-service en verifieert de gebruiker met behulp van het Microsoft Entra-account.

Wanneer het gebruikersaccount is gefedereerd met Microsoft Entra-id, wordt deze verificatie automatisch uitgevoerd en wordt de gebruiker niet om referenties gevraagd.

Wat er gebeurt in stap 2: Nadat de gebruiker is geverifieerd, wordt de verbinding automatisch omgeleid naar de Azure Information Protection-tenant van de organisatie, waarmee certificaten worden uitgegeven waarmee de gebruiker zich kan verifiëren bij de Azure Rights Management-service om beveiligde inhoud te gebruiken en om inhoud offline te beveiligen.

Een van deze certificaten is het rechtenaccountcertificaat, vaak afgekort tot RAC. Dit certificaat verifieert de gebruiker bij Microsoft Entra-id en is 31 dagen geldig. Het certificaat wordt automatisch vernieuwd door de RMS-client, mits het gebruikersaccount zich nog steeds in De Microsoft Entra-id bevindt en het account is ingeschakeld. Dit certificaat kan niet worden geconfigureerd door een beheerder.

Een kopie van dit certificaat wordt opgeslagen in Azure, zodat als de gebruiker naar een ander apparaat wordt verplaatst, de certificaten worden gemaakt met dezelfde sleutels.

Inhoudsbeveiliging

Wanneer een gebruiker een document beveiligt, voert de RMS-client de volgende acties uit op een niet-beveiligd document:

Wat er gebeurt in stap 1: De RMS-client maakt een willekeurige sleutel (de inhoudssleutel) en versleutelt het document met behulp van deze sleutel met het AES-algoritme voor symmetrische versleuteling.

Wat er gebeurt in stap 2: De RMS-client maakt vervolgens een certificaat met een beleid voor het document met de gebruiksrechten voor gebruikers of groepen en andere beperkingen, zoals een vervaldatum. Deze instellingen kunnen worden gedefinieerd in een sjabloon die een beheerder eerder heeft geconfigureerd of die is opgegeven op het moment dat de inhoud wordt beveiligd (ook wel een ad-hocbeleid genoemd).

Het belangrijkste Microsoft Entra-kenmerk dat wordt gebruikt om de geselecteerde gebruikers en groepen te identificeren, is het kenmerk Microsoft Entra ProxyAddresses, waarin alle e-mailadressen voor een gebruiker of groep worden opgeslagen. Als een gebruikersaccount echter geen waarden heeft in het kenmerk AD ProxyAddresses, wordt de waarde UserPrincipalName van de gebruiker gebruikt.

De RMS-client gebruikt vervolgens de sleutel van de organisatie die is verkregen toen de gebruikersomgeving werd geïnitialiseerd en gebruikt deze sleutel om het beleid en de symmetrische inhoudssleutel te versleutelen. De RMS-client ondertekent ook het beleid met het certificaat van de gebruiker dat is verkregen toen de gebruikersomgeving werd geïnitialiseerd.

Wat er gebeurt in stap 3: Ten slotte sluit de RMS-client het beleid in in een bestand met de hoofdtekst van het document dat eerder is versleuteld, samen een beveiligd document.

Dit document kan overal worden opgeslagen of gedeeld met elke methode en het beleid blijft altijd bij het versleutelde document.

Inhoudsverbruik

Wanneer een gebruiker een beveiligd document wil gebruiken, begint de RMS-client met het aanvragen van toegang tot de Azure Rights Management-service:

Wat er gebeurt in stap 1: de geverifieerde gebruiker verzendt het documentbeleid en de certificaten van de gebruiker naar de Azure Rights Management-service. De service ontsleutelt en evalueert het beleid en bouwt een lijst met rechten (indien aanwezig) die de gebruiker voor het document heeft. Om de gebruiker te identificeren, wordt het kenmerk Microsoft Entra ProxyAddresses gebruikt voor het gebruikersaccount en de groepen waartoe de gebruiker lid is. Om prestatieredenen wordt groepslidmaatschap in de cache opgeslagen. Als het gebruikersaccount geen waarden heeft voor het kenmerk Microsoft Entra ProxyAddresses, wordt de waarde in de Microsoft Entra UserPrincipalName gebruikt.

Wat er gebeurt in stap 2: De service extraheert vervolgens de AES-inhoudssleutel uit het ontsleutelde beleid. Deze sleutel wordt vervolgens versleuteld met de openbare RSA-sleutel van de gebruiker die is verkregen met de aanvraag.

De opnieuw versleutelde inhoudssleutel wordt vervolgens ingesloten in een versleutelde gebruikslicentie met de lijst met gebruikersrechten, die vervolgens wordt geretourneerd naar de RMS-client.

Wat er gebeurt in stap 3: Ten slotte gebruikt de RMS-client de licentie voor versleuteld gebruik en ontsleutelt deze met een eigen persoonlijke sleutel van de gebruiker. Hierdoor kan de RMS-client de hoofdtekst van het document ontsleutelen naar behoefte en weergeven op het scherm.

De client ontsleutelt ook de lijst met rechten en geeft deze door aan de toepassing, waardoor deze rechten worden afgedwongen in de gebruikersinterface van de toepassing.

Notitie

Wanneer gebruikers buiten uw organisatie inhoud verbruiken die u hebt beveiligd, is de verbruiksstroom hetzelfde. Welke wijzigingen in dit scenario worden aangebracht, is hoe de gebruiker wordt geverifieerd. Zie Wanneer ik een beveiligd document deel met iemand buiten mijn bedrijf voor meer informatie , hoe wordt die gebruiker geverifieerd?

Variaties

De voorgaande scenario's hebben betrekking op de standaardscenario's, maar er zijn enkele variaties:

• E-mailbeveiliging: wanneer Exchange Online en Office 365-berichtversleuteling met nieuwe mogelijkheden worden gebruikt om e-mailberichten te beveiligen, kan verificatie voor verbruik ook gebruikmaken van federatie met een sociale id-provider of met behulp van een eenmalige wachtwoordcode. Vervolgens zijn de processtromen vergelijkbaar, behalve dat het inhoudsverbruik plaatsvindt in een webbrowsersessie via een tijdelijk in de cache opgeslagen kopie van de uitgaande e-mail.

• Mobiele apparaten: wanneer mobiele apparaten bestanden beveiligen of gebruiken met de Azure Rights Management-service, zijn de processtromen veel eenvoudiger. Mobiele apparaten doorlopen niet eerst het initialisatieproces van de gebruiker, omdat in plaats daarvan elke transactie (om inhoud te beveiligen of te gebruiken) onafhankelijk is. Net als bij Windows-computers maken mobiele apparaten verbinding met de Azure Rights Management-service en worden ze geverifieerd. Voor het beveiligen van inhoud verzenden mobiele apparaten een beleid en de Azure Rights Management-service verzendt ze een publicatielicentie en symmetrische sleutel om het document te beveiligen. Als mobiele apparaten verbinding maken met de Azure Rights Management-service en verifiëren, verzenden ze het documentbeleid naar de Azure Rights Management-service en vragen ze een gebruikslicentie om het document te gebruiken. Als reactie verzendt de Azure Rights Management-service de benodigde sleutels en beperkingen naar de mobiele apparaten. Beide processen gebruiken TLS om de sleuteluitwisseling en andere communicatie te beveiligen.

• RMS-connector: wanneer de Azure Rights Management-service wordt gebruikt met de RMS-connector, blijven de processtromen hetzelfde. Het enige verschil is dat de connector fungeert als een relay tussen de on-premises services (zoals Exchange Server en SharePoint Server) en de Azure Rights Management-service. De connector zelf voert geen bewerkingen uit, zoals de initialisatie van de gebruikersomgeving, of versleuteling of ontsleuteling. De communicatie die meestal naar een AD RMS-server wordt doorgestuurd, verwerkt de vertaling tussen de protocollen die aan elke zijde worden gebruikt. In dit scenario kunt u de Azure Rights Management-service gebruiken met on-premises services.

• Algemene beveiliging (.pfile):wanneer de Azure Rights Management-service een bestand algemeen beveiligt, is de stroom in principe hetzelfde voor inhoudsbeveiliging, behalve dat de RMS-client een beleid maakt dat alle rechten verleent. Wanneer het bestand wordt gebruikt, wordt het ontsleuteld voordat het wordt doorgegeven aan de doeltoepassing. In dit scenario kunt u alle bestanden beveiligen, zelfs als ze geen ondersteuning bieden voor RMS.

• Microsoft-accounts: Azure Information Protection kan e-mailadressen autoriseren voor verbruik wanneer ze worden geverifieerd met een Microsoft-account. Niet alle toepassingen kunnen beveiligde inhoud openen wanneer een Microsoft-account wordt gebruikt voor verificatie. Meer informatie.

Volgende stappen

Voor meer informatie over de Azure Rights Management-service gebruikt u de andere artikelen in de sectie Begrijpen en verkennen , zoals Hoe toepassingen ondersteuning bieden voor de Azure Rights Management-service om te leren hoe uw bestaande toepassingen kunnen worden geïntegreerd met Azure Rights Management om een oplossing voor informatiebeveiliging te bieden.

Controleer de terminologie voor Azure Information Protection zodat u bekend bent met de termen die u kunt tegenkomen tijdens het configureren en gebruiken van de Azure Rights Management-service. Controleer ook de vereisten voor Azure Information Protection voordat u begint met de implementatie. Als u meteen wilt inzoomen en het zelf wilt uitproberen, gebruikt u de quickstart en zelfstudies:

• Quickstart: De client voor geïntegreerde labels implementeren
• Zelfstudie: De geïntegreerde labelscanner van Azure Information Protection (AIP) installeren
• Zelfstudie: Uw gevoelige inhoud zoeken met de AIP-scanner (Azure Information Protection)
• Zelfstudie: Oversharing voorkomen in Outlook met behulp van Azure Information Protection (AIP)

Als u klaar bent om gegevensbeveiliging voor uw organisatie te implementeren, gebruikt u het AIP-implementatieschema voor classificatie, labeling en beveiliging voor uw implementatiestappen en koppelingen voor instructies.

Tip

Gebruik de resources en koppelingen in Informatie en ondersteuning voor Azure Information Protection voor aanvullende informatie en hulp.