Autentikasi dengan Azure AD

  • Artikel
  • 11 menit untuk membaca

Autentikasi adalah proses yang memberikan atau menolak akses ke sistem dengan memverifikasi identitas aksesori. Gunakan layanan identitas terkelola untuk semua sumber daya untuk menyederhanakan manajemen secara keseluruhan (seperti kebijakan kata sandi) dan meminimalkan risiko pengawasan atau kesalahan manusia. Azure Active Directory (Azure AD) adalah layanan manajemen identitas dan akses satu atap untuk Azure.

Poin-poin penting

  • Gunakan Identitas Terkelola untuk mengakses sumber daya di Azure.
  • Jaga agar direktori cloud dan lokal disinkronkan, kecuali untuk akun dengan hak istimewa tinggi.
  • Sebaiknya gunakan metode tanpa kata sandi atau pilih metode kata sandi modern.
  • Aktifkan akses bersyarat Azure AD berdasarkan atribut keamanan utama saat mengautentikasi semua pengguna, terutama untuk akun dengan hak istimewa tinggi.

Gunakan autentikasi berbasis identitas

Bagaimana aplikasi diautentikasi saat berkomunikasi dengan layanan platform Azure?

Identitas terkelola memungkinkan Azure Services untuk mengautentikasi satu sama lain tanpa menghadirkan info masuk eksplisit melalui kode.

Identitas terkelola untuk sumber daya Azure adalah fitur Azure Active Directory. Setiap layanan Azure yang mendukung identitas terkelola untuk sumber daya Azure tunduk pada garis waktu mereka masing-masing. Pastikan Anda meninjau status ketersediaan identitas terkelola untuk sumber daya dan masalah yang diketahui sebelum Anda memulai. Fitur ini menyediakan layanan Azure dengan identitas yang dikelola secara otomatis di Azure AD. Anda dapat menggunakan identitas yang terkelola untuk mengautentikasi layanan apa pun yang mendukung autentikasi Azure AD, termasuk Key Vault, tanpa info masuk apa pun dalam kode Anda. Fitur identitas terkelola untuk sumber daya Azure bersifat gratis dengan langganan Azure AD untuk Azure, tidak ada biaya tambahan.

Ada dua jenis identitas terkelola:

  • Identitas terkelola yang ditetapkan sistem diaktifkan langsung pada instans layanan Azure. Saat identitas diaktifkan, Azure membuat identitas untuk instans di penyewa Azure AD yang dipercayai oleh langganan instans. Setelah identitas dibuat, kredensial disediakan ke instans. Siklus hidup identitas yang ditetapkan sistem unik untuk instans layanan Azure yang diaktifkan. Jika instans dihapus, Azure secara otomatis membersihkan kredensial dan identitas di Azure AD.
  • Identitas terkelola yang ditetapkan pengguna dibuat sebagai sumber daya Azure mandiri. Melalui proses pembuatan, Azure membuat identitas di penyewa Azure AD yang dipercayai oleh langganan yang digunakan. Setelah identitas dibuat, identitas dapat ditetapkan ke satu atau beberapa instans layanan Azure. Siklus hidup identitas yang ditetapkan pengguna dikelola secara terpisah dari siklus hidup instans layanan Azure yang ditetapkannya.

Autentikasi dengan layanan identitas, alih-alih kunci kriptografi. Di Azure, Identitas Terkelola menghilangkan kebutuhan untuk menyimpan info masuk yang mungkin bocor secara tidak sengaja. Saat Identitas Terkelola diaktifkan untuk sumber daya Azure, identitas tersebut akan diberi identitas yang dapat Anda gunakan untuk mendapatkan token Azure AD. Untuk informasi selengkapnya, lihat Identitas yang dikelola Azure AD untuk sumber daya Azure.

Misalnya, kluster Azure Kubernetes Service (AKS) perlu menarik gambar dari Azure Container Registry (ACR). Untuk mengakses gambar, kluster perlu mengetahui info masuk ACR. Cara yang disarankan adalah mengaktifkan Identitas Terkelola selama konfigurasi kluster. Konfigurasi tersebut menetapkan identitas ke kluster dan memungkinkannya untuk mendapatkan token Azure AD.

Pendekatan ini aman karena Azure menangani pengelolaan info masuk yang mendasarinya untuk Anda.

  • Identitas terkait dengan siklus hidup sumber daya, dalam contoh kluster AKS. Saat sumber daya dihapus, Azure secara otomatis menghapus identitas.
  • Azure AD mengelola rotasi rahasia tepat waktu untuk Anda.

Tip

Berikut adalah sumber daya untuk contoh sebelumnya:

GitHub logoGitHub: Penerapan Referensi Garis Besar Aman Azure Kubernetes Service (AKS).

