Gunakan Microsoft SQL Server secara selamat dengan Power Apps

Terdapat beberapa cara yang berbeza untuk menyambung dan mengesahkan ke SQL Server dengan Power Apps. Artikel ini menggariskan konsep yang boleh membantu dalam membuat pilihan tentang cara menyambung ke SQL Server dengan pendekatan keselamatan yang sepadan dengan keperluan aplikasi anda.

Penting

Artikel ini diguna pakai pada semua pangkalan data perhubungan dan sambungan yang tersirat.

Perbezaan antara sambungan tak tersirat dan tersirat

Sambungan ke SQL Server dicipta apabila anda mencipta aplikasi menggunakan Power Apps yang menyambung ke SQL Server. Apabila aplikasi itu diterbitkan dan dikongsi dengan orang lain, kedua-dua aplikasi dan sambungan digunakan untuk pengguna itu. Dalam erti kata lain, aplikasi dan sambungan—kedua-duanya boleh dilihat oleh pengguna yang berkongsi aplikasi.

Kaedah pengesahan yang digunakan untuk sambungan itu boleh tak tersirat atau tersirat. Kita juga boleh mengatakan bahawa sambungan itu dikongsi secara tak tersirat atau tersirat.

• Sambungan dikongsi secara tak tersirat bermaksud pengguna akhir aplikasi mesti mengesahkan ke SQL Server dengan kelayakan tak tersirat mereka sendiri. Biasanya pengesahan ini berlaku di belakang tabir sebagai sebahagian Microsoft Entra daripada atau jabat tangan pengesahan Windows. Pengguna tidak akan perasan apabila pengesahan berlaku.
• Sambungan yang dikongsi secara tersirat bermaksud pengguna secara tersirat menggunakan kelayakan akaun yang digunakan oleh pembuat aplikasi untuk menyambung dan mengesahkan ke sumber data semasa mencipta aplikasi. Kelayakan pengguna akhir tidak digunakan untuk pengesahan. Setiap kali pengguna akhir menjalankan aplikasi, mereka menggunakan kelayakan yang dicipta oleh penulis aplikasi.

Empat jenis pengesahan sambungan yang berikut boleh digunakan dengan SQL Server untuk Power Apps:

Jenis Pengesahan	Kaedah sambungan Power Apps
Microsoft Entra Bersepadu	Tak Tersirat
Pengesahan Pelayan SQL	Tersirat
Pengesahan Windows	Tersirat
Pengesahan Windows (tidak dikongsi)	Tak Tersirat

Risiko perkongsian sambungan tersirat

Oleh kerana kedua-dua aplikasi dan sambungannya digunakan ke pengguna akhir, ini bermaksud pengguna akhir boleh mengarang aplikasi baharu berasaskan pada sambungan itu.

Contohnya, pertimbangkan anda mencipta aplikasi yang menapis keluar data yang anda tidak mahu pengguna lihat. Data yang ditapis keluar wujud dalam pangkalan data. Tetapi anda bergantung pada penapis yang anda konfigurasikan untuk memastikan pengguna akhir tidak dapat melihat data tertentu.

Selepas anda menggunakan aplikasi ini, pengguna akhir boleh menggunakan sambungan yang digunakan dengan aplikasi anda dalam sebarang aplikasi baharu yang mereka cipta. Dalam aplikasi baharu, pengguna boleh melihat data yang anda tapis keluar dalam aplikasi anda.

Penting

Sebaik sahaja sambungan yang dikongsi secara tersirat digunakan ke pengguna akhir, sekatan yang anda mungkin telah masukkan dalam aplikasi yang dikongsi oleh anda (seperti penapis atau akses baca sahaja) tidak lagi sah untuk aplikasi baharu yang dicipta oleh pengguna akhir. Pengguna akhir akan mempunyai apa sahaja hak yang dibenarkan oleh pengesahan sebagai sebahagian daripada sambungan yang dikongsi secara tersirat.

Dunia nyata menggunakan sambungan tersirat

Terdapat kes penggunaan yang sah untuk kedua-dua kaedah pengesahan yang tersirat dan tak tersirat. Pertimbangkan model keselamatan dan kemudahan pembangunan apabila memilih pendekatan anda. Sebagai peraturan umum, gunakan kaedah pengesahan tak tersirat untuk sebarang keadaan yang anda mempunyai keperluan perniagaan di mana data mesti dihadkan berdasarkan baris atau lajur.

Untuk contoh kes penggunaan sambungan tak tersirat, pertimbangkan pengurus jualan yang hanya boleh dibenarkan untuk melihat diskaun harga atau data kos asas dalam jadual yang sama dengan keperluan Sales Professional bagi melihat produk dan harga.

Walau bagaimanapun, tidak semua data mungkin perlu dilindungi dengan cara yang sama. Aplikasi dikongsi dan digunakan untuk pengguna khusus atau kumpulan pengguna. Orang di luar kumpulan itu tidak mempunyai akses kepada aplikasi atau sambungan. Oleh itu, jika semua orang dalam kumpulan dibenarkan untuk melihat semua data dalam pangkalan data, kaedah tersirat bagi perkongsian berfungsi dengan baik.

