Bagaimana cara kerja Azure RMS? Di balik layanan

Hal penting yang perlu dipahami tentang cara kerja Azure RMS, adalah bahwa layanan perlindungan data ini dari Perlindungan Informasi Azure, tidak melihat atau menyimpan data Anda sebagai bagian dari proses perlindungan. Informasi yang Anda lindungi tidak pernah dikirim atau disimpan di Azure, kecuali Anda secara eksplisit menyimpannya di Azure atau menggunakan layanan cloud lain yang menyimpannya di Azure. Azure RMS hanya membuat data dalam dokumen tidak dapat dibaca oleh siapa pun selain pengguna dan layanan yang berwenang:

• Data dienkripsi di tingkat aplikasi dan menyertakan kebijakan yang menentukan penggunaan resmi untuk dokumen tersebut.

• Ketika dokumen yang dilindungi digunakan oleh pengguna yang sah atau diproses oleh layanan resmi, data dalam dokumen didekripsi dan hak yang ditentukan dalam kebijakan diberlakukan.

Pada tingkat tinggi, Anda dapat melihat cara kerja proses ini dalam gambar berikut. Dokumen yang berisi rumus rahasia dilindungi, lalu berhasil dibuka oleh pengguna atau layanan yang berwenang. Dokumen diproteksi oleh kunci konten (kunci hijau dalam gambar ini). Ini unik untuk setiap dokumen dan ditempatkan di header file tempat dokumen dilindungi oleh kunci akar penyewa Perlindungan Informasi Azure Anda (kunci merah dalam gambar ini). Kunci penyewa Anda dapat dihasilkan dan dikelola oleh Microsoft, atau Anda dapat membuat dan mengelola kunci penyewa Anda sendiri.

Sepanjang proses perlindungan saat Azure RMS mengenkripsi dan mendekripsi, mengotorisasi, dan memberlakukan pembatasan, rumus rahasia tidak pernah dikirim ke Azure.

Untuk deskripsi terperinci tentang apa yang terjadi, lihat panduan cara kerja Azure RMS: Penggunaan pertama, perlindungan konten, bagian konsumsi konten di artikel ini.

Untuk detail teknis tentang algoritma dan panjang kunci yang digunakan Azure RMS, lihat bagian berikutnya.

Kontrol kriptografi yang digunakan oleh Azure RMS: Algoritma dan panjang kunci

Bahkan jika Anda tidak perlu tahu secara rinci cara kerja teknologi ini, Anda mungkin ditanya tentang kontrol kriptografi yang digunakannya. Misalnya, untuk mengonfirmasi bahwa perlindungan keamanan berstandar industri.

Kontrol kriptografi	Gunakan di Azure RMS
Algoritma: AES Panjang kunci: 128 bit dan 256 bit [1]	Perlindungan konten
Algoritma: RSA Panjang kunci: 2048 bit [ 2]	Perlindungan kunci
SHA-256	Penandatanganan sertifikat

Catatan kaki 1

256 bit digunakan oleh klien Perlindungan Informasi Azure dalam skenario berikut:

• Perlindungan generik (.pfile).

• Perlindungan asli untuk dokumen PDF ketika dokumen telah dilindungi dengan standar ISO untuk enkripsi PDF, atau dokumen yang dilindungi yang dihasilkan memiliki ekstensi nama file .ppdf.

• Perlindungan asli untuk file teks atau gambar (seperti .ptxt atau .pjpg).

Catatan Kaki 2

2048 bit adalah panjang kunci saat layanan Manajemen Hak Azure diaktifkan. 1024 bit didukung untuk skenario opsional berikut:

• Selama migrasi dari lokal jika kluster AD RMS berjalan dalam Mode Kriptografi 1.

• Untuk kunci yang diarsipkan yang dibuat secara lokal sebelum migrasi, sehingga konten yang sebelumnya dilindungi oleh AD RMS dapat terus dibuka oleh layanan Azure Rights Management pascamigrasi.

Bagaimana kunci kriptografi Azure RMS disimpan dan diamankan

Untuk setiap dokumen atau email yang dilindungi oleh Azure RMS, Azure RMS membuat satu kunci AES ("kunci konten"), dan kunci tersebut disematkan ke dokumen, dan bertahan melalui edisi dokumen.

