Azure RMS nasıl çalışır? Temel bileşenler

Azure RMS'nin nasıl çalıştığı hakkında anlaşılması gereken önemli bir şey, Azure Information Protection'dan gelen bu veri koruma hizmetinin verilerinizi koruma işleminin bir parçası olarak görmemesi veya depolamamasıdır. Açıkça Azure'da depolamadığınız veya Azure'da depolayan başka bir bulut hizmeti kullanmadığınız sürece, koruduğunuz bilgiler hiçbir zaman Azure'a gönderilmez veya Azure'da depolanmaz. Azure RMS, belgedeki verileri yetkili kullanıcılar ve hizmetler dışındaki herkes için okunamaz hale getirir:

• Veriler uygulama düzeyinde şifrelenir ve bu belge için yetkili kullanımı tanımlayan bir ilke içerir.

• 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 zorlanır.

Üst düzeyde, bu işlemin nasıl çalıştığını aşağıdaki resimde görebilirsiniz. Gizli dizi formülünü içeren bir belge korunur ve yetkili bir kullanıcı veya hizmet tarafından başarıyla açılır. Belge bir içerik anahtarıyla (bu resimdeki yeşil anahtar) korunur. Her belge için benzersizdir ve Azure Information Protection kiracı kök anahtarınız (bu resimdeki kırmızı anahtar) tarafından korunduğu dosya üst bilgisine yerleştirilir. Kiracı anahtarınız Microsoft tarafından oluşturulabilir ve yönetilebilir veya kendi kiracı anahtarınızı oluşturup yönetebilirsiniz.

Azure RMS kısıtlamaları şifreleyip şifrelerini çözüyor, yetkilendiriliyor ve kısıtlanıyorsa koruma işlemi boyunca gizli formül hiçbir zaman Azure'a gönderilmez.

Neler olduğuna ilişkin ayrıntılı bir açıklama için bu makalenin Azure RMS'nin nasıl çalıştığına ilişkin kılavuz: İlk kullanım, içerik koruma, içerik tüketimi bölümüne bakın.

Azure RMS'nin kullandığı algoritmalar ve anahtar uzunlukları hakkında teknik ayrıntılar için sonraki bölüme bakın.

Azure RMS tarafından kullanılan şifreleme denetimleri: Algoritmalar ve anahtar uzunlukları

Bu teknolojinin nasıl çalıştığını ayrıntılı olarak bilmeniz gerekmiyor olsa bile, kullandığı şifreleme denetimleri hakkında size sorulabilir. Örneğin, güvenlik korumasının endüstri standardı olduğunu onaylamak için.

Dipnot 1

Aşağıdaki senaryolarda Azure Information Protection istemcisi tarafından 256 bit kullanılır:

• Genel koruma (.pfile).

• Belge PDF şifrelemesi için ISO standardıyla korunduğunda veya sonuçta elde edilen korumalı belgede .ppdf dosya adı uzantısı olduğunda PDF belgeleri için yerel koruma.

• Metin veya görüntü dosyaları (.ptxt veya .pjpg gibi) için yerel koruma.

Dipnot 2

2048 bit, Azure Rights Management hizmeti etkinleştirildiğinde anahtar uzunluğudur. Aşağıdaki isteğe bağlı senaryolar için 1024 bit desteklenir:

• AD RMS kümesi Şifreleme Modu 1'de çalışıyorsa şirket içinden geçiş sırasında.

• Daha önce AD RMS tarafından korunan içeriğin geçiş sonrasında Azure Rights Management hizmeti tarafından açılmaya devam edebilmesi için, geçiş öncesinde şirket içinde oluşturulan arşivlenmiş anahtarlar için.

Azure RMS şifreleme anahtarlarının depolanması ve güvenliğinin sağlanması

Azure RMS tarafından korunan her belge veya e-posta için, Azure RMS tek bir AES anahtarı ("içerik anahtarı") oluşturur ve bu anahtar belgeye eklenir ve belgenin sürümleri aracılığıyla kalıcı hale gelir.

İçerik anahtarı, belgedeki ilkenin bir parçası olarak kuruluşun RSA anahtarıyla ("Azure Information Protection kiracı anahtarı") korunur ve ilke belgenin yazarı tarafından da imzalanır. Bu kiracı anahtarı, kuruluş için Azure Rights Management hizmeti tarafından korunan tüm belgeler ve e-postalar için ortaktır ve bu anahtar yalnızca kuruluş müşteri tarafından yönetilen ("kendi anahtarını getir" veya BYOK olarak bilinir) bir kiracı anahtarı kullanıyorsa Azure Information Protection yöneticisi tarafından değiştirilebilir.

