Bagikan melalui

Perlindungan API

  • Artikel

Saat Anda, sebagai pengembang, lindungi API Anda, fokus Anda adalah pada otorisasi. Untuk memanggil API sumber daya Anda, aplikasi perlu memperoleh otorisasi aplikasi. Sumber daya itu sendiri harus memberlakukan otorisasi. Dalam artikel ini, Anda mempelajari praktik terbaik untuk melindungi API Anda melalui pendaftaran, menentukan izin dan persetujuan, dan menegakkan akses untuk mencapai tujuan Zero Trust Anda.

Mendaftarkan API yang dilindungi

Untuk melindungi API Anda dengan ID Microsoft Entra (ID Microsoft Entra) Anda akan terlebih dahulu mendaftarkan API, setelah itu Anda dapat mengelola API terdaftar Anda. Di ID Microsoft Entra, API adalah aplikasi dengan pengaturan pendaftaran aplikasi tertentu yang mendefinisikannya sebagai sumber daya atau API yang dapat diakses oleh aplikasi lain. Di pusat admin Microsoft Entra, Microsoft Identity Developer, Pendaftaran aplikasi, adalah API yang berada di penyewa baik sebagai LINI API bisnis atau layanan dari penyedia SaaS yang memiliki API yang dilindungi ID Microsoft Entra.

Selama pendaftaran, Anda menentukan bagaimana aplikasi panggilan mereferensikan API Anda dan izin yang didelegasikan dan aplikasinya. Pendaftaran aplikasi dapat mewakili solusi yang memiliki aplikasi klien dan API. Namun, dalam artikel ini, kami membahas skenario di mana sumber daya mandiri mengekspos API.

Biasanya, API tidak melakukan autentikasi atau secara langsung meminta otorisasi. API memvalidasi token yang disajikan aplikasi panggilan. API tidak memiliki rincian masuk interaktif, jadi Anda tidak perlu mendaftarkan pengaturan seperti URI pengalihan atau jenis aplikasi. API mendapatkan token mereka dari aplikasi yang memanggil API tersebut, bukan dengan berinteraksi dengan ID Microsoft Entra. Untuk API web, gunakan token akses OAuth2 untuk otorisasi. API Web memvalidasi token pembawa untuk mengotorisasi penelepon. Jangan terima token ID sebagai bukti izin.

Secara default, MICROSOFT Entra ID menambahkan User.Read izin API dari pendaftaran aplikasi baru apa pun. Anda menghapus izin ini untuk sebagian besar API web. MICROSOFT Entra ID memerlukan izin API hanya saat API memanggil API lain. Jika API Anda tidak memanggil API lain, hapus User.Read izin saat Anda mendaftarkan API Anda.

Anda memerlukan pengidentifikasi unik untuk API Anda, yang dikenal sebagai URI ID Aplikasi, aplikasi klien yang perlu mengakses API Anda meminta izin untuk memanggil API Anda. URI ID Aplikasi harus unik di semua penyewa Microsoft Entra. Anda dapat menggunakan api://<clientId> (saran default di portal), di mana <clientId> adalah ID Aplikasi DARI API terdaftar Anda.

Untuk memberi pengembang yang memanggil API Anda dengan nama yang lebih mudah digunakan, Anda dapat menggunakan alamat API Anda sebagai URI ID Aplikasi Anda. Misalnya, Anda dapat menggunakan https://API.yourdomain.com di mana yourdomain.com harus menjadi domain penerbit yang dikonfigurasi di penyewa Microsoft Entra Anda. Microsoft memvalidasi bahwa Anda memiliki kepemilikan domain sehingga Anda dapat menggunakannya sebagai pengidentifikasi unik untuk API Anda. Anda tidak perlu memiliki kode di alamat ini. API dapat berada di mana pun Anda menginginkannya, tetapi ini adalah praktik yang baik untuk menggunakan alamat HTTPS API sebagai URI ID Aplikasi.

Menentukan izin yang didelegasikan dengan hak istimewa paling sedikit

Jika API Anda akan dipanggil oleh aplikasi yang memiliki pengguna, Anda harus menentukan setidaknya satu izin yang didelegasikan (lihat Menambahkan cakupan pada pendaftaran aplikasi Mengekspos API).

