Perencanaan implementasi Power BI: Perencanaan keamanan pembuat konten

Catatan

Artikel ini merupakan bagian dari rangkaian artikel Perencanaan implementasi Power BI. Seri ini berfokus terutama pada pengalaman Power BI dalam Microsoft Fabric. Untuk pengantar rangkaian ini, lihat Perencanaan implementasi Power BI.

Artikel perencanaan keamanan ini menjelaskan strategi untuk pembuat konten yang bertanggung jawab untuk membuat model semantik (sebelumnya dikenal sebagai himpunan data), aliran data, datamart, laporan, atau dasbor. Ini terutama ditargetkan pada:

• Administrator Power BI: Administrator yang bertanggung jawab untuk mengawasi Power BI di organisasi.
• Tim Center of Excellence, IT, dan BI: Tim yang juga bertanggung jawab untuk mengawasi Power BI. Mereka mungkin perlu berkolaborasi dengan administrator Power BI, tim keamanan informasi, dan tim terkait lainnya.
• Pembuat dan pemilik konten: Pembuat BI layanan mandiri yang perlu membuat, menerbitkan, mengamankan, dan mengelola konten yang digunakan orang lain.

Rangkaian artikel dimaksudkan untuk memperluas konten dalam laporan resmi keamanan Power BI. Meskipun laporan resmi keamanan Power BI berfokus pada topik teknis utama seperti autentikasi, residensi data, dan isolasi jaringan, tujuan utama seri ini adalah untuk memberi Anda pertimbangan dan keputusan untuk membantu Anda merencanakan keamanan dan privasi.

Dalam organisasi, banyak pengguna adalah pembuat konten. Pembuat konten menghasilkan dan menerbitkan konten yang dilihat oleh orang lain. Pembuat konten adalah fokus dari artikel ini.

Tip

Sebaiknya tinjau artikel Laporkan perencanaan keamanan konsumen terlebih dahulu. Ini menjelaskan strategi untuk menyediakan konten dengan aman kepada konsumen baca-saja termasuk cara memberlakukan keamanan data.

Strategi untuk pembuat konten

Fondasi sistem BI layanan mandiri yang diatur dengan baik dimulai dengan pembuat konten dan pemilik. Mereka membuat dan memvalidasi model dan laporan semantik. Dalam banyak kasus, pembuat konten juga menyiapkan izin untuk mengelola keamanan untuk konten mereka.

Tip

Kami menyarankan agar Anda menumbuhkan budaya data yang menjadikan keamanan dan perlindungan data sebagai bagian normal dari peran semua orang. Untuk mencapai tujuan tersebut, pendidikan, dukungan, dan pelatihan pengguna sangat penting.

Untuk tujuan keamanan dan izin, pertimbangkan bahwa ada dua jenis pembuat konten: pembuat data dan pembuat laporan. Mereka dapat bertanggung jawab untuk membuat dan mengelola BI perusahaan atau konten BI layanan mandiri.

Pembuat data

Pembuat data adalah setiap pengguna Power BI yang membuat model semantik, aliran data, atau datamart.

Berikut adalah beberapa skenario pembuat data umum.

• Membuat model semantik baru: Membuat dan menguji model data baru di Power BI Desktop. Kemudian diterbitkan ke layanan Power BI sehingga dapat digunakan sebagai model semantik bersama untuk banyak laporan. Untuk informasi selengkapnya tentang menggunakan kembali model semantik bersama, lihat skenario penggunaan BI layanan mandiri terkelola.
• Memperluas dan menyesuaikan model semantik: Membuat koneksi langsung ke model semantik bersama yang sudah ada di Power BI Desktop. Konversikan koneksi langsung ke model lokal, yang memungkinkan perluasan desain model dengan tabel atau kolom baru. Untuk informasi selengkapnya tentang memperluas dan menyesuaikan model semantik bersama, lihat skenario penggunaan BI layanan mandiri terkelola yang dapat disesuaikan.
• Buat aliran data baru: Di layanan Power BI, buat aliran data baru sehingga dapat digunakan sebagai sumber oleh banyak model semantik. Untuk informasi selengkapnya tentang menggunakan kembali aktivitas persiapan data, lihat skenario penggunaan persiapan data mandiri.
• Buat datamart baru. Di layanan Power BI, buat datamart baru.

Pembuat data sering ditemukan di tim BI perusahaan dan di Center of Excellence (COE). Mereka juga memiliki peran kunci untuk bermain di unit bisnis dan departemen terdesentralisasi yang memelihara dan mengelola data mereka sendiri.

Untuk pertimbangan lain tentang BI yang dipimpin bisnis, BI layanan mandiri terkelola, dan BI perusahaan, lihat artikel Kepemilikan dan manajemen konten.

Pembuat laporan

Pembuat laporan membuat laporan dan dasbor untuk memvisualisasikan data yang bersumber dari model semantik yang ada.

Berikut adalah beberapa skenario pembuat laporan umum.

• Buat laporan baru termasuk model data: Buat dan uji laporan dan model data baru di Power BI Desktop. File Power BI Desktop yang berisi satu atau beberapa halaman laporan dan menyertakan model data diterbitkan ke layanan Power BI. Pembuat konten baru biasanya menggunakan metode ini sebelum mereka sadar menggunakan model semantik bersama. Ini juga sesuai untuk kasus penggunaan sempit yang tidak memerlukan penggunaan kembali data.
• Membuat laporan koneksi langsung: Buat laporan Power BI baru yang tersambung ke model semantik bersama di layanan Power BI. Untuk informasi selengkapnya tentang menggunakan kembali model semantik bersama, lihat skenario penggunaan BI layanan mandiri terkelola.
• Membuat buku kerja Excel yang tersambung: Buat laporan Excel baru yang tersambung ke model semantik bersama di layanan Power BI. Koneksi pengalaman Excel, daripada unduhan data, sangat dianjurkan.
• Membuat laporan DirectQuery: Buat laporan Power BI baru yang tersambung ke sumber data yang didukung dalam mode DirectQuery. Salah satu situasi ketika metode ini berguna adalah ketika Anda ingin memanfaatkan keamanan pengguna yang diterapkan oleh sistem sumber.

Pembuat laporan ditemukan di setiap unit bisnis dalam organisasi. Biasanya ada lebih banyak pembuat laporan di organisasi daripada pembuat data.

Tip

Meskipun tidak setiap model semantik adalah model semantik bersama, masih layak untuk mengadopsi strategi BI layanan mandiri terkelola. Strategi ini menggunakan kembali model semantik bersama jika memungkinkan. Dengan cara itu, pembuatan laporan dan pembuatan data dipisahkan. Setiap pembuat konten dari unit bisnis apa pun dapat secara efektif menggunakan strategi ini.

Izin untuk pembuat

Bagian ini menjelaskan izin paling umum untuk pembuat data dan pembuat laporan.

Bagian ini tidak dimaksudkan untuk menjadi daftar semua-inklusif dari setiap izin yang mungkin. Sebaliknya, ini dimaksudkan untuk membantu merencanakan strategi Anda untuk mendukung berbagai jenis pembuat konten. Tujuan Anda harus mengikuti prinsip hak istimewa paling sedikit. Prinsip ini memungkinkan izin yang cukup bagi pengguna untuk menjadi produktif, tanpa izin provisi berlebihan.

Membuat konten baru

Izin berikut biasanya diperlukan untuk membuat konten baru.

Izin	Pembuat laporan	Pembuat model semantik	Pembuat aliran data	Pembuat Datamart
Akses ke sumber data yang mendasar
Izin Baca dan Bangun model semantik
Izin Baca Aliran Data (saat aliran data digunakan sebagai sumber, melalui peran Penampil ruang kerja)
Akses tempat file Power BI Desktop asli disimpan
Izin untuk menggunakan visual kustom

Menerbitkan izin konten

Izin berikut biasanya diperlukan untuk menerbitkan konten.

Izin	Pembuat laporan	Pembuat model semantik	Pembuat aliran data	Pembuat Datamart
Peran ruang kerja: Kontributor, Anggota, atau Admin
Izin Tulis model semantik (ketika pengguna bukan milik peran ruang kerja)
Peran alur penyebaran untuk menerbitkan item (opsional)

Me-refresh data

Izin berikut biasanya diperlukan untuk merefresh data.

Izin	Pembuat laporan	Pembuat model semantik	Pembuat aliran data	Pembuat Datamart
Pemilik yang ditetapkan (yang telah menyiapkan pengaturan atau mengambil alih item)
Akses ke sumber data yang mendasar (saat gateway tidak digunakan)
Akses ke sumber data di gateway (saat sumber berada di tempat atau di jaringan virtual)

Sisa artikel ini menjelaskan pertimbangan untuk izin pembuat konten.

Tip

Untuk izin yang terkait dengan menampilkan konten, lihat artikel Melaporkan perencanaan keamanan konsumen.

Daftar periksa - Saat merencanakan strategi keamanan Anda untuk pembuat konten, keputusan dan tindakan utama meliputi:

• Menentukan siapa pembuat data Anda: Pastikan Anda terbiasa dengan siapa yang membuat model semantik, aliran data, dan datamart. Verifikasi bahwa Anda memahami apa kebutuhan mereka sebelum memulai aktivitas perencanaan keamanan Anda.
• Tentukan siapa pembuat laporan Anda: Pastikan Anda terbiasa dengan siapa yang membuat laporan, dasbor, buku kerja, dan kartu skor. Verifikasi bahwa Anda memahami apa kebutuhan mereka sebelum memulai aktivitas perencanaan keamanan Anda.

Menemukan konten untuk pembuat

Pengguna dapat mengandalkan penemuan data untuk menemukan model semantik dan datamart. Penemuan data adalah fitur Power BI yang memungkinkan pembuat konten menemukan aset data yang ada—bahkan ketika mereka tidak memiliki izin apa pun untuk konten tersebut.

Penemuan data yang ada berguna untuk:

• Melaporkan pembuat yang ingin menggunakan model semantik yang ada untuk laporan baru.
• Melaporkan pembuat yang ingin mengkueri data dari datamart yang sudah ada.
• Pembuat model semantik yang ingin menggunakan model semantik yang ada untuk model komposit baru.

Catatan

Penemuan data di Power BI bukan izin keamanan data. Ini adalah pengaturan yang memungkinkan pembuat laporan membaca metadata, membantu mereka menemukan data dan meminta akses ke sana.

Anda dapat menyiapkan model semantik atau datamart sebagai dapat ditemukan saat telah didukung (bersertifikat atau dipromosikan). Saat dapat ditemukan, pembuat konten dapat menemukannya di hub data.

Pembuat konten juga dapat meminta akses ke model semantik atau datamart. Pada dasarnya, permintaan akses meminta izin Build, yang diperlukan untuk membuat konten baru berdasarkan permintaan tersebut. Saat menanggapi permintaan akses, pertimbangkan untuk menggunakan grup alih-alih pengguna individual. Untuk informasi selengkapnya tentang cara menggunakan grup untuk tujuan ini, lihat Meminta alur kerja akses untuk konsumen.

Pertimbangkan tiga contoh berikut.

• Model semantik Ringkasan Penjualan disertifikasi. Ini adalah sumber tepercaya dan otoritatif untuk pelacakan penjualan. Banyak pembuat laporan layanan mandiri di seluruh organisasi menggunakan model semantik ini. Jadi, ada banyak laporan dan model komposit yang ada berdasarkan model semantik. Untuk mendorong kreator lain menemukan dan menggunakan model semantik, ini ditetapkan sebagai dapat ditemukan.
• Model semantik Statistik Inventori disertifikasi . Ini adalah sumber tepercaya dan otoritatif untuk analisis inventarisasi. Model semantik dan laporan terkait dipertahankan dan didistribusikan oleh tim BI perusahaan. Karena desain model semantik yang kompleks, hanya tim BI perusahaan yang diizinkan untuk membuat dan memelihara konten inventori. Karena tujuannya adalah untuk mencegah pembuat laporan menggunakan model semantik, itu tidak ditetapkan sebagai dapat ditemukan.
• Model semantik Bonus Eksekutif berisi informasi yang sangat rahasia. Izin untuk melihat atau memperbarui model semantik ini dibatasi untuk beberapa pengguna. Model semantik ini tidak ditetapkan sebagai dapat ditemukan.

Cuplikan layar berikut menunjukkan model semantik di hub data di layanan Power BI. Secara khusus, ini menunjukkan contoh pesan akses Permintaan untuk model semantik yang dapat ditemukan. Pesan ini ditampilkan ketika pengguna saat ini tidak memiliki akses. Pesan Akses permintaan telah disesuaikan dalam pengaturan model semantik.

Pesan akses Permintaan dibaca: Untuk pelaporan penjualan standar MTD/QTD/YTD, model semantik ini adalah sumber otoritatif dan bersertifikat. Harap minta akses ke model semantik dengan melengkapi formulir yang terletak di https://COE.contoso.com/RequestAccess. Anda akan dimintai pembenaran bisnis singkat, dan manajer Center of Excellence juga akan diminta untuk menyetujui permintaan tersebut. Akses akan diaudit setiap enam bulan.

