Klien publik dan aplikasi klien rahasia

Artikel
03/20/2024

Microsoft Authentication Library (MSAL) mendefinisikan dua jenis klien; klien publik dan klien rahasia. Klien adalah entitas perangkat lunak yang memiliki pengidentifikasi unik yang ditetapkan oleh Penyedia Identitas. Jenis klien dibedakan oleh kemampuan mereka untuk mengautentikasi dengan aman dengan server otorisasi dan untuk menyimpan informasi pembuktian identitas yang sensitif sehingga tidak dapat diakses atau diketahui oleh pengguna dalam cakupan aksesnya.

Aplikasi klien publik	Aplikasi klien rahasia
Aplikasi desktop	Aplikasi web
API Tanpa Browser	Web API
Aplikasi seluler	Layanan/daemon

Otorisasi klien publik dan klien rahasia

Saat memeriksa sifat publik atau rahasia klien tertentu, kami mengevaluasi kemampuan klien tersebut untuk membuktikan identitasnya ke server otorisasi. Ini penting karena server otorisasi harus dapat mempercayai identitas klien untuk mengeluarkan token akses.

Aplikasi klien publik berjalan di perangkat, seperti desktop, API tanpa browser, aplikasi browser seluler atau sisi klien. Mereka tidak dapat dipercaya untuk menyimpan rahasia aplikasi dengan aman, sehingga mereka hanya dapat mengakses API web atas nama pengguna. Kapan saja sumber atau bytecode yang dikompilasi dari aplikasi tertentu ditransmisikan di mana saja dapat dibaca, dibongkar, atau diperiksa oleh pihak yang tidak tepercaya, itu adalah klien publik. Karena mereka juga hanya mendukung alur klien publik dan tidak dapat menyimpan rahasia waktu konfigurasi, mereka tidak dapat memiliki rahasia klien.
Aplikasi klien rahasia berjalan di server, seperti aplikasi web, aplikasi API web, atau aplikasi layanan/daemon. Mereka dianggap sulit diakses oleh pengguna atau penyerang, dan oleh karena itu dapat secara memadai menyimpan rahasia waktu konfigurasi untuk menegaskan bukti identitasnya. ID klien diekspos melalui browser web, tetapi rahasia hanya dilewatkan di saluran belakang dan tidak pernah langsung terekspos.

Rahasia dan kepentingannya dalam membuktikan identitas

Berikut ini adalah beberapa contoh bagaimana klien dapat membuktikan identitasnya ke server otorisasi:

Identitas terkelola untuk sumber daya Azure – Untuk skenario autentikasi khusus aplikasi, pengembang aplikasi dan layanan yang membangun di Azure memiliki opsi untuk membongkar manajemen rahasia, rotasi, dan perlindungan ke platform itu sendiri. Dengan identitas terkelola, identitas disediakan dan dihapus dengan sumber daya Azure dan tidak ada, termasuk Administrator Global, yang dapat mengakses kredensial yang mendasar. Dengan menggunakan identitas terkelola, Anda dapat mencegah risiko bocornya rahasia dan membiarkan penyedia menangani keamanan untuk Anda.
ID klien dan rahasia – Dalam pola ini, sepasang nilai dihasilkan oleh server otorisasi saat mendaftarkan klien. ID klien adalah nilai publik yang mengidentifikasi aplikasi, sementara rahasia klien adalah nilai rahasia yang digunakan untuk membuktikan identitas aplikasi.
Membuktikan kepemilikan sertifikat – Infrastruktur Kunci Umum (PKI), yang mencakup standar seperti X.509, adalah teknologi mendasar yang memungkinkan komunikasi yang aman melalui internet dan membentuk tulang punggung privasi internet. PKI digunakan untuk menerbitkan sertifikat digital yang memverifikasi identitas pihak yang terlibat dalam komunikasi online dan merupakan teknologi mendasar yang mendukung protokol seperti HTTPS, yang banyak digunakan untuk mengamankan lalu lintas web. Demikian pula, sertifikat dapat digunakan untuk mengamankan komunikasi service-to-service (S2S) di Azure dengan mengaktifkan autentikasi bersama antara layanan. Ini melibatkan setiap layanan yang menyajikan sertifikat kepada yang lain sebagai sarana untuk membuktikan identitasnya.
Presentasi pernyataan yang ditandatangani - Digunakan dalam federasi identitas beban kerja, pernyataan yang ditandatangani memungkinkan pertukaran token penyedia identitas pihak ketiga tepercaya dengan platform identitas Microsoft untuk mendapatkan token akses untuk memanggil sumber daya yang dilindungi Microsoft Entra. Federasi identitas beban kerja dapat digunakan untuk mengaktifkan berbagai skenario federasi, termasuk Azure Kubernetes Service, Amazon Web Services EKS, GitHub Actions, dan banyak lagi.

