Edit

Bagikan melalui

Menyediakan autentikasi alternatif untuk layanan Azure OpenAI melalui gateway

Azure AI services
Azure OpenAI Service
Azure API Management
Microsoft Entra ID

Aplikasi cerdas yang menggunakan layanan Azure OpenAI melalui layanan Azure asli platform menawarkan pendekatan autentikasi dan otorisasi pengguna yang mulus. Namun, ada berbagai skenario yang menghadirkan kompleksitas yang membutuhkan desain arsitektur yang berbeda. Skenario ini termasuk topologi dengan aplikasi klien yang dihosting non-Azure, penggunaan penyedia identitas eksternal, dan penyebaran beberapa klien yang mengakses instans Azure OpenAI yang sama. Dalam skenario ini, memperkenalkan gateway di depan Azure OpenAI dapat memberikan peningkatan keamanan yang signifikan dengan menambahkan lapisan yang memastikan konsistensi dalam autentikasi ke instans yang disebarkan.

Artikel ini menjelajahi skenario utama berikut saat mengautentikasi dengan layanan Azure OpenAI.

Setiap skenario menjelaskan tantangan yang mereka perkenalkan, dan manfaat yang diperkenalkan dengan menyertakan gateway.

Penting

Panduan berikut cocok untuk implementasi gateway apa pun, termasuk Azure API Management (APIM). Diagram arsitektur mewakili komponen secara generik dalam sebagian besar skenario untuk mengilustrasikan ini.

Aplikasi klien diautentikasi dengan penyedia identitas eksternal

Diagram yang menunjukkan arsitektur konseptual untuk solusi di mana aplikasi klien mengautentikasi pengguna dengan penyedia identitas eksternal, dan mengautentikasi dengan Azure OpenAI dengan kunci API.

Batasan skenario

Berikut ini adalah batasan dalam skenario ini:

  • Aplikasi klien menggunakan penyedia identitas eksternal yang diaktifkan OpenID Connect (OIDC), seperti Okta, Auth0, atau penyedia identitas sosial.
  • Aplikasi klien mengautentikasi terhadap penyewa Microsoft Entra yang berbeda dari penyewa sarana data Azure OpenAI.

Batasan ini dapat berlaku untuk skenario di mana:

  • Aplikasi klien yang sudah ada yang sudah mengautentikasi terhadap penyedia OIDC eksternal atau ID Microsoft Entra terintegrasi dengan instans Azure OpenAI.
  • Aplikasi klien perlu mengautentikasi pengguna dari beberapa penyedia identitas secara konsisten.

Menyambungkan langsung ke Azure OpenAI

Jika aplikasi klien dalam skenario ini terhubung langsung ke Azure OpenAI (tidak menggunakan gateway), mereka harus menggunakan autentikasi berbasis kunci untuk mengautentikasi ke Azure OpenAI. Autentikasi berbasis kunci memperkenalkan masalah keamanan tambahan seperti menyimpan kunci dengan aman, memutar kunci, dan ketidakmampuan untuk menyediakan konfigurasi kontrol akses berbasis peran (RBAC) klien yang berbeda untuk penyebaran model individual.

Memperkenalkan gateway

Diagram yang memperlihatkan menyuntikkan gateway antara aplikasi klien dan Azure OpenAI, memungkinkan autentikasi dengan penyedia identitas eksternal.

Memperkenalkan gateway mengatasi tantangan skenario ini dalam beberapa cara:

  • Gateway dapat menggunakan OAuth untuk mengautentikasi pengguna menggunakan penyedia identitas eksternal yang ada. Gateway memvalidasi token akses pengguna yang diautentikasi, seperti JSON Web Token (JWT), yang dihasilkan oleh idP sebelum memberikan otorisasi ke instans Azure OpenAI yang mendukung.
  • Mengelola kunci untuk klien tidak lagi diperlukan dan risiko keamanan yang terkait dengan penggunaan autentikasi berbasis kunci hilang.
  • Gateway dapat tersambung ke Azure OpenAI menggunakan identitas terkelola, meningkatkan keamanan menggunakan Azure RBAC dengan hak istimewa paling sedikit.