Catatan

Budaya data dan sikap Anda pada demokratisasi data harus sangat memengaruhi apakah Anda mengaktifkan penemuan data. Untuk informasi selengkapnya tentang penemuan data, lihat skenario penggunaan BI layanan mandiri terkelola yang dapat disesuaikan.

Ada tiga pengaturan penyewa yang terkait dengan penemuan.

• Pengaturan Temukan penyewa konten memungkinkan administrator Power BI untuk mengatur grup pengguna mana yang diizinkan untuk menemukan data. Ini terutama ditargetkan pada pembuat laporan yang mungkin perlu menemukan model semantik yang ada saat membuat laporan. Ini juga berguna untuk pembuat model semantik yang mungkin mencari data yang ada yang dapat mereka gunakan dalam pengembangan model komposit mereka. Meskipun dimungkinkan untuk mengaturnya untuk kelompok keamanan tertentu, ada baiknya untuk mengaktifkan pengaturan untuk seluruh organisasi. Pengaturan penemuan pada model semantik individu dan aliran data akan mengontrol apa yang dapat ditemukan. Biasanya, Anda mungkin mempertimbangkan untuk membatasi kemampuan ini hanya untuk pembuat konten yang disetujui.
• Pengaturan Buat penyewa yang dapat ditemukan konten bersertifikat memungkinkan administrator Power BI mengatur grup mana yang dapat mengatur konten agar dapat ditemukan (ketika mereka juga memiliki izin untuk mengedit item serta izin untuk mensertifikasi konten, yang diberikan oleh pengaturan penyewa Sertifikasi). Kemampuan untuk mensertifikasi konten harus dikontrol dengan ketat. Dalam kebanyakan kasus, pengguna yang sama yang diizinkan untuk mensertifikasi konten harus diizinkan untuk mengaturnya sebagai dapat ditemukan. Dalam beberapa situasi, Anda mungkin ingin membatasi kemampuan ini hanya untuk pembuat data yang disetujui.
• Pengaturan Buat penyewa yang dapat ditemukan konten yang dipromosikan memungkinkan administrator Power BI mengatur grup mana yang bisa mengatur konten sebagai dapat ditemukan (saat mereka juga memiliki izin untuk mengedit data). Karena kemampuan untuk mempromosikan konten terbuka untuk semua pembuat konten, dalam kebanyakan kasus, kemampuan ini harus tersedia untuk semua pengguna. Biasanya, Anda mungkin mempertimbangkan untuk membatasi kemampuan ini hanya untuk pembuat konten yang disetujui.

Daftar periksa - Saat merencanakan penemuan data untuk pembuat konten Anda, keputusan dan tindakan utama meliputi:

• Mengklarifikasi kebutuhan untuk penemuan data: Pertimbangkan posisi organisasi Anda dalam mendorong pembuat konten untuk menemukan model dan datamart semantik yang ada. Jika sesuai, buat kebijakan tata kelola tentang bagaimana penemuan data harus digunakan.
• Memutuskan siapa yang dapat menemukan konten: Tentukan apakah ada pengguna Power BI yang diizinkan untuk menemukan konten, atau apakah penemuan harus terbatas pada grup pengguna tertentu (misalnya, sekelompok pembuat konten yang disetujui). Atur pengaturan Temukan penyewa konten agar selaras dengan keputusan ini.
• Memutuskan siapa yang dapat mengatur konten bersertifikat agar dapat ditemukan: Memutuskan apakah ada pengguna Power BI (yang memiliki izin untuk mengedit model semantik atau datamart, serta izin untuk mensertifikasinya) dapat mengaturnya sebagai dapat ditemukan. Atur pengaturan Buat penyewa yang dapat ditemukan konten bersertifikat agar selaras dengan keputusan ini.
• Memutuskan siapa yang dapat mengatur konten yang dipromosikan agar dapat ditemukan: Tentukan apakah ada pengguna Power BI (yang memiliki izin untuk mengedit model semantik atau datamart) dapat mengaturnya sebagai dapat ditemukan. Atur pengaturan Buat penyewa yang dapat ditemukan konten yang dipromosikan agar selaras dengan keputusan ini.
• Sertakan dalam dokumentasi dan pelatihan untuk pembuat model semantik: Sertakan panduan untuk pembuat model semantik Anda tentang kapan tepat untuk menggunakan penemuan data untuk model semantik dan datamart yang mereka miliki dan kelola.
• Sertakan dalam dokumentasi dan pelatihan untuk pembuat laporan: Sertakan panduan untuk pembuat konten Anda tentang cara kerja penemuan data, dan apa yang dapat mereka harapkan.

Meminta alur kerja akses untuk pembuat

Pengguna dapat meminta akses ke konten dengan dua cara.

• Untuk konsumen konten: Pengguna menerima tautan ke laporan atau aplikasi yang ada di layanan Power BI. Untuk melihat item, konsumen dapat memilih tombol Minta akses . Untuk informasi selengkapnya, lihat artikel Melaporkan perencanaan keamanan konsumen.
• Untuk pembuat konten: Pengguna menemukan model semantik atau datamart di hub data. Untuk membuat laporan baru atau model komposit berdasarkan data yang ada, pembuat konten dapat memilih tombol Minta akses . Pengalaman ini adalah fokus dari bagian ini.

Secara default, permintaan akses ke model semantik atau datamart masuk ke pemilik. Pemilik adalah pengguna yang terakhir menjadwalkan refresh data atau info masuk input. Mengandalkan satu pengguna untuk memproses permintaan akses mungkin dapat diterima untuk model semantik tim. Namun, itu mungkin tidak praktis atau dapat diandalkan.

Alih-alih mengandalkan satu pemilik, Anda dapat menentukan instruksi kustom yang disajikan kepada pengguna saat mereka meminta akses ke model semantik atau datamart. Instruksi kustom sangat membantu ketika:

• Model semantik diatur sebagai dapat ditemukan.
• Persetujuan permintaan akses akan dilakukan oleh seseorang selain pemilik data.
• Ada proses yang ada di tempat yang perlu diikuti untuk permintaan akses.
• Pelacakan siapa yang meminta akses, kapan, dan mengapa diperlukan untuk alasan audit atau kepatuhan.
• Penjelasan diperlukan untuk cara meminta akses, dan untuk menetapkan harapan.

Cuplikan layar berikut menunjukkan contoh menyiapkan instruksi kustom yang dilihat pengguna saat mereka meminta izin Build. Instruksi kustom dibaca: Untuk pelaporan penjualan standar MTD/QTD/YTD, model semantik ini adalah sumber otoritatif dan bersertifikat. Harap minta akses ke model semantik dengan melengkapi formulir yang terletak di https://COE.contoso.com/RequestAccess. Anda akan dimintai pembenaran bisnis singkat, dan manajer Center of Excellence juga akan diminta untuk menyetujui permintaan tersebut. Akses akan diaudit setiap enam bulan.

Ada banyak opsi untuk membuat formulir. Power Apps dan Microsoft Forms adalah opsi kode rendah dan mudah digunakan. Kami menyarankan agar Anda membuat formulir dengan cara yang independen dari satu pengguna. Sangat penting bahwa formulir Anda dibuat, dikelola, dan dipantau oleh tim yang tepat.

Kami menyarankan agar Anda membuat informasi bermanfaat untuk:

• Pembuat konten sehingga mereka tahu apa yang diharapkan saat meminta akses.
• Pemilik dan administrator konten sehingga mereka tahu cara mengelola permintaan yang dikirimkan.

Tip

Untuk informasi selengkapnya tentang menanggapi permintaan akses baca dari konsumen, lihat Meminta alur kerja akses untuk konsumen. Ini juga mencakup informasi tentang menggunakan grup (bukan pengguna individual).

Daftar periksa - Saat merencanakan alur kerja Akses permintaan, keputusan dan tindakan utama meliputi:

• Mengklarifikasi preferensi tentang cara menangani permintaan akses: Tentukan situasi mana yang dapat diterima untuk persetujuan pemilik, dan kapan proses yang berbeda harus digunakan. Jika sesuai, buat kebijakan tata kelola tentang bagaimana permintaan akses harus ditangani.
• Sertakan dalam dokumentasi dan pelatihan untuk model semantik dan pembuat datamart: Sertakan panduan untuk model semantik dan pembuat datamart Anda tentang bagaimana dan kapan mengatur instruksi kustom untuk permintaan akses.
• Sertakan dalam dokumentasi dan pelatihan untuk pembuat laporan: Sertakan panduan untuk pembuat laporan Anda tentang apa yang dapat mereka harapkan saat meminta izin Build untuk model semantik dan datamart.

Membuat dan menerbitkan konten

Bagian ini mencakup aspek keamanan yang berlaku untuk pembuat konten.

Catatan

Untuk konsumen yang melihat laporan, dasbor, dan kartu skor, lihat artikel Melaporkan perencanaan keamanan konsumen. Pertimbangan yang terkait dengan izin aplikasi juga tercakup dalam artikel tersebut.

Peran ruang kerja

Anda memberikan akses ruang kerja dengan menambahkan pengguna atau grup (termasuk grup keamanan, grup Microsoft 365, dan daftar distribusi) ke peran ruang kerja. Menetapkan pengguna ke peran ruang kerja memungkinkan Anda menentukan apa yang dapat mereka lakukan dengan ruang kerja dan kontennya.

Catatan

Untuk informasi selengkapnya tentang pertimbangan perencanaan ruang kerja, lihat artikel perencanaan ruang kerja. Untuk informasi selengkapnya tentang grup, lihat artikel Perencanaan keamanan tingkat penyewa.

Karena tujuan utama ruang kerja adalah kolaborasi, akses ruang kerja sebagian besar relevan untuk pengguna yang memiliki dan mengelola kontennya. Saat mulai merencanakan peran ruang kerja, sangat membantu untuk mengajukan pertanyaan berikut kepada diri Anda sendiri.

• Apa harapan tentang bagaimana kolaborasi akan terjadi di ruang kerja?
• Siapa akan bertanggung jawab untuk mengelola konten di ruang kerja?
• Apakah niat untuk menetapkan pengguna atau grup individual ke peran ruang kerja?

Ada empat peran ruang kerja Power BI: Admin, Anggota, Kontributor, dan Penampil. Tiga peran pertama relevan dengan pembuat konten, yang membuat dan menerbitkan konten. Peran Penampil relevan dengan konsumen baca-saja.

Empat izin peran ruang kerja ditumpuk. Itu berarti bahwa administrator ruang kerja memiliki semua kemampuan yang tersedia untuk anggota, kontributor, dan penonton. Demikian juga, anggota memiliki semua kemampuan yang tersedia untuk kontributor dan penonton. Kontributor memiliki semua kemampuan yang tersedia untuk penonton.

Tip

Lihat dokumentasi peran ruang kerja untuk referensi otoritatif untuk masing-masing dari empat peran.

Administrator ruang kerja

Pengguna yang ditetapkan ke peran Admin menjadi administrator ruang kerja. Mereka dapat mengelola semua pengaturan dan melakukan semua tindakan, termasuk menambahkan atau menghapus pengguna (termasuk administrator ruang kerja lainnya).

Administrator ruang kerja dapat memperbarui atau menghapus aplikasi Power BI (jika ada). Mereka dapat, secara opsional, memungkinkan kontributor memperbarui aplikasi untuk ruang kerja. Untuk informasi selengkapnya, lihat Variasi ke peran ruang kerja nanti di artikel ini.

Tip

Saat merujuk ke administrator, pastikan untuk mengklarifikasi apakah Anda berbicara tentang administrator ruang kerja atau administrator tingkat penyewa Power BI.

Berhati-hatilah untuk memastikan bahwa hanya individu tepercaya dan andal yang merupakan administrator ruang kerja. Administrator ruang kerja memiliki hak istimewa tinggi. Mereka memiliki akses untuk melihat dan mengelola semua konten di ruang kerja. Mereka dapat menambahkan dan menghapus pengguna (termasuk administrator lain) ke peran ruang kerja apa pun. Mereka juga dapat menghapus ruang kerja.

Kami menyarankan agar setidaknya ada dua administrator sehingga satu berfungsi sebagai cadangan jika administrator utama tidak tersedia. Ruang kerja yang tidak memiliki administrator dikenal sebagai ruang kerja tanpa intim. Status yatim piatu terjadi ketika pengguna meninggalkan organisasi dan tidak ada administrator alternatif yang ditetapkan ke ruang kerja. Untuk informasi selengkapnya tentang cara mendeteksi dan memperbaiki ruang kerja yatim piatu, lihat artikel Menampilkan ruang kerja.

