Οδηγίες ασφάλειας σε επίπεδο γραμμών (RLS) στο Power BI Desktop

Αυτό το άρθρο απευθύνεται σε εσάς ως δημιουργός μοντέλων δεδομένων που εργάζεται με το Power BI Desktop. Περιγράφει καλές πρακτικές σχεδίασης για την επιβολή ασφάλειας σε επίπεδα γραμμών (RLS) στα μοντέλα δεδομένων σας.

Είναι σημαντικό να κατανοήσετε ότι το RLS φιλτράρει τις γραμμές πίνακα. Δεν μπορούν να ρυθμιστούν για να περιορίσουν την πρόσβαση σε αντικείμενα μοντέλου, συμπεριλαμβανομένων πινάκων, στηλών ή μετρήσεων.

Σημείωμα

Αυτό το άρθρο δεν περιγράφει το RLS ή τον τρόπο ρύθμισης του. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Περιορισμός πρόσβασης δεδομένων με ασφάλεια σε επίπεδο γραμμών (RLS) για το Power BI Desktop.

Επίσης, δεν καλύπτει την επιβολή RLS σε δυναμικές συνδέσεις σε μοντέλα εξωτερικής φιλοξενίας με Υπηρεσίες Ανάλυσης του Azure ή Υπηρεσίες ανάλυσης του SQL Server. Σε αυτές τις περιπτώσεις, το RLS επιβάλλεται από τις Υπηρεσίες ανάλυσης. Όταν το Power BI συνδέεται με καθολική σύνδεση (SSO), οι Υπηρεσίες ανάλυσης θα επιβάλλουν το RLS (εκτός εάν ο λογαριασμός έχει δικαιώματα διαχειριστή).

Δημιουργία ρόλων

Είναι δυνατή η δημιουργία πολλών ρόλων. Όταν εξετάζετε τις ανάγκες δικαιωμάτων για έναν μεμονωμένο χρήστη αναφοράς, προσπαθήστε να δημιουργήσετε έναν μοναδικό ρόλο που εκχωρεί όλα αυτά τα δικαιώματα, αντί για μια σχεδίαση όπου ένας χρήστης αναφοράς θα είναι μέλος πολλών ρόλων. Αυτό συμβαίνει επειδή ένας χρήστης αναφοράς θα μπορούσε να αντιστοιχηθεί σε πολλούς ρόλους, είτε απευθείας χρησιμοποιώντας τον λογαριασμό χρήστη του είτε έμμεσα ως μέλος σε ομάδα ασφαλείας. Πολλές αντιστοιχίσεις ρόλων μπορεί να οδηγήσουν σε μη αναμενόμενα αποτελέσματα.

Όταν ένας χρήστης αναφοράς αντιστοιχίζεται σε πολλούς ρόλους, τα φίλτρα RLS γίνονται πρόσθετα. Αυτό σημαίνει ότι οι χρήστες αναφοράς μπορούν να βλέπουν γραμμές πίνακα που αντιπροσωπεύουν την ένωση αυτών των φίλτρων. Επιπλέον, σε ορισμένα σενάρια δεν είναι δυνατό να εγγυηθείτε ότι ένας χρήστης αναφοράς δεν βλέπει γραμμές σε έναν πίνακα. Επομένως, σε αντίθεση με τα δικαιώματα που εφαρμόζονται σε αντικείμενα βάσης δεδομένων SQL Server (και άλλα μοντέλα δικαιωμάτων), η αρχή "μία φορά απορρίπτεται πάντα" δεν ισχύει.

Εξετάστε ένα μοντέλο με δύο ρόλους: Ο πρώτος ρόλος, με την ονομασία Εργαζόμενοι, περιορίζει την πρόσβαση σε όλες τις γραμμές πίνακα Payroll χρησιμοποιώντας την ακόλουθη παράσταση κανόνα:

FALSE()

Σημείωμα

Ένας κανόνας δεν θα επιστρέψει γραμμές πίνακα όταν η παράθεση καταλήγει σε FALSE.