API yang menyediakan akses ke penyimpanan data organisasi dapat menarik perhatian penyerang yang ingin mengakses data tersebut. Alih-alih hanya memiliki satu izin yang didelegasikan, rancang izin Anda dengan ingat prinsip Zero Trust akses hak istimewa paling sedikit. Mungkin sulit untuk masuk ke model dengan hak istimewa paling sedikit nanti jika semua aplikasi klien dimulai dengan akses istimewa penuh.

Seringkali, pengembang termasuk dalam pola menggunakan satu izin seperti "akses sebagai pengguna" atau "peniruan pengguna" (yang merupakan frasa umum meskipun secara teknis tidak akurat). Izin tunggal seperti ini hanya memungkinkan akses istimewa penuh ke API Anda.

Deklarasikan cakupan hak istimewa paling sedikit sehingga aplikasi Anda tidak rentan terhadap kompromi atau digunakan untuk melakukan tugas yang tidak pernah Anda maksudkan. Tentukan beberapa cakupan Anda dalam Izin API. Misalnya, cakupan terpisah dari membaca dan memperbarui data dan mempertimbangkan untuk menawarkan izin baca-saja. "Akses tulis" mencakup hak istimewa untuk operasi buat, perbarui, dan hapus. Klien seharusnya tidak pernah memerlukan akses tulis hanya untuk membaca data.

Pertimbangkan izin akses "standar" dan "penuh" saat API Anda bekerja dengan data sensitif. Batasi properti sensitif sehingga izin standar tidak mengizinkan akses (misalnya, Resource.Read). Kemudian terapkan izin akses "penuh" (misalnya, Resource.ReadFull) yang mengembalikan properti dan informasi sensitif.

Selalu evaluasi izin yang Anda minta untuk memastikan bahwa Anda mencari set hak istimewa paling sedikit absolut untuk menyelesaikan pekerjaan. Hindari meminta izin hak istimewa yang lebih tinggi. Sebagai gantinya, buat izin individual untuk setiap skenario inti. Lihat referensi izin Microsoft Graph untuk contoh pendekatan ini yang baik. Temukan dan gunakan jumlah izin yang tepat untuk memenuhi kebutuhan Anda.

Sebagai bagian dari definisi cakupan Anda, putuskan apakah rentang operasi yang dapat dilakukan dengan cakupan tertentu memerlukan persetujuan admin.

Sebagai perancang API, Anda dapat memberikan panduan tentang cakupan mana yang dapat dengan aman hanya memerlukan persetujuan pengguna. Namun, admin penyewa dapat mengonfigurasi penyewa sehingga semua izin memerlukan persetujuan admin. Jika Anda menentukan cakupan sebagai memerlukan persetujuan admin, izin selalu memerlukan persetujuan admin.

Saat memutuskan persetujuan pengguna atau admin, Anda memiliki dua pertimbangan utama:

  1. Apakah rentang operasi di belakang izin memengaruhi lebih dari satu pengguna. Jika izin memungkinkan pengguna untuk memilih aplikasi mana yang hanya dapat mengakses informasi mereka sendiri, maka persetujuan pengguna mungkin sesuai. Misalnya, pengguna dapat menyetujui untuk memilih aplikasi pilihan mereka untuk email. Namun, jika operasi di balik izin melibatkan lebih dari satu pengguna (misalnya, melihat profil pengguna lengkap pengguna lain), maka tentukan izin tersebut sebagai memerlukan persetujuan admin.

  2. Apakah rentang operasi di belakang izin memiliki cakupan yang luas. Misalnya, cakupan yang luas adalah ketika izin memungkinkan aplikasi mengubah semua yang ada di penyewa atau melakukan sesuatu yang mungkin tidak dapat diubah. Cakupan luas menunjukkan bahwa Anda memerlukan persetujuan admin daripada persetujuan pengguna.

Err di sisi konservatif dan memerlukan persetujuan admin jika Anda ragu. Jelas dan ringkas menjelaskan konsekuensi persetujuan dalam string izin Anda. Asumsikan bahwa individu yang membaca string deskripsi Anda tidak memiliki keakraban dengan API atau produk Anda.