Idealnya, Anda harus dapat menentukan siapa yang bertanggung jawab atas konten ruang kerja dengan siapa administrator dan anggota ruang kerja berada (dan kontak yang ditentukan untuk ruang kerja). Namun, beberapa organisasi mengadopsi kepemilikan konten dan strategi manajemen yang membatasi pembuatan ruang kerja untuk pengguna atau grup tertentu. Mereka biasanya memiliki proses pembuatan ruang kerja yang mapan yang dikelola oleh departemen IT. Dalam hal ini, administrator ruang kerja akan menjadi departemen IT daripada pengguna yang langsung membuat dan menerbitkan konten.

Anggota ruang kerja

Pengguna yang ditetapkan ke peran Anggota dapat menambahkan pengguna ruang kerja lain (tetapi bukan administrator). Mereka juga dapat mengelola izin untuk semua konten di ruang kerja.

Anggota ruang kerja dapat menerbitkan atau membatalkan penerbitan aplikasi untuk ruang kerja, berbagi item ruang kerja atau aplikasi, dan mengizinkan pengguna lain berbagi item ruang kerja aplikasi.

Anggota ruang kerja harus dibatasi untuk pengguna yang perlu mengelola pembuatan konten ruang kerja dan menerbitkan aplikasi. Dalam beberapa kasus, administrator ruang kerja memenuhi tujuan tersebut, sehingga Anda mungkin tidak perlu menetapkan pengguna atau grup apa pun ke peran Anggota. Ketika administrator ruang kerja tidak terkait langsung dengan konten ruang kerja (misalnya, karena TI mengelola proses pembuatan ruang kerja), anggota ruang kerja mungkin merupakan pemilik sejati yang bertanggung jawab atas konten ruang kerja.

Kontributor ruang kerja

Pengguna yang ditetapkan ke peran Kontributor dapat membuat, mengedit, atau menghapus konten ruang kerja.

Kontributor tidak dapat memperbarui aplikasi Power BI (jika ada untuk ruang kerja) kecuali jika itu diizinkan oleh pengaturan ruang kerja. Untuk informasi selengkapnya, lihat Variasi ke peran ruang kerja nanti di artikel ini.

Sebagian besar pembuat konten di organisasi adalah kontributor ruang kerja.

Penampil ruang kerja

Pengguna yang ditetapkan ke peran Penampil dapat melihat dan berinteraksi dengan semua konten ruang kerja.

Peran Penampil relevan dengan konsumen baca-saja untuk tim kecil dan skenario informal. Ini sepenuhnya dijelaskan dalam artikel Laporan perencanaan keamanan konsumen.

Pertimbangan kepemilikan ruang kerja

Pertimbangkan contoh di mana tindakan berikut diambil untuk menyiapkan ruang kerja baru.

1. Juara Power BI tertentu dan anggota satelit Center of Excellence (COE) telah diberikan izin di pengaturan penyewa untuk membuat ruang kerja baru. Mereka telah dilatih dalam strategi organisasi konten dan standar penamaan.
2. Anda (pembuat konten) mengirimkan permintaan untuk membuat ruang kerja untuk proyek baru yang akan Anda kelola. Ruang kerja akan menyertakan laporan yang melacak kemajuan proyek Anda.
3. Juara Power BI untuk unit bisnis Anda menerima permintaan. Mereka menentukan bahwa ruang kerja baru dibenarkan. Mereka kemudian membuat ruang kerja dan menetapkan grup keamanan juara Power BI (untuk unit bisnis mereka) ke peran Admin ruang kerja.
4. Juara Power BI menetapkan Anda (pembuat konten) ke peran Anggota ruang kerja.
5. Anda menetapkan kolega tepercaya ke peran Anggota ruang kerja untuk memastikan ada cadangan jika Anda tidak di tempat.
6. Anda menetapkan kolega lain ke peran Kontributor ruang kerja karena mereka akan bertanggung jawab untuk membuat konten ruang kerja, termasuk model dan laporan semantik.
7. Anda menetapkan manajer Anda ke peran Penampil ruang kerja karena mereka telah meminta akses untuk memantau kemajuan proyek. Manajer Anda ingin meninjau konten di ruang kerja sebelum menerbitkan aplikasi.
8. Anda bertanggung jawab untuk mengelola properti ruang kerja lain seperti deskripsi dan kontak. Anda juga bertanggung jawab untuk mengelola akses ruang kerja secara berkelanjutan.

Contoh sebelumnya menunjukkan cara yang efektif untuk memungkinkan unit bisnis terdesentralisasi kemampuan untuk bertindak secara independen. Ini juga menunjukkan prinsip hak istimewa paling sedikit.

Untuk konten yang diatur, atau konten penting yang dikelola lebih ketat, ini adalah praktik terbaik untuk menetapkan grup daripada akun pengguna individual ke peran ruang kerja. Dengan demikian, Anda dapat mengelola keanggotaan grup secara terpisah dari ruang kerja. Namun, saat Anda menetapkan grup ke peran, ada kemungkinan pengguna ditetapkan ke beberapa peran ruang kerja (karena pengguna termasuk dalam beberapa grup). Dalam hal ini, izin efektif mereka didasarkan pada peran tertinggi yang ditetapkan. Untuk pertimbangan selengkapnya, lihat Strategi untuk menggunakan grup.

Ketika ruang kerja dimiliki bersama oleh beberapa individu atau tim, itu dapat membuat manajemen konten menjadi rumit. Cobalah untuk menghindari skenario kepemilikan multi-tim dengan memisahkan ruang kerja. Dengan begitu, tanggung jawab jelas dan penetapan peran mudah disiapkan.

Variasi ke peran ruang kerja

Ada dua variasi untuk empat peran ruang kerja (dijelaskan sebelumnya).

• Secara default, hanya administrator dan anggota ruang kerja yang dapat membuat, menerbitkan, dan memperbarui aplikasi untuk ruang kerja. Opsi Izinkan kontributor memperbarui aplikasi untuk pengaturan ruang kerja ini adalah pengaturan tingkat ruang kerja, yang memungkinkan administrator ruang kerja mendelegasikan kemampuan untuk memperbarui aplikasi untuk ruang kerja ke kontributor. Namun, kontributor tidak dapat menerbitkan aplikasi baru atau mengubah siapa yang memiliki izin untuk mengeditnya. Pengaturan ini berguna ketika Anda ingin kontributor dapat memperbarui aplikasi (ketika ada untuk ruang kerja), namun tidak memberikan izin lain yang tersedia untuk anggota.
• Pengaturan Blokir penerbitan ulang dan nonaktifkan penyewa refresh paket hanya memungkinkan pemilik model semantik untuk menerbitkan pembaruan. Saat diaktifkan, administrator ruang kerja, anggota, dan kontributor tidak dapat menerbitkan perubahan kecuali mereka terlebih dahulu mengambil alih model semantik sebagai pemiliknya. Karena pengaturan ini berlaku untuk seluruh organisasi, aktifkan dengan ukuran perhatian karena memengaruhi semua model semantik untuk penyewa. Pastikan untuk berkomunikasi dengan pembuat model semantik Anda apa yang diharapkan karena mengubah perilaku normal peran ruang kerja.

Penting

Izin per item juga dapat dianggap sebagai penimpaan peran ruang kerja standar. Untuk informasi selengkapnya tentang izin per item, lihat artikel Melaporkan perencanaan keamanan konsumen.

Daftar periksa - Saat merencanakan peran ruang kerja, keputusan dan tindakan utama meliputi:

• Membuat matriks tanggung jawab: Memetakan siapa yang diharapkan untuk menangani setiap fungsi saat membuat, memelihara, menerbitkan, mengamankan, dan mendukung konten. Gunakan informasi ini saat merencanakan peran ruang kerja Anda.
• Tentukan strategi Anda untuk menetapkan peran ruang kerja untuk pembuat konten: Tentukan pengguna mana yang harus menjadi administrator, anggota, atau kontributor, dan dalam keadaan apa (seperti peran pekerjaan atau area subjek). Jika ada ketidakcocokan yang menyebabkan masalah keamanan, pertimbangkan kembali bagaimana ruang kerja Anda dapat diatur dengan lebih baik.
• Tentukan bagaimana grup keamanan versus individu harus digunakan untuk peran ruang kerja: Tentukan kasus dan tujuan penggunaan yang anda perlukan untuk menggunakan grup. Spesifikkan tentang kapan keamanan harus diterapkan dengan menggunakan akun pengguna versus saat grup diperlukan atau disukai.
• Berikan panduan bagi pembuat konten tentang mengelola peran ruang kerja: Menyertakan dokumentasi untuk pembuat konten tentang cara mengelola peran ruang kerja. Terbitkan informasi ini ke portal terpusat dan materi pelatihan Anda.
• Menyiapkan dan menguji penetapan peran ruang kerja: Verifikasi bahwa pembuat konten memiliki fungsionalitas yang mereka butuhkan untuk mengedit dan menerbitkan konten.

Izin pembuat aplikasi

Pembuat konten yang merupakan administrator atau anggota ruang kerja dapat membuat dan menerbitkan aplikasi Power BI.

Administrator ruang kerja juga dapat menentukan pengaturan di ruang kerja yang memungkinkan kontributor ruang kerja memperbarui aplikasi. Ini adalah variasi untuk keamanan peran ruang kerja karena memberikan kontributor satu izin lain yang biasanya tidak mereka miliki. Pengaturan ini diatur berdasarkan per ruang kerja.

Tip

Untuk informasi selengkapnya tentang mengirimkan konten kepada konsumen baca-saja, lihat artikel Melaporkan perencanaan keamanan konsumen. Artikel ini menyertakan informasi tentang izin aplikasi untuk konsumen aplikasi, termasuk audiens untuk aplikasi.

Daftar periksa - Saat merencanakan izin pembuat aplikasi, keputusan dan tindakan utama meliputi:

• Tentukan strategi Anda untuk siapa yang dapat membuat dan menerbitkan aplikasi Power BI: Mengklarifikasi siapa yang harus diizinkan untuk membuat dan menerbitkan aplikasi Power BI.
• Tentukan kapan kontributor dapat memperbarui aplikasi Power BI: Mengklarifikasi situasi saat kontributor harus diizinkan untuk memperbarui aplikasi Power BI. Perbarui pengaturan ruang kerja saat kemampuan ini diperlukan.

Izin sumber data

Saat pembuat data memulai proyek baru, izin yang diperlukan untuk mengakses sumber data eksternal adalah salah satu pertimbangan terkait keamanan pertama mereka. Mereka mungkin juga memerlukan panduan tentang hal-hal terkait sumber data lainnya, termasuk tingkat privasi, kueri database asli, dan konektor kustom.

Akses ke sumber data

Saat pembuat data membuat model semantik, aliran data, atau datamart, mereka harus mengautentikasi dengan sumber data untuk mengambil data. Biasanya, autentikasi melibatkan kredensial pengguna (akun dan kata sandi), yang bisa untuk akun layanan.

Terkadang berguna untuk membuat akun layanan tertentu untuk mengakses sumber data. Tanyakan kepada departemen TI Anda untuk panduan tentang bagaimana akun layanan harus digunakan di organisasi Anda. Saat diizinkan, penggunaan akun layanan dapat:

• Mempusatkan izin yang diperlukan untuk sumber data.
• Kurangi jumlah pengguna individual yang memerlukan izin ke sumber data.
• Hindari kegagalan refresh data saat pengguna meninggalkan organisasi.

Tip

Jika Anda memilih untuk menggunakan akun layanan, kami sarankan Anda mengontrol dengan ketat siapa yang memiliki akses ke kredensial. Putar kata sandi secara teratur (seperti setiap tiga bulan) atau ketika seseorang yang memiliki akses meninggalkan organisasi.

Saat mengakses sumber data, terapkan prinsip hak istimewa paling sedikit untuk memastikan bahwa pengguna (atau akun layanan) memiliki izin untuk hanya membaca data yang mereka butuhkan. Mereka seharusnya tidak pernah memiliki izin untuk melakukan modifikasi data. Administrator database yang membuat akun layanan ini harus menanyakan kueri dan beban kerja yang diharapkan dan mengambil langkah-langkah untuk memastikan pengoptimalan yang memadai (seperti indeks) dan sumber daya ada.

Tip

Jika sulit untuk menyediakan akses sumber data langsung ke pembuat data layanan mandiri, pertimbangkan untuk menggunakan pendekatan tidak langsung. Anda dapat membuat aliran data di layanan Power BI dan mengizinkan pembuat data layanan mandiri untuk sumber data darinya. Pendekatan ini memiliki manfaat tambahan untuk mengurangi beban kueri pada sumber data dan memberikan rekam jepret data yang konsisten. Untuk informasi selengkapnya, lihat persiapan data layanan mandiri dan skenario penggunaan persiapan data tingkat lanjut.

Kredensial (akun dan kata sandi) dapat diterapkan dengan salah satu dari dua cara.

• Power BI Desktop: Kredensial dienkripsi dan disimpan secara lokal di komputer pengguna.
• layanan Power BI: Kredensial dienkripsi dan disimpan dengan aman untuk:
  • Model semantik (saat gateway data tidak digunakan untuk menjangkau sumber data).
  • Sumber data gateway (saat gateway standar atau layanan gateway jaringan virtual digunakan untuk menjangkau sumber data).