Ωστόσο, ένας δεύτερος ρόλος, με την ονομασία Διευθυντές, επιτρέπει την πρόσβαση σε όλες τις γραμμές του πίνακα Payroll χρησιμοποιώντας την ακόλουθη παράσταση κανόνα:

TRUE()

Προσοχή: Εάν ένας χρήστης αναφοράς αντιστοιχίζει και τους δύο ρόλους, θα δει όλες τις γραμμές του πίνακα Μισθοδοσία .

Βελτιστοποίηση RLS

Το RLS λειτουργεί αυτόματα εφαρμόζοντας φίλτρα σε κάθε ερώτημα DAX και αυτά τα φίλτρα μπορεί να έχουν αρνητικές επιπτώσεις στις επιδόσεις ερωτημάτων. Επομένως, το αποτελεσματικό RLS καταλήγει στην καλή σχεδίαση μοντέλου. Είναι σημαντικό να ακολουθείτε τις οδηγίες σχεδίασης μοντέλου, όπως περιγράφεται στα παρακάτω άρθρα:

• Κατανοήστε το αστεροειδές σχήμα και τη σημασία του για το Power BI
• Όλα τα άρθρα με οδηγίες για σχέσεις που βρίσκονται στην τεκμηρίωση οδηγιών για το Power BI

Σε γενικές γραμμές, συχνά είναι πιο αποτελεσματικό να επιβάλλετε φίλτρα RLS σε πίνακες διαστάσεων και όχι σε πίνακες στοιχείων. Επίσης, βασιστείτε σε καλά σχεδιασμένες σχέσεις για να εξασφαλίσετε ότι τα φίλτρα RLS μεταδίδονται σε άλλους πίνακες μοντέλων. Τα φίλτρα RLS μεταδίδονται μόνο μέσω ενεργών σχέσεων. Επομένως, αποφύγετε τη χρήση της συνάρτησης DAX LOOKUPVALUE όταν οι σχέσεις μοντέλων μπορούν να επιτύχουν το ίδιο αποτέλεσμα.

Κάθε φορά που επιβάλλονται φίλτρα RLS σε πίνακες DirectQuery και υπάρχουν σχέσεις με άλλους πίνακες DirectQuery, φροντίστε να βελτιστοποιήσετε τη βάση δεδομένων προέλευσης. Μπορεί να περιλαμβάνει τη σχεδίαση κατάλληλων ευρετηρίων ή τη χρήση μόνιμων υπολογιζόμενων στηλών. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Οδηγίες μοντέλου DirectQuery στο Power BI Desktop.

Μέτρηση επίδρασης RLS

Είναι δυνατή η μέτρηση της επίδρασης στις επιδόσεις των φίλτρων RLS στο Power BI Desktop χρησιμοποιώντας Ανάλυση απόδοσης. Πρώτα, προσδιορίστε τις διάρκειες ερωτημάτων απεικόνισης αναφοράς όταν δεν επιβάλλεται RLS. Στη συνέχεια, χρησιμοποιήστε την εντολή Προβολή ως στην καρτέλα κορδέλας Μοντελοποίηση για να επιβάλετε το RLS και να προσδιορίσετε και συγκρίνετε διάρκειες ερωτημάτων.

Ρύθμιση παραμέτρων αντιστοιχίσεων ρόλων

Μετά τη δημοσίευση στο Power BI, πρέπει να αντιστοιχίζετε τα μέλη σε ρόλους σημασιολογικού μοντέλου (παλαιότερα γνωστό ως σύνολο δεδομένων). Μόνο οι κάτοχοι σημασιολογικών μοντέλων ή οι διαχειριστές χώρων εργασίας μπορούν να προσθέτουν μέλη σε ρόλους. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Ασφάλεια σε επίπεδο γραμμών (RLS) με το Power BI (Διαχείριση ασφάλειας στο μοντέλο σας).

