Bagikan melalui

Migrasi fase 5 - tugas pascamigrasi

  • Artikel

Gunakan informasi berikut untuk Fase 5 migrasi dari AD RMS ke Perlindungan Informasi Azure. Prosedur ini mencakup langkah 10 hingga 12 dari Migrasi dari AD RMS ke Perlindungan Informasi Azure.

Langkah 10: Deprovisi AD RMS

Hapus Service Koneksi ion Point (SCP) dari Direktori Aktif untuk mencegah komputer menemukan infrastruktur Manajemen Hak lokal Anda. Ini opsional untuk klien yang ada yang Anda migrasikan karena pengalihan yang Anda konfigurasikan di registri (misalnya, dengan menjalankan skrip migrasi). Namun, menghapus SCP mencegah klien baru dan kemungkinan layanan dan alat terkait RMS menemukan SCP ketika migrasi selesai. Pada titik ini, semua koneksi komputer harus masuk ke layanan Manajemen Hak Azure.

Untuk menghapus SCP, pastikan Anda masuk sebagai administrator perusahaan domain, lalu gunakan prosedur berikut:

  1. Di konsol Layanan Active Directory Rights Management, klik kanan kluster AD RMS, lalu klik Properti.

  2. Klik tab SCP .

  3. Pilih kotak centang Ubah SCP .

  4. Pilih Hapus SCP Saat Ini, lalu klik OK.

Sekarang pantau server AD RMS Anda untuk aktivitas. Misalnya, periksa permintaan dalam laporan Kesehatan Sistem, tabel ServiceRequest, atau akses pengguna audit ke konten yang dilindungi.

Ketika Anda telah mengonfirmasi bahwa klien RMS tidak lagi berkomunikasi dengan server ini dan bahwa klien berhasil menggunakan Perlindungan Informasi Azure, Anda dapat menghapus peran server AD RMS dari server ini. Jika Anda menggunakan server khusus, Anda mungkin lebih suka langkah berhati-hati untuk terlebih dahulu mematikan server untuk jangka waktu tertentu. Ini memberi Anda waktu untuk memastikan bahwa tidak ada masalah yang dilaporkan yang mungkin mengharuskan Anda untuk memulai ulang server ini untuk kelangsungan layanan saat Anda menyelidiki mengapa klien tidak menggunakan Perlindungan Informasi Azure.

Setelah membatalkan provisi server AD RMS, Anda mungkin ingin mengambil kesempatan untuk meninjau templat dan label Anda. Misalnya, konversi templat ke label, konsolidasikan sehingga pengguna memiliki lebih sedikit untuk dipilih, atau mengonfigurasi ulang templat tersebut. Ini juga akan menjadi waktu yang tepat untuk menerbitkan templat default.

Untuk label sensitivitas dan klien pelabelan terpadu, gunakan portal kepatuhan Microsoft Purview. Untuk informasi selengkapnya, lihat dokumentasi Microsoft 365.

Penting

Pada akhir migrasi ini, kluster AD RMS Anda tidak dapat digunakan dengan Perlindungan Informasi Azure dan opsi tahan kunci Anda sendiri (HYOK).

Konfigurasi tambahan untuk komputer yang menjalankan Office 2010

Penting

Dukungan yang diperpanjang Office 2010 berakhir pada 13 Oktober 2020. Untuk informasi selengkapnya, lihat Versi AIP dan Windows dan Office warisan.

Jika klien yang dimigrasikan menjalankan Office 2010, pengguna mungkin mengalami penundaan dalam membuka konten yang dilindungi setelah server AD RMS kami dibatalkan provisinya. Atau, pengguna mungkin melihat pesan bahwa mereka tidak memiliki kredensial untuk membuka konten yang dilindungi. Untuk mengatasi masalah ini, buat pengalihan jaringan untuk komputer ini, yang mengalihkan FQDN URL AD RMS ke alamat IP lokal komputer (127.0.0.1). Anda dapat melakukan ini dengan mengonfigurasi file host lokal di setiap komputer, atau dengan menggunakan DNS.

  • Pengalihan melalui file host lokal: Tambahkan baris berikut di file host lokal, ganti <AD RMS URL FQDN> dengan nilai untuk kluster AD RMS Anda, tanpa awalan atau halaman web:

    127.0.0.1 <AD RMS URL FQDN>

  • Pengalihan melalui DNS: Buat catatan host baru (A) untuk AD RMS URL FQDN Anda, yang memiliki alamat IP 127.0.0.1.

Langkah 11: Menyelesaikan tugas migrasi klien

Untuk klien perangkat seluler dan komputer Mac: Hapus catatan DNS SRV yang Anda buat saat menyebarkan ekstensi perangkat seluler AD RMS.

Ketika perubahan DNS ini telah disebarluaskan, klien ini akan secara otomatis menemukan dan mulai menggunakan layanan Azure Rights Management. Namun, komputer Mac yang menjalankan Office Mac menyimpan cache informasi dari AD RMS. Untuk komputer ini, proses ini dapat memakan waktu hingga 30 hari.

Untuk memaksa komputer Mac menjalankan proses penemuan segera, di rantai kunci, cari "adal" dan hapus semua entri ADAL. Kemudian, jalankan perintah berikut pada komputer ini:


rm -r ~/Library/Cache/MSRightsManagement

rm -r ~/Library/Caches/com.microsoft.RMS-XPCService

rm -r ~/Library/Caches/Microsoft\ Rights\ Management\ Services

rm -r ~/Library/Containers/com.microsoft.RMS-XPCService

rm -r ~/Library/Containers/com.microsoft.RMSTestApp

