Hur fungerar Azure RMS?How does Azure RMS work? Under huvenUnder the hood

Gäller för: Azure information Protection, Office 365Applies to: Azure Information Protection, Office 365

En viktig roll för att förstå hur Azure RMS fungerar, är att den här data skydds tjänsten från Azure Information Protection, inte ser eller lagrar dina data som en del av skydds processen.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. Information som du skyddar skickas aldrig till eller lagras i Azure, om du inte uttryckligen lagrar den i Azure eller använder en annan moln tjänst som lagrar den i 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 gör helt enkelt data i ett dokument oläsliga för alla förutom auktoriserade användare och tjänster:Azure RMS simply makes the data in a document unreadable to anyone other than authorized users and services:

  • Data krypteras på programnivå och innehåller en princip som definierar godkänd användning av dokumentet i fråga.The data is encrypted at the application level and includes a policy that defines the authorized use for that document.

  • När ett skyddat dokument används av en legitim användare eller bearbetas av en auktoriserad tjänst, dekrypteras data i dokumentet och de rättigheter som är definierade i principen används.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.

Du kan se på följande bild hur den här processen fungerar på hög nivå.At a high level, you can see how this process works in the following picture. Ett dokument som innehåller den hemliga formeln är skyddat och har öppnats av en behörig användare eller tjänst.A document containing the secret formula is protected, and then successfully opened by an authorized user or service. Dokumentet skyddas av en innehållsnyckel (den gröna nyckeln på den här bilden).The document is protected by a content key (the green key in this picture). Den är unik för varje dokument och placeras i filhuvudet där den skyddas av klientrotnyckeln för Azure Information Protection (den röda nyckeln på den här bilden).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). Din klientnyckel kan skapas och hanteras av Microsoft, eller också kan du skapa och hantera en egen klientnyckel.Your tenant key can be generated and managed by Microsoft, or you can generate and manage your own tenant key.

Under skyddsprocessen när Azure RMS krypterar och dekrypterar, auktoriserar och tillämpar begränsningarna skickas den hemliga formeln aldrig till Azure.Throughout the protection process when Azure RMS is encrypting and decrypting, authorizing, and enforcing restrictions, the secret formula is never sent to Azure.

Så här skyddas en fil av Azure RMS

En detaljerad beskrivning av vad som händer finns i avsnittet Genomgång av hur Azure RMS fungerar: första användning, innehållsskydd, innehållsanvändning i den här artikeln.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.

Teknisk information om de algoritmer och nyckellängder som Azure RMS använder finns i nästa avsnitt.For technical details about the algorithms and key lengths that Azure RMS uses, see the next section.

Kryptografiska kontroller som används av Azure RMS: algoritmer och nyckellängderCryptographic controls used by Azure RMS: Algorithms and key lengths

Även om du inte behöver veta mer om hur den här tekniken fungerar, kan du bli tillfrågad om de kryptografiska kontroller som används.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. Till exempel för att bekräfta att säkerhets skyddet är bransch standard.For example, to confirm that the security protection is industry-standard.

Kryptografiska kontrollerCryptographic controls Används i Azure RMSUse in Azure RMS
Algoritm: AESAlgorithm: AES

Nyckellängd: 128 och 256 bitar [1]Key length: 128 bits and 256 bits [1]
InnehållsskyddContent protection
Algoritm: RSAAlgorithm: RSA

Nyckellängd: 2 048 bitar [2]Key length: 2048 bits [2]
NyckelskyddKey protection
SHA-256SHA-256 CertifikatsigneringCertificate signing
Fotnot 1Footnote 1

256 bitar används av Azure Information Protection-klienten i följande scenarier:256 bits is used by the Azure Information Protection client in the following scenarios:

  • Allmänt skydd (. pfile).Generic protection (.pfile).

  • Inbyggt skydd för PDF-dokument när dokumentet har skyddats med ISO-standarden för PDF-kryptering eller det resulterande skyddade dokumentet har fil namns tillägget. 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.

  • Inbyggt skydd för text-eller bildfiler (till exempel. ptxt eller. pjpg).Native protection for text or image files (such as .ptxt or .pjpg).

Fotnot 2Footnote 2

