Mengembangkan strategi izin yang didelegasikan

Artikel ini membantu Anda, sebagai pengembang, untuk menerapkan pendekatan terbaik untuk mengelola izin dalam aplikasi Anda dan mengembangkan menggunakan prinsip Zero Trust. Seperti yang dijelaskan dalam Memperoleh otorisasi untuk mengakses sumber daya, izin yang didelegasikan digunakan dengan akses yang didelegasikan untuk memungkinkan aplikasi bertindak atas nama pengguna, hanya mengakses apa yang dapat diakses pengguna. Izin aplikasi digunakan dengan akses langsung untuk memungkinkan aplikasi mengakses data apa pun yang terkait dengan izin. Hanya administrator dan pemilik perwakilan layanan yang dapat menyetujui izin aplikasi.

Model izin dan persetujuan terutama merujuk ke aplikasi. Proses izin dan persetujuan tidak memiliki kontrol atas apa yang dapat dilakukan pengguna. Ini mengontrol tindakan apa yang diizinkan untuk dilakukan aplikasi.

Referensikan diagram Venn berikut. Dengan izin yang didelegasikan, ada persimpangan antara apa yang diizinkan untuk dilakukan pengguna dan apa yang diizinkan untuk dilakukan aplikasi. Persimpangan itu adalah izin efektif di mana aplikasi terikat. Setiap kali Anda menggunakan izin yang didelegasikan, izin efektif akan mengikatnya.

"Deskripsi diagram Venn: Teks lingkaran kiri: Aplikasi diberikan persetujuan untuk rentang operasi aplikasi. Teks lingkaran kanan: Pengguna memiliki izin untuk operasi yang dikelola oleh organisasi mereka. Persimpangan teks lingkaran: Izin efektif: persimpangan izin aplikasi dan kemampuan pengguna."

Misalnya, aplikasi Anda yang memiliki pengguna di depan aplikasi mendapatkan izin untuk memperbarui profil setiap pengguna di penyewa. Itu tidak berarti bahwa siapa pun yang menjalankan aplikasi Anda dapat memperbarui profil orang lain. Jika admin memutuskan untuk memberikan aplikasi User.ReadWrite.AllAnda , maka mereka percaya bahwa aplikasi Anda melakukan hal-hal yang tepat saat memperbarui profil pengguna apa pun. Aplikasi Anda mungkin mencatat perubahan dan melindungi informasi dengan benar. Admin membuat penilaian nilai tentang aplikasi, bukan tentang pengguna.

Pendekatan hak istimewa terkecil

API bisa menjadi kompleks. API sederhana mungkin tidak memiliki banyak operasi. API kompleks seperti Microsoft Graph merangkum banyak permintaan yang mungkin ingin digunakan aplikasi. Hanya karena aplikasi memiliki hak untuk membaca bukan berarti harus memiliki hak untuk memperbarui. Misalnya, Microsoft Graph memiliki ribuan API. Hanya karena Anda memiliki izin untuk membaca profil pengguna, tidak ada alasan mengapa Anda juga harus memiliki izin untuk menghapus semua file OneDrive mereka.

Sebagai pengembang, Anda harus:

• mengetahui API mana yang dipanggil aplikasi.
• pahami dokumentasi API dan izin apa yang diperlukan API.
• gunakan izin sekecil mungkin untuk menyelesaikan tugas Anda.

API sering menyediakan akses ke penyimpanan data organisasi dan menarik perhatian penyerang yang ingin mengakses data tersebut.

Evaluasi izin yang Anda minta untuk memastikan bahwa Anda mencari pengaturan akses yang paling tidak istimewa sepenuhnya untuk menyelesaikan pekerjaan. Hindari meminta izin hak istimewa yang lebih tinggi; sebagai gantinya, bekerja dengan hati-hati melalui sejumlah besar izin yang disediakan API seperti Microsoft Graph. Temukan dan gunakan izin minimum untuk memenuhi kebutuhan Anda. Jika Anda tidak menulis kode untuk memperbarui profil pengguna, Anda tidak memintanya untuk aplikasi Anda. Jika Anda hanya mengakses pengguna dan grup, Anda tidak meminta akses ke informasi lain di direktori. Anda tidak meminta izin untuk mengelola email pengguna jika Anda tidak menulis kode yang mengakses email pengguna.

