Laporan resmi keamanan Power BI

Ringkasan: Power BI adalah penawaran layanan perangkat lunak online (SaaS, atau Software as a Service) dari Microsoft yang memungkinkan Anda membuat dasbor, laporan, model semantik, dan visualisasi Kecerdasan Bisnis mandiri dengan mudah dan cepat. Dengan Power BI, Anda bisa menyambungkan ke berbagai sumber data, menggabungkan dan membentuk data dari koneksi tersebut, lalu membuat laporan dan dasbor yang dapat dibagikan dengan orang lain.

Penulis: Yitzhak Kesselman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Cristian Petculescu, Adi Regev, Naveen Sivaraj, Ben Glastein, Evgeny Tshiorny, Arthi Ramasubramanian Iyer, Sid Jayadevan, Ronald Chang, Ori Eduar, Anton Fritz, Idan Sheinberg, Ron Gilad, Sagiv Hadaya, Paul Inbar, Igor Uzhviev, Michael Roth, Jaime Tarquino, Gennady Pats, Orion Lee, Yury Berezansky, Maya Shenhav, Romit Chattopadhyay, Yariv Maimon, Bogdan Crivat

Peninjau Teknis: Cristian Petculescu, Amir Netz, Sergei Gundorov

Berlaku untuk: Power BI SaaS, Power BI Desktop, Power BI Premium, Power BI Embedded Analytics, Power BI Mobile.

Catatan

Anda dapat menyimpan atau mencetak laporan resmi ini dengan memilih Cetak dari browser Anda, lalu memilih Simpan sebagai PDF.

Pendahuluan

Power BI adalah penawaran layanan perangkat lunak online (SaaS, atau Software as a Service) dari Microsoft yang memungkinkan Anda membuat dasbor, laporan, model semantik, dan visualisasi Kecerdasan Bisnis mandiri dengan mudah dan cepat. Dengan Power BI, Anda bisa menyambungkan ke berbagai sumber data, menggabungkan dan membentuk data dari koneksi tersebut, lalu membuat laporan dan dasbor yang dapat dibagikan dengan orang lain.

Dunia berubah dengan cepat; organisasi sedang melalui transformasi digital yang dipercepat, dan kami melihat peningkatan besar-besaran dalam bekerja jarak jauh, peningkatan permintaan pelanggan untuk layanan online, dan peningkatan penggunaan teknologi canggih dalam operasi dan pengambilan keputusan bisnis. Dan semua ini didukung oleh cloud.

Ketika transisi ke cloud telah berubah dari tembok ke banjir, dan dengan area permukaan baru yang terbuka yang disertakan, lebih banyak perusahaan bertanya Seberapa aman data saya di cloud? dan Perlindungan menyeluruh apa yang tersedia untuk mencegah data sensitif saya bocor? Dan untuk platform BI yang sering menangani beberapa informasi paling strategis di perusahaan, pertanyaan-pertanyaan ini sangat penting.

Fondasi model keamanan BI yang sudah berusia puluhan tahun - keamanan tingkat objek dan baris - meskipun masih penting, jelas tidak lagi cukup untuk menyediakan jenis keamanan yang diperlukan di era cloud. Sebagai gantinya, organisasi harus mencari solusi keamanan cloud-native, multi-tingkat, pertahanan-mendalam untuk data kecerdasan bisnis mereka.

Power BI dibangun untuk memberikan perlindungan lengkap dan hermetik terdepan di industri untuk data. Produk ini telah mendapatkan klasifikasi keamanan tertinggi yang tersedia di industri, dan saat ini banyak badan keamanan nasional, lembaga keuangan, dan penyedia layanan kesehatan mempercayakannya dengan informasi mereka yang paling sensitif.

Semuanya dimulai dengan fondasi. Setelah periode kasar pada awal 2000-an, Microsoft melakukan investasi besar-besaran untuk mengatasi kerentanan keamanannya, dan dalam beberapa dekade berikut membangun tumpukan keamanan yang kuat yang sedalam kernel bios mesin on-chip dan memperluas semua jalan hingga pengalaman pengguna akhir. Investasi mendalam ini berlanjut, dan saat ini lebih dari 3.500 insinyur Microsoft terlibat dalam membangun dan meningkatkan tumpukan keamanan Microsoft dan secara proaktif mengatasi lanskap ancaman yang terus bergeser. Dengan miliaran komputer, triliunan login, dan zettabyte informasi yang tak terhitung jumlahnya yang dipercayakan kepada perlindungan Microsoft, perusahaan sekarang memiliki tumpukan keamanan paling canggih di industri teknologi dan secara luas dipandang sebagai pemimpin global dalam perang melawan aktor jahat.

Power BI dibangun berdasarkan fondasi yang kuat ini. Ini menggunakan tumpukan keamanan yang sama yang mendapatkan hak Azure untuk melayani dan melindungi data paling sensitif di dunia, dan terintegrasi dengan alat perlindungan dan kepatuhan informasi paling canggih dari Microsoft 365. Selain itu, ini memberikan keamanan melalui langkah-langkah keamanan berlapis, menghasilkan perlindungan end-to-end yang dirancang untuk menangani tantangan unik era cloud.

Untuk menyediakan solusi menyeluruh untuk melindungi aset sensitif, tim produk perlu mengatasi masalah pelanggan yang menantang pada beberapa front simultan:

• Bagaimana kita mengontrol siapa yang dapat terhubung, dari mana mereka terhubung, dan bagaimana koneksinya? Bagaimana kita bisa mengontrol koneksi?
• Bagaimana data disimpan? Bagaimana dienkripsi? Kontrol apa yang saya miliki pada data saya?
• Bagaimana cara mengontrol dan melindungi data sensitif saya? Bagaimana cara memastikan data ini tidak dapat bocor di luar organisasi?
• Bagaimana cara mengaudit siapa yang melakukan operasi apa? Bagaimana cara bereaksi dengan cepat jika ada aktivitas mencurigakan pada layanan?

Artikel ini memberikan jawaban komprehensif untuk semua pertanyaan ini. Ini dimulai dengan gambaran umum arsitektur layanan dan menjelaskan bagaimana alur utama dalam sistem bekerja. Kemudian melanjutkan untuk menjelaskan cara pengguna mengautentikasi ke Power BI, bagaimana koneksi data dibuat, dan cara Power BI menyimpan dan memindahkan data melalui layanan. Bagian terakhir membahas fitur keamanan yang memungkinkan Anda, sebagai admin layanan, untuk melindungi aset Anda yang paling berharga.

layanan Power BI diatur oleh Ketentuan Layanan Online Microsoft, dan Pernyataan Privasi Microsoft Enterprise. Untuk lokasi pemrosesan data, lihat Lokasi istilah Pemrosesan Data dalam Ketentuan Layanan Online Microsoft dan ke Adendum Perlindungan Data. Untuk informasi kepatuhan, Pusat Kepercayaan Microsoft adalah sumber daya utama untuk Power BI. Tim Power BI bekerja keras untuk menghadirkan inovasi dan produktivitas terbaru kepada pelanggannya. Pelajari selengkapnya tentang kepatuhan dalam penawaran kepatuhan Microsoft.

layanan Power BI mengikuti Security Development Lifecycle (SDL), praktik keamanan ketat yang mendukung persyaratan jaminan keamanan dan kepatuhan. SDL membantu pengembang membangun perangkat lunak yang lebih aman dengan mengurangi jumlah dan tingkat keparahan kerentanan dalam perangkat lunak, sekaligus mengurangi biaya pengembangan. Pelajari selengkapnya di Praktik Siklus Hidup Pengembangan Keamanan Microsoft.

Arsitektur Power BI

layanan Power BI dibangun di Azure, platform komputasi cloud Microsoft. Power BI saat ini disebarkan di banyak pusat data di seluruh dunia - ada banyak penyebaran aktif yang tersedia untuk pelanggan di wilayah yang dilayani oleh pusat data tersebut, dan jumlah penyebaran pasif yang sama yang berfungsi sebagai cadangan untuk setiap penyebaran aktif.

Kluster front-end web (WFE)

Kluster WFE menyediakan browser pengguna dengan konten halaman HTML awal pada pemuatan situs, dan penunjuk ke konten CDN yang digunakan untuk merender situs di browser.

Kluster WFE terdiri dari situs web ASP.NET yang berjalan di Lingkungan Azure App Service. Saat pengguna mencoba menyambungkan ke layanan Power BI, layanan DNS klien dapat berkomunikasi dengan Azure Traffic Manager untuk menemukan pusat data yang paling tepat (biasanya terdekat) dengan penyebaran Power BI. Untuk informasi selengkapnya tentang proses ini, lihat Metode perutean lalu lintas performa untuk Azure Traffic Manager.

Sumber daya statis seperti *.js, *.css, dan file gambar sebagian besar disimpan di Azure Content Delivery Network (CDN) dan diambil langsung oleh browser. Perhatikan bahwa penyebaran kluster Sovereign Government adalah pengecualian untuk aturan ini, dan karena alasan kepatuhan akan menghilangkan CDN dan sebaliknya menggunakan kluster WFE dari wilayah yang sesuai untuk menghosting konten statis.

Kluster back-end Power BI (BE)

Kluster back-end adalah tulang punggung dari semua fungsionalitas yang tersedia di Power BI. Ini terdiri dari beberapa titik akhir layanan yang digunakan oleh klien Web Front End dan API serta layanan kerja latar belakang, database, cache, dan berbagai komponen lainnya.

