Bagikan melalui

Ketahanan melalui praktik terbaik pengembang

  • Artikel

Dalam artikel ini, Anda dapat memperoleh manfaat dari pengalaman kami bekerja dengan pelanggan besar. Anda dapat mempertimbangkan rekomendasi ini untuk desain dan implementasi layanan Anda.

Pustaka Autentikasi Microsoft

Microsoft Authentication Library (MSAL) dan pustaka autentikasi web identitas Microsoft untuk ASP.NET menyederhanakan memperoleh, mengelola, menyimpan cache, dan menyegarkan token untuk aplikasi. Pustaka ini dioptimalkan untuk mendukung Identitas Microsoft, termasuk fitur yang meningkatkan ketahanan aplikasi.

Pengembang dapat mengadopsi rilis MSAL terbaru dan tetap mendapatkan informasi terbaru. Lihat cara meningkatkan ketahanan autentikasi dan otorisasi dalam aplikasi Anda. Jika memungkinkan, hindari menerapkan tumpukan autentikasi Anda sendiri. Sebagai gantinya, gunakan pustaka yang mapan.

Mengoptimalkan baca dan tulis direktori

Layanan direktori Azure AD B2C mendukung miliaran autentikasi sehari, dengan tingkat baca yang tinggi per detik. Optimalkan penulisan Anda, untuk meminimalkan ketergantungan dan meningkatkan ketahanan.

Cara mengoptimalkan membaca dan menulis direktori

  • Hindari fungsi tulis ke direktori saat masuk: Hindari menjalankan tulis saat masuk tanpa prasyarat (jika klausa) dalam kebijakan kustom Anda. Satu kasus penggunaan yang memerlukan fungsi tulis pada rincian masuk adalah migrasi tepat waktu kata sandi pengguna. Tidak memerlukan tulisan pada setiap rincian masuk. Prasyarat dalam perjalanan pengguna adalah:

    <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>

  • Memahami pembatasan: Direktori menerapkan aturan pembatasan tingkat aplikasi dan penyewa. Ada lebih banyak batas tarif untuk operasi Baca/DAPATKAN, Tulis/POSTING, Perbarui/PUT, dan Hapus/HAPUS. Setiap operasi memiliki batas yang berbeda.

    • Tulis selama masuk berada di bawah POST untuk pengguna baru atau PUT untuk pengguna saat ini.
    • Kebijakan kustom yang membuat atau memperbarui pengguna pada setiap rincian masuk, dapat mencapai batas tingkat PUT atau POST tingkat aplikasi. Batas yang sama berlaku saat memperbarui objek direktori melalui ID Microsoft Entra atau Microsoft Graph. Demikian pula, periksa bacaan untuk meminimalkan jumlah bacaan pada setiap proses masuk.
    • Perkirakan beban puncak untuk memprediksi tingkat penulisan direktori dan menghindari pembatasan. Perkiraan lalu lintas puncak harus mencakup perkiraan untuk tindakan seperti pendaftaran, masuk, dan autentikasi multifaktor (MFA). Uji sistem Azure AD B2C dan aplikasi Anda untuk lalu lintas puncak. Azure AD B2C dapat menangani beban tanpa pembatasan, saat aplikasi atau layanan hilir Anda tidak akan.
    • Pahami dan rencanakan garis waktu migrasi Anda. Saat berencana untuk memigrasikan pengguna ke Azure AD B2C menggunakan Microsoft Graph, pertimbangkan batas aplikasi dan penyewa untuk menghitung waktu untuk menyelesaikan migrasi pengguna. Jika Anda membagi pekerjaan atau skrip pembuatan pengguna menggunakan dua aplikasi, Anda dapat menggunakan batas per aplikasi. Pastikan tetap di bawah ambang batas per penyewa.
    • Pahami efek pekerjaan migrasi Anda pada aplikasi lain. Pertimbangkan lalu lintas langsung yang dilayani oleh aplikasi pengandal lainnya untuk memastikan tidak ada pembatasan di tingkat penyewa dan kelaparan sumber daya untuk aplikasi langsung Anda. Untuk informasi selengkapnya, lihat panduan pembatasan Microsoft Graph.
    • Gunakan sampel uji beban untuk mensimulasikan pendaftaran dan masuk.
    • Pelajari selengkapnya tentang batas dan batasan layanan Azure AD B2C.