2048 bitar är nyckel längden när Azure Rights Management-tjänsten aktive ras.2048 bits is the key length when the Azure Rights Management service is activated. 1024 bitar stöds för följande valfria scenarier:1024 bits is supported for the following optional scenarios:

  • Under en migrering från lokal plats om AD RMS klustret körs i kryptografi läge 1.During a migration from on-premises if the AD RMS cluster is running in Cryptographic Mode 1.

  • För arkiverade nycklar som har skapats lokalt före migreringen, så att innehåll som tidigare skyddades av AD RMS kan fortsätta att öppnas av Azure Rights Management Service post-migreringen.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.

Hur de kryptografiska Azure RMS-nycklarna lagras och skyddasHow the Azure RMS cryptographic keys are stored and secured

För varje dokument eller e-postmeddelande som skyddas av Azure RMS skapas en enda AES-nyckel i Azure RMS (”innehållsnyckeln”) och nyckeln bäddas in i dokumentet och finns kvar i alla utgåvor av dokumentet.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.

Innehållsnyckeln skyddas av organisationens RSA-nyckel (”Azure Information Protection-klientnyckeln”) som en del av principen i dokumentet och principen är även signerad av författaren till dokumentet.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. Klientnyckeln är gemensam för alla dokument och e-postmeddelanden som skyddas av Azure Rights Management-tjänsten för organisationen, och den här nyckeln kan bara ändras av en Azure Information Protection-administratör, förutsatt att organisationen använder en klientnyckel som är kundhanterad (kallas för BYOK).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).

Den här klientnyckeln skyddas i Microsofts onlinetjänster, i en miljö med hög kontroll och noggrann övervakning.This tenant key is protected in Microsoft’s online services, in a highly controlled environment and under close monitoring. När du använder en kundhanterad klient nyckel (BYOK) förbättras den här säkerheten genom användning av en matris med avancerade HSM: er-säkerhetsmoduler () i varje Azure-region, utan möjligheten att de nycklar som ska extraheras, exporteras eller delas under några omständigheter.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. Mer information om alternativen för klientnycklar och BYOK finns i Planera för och implementera din Azure Information Protection-klientnyckel.For more information about the tenant key and BYOK, see Planning and implementing your Azure Information Protection tenant key.

Licenser och certifikat som skickas till en Windows-enhet skyddas av klientenhetens privata nyckel, som skapas första gången en användare på enheten använder Azure RMS.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. Den privata nyckeln skyddas i sin tur med DPAPI på klienten, som skyddar dessa hemligheter med hjälp av en nyckel som härleds från användarens lösenord.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. På mobila enheter används nycklarna bara en gång, så eftersom de inte lagras på klienterna behöver nycklarna inte skyddas på enheten.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.

Genomgång av hur Azure RMS fungerar: första användning, innehållsskydd, innehållsanvändningWalkthrough of how Azure RMS works: First use, content protection, content consumption

För att förstå hur Azure RMS fungerar i detalj ska vi gå igenom ett typiskt flöde efter att Azure Rights Management-tjänsten har aktiverats och när en användare för första gången använder Rights Management-tjänsten på sin Windows-dator (en process som ibland kallas för att initiera användarmiljön eller ”bootstrapping”), skyddar innehåll (ett dokument eller e-postmeddelande) och sedan använder (öppnar och tar del av) innehåll som har skyddats av någon annan.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.

När användarmiljön har initierats kan användaren sedan skydda dokument och använda skyddade dokument på datorn.After the user environment is initialized, that user can then protect documents or consume protected documents on that computer.

Anteckning

Om användaren flyttas till en annan Windows-dator, eller om en annan användare använder samma Windows-dator, upprepas initieringsprocessen.If this user moves to another Windows computer, or another user uses this same Windows computer, the initialization process is repeated.

Initiera användarmiljönInitializing the user environment

Innan en användare kan skydda innehåll eller använder skyddat innehåll på en Windows-dator måste användarmiljön på enheten förberedas.Before a user can protect content or consume protected content on a Windows computer, the user environment must be prepared on the device. Det här är en engångsprocess som sker automatiskt utan åtgärd från användarens sida när hon eller han försöker skydda eller använda skyddat innehåll:This is a one-time process and happens automatically without user intervention when a user tries to protect or consume protected content:

Aktiveringsflöde för RMS-klienten – steg 1, klienten verifieras

Vad som händer i steg 1: RMS-klienten på datorn ansluter först till Azure Rights Management-tjänsten och autentiserar användaren med hjälp av användarens Azure Active Directory-konto.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.

När användarens konto är federerad med Azure Active Directory, är den här autentiseringen automatiskt och användaren tillfrågas inte om autentiseringsuppgifter.When the user’s account is federated with Azure Active Directory, this authentication is automatic and the user is not prompted for credentials.

Aktivering av RMS-klienten – steg 2, certifikat laddas ned till klienten

Vad som händer i steg 2: När användaren har autentiserats dirigeras anslutningen automatiskt om till organisationens Azure Information Protection-klient, som utfärdar certifikat som gör att användaren autentiseras för Azure Rights Management-tjänsten och kan ta del av skyddat innehåll och skydda innehåll offline.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.

Ett av dessa certifikat är rättighets konto certifikatet, ofta förkortat till RAC.One of these certificates is the rights account certificate, often abbreviated to RAC. Det här certifikatet autentiserar användaren till Azure Active Directory och är giltig i 31 dagar.This certificate authenticates the user to Azure Active Directory and is valid for 31 days. Certifikatet förnyas automatiskt av RMS-klienten, vilket innebär att användar kontot fortfarande är i Azure Active Directory och att kontot är aktiverat.The certificate is automatically renewed by the RMS client, providing the user account is still in Azure Active Directory and the account is enabled. Det här certifikatet kan inte konfigureras av en administratör.This certificate is not configurable by an administrator.

En kopia av det här certifikatet lagras i Azure så att om användaren flyttar till en annan enhet skapas certifikaten med hjälp av samma nycklar.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.

InnehållsskyddContent protection

När en användare skyddar ett dokument utförs följande åtgärder i RMS-klienten för ett oskyddat dokument:When a user protects a document, the RMS client takes the following actions on an unprotected document:

RMS-dokumentskydd – steg 1, dokumentet krypteras

Vad som händer i steg 1: RMS-klienten skapar en slumpmässig nyckel (innehållsnyckeln) och krypterar dokumentet med hjälp av den här nyckeln och en symmetrisk AES-krypteringsalgoritm.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-dokumentskydd – steg 2, princip skapas

Vad som händer i steg 2: RMS-klienten skapar sedan ett certifikat som innehåller en princip för dokumentet som i sin tur innehåller användningsrättigheterna för användare eller grupper och andra begränsningar som till exempel förfallodatum.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. De här inställningarna kan definieras i en mall som en administratör har konfigurerat tidigare eller som anges vid den tidpunkt då innehållet skyddas (kallas ibland för en "ad hoc-princip").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").

Det huvudsakliga Azure AD-attributet som används för att identifiera valda användare och grupper är attributet Azure AD ProxyAddresses, som lagrar alla e-postadresser för en användare eller en grupp.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. Men om ett användarkonto saknar värden i attributet AD ProxyAddresses, används användarens UserPrincipalName-värde i stället.However, if a user account doesn't have any values in the AD ProxyAddresses attribute, the user's UserPrincipalName value is used instead.

RMS-klienten använder sedan den organisationsnyckel som hämtades när användarens miljö initierades och använder den här nyckeln för att kryptera principen och den symmetriska innehållsnyckeln.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. RMS-klienten signerar också principen med det användarcertifikat som hämtades när användarmiljön initierades.The RMS client also signs the policy with the user’s certificate that was obtained when the user environment was initialized.

RMS-dokumentskydd – steg 3, principen bäddas in i dokumentet

Vad som händer i steg 3: slutligen BÄDDAr RMS-klienten in principen i en fil med dokumentets brödtext som är krypterad tidigare, som tillsammans utgör ett skyddat dokument.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.

Det här dokumentet kan lagras var som helst eller delas med valfri metod och principen finna alltid kvar i det krypterade dokumentet.This document can be stored anywhere or shared by using any method, and the policy always stays with the encrypted document.

InnehållsanvändningContent consumption

