Hoe werkt Azure RMS? Onderhuids

Belangrijk om te weten 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 alleen de gegevens in een document onleesbaar, behalve voor gemachtigde gebruikers en services:

• De gegevens worden versleuteld op toepassingsniveau en het proces omvat een beleid dat geautoriseerd gebruik van dat document bepaalt.

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

De volgende afbeelding bevat een overzicht, waarmee u kunt zien hoe dit proces werkt. Een document dat de geheime formule bevat, wordt beveiligd en vervolgens geopend door een geautoriseerde gebruiker of -service. Het document wordt beveiligd door een inhoudssleutel (de groene sleutel in deze afbeelding). Deze sleutel is voor elk document uniek en wordt geplaatst in de bestandsheader, waar deze wordt beveiligd door de basissleutel van uw Azure Information Protection-tenant (de rode sleutel in deze afbeelding). Uw tenantsleutel kan worden gegenereerd en beheerd door Microsoft, maar u kunt ook uw eigen tenantsleutel genereren en beheren.

Gedurende het hele beveiligingsproces, waarbij Azure RMS versleutelt, ontsleutelt, goedkeurt en beperkingen afdwingt, wordt de geheime formule nooit wordt verzonden naar Azure.

Zie de sectie Walkthrough over de werking van Azure RMS: eerste gebruik, inhoudsbeveiliging, inhoudverbruik in dit artikel voor een gedetailleerde omschrijving van de bewerkingen.

Zie de volgende sectie voor technische gegevens 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 naar de cryptografische besturingselementen die worden gebruikt. Bijvoorbeeld om te bevestigen dat de beveiliging industriestandaard is.

Cryptografische besturingselementen	Gebruik 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

256 bits wordt gebruikt door de Azure Information Protection-client in de volgende scenario's:

• Algemene beveiliging (.pfile).

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

• 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 van 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 door AD RMS is beveiligd, na de migratie door de Azure Rights Management-service kan worden geopend.

Hoe de cryptografische Azure RMS-sleutels worden opgeslagen en beveiligd

Voor elk document of e-mailbericht dat wordt beveiligd door Azure RMS, maakt Azure RMS een enkele AES-sleutel (de 'inhoudssleutel'). Deze sleutel wordt in het document ingesloten en blijft behouden in alle versies van het document.

