Merencanakan penyebaran Proksi Aplikasi Microsoft Azure Active Directory

Proksi Aplikasi Azure Active Directory (Azure AD) adalah solusi akses jarak jauh yang aman dan hemat biaya untuk aplikasi lokal. Ini menyediakan jalur transisi lebih cepat bagi organisasi "Cloud First" untuk mengelola akses ke aplikasi lokal terdahulu yang belum mampu menggunakan protokol modern. Untuk informasi pengantar tambahan, lihat Apa itu Proksi Aplikasi.

Proksi Aplikasi disarankan untuk memberikan akses ke sumber daya internal kepada pengguna jarak jauh. Proksi Aplikasi menggantikan kebutuhan VPN atau proxy terbalik untuk kasus penggunaan akses jarak jauh ini. Ini tidak ditujukan bagi pengguna internal di jaringan perusahaan. Pengguna yang menggunakan Proksi Aplikasi untuk akses intranet mungkin mengalami masalah kinerja yang tidak diinginkan.

Artikel ini mencakup sumber daya yang Anda butuhkan untuk merencanakan, mengoperasikan, dan mengelola Proksi Aplikasi Microsoft Azure Active Directory.

Merencanakan implementasi Anda

Bagian berikut ini memberikan gambaran yang lebih luas tentang elemen perencanaan utama yang akan memberikan Anda pengalaman penyebaran yang efisien.

Prasyarat

Anda harus memenuhi prasyarat berikut sebelum memulai implementasi Anda. Anda dapat melihat informasi lebih lanjut tentang pengaturan lingkungan Anda, termasuk prasyarat ini, dalam tutorial ini.

  • Konektor: Konektor adalah agen ringan yang dapat Anda sebarkan ke:

    • Perangkat keras fisik lokal
    • Komputer Virtual yang dihosting dalam solusi hypervisor apa pun
    • Komputer Virtual yang dihosting di Azure untuk mengaktifkan koneksi keluar ke layanan Proksi Aplikasi.
  • Lihat Memahami Konektor Proksi Aplikasi Microsoft Azure Active Directory untuk ikhtisar yang lebih rinci.

    • Mesin konektor harus diaktifkan untuk TLS 1.2 sebelum menginstal konektor.

    • Jika memungkinkan, sebarkan konektor di jaringan dan segmen yang sama dengan server aplikasi web back-end. Yang terbaik adalah menyebarkan konektor setelah Anda menyelesaikan penemuan aplikasi.

    • Sebaiknya setiap grup konektor memiliki setidaknya dua konektor untuk memberikan ketersediaan dan skala tinggi. Memiliki tiga konektor bersifat optimal jika Anda mungkin perlu melayani mesin kapan saja. Tinjau tabel kapasitas konektor untuk membantu memutuskan tipe mesin apa yang akan pasang konektor. Semakin besar mesin, semakin banyak buffer dan kinerja konektor.

  • Pengaturan akses jaringan: Konektor Proksi Aplikasi Microsoft Azure Active Directory terhubung ke Azure melalui HTTPS (Port TCP 443) dan HTTP (Port TCP 80).

    • Menghentikan lalu lintas TLS konektor tidak didukung dan akan mencegah konektor membuat saluran aman dengan titik akhir Proksi Aplikasi Azure masing-masing.

    • Hindari semua bentuk pemeriksaan sebaris pada komunikasi TLS keluar antara konektor dan Azure. Inspeksi internal antara aplikasi konektor dan backend dimungkinkan, tetapi dapat menurunkan pengalaman pengguna, dan dengan demikian, tidak disarankan.

    • Penyeimbangan beban konektor itu sendiri juga tidak didukung, atau bahkan diperlukan.

Pertimbangan penting sebelum mengonfigurasi Proksi Aplikasi Microsoft Azure Active Directory