Masa pakai token

Jika layanan autentikasi Azure AD B2C tidak dapat menyelesaikan pendaftaran dan rincian masuk baru, berikan mitigasi bagi pengguna yang masuk. Dengan konfigurasi, pengguna yang masuk dapat menggunakan aplikasi tanpa gangguan sampai mereka keluar dari aplikasi, atau waktu sesi habis dari tidak aktif.

Persyaratan bisnis dan pengalaman pengguna akhir Anda menentukan frekuensi refresh token untuk aplikasi web dan satu halaman (SPAs).

Perpanjang masa pakai token

  • Aplikasi web: Untuk aplikasi web tempat token autentikasi divalidasi saat masuk, aplikasi bergantung pada cookie sesi untuk terus memperpanjang validitas sesi. Memungkinkan pengguna untuk tetap masuk dengan menerapkan waktu sesi bergulir yang diperpanjang berdasarkan aktivitas pengguna. Jika ada pemadaman penerbitan token jangka panjang, waktu sesi ini dapat ditingkatkan sebagai konfigurasi satu kali pada aplikasi. Jaga masa pakai sesi hingga maksimum yang diizinkan.
  • SPAs: SPA mungkin bergantung pada token akses untuk melakukan panggilan ke API. Untuk SPAs, sebaiknya gunakan alur kode otorisasi dengan alur Proof Key for Code Exchange (PKCE) sebagai opsi untuk memungkinkan pengguna terus menggunakan aplikasi. Jika SPA Anda menggunakan alur implisit, pertimbangkan untuk bermigrasi ke alur kode otorisasi dengan PKCE. Migrasikan aplikasi Anda dari MSAL.js 1.x ke MSAL.js 2.x untuk mewujudkan ketahanan aplikasi web. Alur implisit tidak menghasilkan token refresh. SPA dapat menggunakan tersembunyi iframe untuk melakukan permintaan token baru terhadap titik akhir otorisasi jika browser memiliki sesi aktif dengan Azure AD B2C. Untuk SPAs, ada beberapa opsi untuk memungkinkan pengguna untuk terus menggunakan aplikasi.
    • Perluas durasi validitas token akses.
    • Buat aplikasi Anda untuk menggunakan gateway API sebagai proksi autentikasi. Dalam konfigurasi ini, SPA dimuat tanpa autentikasi dan panggilan API dilakukan ke gateway API. Gateway API mengirimkan pengguna melalui proses masuk menggunakan pemberian kode otorisasi, berdasarkan kebijakan, dan mengautentikasi pengguna. Sesi autentikasi antara gateway API dan klien dipertahankan menggunakan cookie autentikasi. API gateway melayani API menggunakan token yang diperoleh oleh gateway API, atau metode autentikasi langsung lainnya seperti sertifikat, kredensial klien, atau kunci API.
    • Beralih ke opsi yang direkomendasikan. Migrasikan SPA Anda dari pemberian implisit ke alur pemberian kode otorisasi dengan dukungan Proof Key for Code Exchange (PKCE) dan Cross-Origin Resource Sharing (CORS).
    • Untuk aplikasi seluler, perluas masa pakai token refresh dan akses.
  • Aplikasi back-end atau layanan mikro: Aplikasi back-end (daemon) non-interaktif dan tidak dalam konteks pengguna, oleh karena itu prospek pencurian token berkurang. Rekomendasi kami adalah mencapai keseimbangan antara keamanan dan masa pakai dan menetapkan masa pakai token yang panjang.

Akses menyeluruh