När en användare vill använda ett skyddat dokument begär RMS-klienten först åtkomst till Azure Rights Management-tjänsten:When a user wants to consume a protected document, the RMS client starts by requesting access to the Azure Rights Management service:

RMS-dokumentförbrukning – steg 1, användaren autentiseras och får listan med rättigheter

Vad som händer i steg 1: Den autentiserade användaren skickar dokumentprincipen och användarens certifikat till Azure Rights Management-tjänsten.What's happening in step 1: The authenticated user sends the document policy and the user’s certificates to the Azure Rights Management service. Tjänsten dekrypterar och utvärderar principen och skapar en lista över (eventuella) rättigheter som användaren har till dokumentet.The service decrypts and evaluates the policy, and builds a list of rights (if any) the user has for the document. För att identifiera användaren används attributet Azure AD ProxyAddresses för det konto och de grupper där användaren är medlem.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. Av prestandaskäl cachelagras gruppmedlemskap.For performance reasons, group membership is cached. Om användarkontot saknar värden för attributet Azure AD ProxyAddresses, används värdet i Azure AD UserPrincipalName i stället.If the user account has no values for the Azure AD ProxyAddresses attribute, the value in the Azure AD UserPrincipalName is used instead.

RMS-dokumentförbrukning – steg 2, användarlicensen returneras till klienten

Vad som händer i steg 2: Tjänsten extraherar sedan AES-innehållsnyckeln från den dekrypterade principen.What's happening in step 2: The service then extracts the AES content key from the decrypted policy. Den här nyckeln krypteras sedan med användarens offentliga RSA-nyckel som hämtades tillsammans med begäran.This key is then encrypted with the user’s public RSA key that was obtained with the request.

Den här omkrypterade innehållsnyckeln bäddas sedan in i en krypterad användarlicens med listan över användarrättigheter som sedan returneras till RMS-klienten.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.

Dokument förbrukning i RMS – steg 3, dokument dekrypteras och rättigheter tillämpas

Vad som händer i steg 3: Slutligen tar RMS-klienten den krypterade användarlicensen och dekrypterar den med sin egen privata användarnyckel.What's happening in step 3: Finally, the RMS client takes the encrypted use license and decrypts it with its own user private key. Detta gör att RMS-klienten kan dekryptera dokumentets brödtext vid behov och visa den på skärmenThis lets the RMS client decrypt the document’s body as it is needed and render it on the screen.

Klienten dekrypterar också rättighetslistan och skickar dem till programmet där rättigheterna tillämpas i programmets användargränssnitt.The client also decrypts the rights list and passes them to the application, which enforces those rights in the application’s user interface.

Anteckning

När användare som är externa för din organisation använder innehåll som du har skyddat är förbrukningsflödet detsamma.When users who are external to your organization consume content that you've protected, the consumption flow is the same. Det som ändras i det här scenariot är hur användaren autentiseras.What changes for this scenario, is how the user is authenticated. Mer information finns i Hur går autentiseringen av utomstående användare till när jag delar ett skyddat dokument med någon utanför företaget?For more information, see When I share a protected document with somebody outside my company, how does that user get authenticated?

VariationerVariations

