Udostępnij za pośrednictwem


Jak działa usługa Azure RMS? Under the hood (Za kulisami usługi Azure RMS — działanie)

Ważne jest, aby zrozumieć, jak działa usługa Azure RMS, jest to, że ta usługa ochrony danych z usługi Azure Information Protection nie widzi ani nie przechowuje danych w ramach procesu ochrony. Informacje chronione nigdy nie są wysyłane do platformy Azure ani przechowywane na platformie Azure, chyba że jawnie zapiszesz je na platformie Azure lub użyjesz innej usługi w chmurze, która przechowuje je na platformie Azure. Usługa Azure RMS po prostu sprawia, że dane w dokumencie są nieczytelne dla każdego innego niż autoryzowani użytkownicy i usługi:

  • Dane są szyfrowane na poziomie aplikacji i zawierają zasady definiujące autoryzowane użycie tego dokumentu.

  • Gdy chroniony dokument jest używany przez uprawnionego użytkownika lub jest przetwarzany przez autoryzowaną usługę, dane w dokumencie są odszyfrowywane, a prawa zdefiniowane w zasadach są wymuszane.

Na wysokim poziomie można zobaczyć, jak działa ten proces na poniższej ilustracji. Dokument zawierający formułę wpisu tajnego jest chroniony, a następnie pomyślnie otwarty przez autoryzowanego użytkownika lub usługę. Dokument jest chroniony przez klucz zawartości (zielony klucz na tym obrazie). Jest on unikatowy dla każdego dokumentu i jest umieszczany w nagłówku pliku, w którym jest chroniony przez klucz główny dzierżawy usługi Azure Information Protection (czerwony klucz na tym obrazie). Klucz dzierżawy można wygenerować i zarządzać nim przez firmę Microsoft lub wygenerować własny klucz dzierżawy i zarządzać nim.

W całym procesie ochrony, gdy usługa Azure RMS szyfruje i odszyfrowuje, autoryzuje i wymusza ograniczenia, formuła wpisu tajnego nigdy nie jest wysyłana na platformę Azure.

Jak usługa Azure RMS chroni plik

Aby uzyskać szczegółowy opis tego, co się dzieje, zobacz sekcję Przewodnik po sposobie działania usługi Azure RMS: pierwsze użycie, ochrona zawartości, zużycie zawartości w tym artykule.

Aby uzyskać szczegółowe informacje techniczne dotyczące algorytmów i długości kluczy używanych przez usługę Azure RMS, zobacz następną sekcję.

Kontrolki kryptograficzne używane przez usługę Azure RMS: algorytmy i długości kluczy

Nawet jeśli nie musisz szczegółowo wiedzieć, jak działa ta technologia, możesz zapytać o formanty kryptograficzne, których używa. Na przykład w celu potwierdzenia, że ochrona zabezpieczeń jest standardem branżowym.

Kontrolki kryptograficzne Używanie w usłudze Azure RMS
Algorytm: AES

Długość klucza: 128 bitów i 256 bitów [1]
Ochrona zawartości
Algorytm: RSA

Długość klucza: 2048 bitów [2]
Ochrona klucza
SHA-256 Podpisywanie certyfikatu
Przypis 1

Klient usługi Azure Information Protection używa 256 bitów w następujących scenariuszach:

  • Ochrona ogólna (pfile).

  • Natywna ochrona dokumentów PDF, gdy dokument jest chroniony przy użyciu standardu ISO dla szyfrowania PLIKÓW PDF lub wynikowy chroniony dokument ma rozszerzenie nazwy ppdf.

  • Natywna ochrona plików tekstowych lub obrazów (takich jak ptxt lub pjpg).

Przypis 2

2048 bitów to długość klucza po aktywowaniu usługi Azure Rights Management. 1024 bity są obsługiwane w następujących scenariuszach opcjonalnych:

  • Podczas migracji ze środowiska lokalnego, jeśli klaster usług AD RMS jest uruchomiony w trybie kryptograficznym 1.

  • W przypadku zarchiwizowanych kluczy utworzonych lokalnie przed migracją, dzięki czemu zawartość, która była wcześniej chroniona przez usługi AD RMS, może być nadal otwierana przez usługę Azure Rights Management po migracji.

Sposób przechowywania i zabezpieczania kluczy kryptograficznych usługi Azure RMS

Dla każdego dokumentu lub wiadomości e-mail chronionej przez usługę Azure RMS usługa Azure RMS tworzy pojedynczy klucz AES ("klucz zawartości"), a ten klucz jest osadzony w dokumencie i jest utrwalany w wersjach dokumentu.