Dengan akses menyeluruh (SSO), pengguna masuk sekali dengan akun dan mendapatkan akses ke aplikasi: web, seluler, atau aplikasi satu halaman (SPA), terlepas dari platform atau nama domain. Saat pengguna masuk ke aplikasi, Azure AD B2C mempertahankan sesi berbasis cookie.

Setelah permintaan autentikasi berikutnya, Azure AD B2C membaca dan memvalidasi sesi berbasis cookie dan mengeluarkan token akses tanpa meminta pengguna untuk masuk. Jika SSO dikonfigurasi dengan cakupan terbatas pada kebijakan atau aplikasi, akses nanti ke kebijakan dan aplikasi lain memerlukan autentikasi baru.

Konfigurasikan akses menyeluruh

Konfigurasikan SSO menjadi seluruh penyewa (default) agar mengizinkan beberapa aplikasi dan alur pengguna di penyewa Anda untuk berbagi sesi pengguna yang sama. Konfigurasi seluruh penyewa memberikan ketahanan terbanyak untuk autentikasi baru.

Praktik penyebaran yang aman

Gangguan layanan yang paling umum adalah perubahan kode dan konfigurasi. Adopsi proses dan alat Integrasi Berkelanjutan dan Pengiriman Berkelanjutan (CICD) memungkinkan penyebaran dalam skala besar dan mengurangi kesalahan manusia selama pengujian dan penyebaran. Mengadopsi CICD untuk pengurangan kesalahan, efisiensi, dan konsistensi. Azure Pipelines adalah contoh CICD.

Perlindungan dari bot

Lindungi aplikasi Anda dari kerentanan yang diketahui seperti serangan Distributed Denial of Service (DDoS), injeksi SQL, pembuatan skrip lintas situs, eksekusi kode jarak jauh, dan lainnya yang didokumentasikan dalam OWASP Top-10. Sebarkan Web Application Firewall (WAF) untuk melindungi dari eksploitasi dan kerentanan umum.

Rahasia

Azure Active Directory B2C menggunakan rahasia untuk aplikasi, API, kebijakan, dan enkripsi. Rahasia mengamankan autentikasi, interaksi eksternal, dan penyimpanan. National Institute of Standards and Technology (NIST) mengacu pada rentang waktu otorisasi utama, yang digunakan oleh entitas yang sah, sebagai kriptoperiod. Pilih panjang kriptoperiod yang diperlukan. Atur kedaluwarsa dan putar rahasia sebelum kedaluwarsa.

Menerapkan rotasi rahasia

  • Gunakan identitas terkelola untuk sumber daya yang didukung untuk mengautentikasi ke layanan apa pun yang mendukung autentikasi Microsoft Entra. Ketika Anda menggunakan identitas terkelola, Anda dapat mengelola sumber daya secara otomatis, termasuk rotasi info masuk.
  • Ambil inventarifikasi kunci dan sertifikat yang dikonfigurasi di Azure AD B2C. Daftar ini dapat mencakup kunci yang digunakan dalam kebijakan kustom, API, token ID penandatanganan, dan sertifikat untuk Security Assertion Markup Language (SAML).
  • Menggunakan CICD, putar rahasia yang kedaluwarsa dalam waktu dua bulan dari musim puncak yang diantisipasi. Cryptoperiod maksimum yang direkomendasikan dari kunci pribadi yang terkait dengan sertifikat adalah satu tahun.
  • Pantau dan putar kredensial akses API, seperti kata sandi dan sertifikat.

Pengujian REST API

Untuk ketahanan, pengujian REST API perlu menyertakan verifikasi kode HTTP, payload respons, header, dan performa. Jangan hanya menggunakan pengujian jalur bahagia, dan konfirmasikan API menangani skenario masalah dengan anggun.

Rencana pengujian

Sebaiknya rencana pengujian Anda menyertakan pengujian API yang komprehensif. Untuk lonjakan karena promosi, atau lalu lintas liburan, revisi pengujian beban dengan perkiraan baru. Lakukan pengujian beban API dan Content Delivery Network (CDN) di lingkungan pengembang, bukan dalam produksi.

Langkah berikutnya