Pertimbangan desain dijelaskan dalam Garis besar produksi Azure Kubernetes Service (AKS).

Tindakan yang disarankan

  • Tinjau autentikasi beban kerja dan identifikasi peluang untuk mengonversi info masuk eksplisit (misalnya, string koneksi dan kunci API) untuk menggunakan identitas terkelola.
  • Untuk semua beban kerja Azure baru, standarisasi penggunaan identitas terkelola jika berlaku.

Pelajari lebih lanjut

Apa yang dimaksud dengan identitas terkelola untuk sumber daya Azure?

Autentikasi seperti apa yang diperlukan oleh API aplikasi?

Jangan berasumsi bahwa URL API yang digunakan oleh beban kerja disembunyikan dan tidak dapat terkena penyerang. Misalnya, kode JavaScript di situs web dapat dilihat. Aplikasi seluler dapat didekompilasi dan diperiksa. Bahkan untuk API internal yang hanya digunakan pada backend, persyaratan autentikasi dapat meningkatkan kesulitan gerakan lateral jika penyerang mendapat akses jaringan. Mekanisme serupa termasuk kunci API, token otorisasi, dan pembatasan IP.

Identitas Terkelola dapat membantu API menjadi lebih aman karena menggantikan penggunaan perwakilan layanan yang dikelola manusia dan dapat meminta token otorisasi.

Bagaimana autentikasi pengguna ditangani dalam aplikasi?

Jangan gunakan penerapan kustom untuk mengelola info masuk pengguna. Sebagai gantinya, gunakan Azure AD atau penyedia identitas terkelola lainnya seperti akun Microsoft Azure B2C. Penyedia identitas terkelola menyediakan fitur keamanan tambahan seperti perlindungan kata sandi modern, autentikasi multifaktor (MFA), dan reset. Secara umum, perlindungan tanpa kata sandi lebih disukai. Selain itu, protokol modern seperti OAuth 2.0 menggunakan autentikasi berbasis token dengan rentang waktu terbatas.

Apakah token autentikasi di-cache dengan aman dan dienkripsi saat berbagi di seluruh server web?

Kode aplikasi pertama-tama harus mencoba untuk mendapatkan token akses OAuth secara diam-diam dari cache sebelum mencoba memperoleh token dari penyedia identitas, untuk mengoptimalkan performa dan memaksimalkan ketersediaan. Token harus disimpan dengan aman dan ditangani sebagai info masuk lainnya. Saat ada kebutuhan untuk berbagi token di seluruh server aplikasi (bukan setiap server yang memperoleh dan penembolokan sendiri) enkripsi harus digunakan.

Untuk informasi, lihat Memperoleh dan menyimpan token.

Pilih sistem dengan dukungan lintas platform