Kapan membuktikan identitas klien penting?

Membuktikan identitas klien penting ketika ada kebutuhan untuk memverifikasi keaslian dan otorisasi aplikasi klien sebelum memberikan akses ke data atau sumber daya sensitif. Beberapa contohnya termasuk:

Mengontrol akses API – Jika Anda memiliki API yang diukur (seperti untuk penagihan), atau mengekspos data atau sumber daya sensitif, Anda akan memverifikasi identitas klien sebelum memberikan akses. Misalnya, ini penting ketika memastikan bahwa hanya aplikasi yang berwenang yang memiliki akses ke API, dan bahwa pelanggan yang benar ditagih untuk penggunaan API terukur mereka.
Melindungi pengguna dari peniruan aplikasi - Jika Anda memiliki aplikasi yang disebarkan layanan dan menghadap pengguna (seperti aplikasi web berbasis backend) yang mengakses data atau layanan sensitif, menggunakan rahasia klien untuk melindungi sumber daya yang digunakan oleh aplikasi tersebut dapat mencegah pelaku jahat meniru klien yang sah ke pengguna phish dan menyelundupkan data atau menyalahgunakan akses.
Komunikasi S2S – Jika Anda memiliki beberapa layanan backend (seperti API hilir) yang perlu berkomunikasi satu sama lain, Anda dapat memverifikasi identitas setiap layanan untuk memastikan mereka berwenang untuk mengakses hanya sumber daya yang diperlukan untuk melakukan fungsinya.

Secara umum, membuktikan identitas klien penting ketika ada kebutuhan untuk mengautentikasi dan mengotorisasi klien yang independen dari atau selain pengguna.

Klien rahasia: praktik terbaik untuk mengelola rahasia

Gunakan identitas terkelola untuk menyederhanakan penyebaran dan keamanan – Identitas terkelola menyediakan identitas yang dikelola secara otomatis di ID Microsoft Entra untuk digunakan aplikasi saat menyambungkan ke sumber daya yang mendukung autentikasi Microsoft Entra. Aplikasi dapat menggunakan identitas terkelola untuk mendapatkan token khusus aplikasi ID Microsoft Entra tanpa harus mengelola kredensial. Ini dapat menghapus banyak kompleksitas yang terkait dengan manajemen rahasia, sambil meningkatkan keamanan dan ketahanan Anda. Jika Anda menggunakan identitas terkelola, sebagian besar, jika tidak semua praktik terbaik berikut sudah diurus untuk Anda.

Gunakan penyimpanan aman - Simpan rahasia klien di lokasi yang aman, seperti Key Vault atau file konfigurasi terenkripsi. Hindari menyimpan rahasia klien dalam teks biasa atau sebagai file check-in ke sistem kontrol versi.

Batasi akses - Batasi akses ke rahasia klien hanya untuk personel yang berwenang. Gunakan kontrol akses berbasis peran untuk membatasi akses ke rahasia klien hanya kepada mereka yang membutuhkannya untuk melakukan tugas operasional mereka.

Putar rahasia klien – Rotasi rahasia klien sesuai kebutuhan atau terjadwal, dapat meminimalkan risiko rahasia yang disusupi yang digunakan untuk mendapatkan akses yang tidak sah. Ketika diterapkan, rentang waktu di mana kunci disarankan untuk tetap digunakan dipengaruhi oleh kekuatan algoritma kriptografi yang digunakan dan/atau kepatuhan terhadap standar atau praktik kepatuhan peraturan.

Gunakan rahasia panjang dan enkripsi yang kuat - Terkait erat dengan titik sebelumnya, menggunakan algoritma enkripsi yang kuat untuk data dalam transit (pada kawat) dan saat tidak aktif (pada disk) membantu memastikan bahwa rahasia entropi tinggi tetap tidak mungkin dipaksakan secara brute. Algoritma seperti AES-128 (atau lebih tinggi) dapat membantu melindungi data tidak aktif, sementara RSA-2048 (atau lebih tinggi) dapat membantu melindungi data secara efisien saat transit. Karena sifat keamanan cyber yang terus berkembang, selalu praktik terbaik untuk berkonsultasi dengan pakar keamanan Anda dan secara berkala meninjau pilihan algoritma Anda.

