Ketahanan melalui praktik terbaik pengembang

Artikel
10/24/2023

Dalam artikel ini, kami membagikan beberapa pembelajaran yang berbasis pengalaman kami dalam bekerja dengan pelanggan besar. Anda dapat mempertimbangkan rekomendasi ini dalam desain dan penerapan layanan Anda.

Gambar ini memperlihatkan komponen pengalaman pengembang

Menggunakan Microsoft Authentication Library (MSAL)

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

Pengembang harus mengadopsi rilis terbaru MSAL dan tetap terbarui. Lihat cara meningkatkan ketahanan autentikasi dan otorisasi dalam aplikasi Anda. Jika memungkinkan, hindari menerapkan tumpukan autentikasi Anda sendiri dan gunakan pustaka yang dibangun dengan baik.

Mengoptimalkan baca dan tulis direktori

Layanan direktori Azure AD B2C mendukung miliaran autentikasi sehari. Ini dirancang untuk tingkat bacaan 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: Jangan pernah mengeksekusi tulis saat masuk tanpa prasyarat (jika klausul) dalam kebijakan kustom Anda. Satu kasus penggunaan yang memerlukan fungsi tulis pada rincian masuk adalah migrasi tepat waktu kata sandi pengguna. Hindari skenario apa pun yang memerlukan fungsi tulis di setiap rincian masuk. Prasyarat dalam perjalanan akan terlihat seperti ini:
```
<Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>
```
Memahami pembatasan: Direktori menerapkan aturan pembatasan tingkat aplikasi dan penyewa. Ada batas laju lebih lanjut untuk operasi Read/GET, Write/POST, Update/PUT, dan Delete/DELETE dan setiap operasi memiliki batas yang berbeda.
- Fungsi tulis pada saat masuk akan berada di bawah POST untuk pengguna baru atau PUT untuk pengguna yang sudah ada.
- Kebijakan kustom yang membuat atau memperbarui pengguna pada setiap login, berpotensi mencapai batas laju 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). Pastikan untuk menguji sistem Azure Active Directory B2C dan aplikasi Anda untuk lalu lintas puncak. Ada kemungkinan bahwa Azure AD B2C dapat menangani beban tanpa pembatasan, ketika aplikasi atau layanan hilir Anda tidak akan.
- Pahami dan rencanakan garis waktu migrasi Anda. Saat berencana memigrasikan pengguna ke Azure Active Directory B2C menggunakan Microsoft Graph, pertimbangkan batas aplikasi dan penyewa untuk menghitung waktu yang diperlukan untuk menyelesaikan migrasi pengguna. Jika Anda membagi pekerjaan atau skrip pembuatan pengguna menggunakan dua aplikasi, Anda dapat menggunakan batas per aplikasi. Itu masih harus tetap di bawah ambang batas per penyewa.
- Pahami efek pekerjaan migrasi Anda pada aplikasi lain. Pertimbangkan lalu lintas langsung yang dilayani oleh aplikasi mengandalkan lainnya untuk memastikan Anda tidak menyebabkan 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 Active Directory B2C.

Perpanjang masa pakai token

Dalam kejadian yang tidak mungkin, ketika layanan autentikasi Azure Active Directory B2C tidak dapat menyelesaikan pendaftaran dan proses masuk baru, Anda masih dapat memberikan mitigasi bagi pengguna yang masuk. Dengan konfigurasi, Anda dapat mengizinkan pengguna yang sudah masuk untuk terus menggunakan aplikasi tanpa gangguan yang dirasakan sampai pengguna keluar dari aplikasi atau waktu sesi habis karena tidak aktif.

Persyaratan bisnis Anda dan pengalaman pengguna akhir yang diinginkan akan menentukan frekuensi penyegaran token Anda untuk aplikasi web dan Halaman Tunggal (SPA).

Cara memperpanjang masa pakai token