Persyaratan inti berikut harus dipenuhi untuk mengonfigurasi dan menerapkan Proksi Aplikasi Microsoft Azure Active Directory.

  • Azure onboarding: Sebelum menerapkan proksi aplikasi, identitas pengguna harus disinkronkan dari direktori lokal atau dibuat langsung di dalam penyewa Microsoft Azure Active Directory Anda. Sinkronisasi identitas memungkinkan Microsoft Azure Active Directory untuk melakukan pra-otentikasi pengguna sebelum memberi mereka akses ke aplikasi yang dipublikasikan Proksi Aplikasi dan memiliki informasi pengidentifikasi pengguna yang diperlukan untuk melakukan akses menyeluruh (SSO).

  • Persyaratan Akses Bersyarat: Kami tidak menyarankan penggunaan Proksi Aplikasi untuk akses intranet karena ini menambah latensi yang akan berdampak pada pengguna. Sebaiknya gunakan Proksi Aplikasi dengan kebijakan pra-autentikasi dan Akses Bersyarat untuk akses jarak jauh dari internet. Pendekatan untuk memprovisikan Akses Bersyarat untuk penggunaan intranet adalah dengan memodernisasi aplikasi sehingga mereka dapat langsung mengautentikasi dengan AAD. Lihat Sumber Daya untuk memigrasikan aplikasi ke Azure Active Directory untuk informasi lebih lanjut.

  • Batas layanan: Untuk melindungi dari kelebihan penggunaan sumber daya oleh penyewa individu ada pembatasan batas yang ditetapkan per aplikasi dan penyewa. Untuk melihat batasan ini, lihat batas dan pembatasan layanan Microsoft Azure Active Directory. Pembatasan batas ini didasarkan pada tolok ukur yang jauh di atas volume penggunaan umum dan menyediakan buffer yang cukup untuk sebagian besar penyebaran.

  • Sertifikat publik: Jika Anda menggunakan nama domain kustom, Anda harus mendapatkan sertifikat TLS/SSL. Bergantung pada persyaratan organisasi Anda, mendapatkan sertifikat dapat memakan waktu dan kami sarankan untuk memulai proses sedini mungkin. Proksi Aplikasi Azure mendukung sertifikat standar, kartu bebas, atau sertifikat berbasis SAN. Untuk lebih rinci lihat Konfigurasikan domain kustom dengan Proksi Aplikasi Azure Active Directory.

  • Persyaratan domain: Akses menyeluruh ke aplikasi yang anda terbitkan menggunakan Kerberos Constrained Delegation (KCD) mengharuskan server yang menjalankan Konektor dan server yang menjalankan aplikasi adalah domain yang bergabung dan bagian dari domain yang sama atau domain kepercayaan. Untuk informasi detail tentang topik ini, lihat KCD untuk akses menyeluruh dengan Proksi Aplikasi. Layanan konektor berjalan dalam konteks sistem lokal dan tidak boleh dikonfigurasi untuk menggunakan identitas kustom.

  • Rekaman DNS untuk URL

    • Sebelum menggunakan domain kustom di Proksi Aplikasi, Anda harus membuat data CNAME di DNS publik, yang memungkinkan klien untuk menyelesaikan URL eksternal kustom yang ditentukan ke alamat Proksi Aplikasi yang telah ditentukan sebelumnya. Gagal membuat data CNAME untuk aplikasi yang menggunakan domain kustom akan mencegah pengguna jarak jauh menyambungkan ke aplikasi. Langkah-langkah yang diperlukan untuk menambahkan data CNAME bisa bervariasi dari penyedia DNS ke penyedia, jadi pelajari cara mengelola catatan DNS dan kumpulan catatan dengan menggunakan portal Microsoft Azure.

    • Demikian pula, host konektor harus dapat menyelesaikan URL internal aplikasi yang dipublikasikan.

  • Hak dan peran administratif

    • Penginstalan konektor memerlukan hak admin lokal ke Windows Server tempatnya diinstal. Ini juga memerlukan minimal peran Administrator Aplikasi untuk mengautentikasi dan mendaftarkan instans konektor ke penyewa Microsoft Azure Active Directory Anda.

    • Penerbitan dan administrasi aplikasi memerlukan peran Administrator Aplikasi. Administrator Aplikasi dapat mengelola semua aplikasi dalam direktori termasuk pendaftaran, pengaturan Akses Menyeluruh, penugasan dan lisensi pengguna dan grup, pengaturan Proksi Aplikasi, dan persetujuan. Ini tidak memberikan kemampuan untuk mengelola Akses Bersyarat. Peran Administrator Aplikasi Cloud memiliki semua kemampuan Administrator Aplikasi, kecuali bahwa itu tidak memungkinkan manajemen pengaturan Proksi Aplikasi.

  • Lisensi: Proksi Aplikasi tersedia melalui langganan Microsoft Azure Active Directory Premium. Lihat halaman Harga Microsoft Azure Active Directory daftar lengkap opsi dan fitur lisensi.

Penemuan aplikasi

Kumpulkan inventaris semua aplikasi dalam lingkup yang dipublikasikan melalui Proksi Aplikasi dengan mengumpulkan informasi berikut:

Tipe informasi Informasi untuk dikumpulkan
Jenis Layanan Misalnya: SharePoint, SAP, CRM, Aplikasi Web Kustom, API
Platform aplikasi Misalnya: Windows IIS, Apache di Linux, Tomcat, NGINX
Keanggotaan domain Nama domain yang sepenuhnya memenuhi syarat (FQDN)
Lokasi aplikasi Di mana web server atau farm berada di infrastruktur Anda
Akses internal URL persis yang digunakan saat mengakses aplikasi secara internal.
Jika sebuah farm, jenis penyeimbangan beban apa yang digunakan?
Apakah aplikasi menarik konten dari sumber selain dirinya sendiri.
Tentukan apakah aplikasi beroperasi melalui WebSocket.
Akses eksternal Solusi vendor bahwa aplikasi mungkin sudah terbuka melalui, secara eksternal.
URL yang ingin Anda gunakan untuk akses eksternal. Jika SharePoint, pastikan Pemetaan Akses Alternatif dikonfigurasi per panduan ini. Jika tidak, Anda harus mendefinisikan URL eksternal.
Sertifikat publik Jika menggunakan domain kustom, mendapatkan sertifikat dengan nama subjek yang sesuai. jika sertifikat ada perhatikan nomor seri dan lokasi dari mana sertifikat dapat diperoleh.
Jenis autentikasi Tipe otentikasi yang didukung oleh dukungan aplikasi seperti Basic, Autentikasi Integrasi Windows, berbasis forms, berbasis header, dan klaim.
Jika aplikasi dikonfigurasi untuk berjalan di bawah akun domain tertentu, perhatikan Nama Domain Yang Sepenuhnya Memenuhi Syarat (FQDN) dari akun layanan.
Jika berbasis SAML, pengidentifikasi dan URL balasan.
Jika berbasis header, solusi vendor dan persyaratan khusus untuk menangani jenis autentikasi.
Nama grup Konektor Nama logis untuk kelompok konektor yang akan ditunjuk untuk menyediakan saluran dan Akses Menyeluruh, ke aplikasi backend ini.
Akses pengguna/grup Pengguna atau grup pengguna yang akan diberikan akses eksternal ke aplikasi.
Persyaratan tambahan Perhatikan setiap akses jarak jauh tambahan atau persyaratan keamanan yang harus diperhitungkan dalam menerbitkan aplikasi.

Anda dapat mengunduh spreadsheet inventaris aplikasi ini untuk menginventarisasi aplikasi Anda.

Menentukan persyaratan organisasi

Berikut ini adalah area yang harus Anda tentukan persyaratan bisnis organisasi Anda. Setiap area berisi contoh persyaratan

Access

  • Pengguna jarak jauh dengan perangkat yang bergabung dengan domain atau Azure Active Directory dapat mengakses aplikasi yang dipublikasikan secara aman dengan akses menyeluruh (SSO) yang lancar.

  • Pengguna jarak jauh dengan perangkat pribadi yang disetujui dapat dengan aman mengakses aplikasi yang diterbitkan asalkan mereka terdaftar di MFA dan telah mendaftarkan aplikasi Microsoft Authenticator di ponsel mereka sebagai metode autentikasi.

Pemerintahan

  • Administrator dapat menentukan dan memantau siklus hidup penetapan pengguna ke aplikasi yang diterbitkan melalui Proksi Aplikasi.

Keamanan

  • Hanya pengguna yang ditetapkan ke aplikasi melalui keanggotaan grup atau secara individual dapat mengakses aplikasi tersebut.

Performa

  • Tidak ada penurunan kinerja aplikasi dibandingkan dengan mengakses aplikasi dari jaringan internal.

Pengalaman pengguna

  • Pengguna menyadari cara mengakses aplikasi mereka dengan menggunakan URL perusahaan yang akrab di platform perangkat apa pun.

Audit

  • Administrator dapat mengaudit aktivitas akses pengguna.

Praktik terbaik untuk pilot

Tentukan jumlah waktu dan upaya yang diperlukan untuk sepenuhnya menugaskan satu aplikasi untuk akses jarak jauh dengan Akses Menyeluruh (SSO). Lakukan dengan menjalankan pilot yang mempertimbangkan penemuan awal, penerbitan, dan pengujian umum. Menggunakan aplikasi web sederhana berbasis IIS yang sudah dikonfigurasi sebelumnya untuk NTLM terintegrasi akan membantu membangun garis dasar, karena pengaturan ini membutuhkan upaya minimal untuk berhasil menguji coba akses jarak jauh dan Akses Menyeluruh.

