Azure RMS nasıl çalışır?How does Azure RMS work? Başlık altındaUnder the hood

Uygulama hedefi: Azure Information Protection, Office 365Applies to: Azure Information Protection, Office 365

Bu veri koruma hizmeti Azure Information Protection, Azure RMS, bu işleyişi hakkında anlamak için önemli bir şey görmez ve verilerinizi koruma işleminin bir parçası depolar.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. Koruduğunuz bilgiler hiçbir zaman gönderilen veya açıkça Azure'da depolamadığınız veya bunları Azure'da depolayan başka bir bulut hizmetini kullanmayı sürece, Azure'da depolanır.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 basitçe, bir belgedeki verileri, yetkili kullanıcıların ve hizmetlerin dışındaki bir kişi için okunamaz hale getirir:Azure RMS simply makes the data in a document unreadable to anyone other than authorized users and services:

  • Veriler, uygulama düzeyinde şifrelenir ve bu belge için yetkili kullanımı tanımlayan bir ilke içerir.The data is encrypted at the application level and includes a policy that defines the authorized use for that document.

  • Korumalı bir belge, meşru bir kullanıcı tarafından kullanıldığında veya yetkili bir hizmet tarafından işlendiğinde, belgedeki verilerin şifresi çözülür ve ilkede tanımlanan haklar uygulanır.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.

Yüksek düzeyde, aşağıdaki resimde bu sürecin nasıl işlediğini görebilirsiniz.At a high level, you can see how this process works in the following picture. Gizli formülü içeren bir belge korunur ve ardından bir yetkili kullanıcı veya hizmet tarafından başarıyla açılır.A document containing the secret formula is protected, and then successfully opened by an authorized user or service. Belge bir içerik anahtarıyla korunur (bu resimdeki yeşil anahtar).The document is protected by a content key (the green key in this picture). Her belge için benzersizdir ve Azure Information Protection kiracı kök anahtarınızla korunan dosya üst bilgisine yerleştirilir (bu resimdeki kırmızı anahtar).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). Kiracı anahtarınız Microsoft tarafından oluşturulabilir ve yönetilebilir ya da kendi kiracı anahtarınızı oluşturabilir ve yönetebilirsiniz.Your tenant key can be generated and managed by Microsoft, or you can generate and manage your own tenant key.

Azure RMS şifreleme ve şifre çözme yetkilendirme yaparken ve kısıtlamalar uygularken gizli formül hiçbir zaman Azure'a gönderilmez koruma işlemi.Throughout the protection process when Azure RMS is encrypting and decrypting, authorizing, and enforcing restrictions, the secret formula is never sent to Azure.

Azure RMS bir dosyayı nasıl korur

Neler olduğunu ayrıntılı açıklaması için bkz Azure RMS'nin çalışmasını gözden geçirme: İlk kullanım, içerik koruma, içerik kullanımı bu makaledeki bir bölüm.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.

Azure RMS’nin kullandığı algoritmalar ve anahtar uzunluklarını hakkında teknik ayrıntılar için, sonraki bölüme bakın.For technical details about the algorithms and key lengths that Azure RMS uses, see the next section.

Azure RMS tarafından kullanılan şifreleme denetimleri: Algoritmalar ve anahtar uzunluklarıCryptographic controls used by Azure RMS: Algorithms and key lengths

Ayrıntılı olarak bu teknolojinin nasıl çalıştığını bilmeniz gerekmez bile, şifreleme denetimleri, kullandığı istenebilir.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. Örneğin, güvenlik koruması endüstri standardında olduğundan emin olmak için.For example, to confirm that the security protection is industry-standard.

Şifreleme denetimleriCryptographic controls Azure RMS’de kullanımUse in Azure RMS
Algoritma: AESAlgorithm: AES

Anahtar uzunluğu: 128 bit ve 256 bit [1]Key length: 128 bits and 256 bits [1]
Belge korumasıDocumentation protection
Algoritma: RSAAlgorithm: RSA

Anahtar uzunluğu: 2048 bit [2]Key length: 2048 bits [2]
Anahtar korumasıKey protection
SHA-256SHA-256 Sertifika imzalamaCertificate signing
Dipnot 1Footnote 1

