Hoe werkt Azure RMS?How does Azure RMS work? OnderhuidsUnder the hood

*Van toepassing op: Azure Information Protection, Office 365**Applies to: Azure Information Protection, Office 365*

*Relevant voor: in het Algemeen gelabelde client en klassieke client. **Relevant for: AIP unified labeling client and classic client.*

Notitie

Om een geïntegreerde en gestroomlijnde klant ervaring te bieden, zijn de Azure Information Protection klassieke client en Label beheer in azure Portal verouderd vanaf 31 maart 2021.To provide a unified and streamlined customer experience, the Azure Information Protection classic client and Label Management in the Azure Portal are deprecated as of March 31, 2021. Terwijl de klassieke client blijft werken zoals geconfigureerd, wordt er geen verdere ondersteuning geboden en worden er geen onderhouds versies meer vrijgegeven voor de klassieke client.While the classic client continues to work as configured, no further support is provided, and maintenance versions will no longer be released for the classic client.

We raden u aan om te migreren naar Unified labels en een upgrade uit te voeren naar de Unified labeling-client.We recommend that you migrate to unified labeling and upgrade to the unified labeling client. Meer informatie vindt u in onze recente blog voor afschaffing.Learn more in our recent deprecation blog.

Het is belang rijk om inzicht te krijgen in de werking van Azure RMS, dat deze Data Protection-Service van Azure Information Protection, uw gegevens niet ziet of opslaat als onderdeel van het beveiligings proces.An important thing to understand about how Azure RMS works, is that this data protection service from Azure Information Protection, does not see or store your data as part of the protection process. Gegevens die u beveiligt, worden nooit verzonden naar of opgeslagen in azure, tenzij u deze expliciet opslaat in azure of een andere Cloud service gebruikt waarmee deze wordt opgeslagen in Azure.Information that you protect is never sent to or stored in Azure, unless you explicitly store it in Azure or use another cloud service that stores it in Azure. Azure RMS maakt alleen de gegevens in een document onleesbaar, behalve voor gemachtigde gebruikers en services:Azure RMS simply makes the data in a document unreadable to anyone other than authorized users and services:

  • De gegevens worden versleuteld op toepassingsniveau en het proces omvat een beleid dat geautoriseerd gebruik van dat document bepaalt.The data is encrypted at the application level and includes a policy that defines the authorized use for that document.

  • 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.When a protected document is used by a legitimate user or it is processed by an authorized service, the data in the document is decrypted and the rights that are defined in the policy are enforced.

De volgende afbeelding bevat een overzicht, waarmee u kunt zien hoe dit proces werkt.At a high level, you can see how this process works in the following picture. Een document dat de geheime formule bevat, wordt beveiligd en vervolgens geopend door een geautoriseerde gebruiker of -service.A document containing the secret formula is protected, and then successfully opened by an authorized user or service. Het document wordt beveiligd door een inhoudssleutel (de groene sleutel in deze afbeelding).The document is protected by a content key (the green key in this picture). 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).It is unique for each document and is placed in the file header where it is protected by your Azure Information Protection tenant root key (the red key in this picture). Uw tenantsleutel kan worden gegenereerd en beheerd door Microsoft, maar u kunt ook uw eigen tenantsleutel genereren en beheren.Your tenant key can be generated and managed by Microsoft, or you can generate and manage your own tenant key.

Gedurende het hele beveiligingsproces, waarbij Azure RMS versleutelt, ontsleutelt, goedkeurt en beperkingen afdwingt, wordt de geheime formule nooit wordt verzonden naar Azure.Throughout the protection process when Azure RMS is encrypting and decrypting, authorizing, and enforcing restrictions, the secret formula is never sent to Azure.

Hoe een bestand wordt beveiligd met Azure RMS

Zie de sectie Walkthrough over de werking van Azure RMS: eerste gebruik, inhoudsbeveiliging, inhoudverbruik in dit artikel voor een gedetailleerde omschrijving van de bewerkingen.For a detailed description of what’s happening, see the Walkthrough of how Azure RMS works: First use, content protection, content consumption section in this article.