Elemen desain berikut harus meningkatkan keberhasilan implementasi pilot Anda secara langsung di penyewa produksi.

Manajemen konektor:

  • Konektor memainkan peran kunci dalam menyediakan saluran lokal untuk aplikasi Anda. Menggunakan grup konektor Default memadai untuk pengujian percontohan awal aplikasi yang dipublikasikan sebelum menugaskannya ke dalam produksi. Aplikasi yang berhasil diuji kemudian dapat dipindahkan ke grup konektor produksi.

Manajemen aplikasi:

  • Tenaga kerja Anda kemungkinan besar mengingat URL eksternal akrab dan relevan. Hindari mempublikasikan aplikasi Anda menggunakan akhiran msappproxy.net atau onmicrosoft.com kami yang telah ditentukan sebelumnya. Sebagai gantinya, berikan domain terverifikasi tingkat atas yang familier, diawali dengan nama host logis seperti intranet.<domain_pelanggan>.com.

  • Batasi visibilitas ikon aplikasi pilot ke grup percontohan dengan menyembunyikan ikon peluncurannya membentuk portal Azure MyApps. Saat siap untuk produksi, Anda dapat menjangkau aplikasi ke audiens yang ditargetkan masing-masing, baik di penyewa pra-produksi yang sama, atau dengan juga memublikasikan aplikasi di penyewa produksi Anda.

Pengaturan akses menyeluruh: Beberapa pengaturan Akses Menyeluruh memiliki dependensi khusus yang dapat memakan waktu untuk mengatur, jadi hindari penundaan kontrol perubahan dengan memastikan dependensi ditangani sebelumnya. Ini termasuk host konektor gabungan domain untuk melakukan Akses Menyeluruh menggunakan Kerberos Constrained Delegation (KCD) dan mengurus kegiatan lain yang memakan waktu. Misalnya, Menyiapkan instans PING Access, jika memerlukan Akses Menyeluruh berbasis header.

TLS Antara Host Konektor dan Aplikasi Target: Keamanan sangat penting, jadi TLS antara host konektor dan aplikasi target harus selalu digunakan. Terutama jika aplikasi web dikonfigurasi untuk autentikasi berbasis formulir (FBA), karena kredensial pengguna kemudian secara efektif dikirimkan dalam teks yang jelas.

Terapkan secara bertahap dan uji setiap langkah. Lakukan pengujian fungsional dasar setelah menerbitkan aplikasi untuk memastikan bahwa semua persyaratan pengguna dan bisnis dipenuhi dengan mengikuti petunjuk di bawah ini:

  1. Uji dan validasi akses umum ke aplikasi web dengan pra-otentikasi dinonaktifkan.
  2. Jika berhasil mengaktifkan pra-autentikasi dan menetapkan pengguna dan grup. Menguji dan memvalidasi akses.
  3. Kemudian tambahkan metode Akses Menyeluruh untuk aplikasi Anda dan uji lagi untuk memvalidasi akses.
  4. Menerapkan kebijakan Akses Bersyarat dan MFA sebagaimana diperlukan. Menguji dan memvalidasi akses.

Alat Pemecahan Masalah: Saat memecahkan masalah, selalu mulai dengan memvalidasi akses ke aplikasi yang diterbitkan dari browser pada host konektor, dan konfirmasikan bahwa aplikasi berfungsi seperti yang diharapkan. Semakin sederhana pengaturan Anda, semakin mudah untuk menentukan penyebab akar, jadi pertimbangkan untuk mencoba mereproduksi masalah dengan konfigurasi minimal seperti hanya menggunakan konektor tunggal dan tanpa Akses Menyeluruh. Dalam beberapa kasus, alat penelurusan kesalahan web seperti Fiddler Telerik dapat terbukti sangat diperlukan untuk memecahkan masalah akses atau konten dalam aplikasi yang diakses melalui proksi. Fiddler juga dapat bertindak sebagai proksi untuk membantu melacak dan men-debug lalu lintas untuk platform seluler seperti iOS dan Android, dan hampir apa pun yang dapat dikonfigurasi untuk merutekan melalui proksi. Untuk informasi selengkapnya, lihat panduan pemecahan masalah.

Terapkan solusi Anda

Sebarkan Proksi Aplikasi

Langkah-langkah untuk menyebarkan Proksi Aplikasi Anda tercakup dalam tutorial ini untuk menambahkan aplikasi lokal untuk akses jarak jauh. Jika penginstalan tidak berhasil, pilih Pecahkan Masalah Proxy Aplikasi di portal atau gunakan panduan pemecahan masalah untuk Masalah dengan penginstalan Konektor Agen Proksi Aplikasi.