Τα μέλη μπορεί να είναι λογαριασμοί χρηστών, ομάδες ασφαλείας, ομάδες διανομής ή ομάδες με δυνατότητα αλληλογραφίας. Όποτε είναι εφικτό, συνιστούμε να αντιστοιχίζετε ομάδες ασφαλείας σε ρόλους σημασιολογικού μοντέλου. Περιλαμβάνει τη διαχείριση των μελών ομάδας ασφαλείας στο Microsoft Entra ID (παλαιότερα γνωστό ως Azure Active Directory). Πιθανώς, αναθέτει την εργασία στους διαχειριστές του δικτύου σας.

Επικύρωση ρόλων

Δοκιμάστε κάθε ρόλο για να εξασφαλίσετε ότι φιλτράρει σωστά το μοντέλο. Πραγματοποιείται εύκολα χρησιμοποιώντας την εντολή Προβολή ως στην καρτέλα κορδέλας Μοντελοποίηση.

Όταν το μοντέλο έχει δυναμικούς κανόνες χρησιμοποιώντας τη συνάρτηση DAX USERNAME , φροντίστε να ελέγξετε για αναμενόμενες και μη αναμενόμενες τιμές. Κατά την ενσωμάτωση περιεχομένου Power BI, ειδικά χρησιμοποιώντας το σενάριο ενσωμάτωση για τους πελάτες σας, η λογική εφαρμογής μπορεί να διαβιβάσει οποιαδήποτε τιμή ως ένα αποτελεσματικό όνομα χρήστη ταυτότητας. Όποτε είναι εφικτό, εξασφαλίστε ότι τυχαίες ή κακόβουλες τιμές έχουν ως αποτέλεσμα φίλτρα που δεν επιστρέφουν γραμμές.

Εξετάστε ένα παράδειγμα χρήσης του Power BI Embedded, όπου η εφαρμογή μεταβιβάζει τον ρόλο εργασίας του χρήστη ως το ισχύον όνομα χρήστη: Είναι είτε "Διευθυντής" είτε "Εργαζόμενος". Οι διευθυντές μπορούν να βλέπουν όλες τις γραμμές, αλλά οι εργαζόμενοι μπορούν να βλέπουν μόνο γραμμές όπου η τιμή στήλης Τύπος είναι "Εσωτερική".

Ορίζεται η ακόλουθη παράσταση κανόνα:

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    TRUE()
)

Το πρόβλημα με αυτή την παράσταση κανόνα είναι ότι όλες οι τιμές, με την εξαίρεση "Εργαζόμενος", επιστρέφουν όλες τις γραμμές πίνακα. Επομένως, μια τυχαία τιμή, όπως "Εργαζόμενος", επιστρέφει τυχαία όλες τις γραμμές πίνακα. Επομένως, είναι πιο ασφαλές να συντάσσετε μια παράσταση που ελέγχει για κάθε αναμενόμενη τιμή. Στην ακόλουθη βελτιωμένη παράσταση κανόνα, μια μη αναμενόμενη τιμή έχει ως αποτέλεσμα ο πίνακας να μην επιστρέφει γραμμές.

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    IF(
        USERNAME() = "Manager",
        TRUE(),
        FALSE()
    )
)

Σχεδίαση μερικού RLS

Ορισμένες φορές, οι υπολογισμοί χρειάζονται τιμές που δεν περιορίζονται από τα φίλτρα RLS. Για παράδειγμα, μια αναφορά μπορεί να χρειαστεί να εμφανίσει μια αναλογία των εσόδων που κερδήθηκαν για την περιοχή πωλήσεων του χρήστη αναφοράς ως προς όλα τα έσοδα που κερδήθηκαν.

Παρόλο που δεν είναι δυνατό μια παράσταση DAX να παρακάμψει το RLS, στην πραγματικότητα, δεν μπορεί καν να προσδιορίσει αν επιβάλλεται RLS, μπορείτε να χρησιμοποιήσετε έναν πίνακα σύνοψης μοντέλου. Ζητείται από τον πίνακα μοντέλου σύνοψης να ανακτήσει έσοδα για "όλες τις περιοχές" και δεν περιορίζεται από φίλτρα RLS.

