Memperoleh otorisasi untuk mengakses sumber daya

Artikel ini membantu Anda, sebagai pengembang, untuk memahami cara terbaik memastikan Zero Trust saat memperoleh izin akses sumber daya untuk aplikasi Anda. Untuk mengakses sumber daya yang dilindungi seperti data email atau kalender, aplikasi Anda memerlukan otorisasi pemilik sumber daya. Pemilik sumber daya dapat menyetujui atau menolak permintaan aplikasi Anda. Aplikasi Anda menerima token akses saat pemilik sumber daya memberikan persetujuan; aplikasi Anda tidak menerima token akses saat pemilik sumber daya menolak akses.

Tinjauan konseptual

Anda dapat menggunakan platform identitas Microsoft untuk mengautentikasi dan mengotorisasi aplikasi Anda dan mengelola izin dan persetujuan. Mari kita mulai dengan beberapa konsep:

• Autentikasi (terkadang dipersingkat ke AuthN) adalah proses membuktikan bahwa identitas yang Anda klaim akurat. Platform identitas Microsoft menggunakan protokol OpenID Connect untuk menangani autentikasi. Otorisasi (terkadang dipersingkat ke AuthZ) memberikan izin pihak yang diautentikasi untuk melakukan sesuatu. Ini menentukan data apa yang dapat diakses oleh pihak yang diautentikasi. platform identitas Microsoft menggunakan protokol OAuth2.0 untuk menangani otorisasi. Opsi otorisasi termasuk daftar kontrol akses (ACL), kontrol akses berbasis peran, dan kontrol akses atribut (ABAC). Autentikasi sering menjadi faktor otorisasi.

• Akses yang didelegasikan (bertindak atas nama pengguna yang masuk) atau akses langsung (bertindak hanya sebagai identitas aplikasi sendiri) memungkinkan aplikasi Anda mengakses data. Akses yang didelegasikan memerlukan izin yang didelegasikan (juga dikenal sebagai cakupan); klien dan pengguna harus diberi wewenang secara terpisah untuk membuat permintaan. Akses langsung mungkin memerlukan izin aplikasi (juga dikenal sebagai peran aplikasi); ketika peran aplikasi diberikan ke aplikasi, mereka dapat disebut izin aplikasi.

• Izin yang didelegasikan, digunakan dengan akses yang didelegasikan, memungkinkan aplikasi untuk bertindak atas nama pengguna, hanya mengakses apa yang dapat diakses pengguna. Izin aplikasi, digunakan dengan akses langsung, memungkinkan aplikasi mengakses data apa pun yang terkait dengan izin. Hanya administrator dan pemilik perwakilan layanan yang dapat menyetujui izin aplikasi.

• Persetujuan adalah cara aplikasi menerima izin. Pengguna atau admin mengotorisasi aplikasi untuk mengakses sumber daya yang dilindungi. Permintaan persetujuan mencantumkan izin yang diperlukan aplikasi bersama dengan informasi penerbit.

• Praautorisasi adalah cara pemilik aplikasi sumber daya memberikan akses ke aplikasi klien. Mereka dapat melakukannya di portal Azure atau dengan menggunakan PowerShell dan API seperti Microsoft Graph. Mereka dapat memberikan izin sumber daya tanpa mengharuskan pengguna untuk melihat permintaan persetujuan untuk serangkaian izin yang telah diotorisasi .

Perbedaan antara izin yang didelegasikan dan aplikasi

Aplikasi bekerja dalam dua mode: ketika pengguna ada (izin yang didelegasikan) dan ketika tidak ada pengguna (izin aplikasi). Ketika ada pengguna di depan aplikasi, Anda dipaksa untuk bertindak atas nama pengguna tersebut; Anda tidak boleh bertindak atas nama aplikasi itu sendiri. Saat pengguna mengarahkan aplikasi, Anda bertindak sebagai delegasi untuk pengguna tersebut. Anda mendapatkan izin untuk bertindak atas nama pengguna yang diidentifikasi token.

Aplikasi jenis layanan (tugas latar belakang, daemon, proses server-ke-server) tidak memiliki pengguna yang dapat mengidentifikasi diri mereka sendiri atau mengetik kata sandi. Mereka memerlukan izin aplikasi untuk bertindak atas nama dirinya sendiri (atas nama aplikasi layanan).

Praktik terbaik otorisasi aplikasi Zero Trust

Pendekatan otorisasi Anda memiliki autentikasi sebagai komponen saat Anda terhubung ke pengguna yang ada ke aplikasi dan ke sumber daya yang Anda panggil. Ketika aplikasi Anda bertindak atas nama pengguna, kami tidak mempercayai aplikasi panggilan untuk memberi tahu kami siapa penggunanya atau membiarkan aplikasi memutuskan siapa penggunanya. MICROSOFT Entra ID memverifikasi dan secara langsung memberikan informasi tentang pengguna dalam token.

Saat Anda perlu mengizinkan aplikasi untuk memanggil API atau mengotorisasi aplikasi Anda sehingga aplikasi dapat mengakses sumber daya, skema otorisasi modern dapat memerlukan otorisasi melalui kerangka kerja izin dan persetujuan. Praktik terbaik Keamanan Referensi untuk properti aplikasi yang mencakup URI pengalihan, token akses (digunakan untuk alur implisit), sertifikat dan rahasia, URI ID aplikasi, dan kepemilikan aplikasi.

Langkah berikutnya

• Kustomisasi token menjelaskan informasi yang dapat Anda terima di token Microsoft Entra. Ini menjelaskan cara menyesuaikan token untuk meningkatkan fleksibilitas dan kontrol sambil meningkatkan keamanan kepercayaan nol aplikasi dengan hak istimewa paling sedikit.
• Mengonfigurasi klaim grup dan peran aplikasi dalam token menunjukkan kepada Anda cara mengonfigurasi aplikasi dengan definisi peran aplikasi dan menetapkan grup keamanan ke peran aplikasi. Metode ini membantu meningkatkan fleksibilitas dan kontrol sekaligus meningkatkan keamanan nol kepercayaan aplikasi dengan hak istimewa paling sedikit.
• Mengembangkan strategi izin yang didelegasikan membantu Anda menerapkan pendekatan terbaik untuk mengelola izin dalam aplikasi Anda dan mengembangkan menggunakan prinsip Zero Trust.
• Mengembangkan strategi izin aplikasi membantu Anda memutuskan pendekatan izin aplikasi Anda untuk manajemen kredensial.
• Berikan kredensial identitas aplikasi ketika tidak ada pengguna yang menjelaskan mengapa Identitas Terkelola untuk sumber daya Azure adalah praktik kredensial klien terbaik untuk layanan (aplikasi nonpengguna) di Azure.
• Praktik terbaik otorisasi membantu Anda menerapkan model otorisasi, izin, dan persetujuan terbaik untuk aplikasi Anda.
• Gunakan identitas Zero Trust dan praktik terbaik pengembangan manajemen akses dalam siklus hidup pengembangan aplikasi Anda untuk membuat aplikasi yang aman.
• Membangun aplikasi dengan pendekatan Zero Trust untuk identitas berlanjut dari artikel praktik terbaik pengembangan identitas dan manajemen akses Zero Trust untuk membantu Anda menggunakan pendekatan Zero Trust untuk identitas dalam Siklus Hidup pengembangan perangkat lunak (SDLC).