Klucz zawartości jest chroniony za pomocą klucza RSA organizacji (klucza dzierżawy usługi Azure Information Protection) w ramach zasad w dokumencie, a zasady są również podpisane przez autora dokumentu. Ten klucz dzierżawy jest wspólny dla wszystkich dokumentów i wiadomości e-mail chronionych przez usługę Azure Rights Management dla organizacji, a ten klucz można zmienić tylko przez administratora usługi Azure Information Protection, jeśli organizacja korzysta z klucza dzierżawy zarządzanego przez klienta (znanego jako "bring your own key" lub BYOK).

Ten klucz dzierżawy jest chroniony w Usługi online firmy Microsoft w wysoce kontrolowanym środowisku i w ramach ścisłego monitorowania. W przypadku korzystania z klucza dzierżawy zarządzanego przez klienta (BYOK) to zabezpieczenia są zwiększane przez użycie tablicy wysokiej klasy sprzętowych modułów zabezpieczeń (HSM) w każdym regionie platformy Azure bez możliwości wyodrębniania, eksportowania lub udostępniania kluczy w dowolnych okolicznościach. Aby uzyskać więcej informacji na temat klucza dzierżawy i rozwiązania BYOK, zobacz Planowanie i wdrażanie klucza dzierżawy usługi Azure Information Protection.

Licencje i certyfikaty wysyłane do urządzenia z systemem Windows są chronione przy użyciu klucza prywatnego urządzenia klienta, który jest tworzony po raz pierwszy przez użytkownika na urządzeniu przy użyciu usługi Azure RMS. Ten klucz prywatny jest z kolei chroniony za pomocą interfejsu DPAPI na kliencie, który chroni te wpisy tajne przy użyciu klucza pochodzącego z hasła użytkownika. Na urządzeniach przenośnych klucze są używane tylko raz, więc ponieważ nie są przechowywane na klientach, te klucze nie muszą być chronione na urządzeniu.

Przewodnik po sposobie działania usługi Azure RMS: pierwsze użycie, ochrona zawartości, użycie zawartości

Aby dowiedzieć się bardziej szczegółowo, jak działa usługa Azure RMS, zapoznajmy się z typowym przepływem po aktywowaniu usługi Azure Rights Management, a gdy użytkownik najpierw korzysta z usługi Rights Management na komputerze z systemem Windows (proces znany czasami jako inicjowanie środowiska użytkownika lub bootstrapping), chroni zawartość (dokument lub wiadomość e-mail), a następnie używa (otwiera i używa) zawartości chronionej przez inną osobę.

Po zainicjowaniu środowiska użytkownika użytkownik może następnie chronić dokumenty lub korzystać z chronionych dokumentów na tym komputerze.

Uwaga

Jeśli ten użytkownik przejdzie na inny komputer z systemem Windows lub inny użytkownik korzysta z tego samego komputera z systemem Windows, proces inicjowania zostanie powtórzony.

Inicjowanie środowiska użytkownika

Aby użytkownik mógł chronić zawartość lub korzystać z chronionej zawartości na komputerze z systemem Windows, środowisko użytkownika musi być przygotowane na urządzeniu. Jest to jednorazowy proces i odbywa się automatycznie bez interwencji użytkownika, gdy użytkownik próbuje chronić lub korzystać z chronionej zawartości:

Przepływ aktywacji klienta usługi RMS — krok 1, uwierzytelnianie klienta

Co się dzieje w kroku 1: Klient usługi RMS na komputerze najpierw łączy się z usługą Azure Rights Management i uwierzytelnia użytkownika przy użyciu konta Microsoft Entra.

Gdy konto użytkownika jest sfederowane z identyfikatorem Firmy Microsoft Entra, to uwierzytelnianie jest automatyczne i użytkownik nie jest monitowany o poświadczenia.

Aktywacja klienta usługi RMS — krok 2. Certyfikaty są pobierane do klienta

Co się dzieje w kroku 2: Po uwierzytelnieniu użytkownika połączenie jest automatycznie przekierowywane do dzierżawy usługi Azure Information Protection organizacji, która wystawia certyfikaty, które umożliwiają użytkownikowi uwierzytelnianie w usłudze Azure Rights Management w celu korzystania z chronionej zawartości i ochrony zawartości w trybie offline.

Jednym z tych certyfikatów jest certyfikat konta praw, często skracany do RAC. Ten certyfikat uwierzytelnia użytkownika w usłudze Microsoft Entra ID i jest ważny przez 31 dni. Certyfikat jest automatycznie odnawiany przez klienta usługi RMS, pod warunkiem, że konto użytkownika jest nadal w identyfikatorze Microsoft Entra ID, a konto jest włączone. Ten certyfikat nie jest konfigurowalny przez administratora.

Kopia tego certyfikatu jest przechowywana na platformie Azure, aby w przypadku przeniesienia użytkownika do innego urządzenia certyfikaty zostały utworzone przy użyciu tych samych kluczy.