Untuk contoh kes penggunaan sambungan tersirat, pertimbangkan jabatan yang mempunyai pangkalan data projek kecil yang sedang mereka jejak. Pangkalan data mungkin boleh termasuk maklumat seperti tiket kerja jabatan atau kalendar korporat untuk seluruh syarikat. Dalam senario ini, pembinaan lebih banyak aplikasi di atas sambungan yang dikongsi secara tersirat mungkin digalakkan selagi semua data boleh diakses oleh semua pengguna yang diberikan akses.

Aplikasi yang dicipta menggunakan Power Apps direka bentuk untuk boleh didekati oleh pengguna akhir. Senario seperti ini adalah lazim kerana kos pembangunan yang berkaitan dengan sambungan yang tersirat adalah rendah.

Aplikasi berasaskan jabatan boleh berkembang ke seluruh perusahaan dan aplikasi kritikal misi. Dalam senario ini, adalah penting untuk memahami bahawa apabila aplikasi jabatan berkembang ke seluruh perusahaan, ia akan perlu mempunyai keselamatan perusahaan tradisional terbina. Pendekatan ini lebih mahal untuk usaha membina aplikasi tetapi penting dalam senario seluruh korporat.

Keselamatan klien dan pelayan

Anda tidak boleh bergantung pada keselamatan data melalui penapisan atau operasi pihak klien yang lain untuk dilindungi. Aplikasi yang memerlukan penapisan data yang selamat mesti memastikan kedua-dua pengesahan dan penapisan pengguna berlaku pada pelayan.

Gunakan perkhidmatan seperti ID dan Microsoft Entra bukannya bergantung pada penapis yang direka dalam apl apabila ia berkaitan dengan identiti pengguna dan keselamatan. Konfigurasi ini memastikan penapis bahagian pelayan berfungsi seperti yang dijangkakan.

Ilustrasi berikut menerangkan cara corak keselamatan dalam aplikasi berbeza antara model keselamatan bahagian klien dan pelayan.

Dalam corak aplikasi keselamatan klien, [1] pengguna hanya mengesahkan ke aplikasi pada bahagian klien. Kemudian [2] aplikasi meminta maklumat perkhidmatan dan [3] perkhidmatan mengembalikan maklumat sepenuhnya berdasarkan pada permintaan data.

Dalam corak keselamatan bahagian pelayan, [1] pertama sekali pengguna mengesahkan ke perkhidmatan supaya pengguna dikenali oleh perkhidmatan. Kemudian [2] apabila panggilan dibuat daripada aplikasi, perkhidmatan [3] menggunakan identiti pengguna semasa yang dikenali untuk menapis data dengan betul dan [4] mengembalikan data.

Senario perkongsian jabatan tersirat yang diterangkan di atas ialah kombinasi kedua-dua corak ini. Pengguna mesti log masuk ke perkhidmatan menggunakan Power Apps Microsoft Entra kelayakan. Tingkah laku ini ialah corak aplikasi keselamatan pelayan. Pengguna diketahui menggunakan identiti pada Microsoft Entra perkhidmatan. Oleh itu, aplikasi dihadkan kepada set pengguna yang berkongsi Power Apps secara rasmi.

Walau bagaimanapun, sambungan dikongsi yang tersirat ke SQL Server ialah corak aplikasi keselamatan klien. Server SQL hanya mengetahui bahawa nama pengguna dan kata laluan khusus digunakan. Contohnya sebarang penapisan bahagian klien, boleh dipintas dengan aplikasi baharu menggunakan nama pengguna dan kata laluan yang sama.

Untuk menapis data secara selamat pada bahagian pelayan, gunakan ciri keselamatan terbina dalam SQL Server seperti keselamatan tahap rendah untuk baris dan menolak keizinan ke objek tertentu (seperti lajur) ke pengguna tertentu. Pendekatan ini akan menggunakan Microsoft Entra identiti pengguna untuk menapis data pada pelayan.

Beberapa perkhidmatan korporat sedia ada telah menggunakan pendekatan yang menangkap identiti pengguna dalam lapisan data perniagaan seperti yang dilakukan oleh Microsoft Dataverse. Dalam kes ini, lapisan perniagaan mungkin sama ada menggunakan atau tidak menggunakan keselamatan peringkat baris SQL Server dan menolak ciri secara langsung. Jika tidak, kebiasaannya kes bagi keselamatan yang didayakan menggunakan prosedur atau pandangan yang disimpan.

Lapisan perniagaan (di bahagian pelayan) menggunakan identiti pengguna Microsoft Entra yang diketahui untuk menggunakan prosedur yang disimpan sebagai prinsipal SQL Server dan menapis data. Walau bagaimanapun pada masa ini Power Apps tidak disambungkan ke prosedur yang disimpan. Lapisan perniagaan juga boleh menggunakan pandangan yang menggunakan identiti sebagai Microsoft Entra prinsipal SQL Server. Dalam kes ini, gunakan Power Apps untuk menyambung ke pandangan supaya data ditapis pada bahagian pelayan. Hanya mendedahkan pandangan kepada pengguna mungkin memerlukan aliran Power Automate untuk kemas kini.

Lihat juga

Gambaran keseluruhan penyambung untuk aplikasi kanvas