Zie de volgende sectie voor technische gegevens over de algoritmen en sleutellengten die Azure RMS gebruikt.For technical details about the algorithms and key lengths that Azure RMS uses, see the next section.

Cryptografische besturingselementen die worden gebruikt door Azure RMS: algoritmen en sleutellengten.Cryptographic controls used by Azure RMS: Algorithms and key lengths

Zelfs als u niet meer wilt weten hoe deze technologie werkt, wordt u mogelijk gevraagd over de cryptografische besturings elementen die worden gebruikt.Even if you don't need to know in detail how this technology works, you might be asked about the cryptographic controls that it uses. Om bijvoorbeeld te bevestigen dat de beveiligings bescherming industrie standaard is.For example, to confirm that the security protection is industry-standard.

Cryptografische besturingselementenCryptographic controls Gebruik in Azure RMSUse in Azure RMS
Algoritme: AESAlgorithm: AES

Sleutellengte: 128-bits en 256-bits [1]Key length: 128 bits and 256 bits [1]
InhoudsbeveiligingContent protection
Algoritme: RSAAlgorithm: RSA

Sleutellengte: 2048 bits [2]Key length: 2048 bits [2]
SleutelbeveiligingKey protection
SHA-256SHA-256 CertificaatondertekeningCertificate signing
Voetnoot 1Footnote 1

256 bits wordt gebruikt door de Azure Information Protection-client in de volgende scenario's:256 bits is used by the Azure Information Protection client in the following scenarios:

  • Algemene beveiliging (. pfile).Generic protection (.pfile).

  • Systeem eigen beveiliging voor PDF-documenten wanneer het document is beveiligd met de ISO-standaard voor PDF-versleuteling of het resulterende beveiligde document heeft de bestandsnaam extensie. ppdf.Native protection for PDF documents when the document has been protected with the ISO standard for PDF encryption, or the resulting protected document has a .ppdf file name extension.

  • Systeem eigen beveiliging voor tekst-of afbeeldings bestanden (zoals. ptxt of. pjpg).Native protection for text or image files (such as .ptxt or .pjpg).

Voetnoot 2Footnote 2

2048 bits is de sleutel lengte wanneer de Azure Rights Management-service wordt geactiveerd.2048 bits is the key length when the Azure Rights Management service is activated. 1024 bits wordt ondersteund voor de volgende optionele scenario's:1024 bits is supported for the following optional scenarios:

  • Tijdens een migratie van on-premises als het AD RMS-cluster wordt uitgevoerd in de cryptografische modus 1.During a migration from on-premises if the AD RMS cluster is running in Cryptographic Mode 1.

  • Voor gearchiveerde sleutels die vóór de migratie on-premises zijn gemaakt, zodat inhoud die eerder is beveiligd door AD RMS, nog steeds kan worden geopend door de Azure Rights Management service na de migratie.For archived keys that were created on-premises before the migration, so that content that was previously protected by AD RMS can continue to be opened by the Azure Rights Management service post migration.

Hoe de cryptografische Azure RMS-sleutels worden opgeslagen en beveiligdHow the Azure RMS cryptographic keys are stored and secured

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.For each document or email that is protected by Azure RMS, Azure RMS creates a single AES key (the "content key"), and that key is embedded to the document, and persists through editions of the 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.The content key is protected with the organization’s RSA key (the "Azure Information Protection tenant key") as part of the policy in the document, and the policy is also signed by the author of the 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).This tenant key is common to all documents and emails that are protected by the Azure Rights Management service for the organization and this key can only be changed by an Azure Information Protection administrator if the organization is using a tenant key that is customer-managed (known as "bring your own key", or BYOK).