Ας δούμε πώς μπορείτε να υλοποιήσετε αυτήν την απαίτηση σχεδίασης. Εξετάστε πρώτα την παρακάτω σχεδίαση μοντέλου:

Το μοντέλο αποτελείται από τέσσερις πίνακες:

• Ο πίνακας Πωλητής αποθηκεύει μία γραμμή ανά πωλητή. Περιλαμβάνει τη στήλη EmailAddress , η οποία αποθηκεύει τη διεύθυνση ηλεκτρονικού ταχυδρομείου για κάθε πωλητή. Αυτός ο πίνακας είναι κρυφός.
• Ο πίνακας Πωλήσεις αποθηκεύει μία γραμμή ανά παραγγελία. Περιλαμβάνει τη μέτρηση Έσοδα % Όλων των περιοχών , η οποία έχει σχεδιαστεί για να επιστρέφει μια αναλογία εσόδων της περιοχής του χρήστη αναφοράς προς τα έσοδα όλων των περιοχών.
• Ο πίνακας Ημερομηνία αποθηκεύει μία γραμμή ανά ημερομηνία και επιτρέπει φιλτράρισμα και ομαδοποίηση έτους και μήνα.
• Το SalesRevenueSummary είναι ένας υπολογιζόμενος πίνακας. Αποθηκεύει τα συνολικά έσοδα για κάθε ημερομηνία παραγγελίας. Αυτός ο πίνακας είναι κρυφός.

Η ακόλουθη παράσταση ορίζει τον υπολογιζόμενο πίνακα SalesRevenueSummary :

SalesRevenueSummary =
SUMMARIZECOLUMNS(
    Sales[OrderDate],
    "RevenueAllRegion", SUM(Sales[Revenue])
)

Σημείωμα

Ένας πίνακας συνάθροισης μπορεί να επιτύχει την ίδια απαίτηση σχεδίασης.

Ο ακόλουθος κανόνας RLS εφαρμόζεται στον πίνακα Salesperson :

[EmailAddress] = USERNAME()

Καθεμία από τις τρεις σχέσεις μοντέλου περιγράφεται στον παρακάτω πίνακα:

Σχέση	Περιγραφή
	Υπάρχει μια σχέση πολλά-προς-πολλά μεταξύ των πινάκων Πωλητής και Πωλήσεις . Ο κανόνας RLS φιλτράρει τη στήλη EmailAddress του κρυφού πίνακα Salesperson χρησιμοποιώντας τη συνάρτηση DAX USERNAME . Η τιμή στήλης Περιοχή (για τον χρήστη αναφοράς) μεταδίδεται στον πίνακα Πωλήσεις .
	Υπάρχει μια σχέση "ένα-προς-πολλά" μεταξύ των πινάκων Ημερομηνία και Πωλήσεις .
	Υπάρχει μια σχέση "ένα-προς-πολλά" μεταξύ των πινάκων Date και SalesRevenueSummary .

Η ακόλουθη παράσταση ορίζει τη μέτρηση % εσόδων όλων των περιοχών :

Revenue % All Region =
DIVIDE(
    SUM(Sales[Revenue]),
    SUM(SalesRevenueSummary[RevenueAllRegion])
)

Σημείωμα

Φροντίστε να αποφύγετε την αποκάλυψη ευαίσθητων δεδομένων. Εάν υπάρχουν μόνο δύο περιοχές σε αυτό το παράδειγμα, τότε θα είναι δυνατό για έναν χρήστη αναφοράς να υπολογίσει τα έσοδα για την άλλη περιοχή.

Πότε πρέπει να αποφύγετε τη χρήση RLS