Azure Information Protection istemcisi ve Rights Management özellikli paylaşım uygulaması, dosya .ppdf dosya adı uzantısına sahip olduğunda veya korumalı bir metin veya görüntü dosyası (.ptxt veya .pjpg gibi) olduğunda genel koruma ve yerel koruma için 256 bit kullanır.256 bits is used by the Azure Information Protection client and the Rights Management sharing application for generic protection and native protection when the file has a .ppdf file name extension or is a protected text or image file (such as .ptxt or .pjpg).

Dipnot 2Footnote 2

Azure Rights Management hizmeti etkinleştirildiğinde anahtar uzunluğu 2048 bit olduğundan.2048 bits is the key length when the Azure Rights Management service is activated. 1024 bit aşağıdaki isteğe bağlı senaryolar için desteklenir:1024 bits is supported for the following optional scenarios:

  • AD RMS kümesi, şifreleme modu 1'de çalışıyorsa, şirket içinden geçiş sırasında.During a migration from on-premises if the AD RMS cluster is running in Cryptographic Mode 1.

  • Şirket içinden AD RMS kümesi, Exchange Online kullanıyorsa, geçişten sonra.After a migration from on-premises, if the AD RMS cluster was using Exchange Online.

  • Azure Rights Management hizmeti tarafından açılması daha önce AD RMS tarafından korunan içeriği devam edebilmesi için yerinde geçiş işleminden önce oluşturulan arşivlenmiş anahtarları geçiş sonrası için.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.

  • Müşteriler Azure Key Vault'u kullanarak kendi anahtarını getirmeyi (KAG) tercih ederse.If customers choose to bring their own key (BYOK) by using Azure Key Vault. Azure Information Protection 1024 bit ve 2048 bit anahtar uzunluklarını destekler.Azure Information Protection supports key lengths of 1024 bits and 2048 bits. Daha yüksek güvenlik için anahtar uzunluğu 2048 bit öneririz.For higher security, we recommend a key length of 2048 bits.

Azure RMS şifreleme anahtarları nasıl depolanır ve güvenli hale getirilir?How the Azure RMS cryptographic keys are stored and secured

Azure RMS tarafından korunan her belge veya e-posta için, Azure RMS tek bir AES anahtarı oluşturur (“içerik anahtarı”) ve bu anahtar, belgeye katıştırılır ve belgenin sürümleriyle devam eder.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.

İçerik anahtarı, belgedeki ilkenin bir parçası olarak kuruluşun RSA anahtarı ile ("Azure Information Protection kiracı anahtarı") korunur. İlke ayrıca, belgeyi yazan tarafından da imzalanır.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. Bu kiracı anahtarı, kuruluş için Azure Rights Management tarafından korunan tüm belgeler ve e-postalar için ortaktır ve bu anahtar yalnızca, kuruluşun müşteri tarafından yönetilen bir kiracı anahtarı kullanması ("kendi anahtarını getir" veya KAG olarak adlandırılır) durumunda bir Azure Information Protection yöneticisi tarafından değiştirilebilir.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).