Dalam pengembangan aplikasi Zero Trust:

• Tentukan niat aplikasi Anda dan apa yang dibutuhkannya.
• Pastikan bahwa pelaku jahat tidak dapat membahayakan dan menggunakan aplikasi Anda dengan cara yang tidak Anda inginkan.
• Buat permintaan persetujuan di mana Anda menentukan persyaratan Anda (misalnya, baca email pengguna).

Peran administrator pengguna dan penyewa dalam izin dan persetujuan

Orang siapa yang dapat menyetujui permintaan Anda termasuk dalam dua kategori: admin yang selalu dapat menyetujui permintaan izin dan pengguna reguler yang bukan admin. Namun, admin penyewa memiliki pernyataan akhir dalam penyewa mereka mengenai izin mana yang memerlukan persetujuan admin dan izin mana yang dapat disetujui pengguna.

Saat perancang API memerlukan persetujuan admin untuk izin, izin tersebut selalu memerlukan persetujuan admin. Admin penyewa tidak dapat menimpanya dan hanya memerlukan persetujuan pengguna.

Saat perancang API menentukan izin yang memerlukan persetujuan pengguna, admin penyewa dapat menimpa saran persetujuan pengguna perancang API. Admin penyewa dapat melakukannya dengan "sakelar besar" di penyewa: semuanya memerlukan persetujuan admin. Mereka dapat mengesampingkan persetujuan pengguna dengan cara yang lebih terperinci dengan manajemen izin dan persetujuan. Misalnya, mereka mungkin mengizinkan pengguna untuk menyetujui permintaan persetujuan pengguna dari penerbit terverifikasi tetapi tidak dari penerbit lain. Dalam contoh lain, mereka mungkin mengizinkan User.Read untuk masuk ke pengguna dan membaca profil mereka tetapi memerlukan persetujuan admin untuk aplikasi yang meminta izin ke email atau ke file.

Perancang API membuat saran mereka tetapi admin penyewa memiliki kata terakhir. Oleh karena itu, sebagai pengembang, Anda tidak selalu tahu kapan aplikasi Anda memerlukan persetujuan admin. Senang merencanakan dan merancang sekitar itu tetapi ingat, ketika Anda membuat permintaan token, itu bisa ditolak karena alasan apa pun. Dalam kode Anda, Anda perlu menangani dengan baik tidak mendapatkan token karena admin penyewa tempat pelanggan atau pengguna Anda menjalankan aplikasi Anda memutuskan kapan izin memerlukan persetujuan admin.

Contoh menggunakan JavaScript MSAL

Untuk autentikasi dalam contoh ini, Anda menggunakan JavaScript Microsoft Authentication Library (MSAL) kami untuk memasukkan pengguna dalam satu aplikasi halaman (SPA) tempat semua logika aplikasi dijalankan dari browser.

Dari artikel Mulai Cepat terkait, Anda dapat mengunduh dan menjalankan sampel kode. Ini menunjukkan bagaimana aplikasi halaman tunggal (SPA) JavaScript dapat memasukkan pengguna dan memanggil Microsoft Graph menggunakan alur kode otorisasi dengan Proof Key for Code Exchange (PKCE). Sampel kode menunjukkan cara mendapatkan token akses untuk memanggil Microsoft Graph API atau API web apa pun.

Seperti yang ditunjukkan dalam contoh kode berikut, Anda membuat instans klien publik karena aplikasi yang berjalan sepenuhnya di browser harus merupakan klien publik. Pengguna bisa mendapatkan tangan mereka di internal aplikasi Anda ketika kode berada di browser.

// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);

Kemudian Anda menggunakan pustaka MSAL kami. Di MSAL JavaScript, ada API tertentu untuk masuk. Ada dua API yang menggunakan kemampuan tertentu dalam browser. Salah satunya adalah masuk dengan pengalaman pop-up; yang lain adalah masuk dengan pengalaman pengalihan browser.