Menerbitkan aplikasi dengan Proksi Aplikasi

Aplikasi penerbitan mengasumsikan bahwa Anda telah memenuhi semua prasyarat dan bahwa Anda memiliki beberapa konektor yang ditampilkan sebagai terdaftar dan aktif di halaman Proksi Aplikasi.

Anda juga dapat menerbitkan aplikasi dengan menggunakan PowerShell.

Di bawah ini adalah beberapa praktik terbaik untuk diikuti saat menerbitkan aplikasi:

  • Gunakan Grup Konektor: Tetapkan grup konektor yang telah ditetapkan untuk memublikasikan setiap aplikasi masing-masing. Sebaiknya setiap grup konektor memiliki setidaknya dua konektor untuk memberikan ketersediaan dan skala tinggi. Memiliki tiga konektor bersifat optimal jika Anda mungkin perlu melayani mesin kapan saja. Selain itu, lihat Menerbitkan aplikasi di jaringan dan lokasi terpisah menggunakan grup konektor untuk melihat bagaimana Anda juga dapat menggunakan grup konektor untuk mensegmentasikan konektor Anda berdasarkan jaringan atau lokasi.

  • Atur Batas Waktu Aplikasi Backend: Pengaturan ini berguna dalam skenario di mana aplikasi mungkin memerlukan lebih dari 75 detik untuk memproses transaksi klien. Misalnya saat klien mengirim kueri ke aplikasi web yang bertindak sebagai ujung depan database. Bagian depan mengirimkan kueri ini ke server database back-end-nya dan menunggu respons, tetapi pada saat menerima respons, sisi klien percakapan habis. Atur waktu habis ke Long menyediakan 180 detik untuk transaksi yang lebih lama selesai.

  • Gunakan Jenis Cookie yang Sesuai

    • HTTP-Only Cookie: Menyediakan keamanan tambahan dengan meminta Proksi Aplikasi menyertakan bendera HTTPOnly di header respons HTTP set-cookie. Pengaturan ini membantu mengurangi eksploitasi seperti scripting lintas situs (XSS). Biarkan set ini ke Tidak untuk klien/agen pengguna yang memerlukan akses ke cookie sesi. Misalnya, klien RDP/MTSC yang terhubung ke Gateway Desktop Jarak Jauh yang diterbitkan melalui Proksi Aplikasi.

    • \Cookie Aman: Ketika cookie diatur dengan atribut Secure, agen pengguna (aplikasi pihak klien) hanya akan menyertakan cookie dalam permintaan HTTP jika permintaan dikirimkan melalui saluran aman TLS. Ini membantu mengurangi risiko cookie yang dikompromikan melalui saluran teks yang jelas, jadi harus diaktifkan.

    • Cookie Persisten: Memungkinkan cookie sesi Proksi Aplikasi bertahan di antara penutupan browser dengan tetap valid sampai kedaluwarsa atau dihapus. Digunakan untuk skenario di mana aplikasi kaya seperti office mengakses dokumen dalam aplikasi web yang diterbitkan, tanpa pengguna diminta kembali untuk autentikasi. Namun, aktifkan dengan hati-hati, karena cookie persisten pada akhirnya dapat membuat layanan berisiko akses tidak sah, jika tidak digunakan bersama dengan kontrol kompensasi lainnya. Setelan ini hanya boleh digunakan untuk aplikasi lama yang tidak dapat berbagi cookie antar proses. Lebih baik memperbarui aplikasi Anda untuk menangani berbagi cookie antara proses alih-alih menggunakan cookie persisten.

  • Menerjemahkan URL di Header:Anda mengaktifkan ini untuk skenario di mana DNS internal tidak dapat dikonfigurasi agar sesuai dengan ruang nama publik organisasi (alias Split DNS). Kecuali aplikasi Anda memerlukan header host asli dalam permintaan klien, biarkan nilai ini diatur ke Ya. Alternatifnya adalah meminta konektor menggunakan FQDN di URL internal untuk perutean lalu lintas aktual, dan FQDN di URL eksternal, sebagai header host. Dalam kebanyakan kasus, alternatif ini seharusnya memungkinkan aplikasi berfungsi seperti biasa, saat diakses dari jarak jauh, tetapi pengguna Anda akan kehilangan manfaat memiliki URL yang cocok di dalam & di luar.

  • Menerjemahkan URL di Isi Aplikasi: Aktifkan tautan terjemahan Isi Aplikasi untuk aplikasi saat Anda ingin tautan dari aplikasi tersebut diterjemahkan sebagai tanggapan kembali ke klien. Jika diaktifkan, fungsi ini memberikan usaha upaya terbaik untuk menerjemahkan semua tautan internal yang ditemukan Proksi Aplikasi dalam respons HTML dan CSS dikembalikan ke klien. Ini berguna ketika memublikasikan aplikasi yang berisi tautan nama pendek hard-coded absolut atau NetBIOS dalam konten, atau aplikasi dengan konten yang dikutseng tautan ke aplikasi lokal lainnya.

