Hoe werkt Azure RMS? Onder de kap

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 eenvoudigweg onleesbaar voor anderen 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 wordt verwerkt door een geautoriseerde service, worden de gegevens in het document ontsleuteld en worden de rechten die in het beleid zijn gedefinieerd, afgedwongen.

Op hoog niveau kunt u in de volgende afbeelding zien hoe dit proces werkt. Een document met de geheime formule is 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 het 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 versleuteling en ontsleuteling, autoriseren en beperkingen afdwingt, wordt de geheime formule nooit naar Azure verzonden.

How Azure RMS protects a file

Zie het overzicht van hoe Azure RMS werkt voor een gedetailleerde beschrijving van wat er gebeurt: Eerste gebruik, inhoudsbeveiliging, 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 naar de cryptografische besturingselementen die worden gebruikt. Bijvoorbeeld om te bevestigen dat 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

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 als het resulterende beveiligde document de extensie .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 is beveiligd door AD RMS, kan worden geopend door de Azure Rights Management-service na de migratie.

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 wordt die sleutel ingesloten in het document en blijft deze 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. 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 van high-end hardwarebeveiligingsmodules (HSM's) in elke Azure-regio, zonder de mogelijkheid om de sleutels onder welke omstandigheden dan ook te extraheren, exporteren of delen. 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 het apparaat van de client, die wordt gemaakt wanneer een gebruiker op het apparaat voor het eerst Azure RMS gebruikt. Deze persoonlijke sleutel wordt op zijn beurt beveiligd met DPAPI op de client, die deze geheimen beveiligt 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 te worden beveiligd op het apparaat.

Overzicht van de werking van Azure RMS: Eerste gebruik, inhoudsbeveiliging, inhoudsverbruik

Als u meer wilt weten over de werking van Azure RMS, gaan we een typische stroom doorlopen 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 het initialiseren van de gebruikersomgeving of bootstrapping wordt genoemd), inhoud (een document of e-mail) beveiligt en vervolgens verbruikt (opent en gebruikt) inhoud die is beveiligd door iemand anders.

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

Opmerking

Als deze gebruiker naar een andere Windows computer gaat 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 op het apparaat worden voorbereid. Dit is een eenmalig proces en gebeurt automatisch zonder tussenkomst van de gebruiker wanneer een gebruiker beveiligde inhoud probeert te beveiligen of gebruiken:

RMS Client activation flow - step 1, authenticating the client

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 behulp van hun Azure Active Directory-account.

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

RMS Client activation - step 2, certificates are downloaded to the client

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, die certificaten uitgeeft 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 certificaat van het rechtenaccount, vaak afgekort tot RAC. Met dit certificaat wordt de gebruiker geverifieerd voor Azure Active Directory en is het 31 dagen geldig. Het certificaat wordt automatisch vernieuwd door de RMS-client, mits het gebruikersaccount zich nog steeds 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 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:

RMS document protection - step 1, document is encrypted

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

RMS document protection - step 2, policy is created

Wat gebeurt er in stap 2: De RMS-client maakt vervolgens een certificaat met een beleid voor het document dat de gebruiksrechten voor gebruikers of groepen bevat, 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 ad-hocbeleid genoemd).

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

RMS document protection - step 3, policy is embedded in the document

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

Dit document kan overal worden opgeslagen of gedeeld met behulp van 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:

RMS document consumption - step 1, user is authenticated and gets the list of rights

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 maakt een lijst met rechten (indien van toepassing) die de gebruiker voor het document heeft. Om de gebruiker te identificeren, wordt het kenmerk Azure AD ProxyAddresses gebruikt voor het account en de groepen van de gebruiker waarvan de gebruiker lid is. Om prestatieredenen wordt groepslidmaatschap in de cache opgeslagen. Als het gebruikersaccount geen waarden heeft voor het kenmerk Azure AD ProxyAddresses, wordt in plaats daarvan de waarde in de Azure AD UserPrincipalName gebruikt.

RMS document consumption - step 2, use license is returned to the client

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 bij de aanvraag is verkregen.

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

RMS document consumption - step 3, document is decrypted and rights are enforced

Wat gebeurt er in stap 3: Ten slotte neemt de RMS-client de versleutelde gebruikslicentie en ontsleutelt deze met een eigen persoonlijke sleutel van de gebruiker. Hierdoor kan de RMS-client de hoofdtekst van het document ontsleutelen zoals nodig is en deze weergeven op het scherm.

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

Opmerking

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

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 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 vergelijkbaar, behalve dat het verbruik van inhoud aan de servicezijde 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 stuurt ze een publicatielicentie en symmetrische sleutel om het document te beveiligen. Wanneer 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 antwoord 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. Hiermee wordt de communicatie die gewoonlijk naar een AD RMS-server wordt verzonden, doorgestuurd en wordt de vertaling verwerkt 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 verbruikt, wordt het ontsleuteld voordat het wordt doorgegeven aan de doeltoepassing. In dit scenario kunt u alle bestanden beveiligen, zelfs als ze RMS niet systeemeigen ondersteunen.

  • Microsoft-accounts: Azure Information Protection kan e-mailadressen autoriseren voor gebruik 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 Verkennen begrijpen&, 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 gegevensbeveiliging te bieden.

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

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.