De inhoudssleutel wordt beschermd met de RSA-sleutel van de organisatie (de 'Azure Information Protection-tenantsleutel') als onderdeel van het beleid in het document. Het beleid wordt ook ondertekend door de auteur van het document. Deze tenantsleutel is hetzelfde voor alle documenten en e-mails die voor de organisatie worden beveiligd door Azure Rights Management 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 uiterst gecontroleerde omgeving en met maximale bewaking. Wanneer u een door de klant beheerde tenantsleutel (BYOK) gebruikt, wordt deze beveiliging verbeterd door het gebruik van een matrix van high-end hardwarebeveiligingsmodules (HSM's) in elke Azure-regio, zonder dat de sleutels onder alle omstandigheden 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 worden verzonden naar een Windows-apparaat, worden beveiligd met de persoonlijke apparaatsleutel van de client, die wordt gemaakt wanneer een gebruiker op het apparaat voor de eerste keer Azure RMS gebruikt. Deze persoonlijke sleutel wordt op zijn beurt beveiligd met DPAPI op de client, die deze geheime gegevens beveiligt met een sleutel die is afgeleid van het wachtwoord van de gebruiker. Op mobiele apparaten wordt de sleutel slechts eenmaal gebruikt. Omdat de sleutels niet worden opgeslagen op de clients, hoeven deze sleutels dus niet te worden beveiligd op het apparaat.

Walkthrough over de werking van Azure RMS: eerste gebruik, inhoudsbeveiliging, inhoudverbruik

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

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

Notitie

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

Initialisatie van de gebruikersomgeving

Voordat een gebruiker inhoud kan beveiligen of beveiligde inhoud op een Windows-computer kan verbruiken, moet de gebruikersomgeving worden voorbereid op het apparaat. Dit is een eenmalige proces en dat automatisch plaatsvindt zonder tussenkomst van de gebruiker wanneer een gebruiker inhoud beveiligt of beveiligde inhoud verbruikt:

Wat gebeurt er in stap 1: de RMS-client op de computer maakt eerst verbinding met de Azure Rights Management-service en verifieert de gebruiker met het Azure Active Directory-account.

Wanneer het gebruikersaccount met Azure Active Directory is gefedereerd, is deze verificatie automatisch en wordt de gebruiker niet gevraagd om referenties.

Wat gebeurt er in stap 2: Nadat de gebruiker is geverifieerd, wordt de verbinding automatisch omgeleid naar de Azure Information Protection-tenant van de organisatie. De tenant geeft certificaten uit waarmee de gebruiker wordt geverifieerd bij de Azure Rights Management-service zodat de gebruiker beveiligde inhoud kan verbruiken en offline inhoud kan beveiligen.

Een van deze certificaten is het rechtenaccountcertificaat, vaak afgekort tot RAC. Dit certificaat verifieert de gebruiker bij Azure Active Directory en is 31 dagen geldig. Het certificaat wordt automatisch vernieuwd door de RMS-client, mits het gebruikersaccount zich nog in Azure Active Directory 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 gaat, de certificaten worden gemaakt met behulp van dezelfde sleutels.

Inhoudsbeveiliging

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

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

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

Het kenmerk Azure AD dat wordt gebruikt om de geselecteerde gebruikers en groepen te identificeren, is het Azure AD-proxyAddress-kenmerk. Hierin worden alle e-mailadressen van een gebruiker of groep opgeslagen. Als een gebruikersaccount echter geen waarden heeft in het kenmerk AD ProxyAddresses, wordt de waarde UserPrincipalName van de gebruiker in plaats daarvan 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 het beleid ook met het gebruikerscertificaat dat is verkregen toen de gebruikersomgeving werd geïnitialiseerd.

Wat gebeurt er 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, die samen een beveiligd document vormen.

Dit document kan overal worden opgeslagen of op welke manier dan ook worden gedeeld en het beleid blijft altijd behouden bij het versleutelde document.

Inhoudsverbruik

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

Wat gebeurt er 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 stelt een lijst met rechten samen (indien aanwezig) die de gebruiker heeft voor het document. Voor de identificatie van de gebruiker wordt het Azure AD-proxyAddresses-kenmerk gebruikt voor het gebruikersaccount en de groepen waarvan de gebruiker lid is. Het groepslidmaatschap wordt vanwege de prestaties in de cache opgeslagen. Als het gebruikersaccount geen waarden heeft in het kenmerk Azure AD ProxyAddresses, wordt de waarde in Azure AD UserPrincipalName in plaats daarvan gebruikt.

Wat gebeurt er 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 tijdens de aanvraag.

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

Wat gebeurt er in stap 3: tot slot neemt de RMS-client de versleutelde gebruikslicentie en ontsleutelt deze met de eigen persoonlijke sleutel van de gebruiker. Hiermee kan de RMS-client de hoofdtekst van het document ontsleutelen wanneer dit gewenst is, en deze op het scherm weergeven.

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

Notitie

Wanneer gebruikers buiten uw organisatie inhoud verbruiken die u hebt beveiligd, is de verbruiksstroom dezelfde. Wat er verandert voor dit scenario, is de manier waarop de gebruiker wordt geverifieerd. Zie Wanneer ik een beveiligd document deel met iemand buiten mijn bedrijf, hoe wordt die gebruiker dan geverifieerd? voor meer informatie.

Variaties

De voorgaande walkthrough behandelt de standaardscenario's, maar er zijn enkele variaties:

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

• Mobiele apparaten: wanneer mobiele apparaten bestanden beveiligen of verbruiken met de Azure Rights Management-service, zijn de processtromen veel eenvoudiger. Mobiele apparaten gaan doorlopen niet eerst door het initialisatieproces voor de gebruiker omdat in plaats daarvan elke transactie (om inhoud te beveiligen of verbruiken) onafhankelijk is. Net zoals Windows-computers, maken mobiele apparaten verbinding met de Azure Rights Management-service voor verificatie. Voor het beveiligen van inhoud, dienen mobiele apparaten een beleid in en stuurt de Azure Rights Management-service een publicatielicentie en symmetrische sleutel om het document te beveiligen. Als mobiele apparaten voor het verbruiken van inhoud verbinding maken met de Azure Rights Management-service voor verificatie, wordt een documentbeleid naar de Azure Rights Management-service verzonden en een licentie aangevraagd om het document te mogen verbruiken. Als antwoord verzendt de Azure Rights Management-service de benodigde sleutels en beperkingen voor de mobiele apparaten. Voor beide processen wordt TLS gebruikt voor de beveiliging van de sleuteluitwisseling en andere berichten.

• RMS-connector: wanneer de Azure Rights Management-service wordt gebruikt met de RMS-connector, blijven de processtromen ongewijzigd. 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 voert zelf geen bewerkingen uit, zoals de initialisatie van de gebruikersomgeving, of versleutelen of ontsleutelen. In plaats daarvan stuurt de connector de communicatie door die meestal naar een AD RMS-server wordt verzonden, en handelt deze de vertaling af tussen de protocollen die aan beide zijden 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 wezen hetzelfde voor inhoudsbeveiliging, behalve dat de RMS-client een beleid maakt dat alle rechten verleend. Wanneer het bestand wordt verbruikt, wordt dit ontsleuteld voordat het aan de doeltoepassing wordt doorgegeven. Met dit scenario kunt u alle bestanden beveiligen, zelfs als deze geen systeemeigen ondersteuning bieden voor RMS.

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

Volgende stappen

Als u meer wilt weten over de Azure Rights Management service, gebruikt u de andere artikelen in de sectie Inzicht & in verkennen, zoals Hoe toepassingen de Azure Rights Management-service ondersteunen om te leren hoe uw bestaande toepassingen kunnen worden geïntegreerd met Azure Rights Management om een oplossing voor gegevensbeveiliging te bieden.

Lees Terminologie voor Azure Information Protection zodat u vertrouwd bent met de termen die u kunt tegenkomen tijdens het configureren en gebruiken van de Azure Rights Management-service, en lees tevens Vereisten voor Azure Information Protection voordat u begint met de implementatie. Als u meteen aan de slag wilt en het zelf wilt uitproberen, gebruikt u de quickstart en zelfstudies:

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

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

Tip

Gebruik de bronnen en koppelingen in Informatie en ondersteuning voor Azure Information Protection voor extra informatie en hulp.