Back end tersedia di sebagian besar wilayah Azure, dan sedang disebarkan di wilayah baru saat tersedia. Satu wilayah Azure menghosting satu atau beberapa kluster back-end yang memungkinkan penskalaan horizontal tak terbatas layanan Power BI setelah batas penskalaan vertikal dan horizontal dari satu kluster habis.

Setiap kluster back-end bersifat stateful dan menghosting semua data semua penyewa yang ditetapkan ke kluster tersebut. Kluster yang berisi data penyewa tertentu disebut sebagai kluster beranda penyewa. Informasi kluster beranda pengguna yang diautentikasi disediakan oleh Layanan Global dan digunakan oleh Web Front End untuk merutekan permintaan ke kluster beranda penyewa.

Setiap kluster back-end terdiri dari beberapa komputer virtual yang digabungkan ke dalam beberapa set skala yang dapat diubah ukurannya disetel untuk melakukan tugas tertentu, sumber daya stateful seperti database SQL, akun penyimpanan, bus layanan, cache, dan komponen cloud lain yang diperlukan.

Metadata penyewa dan data disimpan dalam batas kluster kecuali untuk replikasi data ke kluster back-end sekunder di wilayah Azure yang dipasangkan di geografi Azure yang sama. Kluster back-end sekunder berfungsi sebagai kluster failover jika terjadi pemadaman regional, dan pasif di lain waktu.

Fungsionalitas back-end dilayani oleh layanan mikro yang berjalan pada komputer yang berbeda dalam jaringan virtual kluster yang tidak dapat diakses dari luar, kecuali untuk dua komponen yang dapat diakses dari internet publik:

• Layanan Gateway
• Azure API Management

Infrastruktur Power BI Premium

Power BI Premium menawarkan layanan untuk pelanggan yang memerlukan fitur Power BI premium, seperti AI tingkat lanjut, distribusi ke pengguna tanpa lisensi, dll. Saat pelanggan mendaftar langganan Power BI Premium, kapasitas Premium dibuat melalui Azure Resource Manager.

Kapasitas Power BI Premium dihosting di kluster back-end yang independen dari back end Power BI reguler - lihat di atas). Ini memberikan isolasi yang lebih baik, alokasi sumber daya, dukungan, isolasi keamanan, dan skalabilitas penawaran Premium.

Diagram berikut mengilustrasikan arsitektur infrastruktur Power BI Premium:

Koneksi ke infrastruktur Power BI Premium dapat dilakukan dalam banyak cara, tergantung pada skenario pengguna. Klien Power BI Premium dapat menjadi browser pengguna, back end Power BI reguler, koneksi langsung melalui klien XMLA, API ARM, dll.

Infrastruktur Power BI Premium di wilayah Azure terdiri dari beberapa kluster Power BI Premium (minimumnya adalah satu). Sebagian besar sumber daya Premium dienkapsulasi di dalam kluster (misalnya, komputasi), dan ada beberapa sumber daya regional umum (misalnya, penyimpanan metadata). Infrastruktur premium memungkinkan dua cara mencapai skalabilitas horizontal di suatu wilayah: meningkatkan sumber daya di dalam kluster dan/atau menambahkan lebih banyak kluster sesuai permintaan sesuai kebutuhan (jika sumber daya kluster mendekati batasnya).

Tulang punggung setiap kluster adalah sumber daya komputasi yang dikelola oleh Virtual Machine Scale Sets dan Azure Service Fabric. Virtual Machine Scale Sets dan Service Fabric memungkinkan peningkatan simpul komputasi yang cepat dan tanpa rasa sakit saat penggunaan tumbuh dan mengatur penyebaran, manajemen, dan pemantauan layanan dan aplikasi Power BI Premium.

Ada banyak sumber daya di sekitarnya yang memastikan infrastruktur yang aman dan andal: load balancer, jaringan virtual, kelompok keamanan jaringan, bus layanan, penyimpanan, dll. Rahasia, kunci, dan sertifikat apa pun yang diperlukan untuk Power BI Premium dikelola oleh Azure Key Vault secara eksklusif. Autentikasi apa pun dilakukan melalui integrasi dengan MICROSOFT Entra ID secara eksklusif.

Setiap permintaan yang masuk ke infrastruktur Power BI Premium masuk ke simpul front-end terlebih dahulu - mereka adalah satu-satunya simpul yang tersedia untuk koneksi eksternal. Sumber daya lainnya disembunyikan di balik jaringan virtual. Simpul front-end mengautentikasi permintaan, menanganinya, atau meneruskannya ke sumber daya yang sesuai (misalnya, simpul back-end).

Simpul back-end menyediakan sebagian besar kemampuan dan fitur Power BI Premium.

Power BI Mobile

Power BI Mobile adalah kumpulan aplikasi yang dirancang untuk tiga platform seluler utama: Android, iOS, dan Windows (UWP). Pertimbangan keamanan untuk aplikasi Power BI Mobile termasuk dalam dua kategori:

• Komunikasi perangkat
• Aplikasi dan data pada perangkat

Untuk komunikasi perangkat, semua aplikasi Power BI Mobile berkomunikasi dengan layanan Power BI, dan menggunakan urutan koneksi dan autentikasi yang sama yang digunakan oleh browser, yang dijelaskan secara rinci sebelumnya dalam laporan resmi ini. Aplikasi seluler Power BI untuk iOS dan Android memunculkan sesi browser dalam aplikasi itu sendiri, sementara aplikasi seluler Windows memunculkan broker untuk membangun saluran komunikasi dengan Power BI (untuk proses masuk).

Tabel berikut ini memperlihatkan dukungan autentikasi berbasis sertifikat (CBA) untuk Power BI Mobile, berdasarkan platform perangkat seluler:

Dukungan CBA	iOS	Android	Windows
Power BI (masuk ke layanan)	Didukung	Didukung	Tidak didukung
SSRS ADFS lokal (sambungkan ke server SSRS)	Tidak didukung	Didukung	Tidak didukung
Proksi Aplikasi SSRS	Didukung	Didukung	Tidak didukung

Aplikasi Power BI Mobile secara aktif berkomunikasi dengan layanan Power BI. Telemetri digunakan untuk mengumpulkan statistik penggunaan aplikasi seluler dan data serupa, yang ditransmisikan ke layanan yang digunakan untuk memantau penggunaan dan aktivitas; tidak ada data pelanggan yang dikirim dengan telemetri.

Aplikasi Power BI menyimpan data pada perangkat yang memfasilitasi penggunaan aplikasi:

• ID Microsoft Entra dan token refresh disimpan dalam mekanisme yang aman pada perangkat, menggunakan langkah-langkah keamanan standar industri.
• Data dan pengaturan (pasangan kunci-nilai untuk konfigurasi pengguna) di-cache di penyimpanan pada perangkat, dan dapat dienkripsi oleh OS. Di iOS, ini secara otomatis dilakukan saat pengguna mengatur kode sandi. Di Android, ini dapat dikonfigurasi dalam pengaturan. Di Windows, itu dicapai dengan menggunakan BitLocker.
• Untuk aplikasi Android dan iOS, data dan pengaturan (pasangan kunci-nilai untuk konfigurasi pengguna) di-cache di penyimpanan pada perangkat di kotak pasir dan penyimpanan internal yang hanya dapat diakses oleh aplikasi. Untuk aplikasi Windows, data hanya dapat diakses oleh pengguna (dan admin sistem).
• Geolokasi diaktifkan atau dinonaktifkan secara eksplisit oleh pengguna. Jika diaktifkan, data geolokasi tidak disimpan di perangkat dan tidak dibagikan dengan Microsoft.
• Pemberitahuan diaktifkan atau dinonaktifkan secara eksplisit oleh pengguna. Jika diaktifkan, Android dan iOS tidak mendukung persyaratan residensi data geografis untuk pemberitahuan.

Enkripsi data dapat ditingkatkan dengan menerapkan enkripsi tingkat file melalui Microsoft Intune, layanan perangkat lunak yang menyediakan perangkat seluler dan manajemen aplikasi. Ketiga platform di mana Power BI Mobile tersedia mendukung Intune. Dengan Intune diaktifkan dan dikonfigurasi, data pada perangkat seluler dienkripsi, dan aplikasi Power BI itu sendiri tidak dapat diinstal pada kartu SD. Pelajari selengkapnya tentang Microsoft Intune.

Aplikasi Windows juga mendukung Perlindungan Informasi Windows (WIP).

Untuk menerapkan SSO, beberapa nilai penyimpanan aman yang terkait dengan autentikasi berbasis token tersedia untuk aplikasi pihak pertama Microsoft lainnya (seperti Microsoft Authenticator) dan dikelola oleh Microsoft Authentication Library (MSAL).

Data singgahan Power BI Mobile dihapus saat aplikasi dihapus, saat pengguna keluar dari Power BI Mobile, atau ketika pengguna gagal masuk (seperti setelah peristiwa kedaluwarsa token atau perubahan kata sandi). Cache data menyertakan dasbor dan laporan yang sebelumnya diakses dari aplikasi Power BI Mobile.

Power BI Mobile tidak mengakses folder atau file aplikasi lain di perangkat.