Gunakan penyedia identitas tunggal untuk autentikasi di semua platform (sistem operasi, penyedia cloud, dan layanan pihak ketiga.

Azure AD dapat digunakan untuk mengautentikasi Windows, Linux, Azure, Office 365, penyedia cloud lainnya, dan layanan pihak ketiga sebagai penyedia layanan.

Misalnya, meningkatkan keamanan mesin virtual (VM) Linux di Azure dengan integrasi Azure AD. Untuk mengetahui detailnya, lihat Masuk ke mesin virtual Linux di Azure menggunakan autentikasi Azure Active Directory.

Memusatkan semua sistem identitas

Jaga agar identitas cloud Anda disinkronkan dengan sistem identitas yang ada untuk memastikan konsistensi dan mengurangi kesalahan manusia.

Konsistensi identitas di seluruh cloud dan lokal akan mengurangi kesalahan manusia dan risiko keamanan yang dihasilkan. Tim yang mengelola sumber daya di kedua lingkungan membutuhkan sumber otoritatif yang konsisten untuk mencapai jaminan keamanan. Untuk pemantauan, jika identitas dapat ditentukan tanpa proses pemetaan menengah, efisiensi keamanan ditingkatkan.

Sinkronisasi adalah tentang memberi pengguna identitas di cloud berdasarkan identitas lokal mereka. Apakah mereka akan menggunakan akun yang disinkronkan untuk autentikasi atau autentikasi federasi, pengguna masih harus memiliki identitas di cloud. Identitas ini perlu dipertahankan dan diperbarui secara berkala. Pembaruan dapat mengambil banyak formulir, mulai dari perubahan judul hingga perubahan kata sandi.

Mulailah dengan mengevaluasi solusi identitas lokal organisasi dan persyaratan pengguna. Evaluasi ini penting, karena mendefinisikan persyaratan teknis untuk cara identitas pengguna akan dibuat dan dipelihara di cloud. Untuk sebagian besar organisasi, Active Directory ditetapkan secara lokal dan akan berada pada direktori lokal tempat asal pengguna akan disinkronkan, tetapi ini tidak selalu terjadi.

Pertimbangkan untuk menggunakan Azure AD Connect untuk menyinkronkan Azure AD dengan direktori lokal yang ada. Untuk proyek migrasi, miliki persyaratan untuk menyelesaikan tugas ini sebelum proyek migrasi dan pengembangan Azure dimulai.

Penting

Jangan menyinkronkan akun dengan hak istimewa tinggi ke direktori lokal. Jika penyerang mendapat kendali penuh atas aset lokal, mereka dapat menyusupi akun cloud. Strategi ini akan membatasi cakupan suatu insiden. Untuk informasi selengkapnya, lihat Dependensi akun dampak kritis.

Sinkronisasi diblokir secara default dalam konfigurasi Azure AD Connect default. Pastikan Anda belum menyesuaikan konfigurasi ini. Untuk informasi tentang pemfilteran di Azure AD, lihat Sinkronisasi Azure AD Connect: Mengonfigurasi pemfilteran.

Untuk informasi selengkapnya, lihat penyedia identitas hibrid.

Tip

Berikut adalah sumber daya untuk contoh sebelumnya:

Pertimbangan desain dijelaskan dalam Mengintegrasikan domain Active Directory lokal dengan Azure AD.

Pelajari lebih lanjut

Menyinkronkan sistem identitas hibrid

Menggunakan autentikasi tanpa kata sandi

Penyerang terus memindai rentang IP cloud publik untuk port manajemen terbuka. Mereka mencoba untuk mengeksploitasi info masuk yang lemah (semprotan kata sandi) dan kerentanan yang belum ditambal dalam protokol manajemen seperti SSH, dan RDP. Mencegah akses internet langsung ke mesin virtual menghentikan kesalahan konfigurasi atau pengawasan menjadi lebih serius.

Metode serangan telah berkembang ke titik saat kata sandi saja tidak dapat melindungi akun dengan andal. Solusi autentikasi modern termasuk autentikasi tanpa kata sandi dan multifaktor meningkatkan postur keamanan melalui autentikasi yang kuat.

Hapus penggunaan kata sandi, jika memungkinkan. Juga, wajibkan serangkaian info masuk yang sama untuk masuk dan mengakses sumber daya lokal atau di cloud. Persyaratan ini sangat penting untuk akun yang memerlukan kata sandi, seperti akun admin.

Dengan fitur keamanan dan autentikasi modern di Azure AD, kata sandi dasar tersebut harus dilengkapi atau diganti dengan metode autentikasi yang lebih aman. Setiap organisasi memiliki kebutuhan yang berbeda dalam hal autentikasi. Microsoft menawarkan tiga opsi autentikasi tanpa kata sandi berikut yang terintegrasi dengan Azure Active Directory (Microsoft Azure AD):

  • Windows Hello untuk Bisnis
  • Aplikasi Microsoft Authenticator
  • Kunci keamanan FIDO2

Disarankan untuk mengikuti rencana empat tahap untuk menjadi tanpa kata sandi:

  • Mengembangkan penawaran penggantian kata sandi
  • Mengurangi area permukaan kata sandi yang terlihat pengguna
  • Transisi ke penyebaran tanpa kata sandi
  • Menghilangkan kata sandi dari direktori identitas

Metode autentikasi berikut diurutkan berdasarkan biaya/kesulitan tertinggi untuk menyerang (opsi terkuat/pilihan yang disukai) dengan biaya terendah/sulit diserang:

Metode tersebut berlaku untuk semua pengguna, tetapi harus diterapkan terlebih dahulu dan terkuat untuk akun dengan hak istimewa admin.

Implementasi strategi ini memungkinkan akses menyeluruh (SSO) ke perangkat, aplikasi, dan layanan. Dengan masuk sekali menggunakan satu akun pengguna, Anda dapat memberikan akses ke semua aplikasi dan sumber daya sesuai kebutuhan bisnis. Pengguna tidak perlu mengelola beberapa set nama pengguna dan kata sandi. Anda dapat memprovisikan atau membatalkan provisi akses aplikasi secara otomatis. Untuk informasi selengkapnya, lihat Akses menyeluruh.

Tindakan yang disarankan

  • Kembangkan strategi tanpa kata sandi yang membutuhkan MFA untuk semua pengguna tanpa berdampak signifikan terhadap operasi.
  • Memastikan kebijakan dan proses memerlukan pembatasan, dan pemantauan konektivitas internet langsung oleh mesin virtual.

Pelajari lebih lanjut

Menggunakan perlindungan kata sandi modern

Memerlukan perlindungan modern melalui metode yang mengurangi penggunaan kata sandi. Protokol autentikasi modern mendukung kontrol yang kuat seperti MFA dan harus digunakan sebagai pengganti metode autentikasi lama. Penggunaan metode warisan meningkatkan risiko paparan info masuk.

Autentikasi modern adalah metode manajemen identitas yang menawarkan autentikasi dan otorisasi pengguna yang lebih aman. Ini tersedia untuk penyebaran hibrid Office 365 untuk server Skype for Business lokal dan server Exchange lokal, dan hibrid Skype for Business domain terpisah.

Autentikasi modern adalah istilah umum untuk kombinasi metode autentikasi dan otorisasi antara klien (misalnya, laptop atau ponsel Anda) dan server, serta beberapa langkah keamanan yang bergantung pada kebijakan akses yang mungkin sudah Anda pahami. Hal tersebut mencakup:

  • Metode autentikasi: MFA; autentikasi kartu pintar; autentikasi berbasis sertifikat klien
  • Metode otorisasi: Implementasi Open Authorization (OAuth) Microsoft
  • Kebijakan akses bersyarat: Akses Bersyarat Manajemen Aplikasi Perangkat Bergerak (MAM) dan Azure Active Directory (Azure AD)

Tinjau beban kerja yang tidak memanfaatkan protokol autentikasi modern dan konversi jika memungkinkan. Selain itu, standarisasi menggunakan protokol autentikasi modern untuk semua beban kerja di masa mendatang.

Untuk Azure, aktifkan perlindungan di Azure AD:

  1. Konfigurasikan Azure AD Connect untuk menyinkronkan hash kata sandi. Untuk informasi, lihat Menerapkan sinkronisasi hash kata sandi dengan Sinkronisasi Azure AD Connect.

  2. Pilih apakah akan memulihkan masalah yang ditemukan dalam laporan secara otomatis atau manual. Untuk informasi selengkapnya, lihat Memantau risiko identitas.

Untuk informasi selengkapnya tentang mendukung kata sandi modern di Azure AD, lihat artikel berikut:

Untuk informasi selengkapnya tentang mendukung kata sandi modern di Office 365, lihat artikel berikut:

Apa itu autentikasi modern?

Mengaktifkan akses bersyarat

Aplikasi berbasis cloud modern biasanya dapat diakses melalui internet, membuat akses berbasis lokasi jaringan tidak fleksibel dan kata sandi faktor tunggal menjadi tanggung jawab. Akses bersyarat menjelaskan kebijakan autentikasi Anda untuk keputusan akses. Misalnya, jika pengguna terhubung dari PC perusahaan yang dikelola InTune, mereka mungkin tidak ditantang untuk MFA setiap saat, tetapi jika pengguna tiba-tiba terhubung dari perangkat yang berbeda dalam geografi yang berbeda, MFA diperlukan.

Berikan permintaan akses berdasarkan tingkat kepercayaan pemohon dan sensitivitas sumber daya target.

Apakah ada persyaratan akses bersyarat untuk aplikasi?

Beban kerja dapat diekspos melalui internet publik dan kontrol jaringan berbasis lokasi tidak berlaku. Untuk mengaktifkan akses bersyarat, pahami batasan apa yang diperlukan untuk kasus penggunaan. Misalnya, MFA adalah kebutuhan untuk akses jarak jauh; Pemfilteran berbasis IP dapat digunakan untuk mengaktifkan penelusuran kesalahan adhoc (VPN lebih disukai).

Konfigurasikan Azure AD Conditional Access dengan menyiapkan kebijakan Access untuk manajemen Azure berdasarkan kebutuhan operasional Anda. Untuk informasi, lihat Mengelola akses ke manajemen Azure dengan Akses Bersyarat.

Akses bersyarat dapat menjadi cara yang efektif untuk menghapus autentikasi warisan dan protokol terkait. Kebijakan harus diberlakukan untuk semua admin dan akun dampak kritis lainnya. Mulailah dengan menggunakan metrik dan log untuk menentukan pengguna yang masih mengautentikasi dengan klien lama. Selanjutnya, nonaktifkan protokol tingkat bawah yang tidak digunakan, dan siapkan akses bersyarat untuk semua pengguna yang tidak menggunakan protokol warisan. Terakhir, berikan pemberitahuan dan panduan kepada pengguna tentang peningkatan sebelum memblokir autentikasi warisan sepenuhnya. Untuk informasi selengkapnya, lihat Dukungan Akses Bersyarat Azure AD untuk memblokir autentikasi lama.

Tindakan yang disarankan

Menerapkan kebijakan akses bersyarat untuk beban kerja ini.

Pelajari lebih lanjut tentang Akses Bersyarat Azure AD.

Berikutnya

Memberikan atau menolak akses ke sistem dengan memverifikasi identitas aksesori.

Authorization

Kembali ke artikel utama: Pertimbangan identitas dan manajemen akses Azure