Bu kiracı anahtarı, Microsoft'un çevrimiçi hizmetler, yüksek denetimli bir ortamda ve yakın izleme altında korunur. Müşteri tarafından yönetilen bir kiracı anahtarı (BYOK) kullandığınızda bu güvenlik, anahtarların herhangi bir koşulda ayıklanması, dışarı aktarılması veya paylaşılması özelliği olmadan her Azure bölgesinde bir dizi üst düzey donanım güvenlik modülü (HSM) kullanılmasıyla geliştirilir. Kiracı anahtarı ve KAG hakkında daha fazla bilgi için bkz . Azure Information Protection kiracı anahtarınızı planlama ve uygulama.

Bir Windows cihazına gönderilen lisanslar ve sertifikalar, istemcinin cihaz özel anahtarıyla korunur ve bu anahtar, cihazdaki bir kullanıcı Azure RMS'yi ilk kez kullandığında oluşturulur. Bu özel anahtar da istemcide DPAPI ile korunur ve bu gizli dizileri kullanıcının parolasından türetilen bir anahtar kullanarak korur. Mobil cihazlarda anahtarlar yalnızca bir kez kullanılır, bu nedenle istemcilerde depolanmadıkları için bu anahtarların cihazda korunması gerekmez.

Azure RMS'nin nasıl çalıştığına ilişkin izlenecek yol: İlk kullanım, içerik koruması, içerik tüketimi

Azure RMS'nin nasıl çalıştığını daha ayrıntılı olarak anlamak için Azure Rights Management hizmeti etkinleştirildikten sonra ve bir kullanıcı Kendi Windows bilgisayarında Rights Management hizmetini ilk kez kullandığında (bazen kullanıcı ortamını başlatma veya önyükleme olarak bilinen bir işlem), içeriği (belge veya e-posta) koruyup başka biri tarafından korunan içeriği (açar ve kullanır) genel bir akışa göz atalım.

Kullanıcı ortamı başlatıldıktan sonra, bu kullanıcı belgeleri koruyabilir veya bu bilgisayardaki korumalı belgeleri kullanabilir.

Kullanıcı ortamını başlatma

Bir kullanıcının windows bilgisayarda içeriği koruyabilmesi veya korumalı içeriği kullanabilmesi için önce kullanıcı ortamının cihazda hazırlanması gerekir. Bu tek seferlik bir işlemdir ve kullanıcı korumalı içeriği korumaya veya tüketmeye çalıştığında kullanıcı müdahalesi olmadan otomatik olarak gerçekleşir:

1. adımda olanlar: Bilgisayardaki RMS istemcisi önce Azure Rights Management hizmetine bağlanır ve Microsoft Entra hesabını kullanarak kullanıcının kimliğini doğrular.

Kullanıcının hesabı Microsoft Entra Id ile birleştirilirse, bu kimlik doğrulaması otomatiktir ve kullanıcıdan kimlik bilgileri istenmez.

2. adımda olanlar: Kullanıcının kimliği doğrulandıktan sonra, bağlantı otomatik olarak kuruluşun Azure Information Protection kiracısına yönlendirilir ve bu kiracı, korumalı içeriği kullanmak ve içeriği çevrimdışı korumak için kullanıcının Azure Rights Management hizmetinde kimlik doğrulaması yapmasına olanak tanıyan sertifikalar verir.

Bu sertifikalardan biri, genellikle RAC olarak kısaltılan hak hesabı sertifikasıdır. Bu sertifika, kullanıcının kimliğini Microsoft Entra Kimliği'ne doğrular ve 31 gün boyunca geçerlidir. Kullanıcı hesabının hala Microsoft Entra Id'de olması ve hesabın etkinleştirilmesi halinde sertifika RMS istemcisi tarafından otomatik olarak yenilenir. Bu sertifika bir yönetici tarafından yapılandırılamaz.

Bu sertifikanın bir kopyası Azure'da depolanır, böylece kullanıcı başka bir cihaza geçerse sertifikalar aynı anahtarlar kullanılarak oluşturulur.

İçerik koruma

Kullanıcı bir belgeyi koruduğunda, RMS istemcisi korumasız bir belgede aşağıdaki eylemleri gerçekleştirir:

1. adımda olanlar: RMS istemcisi rastgele bir anahtar (içerik anahtarı) oluşturur ve AES simetrik şifreleme algoritmasıyla bu anahtarı kullanarak belgeyi şifreler.

2. adımda neler oluyor: RMS istemcisi daha sonra, belge için kullanıcılar veya gruplar için kullanım haklarını ve son kullanma tarihi gibi diğer kısıtlamaları içeren bir ilke içeren bir sertifika oluşturur. Bu ayarlar, bir yöneticinin daha önce yapılandırdığı veya içeriğin korunduğu sırada belirtilen bir şablonda tanımlanabilir (bazen "geçici ilke" olarak da adlandırılır).

Seçilen kullanıcıları ve grupları tanımlamak için kullanılan ana Microsoft Entra özniteliği, bir kullanıcı veya grubun tüm e-posta adreslerini depolayan Microsoft Entra ProxyAddresses özniteliğidir. Ancak, bir kullanıcı hesabının AD ProxyAddresses özniteliğinde herhangi bir değeri yoksa, bunun yerine kullanıcının UserPrincipalName değeri kullanılır.

RMS istemcisi daha sonra kullanıcı ortamı başlatıldığında elde edilen kuruluşun anahtarını kullanır ve ilkeyi ve simetrik içerik anahtarını şifrelemek için bu anahtarı kullanır. RMS istemcisi ayrıca ilkeyi, kullanıcı ortamı başlatıldığında alınan kullanıcının sertifikasıyla imzalar.

3. adımda neler oluyor: Son olarak, RMS istemcisi ilkeyi daha önce şifrelenmiş belge gövdesiyle birlikte korumalı bir belgeyi oluşturan bir dosyaya ekler.

Bu belge herhangi bir yerde depolanabilir veya herhangi bir yöntem kullanılarak paylaşılabilir ve ilke her zaman şifrelenmiş belgeyle kalır.

İçerik tüketimi

Kullanıcı korumalı bir belge kullanmak istediğinde, RMS istemcisi Azure Rights Management hizmetine erişim isteyerek başlar:

1. adımda neler oluyor: Kimliği doğrulanmış kullanıcı, belge ilkesini ve kullanıcının sertifikalarını Azure Rights Management hizmetine gönderir. Hizmet, ilkenin şifresini çözer ve değerlendirir ve kullanıcının belge için sahip olduğu hakların (varsa) bir listesini oluşturur. Kullanıcıyı tanımlamak için, kullanıcının hesabı ve üyesi olduğu gruplar için Microsoft Entra ProxyAddresses özniteliği kullanılır. Performans nedeniyle grup üyeliği önbelleğe alınır. Kullanıcı hesabında Microsoft Entra ProxyAddresses özniteliği için değer yoksa, bunun yerine Microsoft Entra UserPrincipalName içindeki değer kullanılır.

2. adımda neler oluyor: Hizmet daha sonra şifresi çözülen ilkeden AES içerik anahtarını ayıklar. Bu anahtar daha sonra kullanıcının istekle elde edilen genel RSA anahtarıyla şifrelenir.

Yeniden şifrelenmiş içerik anahtarı, daha sonra RMS istemcisine döndürülen kullanıcı hakları listesiyle şifrelenmiş kullanım lisansına eklenir.

3. adımda olanlar: Son olarak, RMS istemcisi şifrelenmiş kullanım lisansını alır ve kendi kullanıcı özel anahtarıyla şifresini çözer. Bu, RMS istemcisinin gerektiğinde belgenin gövdesinin şifresini çözmesini ve ekranda işlemesini sağlar.

İstemci ayrıca hak listesinin şifresini çözer ve bu hakları uygulamanın kullanıcı arabiriminde zorlayan uygulamaya geçirir.

Varyasyon -ları

Yukarıdaki kılavuzlar standart senaryoları kapsar ancak bazı varyasyonlar vardır:

• E-posta koruması: E-posta iletilerini korumak için yeni özelliklerle Exchange Online ve Office 365 İleti Şifrelemesi kullanıldığında, tüketim için kimlik doğrulaması bir sosyal kimlik sağlayıcısıyla federasyon veya tek seferlik geçiş kodu kullanarak da kullanılabilir. Ardından, içerik tüketiminin giden e-postanın geçici olarak önbelleğe alınmış bir kopyası üzerinden web tarayıcısı oturumunda hizmet tarafında gerçekleşmesi dışında işlem akışları çok benzerdir.

