Metode autentikasi yang didukung oleh Azure OpenAI

Selesai

Azure OpenAI mendukung beberapa metode autentikasi untuk memastikan akses yang aman dan terkontrol ke sumber dayanya. Metode utamanya adalah:

• Kunci API: Azure OpenAI juga mendukung autentikasi berbasis kunci API. Kunci API dihasilkan dalam portal Azure dan dapat digunakan untuk mengautentikasi permintaan ke layanan Azure OpenAI. Metode autentikasi ini tidak direkomendasikan dari perspektif keamanan dan hanya boleh digunakan sebagai upaya terakhir. Jika Anda harus menggunakan metode autentikasi ini, penting untuk menangani kunci API dengan aman dan memutarnya secara berkala untuk mengurangi risiko akses yang tidak sah.
• ID Microsoft Entra: Metode ini memanfaatkan kemampuan manajemen identitas dan akses Microsoft Entra yang kuat. Pengguna dan aplikasi mengautentikasi menggunakan identitas Microsoft Entra, yang dapat berupa akun pengguna tradisional atau identitas terkelola. Metode ini memastikan bahwa hanya pengguna yang diautentikasi dan berwenang yang dapat mengakses sumber daya Azure OpenAI.
• Identitas TerkelolaEntra: Identitas terkelola untuk sumber daya Azure menyediakan identitas yang dikelola secara otomatis di Microsoft Entra untuk digunakan aplikasi saat menyambungkan ke sumber daya yang mendukung autentikasi Microsoft Entra. Identitas ini dapat ditetapkan sistem, yang berarti identitas tersebut terkait dengan sumber daya Azure tertentu, atau ditetapkan pengguna, yang memungkinkan satu identitas dibagikan di beberapa sumber daya. Identitas terkelola menyederhanakan manajemen kredensial dan meningkatkan keamanan dengan menghilangkan kebutuhan akan kredensial yang dikodekan secara permanen dalam kode aplikasi.

Mengapa identitas terkelola lebih aman daripada kunci API

Identitas terkelola di Microsoft Azure menawarkan alternatif yang lebih aman untuk kunci API karena beberapa alasan:

1. Identitas terkelola menghilangkan kebutuhan pengembang untuk menangani kredensial secara langsung, sehingga mengurangi risiko paparan atau penyalahgunaan yang tidak disengaja.
2. Saat menggunakan kunci API, pengembang harus menyematkan kunci ini dalam kode aplikasi atau file konfigurasi mereka.

Kunci API dapat secara tidak sengaja diekspos melalui repositori kode sumber, log, atau cara lain. Paparan ini dapat menyebabkan akses yang tidak sah dan potensi pelanggaran keamanan. Sebaliknya, identitas terkelola menyediakan identitas yang dikelola secara otomatis untuk digunakan aplikasi saat menyambungkan ke sumber daya yang mendukung autentikasi Microsoft Entra (sebelumnya Azure AD). Ini berarti bahwa info masuk tidak disimpan dalam kode aplikasi, mengurangi risiko kebocoran dan akses yang tidak sah.

Selain itu, identitas terkelola menyederhanakan proses autentikasi dengan memungkinkan layanan Azure mengautentikasi ke layanan Azure lainnya dengan aman tanpa perlu kredensial eksplisit. Ini dicapai dengan menggunakan token yang dikeluarkan oleh Microsoft Entra, yang dikelola dan diputar secara otomatis, memastikan bahwa kredensial selalu diperbarui dan mengurangi risiko pencurian kredensial. Kunci API, di sisi lain, bersifat statis dan memerlukan rotasi manual, yang dapat rawan kesalahan dan sering diabaikan, yang mengarah ke potensi kerentanan. Dengan menggunakan identitas terkelola, pengembang dapat memanfaatkan fitur keamanan bawaan Azure, seperti kontrol akses berbasis peran (RBAC), untuk memberikan izin yang tepat ke sumber daya, meningkatkan keamanan lebih lanjut.

Microsoft menyarankan agar Anda menggunakan Identitas Terkelola melalui kunci API saat mengautentikasi ke Azure OpenAI, atau layanan Azure lainnya yang mendukung Identitas Terkelola.

Perbedaan antara menggunakan kunci API dan identitas terkelola dalam Azure OpenAI

Mari kita evaluasi dampak ID klien yang bocor versus kunci API yang bocor.

Kunci API berfungsi mirip dengan kata sandi biasa. Jika disusupi, siapa pun dengan kunci dapat mengakses sumber daya. Untuk Azure OpenAI, ini berarti penggunaan model AI yang tidak dibatasi seperti GPT-4. Jika jaringan dapat diakses secara publik, dampak keamanan bisa lebih besar.

Sebaliknya, jika ID klien bocor, risikonya minimal. Ini karena ID klien saja tidak dapat membuat koneksi ke Azure OpenAI. Untuk menggunakan Identitas Terkelola, layanan harus beroperasi di Azure dan bahkan jika Azure OpenAI bersifat publik, Anda tidak dapat terhubung dari lingkungan lokal atau di seluruh jaringan menggunakan aplikasi.

Singkatnya, dibandingkan dengan ramifikasi kunci API yang bocor, mengeksploitasi ID klien yang bocor melibatkan beberapa langkah, sehingga lebih sulit bagi aktor jahat untuk mengeksploitasi.

Untuk alasan ini, Identitas Terkelola menawarkan metode yang lebih aman untuk mengelola operasi dibandingkan dengan kunci API. Disarankan dalam istilah sekuat mungkin yang Anda gunakan Identitas Terkelola melalui kunci API saat mengautentikasi ke Azure OpenAI, atau layanan Azure lainnya yang mendukung Identitas Terkelola.

Sistem versus identitas yang ditetapkan pengguna

Saat membangun aplikasi Azure OpenAI, memahami perbedaan antara identitas yang ditetapkan sistem dan yang ditetapkan pengguna sangat penting untuk keamanan dan manajemen sumber daya yang optimal.

• Identitas yang ditetapkan sistem dibuat dan dikelola oleh Azure untuk sumber daya tertentu. Ketika sumber daya dihapus, identitas terkait yang ditetapkan sistem juga dihapus, memastikan bahwa siklus hidup identitas digabungkan erat dengan sumber daya miliknya. Jenis identitas ini sangat ideal untuk skenario di mana identitas hanya perlu digunakan oleh satu sumber daya, memberikan kesederhanaan dan mengurangi overhead administratif karena Azure mengelola kredensial identitas.
• Identitas yang ditetapkan pengguna dibuat secara independen dari sumber daya tertentu dan dapat dibagikan di beberapa sumber daya. Ini membuatnya sangat serbaguna untuk aplikasi yang memerlukan identitas yang konsisten di berbagai sumber daya, memungkinkan manajemen izin dan kontrol akses yang lebih mudah. Identitas yang ditetapkan pengguna bertahan bahkan setelah sumber daya yang menggunakannya dihapus, memungkinkan fleksibilitas yang lebih besar dalam menyebarkan ulang dan menggunakan kembali identitas.

Memilih antara identitas yang ditetapkan sistem dan yang ditetapkan pengguna tergantung pada kebutuhan spesifik aplikasi Anda. Untuk aplikasi sumber daya tunggal di mana kesederhanaan dan manajemen minimal adalah prioritas, identitas yang ditetapkan sistem biasanya merupakan pilihan terbaik. Sebaliknya, untuk aplikasi yang memerlukan identitas bersama di beberapa sumber daya, identitas yang ditetapkan pengguna menawarkan fleksibilitas dan penggunaan kembali yang lebih besar.