Tip

Ketika Anda telah memasukkan kredensial untuk sumber data model semantik, layanan Power BI akan secara otomatis mengikat kredensial tersebut ke sumber data model semantik lainnya ketika ada kecocokan yang tepat dengan string koneksi dan nama database. Baik layanan Power BI maupun Power BI Desktop membuatnya terlihat seperti Anda memasukkan kredensial untuk setiap sumber data. Namun, ini dapat menerapkan kredensial yang sama ke sumber data yang cocok yang memiliki pemilik yang sama. Dalam hal itu, kredensial model semantik dilingkupkan kepada pemilik.

Kredensial dienkripsi dan disimpan secara terpisah dari model data di Power BI Desktop dan layanan Power BI. Pemisahan data ini memiliki keuntungan keamanan berikut.

• Ini memfasilitasi penggunaan kembali kredensial untuk beberapa model semantik, aliran data, dan datamart.
• Ketika seseorang menguraikan metadata model semantik, mereka tidak dapat mengekstrak kredensial.
• Di Power BI Desktop, pengguna lain tidak dapat tersambung ke sumber data asli untuk me-refresh data tanpa terlebih dahulu menerapkan kredensial.

Beberapa sumber data mendukung akses menyeluruh (SSO), yang dapat diatur saat memasukkan kredensial di layanan Power BI (untuk model semantik atau sumber data gateway). Saat Anda mengaktifkan SSO, Power BI mengirimkan kredensial pengguna yang diautentikasi ke sumber data. Opsi ini memungkinkan Power BI untuk mematuhi pengaturan keamanan yang disiapkan di sumber data, seperti keamanan tingkat baris. SSO sangat berguna ketika tabel dalam model data menggunakan mode penyimpanan DirectQuery.

Tingkat privasi

Tingkat privasi data menentukan tingkat isolasi yang menentukan tingkat bahwa satu sumber data diisolasi dari sumber data lainnya. Saat diatur dengan tepat, mereka memastikan bahwa Power Query hanya mengirimkan data yang kompatibel antar sumber. Saat Power Query dapat mengirimkan data antar sumber data, power Query dapat menghasilkan kueri yang lebih efisien yang mengurangi volume data yang dikirim ke Power BI. Ketika tidak dapat mengirimkan data antar sumber data, hal ini dapat mengakibatkan performa yang lebih lambat.

Ada tiga tingkat privasi.

• Privat: Menyertakan data sensitif atau rahasia yang harus diisolasi dari semua sumber data lainnya. Tingkat ini adalah yang paling ketat. Data sumber data privat tidak dapat dibagikan dengan sumber data lainnya. Misalnya, database sumber daya manusia yang berisi nilai gaji karyawan harus diatur ke tingkat privasi Privat.
• Organisasi: Terisolasi dari sumber data publik tetapi terlihat oleh sumber data organisasi lainnya. Tingkat ini adalah yang paling umum. Data sumber data organisasi dapat dibagikan dengan sumber data privat atau sumber data organisasi lainnya. Sebagian besar database operasional internal dapat diatur dengan tingkat privasi Organisasi.
• Publik: Data tidak sensitif yang dapat dibuat terlihat oleh sumber data apa pun. Tingkat ini adalah yang paling tidak ketat. Data sumber data publik dapat dibagikan dengan sumber data lainnya. Misalnya, laporan sensus yang diperoleh dari situs web pemerintah dapat diatur ke tingkat privasi Publik.

Saat menggabungkan kueri dari sumber data yang berbeda, penting agar Anda mengatur tingkat privasi yang benar. Saat tingkat privasi diatur dengan benar, ada potensi data dari satu sumber data dikirimkan ke sumber data lain untuk mengkueri data secara efisien.

Pertimbangkan skenario di mana pembuat model semantik memiliki dua sumber data: buku kerja Excel dan tabel di Azure SQL Database. Mereka ingin memfilter data dalam tabel Azure SQL Database dengan menggunakan nilai yang bersumber dari buku kerja Excel. Cara paling efisien bagi Power Query untuk menghasilkan pernyataan SQL untuk Azure SQL Database adalah dengan menerapkan klausa WHERE untuk melakukan pemfilteran yang diperlukan. Namun, Pernyataan SQL tersebut akan berisi predikat klausa WHERE dengan nilai yang bersumber dari buku kerja Excel. Jika buku kerja Excel berisi data sensitif, buku kerja tersebut dapat mewakili pelanggaran keamanan karena administrator database dapat menampilkan pernyataan SQL dengan menggunakan alat pelacakan. Meskipun kurang efisien, alternatifnya adalah agar mesin mashup Power Query mengunduh seluruh kumpulan hasil tabel database dan melakukan pemfilteran itu sendiri di layanan Power BI. Pendekatan ini akan kurang efisien dan lambat, tetapi aman.

Tingkat privasi dapat diatur untuk setiap sumber data:

• Menurut pemodel data di Power BI Desktop.
• Menurut pemilik model semantik di layanan Power BI (untuk sumber data cloud, yang tidak memerlukan gateway).
• Menurut pembuat dan pemilik sumber data gateway di layanan Power BI (untuk sumber data gateway).

Penting

Tingkat privasi yang Anda tetapkan di Power BI Desktop tidak ditransfer ke layanan Power BI.

Ada opsi keamanan Power BI Desktop yang memungkinkan mengabaikan tingkat privasi untuk meningkatkan performa. Anda mungkin menggunakan opsi ini untuk meningkatkan performa kueri saat mengembangkan model data saat tidak ada risiko melanggar keamanan data (karena Anda bekerja dengan data pengembangan atau pengujian yang tidak sensitif). Namun, pengaturan ini tidak dihormati oleh layanan Power BI.

Untuk informasi selengkapnya, lihat Tingkat privasi Power BI Desktop.

Kueri database asli

Untuk membuat kueri Power Query yang efisien, Anda bisa menggunakan kueri asli untuk mengakses data. Kueri asli adalah pernyataan yang ditulis dalam bahasa yang didukung oleh sumber data. Kueri asli hanya didukung oleh sumber data tertentu, yang biasanya merupakan database relasional seperti Azure SQL Database.

Kueri asli dapat menimbulkan risiko keamanan karena dapat menjalankan pernyataan SQL berbahaya. Pernyataan berbahaya dapat melakukan modifikasi data atau menghapus rekaman database (ketika pengguna memiliki izin yang diperlukan di sumber data). Untuk alasan ini, secara default, kueri asli memerlukan persetujuan pengguna untuk dijalankan di Power BI Desktop.

Ada opsi keamanan Power BI Desktop yang memungkinkan Anda menonaktifkan persyaratan untuk pra-persetujuan. Kami menyarankan agar Anda meninggalkan pengaturan default yang memerlukan persetujuan pengguna, terutama saat Anda mengantisipasi bahwa file Power BI Desktop dapat di-refresh oleh pengguna lain.

Konektor kustom

Pengembang dapat menggunakan Power Query SDK untuk membuat konektor kustom. Konektor kustom memungkinkan akses ke sumber data kepemilikan atau menerapkan autentikasi tertentu dengan ekstensi data kustom. Beberapa konektor kustom disertifikasi dan didistribusikan oleh Microsoft sebagai konektor bersertifikat. Konektor bersertifikat telah diaudit dan ditinjau untuk memastikan bahwa konektor tersebut memenuhi persyaratan kode tertentu yang telah diuji dan disetujui Microsoft.

Ada opsi keamanan ekstensi data Power BI Desktop yang membatasi penggunaan konektor yang tidak bersertifikat. Secara default, kesalahan muncul ketika upaya dilakukan untuk memuat konektor yang tidak bersertifikat. Dengan mengatur opsi ini untuk mengizinkan konektor yang tidak bersertifikat, konektor kustom akan dimuat tanpa validasi atau peringatan.

Sebaiknya Pertahankan tingkat keamanan ekstensi data Anda di tingkat yang lebih tinggi, yang mencegah pemuatan kode yang tidak bersertifikat. Namun, mungkin ada kasus di mana Anda ingin memuat konektor tertentu, mungkin konektor yang telah Anda kembangkan, atau konektor yang diberikan kepada Anda oleh konsultan atau vendor tepercaya di luar jalur sertifikasi Microsoft.

Catatan

Pengembang konektor yang dikembangkan secara internal dapat mengambil langkah-langkah untuk menandatangani konektor dengan sertifikat, memungkinkan Anda menggunakan konektor tanpa perlu mengubah pengaturan keamanan Anda. Untuk informasi selengkapnya, lihat Konektor pihak ketiga tepercaya.

Daftar periksa - Saat merencanakan izin sumber data, keputusan dan tindakan utama meliputi:

• Tentukan siapa yang dapat langsung mengakses setiap sumber data: Tentukan pembuat data mana yang diizinkan untuk mengakses sumber data secara langsung. Jika ada strategi untuk mengurangi jumlah orang dengan akses langsung, klarifikasi apa alternatif yang disukai (mungkin dengan menggunakan aliran data).
• Tentukan bagaimana sumber data harus diakses: Tentukan apakah info masuk pengguna individual akan digunakan untuk mengakses sumber data, atau apakah akun layanan harus dibuat untuk tujuan tersebut. Tentukan kapan akses menyeluruh sesuai.
• Berikan panduan bagi pembuat model semantik tentang mengakses sumber data: Sertakan dokumentasi untuk pembuat konten tentang cara mengakses sumber data organisasi. Terbitkan informasi ke portal terpusat dan materi pelatihan Anda.
• Berikan panduan bagi pembuat model semantik tentang tingkat privasi: Berikan panduan kepada pembuat model semantik untuk menyadarkan mereka tentang tingkat privasi, dan implikasinya saat bekerja dengan data sensitif atau rahasia. Terbitkan informasi ini ke portal terpusat dan materi pelatihan Anda.
• Berikan panduan bagi pembuat koneksi gateway tentang tingkat privasi: Berikan panduan kepada pembuat model semantik untuk membuat mereka mengetahui tingkat privasi dan implikasinya saat bekerja dengan data sensitif atau rahasia. Terbitkan informasi ini ke portal terpusat dan materi pelatihan Anda.
• Tentukan strategi untuk menggunakan kueri database asli: Pertimbangkan strategi Anda untuk menggunakan kueri database asli. Mendidik pembuat model semantik tentang cara dan waktu mengatur opsi kueri database asli Power BI Desktop untuk menonaktifkan pra-persetujuan saat Power Query menjalankan kueri asli.
• Tentukan strategi untuk menggunakan konektor kustom: Pertimbangkan strategi Anda untuk menggunakan konektor kustom. Tentukan apakah penggunaan konektor yang tidak bersertifikat dibenarkan, dalam hal ini mendidik pembuat model semantik tentang bagaimana dan kapan mengatur opsi ekstensi data Power BI Desktop.

Izin pembuat model semantik

Anda dapat menetapkan izin untuk mengedit model semantik ke pengguna atau grup dengan cara yang berbeda.

• Peran ruang kerja: Penetapan ke salah satu peran ruang kerja menyediakan akses ke semua model semantik di ruang kerja. Kemampuan untuk melihat atau mengedit model semantik yang ada tergantung pada peran ruang kerja yang Anda tetapkan. Administrator, anggota, dan kontributor dapat menerbitkan atau mengedit konten dalam ruang kerja.
• Tautan izin per item: Jika tautan berbagi dibuat untuk laporan, izin untuk membaca model semantik (dan secara opsional, membangun, menulis, dan/atau membentuk ulang) juga secara tidak langsung diberikan oleh tautan.
• Izin akses langsung per item: Anda dapat menetapkan izin akses langsung ke model semantik tertentu.

Dalam cuplikan layar berikut, perhatikan izin yang ditetapkan ke model semantik Data Pusat Panggilan. Satu pengguna memiliki izin Baca, yang diberikan dengan menggunakan izin akses langsung per item. Pengguna dan grup yang tersisa memiliki izin karena mereka ditetapkan ke peran ruang kerja.

Tip

Menggunakan izin per item (tautan atau akses langsung) berfungsi paling baik ketika niatnya adalah agar pengguna atau grup melihat atau mengedit satu item tertentu di ruang kerja. Ini paling cocok ketika pengguna tidak diizinkan untuk mengakses semua item di ruang kerja. Dalam kebanyakan kasus, kami sarankan Anda merancang ruang kerja Anda sehingga keamanan lebih mudah dikelola dengan peran ruang kerja. Hindari mengatur izin per item jika memungkinkan.

Izin model semantik

Anda dapat menetapkan izin model semantik berikut.