Ορισμένες φορές είναι λογικό να αποφύγετε τη χρήση RLS. Εάν έχετε μόνο μερικούς απλοϊκούς κανόνες RLS που εφαρμόζουν στατικά φίλτρα, εξετάστε τη δημοσίευση πολλών σημασιολογικών μοντέλων. Κανένα από τα σημασιολογικά μοντέλα δεν ορίζει ρόλους καθώς κάθε μοντέλο σημασιολογίας περιέχει δεδομένα για ένα συγκεκριμένο κοινό χρήστη αναφοράς, το οποίο έχει τα ίδια δικαιώματα δεδομένων. Στη συνέχεια, δημιουργήστε έναν χώρο εργασίας ανά κοινό και εκχωρήστε δικαιώματα πρόσβασης στον χώρο εργασίας ή την εφαρμογή.

Για παράδειγμα, μια εταιρεία που έχει μόνο δύο περιοχές πωλήσεων αποφασίζει να δημοσιεύσει ένα μοντέλο σημασιολογίας για κάθε περιοχή πωλήσεων σε διαφορετικούς χώρους εργασίας. Τα σημασιολογικά μοντέλα δεν επιβάλλουν RLS. Ωστόσο, χρησιμοποιούν παραμέτρους ερωτήματος για το φιλτράρισμα δεδομένων προέλευσης. Με αυτόν τον τρόπο, το ίδιο μοντέλο δημοσιεύεται σε κάθε χώρο εργασίας, απλά έχουν διαφορετικές τιμές παραμέτρων μοντέλου σημασιολογίας. Στους πωλητές εκχωρείται πρόσβαση σε έναν μόνο από τους χώρους εργασίας (ή δημοσιευμένες εφαρμογές).

Υπάρχουν πολλά πλεονεκτήματα που σχετίζονται με την αποφυγή RLS:

• Βελτιωμένες επιδόσεις ερωτήματος: Μπορεί να οδηγήσει σε βελτιωμένες επιδόσεις λόγω λιγότερων φίλτρων.
• Μικρότερα μοντέλα: Αν και οδηγεί σε περισσότερα μοντέλα, είναι μικρότερα σε μέγεθος. Τα μικρότερα μοντέλα μπορούν να βελτιώσουν την ανταπόκριση των ερωτημάτων και της ανανέωσης δεδομένων, ιδιαίτερα εάν οι εκχωρημένοι πόροι φιλοξενίας βιώνουν πίεση στους πόρους. Επίσης, είναι πιο εύκολο να διατηρείτε τα μεγέθη μοντέλων κάτω από τα όρια μεγέθους που επιβάλλουν οι εκχωρημένοι πόροι σας. Τέλος, είναι ευκολότερο να εξισορροπήσετε τους φόρτους εργασίας σε διαφορετικούς εκχωρημένους πόρους, καθώς μπορείτε να δημιουργήσετε χώρους εργασίας ή να μετακινήσετε χώρους εργασίας σε διαφορετικούς εκχωρημένους πόρους.
• Πρόσθετες δυνατότητες: Μπορούν να χρησιμοποιηθούν δυνατότητες Power BI που δεν λειτουργούν με το RLS, όπως η Δημοσίευση στο web.

Ωστόσο, υπάρχουν μειονεκτήματα που σχετίζονται με την αποφυγή RLS:

• Πολλοί χώροι εργασίας: Απαιτείται ένας χώρος εργασίας για κάθε κοινό χρήστη αναφοράς. Εάν δημοσιεύονται εφαρμογές, αυτό σημαίνει επίσης ότι υπάρχει μία εφαρμογή ανά κοινό χρήστη αναφοράς.
• Αναπαραγωγή περιεχομένου: Πρέπει να δημιουργηθούν αναφορές και πίνακες εργαλείων σε κάθε χώρο εργασίας. Απαιτεί περισσότερη προσπάθεια και χρόνο για ρύθμιση και συντήρηση.
• Χρήστες υψηλών προνομίων: Οι χρήστες υψηλών προνομίων, οι οποίοι ανήκουν σε πολλά κοινά χρηστών αναφοράς, δεν μπορούν να δουν μια ενοποιημένη προβολή των δεδομένων. Θα χρειαστεί να ανοίξουν πολλές αναφορές (από διαφορετικούς χώρους εργασίας ή εφαρμογές).

Αντιμετώπιση προβλημάτων RLS