Föregående handledningar täcker in vanliga scenarier men det finns vissa varianter:The preceding walkthroughs cover the standard scenarios but there are some variations:

  • E-post skydd: när meddelande kryptering i Exchange Online och Office 365 med nya funktioner används för att skydda e-postmeddelanden kan autentisering för konsumtion också använda Federation med en social identitetsprovider eller med ett eng ång slö sen ord.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. Process flödena är sedan mycket lika, förutom att innehålls förbrukningen sker på tjänst sidan i en webbläsarsession över en tillfälligt cachelagrad kopia av utgående e-post.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.

  • Mobila enheter: När mobila enheter skyddar eller använder filer med Azure Rights Management-tjänsten är processflödena mycket enklare.Mobile devices: When mobile devices protect or consume files with the Azure Rights Management service, the process flows are much simpler. Mobila enheter går inte först igenom processen för användarinitiering eftersom varje transaktion i stället (för att skydda eller använda innehåll) är oberoende.Mobile devices don’t first go through the user initialization process because instead, each transaction (to protect or consume content) is independent. Precis som med Windows-datorer ansluts mobila enheter till Azure Rights Management-tjänsten och autentiseras.As with Windows computers, mobile devices connect to the Azure Rights Management service and authenticate. För att skydda innehåll skickar de mobila enheterna in en princip och Azure Rights Management-tjänsten skickar dem en publiceringslicens och en symmetrisk nyckel som skyddar dokumentet.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. För att det ska gå att använda innehållet när mobila enheter ansluter till Azure Rights Management-tjänsten och autentiseras skickar de dokumentprincipen till Azure Rights Management-tjänsten och begär en användarlicens för att använda dokumentet.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. Som ett svar skickar Azure Rights Management-tjänsten nödvändiga nycklar och begränsningar till de mobila enheterna.In response, the Azure Rights Management service sends the necessary keys and restrictions to the mobile devices. I båda dessa förfaranden skyddas nyckelutbytet och annan kommunikation med hjälp av TLS.Both processes use TLS to protect the key exchange and other communications.

  • RMS-koppling: När Azure Rights Management-tjänsten används med RMS-anslutningstjänsten förblir processflödena identiska.RMS connector: When the Azure Rights Management service is used with the RMS connector, the process flows remain the same. Den enda skillnaden är att kopplingen fungerar som ett relä mellan lokala tjänster (till exempel Exchange Server och SharePoint Server) och Azure Rights Management-tjänsten.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. Inga åtgärder utförs av kopplingen själv, till exempel initiering av användarmiljön, kryptering eller dekryptering.The connector itself does not perform any operations, such as the initialization of the user environment, or encryption or decryption. Den vidarebefordrar bara den kommunikation som vanligtvis skulle gå till en AD RMS-server, och hanterar översättningen mellan de protokoll som används på vardera sida.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. Det här scenariot gör det möjligt att integrera Azure Rights Management-tjänsten med lokala tjänster.This scenario lets you use the Azure Rights Management service with on-premises services.

  • Allmänt skydd (.pfile): När Azure Rights Management-tjänsten allmänt skyddar en fil är flödet i princip detsamma för innehållsskyddet, förutom att RMS-klienten skapar en princip som ger samtliga rättigheter.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. När filen har använts dekrypteras den innan den skickas till målprogrammet.When the file is consumed, it is decrypted before it is passed to the target application. I det här scenariot kan du skydda alla filer, även om de inte har internt stöd för RMS.This scenario lets you protect all files, even if they don’t natively support RMS.

  • Microsoft-konton: Azure information Protection kan auktorisera e-postadresser för användning när de autentiseras med ett Microsoft-konto.Microsoft accounts: Azure Information Protection can authorize email addresses for consumption when they are authenticated with a Microsoft account. Men alla program kan inte öppna skyddat innehåll när en Microsoft-konto används för autentisering.However, not all applications can open protected content when a Microsoft account is used for authentication. Mer information.More information.

Nästa stegNext steps

Om du vill veta mer om Azure Rights Management-tjänsten kan du läsa de övriga artiklarna i avsnittet Förstå och utforska, till exempel Hur program har stöd för Azure Rights Management-tjänsten för att lära dig hur befintliga program kan integreras med Azure Rights Management i syfte att tillhandahålla en lösning för skydd av information.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.

Gå igenom avsnittet Terminologi för Azure Information Protection så att du är bekant med termer som du kan stöta på när du konfigurerar och använder Azure Rights Management-tjänsten och se även till att gå igenom Krav för Azure Information Protection innan du påbörjar distributionen.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. Om du vill sätta igång direkt och prova själv kan du använda själv studie kursen Redigera principen och skapa en ny etikett .If you want to dive right in and try it out for yourself, use the Edit the policy and create a new label tutorial.

Om du är redo att börja distribuera dataskydd för din organisation går du till Översikt över Azure Information Protection-distribution, som innehåller distributionsstegen och länkar till anvisningar.If you’re ready to start deploying data protection for your organization, use the Azure Information Protection deployment roadmap for your deployment steps and links for how-to instructions.

Tips

Om du behöver ytterligare information och hjälp kan du använda resurserna och länkarna i Information och support för Azure Information Protection.For additional information and help, use the resources and links in Information and support for Azure Information Protection.