• Baca: Ditargetkan terutama pada konsumen laporan, izin ini memungkinkan laporan untuk mengkueri data dalam model semantik. Untuk informasi selengkapnya tentang izin untuk menampilkan konten baca-saja, lihat artikel Melaporkan perencanaan keamanan konsumen.
• Build: Ditargetkan pada pembuat laporan, izin ini memungkinkan pengguna untuk membuat laporan baru berdasarkan model semantik bersama. Untuk informasi selengkapnya, lihat bagian Izin pembuat laporan nanti di artikel ini.
• Tulis: Ditargetkan pada pembuat model semantik yang membuat, menerbitkan, dan mengelola model semantik, izin ini memungkinkan pengguna untuk mengedit model semantik. Ini dijelaskan nanti di bagian ini.
• Reshare: Ditargetkan kepada siapa pun dengan izin yang ada ke model semantik, izin ini memungkinkan pengguna untuk berbagi model semantik dengan pengguna lain. Ini dijelaskan nanti di bagian ini.

Administrator atau anggota ruang kerja dapat mengedit izin untuk model semantik.

Izin Baca model semantik

Izin Baca model semantik terutama ditargetkan pada konsumen. Izin ini diperlukan agar pengguna dapat melihat data yang ditampilkan dalam laporan. Ketahuilah bahwa laporan berdasarkan model semantik juga harus memiliki izin Baca; jika tidak, laporan akan gagal dimuat. Untuk informasi selengkapnya tentang mengatur laporan Izin baca, lihat artikel Melaporkan perencanaan keamanan konsumen.

Izin Build model semantik

Selain izin Baca model semantik, pembuat konten juga memerlukan izin Build model semantik. Secara khusus, izin Build memungkinkan pembuat laporan untuk:

• Buat laporan Power BI baru berdasarkan model semantik.
• Koneksi ke model semantik dengan menggunakan Analisis di Excel.
• Kueri model semantik dengan menggunakan titik akhir XMLA.
• Ekspor data yang mendasar visual laporan Power BI (alih-alih data ringkasan yang diambil oleh visual).
• Buat koneksi DirectQuery ke model semantik Power BI. Dalam hal ini, model semantik baru tersambung ke satu atau beberapa model semantik Power BI yang sudah ada (dikenal sebagai penautan). Untuk mengkueri model semantik berantai, pembuat model semantik akan memerlukan izin Build untuk semua model semantik upstream. Untuk informasi selengkapnya, lihat Model semantik berantai nanti di artikel ini.

Anda dapat memberikan izin Build kepada pengguna atau grup, secara langsung atau tidak langsung, dengan cara yang berbeda.

• Berikan Build secara langsung dengan:
  • Mengatur izin model semantik pada halaman pengaturan model semantik di layanan Power BI.
  • Mengatur izin model semantik dengan menggunakan Power BI REST API.
• Berikan Build secara tidak langsung dengan:
  • Berbagi laporan atau dasbor dan mengatur opsi untuk memberikan izin Build model semantik.
  • Menerbitkan aplikasi Power BI dan mengatur opsi tingkat lanjut (untuk audiens) untuk memberikan izin Build pada model semantik terkait.
  • Menetapkan pengguna ke peran ruang kerja Admin, Anggota, atau Kontributor.

Mengatur izin Build secara langsung untuk model semantik sesuai saat Anda ingin mengelola keamanan secara terperinci per item. Mengatur izin Build secara tidak langsung sesuai ketika pengguna yang akan melihat atau menggunakan konten melalui salah satu metode tidak langsung juga akan membuat konten baru.

Tip

Sering kali, pengguna yang melihat laporan atau aplikasi Power BI berbeda dari pengguna yang membuat konten baru dengan menggunakan model semantik yang mendasar. Sebagian besar konsumen hanya pemirsa, sehingga mereka tidak perlu membuat konten baru. Sebaiknya Anda mendidik pembuat konten untuk memberikan jumlah izin paling sedikit yang diperlukan.

Izin Tulis model semantik

Biasanya, mengatur izin untuk siapa yang dapat mengedit dan mengelola model semantik akan dilakukan dengan menetapkan pengguna ke peran ruang kerja Admin, Anggota, atau Kontributor. Namun, dimungkinkan juga untuk mengatur izin Tulis untuk model semantik tertentu.

Kami menyarankan agar Anda menggunakan peran ruang kerja jika memungkinkan karena ini adalah cara paling sederhana untuk mengelola dan mengaudit izin. Gunakan izin Tulis model semantik berdasarkan per item saat Anda memilih untuk membuat lebih sedikit ruang kerja, dan ruang kerja berisi model semantik untuk area subjek berbeda yang memerlukan manajemen izin yang berbeda.

Tip

Untuk panduan tentang cara mengatur ruang kerja, lihat artikel perencanaan ruang kerja.

Izin Reshare model semantik

Izin Reshare model semantik memungkinkan pengguna dengan izin yang ada untuk berbagi model semantik dengan pengguna lain. Anda dapat memberikan izin ini ketika konten dalam model semantik dapat dibagikan secara bebas, berdasarkan kebijaksanaan pengguna.

Dalam banyak kasus, sebaiknya batasi penggunaan izin Reshare untuk memastikan bahwa izin model semantik dikontrol dengan hati-hati. Dapatkan persetujuan dari pemilik model semantik sebelum memberikan izin Reshare.

Keamanan data model semantik

Anda dapat merencanakan untuk membuat lebih sedikit model dan laporan semantik dengan memberlakukan keamanan data. Tujuannya adalah untuk memberlakukan keamanan data berdasarkan identitas pengguna yang melihat konten.

Pembuat model semantik dapat memberlakukan keamanan data dengan dua cara.

• Keamanan tingkat baris (RLS) memungkinkan pemodel data membatasi akses ke subset data.
• Keamanan tingkat objek (OLS) memungkinkan pemodel data membatasi akses ke tabel dan kolom tertentu, dan metadatanya.

Implementasi RLS dan OLS ditargetkan untuk konsumen laporan. Untuk informasi selengkapnya, lihat artikel Melaporkan perencanaan keamanan konsumen. Ini menjelaskan bagaimana dan kapan RLS dan OLS diberlakukan untuk konsumen yang memiliki izin lihat-saja ke model semantik.

Untuk RLS dan OLS yang ditargetkan pada pembuat laporan lain, lihat keamanan data di bagian Izin pembuat laporan nanti di artikel ini.

Model semantik berantai

Model semantik Power BI dapat tersambung ke model semantik lain dalam proses yang dikenal sebagai penautan, yang merupakan koneksi ke model semantik upstream. Untuk informasi selengkapnya, lihat Menggunakan DirectQuery untuk model semantik Power BI dan Analysis Services.

Pengaturan Penyewa Izinkan koneksi DirectQuery ke model semantik Power BI memungkinkan administrator Power BI menyiapkan grup pembuat konten mana yang dapat membuat model semantik berantai. Jika Anda tidak ingin membatasi pembuat model semantik dari penautan model semantik, Anda dapat membiarkan pengaturan ini diaktifkan untuk seluruh organisasi dan mengandalkan akses ruang kerja dan izin model semantik. Dalam beberapa kasus, Anda mungkin mempertimbangkan untuk membatasi kemampuan ini untuk pembuat konten yang disetujui.

Catatan

Sebagai pembuat model semantik, Anda dapat membatasi penautan ke model semantik Anda. Ini dilakukan dengan mengaktifkan opsi Diskourage DirectQuery ke model semantik ini di Power BI Desktop. Untuk informasi selengkapnya, lihat Mengelola koneksi DirectQuery ke model semantik yang diterbitkan.

Kueri API model semantik

Dalam beberapa situasi, Anda mungkin ingin menjalankan kueri DAX dengan menggunakan Power BI REST API. Misalnya, Anda mungkin ingin melakukan validasi kualitas data. Untuk informasi selengkapnya, lihat Himpunan Data - Jalankan Kueri.

Pengaturan Penyewa REST API Eksekusi Kueri Himpunan Data memungkinkan administrator Power BI untuk mengatur grup pengguna mana yang dapat mengirim kueri DAX dengan menggunakan Power BI REST API. Dalam kebanyakan kasus, Anda dapat membiarkan pengaturan ini diaktifkan untuk seluruh organisasi dan mengandalkan akses ruang kerja dan izin model semantik. Dalam beberapa kasus, Anda mungkin mempertimbangkan untuk membatasi kemampuan ini untuk pembuat konten yang disetujui.

Daftar periksa - Saat merencanakan izin pembuat model semantik, keputusan dan tindakan utama meliputi:

• Tentukan strategi untuk izin pembuat model semantik: Tentukan preferensi dan persyaratan apa yang ada untuk mengelola keamanan bagi pembuat model semantik. Pertimbangkan area subjek dan tingkat sensitivitas data. Pertimbangkan juga siapa yang diizinkan untuk bertanggung jawab untuk mengelola data dan izin di unit bisnis terpusat dan terdesentralisasi.
• Tinjau bagaimana peran ruang kerja ditangani untuk pembuat model semantik: Tentukan apa dampaknya pada proses desain ruang kerja Anda. Buat ruang kerja data terpisah untuk setiap area subjek sehingga Anda dapat dengan lebih mudah mengelola peran ruang kerja dan keamanan model semantik untuk setiap area subjek.
• Berikan panduan bagi pembuat model semantik tentang mengelola izin: Sertakan dokumentasi untuk pembuat model semantik tentang cara mengelola izin model semantik. Terbitkan informasi ini ke portal terpusat dan materi pelatihan Anda.
• Memutuskan siapa yang bisa menggunakan koneksi DirectQuery untuk model semantik Power BI: Memutuskan apakah harus ada batasan pembuat model semantik Power BI (dengan izin Build yang ada untuk model semantik) dapat membuat koneksi ke model semantik Power BI. Atur pengaturan Izinkan koneksi DirectQuery ke penyewa model semantik Power BI agar selaras dengan keputusan ini. Jika Anda memutuskan untuk membatasi kemampuan ini, pertimbangkan untuk menggunakan grup seperti pembuat model semantik yang disetujui Power BI.
• Memutuskan siapa yang bisa mengkueri model semantik Power BI dengan menggunakan REST API: Memutuskan apakah akan membatasi pembuat konten Power BI agar tidak mengkueri model semantik Power BI dengan menggunakan Rest API Power BI. Atur pengaturan Penyewa REST API Kueri Eksekusi Himpunan Data agar selaras dengan keputusan ini. Jika Anda memutuskan untuk membatasi kemampuan ini, pertimbangkan untuk menggunakan grup seperti pembuat laporan yang disetujui Power BI.
• Tentukan strategi penggunaan RLS atau OLS untuk pembuat model semantik: Pertimbangkan kasus penggunaan dan tujuan mana yang ingin Anda gunakan RLS atau OLS. Faktor dalam strategi desain ruang kerja, dan siapa yang memiliki izin baca versus edit, ketika Anda ingin memberlakukan RLS atau OLS untuk pembuat model semantik.

Izin pembuat laporan

Pembuat laporan memerlukan akses ruang kerja untuk membuat laporan di layanan Power BI atau menerbitkannya dari Power BI Desktop. Mereka harus menjadi administrator, anggota, atau kontributor di ruang kerja target.

Jika memungkinkan, pembuat laporan harus menggunakan model semantik bersama yang ada (melalui koneksi langsung atau DirectQuery). Dengan begitu, proses pembuatan laporan dipisahkan dari proses pembuatan model semantik. Pemisahan jenis ini memberikan banyak manfaat untuk skenario pengembangan keamanan dan tim.

Pembuat laporan harus menjadi administrator, anggota, atau kontributor ruang kerja.

Tidak seperti model semantik, tidak ada izin Tulis untuk laporan. Untuk mendukung pembuat laporan, peran ruang kerja harus digunakan. Untuk alasan ini, desain ruang kerja yang optimal penting untuk menyeimbangkan organisasi konten dan kebutuhan keamanan.

Tip

Untuk izin untuk mendukung konsumen laporan (termasuk izin Baca dan Reshare per item), lihat artikel Melaporkan perencanaan keamanan konsumen.

Izin Baca dan Bangun untuk model semantik yang mendasar

Pembuat laporan harus memiliki izin Baca dan Bangun pada model semantik yang akan digunakan laporan mereka, yang mencakup model semantik berantai. Izin tersebut dapat diberikan secara eksplisit pada model semantik individu, atau dapat diberikan secara implisit untuk model semantik ruang kerja ketika pembuat laporan adalah administrator, anggota, atau kontributor ruang kerja.

Pengaturan Gunakan model semantik di seluruh ruang kerja penyewa memungkinkan administrator Power BI menyiapkan grup pengguna mana yang dapat membuat laporan yang menggunakan model semantik yang terletak di ruang kerja lain. Pengaturan ini ditargetkan pada model semantik dan pembuat laporan. Biasanya, kami sarankan Anda membiarkan pengaturan ini diaktifkan untuk seluruh organisasi dan mengandalkan pengaturan akses ruang kerja dan izin model semantik. Dengan begitu, Anda dapat mendorong penggunaan model semantik yang ada. Dalam beberapa kasus, Anda mungkin mempertimbangkan untuk membatasi kemampuan ini hanya untuk pembuat konten yang disetujui.