Rekomendasi dan panduan untuk skenario ini

  • Lebih banyak cakupan OAuth dapat ditambahkan ke pendaftaran aplikasi Anda di IdP Anda untuk mengaktifkan izin terperinci kepada konsumen. Cakupan ini memungkinkan aplikasi klien meminta izin untuk melakukan operasi tertentu di gateway Anda, termasuk akses ke Azure OpenAI.
  • Anda dapat mengonfigurasi skenario ini untuk Azure API Management menggunakan kebijakan masuk. Gunakan kebijakan validasi-jwt untuk menegakkan nilai keberadaan, validitas, dan atribut JWT yang didukung.

Alasan untuk menghindari gateway untuk skenario ini

Jika Anda memiliki satu aplikasi cerdas yang mengakses Azure OpenAI, akan lebih mudah untuk mengonfigurasi autentikasi dan otorisasi pengguna dalam aplikasi versus gateway. Anda dapat menetapkan Azure RBAC yang diperlukan untuk mengautentikasi aplikasi cerdas dengan Azure OpenAI dengan aman menggunakan pendekatan ini.

Aplikasi klien diautentikasi dengan sertifikat

Diagram tempat pengguna diautentikasi dengan aplikasi klien menggunakan sertifikat klien, dan mengautentikasi dengan Azure OpenAI dengan kunci API.

Batasan skenario

Berikut ini adalah batasan dalam skenario ini:

  • Anda ingin menggunakan sertifikat untuk mengautentikasi aplikasi klien.
  • Aplikasi klien tidak dapat menggunakan atau Anda tidak ingin menggunakan ID Microsoft Entra atau penyedia OIDC apa pun untuk autentikasi.
  • Klien tidak dapat menggunakan atau Anda tidak ingin menggunakan identitas gabungan untuk autentikasi.

Batasan ini dapat berlaku untuk skenario di mana:

  • Klien yang mengautentikasi ke layanan Azure OpenAI adalah mesin atau perangkat di mana tidak ada interaksi pengguna.
  • Organisasi Anda memerlukan penggunaan sertifikat untuk autentikasi karena standar keamanan dan peraturan kepatuhan.
  • Anda ingin menyediakan beberapa aplikasi klien dengan opsi untuk mengautentikasi berdasarkan lingkungan mereka, termasuk penggunaan sertifikat klien.

Menyambungkan langsung ke Azure OpenAI

Azure OpenAI tidak secara asli mendukung autentikasi sertifikasi klien. Untuk mendukung skenario ini tanpa gateway, aplikasi cerdas akan dibatasi untuk menggunakan autentikasi sertifikat untuk pengguna dan menggunakan kunci API atau identitas terkelola untuk mengautentikasi permintaan ke instans Azure OpenAI. Logika autentikasi sertifikat harus diterapkan di setiap klien. Overhead risiko dan manajemen penggunaan autentikasi berbasis kunci akan berlaku jika Anda terhubung langsung ke Azure OpenAI dari klien dalam skenario ini.

Memperkenalkan gateway

Diagram yang menunjukkan menyuntikkan gateway antara aplikasi klien dan Azure OpenAI menggunakan identitas terkelola dengan kontrol akses berbasis peran.

Anda dapat memperkenalkan gateway ke dalam arsitektur ini yang membongkar validasi sertifikasi klien dari klien. Gateway memiliki tanggung jawab untuk memvalidasi sertifikat digital klien yang disajikan oleh aplikasi cerdas dan memeriksa penerbit, kedaluwarsa, thumbprint, dan daftar pencabutan. Gateway harus menggunakan identitas terkelola untuk mengautentikasi dirinya dengan Azure OpenAI. Gateway harus menggunakan Azure Key Vault untuk menyimpan otoritas sertifikat akar (CA) untuk memastikan bahwa validasi sertifikat klien dikelola di lokasi terpusat, yang mengurangi overhead pemeliharaan.