Εάν το RLS παράγει μη αναμενόμενα αποτελέσματα, ελέγξτε για τα ακόλουθα προβλήματα:

• Υπάρχουν λανθασμένες σχέσεις μεταξύ πινάκων μοντέλων, όσον αφορά τις αντιστοιχίσεις στηλών και τις κατευθύνσεις φίλτρου. Να θυμάστε ότι τα φίλτρα RLS μεταδίδονται μόνο μέσω ενεργών σχέσεων.
• Η ιδιότητα σχέσης Εφαρμογή φίλτρων ασφαλείας και στις δύο κατευθύνσεις δεν έχει οριστεί σωστά. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Οδηγίες για τις σχέσεις αμφίδρομης κατεύθυνσης.
• Οι πίνακες δεν περιέχουν δεδομένα.
• Φορτώνονται λανθασμένες τιμές στους πίνακες.
• Ο χρήστης αντιστοιχίζεται σε πολλούς ρόλους.
• Το μοντέλο περιλαμβάνει πίνακες συνάθροισης και οι κανόνες RLS δεν φιλτράρουν συναθροίσεις και λεπτομέρειες με συνέπεια. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Χρήση συναθροίσεων στο Power BI Desktop (RLS για συναθροίσεις).

Όταν ένας συγκεκριμένος χρήστης δεν μπορεί να δει δεδομένα, αυτό μπορεί να οφείλεται στο ότι το UPN του δεν έχει αποθηκευτεί ή έχει καταχωρηθεί λανθασμένα. Μπορεί να συμβεί απότομα καθώς ο λογαριασμός χρήστη του έχει αλλάξει ως αποτέλεσμα μιας αλλαγής ονόματος.

Φιλοδώρημα

Για σκοπούς δοκιμής, προσθέστε μια μέτρηση που επιστρέφει τη συνάρτηση DAX USERNAME . Μπορείς να το ονομάσεις "Ποιος είμαι". Στη συνέχεια, προσθέστε τη μέτρηση σε μια απεικόνιση κάρτας σε μια αναφορά και δημοσιεύστε τη στο Power BI.

Οι δημιουργοί και οι καταναλωτές με μόνο δικαίωμα ανάγνωσης στο μοντέλο σημασιολογίας θα μπορούν να προβάλλουν μόνο τα δεδομένα που επιτρέπεται να βλέπουν (με βάση την αντιστοίχιση ρόλων RLS).

Όταν ένας χρήστης προβάλει μια αναφορά είτε σε έναν χώρο εργασίας είτε σε μια εφαρμογή, το RLS μπορεί να επιβληθεί ή όχι ανάλογα με τα δικαιώματα του μοντέλου σημασιολογίας. Για αυτόν τον λόγο, είναι σημαντικό οι καταναλωτές και οι δημιουργοί περιεχομένου να διαθέτουν δικαιώματα ανάγνωσης μόνο στο υποκείμενο σημασιολογικό μοντέλο όταν πρέπει να επιβληθεί RLS. Για λεπτομέρειες σχετικά με τους κανόνες δικαιωμάτων που καθορίζουν εάν επιβάλλεται RLS, ανατρέξτε στο άρθρο Σχεδιασμός ασφάλειας καταναλωτή αναφοράς.

Σχετικό περιεχόμενο

Για περισσότερες πληροφορίες σχετικά με αυτό το άρθρο, ανατρέξτε στους παρακάτω πόρους:

• Ασφάλεια σε επίπεδο γραμμών (RLS) με το Power BI
• Περιορισμός πρόσβασης σε δεδομένα με την ασφάλεια σε επίπεδο γραμμών (RLS) για το Power BI Desktop
• Σχέσεις μοντέλων στο Power BI Desktop
• Σχεδιασμός υλοποίησης Power BI: Σχεδιασμός ασφάλειας καταναλωτών αναφοράς
• Ερωτήσεις; Δοκιμάστε να ρωτήσετε τον Κοινότητα Power BI
• Προτάσεις? Συνεισφέρετε ιδέες για τη βελτίωση του Power BI