Faza 2 migracji — konfiguracja po stronie serwera dla usług AD RMS
Skorzystaj z poniższych informacji w fazie 2 migracji z usług AD RMS do usługi Azure Information Protection. Te procedury obejmują kroki od 4 do 6 z sekcji Migrowanie z usług AD RMS do usługi Azure Information Protection.
Krok 4. Eksportowanie danych konfiguracji z usług AD RMS i importowanie ich do usługi Azure Information Protection
Ten krok jest dwuczęściowym procesem:
Wyeksportuj dane konfiguracji z usług AD RMS, eksportując zaufane domeny publikowania (TPD) do pliku XML. Ten proces jest taki sam dla wszystkich migracji.
Zaimportuj dane konfiguracji do usługi Azure Information Protection. W tym kroku istnieją różne procesy, w zależności od bieżącej konfiguracji wdrożenia usług AD RMS i preferowanej topologii klucza dzierżawy usługi Azure RMS.
Eksportowanie danych konfiguracji z usług AD RMS
Wykonaj poniższą procedurę dla wszystkich klastrów usług AD RMS dla wszystkich zaufanych domen publikowania, które mają chronioną zawartość dla organizacji. Nie trzeba uruchamiać tej procedury w klastrach tylko do licencjonowania.
Aby wyeksportować dane konfiguracji (informacje o zaufanej domenie publikowania)
Zaloguj się w klastrze usług AD RMS jako użytkownik z uprawnieniami administracyjnymi usług AD RMS.
W konsoli zarządzania usługAMI AD RMS (Usługi Active Directory Rights Management) rozwiń nazwę klastra usług AD RMS, rozwiń węzeł Zasady zaufania, a następnie kliknij pozycję Zaufane domeny publikowania.
W okienku wyników wybierz zaufaną domenę publikowania, a następnie w okienku Akcje kliknij pozycję Eksportuj zaufaną domenę publikowania.
W oknie dialogowym Eksportowanie zaufanej domeny publikowania:
Kliknij pozycję Zapisz jako i zapisz, aby wybrać ścieżkę i wybraną nazwę pliku. Pamiętaj, aby określić plik XML jako rozszerzenie nazwy pliku (nie jest on dołączany automatycznie).
Określ i potwierdź silne hasło. Pamiętaj, że to hasło będzie potrzebne później podczas importowania danych konfiguracji do usługi Azure Information Protection.
Nie zaznaczaj pola wyboru, aby zapisać plik zaufanej domeny w usłudze RMS w wersji 1.0.
Po wyeksportowaniu wszystkich zaufanych domen publikowania możesz rozpocząć procedurę importowania tych danych do usługi Azure Information Protection.
Należy pamiętać, że zaufane domeny publikowania obejmują klucze certyfikatu licencjodawcy serwera (SLC) do odszyfrowania wcześniej chronionych plików, dlatego ważne jest, aby wyeksportować (i później zaimportować na platformę Azure) wszystkie zaufane domeny publikowania, a nie tylko obecnie aktywne.
Na przykład w przypadku uaktualnienia serwerów usług AD RMS z trybu kryptograficznego 1 do trybu kryptograficznego 2 będzie dostępnych wiele zaufanych domen publikowania. Jeśli nie zostanie wyeksportowana i zaimportowana zaufana domena publikowania zawierająca zarchiwizowany klucz, który używał trybu kryptograficznego 1, na końcu migracji użytkownicy nie będą mogli otwierać zawartości chronionej za pomocą klucza trybu kryptograficznego 1.
Importowanie danych konfiguracji do usługi Azure Information Protection
Dokładne procedury tego kroku zależą od bieżącej konfiguracji wdrożenia usług AD RMS i preferowanej topologii klucza dzierżawy usługi Azure Information Protection.
Bieżące wdrożenie usług AD RMS używa jednej z następujących konfiguracji dla klucza certyfikatu licencjodawcy serwera (SLC):
Ochrona haseł w bazie danych usług AD RMS. To jest konfiguracja domyślna.
Ochrona modułu HSM przy użyciu sprzętowego modułu zabezpieczeń (HSM) nCipher.
Ochrona modułu HSM przy użyciu sprzętowego modułu zabezpieczeń (HSM) od dostawcy innego niż nCipher.
Hasło chronione przy użyciu zewnętrznego dostawcy usług kryptograficznych.
Uwaga
Aby uzyskać więcej informacji na temat używania sprzętowych modułów zabezpieczeń w usługach AD RMS, zobacz Using AD RMS with Hardware Security Modules (Używanie usług AD RMS ze sprzętowymi modułami zabezpieczeń).
Dwie opcje topologii klucza dzierżawy usługi Azure Information Protection to: firma Microsoft zarządza kluczem dzierżawy (zarządzanym przez firmę Microsoft) lub zarządza kluczem dzierżawy (zarządzanym przez klienta) w usłudze Azure Key Vault. Jeśli zarządzasz własnym kluczem dzierżawy usługi Azure Information Protection, czasami jest to nazywane "bring your own key" (BYOK). Aby uzyskać więcej informacji, zobacz Artykuł Planowanie i wdrażanie klucza dzierżawy usługi Azure Information Protection.
Skorzystaj z poniższej tabeli, aby zidentyfikować procedurę, która ma być używana do migracji.
Bieżące wdrożenie usług AD RMS | Wybrana topologia klucza dzierżawy usługi Azure Information Protection | Instrukcje dotyczące migracji |
---|---|---|
Ochrona haseł w bazie danych usług AD RMS | Zarządzane przez firmę Microsoft | Zobacz procedurę migracji klucza chronionego przez oprogramowanie do klucza chronionego przez oprogramowanie po tej tabeli. Jest to najprostsza ścieżka migracji i wymaga tylko przeniesienia danych konfiguracji do usługi Azure Information Protection. |
Ochrona modułu HSM przy użyciu sprzętowego modułu zabezpieczeń nCipher nShield (HSM) | Zarządzane przez klienta (BYOK) | Zobacz procedurę migracji klucza chronionego przez moduł HSM do klucza chronionego przez moduł HSM po tej tabeli. Wymaga to zestawu narzędzi BYOK usługi Azure Key Vault i trzech zestawów kroków, aby najpierw przenieść klucz z lokalnego modułu HSM do modułów HSM usługi Azure Key Vault, a następnie autoryzować usługę Azure Rights Management z usługi Azure Information Protection do używania klucza dzierżawy, a na koniec przenieść dane konfiguracji do usługi Azure Information Protection. |
Ochrona haseł w bazie danych usług AD RMS | Zarządzane przez klienta (BYOK) | Zobacz procedurę migracji klucza chronionego przez oprogramowanie do klucza chronionego przez moduł HSM po tej tabeli. Wymaga to zestawu narzędzi BYOK usługi Azure Key Vault i czterech zestawów kroków, aby najpierw wyodrębnić klucz oprogramowania i zaimportować go do lokalnego modułu HSM, a następnie przenieść klucz z lokalnego modułu HSM do modułów HSM usługi Azure Information Protection, następnie przenieść dane usługi Key Vault do usługi Azure Information Protection, a na koniec przenieść dane konfiguracji do usługi Azure Information Protection. |
Ochrona modułu HSM przy użyciu sprzętowego modułu zabezpieczeń (HSM) od dostawcy innego niż nCipher | Zarządzane przez klienta (BYOK) | Skontaktuj się z dostawcą modułu HSM, aby uzyskać instrukcje dotyczące przenoszenia klucza z tego modułu HSM do sprzętowego modułu zabezpieczeń (HSM) nCipher nShield. Następnie postępuj zgodnie z instrukcjami dotyczącymi procedury migracji klucza chronionego przez moduł HSM do klucza chronionego przez moduł HSM po tej tabeli. |
Hasło chronione przy użyciu zewnętrznego dostawcy kryptograficznego | Zarządzane przez klienta (BYOK) | Skontaktuj się z dostawcą dostawcy usług kryptograficznych, aby uzyskać instrukcje dotyczące przenoszenia klucza do sprzętowego modułu zabezpieczeń (HSM) nCipher nShield. Następnie postępuj zgodnie z instrukcjami dotyczącymi procedury migracji klucza chronionego przez moduł HSM do klucza chronionego przez moduł HSM po tej tabeli. |
Jeśli masz klucz chroniony przez moduł HSM, którego nie można wyeksportować, nadal możesz przeprowadzić migrację do usługi Azure Information Protection, konfigurując klaster usług AD RMS dla trybu tylko do odczytu. W tym trybie wcześniej chroniona zawartość może być nadal otwierana, ale nowo chroniona zawartość używa nowego klucza dzierżawy zarządzanego przez Ciebie (BYOK) lub zarządzanego przez firmę Microsoft. Aby uzyskać więcej informacji, zobacz Aktualizacja jest dostępna dla pakietu Office w celu obsługi migracji z usług AD RMS do usługi Azure RMS.
Przed rozpoczęciem tych kluczowych procedur migracji upewnij się, że możesz uzyskać dostęp do plików XML utworzonych wcześniej podczas eksportowania zaufanych domen publikowania. Na przykład można je zapisać na dysku kciuka USB, który zostanie przeniesiony z serwera usług AD RMS do stacji roboczej podłączonej do Internetu.
Uwaga
Jednak przechowujesz te pliki, użyj najlepszych rozwiązań w zakresie zabezpieczeń, aby je chronić, ponieważ te dane zawierają klucz prywatny.
Aby ukończyć krok 4, wybierz i wybierz instrukcje dotyczące ścieżki migracji:
- Klucz chroniony przez oprogramowanie do klucza chronionego przez oprogramowanie
- Klucz chroniony przez moduł HSM do klucza chronionego przez moduł HSM
- Klucz chroniony przez oprogramowanie do klucza chronionego przez moduł HSM
Krok 5. Aktywowanie usługi Azure Rights Management
Otwórz sesję programu PowerShell i uruchom następujące polecenia:
Połączenie do usługi Azure Rights Management i po wyświetleniu monitu określ poświadczenia administratora globalnego:
Connect-AipService
Aktywuj usługę Azure Rights Management:
Enable-AipService
Co zrobić, jeśli dzierżawa usługi Azure Information Protection została już aktywowana? Jeśli usługa Azure Rights Management została już aktywowana dla organizacji i utworzono szablony niestandardowe, które mają być używane po migracji, musisz wyeksportować i zaimportować te szablony. Ta procedura jest omówiona w następnym kroku.
Krok 6. Konfigurowanie zaimportowanych szablonów
Ponieważ zaimportowane szablony mają domyślny stan Zarchiwizowane, musisz zmienić ten stan na Opublikowany, jeśli chcesz, aby użytkownicy mogli używać tych szablonów w usłudze Azure Rights Management.
Szablony importowane z usług AD RMS wyglądają i zachowują się podobnie jak szablony niestandardowe, które można utworzyć w witrynie Azure Portal. Aby zmienić zaimportowane szablony do opublikowania, aby użytkownicy mogli je wyświetlać i wybierać z aplikacji, zobacz Konfigurowanie szablonów usługi Azure Information Protection i zarządzanie nimi.
Oprócz publikowania nowo zaimportowanych szablonów istnieją tylko dwie ważne zmiany dotyczące szablonów, które mogą być konieczne przed kontynuowaniem migracji. Aby uzyskać bardziej spójne środowisko dla użytkowników podczas procesu migracji, nie należy wprowadzać dodatkowych zmian w zaimportowanych szablonach i nie publikować dwóch domyślnych szablonów, które są dostarczane z usługą Azure Information Protection, ani tworzyć nowych szablonów w tej chwili. Zamiast tego zaczekaj na zakończenie procesu migracji i anulowano aprowizowanie serwerów usług AD RMS.
Zmiany szablonu, które mogą być konieczne w tym kroku:
Jeśli szablony niestandardowe usługi Azure Information Protection zostały utworzone przed migracją, należy je ręcznie wyeksportować i zaimportować.
Jeśli szablony w usłudze AD RMS używały grupy KAŻDY , może być konieczne ręczne dodanie użytkowników lub grup.
W usłudze AD RMS grupa KAŻDY przyznała prawa wszystkim użytkownikom uwierzytelnionymi przez lokalna usługa Active Directory, a ta grupa nie jest obsługiwana przez usługę Azure Information Protection. Odpowiednik szafy to grupa, która jest automatycznie tworzona dla wszystkich użytkowników w dzierżawie firmy Microsoft Entra. Jeśli używasz grupy KAŻDY dla szablonów usług AD RMS, może być konieczne dodanie użytkowników i praw, które chcesz im udzielić.
Procedura tworzenia szablonów niestandardowych przed migracją
Jeśli szablony niestandardowe zostały utworzone przed migracją, przed aktywowanie usługi Azure Rights Management lub po jej aktywowaniu, szablony nie będą dostępne dla użytkowników po migracji, nawet jeśli zostały ustawione na Opublikowano. Aby udostępnić je użytkownikom, należy najpierw wykonać następujące czynności:
Zidentyfikuj te szablony i zanotuj identyfikator szablonu, uruchamiając polecenie Get-AipServiceTemplate.
Wyeksportuj szablony przy użyciu polecenia cmdlet programu PowerShell usługi Azure RMS Export-AipServiceTemplate.
Zaimportuj szablony przy użyciu polecenia cmdlet programu PowerShell usługi Azure RMS Import-AipServiceTemplate.
Następnie możesz opublikować lub zarchiwizować te szablony, tak jak każdy inny szablon utworzony po migracji.
Procedura, jeśli szablony w usłudze AD RMS używały grupy KAŻDY
Jeśli szablony w usłudze AD RMS używały grupy KAŻDY, najbliższa równoważna grupa w usłudze Azure Information Protection nosi nazwę AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@<tenant_name.onmicrosoft.com>. Na przykład ta grupa może wyglądać następująco dla firmy Contoso: AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@contoso.onmicrosoft.com. Ta grupa zawiera wszystkich użytkowników z dzierżawy firmy Microsoft Entra.
Podczas zarządzania szablonami i etykietami w witrynie Azure Portal ta grupa jest wyświetlana jako nazwa domeny dzierżawy w identyfikatorze Entra firmy Microsoft. Na przykład ta grupa może wyglądać podobnie do następującej dla firmy Contoso: contoso.onmicrosoft.com. Aby dodać tę grupę, zostanie wyświetlona opcja Dodaj <nazwę> organizacji — wszyscy członkowie.
Jeśli nie masz pewności, czy szablony usług AD RMS zawierają grupę KAŻDY, możesz użyć następującego przykładowego skryptu programu Windows PowerShell, aby zidentyfikować te szablony. Aby uzyskać więcej informacji na temat korzystania z programu Windows PowerShell z usługami AD RMS, zobacz Using Windows PowerShell to Administracja ister AD RMS (Używanie programu Windows PowerShell do Administracja ster AD RMS).
Możesz łatwo dodawać użytkowników zewnętrznych do szablonów podczas konwertowania tych szablonów na etykiety w witrynie Azure Portal. Następnie w okienku Dodawanie uprawnień wybierz pozycję Wprowadź szczegóły , aby ręcznie określić adresy e-mail dla tych użytkowników.
Aby uzyskać więcej informacji na temat tej konfiguracji, zobacz How to configure a label for Rights Management protection (Jak skonfigurować etykietę ochrony usługi Rights Management).
Przykładowy skrypt programu Windows PowerShell umożliwiający zidentyfikowanie szablonów usług AD RMS zawierających grupę KAŻDY
Ta sekcja zawiera przykładowy skrypt, który ułatwia zidentyfikowanie szablonów usług AD RMS, które mają zdefiniowaną grupę KAŻDY zgodnie z opisem w poprzedniej sekcji.
Zastrzeżenie: ten przykładowy skrypt nie jest obsługiwany w żadnym standardowym programie pomocy technicznej lub usłudze firmy Microsoft. Ten przykładowy skrypt jest dostarczany jako bez gwarancji jakiegokolwiek rodzaju.
import-module adrmsadmin
New-PSDrive -Name MyRmsAdmin -PsProvider AdRmsAdmin -Root https://localhost -Force
$ListofTemplates=dir MyRmsAdmin:\RightsPolicyTemplate
foreach($Template in $ListofTemplates)
{
$templateID=$Template.id
$rights = dir MyRmsAdmin:\RightsPolicyTemplate\$Templateid\userright
$templateName=$Template.DefaultDisplayName
if ($rights.usergroupname -eq "anyone")
{
$templateName = $Template.defaultdisplayname
write-host "Template " -NoNewline
write-host -NoNewline $templateName -ForegroundColor Red
write-host " contains rights for " -NoNewline
write-host ANYONE -ForegroundColor Red
}
}
Remove-PSDrive MyRmsAdmin -force
Następne kroki
Przejdź do fazy 3 — konfiguracja po stronie klienta.