Ada beberapa keuntungan memperkenalkan gateway untuk mengatasi skenario ini, termasuk:

  • Menggunakan identitas terkelola gateway vs. kunci akses menghilangkan risiko kunci dicuri dan mengurangi beban pemeliharaan kunci yang berputar.
  • Memusatkan validasi sertifikat memastikan Anda menggunakan kebijakan keamanan yang konsisten untuk mengevaluasi sertifikat digital klien untuk semua aplikasi cerdas.
  • Membongkar validasi sertifikat ke gateway dapat menyederhanakan kode klien.

Rekomendasi dan panduan untuk skenario ini

  • Saat memvalidasi sertifikat, verifikasi seluruh rantai sertifikat, termasuk CA akar dan sertifikat perantara. Verifikasi penuh memastikan keaslian sertifikat dan mencegah akses yang tidak sah.
  • Putar dan perbarui sertifikat klien secara teratur untuk meminimalkan risiko penyusupan sertifikat. Otomatiskan proses ini menggunakan Azure Key Vault untuk memastikan sertifikat selalu diperbarui. Mengatur pemberitahuan untuk kedaluwarsa sertifikat yang akan datang juga mencegah gangguan layanan di gateway.
  • Terapkan TLS bersama (mTLS) untuk memastikan klien dan server saling mengautentikasi, memberikan lapisan keamanan tambahan. Konfigurasikan gateway untuk memberlakukan mTLS dengan mengatur kebijakan dan batasan yang sesuai.
  • Dengan menggunakan Azure API Management, Anda dapat menggunakan kebijakan validasi-sertifikat klien untuk memvalidasi sertifikat klien, yang dirujuk dalam brankas kunci Azure. Kebijakan ini memvalidasi sertifikat klien yang disajikan oleh aplikasi klien dan memeriksa penerbit, kedaluwarsa, thumbprint, dan daftar pencabutan.

Alasan untuk menghindari gateway untuk skenario ini

Di lingkungan sederhana dengan beberapa klien, biaya penanganan keamanan dan manajemen sertifikat di klien dapat melebihi kompleksitas tambahan untuk memperkenalkan gateway. Selain itu, gateway dapat menjadi titik kegagalan tunggal, meningkatkan latensi karena lapisan tambahan, dan menyebabkan penguncian vendor jika Anda memilih solusi komersial atas implementasi kustom.

Anda harus menilai dengan cermat kebutuhan spesifik, ketersediaan sumber daya, dan kekritisan aplikasi Anda sebelum memutuskan untuk menerapkan gateway untuk autentikasi sertifikat klien.

Beberapa aplikasi klien menggunakan kunci untuk mengakses instans Azure OpenAI bersama

Diagram yang menunjukkan arsitektur konseptual untuk solusi di mana beberapa aplikasi klien mengautentikasi dengan Azure OpenAI menggunakan kunci API bersama.

Batasan skenario

Berikut ini adalah batasan dalam skenario ini:

  • Beberapa aplikasi klien mengakses instans Azure OpenAI bersama.
  • Klien tidak dapat menggunakan atau Anda tidak ingin menggunakan ID Microsoft Entra untuk autentikasi.
  • Klien tidak dapat menggunakan atau Anda tidak ingin menggunakan identitas gabungan untuk autentikasi.
  • Anda ingin menggunakan autentikasi berbasis kunci untuk aplikasi klien.

Batasan ini dapat berlaku untuk skenario di mana:

  • Aplikasi klien disebarkan di beberapa lingkungan, termasuk Azure, penyedia cloud lainnya, atau lokal.
  • Organisasi perlu menyediakan layanan Azure OpenAI ke tim yang berbeda, masing-masing dengan akses dan batas penggunaan yang unik.

Menyambungkan langsung ke Azure OpenAI