Ochrona zawartości

Gdy użytkownik chroni dokument, klient usługi RMS wykonuje następujące akcje w niechronionym dokumencie:

Ochrona dokumentów za pomocą usługi RMS — krok 1. Dokument jest szyfrowany

Co się dzieje w kroku 1: klient usługi RMS tworzy losowy klucz (klucz zawartości) i szyfruje dokument przy użyciu tego klucza za pomocą algorytmu szyfrowania symetrycznego AES.

Ochrona dokumentów za pomocą usługi RMS — krok 2, tworzone są zasady

Co się dzieje w kroku 2: Klient usługi RMS tworzy następnie certyfikat zawierający zasady dla dokumentu zawierające prawa użytkowania dla użytkowników lub grup oraz inne ograniczenia, takie jak data wygaśnięcia. Te ustawienia można zdefiniować w szablonie skonfigurowanym wcześniej przez administratora lub określonym w momencie, gdy zawartość jest chroniona (czasami nazywana "zasadami ad hoc").

Głównym atrybutem Microsoft Entra używanym do identyfikowania wybranych użytkowników i grup jest atrybut Microsoft Entra ProxyAddresses, który przechowuje wszystkie adresy e-mail użytkownika lub grupy. Jeśli jednak konto użytkownika nie ma żadnych wartości w atrybucie ProxyAddresses usługi AD, zamiast tego zostanie użyta wartość UserPrincipalName użytkownika.

Następnie klient usługi RMS używa klucza organizacji uzyskanego podczas inicjowania środowiska użytkownika i używa tego klucza do szyfrowania zasad i symetrycznego klucza zawartości. Klient usługi RMS podpisuje również zasady przy użyciu certyfikatu użytkownika uzyskanego podczas inicjowania środowiska użytkownika.

Ochrona dokumentów za pomocą usługi RMS — krok 3. Zasady są osadzone w dokumencie

Co się dzieje w kroku 3: Na koniec klient usługi RMS osadza zasady w pliku z treścią dokumentu zaszyfrowanego wcześniej, co razem składa się z chronionego dokumentu.

Ten dokument można przechowywać w dowolnym miejscu lub udostępniać przy użyciu dowolnej metody, a zasady zawsze pozostają w zaszyfrowanym dokumencie.

Użycie zawartości

Gdy użytkownik chce korzystać z chronionego dokumentu, klient usługi RMS rozpoczyna się od żądania dostępu do usługi Azure Rights Management:

Użycie dokumentów usługi RMS — krok 1, uwierzytelnienie użytkownika i pobranie listy praw

Co się dzieje w kroku 1: uwierzytelniony użytkownik wysyła zasady dokumentu i certyfikaty użytkownika do usługi Azure Rights Management. Usługa odszyfrowuje i ocenia zasady oraz tworzy listę praw (jeśli istnieją) dla dokumentu. Aby zidentyfikować użytkownika, atrybut Microsoft Entra ProxyAddresses jest używany dla konta użytkownika i grup, do których użytkownik jest członkiem. Ze względu na wydajność członkostwo w grupie jest buforowane. Jeśli konto użytkownika nie ma wartości atrybutu Microsoft Entra ProxyAddresses, zamiast tego jest używana wartość w elemecie Microsoft Entra UserPrincipalName.

Użycie dokumentów usługi RMS — krok 2. Licencja użycia jest zwracana do klienta

Co się dzieje w kroku 2: usługa wyodrębnia następnie klucz zawartości AES z odszyfrowanych zasad. Ten klucz jest następnie szyfrowany przy użyciu publicznego klucza RSA użytkownika uzyskanego za pomocą żądania.

Następnie ponownie zaszyfrowany klucz zawartości jest osadzony w zaszyfrowanej licencji użycia z listą praw użytkownika, która następnie jest zwracana do klienta usługi RMS.

Użycie dokumentów usługi RMS — krok 3, odszyfrowywanie dokumentu i wymuszanie praw

Co się dzieje w kroku 3: Na koniec klient usługi RMS przyjmuje zaszyfrowaną licencję użycia i odszyfrowuje ją przy użyciu własnego klucza prywatnego użytkownika. Dzięki temu klient usługi RMS odszyfruje treść dokumentu zgodnie z potrzebami i renderuje go na ekranie.

Klient odszyfrowuje również listę praw i przekazuje je do aplikacji, co wymusza te prawa w interfejsie użytkownika aplikacji.

Uwaga

Gdy użytkownicy zewnętrzni w organizacji korzystają z chronionej zawartości, przepływ zużycia jest taki sam. Co zmienia się w tym scenariuszu, to sposób uwierzytelniania użytkownika. Aby uzyskać więcej informacji, zobacz Kiedy udostępniam chroniony dokument komuś spoza firmy, jak ten użytkownik jest uwierzytelniony?