Ada juga pengaturan Izinkan penyewa koneksi langsung, yang memungkinkan administrator Power BI menyiapkan grup pengguna mana yang bisa membuat koneksi langsung ke model semantik di Power BI Desktop atau Excel. Ini ditargetkan secara khusus pada pembuat laporan, dan juga mengharuskan mereka diberikan izin Baca dan Bangun pada model semantik yang akan digunakan laporan. Kami menyarankan agar Anda membiarkan pengaturan ini diaktifkan untuk seluruh organisasi dan mengandalkan akses ruang kerja dan izin model semantik. Dengan begitu, Anda dapat mendorong penggunaan model semantik yang ada. Dalam beberapa kasus, Anda mungkin mempertimbangkan untuk membatasi kemampuan ini hanya untuk pembuat konten yang disetujui.

Keamanan data untuk model semantik yang mendasar

RLS dan OLS (dijelaskan sebelumnya dalam artikel ini) ditargetkan untuk konsumen laporan. Namun, terkadang juga perlu diberlakukan untuk pembuat laporan. Membuat ruang kerja terpisah dibenarkan ketika RLS perlu diberlakukan untuk pembuat laporan dan juga melaporkan konsumen.

Pertimbangkan skenario berikut.

• Model semantik bersama terpusat dengan RLS: Tim BI perusahaan menerbitkan model semantik penjualan ke ruang kerja Data Penjualan. Model semantik ini memberlakukan RLS untuk menampilkan data penjualan untuk wilayah penjualan yang ditetapkan dari konsumen laporan.
• Pembuat laporan layanan mandiri terdesentralisasi: Unit bisnis penjualan dan pemasaran memiliki banyak analis berkemampuan yang membuat laporan mereka sendiri. Mereka menerbitkan laporan mereka ke ruang kerja Sales Analytics .
• Izin Baca dan Bangun untuk model semantik: Jika memungkinkan, analis menggunakan model semantik dari ruang kerja Data Penjualan untuk menghindari duplikasi data yang tidak perlu. Karena analis hanya memiliki izin Baca dan Bangun pada model semantik ini (tanpa izin tulis atau edit), RLS diberlakukan untuk pembuat laporan (dan juga konsumen laporan).
• Edit izin untuk melaporkan ruang kerja: Analis memiliki lebih banyak hak di ruang kerja Sales Analytics . Peran administrator, anggota, atau ruang kerja kontributor memungkinkan mereka menerbitkan dan mengelola laporan mereka.

Untuk informasi selengkapnya tentang RLS dan OLS, lihat artikel Melaporkan perencanaan keamanan konsumen. Ini menjelaskan bagaimana dan kapan RLS dan OLS diberlakukan untuk konsumen yang memiliki izin lihat-saja ke model semantik.

Koneksi ke model semantik eksternal

Saat pembuat laporan tersambung ke model semantik bersama untuk laporan mereka, mereka biasanya tersambung ke model semantik bersama yang telah diterbitkan di penyewa Power BI mereka sendiri. Ketika izin telah diberikan, dimungkinkan juga untuk terhubung ke model semantik bersama di penyewa lain. Penyewa lain bisa menjadi mitra, pelanggan, atau vendor.

Fungsionalitas ini dikenal sebagai berbagi model semantik di tempat (juga dikenal sebagai berbagi model semantik lintas penyewa). Laporan yang dibuat oleh pembuat laporan (atau model komposit baru yang dibuat oleh pembuat model semantik) disimpan dan diamankan di penyewa Power BI Anda dengan menggunakan proses normal Anda. Model semantik bersama asli tetap berada di penyewa Power BI aslinya, dan semua izin dikelola di sana.

Untuk informasi selengkapnya, lihat artikel Perencanaan keamanan tingkat penyewa. Ini termasuk informasi tentang pengaturan penyewa dan pengaturan model semantik yang membuat berbagi eksternal berfungsi.

Tabel unggulan

Di Power BI Desktop, pembuat model semantik dapat mengatur tabel model untuk menjadi tabel unggulan. Saat model semantik diterbitkan ke layanan Power BI, pembuat laporan bisa menggunakan Galeri Tipe Data di Excel untuk menemukan tabel unggulan, memungkinkan mereka menambahkan data tabel unggulan untuk menambah lembar kerja Excel mereka.

Pengaturan Izinkan koneksi ke penyewa tabel unggulan memungkinkan administrator Power BI menyiapkan grup pengguna mana yang bisa mengakses tabel unggulan. Ini ditargetkan pada pengguna Excel yang ingin mengakses tabel unggulan Power BI di tipe data organisasi Excel. Kami menyarankan agar Anda membiarkan pengaturan ini diaktifkan untuk seluruh organisasi dan mengandalkan akses ruang kerja dan izin model semantik. Dengan demikian, Anda dapat mendorong penggunaan tabel unggulan.

Izin visual kustom

Selain visual inti, pembuat laporan Power BI bisa menggunakan visual kustom. Di Power BI Desktop, visual kustom dapat diunduh dari Microsoft AppSource. Mereka juga dapat dikembangkan secara internal dengan menggunakan Power BI SDK, dan diinstal dengan membuka file visual (.pbviz).

Beberapa visual yang tersedia untuk diunduh dari AppSource adalah visual bersertifikat. Visual bersertifikat memenuhi persyaratan kode tertentu yang telah diuji dan disetujui oleh tim Power BI. Pengujian memeriksa bahwa visual tidak mengakses layanan atau sumber daya eksternal.

Pengaturan Izinkan visual yang dibuat oleh penyewa Power BI SDK memungkinkan administrator Power BI mengontrol grup pengguna mana yang bisa menggunakan visual kustom.

Ada juga pengaturan Tambahkan dan gunakan penyewa hanya visual bersertifikat, yang memungkinkan administrator Power BI memblokir penggunaan visual yang tidak bersertifikat di layanan Power BI. Pengaturan ini dapat diaktifkan atau dinonaktifkan untuk seluruh organisasi.

Catatan

Jika Anda memblokir penggunaan visual yang tidak bersertifikat, itu hanya berlaku untuk layanan Power BI. Jika Anda ingin membatasi penggunaannya di Power BI Desktop, minta administrator sistem Anda untuk menggunakan pengaturan kebijakan grup untuk memblokir penggunaannya di Power BI Desktop. Mengambil langkah ini akan memastikan bahwa pembuat laporan tidak membuang waktu dan upaya membuat laporan yang tidak akan berfungsi saat diterbitkan ke layanan Power BI. Kami sangat menyarankan Agar Anda menyiapkan pengguna agar memiliki pengalaman yang konsisten di layanan Power BI (dengan pengaturan penyewa) dan Power BI Desktop (dengan kebijakan grup).

Power BI Desktop memiliki opsi untuk menampilkan peringatan keamanan saat pembuat laporan menambahkan visual kustom ke laporan. Pembuat laporan dapat menonaktifkan opsi ini. Opsi ini tidak menguji apakah visual bersertifikat.

Administrator Power BI dapat menyetujui dan menyebarkan visual kustom untuk organisasi mereka. Pembuat laporan kemudian dapat dengan mudah menemukan, memperbarui, dan menggunakan visual ini. Administrator kemudian dapat mengelola visual ini dengan memperbarui versi atau menonaktifkan dan mengaktifkan visual kustom tertentu. Pendekatan ini berguna ketika Anda ingin membuat visual yang dikembangkan secara internal tersedia untuk pembuat laporan Anda, atau saat Anda memperoleh visual kustom dari vendor yang tidak ada di AppSource. Untuk informasi selengkapnya, lihat Visual organisasi Power BI.

Pertimbangkan strategi seimbang untuk mengaktifkan hanya visual kustom bersertifikat di organisasi Anda (dengan pengaturan penyewa dan kebijakan grup yang dijelaskan sebelumnya), sambil menyebarkan visual organisasi untuk menangani pengecualian apa pun.

Daftar periksa - Saat merencanakan izin pembuat laporan, keputusan dan tindakan utama meliputi:

• Tentukan strategi untuk izin pembuat laporan: Tentukan preferensi dan persyaratan apa yang ada untuk mengelola keamanan bagi pembuat laporan. Pertimbangkan area subjek dan tingkat sensitivitas data. Selain itu, pertimbangkan siapa yang diizinkan untuk bertanggung jawab untuk membuat dan mengelola laporan di unit bisnis terpusat dan terdesentralisasi.
• Tinjau bagaimana peran ruang kerja ditangani untuk pembuat laporan: Tentukan dampaknya pada proses desain ruang kerja Anda. Buat ruang kerja data terpisah dan ruang kerja pelaporan untuk setiap area subjek, sehingga peran ruang kerja (dan keamanan model semantik yang mendasar) disederhanakan untuk area subjek.
• Berikan panduan bagi pembuat laporan tentang mengelola izin: Sertakan dokumentasi untuk pembuat laporan tentang cara mengelola izin untuk konsumen laporan. Terbitkan informasi ini ke portal terpusat dan materi pelatihan Anda.
• Memutuskan siapa yang dapat menggunakan model semantik bersama: Memutuskan apakah harus ada batasan pembuat laporan Power BI (yang sudah memiliki izin Baca dan Bangun untuk model semantik) dapat menggunakan model semantik di seluruh ruang kerja. Atur pengaturan Gunakan model semantik di seluruh ruang kerja penyewa agar selaras dengan keputusan ini. Jika Anda memutuskan untuk membatasi kemampuan ini, pertimbangkan untuk menggunakan grup seperti pembuat laporan yang disetujui Power BI.
• Memutuskan siapa yang bisa menggunakan koneksi langsung: Memutuskan apakah harus ada batasan pembuat laporan Power BI (yang sudah memiliki izin Baca dan Bangun untuk model semantik) dapat menggunakan koneksi langsung. Atur pengaturan Izinkan penyewa koneksi langsung agar selaras dengan keputusan ini. Jika Anda memutuskan untuk membatasi kemampuan ini, pertimbangkan untuk menggunakan grup seperti pembuat laporan yang disetujui Power BI.
• Tentukan strategi penggunaan RLS untuk pembuat laporan: Pertimbangkan kasus penggunaan dan tujuan mana yang ingin Anda gunakan keamanan tingkat baris. Faktor dalam strategi desain ruang kerja untuk memastikan bahwa RLS diberlakukan untuk pembuat laporan.
• Tentukan strategi penggunaan visual kustom: Pertimbangkan strategi Anda untuk pembuat laporan mana yang dapat menggunakan visual kustom. Atur pengaturan Izinkan visual yang dibuat oleh penyewa Power BI SDK agar selaras dengan keputusan ini. Buat proses untuk menggunakan visual organisasi, jika sesuai.

Izin pembuat aliran data

Aliran data sangat membantu untuk memusatkan persiapan data sehingga pekerjaan yang dilakukan di Power Query tidak diulang di banyak model semantik. Mereka adalah blok bangunan untuk mencapai satu sumber kebenaran, mencegah analis membutuhkan akses langsung ke sumber, dan untuk membantu melakukan operasi ekstraksi, transformasi, dan pemuatan (ETL) dalam skala besar.

Pembuat aliran data harus menjadi administrator, anggota, atau kontributor ruang kerja.

Untuk menggunakan aliran data (misalnya, dari model data baru yang dibuat di Power BI Desktop atau di ruang kerja lain), pembuat model semantik dapat termasuk peran ruang kerja apa pun, termasuk peran Penampil. Tidak ada konsep RLS untuk aliran data.

Selain peran ruang kerja, pengaturan Buat dan gunakan penyewa aliran data harus diaktifkan. Pengaturan penyewa ini berlaku untuk seluruh organisasi.

Pertimbangkan skenario berikut.

• Banyak model semantik dalam organisasi perlu memberlakukan RLS dinamis. Ini mengharuskan nama prinsipal pengguna (UPN) disimpan dalam model semantik (untuk memfilter berdasarkan identitas konsumen laporan).
• Pembuat aliran data, yang termasuk dalam departemen Sumber Daya Manusia, membuat aliran data detail karyawan saat ini termasuk UPN mereka. Mereka menyiapkan aliran data untuk di-refresh setiap hari.
• Pembuat model semantik kemudian menggunakan aliran data dalam desain model mereka untuk menyiapkan RLS.

Untuk informasi selengkapnya tentang menggunakan aliran data, lihat persiapan data layanan mandiri dan skenario penggunaan persiapan data tingkat lanjut.

Daftar periksa - Saat merencanakan izin pembuat aliran data, keputusan dan tindakan utama meliputi:

• Tentukan strategi untuk izin pembuat aliran data: Tentukan preferensi dan persyaratan apa yang ada untuk mengelola keamanan bagi pembuat aliran data. Pertimbangkan siapa yang diizinkan, atau didorong, untuk bertanggung jawab dalam mengelola aktivitas persiapan data di unit bisnis terpusat dan terdesentralisasi.
• Memutuskan siapa yang bisa membuat aliran data: Tentukan apakah harus ada batasan yang dapat dibuat oleh pembuat data Power BI untuk membuat aliran data. Atur pengaturan Buat dan gunakan penyewa aliran data agar selaras dengan keputusan ini.
• Tinjau bagaimana peran ruang kerja ditangani untuk pembuat aliran data: Tentukan apa dampaknya pada proses desain ruang kerja Anda. Buat ruang kerja aliran data terpisah per area subjek sehingga Anda dapat menangani peran dan izin ruang kerja secara terpisah untuk setiap area subjek, jika sesuai.