Azure OpenAI mendukung autentikasi berbasis kunci menggunakan kunci bersama. Meskipun Azure OpenAI mengekspos kunci primer dan kunci sekunder, tujuan kunci sekunder adalah untuk mendukung rotasi kunci bukan untuk isolasi identitas klien. Saat Anda mengautentikasi beberapa klien langsung ke Azure OpenAI dalam skenario ini, setiap klien berbagi kunci yang sama. Berikut ini adalah tantangan dengan implementasi ini:

  • Anda tidak memiliki kemampuan untuk mencabut izin untuk klien tertentu karena setiap klien berbagi kunci yang sama.
  • Anda tidak dapat memberikan klien yang berbeda hak akses yang berbeda ke model yang berbeda dalam penyebaran instans Azure OpenAI yang sama.
  • Anda tidak dapat membedakan satu klien dari klien lain dari perspektif pengelogan.

Memperkenalkan gateway

Diagram yang memperlihatkan gateway antara beberapa klien dan Azure OpenAI dengan kunci langganan per klien dan autentikasi identitas terkelola.

Anda dapat memperkenalkan gateway ke dalam arsitektur ini yang mengeluarkan kunci khusus untuk setiap aplikasi klien. Azure API Management menggunakan konsep langganan untuk menyediakan kunci klien khusus. Gateway harus menggunakan identitas terkelola untuk mengautentikasi dirinya dengan Azure OpenAI.

Ada beberapa keuntungan memperkenalkan gateway untuk mengatasi skenario ini, termasuk:

  • Anda dapat mencabut akses ke satu aplikasi klien tanpa memengaruhi klien lain.
  • Memutar kunci menjadi kurang menantang secara logistik karena Anda tidak perlu memperbarui semua konfigurasi kunci klien sebelum memutarnya. Kunci khusus dapat diputar untuk setiap klien setelah konfigurasi klien diperbarui.
  • Setiap klien dapat diidentifikasi secara unik dari perspektif pengelogan.
  • Gateway menjadi bertanggung jawab untuk memberlakukan batas tarif dan kuota untuk setiap klien secara independen.

Rekomendasi dan panduan untuk skenario ini

  • Karena menggunakan identitas terkelola dari gateway tidak meningkatkan keterlacakan aplikasi pengguna akhir dan klien di log Azure OpenAI, tingkatkan pemantauan pada metrik yang terkait dengan permintaan API. Gateway harus menyediakan pengelogan yang terkait dengan permintaan, seperti ID klien dan pengguna yang meminta.
  • Saat merutekan beberapa permintaan aplikasi klien melalui gateway ke layanan Azure OpenAI bersama, pastikan gateway membuat keputusan perutean berdasarkan identitas klien ke penyebaran model yang sesuai. Untuk praktik terbaik lainnya dalam implementasi gateway untuk beberapa penyebaran Azure OpenAI, lihat Menggunakan gateway di depan beberapa penyebaran Azure OpenAI.

Aplikasi klien yang mengakses beberapa instans Azure OpenAI

Diagram yang menunjukkan aplikasi klien yang mengautentikasi dengan beberapa instans Azure OpenAI menggunakan kunci API bersama per instans.

Batasan skenario

Berikut ini adalah batasan dalam skenario ini:

  • Aplikasi klien terhubung ke beberapa instans Azure OpenAI di satu atau beberapa wilayah.
  • Klien tidak dapat menggunakan atau Anda tidak ingin menggunakan ID Microsoft Entra atau penyedia OIDC apa pun untuk autentikasi.
  • Anda ingin menggunakan autentikasi berbasis kunci untuk aplikasi klien.