• Mobil cihazlar: Mobil cihazlar Azure Rights Management hizmetiyle dosyaları koruduğunda veya tükettiğinde, işlem akışları çok daha basittir. Mobil cihazlar önce kullanıcı başlatma işleminden geçmez, çünkü bunun yerine her işlem (içeriği korumak veya kullanmak için) bağımsızdır. Windows bilgisayarlarda olduğu gibi mobil cihazlar da Azure Rights Management hizmetine bağlanır ve kimlik doğrulaması yapar. İçeriği korumak için mobil cihazlar bir ilke gönderir ve Azure Rights Management hizmeti belgeyi korumak için onlara yayımlama lisansı ve simetrik anahtar gönderir. İçeriği kullanmak için, mobil cihazlar Azure Rights Management hizmetine bağlandığında ve kimlik doğrulaması yaptıklarında, belge ilkesini Azure Rights Management hizmetine gönderir ve belgeyi kullanmak için bir kullanım lisansı talep ederler. Buna yanıt olarak, Azure Rights Management hizmeti gerekli anahtarları ve kısıtlamaları mobil cihazlara gönderir. Her iki işlem de anahtar değişimini ve diğer iletişimleri korumak için TLS kullanır.

• RMS bağlayıcısı: Azure Rights Management hizmeti RMS bağlayıcısı ile kullanıldığında, işlem akışları aynı kalır. Tek fark, bağlayıcının şirket içi hizmetler (Exchange Server ve SharePoint Server gibi) ile Azure Rights Management hizmeti arasında geçiş görevi üstlenmesidir. Bağlayıcının kendisi, kullanıcı ortamının başlatılması veya şifreleme veya şifre çözme gibi herhangi bir işlem gerçekleştirmez. Yalnızca genellikle bir AD RMS sunucusuna gidecek iletişimi aktarır ve her iki tarafta kullanılan protokoller arasındaki çeviriyi işler. Bu senaryo, Azure Rights Management hizmetini şirket içi hizmetlerle kullanmanıza olanak tanır.

• Genel koruma (.pfile): Azure Rights Management hizmeti bir dosyayı genel olarak koruduğunda, rms istemcisinin tüm hakları veren bir ilke oluşturması dışında akış temelde içerik koruması için aynıdır. Dosya tüketildiğinde, hedef uygulamaya geçirilmeden önce şifresi çözülür. Bu senaryo, RMS'yi yerel olarak desteklemeseler bile tüm dosyaları korumanıza olanak tanır.

• Microsoft hesapları: Azure Information Protection, bir Microsoft hesabıyla kimlik doğrulaması yapıldığında e-posta adreslerini tüketim için yetkilendirir. Ancak, kimlik doğrulaması için bir Microsoft hesabı kullanıldığında tüm uygulamalar korumalı içeriği açamayabilir. Daha fazla bilgi.

Sonraki adımlar

Azure Rights Management hizmeti hakkında daha fazla bilgi edinmek için, bilgi koruma çözümü sağlamak üzere mevcut uygulamalarınızın Azure Rights Management ile nasıl tümleşebileceğini öğrenmek için, Uygulamalarınız Azure Rights Management hizmetini nasıl destekler? gibi Anlama ve Araştırma bölümündeki diğer makaleleri kullanın.

Azure Rights Management hizmetini yapılandırırken ve kullanırken karşılaşabileceğiniz terimleri öğrenmek için Azure Information Protection Terminolojisi'ni gözden geçirin ve dağıtımınıza başlamadan önce Azure Information Protection Gereksinimleri'ni de kontrol edin. Doğrudan dalmak ve kendiniz denemek istiyorsanız hızlı başlangıcı ve öğreticileri kullanın:

• Hızlı Başlangıç: Birleşik etiketleme istemcisini dağıtma
• Öğretici: Azure Information Protection (AIP) birleşik etiketleme tarayıcısını yükleme
• Öğretici: Azure Information Protection (AIP) tarayıcısıyla hassas içeriğinizi bulma
• Öğretici: Azure Information Protection (AIP) kullanarak Outlook'ta fazla paylaşımı önleme

Kuruluşunuz için veri korumasını dağıtmaya başlamaya hazırsanız, dağıtım adımlarınız için sınıflandırma, etiketleme ve koruma için AIP dağıtım yol haritasını ve nasıl yapılır yönergeleri için bağlantıları kullanın.