Izin pembuat Datamart

Datamart adalah solusi analitik layanan mandiri yang memungkinkan pengguna untuk menyimpan dan menjelajahi data yang dimuat dalam database relasional yang dikelola sepenuhnya. Ini juga terdiri dari model semantik yang dihasilkan secara otomatis.

Datamarts memberikan pengalaman kode rendah sederhana untuk menyerap data dari sumber data yang berbeda, dan untuk mengekstrak, mengubah, dan memuat (ETL) data dengan menggunakan Power Query Online. Data dimuat ke dalam Azure SQL Database yang dikelola sepenuhnya dan tidak memerlukan penyetelan atau pengoptimalan. Model semantik yang dihasilkan secara otomatis selalu disinkronkan dengan database terkelola karena berada dalam mode DirectQuery.

Anda dapat membuat datamart saat Anda adalah administrator, anggota, atau kontributor ruang kerja. Peran ruang kerja juga dipetakan ke peran tingkat database di Azure SQL Database (namun, karena database dikelola sepenuhnya, izin pengguna tidak dapat diedit atau dikelola dalam database relasional).

Pengaturan Buat penyewa datamarts memungkinkan administrator Power BI menyiapkan grup pengguna mana yang dapat membuat datamart.

Berbagi Datamart

Untuk datamart, istilah berbagi memiliki arti yang berbeda dengan tipe konten Power BI lainnya. Biasanya, operasi berbagi ditargetkan pada konsumen karena menyediakan izin baca-saja untuk satu item, seperti laporan.

Berbagi datamart ditargetkan untuk pembuat konten (bukan konsumen). Ini memberikan izin Baca dan Bangun, yang memungkinkan pengguna untuk mengkueri model semantik atau database relasional, mana pun yang mereka sukai.

Berbagi datamart memungkinkan pembuat konten untuk:

• Buat konten dengan menggunakan model semantik yang dihasilkan secara otomatis: Model semantik adalah lapisan semantik tempat laporan Power BI dapat dibuat. Sebagian besar pembuat laporan harus menggunakan model semantik.
• Koneksi ke dan kueri Azure SQL Database: Database relasional berguna untuk pembuat konten yang ingin membuat model semantik baru atau laporan paginated. Mereka dapat menulis kueri bahasa kueri terstruktur (SQL) untuk mengambil data dengan menggunakan titik akhir SQL.

Keamanan tingkat baris Datamart

Anda dapat menentukan RLS untuk datamart untuk membatasi akses data bagi pengguna tertentu. RLS disiapkan di editor datamart di layanan Power BI, dan secara otomatis diterapkan ke model semantik yang dihasilkan secara otomatis dan Azure SQL Database (sebagai aturan keamanan).

Terlepas dari bagaimana pengguna memilih untuk menyambungkan ke datamart (ke model semantik atau database), izin RLS yang identik diberlakukan.

Daftar periksa - Saat merencanakan izin pembuat datamart, keputusan dan tindakan utama meliputi:

• Tentukan strategi untuk izin pembuat datamart: Tentukan preferensi dan persyaratan apa yang ada untuk mengelola keamanan bagi pembuat datamart. Pertimbangkan siapa yang diizinkan, atau didorong, untuk bertanggung jawab mengelola data di unit bisnis terpusat dan terdesentralisasi.
• Memutuskan siapa yang bisa membuat datamart: Tentukan apakah harus ada batasan pembuat data Power BI yang dapat membuat datamart. Atur pengaturan Buat penyewa datamart agar selaras dengan keputusan ini. Jika Anda memutuskan untuk membatasi siapa yang bisa membuat datamart, pertimbangkan untuk menggunakan grup seperti pembuat datamart yang disetujui Power BI.
• Tinjau bagaimana peran ruang kerja ditangani untuk pembuat datamart: Tentukan apa dampaknya pada proses desain ruang kerja Anda. Buat ruang kerja data terpisah per area subjek sehingga peran ruang kerja dan keamanan model semantik dapat disederhanakan untuk area subjek.
• Berikan panduan bagi pembuat datamart tentang mengelola izin: Sertakan dokumentasi untuk pembuat datamart tentang cara mengelola izin datamart. Terbitkan informasi ini ke portal terpusat dan materi pelatihan Anda.
• Tentukan strategi untuk menggunakan RLS dalam datamart: Pertimbangkan kasus dan tujuan penggunaan mana yang ingin Anda gunakan RLS dalam datamart.

Izin pembuat kartu skor

Metrik di Power BI memungkinkan Anda mengumpulkan metrik tertentu dan melacaknya terhadap tujuan bisnis utama. Metrik ditambahkan ke kartu skor, yang dapat dibagikan dengan pengguna lain dan ditampilkan dalam satu panel.

Kartu skor dapat diamankan dengan tiga tingkat izin:

• Ruang kerja.
• Izin kartu skor (per item).
• Metrik (dalam kartu skor).

Pengguna yang membuat, atau sepenuhnya mengelola, kartu skor harus menjadi administrator, anggota, atau kontributor ruang kerja.

Karena metrik sering mencakup beberapa area subjek, kami sarankan Anda membuat ruang kerja terpisah sehingga Anda dapat mengelola izin secara independen untuk pembuat dan konsumen.

Pengaturan Buat dan gunakan penyewa metrik memungkinkan administrator Power BI menyiapkan grup pengguna mana yang dapat membuat metrik kartu skor.

Izin kartu skor

Anda dapat menetapkan izin kartu skor berikut.

• Baca: Izin ini memungkinkan pengguna untuk melihat kartu skor.
• Reshare: Ditargetkan kepada siapa pun dengan izin yang ada ke kartu skor, izin ini memungkinkan pengguna untuk berbagi kartu skor dengan pengguna lain.

Konsisten dengan jenis konten lain di layanan Power BI, izin per item berguna ketika niatnya adalah berbagi satu item dengan pengguna lain. Sebaiknya gunakan peran ruang kerja dan izin aplikasi jika memungkinkan.

Izin tingkat metrik

Setiap kartu skor memiliki sekumpulan izin tingkat metrik yang dapat Anda siapkan di pengaturan kartu skor. Izin tingkat metrik (dalam kartu skor) dapat diberikan secara berbeda dari ruang kerja atau izin kartu skor (per item).

Peran tingkat metrik memungkinkan Anda mengatur:

• Siapa dapat melihat metrik individual pada kartu skor.
• Siapa dapat memperbarui metrik individual dengan:
  • Memperbarui status selama check-in.
  • Menambahkan catatan selama check-in.
  • Memperbarui nilai saat ini selama check-in.

Untuk mengurangi tingkat pemeliharaan di masa mendatang, dimungkinkan untuk mengatur izin default yang akan diwariskan oleh submetrik yang Anda buat di masa mendatang.

Daftar periksa - Saat merencanakan izin pembuat metrik, keputusan dan tindakan utama meliputi:

• Tentukan strategi untuk izin pembuat kartu skor: Tentukan preferensi dan persyaratan apa yang ada untuk mengelola keamanan bagi pembuat kartu skor. Pertimbangkan siapa yang diizinkan, atau didorong, untuk bertanggung jawab mengelola data di unit bisnis terpusat dan terdesentralisasi.
• Memutuskan siapa yang bisa membuat kartu skor: Tentukan apakah harus ada batasan yang dapat dibuat oleh pembuat data Power BI untuk membuat kartu skor. Atur pengaturan Buat dan gunakan penyewa Metrik untuk menyelaraskan dengan keputusan ini. Jika Anda memutuskan untuk membatasi siapa yang bisa membuat kartu skor, pertimbangkan untuk menggunakan grup seperti pembuat kartu skor yang disetujui Power BI.
• Tinjau bagaimana peran ruang kerja ditangani untuk pembuat kartu skor: Tentukan dampaknya pada proses desain ruang kerja Anda. Pertimbangkan untuk membuat ruang kerja terpisah untuk kartu skor saat konten mencakup area subjek.
• Berikan panduan bagi pembuat kartu skor tentang mengelola izin: Sertakan dokumentasi untuk pembuat kartu skor tentang cara mengelola izin tingkat metrik. Terbitkan informasi ini ke portal terpusat dan materi pelatihan Anda.

Menerbitkan konten

Bagian ini mencakup topik yang terkait dengan penerbitan konten yang relevan dengan pembuat konten.

Ruang kerja

Pembuat konten akan memerlukan akses peran administrator, anggota, atau kontributor untuk menerbitkan konten ke ruang kerja. Untuk informasi selengkapnya, lihat peran ruang kerja yang dijelaskan sebelumnya di artikel ini.

Kecuali BI pribadi, pembuat konten harus didorong untuk menerbitkan konten ke ruang kerja standar, bukan ruang kerja pribadi mereka.

Pengaturan Blokir penerbitan ulang dan nonaktifkan penyewa refresh paket mengubah perilaku untuk menerbitkan model semantik. Saat diaktifkan, administrator ruang kerja, anggota, atau kontributor tidak dapat menerbitkan perubahan pada model semantik. Hanya pemilik model semantik yang diizinkan untuk menerbitkan pembaruan (memaksa pengambungan model semantik sebelum menerbitkan model semantik yang diperbarui). Karena pengaturan penyewa ini berlaku untuk seluruh organisasi, aktifkan dengan ukuran perhatian karena memengaruhi semua model semantik untuk seluruh penyewa. Pastikan untuk berkomunikasi dengan pembuat model semantik Anda apa yang diharapkan karena mengubah perilaku normal peran ruang kerja.

Sinkronisasi Power Apps

Dimungkinkan untuk membuat solusi Power Apps yang menyertakan laporan Power BI yang disematkan. Proses Power Apps akan secara otomatis membuat ruang kerja Power BI khusus untuk menyimpan dan mengamankan laporan Power BI dan model semantik. Untuk mengelola item yang ada di Power Apps dan Power BI, ada proses sinkronisasi.

Proses ini menyinkronkan peran keamanan untuk memastikan bahwa Power BI mewarisi peran yang sama yang awalnya disiapkan di Power Apps. Ini juga memungkinkan pembuat konten mengelola izin untuk siapa yang bisa menampilkan laporan Power BI (dan model semantik terkait) yang disematkan di Power App.

Untuk informasi selengkapnya tentang menyinkronkan peran Power Apps dengan peran ruang kerja Power BI, lihat Sinkronisasi izin antara lingkungan Power Apps dan ruang kerja Power BI.

Akses alur penyebaran

Pembuat konten dan pemilik dapat menggunakan alur penyebaran Power BI untuk penerbitan konten layanan mandiri. Alur penyebaran menyederhanakan proses publikasi dan meningkatkan tingkat kontrol saat merilis konten baru.

Anda mengelola izin alur (untuk pengguna yang dapat menyebarkan konten dengan alur penyebaran) secara terpisah dari peran ruang kerja. Akses ke ruang kerja dan alur penyebaran diperlukan untuk pengguna yang melakukan penyebaran.

Pembuat konten mungkin juga memerlukan:

• Izin pembuatan ruang kerja (saat ruang kerja perlu dibuat oleh alur).
• Izin kapasitas Premium atau Fabric (saat ruang kerja ditetapkan oleh alur).

Penting

Terkadang artikel ini mengacu pada Power BI Premium atau langganan kapasitasnya (SKU P). Ketahuilah bahwa Microsoft saat ini mengonsolidasikan opsi pembelian dan menghentikan SKU Power BI Premium per kapasitas. Pelanggan baru dan yang sudah ada harus mempertimbangkan untuk membeli langganan kapasitas Fabric (F SKU) sebagai gantinya.

Untuk informasi selengkapnya, lihat Pembaruan penting yang masuk ke lisensi Power BI Premium dan Tanya Jawab Umum Power BI Premium.

Untuk informasi selengkapnya, lihat Akses alur penyebaran.

Titik akhir XMLA

Titik akhir XMLA menggunakan protokol XMLA untuk mengekspos semua fitur model data tabular, termasuk beberapa operasi pemodelan data yang tidak didukung oleh Power BI Desktop. Anda dapat menggunakan API Model Objek Tabular (TOM) untuk membuat perubahan terprogram pada model data.

Titik akhir XMLA juga menyediakan konektivitas. Anda hanya dapat terhubung ke model semantik ketika ruang kerja memiliki mode lisensi yang diatur ke Premium per pengguna, Premium per kapasitas, atau Tersemat. Setelah koneksi dibuat, alat yang mematuhi XMLA dapat beroperasi pada model data untuk membaca atau menulis data. Untuk informasi selengkapnya tentang cara menggunakan titik akhir XMLA untuk mengelola model semantik, lihat skenario penggunaan manajemen model data tingkat lanjut.