Zmiany

Powyższe przewodniki obejmują standardowe scenariusze, ale istnieją pewne różnice:

  • Ochrona poczty e-mail: w przypadku szyfrowania wiadomości w usługach Exchange Online i Office 365 z nowymi funkcjami jest używana do ochrony wiadomości e-mail, uwierzytelnianie do użycia może również używać federacji z dostawcą tożsamości społecznościowych lub przy użyciu jednorazowego kodu dostępu. Następnie przepływy procesów są bardzo podobne, z tą różnicą, że użycie zawartości odbywa się po stronie usługi w sesji przeglądarki internetowej za pośrednictwem tymczasowo buforowanej kopii wychodzącej poczty e-mail.

  • Urządzenia przenośne: gdy urządzenia przenośne chronią pliki lub używają ich w usłudze Azure Rights Management, przepływy procesów są znacznie prostsze. Urządzenia przenośne nie najpierw przechodzą przez proces inicjowania użytkownika, ponieważ każda transakcja (w celu ochrony lub korzystania z zawartości) jest niezależna. Podobnie jak w przypadku komputerów z systemem Windows, urządzenia przenośne łączą się z usługą Azure Rights Management i uwierzytelniają się. Aby chronić zawartość, urządzenia przenośne przesyłają zasady, a usługa Azure Rights Management wysyła im licencję publikowania i klucz symetryczny w celu ochrony dokumentu. Aby korzystać z zawartości, gdy urządzenia przenośne łączą się z usługą Azure Rights Management i uwierzytelniają się, wysyłają zasady dokumentów do usługi Azure Rights Management i żądają licencji użycia do korzystania z dokumentu. W odpowiedzi usługa Azure Rights Management wysyła niezbędne klucze i ograniczenia do urządzeń przenośnych. Oba procesy używają protokołu TLS, aby chronić wymianę kluczy i inną komunikację.

  • Łącznik usługi RMS: gdy usługa Azure Rights Management jest używana z łącznikiem usługi RMS, przepływy procesu pozostają takie same. Jedyną różnicą jest to, że łącznik działa jako przekaźnik między usługami lokalnymi (takimi jak Exchange Server i SharePoint Server) i usługą Azure Rights Management. Sam łącznik nie wykonuje żadnych operacji, takich jak inicjowanie środowiska użytkownika, szyfrowanie lub odszyfrowywanie. Po prostu przekazuje komunikację, która zwykle przechodzi do serwera usług AD RMS, obsługując tłumaczenie między protokołami używanymi po każdej stronie. Ten scenariusz umożliwia korzystanie z usługi Azure Rights Management z usługami lokalnymi.

  • Ochrona ogólna (pfile): Gdy usługa Azure Rights Management ogólnie chroni plik, przepływ jest zasadniczo taki sam w przypadku ochrony zawartości, z wyjątkiem tego, że klient usługi RMS tworzy zasady, które udzielają wszystkich praw. Gdy plik zostanie użyty, zostanie odszyfrowany przed przekazaniem go do aplikacji docelowej. Ten scenariusz umożliwia ochronę wszystkich plików, nawet jeśli nie obsługują natywnie usługi RMS.

  • Konta Microsoft: usługa Azure Information Protection może autoryzować adresy e-mail do użycia podczas ich uwierzytelniania przy użyciu konta Microsoft. Jednak nie wszystkie aplikacje mogą otwierać chronioną zawartość, gdy konto Microsoft jest używane do uwierzytelniania. Więcej informacji.

Następne kroki

Aby dowiedzieć się więcej na temat usługi Azure Rights Management, skorzystaj z innych artykułów w sekcji Omówienie i eksplorowanie , na przykład Jak aplikacje obsługują usługę Azure Rights Management, aby dowiedzieć się, jak istniejące aplikacje mogą integrować się z usługą Azure Rights Management w celu zapewnienia rozwiązania do ochrony informacji.

Zapoznaj się z terminologią dotyczącą usługi Azure Information Protection , aby zapoznać się z terminami, które można napotkać podczas konfigurowania i używania usługi Azure Rights Management. Przed rozpoczęciem wdrażania zapoznaj się również z tematem Wymagania dotyczące usługi Azure Information Protection . Jeśli chcesz zapoznać się z przewodnikiem i wypróbować go samodzielnie, skorzystaj z przewodników Szybki start i samouczków:

Jeśli wszystko jest gotowe do rozpoczęcia wdrażania ochrony danych dla organizacji, skorzystaj z planu wdrożenia usługi AIP na potrzeby klasyfikacji, etykietowania i ochrony kroków wdrażania oraz linków do instrukcji.