Aplikasi Power BI untuk iOS dan Android memungkinkan Anda melindungi data dengan mengonfigurasi identifikasi tambahan, seperti menyediakan ID Wajah, ID Sentuhan, atau kode sandi untuk iOS, dan data biometrik (ID Sidik Jari) untuk Android. Pelajari selengkapnya tentang identifikasi tambahan.

Autentikasi ke layanan Power BI

Autentikasi pengguna ke layanan Power BI terdiri dari serangkaian permintaan, respons, dan pengalihan antara browser pengguna dan layanan Power BI atau layanan Azure yang digunakan oleh Power BI. Urutan tersebut menjelaskan proses autentikasi pengguna di Power BI, yang mengikuti alur pemberian kode autentikasi Microsoft Entra. Untuk informasi selengkapnya tentang opsi untuk model autentikasi pengguna organisasi (model masuk), lihat Memilih model masuk untuk Microsoft 365.

Urutan autentikasi

Urutan autentikasi pengguna untuk layanan Power BI terjadi seperti yang dijelaskan dalam langkah-langkah berikut, yang diilustrasikan dalam gambar yang mengikutinya.

1. Pengguna memulai koneksi ke layanan Power BI dari browser, baik dengan mengetikkan alamat Power BI di bilah alamat atau dengan memilih Masuk dari halaman pemasaran Power BI (https://powerbi.microsoft.com). Koneksi dibuat menggunakan TLS dan HTTPS, dan semua komunikasi berikutnya antara browser dan layanan Power BI menggunakan HTTPS.

2. Azure Traffic Manager memeriksa catatan DNS pengguna untuk menentukan pusat data yang paling tepat (biasanya terdekat) tempat Power BI disebarkan, dan merespons DNS dengan alamat IP kluster WFE tempat pengguna harus dikirim.

3. WFE kemudian mengembalikan halaman HTML ke klien browser, yang berisi referensi pustaka MSAL.js yang diperlukan untuk memulai alur masuk.

4. Klien browser memuat halaman HTML yang diterima dari WFE, dan mengalihkan pengguna ke halaman masuk Microsoft Online Services.

5. Setelah pengguna diautentikasi, halaman masuk mengalihkan pengguna kembali ke halaman Power BI WFE dengan kode autentikasi.

6. Klien browser memuat halaman HTML, dan menggunakan kode autentikasi untuk meminta token (akses, ID, refresh) dari ID Microsoft Entra.

7. ID penyewa pengguna digunakan oleh klien browser untuk mengkueri Layanan Global Power BI, yang mempertahankan daftar penyewa dan lokasi kluster back-end Power BI mereka. Layanan Global Power BI menentukan kluster layanan back-end Power BI mana yang berisi penyewa pengguna, dan mengembalikan URL kluster back-end Power BI kembali ke klien.

8. Klien sekarang dapat berkomunikasi dengan API URL kluster back-end Power BI, menggunakan token akses di header Otorisasi untuk permintaan HTTP. Token akses Microsoft Entra akan memiliki tanggal kedaluwarsa yang ditetapkan sesuai dengan kebijakan Microsoft Entra, dan untuk mempertahankan sesi saat ini Klien Power BI di browser pengguna akan membuat permintaan berkala untuk memperbarui token akses sebelum kedaluwarsa.

Dalam kasus yang jarang terjadi di mana autentikasi sisi klien gagal karena kesalahan tak terduga, kode mencoba untuk kembali menggunakan autentikasi sisi server di WFE. Lihat bagian pertanyaan dan jawaban di akhir dokumen ini untuk detail tentang alur autentikasi sisi server.

Residensi data

Kecuali dinyatakan lain dalam dokumentasi, Power BI menyimpan data pelanggan dalam geografi Azure yang ditetapkan saat penyewa Microsoft Entra mendaftar untuk layanan Power BI untuk pertama kalinya. Penyewa Microsoft Entra menampung identitas pengguna dan aplikasi, grup, dan informasi relevan lainnya yang berkaitan dengan organisasi dan keamanannya.

Penetapan geografi Azure untuk penyimpanan data penyewa dilakukan dengan memetakan negara atau wilayah yang dipilih sebagai bagian dari penyiapan penyewa Microsoft Entra ke geografi Azure yang paling sesuai tempat penyebaran Power BI berada. Setelah penetapan ini dibuat, semua data pelanggan Power BI akan disimpan dalam geografi Azure yang dipilih ini (juga dikenal sebagai geografi rumah), kecuali dalam kasus di mana organisasi menggunakan penyebaran multi-geo.

Beberapa geografi (multi-geo)

Beberapa organisasi memiliki kehadiran global dan mungkin memerlukan layanan Power BI di beberapa geografi Azure. Misalnya, bisnis mungkin memiliki kantor pusat mereka di Amerika Serikat tetapi juga dapat melakukan bisnis di area geografis lainnya, seperti Australia. Dalam kasus seperti itu, bisnis mungkin mengharuskan data Power BI tertentu tetap disimpan saat tidak aktif di wilayah jarak jauh untuk mematuhi peraturan lokal. Fitur layanan Power BI ini disebut sebagai multi-geo.

Lapisan eksekusi kueri, cache kueri, dan data artefak yang ditetapkan ke ruang kerja multi-geo dihosting dan tetap berada dalam geografi Azure kapasitas jarak jauh. Namun, beberapa metadata artefak, seperti struktur laporan, dapat tetap disimpan saat tidak aktif di geo rumah penyewa. Selain itu, beberapa transit dan pemrosesan data mungkin masih terjadi di geo rumah penyewa, bahkan untuk ruang kerja yang dihosting dalam kapasitas Premium multi-geo.

Lihat Mengonfigurasi dukungan Multi-Geo untuk Power BI Premium untuk informasi selengkapnya tentang membuat dan mengelola penyebaran Power BI yang mencakup beberapa geografi Azure.

Wilayah dan pusat data

layanan Power BI tersedia di geografi Azure tertentu seperti yang dijelaskan dalam Pusat Kepercayaan Microsoft. Untuk informasi selengkapnya tentang tempat data Anda disimpan dan cara data tersebut digunakan, lihat Pusat Kepercayaan Microsoft. Komitmen mengenai lokasi data pelanggan tidak aktif ditentukan dalam Ketentuan Pemrosesan Data dari Ketentuan Layanan Online Microsoft.

Microsoft juga menyediakan pusat data untuk entitas berdaulat. Untuk informasi selengkapnya tentang ketersediaan layanan Power BI untuk cloud nasional/regional, lihat Cloud nasional/regional Power BI.

Penanganan data

Bagian ini menguraikan praktik penanganan data Power BI dalam hal menyimpan, memproses, dan mentransfer data pelanggan.

Data tidak aktif

Power BI menggunakan dua jenis sumber daya penyimpanan data utama:

• Azure Storage
• Azure SQL Database

Dalam sebagian besar skenario, Azure Storage digunakan untuk mempertahankan data artefak Power BI, sementara Azure SQL Database digunakan untuk mempertahankan metadata artefak.

Semua data yang disimpan oleh Power BI dienkripsi secara default menggunakan kunci yang dikelola Microsoft. Data pelanggan yang disimpan di Azure SQL Database sepenuhnya dienkripsi menggunakan teknologi Transparent Data Encryption (TDE) Azure SQL. Data pelanggan yang disimpan di penyimpanan Azure Blob dienkripsi menggunakan Azure Storage Encryption.

Secara opsional, organisasi dapat menggunakan Power BI Premium untuk menggunakan kunci mereka sendiri untuk mengenkripsi data tidak aktif yang diimpor ke dalam model semantik. Pendekatan ini sering dijelaskan sebagai bring your own key (BYOK). Memanfaatkan BYOK membantu memastikan bahwa bahkan jika terjadi kesalahan operator layanan, data pelanggan tidak akan diekspos – sesuatu yang tidak dapat dengan mudah dicapai menggunakan enkripsi sisi layanan transparan. Lihat Membawa kunci enkripsi Anda sendiri untuk Power BI untuk informasi selengkapnya.

Model semantik Power BI memungkinkan berbagai mode koneksi sumber data yang menentukan apakah data sumber data dipertahankan dalam layanan atau tidak.

Mode Model Semantik (Jenis)	Data Bertahan di Power BI
Impor	Ya
DirectQuery	No
Live Connect	No
Komposit	Jika berisi sumber impor data
Streaming	Jika dikonfigurasi untuk bertahan

Terlepas dari mode model semantik yang digunakan, Power BI dapat men-cache sementara data yang diambil untuk mengoptimalkan kueri dan melaporkan performa beban.

Data dalam pemrosesan

Data sedang diproses saat digunakan secara aktif oleh satu atau beberapa pengguna sebagai bagian dari skenario interaktif, atau ketika proses latar belakang, seperti refresh, menyentuh data ini. Power BI memuat data yang diproses secara aktif ke ruang memori satu atau beberapa beban kerja layanan. Untuk memfasilitasi fungsionalitas yang diperlukan oleh beban kerja, data yang diproses dalam memori tidak dienkripsi.

Data saat transit

Power BI mengharuskan semua lalu lintas HTTP masuk dienkripsi menggunakan TLS 1.2 atau lebih tinggi. Setiap permintaan yang mencoba menggunakan layanan dengan TLS 1.1 atau yang lebih rendah akan ditolak.

Autentikasi ke sumber data

Saat menyambungkan ke sumber data, pengguna bisa memilih untuk mengimpor salinan data ke Power BI atau menyambungkan langsung ke sumber data.

Dalam kasus impor, pengguna membuat koneksi berdasarkan masuk pengguna dan mengakses data dengan kredensial. Setelah model semantik diterbitkan ke layanan Power BI, Power BI selalu menggunakan kredensial pengguna ini untuk mengimpor data. Setelah data diimpor, menampilkan data dalam laporan dan dasbor tidak mengakses sumber data yang mendasar. Power BI mendukung autentikasi akses menyeluruh untuk sumber data yang dipilih. Jika koneksi dikonfigurasi untuk menggunakan akses menyeluruh, kredensial pemilik model semantik digunakan untuk menyambungkan ke sumber data.

Jika sumber data tersambung langsung menggunakan kredensial yang telah dikonfigurasi sebelumnya, kredensial yang telah dikonfigurasi sebelumnya digunakan untuk menyambungkan ke sumber data saat pengguna melihat data. Jika sumber data tersambung langsung menggunakan akses menyeluruh, kredensial pengguna saat ini digunakan untuk menyambungkan ke sumber data saat pengguna melihat data. Saat digunakan dengan akses menyeluruh, Keamanan Tingkat Baris (RLS) dan/atau keamanan tingkat objek (OLS) dapat diimplementasikan pada sumber data. Ini memungkinkan pengguna untuk melihat hanya data yang mereka miliki hak istimewa untuk diakses. Saat koneksi ke sumber data di cloud, autentikasi Microsoft Entra digunakan untuk akses menyeluruh; untuk sumber data lokal, Kerberos, Security Assertion Markup Language (SAML), dan MICROSOFT Entra ID didukung.

Jika sumber data adalah Azure Analysis Services atau Analysis Services lokal, dan RLS dan/atau OLS dikonfigurasi, layanan Power BI akan menerapkan keamanan tingkat baris tersebut, dan pengguna yang tidak memiliki kredensial yang memadai untuk mengakses data yang mendasar (yang bisa menjadi kueri yang digunakan dalam dasbor, laporan, atau artefak data lainnya) tidak akan melihat data yang tidak memiliki hak istimewa yang memadai.

Fitur premium

Arsitektur aliran data

Aliran data memberi pengguna kemampuan untuk mengonfigurasi operasi pemrosesan data back-end yang akan mengekstrak data dari sumber data polimorfous, menjalankan logika transformasi terhadap data, lalu mendaratkannya dalam model target untuk digunakan di berbagai teknologi presentasi pelaporan. Setiap pengguna yang memiliki peran anggota, kontributor, atau admin di ruang kerja dapat membuat aliran data. Pengguna dalam peran penampil dapat melihat data yang diproses oleh aliran data tetapi mungkin tidak membuat perubahan pada komposisinya. Setelah aliran data ditulis, setiap anggota, kontributor, atau admin ruang kerja dapat menjadwalkan refresh, serta melihat dan mengedit aliran data dengan mengambil kepemilikannya.

Setiap sumber data yang dikonfigurasi terikat ke teknologi klien untuk mengakses sumber data tersebut. Struktur kredensial yang diperlukan untuk mengaksesnya dibentuk agar sesuai dengan detail implementasi sumber data yang diperlukan. Logika transformasi diterapkan oleh layanan Power Query saat data sedang dalam penerbangan. Untuk aliran data premium, layanan Power Query dijalankan di simpul back-end. Data dapat ditarik langsung dari sumber cloud atau melalui gateway yang diinstal secara lokal. Ketika ditarik langsung dari sumber cloud ke layanan atau ke gateway, transportasi menggunakan metodologi perlindungan khusus untuk teknologi klien, jika berlaku. Saat data ditransfer dari gateway ke layanan awan, data dienkripsi. Lihat bagian Data di Transit di atas.

Ketika sumber data yang ditentukan pelanggan memerlukan kredensial untuk akses, pemilik/pembuat aliran data akan memberi mereka selama penulisan. Mereka disimpan menggunakan penyimpanan kredensial seluruh produk standar. Lihat bagian Autentikasi ke Sumber Data di atas. Ada berbagai pendekatan yang dapat dikonfigurasi pengguna untuk mengoptimalkan persistensi dan akses data. Secara default, data ditempatkan di akun penyimpanan yang dimiliki dan dilindungi Power BI. Enkripsi penyimpanan diaktifkan pada kontainer penyimpanan Blob untuk melindungi data saat tidak aktif. Lihat bagian Data saat Istirahat di bawah ini. Namun, pengguna dapat mengonfigurasi akun penyimpanan mereka sendiri yang terkait dengan langganan Azure mereka sendiri. Saat melakukannya, perwakilan layanan Power BI diberikan akses ke akun penyimpanan tersebut sehingga dapat menulis data di sana selama refresh. Dalam hal ini, pemilik sumber daya penyimpanan bertanggung jawab untuk mengonfigurasi enkripsi pada akun penyimpanan ADLS yang dikonfigurasi. Data selalu ditransmisikan ke penyimpanan Blob menggunakan enkripsi.

Karena performa saat mengakses akun penyimpanan mungkin kurang optimal untuk beberapa data, pengguna juga memiliki opsi untuk menggunakan mesin komputasi yang dihosting Power BI untuk meningkatkan performa. Dalam hal ini, data disimpan secara berlebihan dalam database SQL yang tersedia untuk DirectQuery melalui akses oleh sistem Power BI back-end. Data selalu dienkripsi pada sistem file. Jika pengguna menyediakan kunci untuk mengenkripsi data yang disimpan dalam database SQL, kunci tersebut akan digunakan untuk mengenkripsinya dua kali lipat.

Saat mengkueri menggunakan DirectQuery, HTTPS protokol transportasi terenkripsi digunakan untuk mengakses API. Semua penggunaan sekunder atau tidak langsung DirectQuery dikontrol oleh kontrol akses yang sama yang dijelaskan sebelumnya. Karena aliran data selalu terikat ke ruang kerja, akses ke data selalu dijaga oleh peran pengguna di ruang kerja tersebut. Pengguna harus memiliki setidaknya akses baca untuk dapat mengkueri data melalui cara apa pun.

Saat Power BI Desktop digunakan untuk mengakses data dalam aliran data, Power BI Desktop harus terlebih dahulu mengautentikasi pengguna menggunakan ID Microsoft Entra untuk menentukan apakah pengguna memiliki hak yang memadai untuk melihat data. Jika demikian, kunci SaS diperoleh dan digunakan untuk mengakses penyimpanan secara langsung menggunakan HTTPS protokol transportasi terenkripsi.

Pemrosesan data di seluruh alur memancarkan peristiwa audit Office 365. Beberapa peristiwa ini akan menangkap operasi keamanan dan terkait privasi.

Laporan bernomor

laporan yang dipaginasi dirancang untuk dicetak atau dibagikan. Mereka disebut dipaginasi karena diformat agar sesuai dengan halaman. Mereka menampilkan semua data dalam tabel, bahkan jika tabel mencakup beberapa halaman. Anda dapat mengontrol tata letak halaman laporan mereka dengan tepat.

Laporan yang dipaginasi mendukung ekspresi yang kaya dan kuat yang ditulis dalam Microsoft Visual Basic .NET. Ekspresi banyak digunakan di seluruh laporan paginasi Power BI Report Builder untuk mengambil, menghitung, menampilkan, mengelompokkan, mengurutkan, memfilter, membuat parameter, dan memformat data.

Ekspresi dibuat oleh penulis laporan dengan akses ke berbagai fitur kerangka kerja .NET. Pemrosesan dan eksekusi laporan paginated dilakukan di dalam kotak pasir.

Definisi laporan paginasi (.rdl) disimpan di Power BI, dan untuk menerbitkan dan/atau merender laporan paginated yang diperlukan pengguna untuk mengautentikasi dan mengotorisasi dengan cara yang sama seperti yang dijelaskan di bagian Autentikasi ke Layanan Power BI di atas.

Token Microsoft Entra yang diperoleh selama autentikasi digunakan untuk berkomunikasi langsung dari browser ke kluster Power BI Premium.

Di Power BI Premium, runtime layanan Power BI menyediakan lingkungan eksekusi yang terisolasi dengan tepat untuk setiap render laporan. Ini termasuk kasus di mana laporan yang dirender milik ruang kerja yang ditetapkan ke kapasitas yang sama.

Laporan yang dipaginasi dapat mengakses berbagai sumber data sebagai bagian dari penyajian laporan. Kotak pasir tidak berkomunikasi langsung dengan salah satu sumber data tetapi sebaliknya berkomunikasi dengan proses tepercaya untuk meminta data, lalu proses tepercaya menambahkan kredensial yang diperlukan ke koneksi. Dengan cara ini, kotak pasir tidak pernah memiliki akses ke kredensial atau rahasia apa pun.

Untuk mendukung fitur seperti peta Bing, atau panggilan ke Azure Functions, kotak pasir memang memiliki akses ke internet.

Power BI analitik yang disematkan

Vendor Perangkat Lunak Independen (ISV) dan penyedia solusi memiliki dua mode utama penyematan artefak Power BI di aplikasi web dan portal mereka: sematkan untuk organisasi Anda dan sematkan untuk pelanggan Anda. Artefak disematkan ke dalam IFrame di aplikasi atau portal. IFrame tidak diizinkan untuk membaca atau menulis data dari aplikasi web atau portal eksternal, dan komunikasi dengan IFrame dilakukan dengan menggunakan SDK Klien Power BI menggunakan pesan POST.

Dalam semat untuk skenario organisasi Anda, pengguna Microsoft Entra mengakses konten Power BI mereka sendiri melalui portal yang disesuaikan oleh perusahaan dan IP mereka. Semua kebijakan dan kemampuan Power BI yang dijelaskan dalam makalah ini seperti Keamanan Tingkat Baris (RLS) dan keamanan tingkat objek (OLS) secara otomatis diterapkan ke semua pengguna secara independen tentang apakah mereka mengakses Power BI melalui portal Power BI atau melalui portal yang disesuaikan.

Dalam semat untuk skenario pelanggan Anda, ISV biasanya memiliki penyewa Power BI dan item Power BI (dasbor, laporan, model semantik, dan lainnya). Ini adalah tanggung jawab layanan ujung belakang ISV untuk mengautentikasi pengguna akhirnya dan memutuskan artefak mana dan tingkat akses mana yang sesuai untuk pengguna akhir tersebut. Keputusan kebijakan ISV dienkripsi dalam token semat yang dihasilkan oleh Power BI dan diteruskan ke ujung belakang ISV untuk distribusi lebih lanjut kepada pengguna akhir sesuai dengan logika bisnis ISV. Pengguna akhir yang menggunakan browser atau aplikasi klien lainnya tidak dapat mendekripsi atau memodifikasi token yang disematkan. SDK sisi klien seperti API Klien Power BI secara otomatis menambahkan token tersemat terenkripsi ke permintaan Power BI sebagai Otorisasi: header EmbedToken . Berdasarkan header ini, Power BI akan memberlakukan semua kebijakan (seperti akses atau RLS) tepat seperti yang ditentukan oleh ISV selama pembuatan.

Untuk mengaktifkan penyematan dan otomatisasi, dan untuk menghasilkan token semat yang dijelaskan di atas, Power BI mengekspos serangkaian REST API yang kaya. REST API Power BI ini mendukung metode autentikasi dan otorisasi Microsoft Entra perwakilan layanan dan pengguna.

Analitik yang disematkan Power BI dan REST API-nya mendukung semua kemampuan isolasi jaringan Power BI yang dijelaskan dalam artikel ini: Misalnya, Tag Layanan dan Private Link.

Fitur AI

Power BI saat ini mendukung dua kategori fitur AI yang luas dalam produk saat ini: Visual AI dan pengayaan AI. Fitur AI tingkat visual mencakup kemampuan seperti Key-Influencer, Decomposition-Tree, Smart-Narrative, Deteksi Anomali, R-visual, Python-visual, Clustering, Forecasting, Q&A, Quick-Insights dll. Kemampuan pengayaan AI mencakup kemampuan seperti AutoML, Azure Pembelajaran Mesin, CognitiveServices, transformasi R/Python, dll.

Sebagian besar fitur yang disebutkan di atas didukung di ruang kerja Bersama dan Premium saat ini. Namun, AutoML dan CognitiveServices hanya didukung di ruang kerja Premium, karena pembatasan IP. Saat ini, dengan integrasi AutoML di Power BI, pengguna dapat membangun dan melatih model ML kustom (misalnya, Prediksi, Klasifikasi, Regresi, dll.) dan menerapkannya untuk mendapatkan prediksi saat memuat data ke dalam aliran data yang ditentukan di ruang kerja Premium. Selain itu, pengguna Power BI dapat menerapkan beberapa API CognitiveServices, seperti TextAnalytics dan ImageTagging, untuk mengubah data sebelum memuatnya ke dalam model aliran data/semantik yang ditentukan di ruang kerja Premium.

Fitur pengayaan AI Premium dapat dilihat sebagai kumpulan fungsi/transformasi AI stateless yang dapat digunakan oleh pengguna Power BI dalam alur integrasi data mereka yang digunakan oleh model semantik atau aliran data Power BI. Perhatikan bahwa fungsi-fungsi ini juga dapat diakses dari lingkungan penulisan model aliran data/semantik saat ini di Layanan Power BI dan Power BI Desktop. Fungsi/transformasi AI ini selalu berjalan di ruang kerja/kapasitas Premium. Fungsi-fungsi ini muncul di Power BI sebagai sumber data yang memerlukan token Microsoft Entra untuk pengguna Power BI yang menggunakan fungsi AI. Sumber data AI ini istimewa karena tidak menampilkan data mereka sendiri dan mereka hanya menyediakan fungsi/transformasi ini. Selama eksekusi, fitur-fitur ini tidak melakukan panggilan keluar ke layanan lain untuk mengirimkan data pelanggan. Mari kita lihat skenario Premium satu per satu untuk memahami pola komunikasi dan detail terkait keamanan yang relevan yang berkaitan dengannya.

Untuk melatih dan menerapkan model AutoML, Power BI menggunakan Azure AutoML SDK dan menjalankan semua pelatihan dalam kapasitas Power BI pelanggan. Selama perulangan pelatihan, Power BI memanggil eksperimen layanan Azure Pembelajaran Mesin untuk memilih model dan parameter hiper yang sesuai untuk perulangan saat ini. Dalam panggilan keluar ini, hanya metadata eksperimen yang relevan (misalnya, akurasi, algoritma ml, parameter algoritma, dll.) dari iterasi sebelumnya yang dikirim. Pelatihan AutoML menghasilkan model ONNX dan data laporan pelatihan yang kemudian disimpan dalam aliran data. Nantinya, pengguna Power BI kemudian dapat menerapkan model ML terlatih sebagai transformasi untuk mengoperalisasi model ML secara terjadwal. Untuk API TextAnalytics dan ImageTagging, Power BI tidak secara langsung memanggil API layanan CognitiveServices, melainkan menggunakan SDK internal untuk menjalankan API dalam kapasitas Power BI Premium. Saat ini API ini didukung dalam aliran data Power BI dan model semantik. Saat menulis model data di Power BI Desktop, pengguna hanya dapat mengakses fungsionalitas ini jika mereka memiliki akses ke ruang kerja Power BI Premium. Oleh karena itu, pelanggan diminta untuk menyediakan kredensial Microsoft Entra mereka.

Isolasi jaringan

Bagian ini menguraikan fitur keamanan tingkat lanjut di Power BI. Beberapa fitur memiliki persyaratan lisensi tertentu. Lihat bagian di bawah ini untuk detailnya.

Tag layanan

Tag layanan mewakili sekelompok awalan alamat IP dari layanan Azure tertentu. Ini membantu meminimalkan kompleksitas pembaruan yang sering terjadi pada aturan keamanan jaringan. Pelanggan dapat menggunakan tag layanan untuk menentukan kontrol akses jaringan pada Kelompok Keamanan Jaringan atau Azure Firewall. Pelanggan dapat menggunakan tag layanan sebagai pengganti alamat IP tertentu saat membuat aturan keamanan. Dengan menentukan nama tag layanan (seperti PowerBI) di bidang sumber atau tujuan (untuk API) yang sesuai dari aturan, pelanggan dapat mengizinkan atau menolak lalu lintas untuk layanan yang sesuai. Microsoft mengelola awalan alamat yang dicakup oleh tag layanan dan secara otomatis memperbarui tag layanan saat alamat berubah.

Integrasi Private Link

Jaringan Azure menyediakan fitur Azure Private Link yang memungkinkan Power BI menyediakan akses aman melalui titik akhir privat Azure Networking. Dengan Azure Private Link dan titik akhir privat, lalu lintas data dikirim secara privat menggunakan infrastruktur jaringan backbone Microsoft, dan dengan demikian data tidak melintasi Internet.

Private Link memastikan bahwa pengguna Power BI menggunakan backbone jaringan privat Microsoft saat membuka sumber daya di layanan Power BI.

Menggunakan Private Link dengan Power BI memberikan manfaat berikut:

• Private Link memastikan bahwa lalu lintas akan mengalir melalui backbone Azure ke titik akhir privat untuk sumber daya berbasis cloud Azure.
• Isolasi lalu lintas jaringan dari infrastruktur berbasis non-Azure, seperti akses lokal, akan mengharuskan pelanggan untuk mengonfigurasi ExpressRoute atau Virtual Private Network (VPN).

Lihat Tautan privat untuk mengakses Power BI untuk informasi tambahan.

Konektivitas VNet

Meskipun fitur integrasi Private Link menyediakan koneksi masuk yang aman ke Power BI, fitur konektivitas VNet memungkinkan konektivitas keluar yang aman dari Power BI ke sumber data dalam VNet.

Gateway VNet (dikelola Microsoft) menghilangkan overhead penginstalan dan pemantauan gateway data lokal untuk menyambungkan ke sumber data yang terkait dengan VNet. Namun, mereka masih mengikuti proses pengelolaan keamanan dan sumber data yang familier, seperti halnya gateway data lokal.

Berikut ini adalah gambaran umum tentang apa yang terjadi saat Anda berinteraksi dengan laporan Power BI yang tersambung ke sumber data dalam VNet menggunakan gateway VNet:

1. Layanan awan Power BI (atau salah satu layanan cloud lain yang didukung) memulai kueri dan mengirim kueri, detail sumber data, dan kredensial ke layanan Power Platform VNet (PP VNet).

2. Layanan PP VNet kemudian dengan aman menyuntikkan kontainer yang menjalankan gateway VNet ke subnet. Kontainer ini sekarang dapat terhubung ke layanan data yang dapat diakses dari dalam subnet ini.

3. Layanan PP VNet kemudian mengirim kueri, detail sumber data, dan kredensial ke gateway VNet.

4. Gateway VNet mendapatkan kueri dan menyambungkan ke sumber data dengan kredensial tersebut.

5. Kueri kemudian dikirim ke sumber data untuk dieksekusi.

6. Setelah eksekusi, hasilnya dikirim ke gateway VNet, dan layanan PP VNet dengan aman mendorong data dari kontainer ke layanan cloud Power BI.

Perwakilan layanan

Power BI mendukung penggunaan perwakilan layanan. Simpan kredensial perwakilan layanan apa pun yang digunakan untuk mengenkripsi atau mengakses Power BI di Key Vault, menetapkan kebijakan akses yang tepat ke vault, dan meninjau izin akses secara teratur.

Lihat Mengotomatiskan ruang kerja Premium dan tugas model semantik dengan perwakilan layanan untuk detail tambahan.

Microsoft Purview untuk Power BI

Perlindungan Informasi Microsoft Purview

Power BI terintegrasi secara mendalam dengan Perlindungan Informasi Microsoft Purview. Perlindungan Informasi Microsoft Purview memungkinkan organisasi memiliki satu solusi terintegrasi untuk klasifikasi, pelabelan, audit, dan kepatuhan di Seluruh Azure, Power BI, dan Office.

Saat perlindungan informasi diaktifkan di Power BI:

• Data sensitif, baik di layanan Power BI maupun di Power BI Desktop, dapat diklasifikasikan dan diberi label menggunakan label sensitivitas yang sama yang digunakan di Office dan di Azure.
• Kebijakan tata kelola dapat diberlakukan saat konten Power BI diekspor ke file Excel, PowerPoint, PDF, Word, atau .pbix , untuk membantu memastikan bahwa data dilindungi bahkan ketika meninggalkan Power BI.
• Sangat mudah untuk mengklasifikasikan dan melindungi file .pbix di Power BI Desktop, seperti yang dilakukan di aplikasi Excel, Word, dan PowerPoint. File dapat dengan mudah ditandai sesuai dengan tingkat sensitivitasnya. Bahkan lebih lanjut, mereka dapat dienkripsi jika berisi data rahasia bisnis, memastikan bahwa hanya pengguna yang berwenang yang dapat mengedit file-file ini.
• Buku kerja Excel secara otomatis mewarisi label sensitivitas saat tersambung ke Power BI (pratinjau), memungkinkan untuk mempertahankan klasifikasi end-to-end dan menerapkan perlindungan saat model semantik Power BI dianalisis di Excel.
• Label sensitivitas yang diterapkan ke laporan dan dasbor Power BI terlihat di aplikasi seluler Power BI iOS dan Android.
• Label sensitivitas tetap ada saat laporan Power BI disematkan di Teams, SharePoint, atau situs web yang aman. Ini membantu organisasi mempertahankan klasifikasi dan perlindungan saat ekspor saat menyematkan konten Power BI.
• Pewarisan label pada pembuatan konten baru di layanan Power BI memastikan bahwa label yang diterapkan ke model semantik atau datamart dalam layanan Power BI akan diterapkan ke konten baru yang dibuat di atas model semantik dan datamart tersebut.
• API pemindaian admin Power BI dapat mengekstrak label sensitivitas item Power BI, memungkinkan admin Power BI dan InfoSec memantau pelabelan di layanan Power BI dan menghasilkan laporan eksekutif.
• API admin Power BI memungkinkan tim pusat menerapkan label sensitivitas secara terprogram ke konten di layanan Power BI.
• Tim pusat dapat membuat kebijakan label wajib untuk menerapkan label pada konten baru atau yang diedit di Power BI.
• Tim pusat dapat membuat kebijakan label default untuk memastikan bahwa label sensitivitas diterapkan ke semua konten Power BI baru atau yang diubah.
• Pelabelan sensitivitas hilir otomatis di layanan Power BI memastikan bahwa ketika label pada model semantik atau datamart diterapkan atau diubah, label akan secara otomatis diterapkan atau diubah pada semua konten hilir yang terhubung ke model semantik atau datamart.

Untuk informasi selengkapnya, lihat Label sensitivitas di Power BI.

Kebijakan Pencegahan Kehilangan Data Microsoft Purview (DLP) untuk Power BI

Kebijakan DLP Microsoft Purview membantu organisasi mengurangi risiko kebocoran data bisnis sensitif dari Power BI. Kebijakan DLP membantu mereka memenuhi persyaratan kepatuhan peraturan pemerintah atau industri, seperti GDPR (Peraturan Perlindungan Data Umum Uni Eropa) atau CCPA (Undang-Undang Privasi Konsumen California) dan memastikan data mereka di Power BI dikelola.

Saat kebijakan DLP untuk Power BI disiapkan:

• Semua model semantik dalam ruang kerja yang ditentukan dalam kebijakan dievaluasi oleh kebijakan.
• Anda dapat mendeteksi kapan data sensitif diunggah ke dalam kapasitas Premium Anda. Kebijakan DLP dapat mendeteksi:
  • Label sensitivitas.
  • Jenis info sensitif. Lebih dari 260 jenis didukung. Deteksi jenis info sensitif bergantung pada pemindaian konten Microsoft Purview.
• Ketika Anda menemukan model semantik yang diidentifikasi sebagai sensitif, Anda dapat melihat tip kebijakan yang disesuaikan yang membantu Anda memahami apa yang harus Anda lakukan.
• Jika Anda adalah pemilik model semantik, Anda dapat mengambil alih kebijakan dan mencegah model semantik Anda diidentifikasi sebagai "sensitif" jika Anda memiliki alasan yang valid untuk melakukannya.
• Jika Anda adalah pemilik model semantik, Anda dapat melaporkan masalah dengan kebijakan jika Anda menyimpulkan bahwa jenis info sensitif telah diidentifikasi secara keliru.
• Mitigasi risiko otomatis, seperti pemberitahuan ke admin keamanan, dapat dipanggil.

Untuk informasi selengkapnya, lihat Kebijakan pencegahan kehilangan data untuk Fabric Power BI.

Aplikasi Microsoft Defender untuk Cloud untuk Power BI

Microsoft Defender untuk Cloud Apps adalah salah satu broker keamanan akses cloud terkemuka di dunia, yang dinamai sebagai pemimpin dalam Magic Quadrant Gartner untuk pasar broker keamanan akses cloud (CASB). Defender untuk Cloud Apps digunakan untuk mengamankan penggunaan aplikasi cloud. Ini memungkinkan organisasi untuk memantau dan mengontrol, secara real time, sesi Power BI berisiko seperti akses pengguna dari perangkat yang tidak dikelola. Administrator keamanan dapat menentukan kebijakan untuk mengontrol tindakan pengguna, seperti mengunduh laporan dengan informasi sensitif.

Dengan Defender untuk Cloud Apps, organisasi dapat memperoleh kemampuan DLP berikut:

• Atur kontrol real-time untuk memberlakukan sesi pengguna berisiko di Power BI. Misalnya, jika pengguna tersambung ke Power BI dari luar negara atau wilayah mereka, sesi dapat dipantau oleh kontrol real time Aplikasi Defender untuk Cloud, dan tindakan berisiko, seperti mengunduh data yang ditandai dengan label sensitivitas "Sangat Rahasia", dapat segera diblokir.
• Selidiki aktivitas pengguna Power BI dengan log aktivitas aplikasi Defender untuk Cloud. Log aktivitas aplikasi Defender untuk Cloud menyertakan aktivitas Power BI seperti yang diambil dalam log audit Office 365, yang berisi informasi tentang semua aktivitas pengguna dan admin, serta informasi label sensitivitas untuk aktivitas yang relevan seperti menerapkan, mengubah, dan menghapus label. Admin dapat memanfaatkan filter tingkat lanjut Defender untuk Cloud Apps dan tindakan cepat untuk penyelidikan masalah yang efektif.
• Buat kebijakan kustom untuk memperingatkan aktivitas pengguna yang mencurigakan di Power BI. Fitur kebijakan aktivitas Defender untuk Cloud Apps dapat dimanfaatkan untuk menentukan aturan kustom Anda sendiri, untuk membantu Anda mendeteksi perilaku pengguna yang menyimpang dari norma, dan bahkan mungkin bertindak atasnya secara otomatis, jika tampaknya terlalu berbahaya.
• Bekerja dengan deteksi anomali bawaan Defender untuk Cloud Apps. Kebijakan deteksi anomali aplikasi Defender untuk Cloud menyediakan analitik perilaku pengguna dan pembelajaran mesin di luar kotak sehingga Anda siap dari awal untuk menjalankan deteksi ancaman tingkat lanjut di seluruh lingkungan cloud Anda. Ketika kebijakan deteksi anomali mengidentifikasi perilaku yang mencurigakan, kebijakan tersebut memicu pemberitahuan keamanan.
• Peran admin Power BI di portal aplikasi Defender untuk Cloud. Defender untuk Cloud Apps menyediakan peran admin khusus aplikasi yang dapat digunakan untuk memberi admin Power BI izin yang mereka butuhkan untuk mengakses data yang relevan dengan Power BI di portal, seperti pemberitahuan, pengguna berisiko, log aktivitas, dan informasi terkait Power BI lainnya.

Lihat Menggunakan Kontrol Aplikasi Microsoft Defender untuk Cloud di Power BI untuk detail tambahan.

Pratinjau fitur keamanan

Bagian ini mencantumkan fitur yang direncanakan rilis hingga Maret 2021. Karena topik ini mencantumkan fitur yang mungkin belum dirilis, garis waktu pengiriman dapat berubah dan fungsionalitas yang diproyeksikan dapat dirilis lebih lambat dari Maret 2021, atau mungkin tidak dirilis sama sekali. Untuk informasi selengkapnya, tentang pratinjau, silakan tinjau Ketentuan Layanan Online.

Bawa Analitik Log Anda Sendiri (BYOLA)

Bring Your Own Log Analytics memungkinkan integrasi antara Power BI dan Azure Log Analytics. Integrasi ini mencakup mesin analitik tingkat lanjut Azure Log Analytics, bahasa kueri interaktif, dan konstruksi pembelajaran mesin bawaan.

Pertanyaan dan jawaban keamanan Power BI

Pertanyaan berikut adalah pertanyaan dan jawaban keamanan umum untuk Power BI. Ini diatur berdasarkan ketika ditambahkan ke laporan resmi ini, untuk memfasilitasi kemampuan Anda untuk dengan cepat menemukan pertanyaan dan jawaban baru ketika makalah ini diperbarui. Pertanyaan terbaru ditambahkan ke akhir daftar ini.

Bagaimana pengguna tersambung, dan mendapatkan akses ke sumber data saat menggunakan Power BI?

• Power BI mengelola kredensial ke sumber data untuk setiap pengguna untuk kredensial cloud atau untuk konektivitas melalui gateway pribadi. Sumber data yang dikelola oleh gateway data lokal dapat dibagikan di seluruh perusahaan dan izin ke sumber data ini dapat dikelola oleh Admin Gateway. Saat mengonfigurasi model semantik, pengguna diizinkan untuk memilih kredensial dari penyimpanan pribadi mereka atau menggunakan gateway data lokal untuk menggunakan kredensial bersama.

  Dalam kasus impor, pengguna membuat koneksi berdasarkan masuk pengguna dan mengakses data dengan kredensial. Setelah model semantik diterbitkan ke layanan Power BI, Power BI selalu menggunakan kredensial pengguna ini untuk mengimpor data. Setelah data diimpor, menampilkan data dalam laporan dan dasbor tidak mengakses sumber data yang mendasar. Power BI mendukung autentikasi akses menyeluruh untuk sumber data yang dipilih. Jika koneksi dikonfigurasi untuk menggunakan akses menyeluruh, kredensial pemilik model semantik digunakan untuk terhubung dengan sumber data.

  Untuk laporan yang terhubung dengan DirectQuery, sumber data terhubung langsung menggunakan kredensial yang telah dikonfigurasi sebelumnya, kredensial yang telah dikonfigurasi sebelumnya digunakan untuk menyambungkan ke sumber data saat pengguna melihat data. Jika sumber data tersambung langsung menggunakan akses menyeluruh, kredensial pengguna saat ini digunakan untuk menyambungkan ke sumber data saat pengguna melihat data. Saat menggunakan dengan akses menyeluruh, Keamanan Tingkat Baris (RLS) dan/atau keamanan tingkat objek (OLS) dapat diimplementasikan pada sumber data, dan ini memungkinkan pengguna untuk melihat data yang memiliki hak istimewa untuk diakses. Saat koneksi ke sumber data di cloud, autentikasi Microsoft Entra digunakan untuk akses menyeluruh; untuk sumber data lokal, Kerberos, SAML, dan MICROSOFT Entra ID didukung.

  Saat terhubung dengan Kerberos, UPN pengguna diteruskan ke gateway, dan menggunakan delegasi yang dibatasi Kerberos, pengguna ditiru dan terhubung ke sumber data masing-masing. SAML juga didukung pada sumber data Gateway untuk SAP Hana. Informasi selengkapnya tersedia dalam gambaran umum akses menyeluruh untuk gateway.

  Jika sumber data adalah Azure Analysis Services atau Analysis Services lokal dan Keamanan Tingkat Baris (RLS) dan/atau keamanan tingkat objek (OLS) dikonfigurasi, layanan Power BI akan menerapkan keamanan tingkat baris tersebut, dan pengguna yang tidak memiliki kredensial yang memadai untuk mengakses data yang mendasar (yang dapat berupa kueri yang digunakan di dasbor, laporan, atau artefak data lainnya) tidak akan melihat data yang hak istimewanya tidak memadai oleh pengguna.

  Keamanan Tingkat Baris dengan Power BI dapat digunakan untuk membatasi akses data untuk pengguna tertentu. Filter membatasi akses data di tingkat baris, dan Anda dapat menentukan filter dalam peran.

  Keamanan tingkat objek (OLS) dapat digunakan untuk mengamankan tabel atau kolom sensitif. Namun, tidak seperti keamanan tingkat baris, keamanan tingkat objek juga mengamankan nama objek dan metadata. Ini membantu mencegah pengguna berbahaya menemukan bahkan keberadaan objek tersebut. Tabel dan kolom aman dikaburkan dalam daftar bidang saat menggunakan alat pelaporan seperti Excel atau Power BI, dan selain itu, pengguna tanpa izin tidak dapat mengakses objek metadata aman melalui DAX atau metode lainnya. Dari sudut depan pengguna tanpa izin akses yang tepat, tabel dan kolom aman tidak ada.

  Keamanan tingkat objek, bersama dengan keamanan tingkat baris, memungkinkan keamanan tingkat perusahaan yang ditingkatkan pada laporan dan model semantik, memastikan bahwa hanya pengguna dengan izin yang diperlukan yang memiliki akses untuk melihat dan berinteraksi dengan data sensitif.

Bagaimana data ditransfer ke Power BI?

• Semua data yang diminta dan ditransmisikan oleh Power BI dienkripsi saat transit menggunakan HTTPS (kecuali ketika sumber data yang dipilih oleh pelanggan tidak mendukung HTTPS) untuk menyambungkan dari sumber data ke layanan Power BI. Koneksi aman dibuat dengan penyedia data, dan hanya setelah koneksi dibuat akan data melintasi jaringan.

Bagaimana laporan cache Power BI, dasbor, atau data model, dan apakah aman?

• Saat sumber data diakses, layanan Power BI mengikuti proses yang diuraikan di bagian Autentikasi ke Sumber Data sebelumnya dalam dokumen ini.

Apakah klien menyimpan data halaman web secara lokal?

• Saat klien browser mengakses Power BI, server web Power BI mengatur direktif Cache-Control ke tanpa penyimpanan. Direktif tanpa penyimpanan menginstruksikan browser untuk tidak menyimpan cache halaman web yang dilihat oleh pengguna, dan tidak menyimpan halaman web di folder cache klien.

Bagaimana dengan keamanan berbasis peran, berbagi laporan atau dasbor, dan koneksi data? Bagaimana cara kerjanya dalam hal akses data, tampilan dasbor, akses laporan, atau refresh?

• Untuk sumber data yang diaktifkan non-Role Level Security (RLS), jika dasbor, laporan, atau model data dibagikan dengan pengguna lain melalui Power BI, data kemudian tersedia untuk pengguna yang dibagikan untuk dilihat dan berinteraksi dengannya. Power BI tidak mengautentikasi ulang pengguna terhadap sumber data asli; setelah data diunggah ke Power BI, pengguna yang diautentikasi terhadap data sumber bertanggung jawab untuk mengelola pengguna dan grup lain mana yang dapat menampilkan data.

  Saat koneksi data dibuat ke sumber data berkemampu RLS, seperti sumber data Analysis Services, hanya data dasbor yang di-cache di Power BI. Setiap kali laporan atau model semantik ditampilkan atau diakses di Power BI yang menggunakan data dari sumber data berkemampuan RLS, layanan Power BI mengakses sumber data untuk mendapatkan data berdasarkan kredensial pengguna, dan jika ada izin yang memadai, data dimuat ke dalam laporan atau model data untuk pengguna tersebut. Jika autentikasi gagal, pengguna akan melihat kesalahan.

  Untuk informasi selengkapnya, lihat bagian Autentikasi ke Sumber Data sebelumnya dalam dokumen ini.

Pengguna kami terhubung ke sumber data yang sama sepanjang waktu, beberapa di antaranya memerlukan kredensial yang berbeda dari kredensial domain mereka. Bagaimana mereka dapat menghindari harus memasukkan kredensial ini setiap kali mereka membuat koneksi data?

• Power BI menawarkan Power BI Personal Gateway, yang merupakan fitur yang memungkinkan pengguna membuat kredensial untuk beberapa sumber data yang berbeda, lalu secara otomatis menggunakan kredensial tersebut saat kemudian mengakses masing-masing sumber data tersebut. Untuk informasi selengkapnya, lihat Power BI Personal Gateway.

Port mana yang digunakan oleh gateway data lokal dan gateway pribadi? Apakah ada nama domain yang perlu diizinkan untuk tujuan konektivitas?

• Jawaban terperinci untuk pertanyaan ini tersedia di tautan berikut: Port gateway

Saat bekerja dengan gateway data lokal, bagaimana kunci pemulihan digunakan dan di mana kunci tersebut disimpan? Bagaimana dengan manajemen kredensial yang aman?

• Selama penginstalan dan konfigurasi gateway, jenis administrator di Kunci Pemulihan gateway. Kunci Pemulihan tersebut digunakan untuk menghasilkan kunci konten AES yang kuat. Kunci asimetris RSA juga dibuat secara bersamaan.

  Kunci yang dihasilkan (RSA dan AES) disimpan dalam file yang terletak di komputer lokal. File itu juga dienkripsi. Konten file hanya dapat didekripsi oleh komputer Windows tertentu, dan hanya oleh akun layanan gateway tertentu.

  Saat pengguna memasukkan kredensial sumber data di antarmuka pengguna layanan Power BI, kredensial dienkripsi dengan kunci publik di browser. Gateway mendekripsi kredensial menggunakan kunci privat RSA dan mengenkripsi ulang dengan kunci konten AES sebelum data disimpan di layanan Power BI. Dengan proses ini, layanan Power BI tidak pernah memiliki akses ke data yang tidak terenkripsi.

Protokol komunikasi mana yang digunakan oleh gateway data lokal, dan bagaimana protokol tersebut diamankan?

• Gateway mendukung dua protokol komunikasi berikut:

  • AMQP 1.0 – TCP + TLS: Protokol ini memerlukan port 443, 5671-5672, dan 9350-9354 agar terbuka untuk komunikasi keluar. Protokol ini lebih disukai, karena memiliki overhead komunikasi yang lebih rendah.

  • HTTPS – WebSockets melalui HTTPS + TLS: Protokol ini hanya menggunakan port 443. WebSocket dimulai oleh satu pesan HTTP CONNECT. Setelah saluran dibuat, komunikasi pada dasarnya adalah TCP+TLS. Anda bisa memaksa gateway untuk menggunakan protokol ini dengan memodifikasi pengaturan yang dijelaskan dalam artikel gateway lokal.

Apa peran Azure CDN di Power BI?

• Seperti disebutkan sebelumnya, Power BI menggunakan Azure Content Delivery Network (CDN) untuk mendistribusikan konten dan file statis yang diperlukan secara efisien kepada pengguna berdasarkan lokal geografis. Untuk masuk ke detail lebih lanjut, layanan Power BI menggunakan beberapa CDN untuk mendistribusikan konten dan file statis yang diperlukan secara efisien kepada pengguna melalui Internet publik. File statis ini mencakup unduhan produk (seperti Power BI Desktop, gateway data lokal, atau aplikasi Power BI dari berbagai penyedia layanan independen), file konfigurasi browser yang digunakan untuk memulai dan membuat koneksi berikutnya dengan layanan Power BI, serta halaman masuk Power BI aman awal.

  Berdasarkan informasi yang diberikan selama koneksi awal ke layanan Power BI, browser pengguna menghubungi Azure CDN yang ditentukan (atau untuk beberapa file, WFE) untuk mengunduh kumpulan file umum yang ditentukan yang diperlukan untuk mengaktifkan interaksi browser dengan layanan Power BI. Halaman browser kemudian menyertakan token Microsoft Entra, informasi sesi, lokasi kluster back-end terkait, dan kumpulan file yang diunduh dari kluster Azure CDN dan WFE, selama sesi browser layanan Power BI.

Untuk visual Power BI, apakah Microsoft melakukan penilaian keamanan atau privasi kode visual kustom sebelum menerbitkan item ke Galeri?

• Tidak. Pelanggan bertanggung jawab untuk meninjau dan menentukan apakah kode visual kustom harus diandalkan. Semua kode visual kustom dioperasikan di lingkungan kotak pasir, sehingga kode yang salah dalam visual kustom tidak berdampak buruk pada layanan Power BI lainnya.

Apakah ada visual Power BI lain yang mengirim informasi di luar jaringan pelanggan?

• Ya. Visual Bing Maps dan ESRI mengirimkan data dari layanan Power BI untuk visual yang menggunakan layanan tersebut.

Untuk aplikasi templat, apakah Microsoft melakukan penilaian keamanan atau privasi aplikasi templat sebelum menerbitkan item ke Galeri?

• Tidak. Penerbit aplikasi bertanggung jawab atas konten sementara pelanggan bertanggung jawab untuk meninjau dan menentukan apakah akan mempercayai penerbit aplikasi templat.

Apakah ada aplikasi templat yang dapat mengirim informasi di luar jaringan pelanggan?

• Ya. Pelanggan bertanggung jawab untuk meninjau kebijakan privasi penerbit dan menentukan apakah akan menginstal aplikasi templat pada penyewa. Penerbit bertanggung jawab untuk memberi tahu pelanggan tentang perilaku dan kemampuan aplikasi.

Bagaimana dengan kedaulatan data? Dapatkah kami menyediakan penyewa di pusat data yang terletak di geografi tertentu, untuk memastikan data tidak meninggalkan batas negara atau wilayah?

• Beberapa pelanggan di geografi tertentu memiliki opsi untuk membuat penyewa di cloud nasional/regional, di mana penyimpanan dan pemrosesan data dipisahkan dari semua pusat data lainnya. Cloud Nasional/Regional memiliki jenis keamanan yang sedikit berbeda, karena wali data terpisah mengoperasikan layanan Power BI cloud nasional/regional atas nama Microsoft.

  Atau, pelanggan juga dapat menyiapkan penyewa di wilayah tertentu. Namun, penyewa tersebut tidak memiliki wali data terpisah dari Microsoft. Harga untuk cloud nasional/regional berbeda dari layanan Power BI komersial yang tersedia secara umum. Untuk informasi selengkapnya tentang ketersediaan layanan Power BI untuk cloud nasional/regional, lihat Cloud nasional/regional Power BI.

Bagaimana Microsoft memperlakukan koneksi untuk pelanggan yang memiliki langganan Power BI Premium? Apakah koneksi tersebut berbeda dari yang dibuat untuk layanan Power BI non-Premium?

• Koneksi yang dibuat untuk pelanggan dengan langganan Power BI Premium menerapkan proses otorisasi Microsoft Entra business-to-business (B2B), menggunakan ID Microsoft Entra untuk mengaktifkan kontrol dan otorisasi akses. Power BI menangani koneksi dari pelanggan Power BI Premium ke sumber daya Power BI Premium seperti halnya pengguna Microsoft Entra lainnya.

Bagaimana cara kerja autentikasi sisi server di WFE?

• Urutan autentikasi pengguna autentikasi sisi layanan terjadi seperti yang dijelaskan dalam langkah-langkah berikut, yang diilustrasikan dalam gambar yang mengikutinya.

1. Pengguna memulai koneksi ke layanan Power BI dari browser, baik dengan mengetikkan alamat Power BI di bilah alamat atau dengan memilih Masuk dari halaman pemasaran Power BI (https://powerbi.microsoft.com). Koneksi dibuat menggunakan TLS 1.2 dan HTTPS, dan semua komunikasi berikutnya antara browser dan layanan Power BI menggunakan HTTPS.

2. Azure Traffic Manager memeriksa catatan DNS pengguna untuk menentukan pusat data yang paling tepat (biasanya terdekat) tempat Power BI disebarkan, dan merespons DNS dengan alamat IP kluster WFE tempat pengguna harus dikirim.

3. WFE kemudian mengalihkan pengguna ke halaman masuk Microsoft Online Services.

4. Setelah pengguna diautentikasi, halaman masuk mengalihkan pengguna ke kluster WFE layanan Power BI terdekat yang ditentukan sebelumnya dengan kode autentikasi.

5. Kluster WFE memeriksa dengan ID Microsoft Entra untuk mendapatkan token keamanan Microsoft Entra dengan menggunakan kode autentikasi. Saat MICROSOFT Entra ID mengembalikan autentikasi pengguna yang berhasil dan mengembalikan token keamanan Microsoft Entra, kluster WFE berkonsultasi dengan Layanan Global Power BI, yang mempertahankan daftar penyewa dan lokasi kluster back-end Power BI mereka dan menentukan kluster layanan back-end Power BI mana yang berisi penyewa pengguna. Kluster WFE kemudian mengembalikan halaman aplikasi ke browser pengguna dengan informasi sesi, akses, dan perutean yang diperlukan untuk operasinya.

6. Sekarang, ketika browser klien memerlukan data pelanggan, ia akan mengirim permintaan ke alamat kluster back-end dengan token akses Microsoft Entra di header Otorisasi. Kluster back-end Power BI membaca token akses Microsoft Entra dan memvalidasi tanda tangan untuk memastikan bahwa identitas untuk permintaan tersebut valid. Token akses Microsoft Entra akan memiliki tanggal kedaluwarsa yang ditetapkan sesuai dengan kebijakan Microsoft Entra, dan untuk mempertahankan sesi saat ini Klien Power BI di browser pengguna akan membuat permintaan berkala untuk memperbarui token akses sebelum kedaluwarsa.

Sumber Daya Tambahan:

Untuk informasi selengkapnya tentang Power BI, lihat sumber daya berikut ini.

• Memulai dengan Power BI Desktop
• Power BI REST API - Gambaran Umum
• referensi API Power BI
• Gateway data lokal
• Cloud Nasional/Regional Power BI
• Power BI Premium
• Gambaran umum akses menyeluruh (SSO) untuk gateway di Power BI