Hindari menambahkan API Anda ke izin yang ada dengan cara yang mengubah semantik izin. Kelebihan beban izin yang ada mengencerkan penalaran di mana klien sebelumnya memberikan persetujuan.

Menentukan izin aplikasi

Saat membuat aplikasi nonpengguna, Anda tidak memiliki pengguna yang dapat dimintai nama pengguna dan kata sandi atau Autentikasi Multifaktor (MFA). Jika aplikasi tanpa pengguna (seperti beban kerja, layanan, dan daemon) memanggil API Anda, Anda harus menentukan izin aplikasi untuk API Anda. Saat Anda menentukan izin aplikasi, Anda menggunakan peran aplikasi alih-alih menggunakan cakupan.

Seperti halnya izin yang didelegasikan, Anda memberikan izin aplikasi terperinci sehingga beban kerja yang memanggil API Anda dapat mengikuti akses hak istimewa paling sedikit dan selaras dengan prinsip Zero Trust. Hindari menerbitkan hanya satu peran aplikasi (izin aplikasi) dan satu cakupan (izin yang didelegasikan) atau mengekspos semua operasi ke setiap klien.

Beban kerja mengautentikasi dengan kredensial klien dan meminta token menggunakan .default cakupan seperti yang ditunjukkan dalam contoh kode berikut.

// With client credentials flows the scopes is ALWAYS of the shape "resource/.default", as the 
// application permissions need to be set statically (in the portal or by PowerShell), 
// and then granted by a tenant administrator
string[] scopes = new string[] { "https://kkaad.onmicrosoft.com/webapi/.default" };
 
AuthenticationResult result = null;
try
{
  result = await app.AcquireTokenForClient(scopes)
    .ExecuteAsync();
  Console.WriteLine("Token acquired \n");
}
catch (MsalServiceException ex) when (ex.Message.Contains("AADSTS70011"))
{
  // Invalid scope. The scope has to be of the form "https://resourceurl/.default"
  // Mitigation: change the scope to be as expected
  Console.WriteLine("Scope provided is not supported");
}

Izin memerlukan persetujuan admin ketika tidak ada pengguna di depan aplikasi dan ketika izin aplikasi mengaktifkan berbagai operasi.

Menerapkan akses

Pastikan API Anda menerapkan akses dengan memvalidasi dan menginterpretasikan token akses yang disediakan aplikasi panggilan sebagai token pembawa di header otorisasi permintaan HTTPS. Anda dapat menerapkan akses dengan memvalidasi token, mengelola refresh metadata, dan menerapkan cakupan dan peran, seperti yang dijelaskan di bagian berikut.

Memvalidasi token

Setelah API Anda menerima token, API harus memvalidasi token. Validasi memastikan bahwa token berasal dari penerbit yang tepat sebagai tidak diubah dan tidak dimodifikasi. Periksa tanda tangan karena Anda tidak mendapatkan token langsung dari ID Microsoft Entra seperti yang Anda lakukan dengan token ID. Validasi tanda tangan setelah API Anda menerima token dari sumber yang tidak tepercaya di jaringan.

Karena ada kerentanan yang diketahui sekeliling verifikasi tanda tangan token web JSON, gunakan pustaka validasi token standar yang dikelola dengan baik dan ditetapkan. Pustaka autentikasi (seperti Microsoft.Identity.Web) menggunakan langkah-langkah yang tepat dan mengurangi kerentanan yang diketahui.

Secara opsional, perluas validasi token. Gunakan klaim ID penyewa (tid) untuk membatasi penyewa tempat API Anda dapat memperoleh token. azp Gunakan klaim dan appid untuk memfilter aplikasi yang dapat memanggil API Anda. Gunakan klaim ID objek (oid) untuk mempersempit akses lebih lanjut ke pengguna individu.

Mengelola refresh metadata