Kunci konten dilindungi dengan kunci RSA organisasi ("kunci penyewa Perlindungan Informasi Azure") sebagai bagian dari kebijakan dalam dokumen, dan kebijakan juga ditandatangani oleh pembuat dokumen. Kunci penyewa ini umum untuk semua dokumen dan email yang dilindungi oleh layanan Azure Rights Management untuk organisasi dan kunci ini hanya dapat diubah oleh administrator Perlindungan Informasi Azure jika organisasi menggunakan kunci penyewa yang dikelola pelanggan (dikenal sebagai "bawa kunci Anda sendiri", atau BYOK).

Kunci penyewa ini dilindungi dalam layanan online Microsoft, di lingkungan yang sangat terkontrol dan di bawah pemantauan ketat. Saat Anda menggunakan kunci penyewa yang dikelola pelanggan (BYOK), keamanan ini ditingkatkan dengan penggunaan array modul keamanan perangkat keras kelas atas (HSM) di setiap wilayah Azure, tanpa kemampuan agar kunci diekstrak, diekspor, atau dibagikan dalam keadaan apa pun. Untuk informasi selengkapnya tentang kunci penyewa dan BYOK, lihat Merencanakan dan menerapkan kunci penyewa Perlindungan Informasi Azure Anda.

Lisensi dan sertifikat yang dikirim ke perangkat Windows dilindungi dengan kunci privat perangkat klien, yang dibuat pertama kali pengguna di perangkat menggunakan Azure RMS. Kunci privat ini, pada gilirannya, dilindungi dengan DPAPI pada klien, yang melindungi rahasia ini dengan menggunakan kunci yang berasal dari kata sandi pengguna. Pada perangkat seluler, kunci hanya digunakan satu kali, jadi karena tidak disimpan pada klien, kunci ini tidak perlu dilindungi pada perangkat.

Panduan cara kerja Azure RMS: Penggunaan pertama, perlindungan konten, konsumsi konten

Untuk memahami secara lebih rinci cara kerja Azure RMS, mari kita telusuri alur umum setelah layanan Manajemen Hak Azure diaktifkan dan ketika pengguna pertama kali menggunakan layanan Manajemen Hak di komputer Windows mereka (proses yang terkadang dikenal sebagai menginisialisasi lingkungan pengguna atau bootstrapping), melindungi konten (dokumen atau email), lalu menggunakan konten (terbuka dan menggunakan) yang telah dilindungi oleh orang lain.

Setelah lingkungan pengguna diinisialisasi, pengguna tersebut kemudian dapat melindungi dokumen atau menggunakan dokumen yang dilindungi di komputer tersebut.

Catatan

Jika pengguna ini berpindah ke komputer Windows lain, atau pengguna lain menggunakan komputer Windows yang sama ini, proses inisialisasi diulang.

Menginisialisasi lingkungan pengguna

Sebelum pengguna dapat melindungi konten atau menggunakan konten yang dilindungi di komputer Windows, lingkungan pengguna harus disiapkan pada perangkat. Ini adalah proses satu kali dan terjadi secara otomatis tanpa intervensi pengguna saat pengguna mencoba melindungi atau menggunakan konten yang dilindungi:

Apa yang terjadi di langkah 1: Klien RMS di komputer terlebih dahulu tersambung ke layanan Azure Rights Management, dan mengautentikasi pengguna dengan menggunakan akun Microsoft Entra mereka.

Saat akun pengguna digabungkan dengan ID Microsoft Entra, autentikasi ini otomatis dan pengguna tidak dimintai kredensial.

Apa yang terjadi di langkah 2: Setelah pengguna diautentikasi, koneksi secara otomatis diarahkan ke penyewa Perlindungan Informasi Azure organisasi, yang mengeluarkan sertifikat yang memungkinkan pengguna mengautentikasi ke layanan Azure Rights Management untuk menggunakan konten yang dilindungi dan untuk melindungi konten secara offline.

Salah satu sertifikat ini adalah sertifikat akun hak, sering disingkat rac. Sertifikat ini mengautentikasi pengguna ke ID Microsoft Entra dan berlaku selama 31 hari. Sertifikat diperbarui secara otomatis oleh klien RMS, yang menyediakan akun pengguna masih berada di ID Microsoft Entra dan akun diaktifkan. Sertifikat ini tidak dapat dikonfigurasi oleh administrator.

Salinan sertifikat ini disimpan di Azure sehingga jika pengguna pindah ke perangkat lain, sertifikat dibuat dengan menggunakan kunci yang sama.

Perlindungan konten

Saat pengguna melindungi dokumen, klien RMS mengambil tindakan berikut pada dokumen yang tidak terlindungi:

Apa yang terjadi di langkah 1: Klien RMS membuat kunci acak (kunci konten) dan mengenkripsi dokumen menggunakan kunci ini dengan algoritma enkripsi simetris AES.

Apa yang terjadi di langkah 2: Klien RMS kemudian membuat sertifikat yang menyertakan kebijakan untuk dokumen yang menyertakan hak penggunaan untuk pengguna atau grup, dan batasan lainnya, seperti tanggal kedaluwarsa. Pengaturan ini dapat didefinisikan dalam templat yang sebelumnya dikonfigurasi administrator, atau ditentukan pada saat konten dilindungi (terkadang disebut sebagai "kebijakan ad hoc").

Atribut Microsoft Entra utama yang digunakan untuk mengidentifikasi pengguna dan grup yang dipilih adalah atribut Microsoft Entra ProxyAddresses, yang menyimpan semua alamat email untuk pengguna atau grup. Namun, jika akun pengguna tidak memiliki nilai apa pun di atribut Ad ProxyAddresses, nilai UserPrincipalName pengguna akan digunakan sebagai gantinya.

Klien RMS kemudian menggunakan kunci organisasi yang diperoleh ketika lingkungan pengguna diinisialisasi dan menggunakan kunci ini untuk mengenkripsi kebijakan dan kunci konten konten simetris. Klien RMS juga menandatangani kebijakan dengan sertifikat pengguna yang diperoleh saat lingkungan pengguna diinisialisasi.

Apa yang terjadi di langkah 3: Akhirnya, klien RMS menyematkan kebijakan ke dalam file dengan isi dokumen yang dienkripsi sebelumnya, yang bersama-sama terdiri dari dokumen yang dilindungi.

Dokumen ini dapat disimpan di mana saja atau dibagikan dengan menggunakan metode apa pun, dan kebijakan selalu tetap dengan dokumen terenkripsi.

Konsumsi konten

Saat pengguna ingin menggunakan dokumen yang dilindungi, klien RMS dimulai dengan meminta akses ke layanan Azure Rights Management:

Apa yang terjadi di langkah 1: Pengguna yang diautentikasi mengirimkan kebijakan dokumen dan sertifikat pengguna ke layanan Azure Rights Management. Layanan mendekripsi dan mengevaluasi kebijakan, dan membangun daftar hak (jika ada) yang dimiliki pengguna untuk dokumen tersebut. Untuk mengidentifikasi pengguna, atribut Microsoft Entra ProxyAddresses digunakan untuk akun dan grup pengguna tempat pengguna menjadi anggota. Untuk alasan performa, keanggotaan grup di-cache. Jika akun pengguna tidak memiliki nilai untuk atribut Microsoft Entra ProxyAddresses, nilai dalam Microsoft Entra UserPrincipalName digunakan sebagai gantinya.

Apa yang terjadi di langkah 2: Layanan kemudian mengekstrak kunci konten AES dari kebijakan yang didekripsi. Kunci ini kemudian dienkripsi dengan kunci RSA publik pengguna yang diperoleh dengan permintaan.

Kunci konten yang dienkripsi ulang kemudian disematkan ke dalam lisensi penggunaan terenkripsi dengan daftar hak pengguna, yang kemudian dikembalikan ke klien RMS.

Apa yang terjadi di langkah 3: Akhirnya, klien RMS mengambil lisensi penggunaan terenkripsi dan mendekripsinya dengan kunci privat penggunanya sendiri. Ini memungkinkan klien RMS mendekripsi isi dokumen sesuai kebutuhan dan merendernya di layar.

Klien juga mendekripsi daftar hak dan meneruskannya ke aplikasi, yang memberlakukan hak tersebut di antarmuka pengguna aplikasi.

Catatan

Saat pengguna yang berada di luar organisasi Anda menggunakan konten yang telah Anda lindungi, alur konsumsinya sama. Perubahan apa untuk skenario ini, adalah bagaimana pengguna diautentikasi. Untuk informasi selengkapnya, lihat Saat saya berbagi dokumen yang dilindungi dengan seseorang di luar perusahaan saya, bagaimana pengguna tersebut diautentikasi?

Variasi

Panduan sebelumnya mencakup skenario standar tetapi ada beberapa variasi:

• Perlindungan email: Saat Exchange Online dan Enkripsi Pesan Office 365 dengan kemampuan baru digunakan untuk melindungi pesan email, autentikasi untuk konsumsi juga dapat menggunakan federasi dengan idP sosial atau dengan menggunakan kode sandi satu kali. Kemudian, alur proses sangat mirip, kecuali bahwa konsumsi konten terjadi sisi layanan dalam sesi browser web melalui salinan email keluar yang di-cache sementara.