Akses melalui titik akhir XMLA akan mematuhi izin yang ada. Administrator, anggota, dan kontributor ruang kerja secara implisit memiliki izin Tulis model semantik, yang berarti mereka dapat menyebarkan model semantik baru dari Visual Studio dan menjalankan skrip Tabular Modeling Scripting Language (TMSL) di SQL Server Management Studio (SSMS).

Pengguna dengan izin Build model semantik dapat menggunakan titik akhir XMLA untuk menyambungkan dan menelusuri model semantik untuk konsumsi dan visualisasi data. Aturan RLS dihormati, dan pengguna tidak dapat melihat metadata model semantik internal.

Pengaturan Penyewa Izinkan titik akhir XMLA dan Analisis di Excel dengan model semantik lokal mengacu pada dua kemampuan: Ini mengontrol grup pengguna mana yang dapat menggunakan titik akhir XMLA untuk mengkueri dan/atau mempertahankan model semantik dalam layanan Power BI. Ini juga menentukan apakah Analisis di Excel dapat digunakan dengan model SQL Server Analysis Services (SSAS) lokal.

Catatan

Aspek Analisis di Excel dari pengaturan penyewa tersebut hanya berlaku untuk model SQL Server Analysis Services (SSAS) lokal. Fungsionalitas Analisis di Excel standar, yang tersambung ke model semantik Power BI di layanan Power BI, dikontrol oleh pengaturan Izinkan penyewa Izinkan Koneksi ion Langsung.

Publikasikan ke web

Terbitkan ke web adalah fitur yang menyediakan akses ke laporan Power BI kepada siapa saja di internet. Ini tidak memerlukan autentikasi dan akses tidak dicatat untuk tujuan audit. Karena konsumen laporan tidak perlu termasuk dalam organisasi atau memiliki lisensi Power BI, teknik ini sangat cocok untuk jurnalisme data, proses di mana laporan disematkan dalam posting blog, situs web, email, atau media sosial.

Perhatian

Publikasikan ke web berpotensi mengekspos data sensitif atau rahasia, baik secara tidak sengaja maupun sengaja. Untuk alasan ini, fitur ini dinonaktifkan secara default. Publikasikan ke web hanya boleh digunakan untuk laporan yang berisi data yang dapat dilihat oleh publik.

Pengaturan Terbitkan ke penyewa web memungkinkan administrator Power BI mengontrol grup pengguna mana yang bisa menerbitkan laporan ke web. Untuk mempertahankan tingkat kontrol yang lebih tinggi, kami sarankan Anda tidak menyertakan grup lain dalam pengaturan penyewa ini (seperti administrator Power BI atau jenis pembuat konten lainnya). Sebagai gantinya, berlakukan akses pengguna tertentu dengan menggunakan grup keamanan seperti penerbitan publik Power BI. Pastikan bahwa grup keamanan dikelola dengan baik.

Penyematan di aplikasi kustom

Pengaturan Sematkan konten dalam penyewa aplikasi memungkinkan administrator Power BI mengontrol pengguna mana yang bisa menyematkan konten Power BI di luar layanan Power BI. Saat Anda berencana untuk menyematkan konten Power BI dalam aplikasi kustom, aktifkan pengaturan ini untuk grup tertentu, seperti pengembang aplikasi.

Penyematan di PowerPoint

Pengaturan Aktifkan add-in Power BI untuk penyewa PowerPoint memungkinkan administrator Power BI mengontrol pengguna mana yang bisa menyematkan halaman laporan Power BI di presentasi PowerPoint. Jika sesuai, aktifkan pengaturan ini untuk grup tertentu, seperti pembuat laporan.

Catatan

Agar kemampuan ini berfungsi, pengguna harus menginstal add-in Power BI untuk PowerPoint. Untuk menggunakan add-in, pengguna harus memiliki akses ke penyimpanan add-in Office, atau add-in harus tersedia untuk mereka sebagai add-in terkelola admin. Untuk informasi selengkapnya, lihat Add-in Power BI untuk PowerPoint.

Mendidik pembuat laporan untuk berhati-hati tentang di mana mereka menyimpan presentasi PowerPoint mereka dan dengan siapa mereka membagikannya. Itu karena gambar visual laporan Power BI diperlihatkan kepada pengguna saat mereka membuka presentasi. Gambar tersebut diambil dari terakhir kali file PowerPoint tersambung. Namun, gambar tersebut secara tidak sengaja dapat mengungkapkan data yang tidak memiliki izin untuk dilihat pengguna penerima.

Catatan

Gambar dapat berguna ketika pengguna penerima belum memiliki add-in, atau sampai add-in tersambung ke layanan Power BI untuk mengambil data. Setelah pengguna tersambung, hanya data yang dapat dilihat pengguna (memberlakukan RLS apa pun) yang diambil dari Power BI.

Aplikasi templat

Aplikasi templat memungkinkan mitra Power BI dan vendor perangkat lunak untuk membangun aplikasi Power BI dengan sedikit atau tanpa pengkodean, dan menyebarkannya ke pelanggan Power BI mana pun.

Pengaturan Terbitkan penyewa aplikasi templat memungkinkan administrator Power BI mengontrol pengguna mana yang dapat menerbitkan aplikasi templat di luar organisasi, seperti melalui Microsoft AppSource. Untuk sebagian besar organisasi, pengaturan penyewa ini harus dinonaktifkan atau dikontrol dengan ketat. Pertimbangkan untuk menggunakan grup keamanan seperti pembuat aplikasi templat eksternal Power BI.

Langganan email

Anda bisa berlangganan diri Anda sendiri dan orang lain ke laporan Power BI, dasbor, dan laporan paginasi. Power BI kemudian akan mengirim email sesuai jadwal yang Anda tetapkan. Email akan berisi snapshot dan tautan ke laporan atau dasbor.

Anda dapat membuat langganan yang menyertakan pengguna lain saat Anda adalah administrator, anggota, atau kontributor ruang kerja. Jika laporan berada di ruang kerja Premium, Anda dapat berlangganan grup (baik itu di domain Anda atau tidak) dan pengguna eksternal. Saat menyiapkan langganan, ada juga opsi untuk memberikan izin ke item. Izin akses langsung per item digunakan untuk tujuan ini, yang dijelaskan dalam artikel Melaporkan perencanaan keamanan konsumen.

Perhatian

Fitur langganan email berpotensi berbagi konten ke audiens internal dan eksternal. Selain itu, ketika RLS diberlakukan pada model semantik, lampiran, dan gambar yang mendasarinya dihasilkan dengan menggunakan konteks keamanan pengguna berlangganan.

Pengaturan Penyewa langganan Email memungkinkan administrator Power BI mengontrol apakah fitur ini diaktifkan atau dinonaktifkan untuk seluruh organisasi.

Ada beberapa batasan mengenai lampiran yang terkait dengan pembatasan pengaturan lisensi dan penyewa. Untuk informasi selengkapnya, lihat Langganan email untuk laporan dan dasbor di layanan Power BI.

Daftar periksa - Saat merencanakan penerbitan konten, keputusan dan tindakan utama meliputi:

• Tentukan strategi di mana konten harus diterbitkan, bagaimana, dan oleh siapa: Tentukan preferensi dan persyaratan apa yang ada di mana konten diterbitkan.
• Memverifikasi akses ruang kerja: Konfirmasi pendekatan desain ruang kerja. Verifikasi cara menggunakan peran akses ruang kerja untuk mendukung strategi Anda di mana konten harus diterbitkan.
• Tentukan cara menangani izin alur penyebaran: Tentukan pengguna mana yang diizinkan untuk menerbitkan konten dengan menggunakan alur penyebaran. Atur izin alur penyebaran yang sesuai. Pastikan bahwa akses ruang kerja juga disediakan.
• Tentukan siapa yang dapat tersambung ke model semantik dengan menggunakan titik akhir XMLA: Tentukan pengguna mana yang diizinkan untuk mengkueri atau mengelola model semantik dengan menggunakan titik akhir XMLA. Atur pengaturan Izinkan titik akhir XMLA dan Analisis di Excel dengan penyewa model semantik lokal agar selaras dengan keputusan ini. Saat Anda memutuskan untuk membatasi kemampuan ini, pertimbangkan untuk menggunakan grup seperti pembuat konten yang disetujui Power BI.
• Memutuskan siapa yang bisa menerbitkan laporan secara publik: Tentukan pengguna mana yang diizinkan untuk menerbitkan laporan Power BI secara publik, jika ada. Atur pengaturan Terbitkan ke penyewa web agar selaras dengan keputusan ini. Gunakan grup seperti penerbitan publik Power BI.
• Tentukan siapa yang dapat menyematkan konten di aplikasi kustom: Tentukan siapa yang harus diizinkan untuk menyematkan konten di luar layanan Power BI. Atur pengaturan Sematkan konten di penyewa aplikasi agar selaras dengan keputusan ini.
• Memutuskan siapa yang bisa menyematkan konten di PowerPoint: Tentukan siapa yang harus diizinkan untuk menyematkan konten di PowerPoint. Atur pengaturan Aktifkan add-in Power BI untuk penyewa PowerPoint agar selaras dengan keputusan ini.
• Tentukan siapa yang dapat menerbitkan aplikasi templat: Tentukan strategi Anda untuk menggunakan aplikasi templat di luar organisasi. Atur pengaturan Terbitkan penyewa aplikasi templat agar selaras dengan keputusan ini.
• Memutuskan apakah akan mengaktifkan langganan: Konfirmasikan strategi Anda untuk menggunakan langganan. Atur pengaturan penyewa Langganan Email agar selaras dengan keputusan ini.

Memuat ulang data

Setelah diterbitkan, pembuat data harus memastikan bahwa model semantik dan aliran data mereka (yang berisi data yang diimpor) disegarkan secara berkala. Anda juga harus memutuskan strategi yang sesuai untuk model semantik dan pemilik aliran data.

Pemilik model semantik

Setiap model semantik memiliki pemilik, yang merupakan satu akun pengguna. Pemilik model semantik diperlukan untuk menyiapkan refresh model semantik dan mengatur parameter model semantik.

Secara default, pemilik model semantik juga menerima permintaan akses dari pembuat laporan yang menginginkan izin Build (kecuali pengaturan Minta akses untuk model semantik diatur untuk memberikan instruksi kustom). Untuk informasi selengkapnya, lihat bagian Minta alur kerja akses untuk pembuat di artikel ini.

Ada dua cara agar Power BI bisa mendapatkan kredensial untuk me-refresh model semantik.

• Pemilik model semantik menyimpan kredensial dalam pengaturan model semantik.
• Pemilik model semantik mereferensikan gateway dalam pengaturan model semantik (yang berisi sumber data dengan kredensial tersimpan).

Jika pengguna yang berbeda perlu menyiapkan refresh atau mengatur parameter model semantik, mereka harus mengambil kepemilikan model semantik. kepemilikan model semantik dapat diambil alih oleh administrator, anggota, atau kontributor ruang kerja.

Perhatian

Mengambil kepemilikan model semantik secara permanen menghapus kredensial yang disimpan untuk model semantik. Kredensial harus dimasukkan kembali untuk memungkinkan operasi refresh data dilanjutkan.

Idealnya, pemilik model semantik adalah pengguna yang bertanggung jawab atas model semantik. Anda harus memperbarui pemilik model semantik saat mereka meninggalkan organisasi atau mengubah peran. Selain itu, ketahuilah bahwa ketika akun pengguna pemilik model semantik dinonaktifkan di ID Microsoft Entra (sebelumnya dikenal sebagai Azure Active Directory), refresh data secara otomatis dinonaktifkan. Dalam hal ini, pengguna lain harus mengambil kepemilikan model semantik untuk memungkinkan operasi refresh data dilanjutkan.

Pemilik aliran data

Seperti model semantik, aliran data juga memiliki pemilik, yang merupakan satu akun pengguna. Informasi dan panduan yang diberikan dalam topik sebelumnya tentang pemilik model semantik juga berlaku untuk pemilik aliran data.

Daftar periksa - Saat merencanakan keamanan yang terkait dengan proses refresh data, keputusan dan tindakan utama meliputi:

• Tentukan strategi untuk pemilik model semantik: Tentukan preferensi dan persyaratan apa yang ada untuk mengelola pemilik model semantik.
• Tentukan strategi untuk pemilik aliran data: Tentukan preferensi dan persyaratan apa yang ada untuk mengelola pemilik aliran data.
• Sertakan dalam dokumentasi dan pelatihan untuk pembuat model semantik: Sertakan panduan untuk pembuat data Anda tentang cara mengelola pemilik untuk setiap jenis item.

Konten terkait

Untuk pertimbangan, tindakan, kriteria pengambilan keputusan, dan rekomendasi lainnya untuk membantu Anda dengan keputusan implementasi Power BI, lihat area subjek yang perlu dipertimbangkan.