Batasan ini dapat berlaku untuk skenario di mana:

  • Aplikasi klien perlu mendistribusikan beban kerja mereka secara geografis untuk mengurangi latensi dan meningkatkan performa.
  • Aplikasi klien mencoba mengoptimalkan kuota token per menit (TPM) mereka dengan menyebarkan instans di beberapa wilayah.
  • Organisasi memerlukan kemampuan failover dan pemulihan bencana yang mulus untuk memastikan operasi berkelanjutan dengan mengelola strategi penyebaran ganda, berpotensi terdiri dari penyebaran throughput yang disediakan dan penyebaran bayar sesuai penggunaan.
  • Aplikasi klien perlu menggunakan kemampuan model tertentu yang hanya tersedia di wilayah Azure tertentu.

Menyambungkan langsung ke beberapa instans Azure OpenAI

Ketika aplikasi klien terhubung langsung ke beberapa instans OpenAI, setiap klien harus menyimpan kunci untuk setiap instans. Seiring dengan pertimbangan keamanan menggunakan kunci, ada peningkatan beban manajemen mengenai memutar kunci.

Memperkenalkan gateway

Diagram gateway dengan satu kunci ke aplikasi klien dan autentikasi identitas terkelola ke Azure OpenAI dengan kontrol akses berbasis peran.

Memperkenalkan gateway untuk menangani aplikasi klien yang mengakses beberapa penyebaran Azure OpenAI memiliki manfaat yang sama yang tercakup dengan memperkenalkan gateway untuk menangani beberapa aplikasi klien menggunakan kunci untuk mengakses instans Azure OpenAI bersama. Selain alasan tersebut, dengan menggunakan satu identitas terkelola yang ditentukan pengguna untuk mengautentikasi permintaan dari gateway ke beberapa instans Azure OpenAI, proses untuk autentikasi disederhanakan. Menerapkan pendekatan ini mengurangi overhead operasional secara keseluruhan dan meminimalkan risiko kesalahan konfigurasi klien saat bekerja dengan beberapa instans.

Rekomendasi dan panduan untuk skenario ini

  • Terapkan teknik penyeimbangan beban untuk mendistribusikan permintaan API di beberapa instans layanan Azure OpenAI untuk menangani lalu lintas tinggi dan memastikan ketersediaan tinggi. Untuk informasi selengkapnya tentang implementasi ini, lihat Menggunakan gateway di depan beberapa penyebaran atau instans Azure OpenAI.
  • Saat Anda menerapkan skenario multipenyewa menggunakan beberapa instans Azure OpenAI, melacak penggunaan token untuk penyewa tertentu harus berkorelasi di gateway. Menghubungkan penggunaan token di gateway memastikan bahwa Anda melacak total penggunaan token terlepas dari instans Azure OpenAI backend tempat permintaan diteruskan.

Rekomendasi umum

Saat Anda mengintegrasikan layanan Azure OpenAI melalui gateway, ada beberapa rekomendasi lintas pemotongan untuk mempertimbangkan hal tersebut berlaku di semua skenario.

Memilih Azure API Management (APIM) alih-alih membuat solusi Anda sendiri memiliki beberapa manfaat. Ini menyediakan orkestrasi API yang efisien, integrasi yang mudah dengan layanan Azure lainnya, dan penghematan biaya dengan menurunkan upaya pengembangan dan pemeliharaan. APIM menyediakan manajemen API yang aman dengan mendukung autentikasi dan otorisasi secara langsung. Ini terintegrasi dengan penyedia identitas, seperti ID Microsoft Entra, mengaktifkan OAuth 2.0, dan menawarkan otorisasi berbasis kebijakan. Selain itu, ini dapat memanfaatkan identitas terkelola untuk akses pemeliharaan yang aman dan rendah ke Azure OpenAI.

Menggabungkan skenario untuk solusi gateway yang komprehensif

Dalam praktiknya, kasus penggunaan Anda dapat mencakup beberapa skenario yang diuraikan dalam panduan ini. Misalnya, Anda mungkin memiliki aplikasi klien yang mengautentikasi dengan idP eksternal, dan memerlukan akses ke beberapa instans Azure OpenAI.