Untuk skenario di mana aplikasi yang dipublikasikan terhubung ke aplikasi lain yang dipublikasikan, aktifkan terjemahan tautan untuk setiap aplikasi sehingga Anda memiliki kontrol atas pengalaman pengguna di tingkat per aplikasi.

Misalnya, Anda memiliki tiga aplikasi yang diterbitkan melalui Proksi Aplikasi yang semuanya terhubung satu sama lain: Manfaat, Pengeluaran, dan Perjalanan, ditambah aplikasi keempat, Umpan Balik, yang tidak dipublikasikan melalui Aplikasi Proxy.

Picture 1

Saat Anda mengaktifkan terjemahan tautan untuk aplikasi Manfaat, tautan ke Pengeluaran dan Perjalanan dialihkan ke URL eksternal untuk aplikasi tersebut, sehingga pengguna yang mengakses aplikasi dari luar jaringan perusahaan dapat mengaksesnya. Tautan dari Pengeluaran dan Perjalanan kembali ke Keuntungan tidak berfungsi, karena terjemahan tautan belum diaktifkan untuk dua aplikasi tersebut. Tautan ke Umpan Balik tidak dialihkan karena tidak ada URL eksternal, sehingga pengguna yang menggunakan aplikasi Manfaat tidak akan dapat mengakses aplikasi umpan balik dari luar jaringan perusahaan. Lihat informasi terperinci tentang terjemahan tautan dan opsi pengalihan lainnya.

Mengakses aplikasi Anda

Beberapa opsi ada untuk mengelola akses ke sumber daya yang dipublikasikan Proksi Aplikasi, jadi pilih yang paling sesuai untuk skenario dan kebutuhan skalabilitas yang Anda berikan. Pendekatan umum meliputi: menggunakan grup lokal yang sedang disinkronkan melalui Azure AD Connect, membuat Grup Dinamis di Azure AD berdasarkan atribut pengguna, menggunakan grup layanan mandiri yang dikelola oleh pemilik sumber daya, atau kombinasi dari semua ini. Lihat sumber daya yang ditautkan untuk manfaat masing-masing.

Cara paling lurus ke depan dalam menetapkan akses pengguna ke aplikasi adalah masuk ke opsi Pengguna dan Grup dari panel kiri aplikasi Anda yang diterbitkan dan secara langsung menetapkan grup atau individu.

Picture 24

Anda juga dapat mengizinkan pengguna untuk mengakses layanan mandiri ke aplikasi Anda dengan menetapkan grup tempat mereka saat ini bukan anggota dan mengonfigurasi opsi layanan mandiri.

Picture 25

Jika diaktifkan, pengguna kemudian akan dapat masuk ke portal MyApps dan meminta akses, dan disetujui secara otomatis dan ditambahkan ke grup layanan mandiri yang sudah diizinkan, atau memerlukan persetujuan dari pemberi persetujuan yang ditunjuk.

Pengguna tamu juga dapat diundang untuk mengakses aplikasi internal yang diterbitkan melalui Proksi Aplikasi melalui Microsoft Azure Active Directory B2B.

Untuk aplikasi lokal yang biasanya dapat diakses secara anonim, tidak memerlukan autentikasi, Anda mungkin lebih suka menonaktifkan opsi yang terletak di Properti aplikasi.

Picture 26

Membiarkan opsi ini diatur ke Tidak memungkinkan pengguna untuk mengakses aplikasi lokal melalui Proksi Aplikasi Microsoft Azure Active Directory tanpa izin, jadi gunakan dengan hati-hati.

Setelah aplikasi Anda diterbitkan, aplikasi harus dapat diakses dengan mengetikkan URL eksternalnya di browser atau dengan ikonnya di https://myapps.microsoft.com.

Mengaktifkan pra-autentikasi