Deze tenantsleutel wordt beveiligd in de onlineservices van Microsoft, in een uiterst gecontroleerde omgeving en met maximale bewaking.This tenant key is protected in Microsoft’s online services, in a highly controlled environment and under close monitoring. Wanneer u een door de klant beheerde Tenant sleutel (BYOK) gebruikt, wordt deze beveiliging verbeterd door het gebruik van een matrix met high-end hardware security modules (Hsm's) in elke Azure-regio, zonder dat de sleutels kunnen worden geëxtraheerd, geëxporteerd of gedeeld onder elke omstandigheden.When you use a customer-managed tenant key (BYOK), this security is enhanced by the use of an array of high-end hardware security modules (HSMs) in each Azure region, without the ability for the keys to be extracted, exported, or shared under any circumstances. Zie Uw Azure Information Protection-tenantsleutel plannen en implementeren voor meer informatie over de tenantsleutel en BYOK.For more information about the tenant key and BYOK, see Planning and implementing your Azure Information Protection tenant key.

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.Licenses and certificates that are sent to a Windows device are protected with the client’s device private key, which is created the first time a user on the device uses Azure RMS. 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.This private key, in turn, is protected with DPAPI on the client, which protects these secrets by using a key derived from the user’s password. 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.On mobile devices, the keys are used only one time, so because they are not stored on the clients, these keys don’t need to be protected on the device.

Walkthrough over de werking van Azure RMS: eerste gebruik, inhoudsbeveiliging, inhoudverbruikWalkthrough of how Azure RMS works: First use, content protection, content consumption

Voor een gedetailleerder inzicht in de werking van Azure RMS, doorlopen we een typische stroom nadat de Azure Rights Management-service is geactiveerd en wanneer een gebruiker voor het eerst gebruikmaakt van de Rights Management-service op een Windows-computer (een proces dat ook wel initialisatie van de gebruikersomgeving of opstarten wordt genoemd), inhoud beveiligt (een document of e-mailadres) en vervolgens inhoud verbruikt (opent en gebruikt) die is beveiligd door iemand anders.To understand in more detail how Azure RMS works, let's walk through a typical flow after the Azure Rights Management service is activated and when a user first uses the Rights Management service on their Windows computer (a process sometimes known as initializing the user environment or bootstrapping), protects content (a document or email), and then consumes (opens and uses) content that has been protected by somebody else.

Nadat de gebruikersomgeving is geïnitialiseerd, kan die gebruiker vervolgens documenten beveiligen of beveiligde documenten op die computer verbruiken.After the user environment is initialized, that user can then protect documents or consume protected documents on that computer.

Notitie

Als deze gebruiker naar een andere Windows-computer verplaatst of een andere gebruiker deze dezelfde Windows-computer gebruikt, wordt het initialisatieproces herhaald.If this user moves to another Windows computer, or another user uses this same Windows computer, the initialization process is repeated.

Initialisatie van de gebruikersomgevingInitializing the user environment

Voordat een gebruiker inhoud kan beveiligen of beveiligde inhoud op een Windows-computer kan verbruiken, moet de gebruikersomgeving worden voorbereid op het apparaat.Before a user can protect content or consume protected content on a Windows computer, the user environment must be prepared on the device. Dit is een eenmalige proces en dat automatisch plaatsvindt zonder tussenkomst van de gebruiker wanneer een gebruiker inhoud beveiligt of beveiligde inhoud verbruikt:This is a one-time process and happens automatically without user intervention when a user tries to protect or consume protected content:

Activeringsstroom RMS-client - stap 1, verificatie van de 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 het Azure Active Directory-account.What's happening in step 1: The RMS client on the computer first connects to the Azure Rights Management service, and authenticates the user by using their 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.When the user’s account is federated with Azure Active Directory, this authentication is automatic and the user is not prompted for credentials.

Activering RMS-client - stap 2, certificaten zijn gedownload naar de 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. 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.What's happening in step 2: After the user is authenticated, the connection is automatically redirected to the organization’s Azure Information Protection tenant, which issues certificates that let the user authenticate to the Azure Rights Management service in order to consume protected content and to protect content offline.

Een van deze certificaten is het Rights Account-certificaat, vaak afgekort tot RAC.One of these certificates is the rights account certificate, often abbreviated to RAC. Dit certificaat verifieert de gebruiker tot Azure Active Directory en is 31 dagen geldig.This certificate authenticates the user to Azure Active Directory and is valid for 31 days. Het certificaat wordt automatisch vernieuwd door de RMS-client, zodat het gebruikers account nog steeds in Azure Active Directory is en het account is ingeschakeld.The certificate is automatically renewed by the RMS client, providing the user account is still in Azure Active Directory and the account is enabled. Dit certificaat kan niet worden geconfigureerd door een beheerder.This certificate is not configurable by an administrator.

Een kopie van dit certificaat wordt opgeslagen in azure, zodat de certificaten worden gemaakt met behulp van dezelfde sleutels als de gebruiker naar een ander apparaat verplaatst.A copy of this certificate is stored in Azure so that if the user moves to another device, the certificates are created by using the same keys.

InhoudsbeveiligingContent protection

Wanneer een gebruiker een document beveiligt, voert de RMS-client de volgende acties uit op een niet-beveiligd document:When a user protects a document, the RMS client takes the following actions on an unprotected document:

RMS-beveiliging voor documenten - stap 1, document wordt versleuteld

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.What's happening in step 1: The RMS client creates a random key (the content key) and encrypts the document using this key with the AES symmetric encryption algorithm.

RMS-beveiliging voor documenten - stap 2, beleid wordt gemaakt

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.What's happening in step 2: The RMS client then creates a certificate that includes a policy for the document that includes the usage rights for users or groups, and other restrictions, such as an expiration date. Deze instellingen kunnen worden gedefinieerd in een sjabloon die eerder is geconfigureerd door een beheerder of die is opgegeven op het moment dat de inhoud wordt beveiligd (ook wel ' ad hoc beleid ' genoemd).These settings can be defined in a template that an administrator previously configured, or specified at the time the content is protected (sometimes referred to as an "ad hoc policy").

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.The main Azure AD attribute used to identify the selected users and groups is the Azure AD ProxyAddresses attribute, which stores all the email addresses for a user or group. Als een gebruikersaccount echter geen waarden heeft in het kenmerk AD ProxyAddresses, wordt de waarde UserPrincipalName van de gebruiker in plaats daarvan gebruikt.However, if a user account doesn't have any values in the AD ProxyAddresses attribute, the user's UserPrincipalName value is used instead.

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.The RMS client then uses the organization’s key that was obtained when the user environment was initialized and uses this key to encrypt the policy and the symmetric content key. De RMS-client ondertekent het beleid ook met het gebruikerscertificaat dat is verkregen toen de gebruikersomgeving werd geïnitialiseerd.The RMS client also signs the policy with the user’s certificate that was obtained when the user environment was initialized.

RMS-beveiliging voor documenten - stap 3, beleid wordt ingesloten in het document

Wat gebeurt er in stap 3: tot slot wordt het beleid door de RMS-client Inge sloten in een bestand met de hoofd tekst van het document dat eerder is versleuteld, die samen een beveiligd document vormen.What's happening in step 3: Finally, the RMS client embeds the policy into a file with the body of the document encrypted previously, which together comprise a protected document.

Dit document kan overal worden opgeslagen of op welke manier dan ook worden gedeeld en het beleid blijft altijd behouden bij het versleutelde document.This document can be stored anywhere or shared by using any method, and the policy always stays with the encrypted document.

InhoudsverbruikContent consumption

Wanneer een gebruiker een beveiligd document wil verbruiken, begint de RMS-client met het aanvragen van toegang tot de Azure Rights Management-service:When a user wants to consume a protected document, the RMS client starts by requesting access to the Azure Rights Management service:

RMS-documentverbruik - stap 1, gebruiker wordt geverifieerd en krijgt de lijst met rechten

Wat gebeurt er in stap 1: de geverifieerde gebruiker verzendt het documentbeleid en de certificaten van de gebruiker naar de Azure Rights Management-service.What's happening in step 1: The authenticated user sends the document policy and the user’s certificates to the 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.The service decrypts and evaluates the policy, and builds a list of rights (if any) the user has for the 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.To identify the user, the Azure AD ProxyAddresses attribute is used for the user's account and groups to which the user is a member. Het groepslidmaatschap wordt vanwege de prestaties in de cache opgeslagen.For performance reasons, group membership is cached. Als het gebruikersaccount geen waarden heeft in het kenmerk Azure AD ProxyAddresses, wordt de waarde in Azure AD UserPrincipalName in plaats daarvan gebruikt.If the user account has no values for the Azure AD ProxyAddresses attribute, the value in the Azure AD UserPrincipalName is used instead.

RMS-documentverbruik - stap 2, gebruikslicentie wordt geretourneerd naar de client

Wat gebeurt er in stap 2: de service extraheert vervolgens de AES-inhoudssleutel uit het ontsleutelde beleid.What's happening in step 2: The service then extracts the AES content key from the decrypted policy. Deze sleutel wordt vervolgens versleuteld met de openbare RSA-sleutel van de gebruiker die is verkregen tijdens de aanvraag.This key is then encrypted with the user’s public RSA key that was obtained with the request.

De opnieuw versleutelde inhoudssleutel wordt vervolgens ingebed in een versleutelde gebruikslicentie met de lijst met gebruikersrechten, die vervolgens wordt geretourneerd naar de RMS-client.The re-encrypted content key is then embedded into an encrypted use license with the list of user rights, which is then returned to the RMS client.

RMS-document verbruik-stap 3, document wordt ontsleuteld en rechten worden afgedwongen

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.What's happening in step 3: Finally, the RMS client takes the encrypted use license and decrypts it with its own user private key. Hiermee kan de RMS-client de hoofdtekst van het document ontsleutelen wanneer dit gewenst is, en deze op het scherm weergeven.This lets the RMS client decrypt the document’s body as it is needed and render it on the screen.

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.The client also decrypts the rights list and passes them to the application, which enforces those rights in the application’s user interface.

Notitie

Wanneer gebruikers buiten uw organisatie inhoud verbruiken die u hebt beveiligd, is de verbruiksstroom dezelfde.When users who are external to your organization consume content that you've protected, the consumption flow is the same. Wat er verandert voor dit scenario, is de manier waarop de gebruiker wordt geverifieerd.What changes for this scenario, is how the user is authenticated. Zie Wanneer ik een beveiligd document deel met iemand buiten mijn bedrijf, hoe wordt die gebruiker dan geverifieerd? voor meer informatie.For more information, see When I share a protected document with somebody outside my company, how does that user get authenticated?

VariatiesVariations

De voorgaande walkthrough behandelt de standaardscenario's, maar er zijn enkele variaties:The preceding walkthroughs cover the standard scenarios but there are some variations:

  • E-mail beveiliging: wanneer Exchange Online en Office 365-bericht versleuteling met nieuwe mogelijkheden wordt gebruikt voor het beveiligen van e-mail berichten, kan de verificatie voor verbruik ook worden gebruikt met behulp van Federatie met een id-provider voor sociale netwerken of met een eenmalige wachtwoord code.Email protection: When Exchange Online and Office 365 Message Encryption with new capabilities is used to protect email messages, authentication for consumption can also use federation with a social identity provider or by using a one-time passcode. De proces stromen zijn dan vergelijkbaar, behalve dat het inhouds verbruik aan de service zijde in een webbrowser wordt uitgevoerd via een tijdelijk in de cache opgeslagen kopie van het uitgaande e-mail bericht.Then, the process flows are very similar, except that content consumption happens service-side in a web browser session over a temporarily cached copy of the outbound email.

  • Mobiele apparaten: wanneer mobiele apparaten bestanden beveiligen of verbruiken met de Azure Rights Management-service, zijn de processtromen veel eenvoudiger.Mobile devices: When mobile devices protect or consume files with the Azure Rights Management service, the process flows are much simpler. 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.Mobile devices don’t first go through the user initialization process because instead, each transaction (to protect or consume content) is independent. Net zoals Windows-computers, maken mobiele apparaten verbinding met de Azure Rights Management-service voor verificatie.As with Windows computers, mobile devices connect to the Azure Rights Management service and authenticate. 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.To protect content, mobile devices submit a policy and the Azure Rights Management service sends them a publishing license and symmetric key to protect the document. 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.To consume content, when mobile devices connect to the Azure Rights Management service and authenticate, they send the document policy to the Azure Rights Management service and request a use license to consume the document. Als antwoord verzendt de Azure Rights Management-service de benodigde sleutels en beperkingen voor de mobiele apparaten.In response, the Azure Rights Management service sends the necessary keys and restrictions to the mobile devices. Voor beide processen wordt TLS gebruikt voor de beveiliging van de sleuteluitwisseling en andere berichten.Both processes use TLS to protect the key exchange and other communications.

  • RMS-connector: wanneer de Azure Rights Management-service wordt gebruikt met de RMS-connector, blijven de processtromen ongewijzigd.RMS connector: When the Azure Rights Management service is used with the RMS connector, the process flows remain the same. 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.The only difference is that the connector acts as a relay between the on-premises services (such as Exchange Server and SharePoint Server) and the Azure Rights Management service. De connector voert zelf geen bewerkingen uit, zoals de initialisatie van de gebruikersomgeving, of versleutelen of ontsleutelen.The connector itself does not perform any operations, such as the initialization of the user environment, or encryption or decryption. 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.It simply relays the communication that would usually go to an AD RMS server, handling the translation between the protocols that are used on each side. In dit scenario kunt u de Azure Rights Management-service gebruiken met on-premises services.This scenario lets you use the Azure Rights Management service with 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.Generic protection (.pfile): When the Azure Rights Management service generically protects a file, the flow is basically the same for content protection except that the RMS client creates a policy that grants all rights. Wanneer het bestand wordt verbruikt, wordt dit ontsleuteld voordat het aan de doeltoepassing wordt doorgegeven.When the file is consumed, it is decrypted before it is passed to the target application. Met dit scenario kunt u alle bestanden beveiligen, zelfs als deze geen systeemeigen ondersteuning bieden voor RMS.This scenario lets you protect all files, even if they don’t natively support RMS.

  • Micro soft-accounts: Azure Information Protection kunnen e-mail adressen toestaan voor gebruik wanneer ze worden geverifieerd met een Microsoft-account.Microsoft accounts: Azure Information Protection can authorize email addresses for consumption when they are authenticated with a Microsoft account. Niet alle toepassingen kunnen echter beveiligde inhoud openen als een Microsoft-account wordt gebruikt voor verificatie.However, not all applications can open protected content when a Microsoft account is used for authentication. Meer informatie.More information.

Volgende stappenNext steps

Als u meer wilt weten over de Azure Rights Management-service, leest u de andere artikelen in het gedeelte Begrijpen en verkennen, zoals Hoe toepassingen ondersteuning bieden voor de Azure Rights Management-service voor meer informatie over hoe u uw huidige toepassingen kunt integreren met Azure Rights Management om een oplossing voor gegevensbeveiliging te bieden.To learn more about the Azure Rights Management service, use the other articles in the Understand & Explore section, such as How applications support the Azure Rights Management service to learn how your existing applications can integrate with Azure Rights Management to provide an information protection solution.

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.Review Terminology for Azure Information Protection so that you’re familiar with the terms that you might come across as you’re configuring and using the Azure Rights Management service, and be sure to also check Requirements for Azure Information Protection before you start your deployment. Als u meteen van start wilt gaan en het zelf wilt proberen, gebruikt u de Snelstartgids en zelf studies:If you want to dive right in and try it out for yourself, use the quickstart and tutorials:

Als u klaar bent voor het implementeren van gegevens beveiliging voor uw organisatie, gebruikt u het beheerders implementatie schema voor classificatie, labeling en beveiliging voor uw implementaties tappen en koppelingen naar instructies.If you’re ready to start deploying data protection for your organization, use the AIP deployment roadmap for classification, labeling, and protection for your deployment steps and links for how-to instructions.

Tip

Gebruik de bronnen en koppelingen in Informatie en ondersteuning voor Azure Information Protection voor extra informatie en hulp.For additional information and help, use the resources and links in Information and support for Azure Information Protection.