Hindari rahasia hardcoding – Jangan rahasia klien hardcode dalam kode sumber. Menghindari rahasia dalam kode sumber dapat meminimalkan nilai pelaku jahat yang mendapatkan akses ke kode sumber Anda. Ini juga dapat mencegah rahasia tersebut secara tidak sengaja didorong ke repositori yang tidak aman atau tersedia untuk kontributor proyek yang dapat memiliki akses sumber, tetapi bukan akses rahasia.

Pantau repositori untuk rahasia yang bocor - Ini adalah fakta yang tidak menguntungkan bahwa check-in buruk terjadi saat berhadapan dengan kode sumber. Kait pra-penerapan Git adalah cara yang disarankan untuk mencegah check-in yang tidak disengaja, tetapi juga bukan pengganti pemantauan. Pemantauan otomatis repositori dapat mengidentifikasi rahasia yang bocor dan, dengan rencana untuk memutar kredensial yang disusupi, dapat membantu mengurangi insiden keamanan.

Pantau aktivitas mencurigakan – Pantau log dan jejak audit untuk aktivitas mencurigakan yang terkait dengan rahasia klien. Jika memungkinkan, gunakan pemberitahuan otomatis dan proses respons untuk memberi tahu personel dan menentukan kontingensi untuk aktivitas yang tidak biasa yang terkait dengan rahasia klien.

Ingat arsitek aplikasi Anda dengan kerahasiaan klien - Model keamanan Anda hanya sekuat tautan terlemah dalam rantai. Jangan meneruskan kredensial atau token keamanan dari rahasia ke klien publik, karena ini dapat memindahkan data rahasia klien ke klien publik, yang memungkinkan peniruan identitas klien rahasia.

Gunakan pustaka dan SDK terbaru dari sumber tepercaya – platform identitas Microsoft menyediakan berbagai SDK klien dan server dan middleware yang dirancang untuk meningkatkan produktivitas Anda sambil menjaga keamanan aplikasi Anda. Pustaka seperti Microsoft.Identity.Web menyederhanakan penambahan autentikasi dan otorisasi ke aplikasi web dan API di platform identitas Microsoft. Menjaga dependensi tetap diperbarui membantu memastikan aplikasi dan layanan Anda mendapat manfaat dari inovasi dan pembaruan keamanan terbaru.

Membandingkan jenis klien dan kemampuannya

Berikut ini adalah beberapa kesamaan dan perbedaan antara aplikasi klien publik dan rahasia:

Kedua jenis aplikasi mempertahankan cache token pengguna dan dapat memperoleh token secara diam-diam (ketika token ada di cache). Aplikasi klien rahasia juga memiliki cache token aplikasi untuk token yang diperoleh oleh aplikasi itu sendiri.
Kedua jenis aplikasi dapat mengelola akun pengguna dan mendapatkan akun dari cache token pengguna, mendapatkan akun dari pengidentifikasinya, atau menghapus akun.
Di MSAL, aplikasi klien publik memiliki empat cara untuk memperoleh token, melalui alur autentikasi terpisah. Aplikasi klien rahasia hanya memiliki tiga cara untuk memperoleh token dan salah satu cara untuk menghitung URL idP mengotorisasi titik akhir. ID klien diteruskan sekali pada konstruksi aplikasi dan tidak perlu diteruskan lagi ketika aplikasi memperoleh token. Untuk informasi selengkapnya, lihat memperoleh token.

Klien publik berguna untuk mengaktifkan akses yang didelegasikan pengguna ke sumber daya yang dilindungi tetapi tidak dapat membuktikan identitas aplikasi mereka sendiri. Klien rahasia, di sisi lain, dapat melakukan autentikasi dan otorisasi pengguna dan aplikasi dan harus dibangun dengan pertimbangkan keamanan untuk memastikan bahwa rahasia mereka tidak dibagikan dengan klien publik atau pihak ketiga lainnya.

Dalam beberapa kasus, seperti komunikasi S2S, infrastruktur seperti identitas terkelola sangat membantu menyederhanakan pengembangan dan penyebaran layanan dan menghapus banyak kompleksitas yang biasanya terkait dengan manajemen rahasia. Ketika identitas terkelola tidak dapat digunakan, penting untuk memiliki kebijakan, tindakan pencegahan, dan kontingensi yang berlaku untuk mengamankan rahasia dan merespons dengan insiden keamanan yang terkait dengannya.

Lihat juga

Untuk informasi selengkapnya tentang konfigurasi aplikasi dan pembuatan instans, lihat:

Bagikan melalui