Verifikasi bahwa aplikasi Anda dapat diakses melalui Proksi Aplikasi yang mengaksesnya melalui URL eksternal.

  1. Navigasi ke Azure Active Directory>Aplikasi Enterprise>Semua aplikasi dan pilih aplikasi yang ingin Anda kelola.

  2. Mengelola Proksi Aplikasi.

  3. Di bidang Pra-Autentikasi, gunakan daftar dropdown untuk memilih Azure Active Directory, dan pilih Simpan.

Dengan pra-autentikasi diaktifkan, Microsoft Azure Active Directory akan menantang pengguna terlebih dahulu untuk autentikasi dan jika masuk tunggal dikonfigurasi maka aplikasi back-end juga akan memverifikasi pengguna sebelum akses ke aplikasi diberikan. Mengubah mode pra-autentikasi dari Passthrough ke Microsoft Azure Active Directory juga mengonfigurasi URL eksternal dengan HTTPS, sehingga aplikasi apa pun yang awalnya dikonfigurasi untuk HTTP sekarang akan diamankan dengan HTTPS.

Mengaktifkan Akses Menyeluruh

Akses Menyeluruh memberikan pengalaman dan keamanan pengguna sebaik mungkin karena pengguna hanya perlu masuk sekali saat mengakses Microsoft Azure Active Directory. Setelah pengguna melakukan pra-otentikasi, Akses Menyeluruh dilakukan oleh konektor Proksi Aplikasi yang mengautentikasi ke aplikasi lokal, atas nama pengguna. Aplikasi backend memproses login seolah-olah itu adalah pengguna itu sendiri.

Memilih opsi Passthrough memungkinkan pengguna untuk mengakses aplikasi yang dipublikasikan tanpa harus mengautentikasi ke Microsoft Azure Active Directory.

Melakukan Akses Menyeluruh hanya dimungkinkan jika Microsoft Azure Active Directory dapat mengidentifikasi pengguna yang meminta akses ke sumber daya, sehingga aplikasi Anda harus dikonfigurasi untuk mengautentikasi pengguna terlebih dahulu dengan Azure AD pada akses agar Akses Menyeluruh berfungsi, jika tidak, opsi Akses Menyeluruh akan dinonaktifkan.

Baca Akses menyeluruh ke aplikasi di Microsoft Azure Active Directory untuk membantu Anda memilih metode Akses Menyeluruh yang paling tepat saat mengonfigurasi aplikasi Anda.

Bekerja dengan aplikasi jenis lain

Proksi Aplikasi Azure AD juga dapat mendukung aplikasi yang telah dikembangkan untuk menggunakan Microsoft Authentication Library (MSAL). Ini mendukung aplikasi klien asli dengan mengkonsumsi token yang dikeluarkan Microsoft Azure Active Directory yang diterima dalam informasi header permintaan klien untuk melakukan pra-autentikasi atas nama pengguna.

Baca aplikasi klien penerbitan asli dan seluler dan aplikasi berbasis klaim untuk mempelajari konfigurasi Proksi Aplikasi yang tersedia.

Gunakan Akses Bersyarat untuk memperkuat keamanan

Keamanan aplikasi memerlukan serangkaian kemampuan keamanan tingkat lanjut yang dapat melindungi dari dan merespons ancaman kompleks di tempat dan di cloud. Penyerang paling sering mendapatkan akses jaringan perusahaan melalui kredensial pengguna yang lemah, default, atau dicuri. Keamanan berbasis identitas Microsoft mengurangi penggunaan kredensial yang dicuri dengan mengelola dan melindungi identitas istimewa dan tidak istimewa.

Kapabilitas berikut ini dapat digunakan untuk mendukung Proksi Aplikasi Microsoft Azure Active Directory:

  • Akses Bersyarat Berbasis Pengguna dan Lokasi: Lindungi data sensitif dengan membatasi akses pengguna berdasarkan lokasi geografis atau alamat IP dengan kebijakan Akses Bersyarat berbasis lokasi.

  • Akses Bersyarat Berbasis Perangkat: Pastikan hanya perangkat yang terdaftar, disetujui, dan mematuhi yang dapat mengakses data perusahaan Akses Bersyarat berbasis perangkat.

  • Akses Bersyarat Berbasis Aplikasi: Pekerjaan tidak harus berhenti saat pengguna tidak berada di jaringan perusahaan. Amankan akses ke cloud perusahaan dan aplikasi lokal dan pertahankan kontrol dengan Akses Bersyarat.

  • Akses Bersyarat Berbasis Risiko: Lindungi data Anda dari peretas berbahaya dengan kebijakan Akses Bersyarat berbasis risiko yang dapat diterapkan ke semua aplikasi dan semua pengguna, baik lokal maupun di cloud.

  • Microsoft Azure Active Directory Aplikasi Saya: Dengan layanan Proksi Aplikasi Anda diterapkan, dan aplikasi yang diterbitkan dengan aman, tawarkan pengguna Anda hub sederhana untuk menemukan dan mengakses semua aplikasi mereka. Tingkatkan produktivitas dengan kemampuan layanan mandiri, seperti kemampuan untuk meminta akses ke aplikasi dan grup baru atau mengelola akses ke sumber daya ini atas nama orang lain, melalui Aplikasi Saya.