Selalu pastikan bahwa pustaka validasi token Anda secara efektif mengelola metadata yang diperlukan. Dalam hal ini, metadata adalah kunci publik, pasangan kunci privat, yang digunakan Microsoft untuk menandatangani token Microsoft Entra. Saat pustaka Anda memvalidasi token ini, pustaka tersebut mendapatkan daftar kunci penandatanganan publik kami yang diterbitkan dari alamat internet terkenal. Pastikan bahwa lingkungan hosting memiliki waktu yang tepat untuk mendapatkan kunci tersebut.

Misalnya, pustaka yang lebih lama kadang-kadang dikodekan secara keras untuk memperbarui kunci penandatanganan publik tersebut setiap 24 jam. Pertimbangkan kapan MICROSOFT Entra ID harus dengan cepat memutar kunci tersebut dan kunci yang Anda unduh tidak menyertakan kunci baru yang diputar. API Anda bisa offline selama sehari saat menunggu siklus refresh metadatanya. Referensikan panduan refresh metadata tertentu untuk memastikan bahwa Anda mendapatkan metadata dengan benar. Jika Anda menggunakan pustaka, pastikan metadata tersebut memperlakukan metadata tersebut dalam waktu yang wajar.

Menerapkan cakupan dan peran

Setelah memvalidasi token, API Anda melihat klaim dalam token untuk menentukan cara kerjanya.

Untuk token izin yang didelegasikan, mintaLAH API Anda memeriksa klaim cakupan (scp) untuk melihat apa yang telah disetujui aplikasi untuk dilakukan. Periksa klaim ID objek (oid) atau kunci subjek (sub) untuk melihat pengguna atas nama aplikasi berfungsi.

Kemudian minta pemeriksaan API Anda untuk memastikan bahwa pengguna juga memiliki akses ke operasi yang diminta. Jika API Anda menentukan peran untuk ditetapkan ke pengguna dan grup, mintalah API Anda memeriksa klaim peran apa pun dalam token dan berperilaku sesuai. Token izin aplikasi tidak memiliki klaim cakupan (scp). Sebagai gantinya, minta API Anda memeriksa klaim peran untuk menentukan izin aplikasi mana yang diterima beban kerja.

Setelah API Anda memvalidasi token dan cakupan dan memproses ID objek (oid), kunci subjek (sub), dan klaim peran, API Anda dapat mengembalikan hasilnya.

Langkah berikutnya

  • Contoh API yang dilindungi oleh kerangka kerja persetujuan identitas Microsoft membantu Anda merancang strategi izin aplikasi hak istimewa paling sedikit untuk pengalaman pengguna terbaik.
  • Memanggil API dari API lain membantu Anda memastikan Zero Trust saat Anda memiliki satu API yang perlu memanggil API lain dan mengembangkan aplikasi Anda dengan aman saat bekerja atas nama pengguna.
  • Kustomisasi token menjelaskan informasi yang dapat Anda terima di token Microsoft Entra. Ini menjelaskan cara menyesuaikan token untuk meningkatkan fleksibilitas dan kontrol sambil meningkatkan keamanan kepercayaan nol aplikasi dengan hak istimewa paling sedikit.
  • Mengonfigurasi klaim grup dan peran aplikasi dalam token menunjukkan kepada Anda cara mengonfigurasi aplikasi dengan definisi peran aplikasi dan menetapkan grup keamanan ke peran aplikasi. Metode ini membantu meningkatkan fleksibilitas dan kontrol sekaligus meningkatkan keamanan nol kepercayaan aplikasi dengan hak istimewa paling sedikit.
  • Memperoleh otorisasi untuk mengakses sumber daya membantu Anda memahami cara terbaik memastikan Zero Trust saat memperoleh izin akses sumber daya untuk aplikasi Anda.
  • Meminta izin yang memerlukan persetujuan administratif menjelaskan izin dan pengalaman persetujuan saat izin aplikasi memerlukan persetujuan administratif.
  • Dalam Mulai Cepat ini: Lindungi API web dengan platform identitas Microsoft, pelajari cara melindungi API web ASP.NET dengan membatasi akses ke sumber dayanya ke akun yang diotorisasi saja.
  • Dalam Tutorial ini - Mengubah dan melindungi API Anda di Azure API Management, pelajari tentang mengonfigurasi kebijakan umum untuk menyembunyikan info tumpukan teknologi atau URL asli dalam respons HTTP API.