Bu kiracı anahtarı, Microsoft’un çevrimiçi hizmetlerinde, yüksek düzeyde denetimli bir ortamda ve yakından izlenerek korunmaktadır.This tenant key is protected in Microsoft’s online services, in a highly controlled environment and under close monitoring. Müşteri tarafından yönetilen Kiracı anahtarı (BYOK) kullandığınızda, bu güvenlik bir dizi ayıklanan, dışarı veya altında ayıklanabilmesi anahtarları özelliği olmadan her bir Azure bölgesinde Gelişmiş donanım güvenlik modülleri (HSM'ler) kullanılarak geliştirilir.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. Kiracı anahtarı ve BYOK hakkında daha fazla bilgi için bkz. Azure Rights Management kiracı anahtarınızı planlama ve uygulama.For more information about the tenant key and BYOK, see Planning and implementing your Azure Information Protection tenant key.

Bir Windows cihazına gönderilen lisanslar ve sertifikalar, cihazda bir kullanıcı Azure RMS’yi ilk kullandığında oluşturulan, istemcinin cihaz özel anahtarıyla korunur.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. Bu özel anahtar ise istemci üzerinde DPAPI ile korunur. DPAPI, gizli dizileri kullanıcının parolasından türetilen bir anahtar aracılığıyla korur.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. Mobil cihazlarda, anahtarlar yalnızca bir kez kullanılır, böylelikle istemcilerde depolanmadıklarından, bu anahtarların cihazda korunması gerekmez.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.

Azure RMS'nin çalışmasını gözden geçirme: İlk kullanmak için içerik koruma, içerik kullanımıWalkthrough of how Azure RMS works: First use, content protection, content consumption

Azure RMS’nin çalıştığı hakkında daha ayrıntılı bilgi edinmek için, Azure Rights Management hizmeti etkinleştirildikten sonraki ve bir kullanıcının Rights Management hizmetini Windows bilgisayarında ilk kez kullandığı (bazen kullanıcı ortamını başlatma veya önyükleme olarak da adlandırılan süreç), içeriği koruduğu (bir belgeyi veya e-postayı) ve ardından, başka biri tarafından korunmuş içeriği kullandığı (açtığı ve kullandığı) tipik bir akışı gözden geçirelim.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.

Kullanıcı ortamını başlatıldıktan sonra, o kullanıcı ardından belgeleri koruyabilir veya bu bilgisayarda korunan belgeleri kullanabilir.After the user environment is initialized, that user can then protect documents or consume protected documents on that computer.

Not

Bu kullanıcı başka bir Windows bilgisayara geçerse veya başka bir kullanıcı bu Windows bilgisayarı kullanırsa, başlatma işlemi yinelenir.If this user moves to another Windows computer, or another user uses this same Windows computer, the initialization process is repeated.

Kullanıcı ortamını başlatmaInitializing the user environment

Bir kullanıcının, bir Windows bilgisayarda içerik koruyabilmesi veya korumalı içeriği kullanabilmesi için önce cihazda kullanıcı ortamı hazırlanmalıdır.Before a user can protect content or consume protected content on a Windows computer, the user environment must be prepared on the device. Bu tek seferlik bir işlemdir ve bir kullanıcı, içerik korumaya veya korumalı içeriği kullanmaya çalıştığında, kullanıcı müdahalesi olmadan otomatik olarak gerçekleşir:This is a one-time process and happens automatically without user intervention when a user tries to protect or consume protected content:

RMS İstemcisini etkinleştirme akışı - 1. adım, istemcinin kimliğini doğrulama

1. adımda olanlar: Bilgisayardaki RMS istemcisi önce Azure Rights Management hizmetine bağlanır ve Azure Active Directory hesabını kullanarak kullanıcının kimliğini doğrular.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.

Kullanıcının hesabı Azure Active Directory ile Federasyon olduğunda, bu kimlik doğrulaması otomatiktir ve kullanıcıdan kimlik bilgileri istenmez.When the user’s account is federated with Azure Active Directory, this authentication is automatic and the user is not prompted for credentials.

RMS İstemcisini etkinleştirme - 2. adım, sertifikalar istemciye indirilir

2. adımda olanlar: Kullanıcının kimliği doğrulandıktan sonra bağlantı otomatik olarak kullanıcının kullanmak için Azure Rights Management hizmeti için kimlik doğrulamasını sağlayan sertifikalar korumalı kuruluşun Azure Information Protection kiracısına yönlendirilir İçerik ve içeriği çevrimdışı korumak için.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.

Bu sertifikalar için RAC genellikle kısaltılır hak hesabı sertifikası biridir.One of these certificates is the rights account certificate, often abbreviated to RAC. Bu sertifika, Azure Active Directory kullanıcı kimliğini doğrular ve 31 gün için geçerlidir.This certificate authenticates the user to Azure Active Directory and is valid for 31 day. Sertifika, Azure Active Directory'de yine de kullanıcı hesabıdır ve hesabın etkinleştirilmiş olduğundan RMS İstemci tarafından otomatik olarak yenilenir.The certificate is automatically renewed by the RMS client, providing the user account is still in Azure Active Directory and the account is enabled. Bu sertifika, bir yönetici tarafından yapılandırılabilir değildir.This certificate is not configurable by an administrator.

Bu sertifikanın bir kopyasını Azure'da depolanır, böylece kullanıcı başka bir cihaza geçerse, sertifikalar aynı anahtarlar kullanılarak oluşturulur.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.

İçerik korumaContent protection

Bir kullanıcı bir belgeyi koruduğunda, RMS istemcisi korumasız bir belgede aşağıdaki işlemleri yapar:When a user protects a document, the RMS client takes the following actions on an unprotected document:

RMS belge koruması - 1. adım, belge şifrelenir

1. adımda olanlar: RMS istemcisi, rastgele bir anahtar (içerik anahtarı) oluşturur ve bir AES simetrik şifreleme algoritması bu anahtarı kullanarak belgeyi şifreler.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 belge koruması - 2. adım, ilke oluşturulur

2. adımda olanlar: RMS istemcisi ardından içeren belge için bir ilke içeren bir sertifika oluşturur kullanım hakları kullanıcıları veya grupları ve sona erme tarihi gibi diğer kısıtlamaları için.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. Bu ayarlar, yöneticinin önceden yapılandırılmış veya içeriğin korunduğu zaman (bazen bir "geçici ilke" olarak adlandırılır) belirtilen bir şablon içinde tanımlanabilir.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").

Seçili kullanıcılar ve grupları tanımlamak için kullanılan ana Azure AD özniteliği, bir kullanıcı veya grup için tüm e-posta adreslerini depolayan Azure AD ProxyAddresses özniteliğidir.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. Ancak bir kullanıcı hesabının AD ProxyAddresses özniteliğinde herhangi bir değer yoksa bunun yerine kullanıcının UserPrincipalName değeri kullanılır.However, if a user account doesn't have any values in the AD ProxyAddresses attribute, the user's UserPrincipalName value is used instead.

RMS istemcisi ardından, kullanıcı ortamı başlatıldığında edinilen kuruluş anahtarını kullanır ve bu anahtarı, ilkeyi ve simetrik içerik anahtarını şifrelemek için kullanır.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 istemcisi ayrıca, ilkeyi, kullanıcı ortamı başlatıldığında edinilen kullanıcı sertifikasıyla imzalar.The RMS client also signs the policy with the user’s certificate that was obtained when the user environment was initialized.

RMS belge koruması - 3. adım, ilke belgeye eklenir

3. adımda olanlar: Son olarak, RMs istemcisi, ilkeyi bir dosyaya birlikte korumalı bir belgeyi oluşturan gövdesi daha önce şifrelenmiş bir belge ile katıştırır.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.

Bu belge herhangi bir yerde depolanabilir veya herhangi bir yöntem kullanılarak paylaşılabilir ve ilke her zaman şifreli belgeyle kalır.This document can be stored anywhere or shared by using any method, and the policy always stays with the encrypted document.

İçerik tüketimiContent consumption

Bir kullanıcı, korumalı bir belgeyi kullanmak istediğinde RMS istemcisi öncelikle Azure Rights Management hizmetine erişim izni ister:When a user wants to consume a protected document, the RMS client starts by requesting access to the Azure Rights Management service:

RMS belge tüketimi - 1. adım, kullanıcının kimliği doğrulanır ve kullanıcı, haklar listesine alınır

1. adımda olanlar: Kimliği doğrulanmış kullanıcı belge ilkesini ve kullanıcı sertifikalarını Azure Rights Management hizmetine gönderir.What's happening in step 1: The authenticated user sends the document policy and the user’s certificates to the Azure Rights Management service. Hizmet ilkenin şifresini çözer ve ilkeyi değerlendirir ve kullanıcının belge için sahip olduğu hakların bir listesini (varsa) derler.The service decrypts and evaluates the policy, and builds a list of rights (if any) the user has for the document. Kullanıcıyı tanımlamak amacıyla kullanıcının hesabı ve üyesi olduğu gruplar için Azure AD ProxyAddresses özniteliği kullanılır.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. Performansla ilgili nedenlerden dolayı, grup üyeliği önbelleğe alınır.For performance reasons, group membership is cached. Kullanıcı hesabının Azure AD ProxyAddresses özniteliğinde hiçbir değer yoksa bunun yerine Azure AD UserPrincipalName değeri kullanılır.If the user account has no values for the Azure AD ProxyAddresses attribute, the value in the Azure AD UserPrincipalName is used instead.

RMS belge tüketimi - 2. adım, kullanım lisansı istemciye döndürülür

2. adımda olanlar: Hizmet, ardından şifresi çözülmüş ilkeden AES içerik anahtarını ayıklar.What's happening in step 2: The service then extracts the AES content key from the decrypted policy. Bu anahtar ardından, kullanıcının istekle edinilen ortak RSA anahtarıyla şifrelenir.This key is then encrypted with the user’s public RSA key that was obtained with the request.

Yeniden şifrelenmiş içerik anahtarı ardından, kullanıcı hakları olan şifrelenmiş kullanım lisansı içine katıştırılır, bu ardından RMS istemcisine geri gönderilir.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 belge tüketimi - 3. adım, belgenin şifresi çözülür ve haklar zorlanır

3. adımda olanlar: Son olarak, RMS istemcisi, şifrelenmiş kullanım lisansını alır ve kendi kullanıcı özel anahtarıyla bunun şifresini çözer.What's happening in step 3: Finally, the RMS client takes the encrypted use license and decrypts it with its own user private key. Bu, RMS istemcisinin, gerektiğinde belgenin gövdesinin şifresini çözmesini ve ekranda işlemesini sağlar.This lets the RMS client decrypt the document’s body as it is needed and render it on the screen.

İstemci ayrıca, haklar listesinin şifresini çözer ve bunları uygulamaya geçirir, böylelikle bu haklar uygulamanın kullanıcı arabiriminde uygulanır.The client also decrypts the rights list and passes them to the application, which enforces those rights in the application’s user interface.

Not

Kuruluşunuzun dışında kalan kullanıcılar koruduğunuz içeriği tükettiğinde, tüketim akışı aynı kalır.When users who are external to your organization consume content that you've protected, the consumption flow is the same. Kullanıcı kimliğinin nasıl doğrulandığı bu senaryoyu değiştirir.What changes for this scenario, is how the user is authenticated. Daha fazla bilgi için bkz. Korumalı bir belgeyi şirketimin dışındaki biriyle paylaştığımda, bu kullanıcının kimlik doğrulaması nasıl yapılır?For more information, see When I share a protected document with somebody outside my company, how does that user get authenticated?

FarklılıklarVariations

Önceki gözden geçirmelerde standart senaryolar ele alınır, ancak bazı farklılıklar vardır:The preceding walkthroughs cover the standard scenarios but there are some variations:

  • E-posta koruma: Exchange Online ve Office 365 ileti şifreleme yeni özelliklere sahip e-posta mesajlarını korumak için kullanıldığında, tüketim için kimlik doğrulaması bir sosyal kimlik sağlayıcısı ile veya bir kerelik geçiş kodu kullanarak da Federasyon kullanabilirsiniz.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. Ardından, içerik kullanımı Hizmet tarafı web tarayıcı oturumunda giden e-posta geçici olarak önbelleğe alınan bir kopyası üzerinde gerçekleşmesi dışında işlem akışları çok benzer.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.

  • Mobil cihazları: Mobil cihazları korumak veya dosya Azure Rights Management hizmeti ile kullanma, işlem akışları çok daha basittir.Mobile devices: When mobile devices protect or consume files with the Azure Rights Management service, the process flows are much simpler. Mobil cihazlar önce kullanıcı başlatma sürecinden geçmez, çünkü bunun yerine, her işlem (içerik korumak veya kullanmak için) bağımsızdır.Mobile devices don’t first go through the user initialization process because instead, each transaction (to protect or consume content) is independent. Windows bilgisayarlarında olduğu gibi mobil cihazlar da Azure Rights Management hizmetine bağlanır ve cihazların kimliği doğrulanır.As with Windows computers, mobile devices connect to the Azure Rights Management service and authenticate. Mobil cihazlar içeriği korumak için bir ilke gönderir ve Azure Rights Management hizmeti, belgeyi korumak için cihazlara bir yayımlama lisansı ve simetrik anahtar gönderir.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. Mobil cihazlar içeriği kullanmak için, Azure Rights Management hizmetine bağlanıp kimlikleri doğruladıktan sonra belge ilkesini Azure Rights Management hizmetine gönderir ve belgeyi kullanmak için kullanım lisansı ister.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. Azure Rights Management hizmeti yanıt olarak, mobil cihazlara gerekli anahtarları ve kısıtlamaları gönderir.In response, the Azure Rights Management service sends the necessary keys and restrictions to the mobile devices. Her iki işlem, anahtar değişimini ve diğer iletişimleri korumak üzere TLS kullanır.Both processes use TLS to protect the key exchange and other communications.

  • RMS bağlayıcısını: Azure Rights Management hizmeti RMS Bağlayıcısı ile kullanıldığında işlem akışları aynı kalır.RMS connector: When the Azure Rights Management service is used with the RMS connector, the process flows remain the same. Tek fark, bağlayıcının şirket içi hizmetler (Exchange Server ve SharePoint Server gibi) ve Azure Rights Management hizmeti arasında bir geçiş işlevi görmesidir.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. Bağlayıcının kendisi, kullanıcı ortamının başlatılması veya şifreleme ya da şifre çözüme gibi herhangi bir işlem gerçekleştirmez.The connector itself does not perform any operations, such as the initialization of the user environment, or encryption or decryption. Yalnızca, genellikle her bir tarafta kullanılan protokoller arasındaki çeviriyi işleme bir AD RMS sunucusuna gidecek iletişimi geçirir.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. Bu senaryo, şirket içi hizmetlerle Azure Rights Management hizmetini kullanmanızı sağlar.This scenario lets you use the Azure Rights Management service with on-premises services.

  • Genel korumalı (.pfile): Azure Rights Management hizmetine genel bir dosyayı koruduğunda RMS istemcisinin tüm hakları veren bir ilke oluşturması dışında akışın temel içerik koruması için aynıdır.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. Dosya kullanıldığında, hedef uygulamaya geçirilmeden önce şifresi çözülür.When the file is consumed, it is decrypted before it is passed to the target application. Bu senaryo, RMS’yi yerel olarak desteklemeseler dahi tüm dosyaları korumanıza olanak sağlar.This scenario lets you protect all files, even if they don’t natively support RMS.

  • Korumalı PDF (.ppdf): Azure Rights Management hizmeti bir Office dosyasını yerel olarak koruduğunda, ayrıca bu dosyanın bir kopyasını oluşturur ve onu aynı şekilde korur.Protected PDF (.ppdf): When the Azure Rights Management service natively protects an Office file, it also creates a copy of that file and protects it in the same way. Tek fark, dosyanın kopyasının Azure Information Protection istemcisi görüntüleyicisi ve RMS sharing uygulamasının yalnızca görüntüleme için açabildiği PPDF dosya biçiminde olmasıdır.The only difference is that the file copy is in PPDF file format, which the Azure Information Protection client viewer and the RMS sharing application knows how to open for viewing only. Korumalı Office dosyalarını mobil cihazın yerel olarak destekleyen bir uygulama olmasa bile bir mobil cihazdaki alıcının her zaman okuyabilirsiniz olduğunu bilmenin verdiği e-posta ile korumalı ekler gönderdiğiniz bu senaryo sağlar.This scenario lets you send protected attachments via email, knowing that the recipient on a mobile device can always read them even if the mobile device doesn’t have an app that natively supports protected Office files.

  • Microsoft hesapları: Azure Information Protection, bir Microsoft hesabıyla kimlik doğrulaması gerçekleştirdiğinizde e-posta adreslerini tüketim için yetki verebilir.Microsoft accounts: Azure Information Protection can authorize email addresses for consumption when they are authenticated with a Microsoft account. Ancak, bir Microsoft hesabı kimlik doğrulaması için kullanıldığında, tüm uygulamalar korumalı içeriği açabildiklerini.However, not all applications can open protected content when a Microsoft account is used for authentication. Daha fazla bilgi.More information.

Sonraki adımlarNext steps

Azure Rights Management hizmeti hakkında daha fazla bilgi için diğer makaleleri kullanın anlama ve keşfetme bölümündeki uygulamalar Azure Rights Management hizmetini nasıl destekler? öğrenin nasıl mevcut uygulamalarınızı bilgi koruma çözümü sağlamak için Azure Rights Management ile tümleştirebilirsiniz.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.

Azure Rights Management hizmetini yapılandırırken ve kullanırken karşılaşabileceğiniz terimleri öğrenmek için Azure Information Protection terminolojisini gözden geçirin ve dağıtımınıza başlamadan önce Azure Information Protection gereksinimlerini incelemeyi unutmayın.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. Hemen başlamak istiyorsanız ve kendiniz denemek, kullanın ilkeyi düzenleyebilir ve yeni etiket oluşturma öğretici.If you want to dive right in and try it out for yourself, use the Edit the policy and create a new label tutorial.

Kuruluşunuzda veri koruma dağıtımına başlamaya hazırsanız, dağıtım adımlar için Azure Information Protection dağıtım yol haritasını ve uygulama yönergeleri için bağlantıları kullanın.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.

İpucu

Ek bilgi ve yardım için Azure Information Protection için bilgi ve destek konusunda yer alan kaynakları ve bağlantıları kullanın.For additional information and help, use the resources and links in Information and support for Azure Information Protection.