• Perangkat seluler: Saat perangkat seluler melindungi atau menggunakan file dengan layanan Azure Rights Management, alur prosesnya jauh lebih sederhana. Perangkat seluler tidak terlebih dahulu melalui proses inisialisasi pengguna karena sebaliknya, setiap transaksi (untuk melindungi atau menggunakan konten) bersifat independen. Seperti halnya komputer Windows, perangkat seluler terhubung ke layanan Azure Rights Management dan mengautentikasi. Untuk melindungi konten, perangkat seluler mengirimkan kebijakan dan layanan Azure Rights Management mengirimkan lisensi penerbitan dan kunci konten untuk melindungi dokumen. Untuk menggunakan konten, saat perangkat seluler tersambung ke layanan Azure Rights Management dan mengautentikasi, mereka mengirim kebijakan dokumen ke layanan Azure Rights Management dan meminta lisensi penggunaan untuk menggunakan dokumen. Sebagai respons, layanan Azure Rights Management mengirimkan kunci dan batasan yang diperlukan ke perangkat seluler. Kedua proses menggunakan TLS untuk melindungi pertukaran kunci dan komunikasi lainnya.

• Konektor RMS: Saat layanan Manajemen Hak Azure digunakan dengan konektor RMS, alur proses tetap sama. Satu-satunya perbedaan adalah bahwa konektor bertindak sebagai relai antara layanan lokal (seperti Server Exchange dan SharePoint Server) dan layanan Manajemen Hak Azure. Konektor itu sendiri tidak melakukan operasi apa pun, seperti inisialisasi lingkungan pengguna, atau enkripsi atau dekripsi. Ini hanya menyampaikan komunikasi yang biasanya akan masuk ke server AD RMS, menangani terjemahan antara protokol yang digunakan di setiap sisi. Skenario ini memungkinkan Anda menggunakan layanan Azure Rights Management dengan layanan lokal.

• Perlindungan generik (.pfile): Ketika layanan Azure Rights Management secara generik melindungi file, alur pada dasarnya sama untuk perlindungan konten kecuali bahwa klien RMS membuat kebijakan yang memberikan semua hak. Ketika file dikonsumsi, file didekripsi sebelum diteruskan ke aplikasi target. Skenario ini memungkinkan Anda melindungi semua file, meskipun tidak mendukung RMS secara asli.

• Akun Microsoft: Perlindungan Informasi Azure dapat mengotorisasi alamat email untuk dikonsumsi saat diautentikasi dengan akun Microsoft. Namun, tidak semua aplikasi dapat membuka konten yang dilindungi saat akun Microsoft digunakan untuk autentikasi. Informasi selengkapnya.

Langkah berikutnya

Untuk mempelajari selengkapnya tentang layanan Azure Rights Management, gunakan artikel lain di bagian Pahami & Jelajahi , seperti Bagaimana aplikasi mendukung layanan Manajemen Hak Azure untuk mempelajari bagaimana aplikasi Anda yang ada dapat diintegrasikan dengan Azure Rights Management untuk memberikan solusi perlindungan informasi.

Tinjau Terminologi untuk Perlindungan Informasi Azure sehingga Anda terbiasa dengan istilah yang mungkin Anda temui saat mengonfigurasi dan menggunakan layanan Azure Rights Management, dan pastikan juga memeriksa Persyaratan untuk Perlindungan Informasi Azure sebelum memulai penyebaran. Jika Anda ingin menyelam dan mencobanya sendiri, gunakan mulai cepat dan tutorial:

• Mulai cepat: Menyebarkan klien pelabelan terpadu
• Tutorial: Menginstal pemindai pelabelan terpadu Azure Information Protection (AIP)
• Tutorial: Menemukan konten sensitif Anda dengan pemindai Azure Information Protection (AIP)
• Tutorial: Mencegah oversharing di Outlook menggunakan Azure Information Protection (AIP)

Jika Anda siap untuk mulai menyebarkan perlindungan data untuk organisasi Anda, gunakan peta jalan penyebaran AIP untuk klasifikasi, pelabelan, dan perlindungan untuk langkah dan tautan penyebaran Anda untuk instruksi cara penggunaan.

Tip

Untuk informasi dan bantuan tambahan, gunakan sumber daya dan tautan di Informasi dan dukungan untuk Perlindungan Informasi Azure.