Seperti yang ditunjukkan dalam contoh kode berikut, pop-up masuk menangani autentikasi yang perlu dilakukan pengguna dengan memanggil signIn fungsi .

function signIn() {

    /**
     * You can pass a custom request object. This overrides the initial configuration. For more information, visit:
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
     */

    myMSALObj.loginPopup(loginRequest)
        .then(handleResponse)
        .catch(error => {
            console.error(error);
        });
}

Aplikasi Anda bisa mendapatkan informasi tentang pengguna, seperti nama tampilan atau ID pengguna mereka. Selanjutnya, aplikasi Anda memerlukan otorisasi untuk membaca profil lengkap pengguna dari Microsoft Graph dengan mengikuti pola yang Anda gunakan di seluruh pustaka MSAL kami.

Seperti yang ditunjukkan dalam contoh kode di bawah ini, aplikasi Anda mencoba mendapatkan otorisasi dengan memanggil AcquireTokenSilent. Jika ID Microsoft Entra dapat mengeluarkan token tanpa berinteraksi dengan pengguna, maka AcquireTokenSilent mengembalikan token yang diperlukan aplikasi Anda untuk mengakses Microsoft Graph atas nama pengguna.

function getTokenPopup(request) {

    /**
     * See here for more info on account retrieval: 
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
     */
    request.account = myMSALObj.getAccountByUsername(username);
    
    return myMSALObj.`AcquireTokenSilent`(request)
        .catch(error => {
            console.warn("silent token acquisition fails. acquiring token using popup");
            if (error instanceof msal.InteractionRequiredAuthError) {
                // fallback to interaction when silent call fails
                return myMSALObj.`AcquireTokenPopup`(request)
                    .then(tokenResponse => {
                        console.log(tokenResponse);
                        return tokenResponse;
                    }).catch(error => {
                        console.error(error);
                    });
            } else {
                console.warn(error);
            }
    });
}

Namun, seringkali MICROSOFT Entra ID tidak dapat mengeluarkan token tanpa berinteraksi dengan pengguna (misalnya, pengguna mengubah kata sandi mereka atau tidak memberikan persetujuan). Oleh karena itu, AcquireTokenSilent mengirim kesalahan kembali ke aplikasi yang memerlukan interaksi pengguna. Saat aplikasi Menerima kesalahan, Anda akan kembali ke panggilan AcquireTokenPopup.

Pada saat itu, MICROSOFT Entra ID memiliki percakapan dengan pengguna sehingga mereka dapat mengautentikasi pengguna dan mengotorisasi aplikasi Anda untuk bertindak atas nama pengguna (misalnya, melakukan MFA, memberikan kata sandi mereka, memberikan persetujuan). Kemudian aplikasi Anda mendapatkan token yang diperlukan untuk bergerak maju.

Langkah utama dalam perjalanan perusahaan ke Zero Trust adalah mengadopsi metode autentikasi yang lebih kuat alih-alih hanya ID pengguna dan kata sandi. Contoh kode sebelumnya sepenuhnya memungkinkan perusahaan untuk pindah ke metode autentikasi yang lebih kuat yang dipilih perusahaan. Misalnya, autentikasi multifaktor, sepenuhnya tanpa kata sandi dengan kunci FIDO2, Microsoft Authenticator.

Langkah berikutnya

• Memperoleh otorisasi untuk mengakses sumber daya membantu Anda memahami cara terbaik memastikan Zero Trust saat memperoleh izin akses sumber daya untuk aplikasi Anda.
• Mengembangkan strategi izin aplikasi membantu Anda memutuskan pendekatan izin aplikasi Anda untuk manajemen kredensial.
• 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.
• API Protection menjelaskan praktik terbaik untuk melindungi API Anda melalui pendaftaran, menentukan izin dan persetujuan, dan menegakkan akses untuk mencapai tujuan Zero Trust Anda.
• Memanggil API dari API lain membantu Anda memastikan Zero Trust saat Anda memiliki satu API yang perlu memanggil API lain dan mengembangkan aplikasi Anda dengan aman saat bekerja atas nama pengguna.
• 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.