Aplikasi web: Untuk aplikasi web di mana token autentikasi divalidasi pada awal proses masuk, aplikasi bergantung pada cookie sesi untuk terus memperpanjang masa berlaku sesi. Memungkinkan pengguna untuk tetap masuk dengan menerapkan waktu sesi bergulir yang akan terus memperbarui sesi berdasarkan aktivitas pengguna. Jika ada pemadaman penerbitan token jangka panjang, waktu sesi ini dapat ditingkatkan lebih lanjut sebagai konfigurasi satu kali pada aplikasi. Jaga masa pakai sesi hingga maksimum yang diizinkan.
SPA: 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 Anda untuk memungkinkan pengguna terus menggunakan aplikasi. Jika SPA Anda saat ini 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. Jika Anda tetap menggunakan alur implisit, perlu diingat bahwa alur implisit yang tidak menghasilkan token refresh. SPA dapat menggunakan tersembunyi iframe untuk melakukan permintaan token baru terhadap titik akhir otorisasi jika browser masih memiliki sesi aktif dengan Azure AD B2C. Untuk SPAs, ada beberapa opsi yang tersedia untuk memungkinkan pengguna terus menggunakan aplikasi dalam skenario ini.
- Perluas durasi validitas token akses untuk memenuhi persyaratan bisnis Anda.
- 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 mengirim pengguna melalui proses masuk menggunakan kode otorisasi yang diberikan berdasarkan kebijakan dan mengautentikasi pengguna. Kemudian sesi autentikasi antara gateway API dan klien dipertahankan menggunakan cookie autentikasi. API gateway melayani API menggunakan token yang diperoleh oleh gateway API (atau beberapa metode autentikasi langsung lainnya seperti sertifikat, kredensial klien, atau kunci API).
- Beralih ke opsi yang direkomendasikan dengan memigrasikan SPA Anda dari pemberian implisit ke alur pemberian kode otorisasi dengan dukungan Proof Key for Code Exchange (PKCE) dan Berbagi Sumber Daya Lintas asal (CORS).
- Untuk aplikasi seluler, disarankan untuk memperpanjang masa pakai token akses dan penyegaran.
Aplikasi backend atau microservice: Karena aplikasi backend (daemon) non-interaktif dan tidak dalam konteks pengguna, kemungkinan pencurian token sangat berkurang. Rekomendasinya adalah untuk mencapai keseimbangan antara keamanan dan masa pakai dan menetapkan masa pakai token yang panjang.

Mengonfigurasikan Akses menyeluruh

Dengan Akses menyeluruh (SSO), pengguna masuk satu kali dengan satu akun dan mendapatkan akses ke beberapa aplikasi. Aplikasi ini dapat berupa aplikasi web, seluler, atau halaman tunggal (SPA), terlepas dari platform atau nama domainnya. Ketika pengguna pertama kali masuk ke aplikasi, Azure Active Directory B2C mempertahankan sesi berbasis cookie.

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

Cara mengonfigurasi SSO

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

Praktik penyebaran yang aman

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

Lindungi dari bot

Lindungi aplikasi Anda dari kerentanan yang diketahui seperti serangan Distributed Denial of Service (DDoS), injeksi SQL, scripting lintas situs, eksekusi kode jarak jauh, dan banyak lainnya seperti yang didokumentasikan dalam OWASP Top 10. Penyebaran Web Application Firewall (WAF) dapat bertahan terhadap eksploitasi dan kerentanan umum.

Gunakan Azure WAF, yang memberikan perlindungan terpusat terhadap serangan.
Gunakan WAF dengan Microsoft Entra Identity Protection dan Conditional Access untuk memberikan perlindungan multi-lapisan saat menggunakan Azure AD B2C.
Membangun resistans terhadap pendaftaran dengan integrasi sistem CAPTCHA otomatis.

Rotasi 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) menyebut rentang waktu di mana kunci tertentu diotorisasi untuk digunakan oleh entitas yang sah sebagai cryptoperiod. Pilih panjang cryptoperiod yang tepat untuk memenuhi kebutuhan bisnis Anda. Pengembang perlu mengatur kedaluwarsa secara manual dan merotasi rahasia jauh sebelum kedaluwarsa.

Cara mengimplementasikan 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.
Inventarisasi semua kunci dan sertifikat yang dikonfigurasi di Azure Active Directory B2C. Daftar ini kemungkinan menyertakan kunci yang digunakan dalam kebijakan kustom, API, token ID penandatanganan, dan sertifikat untuk SAML.
Menggunakan CICD, rotasikan rahasia yang akan kedaluwarsa dalam waktu dua bulan dari musim puncak yang diantisipasi. Cryptoperiod maksimum yang direkomendasikan dari kunci pribadi yang terkait dengan sertifikat adalah satu tahun.
Secara proaktif memantau dan merotasi info masuk akses API seperti kata sandi, dan sertifikat.

Menguji REST API

Dalam konteks ketahanan, pengujian REST API perlu menyertakan verifikasi – kode HTTP, muatan respons, header, dan performa. Pengujian seharusnya tidak hanya mencakup pengujian happy path, tetapi juga memeriksa apakah API menangani skenario masalah dengan baik.

Cara menguji API

Kami merekomendasikan rencana pengujian Anda untuk menyertakan pengujian API yang komprehensif. Jika Anda berencana untuk lonjakan yang akan datang karena promosi atau lalu lintas liburan, Anda perlu merevisi pengujian beban Anda dengan perkiraan baru. Lakukan pengujian beban API dan Jaringan Pengiriman Konten (CDN) Anda di lingkungan pengembang dan bukan di lingkungan produksi.

Share via