rm ~/Library/Group\ Containers/UBF8T346G9.Office/DRM.plist

killall cfprefsd

Ketika semua komputer Windows yang ada telah bermigrasi ke Perlindungan Informasi Azure, tidak ada alasan untuk terus menggunakan kontrol orientasi dan mempertahankan grup AIPMigrated yang Anda buat untuk proses migrasi.

Hapus kontrol onboarding terlebih dahulu, lalu Anda dapat menghapus grup AIPMigrated dan metode penyebaran perangkat lunak apa pun yang Anda buat untuk menyebarkan skrip migrasi.

Untuk menghapus kontrol onboarding:

  1. Dalam sesi PowerShell, sambungkan ke layanan Azure Rights Management dan saat diminta, tentukan kredensial admin global Anda:

    Connect-AipService

  2. Jalankan perintah berikut, dan masukkan Y untuk mengonfirmasi:

    Set-AipServiceOnboardingControlPolicy -UseRmsUserLicense $False

    Perhatikan bahwa perintah ini menghapus penegakan lisensi apa pun untuk layanan perlindungan Azure Rights Management, sehingga semua komputer dapat melindungi dokumen dan email.

  3. Konfirmasikan bahwa kontrol onboarding tidak lagi diatur:

    Get-AipServiceOnboardingControlPolicy

    Dalam output, Lisensi harus menampilkan False, dan tidak ada GUID yang ditampilkan untuk SecurityGroupOjbectId

Terakhir, jika Anda menggunakan Office 2010 dan telah mengaktifkan tugas Manajemen Templat Kebijakan Hak AD RMS (Otomatis) di pustaka Penjadwal Tugas Windows, nonaktifkan tugas ini karena tidak digunakan oleh klien Perlindungan Informasi Azure.

Tugas ini biasanya diaktifkan dengan menggunakan kebijakan grup dan mendukung penyebaran AD RMS. Anda dapat menemukan tugas ini di lokasi berikut: Microsoft>Windows> Layanan Active Directory Rights Management Client.

Penting

Dukungan yang diperpanjang Office 2010 berakhir pada 13 Oktober 2020. Untuk informasi selengkapnya, lihat Versi AIP dan Windows dan Office warisan.

Langkah 12: Kunci kunci penyewa Perlindungan Informasi Azure Anda

Langkah ini diperlukan ketika migrasi selesai jika penyebaran AD RMS Anda menggunakan Mode Kriptografi RMS 1 karena mode ini menggunakan kunci 1024-bit dan SHA-1. Konfigurasi ini dianggap menawarkan tingkat perlindungan yang tidak memadai. Microsoft tidak mendukung penggunaan panjang kunci yang lebih rendah seperti kunci RSA 1024-bit dan penggunaan protokol terkait yang menawarkan tingkat perlindungan yang tidak memadai, seperti SHA-1.

Pengulangan menghasilkan perlindungan yang menggunakan Mode Kriptografi RMS 2, yang menghasilkan kunci 2048-bit dan SHA-256.

Bahkan jika penyebaran AD RMS Anda menggunakan Mode Kriptografi 2, kami masih menyarankan Anda melakukan langkah ini karena kunci baru membantu melindungi penyewa Anda dari potensi pelanggaran keamanan ke kunci AD RMS Anda.

Saat Anda memasukkan kembali kunci penyewa Perlindungan Informasi Azure Anda (juga dikenal sebagai "menggulung kunci Anda"), kunci yang saat ini aktif diarsipkan dan Perlindungan Informasi Azure mulai menggunakan kunci berbeda yang Anda tentukan. Kunci yang berbeda ini bisa menjadi kunci baru yang Anda buat di Azure Key Vault, atau kunci default yang dibuat secara otomatis untuk penyewa Anda.

Berpindah dari satu kunci ke kunci lain tidak segera terjadi tetapi selama beberapa minggu. Karena tidak segera, jangan tunggu sampai Anda mencurigai pelanggaran pada kunci asli Anda tetapi lakukan langkah ini segera setelah migrasi selesai.

Untuk mengulang kunci penyewa Perlindungan Informasi Azure Anda:

  • Jika kunci penyewa Anda dikelola oleh Microsoft: Jalankan cmdlet PowerShell Set-AipServiceKeyProperties dan tentukan pengidentifikasi kunci untuk kunci yang dibuat secara otomatis untuk penyewa Anda. Anda dapat mengidentifikasi nilai yang akan ditentukan dengan menjalankan cmdlet Get-AipServiceKeys . Kunci yang dibuat secara otomatis untuk penyewa Anda memiliki tanggal pembuatan terlama, sehingga Anda dapat mengidentifikasinya dengan menggunakan perintah berikut:

    (Get-AipServiceKeys) | Sort-Object CreationTime | Select-Object -First 1

  • Jika kunci penyewa Dikelola oleh Anda (BYOK): Di Azure Key Vault, ulangi proses pembuatan kunci untuk penyewa Perlindungan Informasi Azure Anda, lalu jalankan cmdlet Use-AipServiceKeyVaultKey lagi untuk menentukan URI untuk kunci baru ini.

Untuk informasi selengkapnya tentang mengelola kunci penyewa Perlindungan Informasi Azure Anda, lihat Operasi untuk kunci penyewa Perlindungan Informasi Azure Anda.

Langkah berikutnya

Sekarang setelah Anda menyelesaikan migrasi, tinjau peta jalan penyebaran AIP untuk klasifikasi, pelabelan, dan perlindungan untuk mengidentifikasi tugas penyebaran lain yang mungkin perlu Anda lakukan.