Mengelola implementasi Anda

Peran yang Diperlukan

Microsoft menganjurkan prinsip pemberian hak istimewa sesering mungkin untuk melakukan tugas yang diperlukan dengan Azure AD. Tinjau berbagai peran Azure yang tersedia dan pilih yang tepat untuk memenuhi kebutuhan setiap persona. Beberapa peran mungkin perlu diterapkan untuk sementara dan dihapus setelah penyebaran selesai.

Peran bisnis Tugas bisnis Peran Microsoft Azure Active Directory
Admin meja bantuan Biasanya terbatas pada masalah yang dilaporkan pengguna akhir yang memenuhi syarat dan melakukan tugas terbatas seperti mengubah kata sandi pengguna, membatalkan token refresh, dan memantau kesehatan layanan. Admin Helpdesk
Admin identitas Baca laporan masuk Microsoft Azure Active Directory dan log audit untuk men-debug masalah terkait Proksi Aplikasi. Pembaca keamanan
Pemilik aplikasi Pengguna dalam peran ini dapat membuat dan mengelola semua aspek aplikasi perusahaan, pendaftaran aplikasi, dan pengaturan proksi aplikasi. Admin aplikasi
Admin infrastruktur Pemilik sertifikat Rollover Admin aplikasi

Meminimalkan jumlah orang yang memiliki akses ke informasi atau sumber daya yang aman akan membantu mengurangi kemungkinan aktor jahat mendapatkan akses tidak sah, atau pengguna yang berwenang secara tidak sengaja berdampak pada sumber daya sensitif.

Namun, pengguna masih perlu melakukan operasi istimewa sehari-hari, jadi memberlakukan kebijakan Manajemen Identitas Istimewa berbasis just-in-time (JIT) untuk menyediakan akses istimewa sesuai permintaan ke sumber daya Azure dan Microsoft Azure Active Directory adalah pendekatan yang direkomendasikan kami untuk mengelola akses dan audit administratif secara efektif.

Pelaporan dan Pemantauan

Azure Active Directory dapat memberikan wawasan tambahan tentang penggunaan provisi pengguna organisasi Anda dan kesehatan operasional melalui log audit dan laporan. Proksi Aplikasi juga membuatnya sangat mudah untuk memantau konektor dari portal Microsoft Azure Active Directory dan Catatan Peristiwa Windows.

Log audit aplikasi

Log ini memberikan informasi terperinci tentang login ke aplikasi yang dikonfigurasi dengan Proksi Aplikasi dan perangkat dan pengguna yang mengakses aplikasi. Log audit terletak di portal Microsoft Azure dan di Audit API untuk diekspor. Selain itu, laporan penggunaan dan wawasan juga tersedia untuk aplikasi Anda.

Pemantauan Konektor Proksi Aplikasi

Konektor dan layanan menangani semua tugas ketersediaan tinggi. Anda dapat memantau status konektor Anda dari halaman Proksi Aplikasi di Portal Microsoft Azure Active Directory. Untuk informasi selengkapnya tentang cara kerja konektor, lihat Memahami konektor Proksi Aplikasi Microsoft Azure Active Directory.

Example: Azure AD Application Proxy connectors

Catatan peristiwa Windows dan penghitung kinerja

Konektor memiliki catatan admin dan sesi. Log Admin menyertakan peristiwa utama dan kesalahannya. Catatan Sesi menyertakan semua transaksi dan detail pemrosesannya. Log dan penghitung terletak di Windows Event Logs untuk informasi selengkapnya lihat Memahami Konektor Proksi Aplikasi Microsoft Azure Active Directory. Ikuti tutorial ini untuk mengonfigurasi sumber data log kejadian di Azure Monitor.

Panduan pemecahan masalah dan langkah-langkahnya

Pelajari selengkapnya tentang masalah umum dan cara mengatasinya dengan panduan kami untuk memecahkan masalah pesan kesalahan.

Artikel berikut ini mencakup skenario umum yang juga dapat digunakan untuk membuat panduan pemecahan masalah untuk organisasi dukungan Anda.