Diagram yang memperlihatkan aplikasi klien yang mengautentikasi dengan penyedia identitas eksternal melalui gateway dengan akses ke beberapa instans Azure OpenAI.

Menggabungkan rekomendasi dari skenario ini memberikan pendekatan komprehensif untuk membangun gateway yang mendukung persyaratan spesifik Anda.

Penegakan kebijakan gateway

Sebelum permintaan ke instans Azure OpenAI dikirim melalui gateway, kebijakan autentikasi dan otorisasi masuk harus diberlakukan. Baik oleh token akses pengguna dari penyedia identitas atau validasi sertifikat, menerapkan pendekatan ini memastikan bahwa hanya permintaan yang diautentikasi dan diotorisasi yang diteruskan.

Menerapkan lebih banyak cakupan otorisasi dengan peran dan izin untuk aplikasi klien di gateway Anda juga memungkinkan kontrol terperinci. Cakupan ini memungkinkan operasi tertentu diizinkan berdasarkan kebutuhan aplikasi klien, meningkatkan keamanan dan pengelolaan.

Untuk validasi token akses, pastikan untuk memvalidasi semua klaim terdaftar utama seperti iss, , audexp, dan nbf selain klaim spesifik beban kerja yang relevan seperti keanggotaan grup atau peran aplikasi.

Menggunakan identitas terkelola Azure

Menggunakan identitas terkelola Azure menyederhanakan autentikasi di semua skenario aplikasi klien dengan memusatkan manajemen autentikasi. Pendekatan ini mengurangi kompleksitas dan risiko yang terkait dengan pengelolaan beberapa kunci API atau kredensial dalam aplikasi klien.

Karena identitas terkelola secara inheren mendukung kontrol akses berbasis peran Azure, identitas tersebut memastikan gateway hanya memiliki tingkat izin terendah yang diperlukan untuk mengakses instans Azure OpenAI. Dikombinasikan dengan menonaktifkan metode autentikasi alternatif, identitas terkelola mengurangi risiko akses yang tidak sah dan menyederhanakan kepatuhan terhadap kebijakan keamanan.

Menerapkan pengamatan komprehensif

Saat Anda menerapkan gateway dengan identitas terkelola, keterlacakan dapat dikurangi karena identitas terkelola mewakili gateway, bukan pengguna akhir, atau aplikasi yang membuat permintaan. Oleh karena itu, penting untuk meningkatkan pengamatan pada metrik yang terkait dengan permintaan API. Gateway harus menyediakan lebih banyak metadata pelacakan, termasuk ID klien dan pengguna yang meminta, untuk mempertahankan visibilitas atas pola dan penggunaan akses.

Pengelogan terpusat dari semua permintaan yang melewati gateway juga membantu dalam mempertahankan jejak audit. Jejak audit terpusat sangat penting untuk pemecahan masalah, kepatuhan, dan memastikan bahwa upaya akses yang tidak sah dapat dideteksi.

Implementasi gateway

Azure tidak menawarkan solusi turn-key atau arsitektur referensi untuk membangun gateway seperti itu. Seperti disebutkan dalam artikel pengenalan, Anda harus membangun dan mengoperasikan gateway ini. Berikut ini adalah contoh implementasi yang didukung komunitas yang mencakup kasus penggunaan yang disebutkan sebelumnya. Pertimbangkan untuk mereferensikan sampel ini saat Anda membangun solusi gateway Anda sendiri.

implementasi Contoh
Identitas dan Keamanan Aplikasi Azure OpenAI – Learn Live Webinar Learn Live: Identitas & Keamanan Aplikasi Azure OpenAI (youtube.com)

Langkah berikutnya

Menerapkan gateway untuk beban kerja Anda memberikan manfaat di luar skenario untuk meningkatkan autentikasi dan otorisasi yang dirinci dalam artikel ini. Pelajari tentang tantangan utama lain yang dapat diselesaikan gateway.

Kontributor

Kontributor berikut awalnya menulis artikel ini.

Penulis utama:

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.