Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Sicurezza a livello di riga in Power BI e Fabric: come DAX, ruoli e gruppi decidono davvero chi vede cosa (Doppiaggio IA)

Transcript

Sicurezza a livello di riga in Power BI e Fabric: come DAX, ruoli e gruppi decidono davvero chi vede cosa (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Pronto per dieci giorni di Microsoft 365? Pilot, intelligenza artificiale,
0:04
Speaker 2: Azure e le persone che stanno plasmando il futuro del lavoro?
0:08
Speaker 2: A gennaio torna M365Con e ci stiamo espandendo. Unisciti a
0:13
Speaker 2: noi per sessioni live, dimostrazioni pratiche e conoscenze pratiche da
0:16
Speaker 2: parte di MVP ed esperti del settore di tutto il mondo.
0:18
Speaker 2: Nessuna slide generica, nessun termine di moda infinito. Stiamo affrontando
0:22
Speaker 2: le vere sfide. Copilot Studio, agenti di intelligenza artificiale, Fabric, sicurezza,
0:27
Speaker 2: governance e automazione. Che tu sia un professionista IT, uno
0:31
Speaker 2: sviluppatore o un leader aziendale, ci sono sessioni pensate per te.
0:35
Speaker 2: Con 10 giorni interi puoi esplorare più tecnologie e connetterti
0:38
Speaker 2: con una community globale. Guarda la diretta e porta spunti
0:42
Speaker 2: pratici alla tua organizzazione. Gennaio 2027, 10 giorni, una community Microsoft.
0:49
Speaker 2: Le registrazioni sono aperte ora. Vai subito a casa tua.
0:54
Speaker 2: Questo è M365con. net. it iscriviti ora su m365con. net e ci vediamo
1:03
Speaker 2: in diretta gennaio T6
1:05
Speaker 3: ma hai chiesto chi può effettivamente vedere i tuoi dati
1:07
Speaker 3: in Power BI? attenzione spoiler non è così privato come
1:09
Speaker 3: potresti pensare a meno che tu non padronigi la sicurezza
1:11
Speaker 3: a livello di riga in questo episodio non ci limitiamo
1:14
Speaker 3: a spuntare la casella RLS ma analizziamo le parti in
1:16
Speaker 3: movimento le definizioni di ruoli le espressioni DAX che decidono
1:19
Speaker 3: silenziosamente chi vede cosa la maggior parte delle persone si
1:22
Speaker 3: ferma alla configurazione ma ti mostreremo come ogni decisione si
1:25
Speaker 3: collega in modo che i tuoi dati non siano solo
1:27
Speaker 3: bloccati ma siano progettati per la sicurezza Perché la sicurezza
1:31
Speaker 3: a livello di riga è un sistema, non una casella
1:32
Speaker 3: di controllo. Se sei abituato a bloccare un foglio di
1:35
Speaker 3: calcolo sensibile inserendo una password, sai già che c'è un
1:38
Speaker 3: divario tra ciò che intendi e ciò che protegge effettivamente
1:40
Speaker 3: i tuoi dati. Power BI con sicurezza a livello di
1:44
Speaker 3: riga può sembrare esattamente lo stesso. Premi il pulsante di
1:47
Speaker 3: attivazione e blascia disattivazione RLS, segni un paio di ruoli,
1:49
Speaker 3: pensi di aver risolto il problema. Ma la realtà è diversa.
1:52
Speaker 3: I dati sensibili trovano una via d'uscita quando quelle connessioni
1:54
Speaker 3: tra ruoli, filtri e utenti non vengono mappate attentamente. Le
1:58
Speaker 3: persone veramente parlano delle volte in cui un membro del
2:00
Speaker 3: team di vendita ha aperto una dashboard e si è
2:02
Speaker 3: ritrovato con una dashboard e si è ritrovato con una
2:03
Speaker 3: visione chiara di numeri che non avrebbe mai dovuto vedere.
2:06
Speaker 3: Ma succede, e quasi sempre, si parte dal presupposto che
2:08
Speaker 3: RLS sia solo un'altra casella da spuntare durante la configurazione.
2:12
Speaker 3: Mettiamoci nei panni di qualcuno che ha concesso l'accesso alla
2:14
Speaker 3: dashboard pensando di dare potere a un collega. Sembra il knockover.
2:19
Speaker 3: Ma in troppe organizzazioni l'accesso a una dashboard equivale all'accesso
2:22
Speaker 3: a tutto ciò che sta dietro le quinte. Ho visto
2:24
Speaker 3: ambienti in cui un singolo ruolo di responsabile globale ha
2:27
Speaker 3: consentito accidentalmente a utenti junior di consultare dati riservati da
2:29
Speaker 3: risorse umane, solo perché la denominazione non corrispondeva alla realtà.
2:33
Speaker 3: Non si tratta nemmeno di un caso isolato. È più
2:35
Speaker 3: vicino alla regola che all'eccezione, soprattutto quando un'azienda è in
2:37
Speaker 3: crescita e le dashboard si moltiplicano. Tutti vogliono muoversi velocemente,
2:41
Speaker 3: ma quando ci si muove senza una struttura. Si lasciano
2:44
Speaker 3: dietro piccole lacune che possano trasformarsi in enormi lacune durante
2:46
Speaker 3: un audit. Sulla carta RLS non potrebbe sembrare più semplice.
2:50
Speaker 3: Crea un ruolo, magari chiamalo vendite, aggiunge un filtro come
2:53
Speaker 3: regione uguale USA e associa gli utenti a esso. Ma
2:56
Speaker 3: dietro ogni menu a discesa e casella di controllo in
2:58
Speaker 3: Power BI c'è un sistema che prende decisioni su quali
3:00
Speaker 3: dati devono essere trasferiti e dove. Se perdi una relazione
3:03
Speaker 3: a un filtro, non catturano nuove origini e dati, non
3:06
Speaker 3: è solo un errore tecnico, è un incidente di sicurezza
3:09
Speaker 3: in attesa di accadere. Non lo saprai finché qualcuno non
3:12
Speaker 3: inciampa su dati che non dovrebbe vedere, e a volte
3:15
Speaker 3: nemmeno in quel caso. Ecco perché queste piccole mancanze sono
3:17
Speaker 3: così difficili da individuare. non sono dotate di campanelle d'allarme,
3:20
Speaker 3: e gli Audi standard spesso non vengono esaminati abbastanza in
3:22
Speaker 3: profondità per notarli. Ciò che viene trascurato è quanto siano
3:26
Speaker 3: strettamente commessi i componenti RLS. La maggior parte dei tutorial
3:30
Speaker 3: semplifica la configurazione guidandoti attraverso la creazione di ruoli e
3:33
Speaker 3: nozioni di base sui filtri. Ti mostreranno come mappare gli
3:36
Speaker 3: utenti e selezionare una casella d'inteprima, ma quasi nessuno si
3:38
Speaker 3: soffermerà a chiedersi in che modo un filtro nella tabella
3:40
Speaker 3: delle vendite influisce ad esempio su una tabella dei territori correlati.
3:44
Speaker 3: Ogni parte della logica in RLS si ripercuote sulle altre, assegnazioni,
3:48
Speaker 3: espressioni DAX e persino la denominazione dei ruoli stessi se
3:51
Speaker 3: si considerano queste scelte come passaggi isolati ci si fida
3:53
Speaker 3: del fatto che il sistema non avrà nulla in sospeso
3:56
Speaker 3: ma se si dimentica un filtro all'improvviso la configurazione accurata
3:59
Speaker 3: dei ruoli diventa come un setaccio questa è una di
4:02
Speaker 3: quelle aree in cui l'analogia giusta non è quella di
4:05
Speaker 3: una porta chiusa a chiave è una rete di thread
4:09
Speaker 3: se si cambia una parte l'intera cosa può cambiare all'improvviso
4:12
Speaker 3: se si salta un thread si crea una perdita che
4:13
Speaker 3: non è nemmeno evidente finché non viene sfruttata Incidenti reali
4:16
Speaker 3: mostrano come funziona. Storie riservate ai team di analisi parlano
4:20
Speaker 3: del momento in cui il responsabile delle vendite europee si
4:22
Speaker 3: è imbattuto nei dati della pipeline del Nord America. Non
4:26
Speaker 3: è stata un'intrusione, ma un filtro applicato in modo errato,
4:28
Speaker 3: un'impostazione predefinita e involontaria, un ruolo che nessuno ha pensato
4:31
Speaker 3: di controllare. Non si tratta solo di storie del mondo reale.
4:34
Speaker 3: I report sulle vulnerabilità di Microsoft elencano la sicurezza, a
4:37
Speaker 3: livello di riga configurata in modo errato come una delle
4:39
Speaker 3: principali ragioni per l'esposizione imbarazzante dei dati pubblici nelle grandi organizzazioni.
4:44
Speaker 3: Per ogni titolo di giornale su una grande violazione, ce
4:46
Speaker 3: ne sono decine che non vengono segnalate ma che hanno
4:48
Speaker 3: conseguenze e durature dietro le quinte. Ciò che accomuna questi
4:52
Speaker 3: problemi è il falso senso di sicurezza, offerto da RLS
4:55
Speaker 3: quando lo si considera come un semplice elemento, da spuntare
4:57
Speaker 3: da una lista di cose da fare. Studi condotti dai
5:01
Speaker 3: team di sicurezza Microsoft sottolineano che la stratificazione dei filtri,
5:04
Speaker 3: l'impilamento tra tabelle, l'applicazione di espressioni DAX aggiuntive o l'utilizzo
5:08
Speaker 3: di combinazioni di logica statica e dinamica aumentano sia la
5:11
Speaker 3: protezione che la complessità. Ogni livello aggiunto non solo rende
5:15
Speaker 3: le cose più sicure ma moltiplica il numero di punti
5:17
Speaker 3: in cui può verificarsi un errore di configurazione. Invece di
5:21
Speaker 3: un semplice guardiano alla porta si ottiene una rete complessa
5:24
Speaker 3: in cui un nodo mancato può compromettere mesi di pianificazione
5:27
Speaker 3: della sicurezza. Non trascuriamo nemmeno le realtà pratiche. Un sistema
5:32
Speaker 3: potrebbe funzionare bene in fase di test ma se lo
5:34
Speaker 3: trasciniamo in produzione con utenti reali reparti reali e team
5:38
Speaker 3: in continuo cambiamento si ottengono situazioni in cui qualcuno che
5:41
Speaker 3: ha cambiato team nel trimestre precedente ha ancora accesso ai
5:44
Speaker 3: dati finanziari trimestrali nomi e incarichi che all'inizio avevano senso
5:50
Speaker 3: si trasformano in misteriosi artefatti legacy nessuno vuole toccarli nel
5:54
Speaker 3: caso in cui siano ancora in uso se attivi rls
5:57
Speaker 3: solo durante la configurazione e poi procedi non stai proteggendo
5:59
Speaker 3: i tuoi dati speri che nessuno bussi alla porta sbagliata
6:03
Speaker 3: per curiosità o per sbaglio Tutto questo porta a una
6:07
Speaker 3: verità fondamentale. La sicurezza a livello di riga è attiva.
6:10
Speaker 3: Cambia con la tua organizzazione. Ogni ruolo che crei, ogni
6:12
Speaker 3: filtro DAX che applichi, ogni gruppo che assegni non sono
6:15
Speaker 3: piccole scelte. Confluiscono insieme per creare un sistema di protezione
6:19
Speaker 3: dinamico o, se ignorato, una rete piena di falle. Quindi,
6:22
Speaker 3: prima di passare alla dashboard successiva o di consegnare un modello,
6:25
Speaker 3: fermati e chiediti, sto effettivamente gestendo un sistema di sicurezza
6:28
Speaker 3: o spero solo che il passaggio sia sufficiente? La parte
6:32
Speaker 3: successiva di questa storia inizia con l'elemento al centro di tutto,
6:35
Speaker 3: la logica del filtro stessa e il modo in cui
6:37
Speaker 3: guida ogni altra decisione che prendi. Creazione di una base sicura,
6:42
Speaker 3: filtraggio dei dati e progettazione dei ruoli. Si è mai
6:44
Speaker 3: impostato la sicurezza a livello di riga pensando che si
6:46
Speaker 3: trattasse solo di tenere alcune righe fuori dalla vista non
6:48
Speaker 3: sei il solo? Il motivo principale per cui la RLS
6:51
Speaker 3: diventa caotica è un semplice malinteso. Non riguarda solo ciò
6:54
Speaker 3: che è visibile, ma anche la definizione dell'intera esperienza utente.
6:58
Speaker 3: Un piccolo passo falso, all'improvviso, quella tabella dei bonus riservati
7:01
Speaker 3: o quella cifra sullo stipendio dei dirigenti si riversano nella
7:04
Speaker 3: dashboard di qualcuno. Tuttavia le persone scoprono queste perdite quando
7:08
Speaker 3: i report sono già in circolazione e a quel punto
7:10
Speaker 3: tornare indietro può diventare imbarazzante. La parte scomoda è che
7:13
Speaker 3: queste suddivisioni raramente sembrano drammatiche. Di solito si tratta di
7:16
Speaker 3: un caso limite e un responsabile statunitense effettua l'accesso e
7:19
Speaker 3: vede esattamente ciò che dovrebbe ma un collega di Londra
7:21
Speaker 3: apre lo stesso modello e senza che nessuno se ne
7:23
Speaker 3: accorga trova il numero di New York proprio lì. Pensa
7:26
Speaker 3: di avviare un modello Fabric per le vendite globali Vuoi
7:30
Speaker 3: che i responsabili di diverse regioni vedano solo i propri dati.
7:33
Speaker 3: Un effetto riflesso è quello di inserire un filtro, qualcosa
7:35
Speaker 3: di semplice. Regione uguale Stati Uniti o Paese uguale, Regno Unito...
7:40
Speaker 3: Ma ecco il trucco. Il modo in cui scrivi quel
7:42
Speaker 3: filtro e come lo colleghi al tuo modello determina se
7:44
Speaker 3: il tuo sistema effettivamente regge o si sgretola nel momento
7:46
Speaker 3: in cui le cose diventano più complesse. Molte persone presumono
7:50
Speaker 3: che sia semplicissimo un filtro DAX a una riga e
7:52
Speaker 3: poi vanno avanti. Ma non tutti i DAX si comportano
7:55
Speaker 3: allo stesso modo. Infatti queste sfumature spesso creano problemi in seguito,
7:58
Speaker 3: soprattutto quando si passa da Power BI Desktop a Fabric,
8:01
Speaker 3: dove iniziano a emergere stranezze a livello di cloud. RS
8:05
Speaker 3: si complica abbastanza rapidamente quando si entra nei dettagli. Spesso
8:08
Speaker 3: le persone contano su funzioni come nome utente o nome
8:11
Speaker 3: principale utente, supponendo che facciano la stessa cosa o semplicemente
8:14
Speaker 3: prendendo quella utilizzata da un post di blog. Ma se
8:16
Speaker 3: si sostituisce nome utente che recupera il nome Windows in
8:19
Speaker 3: Desktop con nome principale utente che recupera l'indirizzo email in Fabric,
8:23
Speaker 3: all'improvviso la logica del filtro inizia a vacillare. Se hai
8:26
Speaker 3: mai avuto un test che funzionava in desktop ma che
8:28
Speaker 3: crollava una volta pubblicato su Fabric, probabilmente è per questo.
8:31
Speaker 3: Ed è così che si aprono silenziosamente delle lacune, offrendo
8:34
Speaker 3: alle persone sbagliate una finestra sui dati che non dovrebbero
8:37
Speaker 3: mai toccare. Entriamo nello specifico. Per gli scenari di base
8:40
Speaker 3: funziona un controllo codificato. Regione uguale a Stati Uniti significa
8:44
Speaker 3: che vengono visualizzate solo le righe in cui la regione
8:47
Speaker 3: è Stati Uniti. Ecco il manuale di RS statico. È rapido,
8:50
Speaker 3: semplice e per divisioni fisse come un report destinato solo
8:52
Speaker 3: ai manager statunitensi svolge il suo lavoro. Tuttavia, non appena
8:56
Speaker 3: qualcuno richiede la sicurezza dinamica, le cose cambiano. Potresti dover
8:59
Speaker 3: determinare l'accesso non solo in base al visualizzatore del report,
9:01
Speaker 3: ma anche in base alla relazione in un'altra tabella, ad
9:03
Speaker 3: esempio una tabella di accesso utente che elenca quali utenti
9:05
Speaker 3: visualizzano quali regioni. Ora, il filtro RLS non è solo
9:08
Speaker 3: un valore fisso. È una formula che cerca quali regioni
9:12
Speaker 3: ogni persona dovrebbe accedere in tempo reale. Ecco dove DAX
9:15
Speaker 3: può farti inciampare se non stai attento. Potresti cercare qualcosa
9:18
Speaker 3: come nome principale utente e quindi provare a unirlo alla
9:21
Speaker 3: tabella di accesso. Tuttavia, se il tuo DAX si basa
9:24
Speaker 3: su colonne calcolate e richiama una logica che non risponde
9:26
Speaker 3: al contesto utente al momento della visualizzazione, potresti interrompere accidentalmente
9:30
Speaker 3: il filtro dinamico. Potresti interrompere accidentalmente il filtro dinamico. Esempio concreto.
9:34
Speaker 3: Un'azienda ha imposto un filtro dinamico basandosi su una colonna
9:36
Speaker 3: calcolata nella propria tabella dei fatti solo per rendersi conto
9:39
Speaker 3: in seguito che le colonne calcolate vengono valutate quando i
9:42
Speaker 3: dati vengono caricati, non quando vengono visualizzati. Ciò significa che
9:47
Speaker 3: gli utenti non possono vedere le loro righe personalizzate, o
9:49
Speaker 3: peggio ancora, ne vedono troppo. Non te ne accorgi finché
9:51
Speaker 3: un utente non ti contatta chiedendoti perché un report appare
9:54
Speaker 3: diverso per lui rispetto a un altro membro dello stesso team.
9:57
Speaker 3: La documentazione di Microsoft e una lunga serie di post
9:59
Speaker 3: di blog MVP continuano a gridare dai tetti. Non fidarti
10:01
Speaker 3: delle colonne calcolate con RLS. Le colonne calcolate all'aggiornamento non
10:07
Speaker 3: cambiano in base all'utente. Affinché RLS risponda effettivamente al visualizzatore,
10:12
Speaker 3: la logica del filtro deve essere creata come un'espressione DAX
10:15
Speaker 3: su tabelle che si aggiorna nel contesto del report. Ignora
10:18
Speaker 3: questo e le tue dashboard ti tradiranno silenziosamente mostrando le
10:20
Speaker 3: stesse righe indipendentemente da chi ha effettuato l'accesso. RLS statico
10:24
Speaker 3: rispetto a dinamico non è solo una distinzione tecnica. Riguarda
10:28
Speaker 3: quando e come vengono filtrati i dati. Un RLS statico
10:32
Speaker 3: è rapido e rigido, ottimo quando sai esattamente quale ruolo
10:35
Speaker 3: necessita di quali dati in anticipo. Se stai avviando un
10:39
Speaker 3: report solo con un gruppo finanziario o di vendita, questo funziona.
10:42
Speaker 3: Questo funz... Ma se si passa alla modalità dinamica, ogni
10:45
Speaker 3: decisione di accesso avviene al volo, solitamente abbinando l'identità dell'utente
10:48
Speaker 3: corrente a una voce in una tabella di ricerca delle autorizzazioni.
10:52
Speaker 3: La flessibilità è importante, soprattutto per le grandi organizzazioni o
10:55
Speaker 3: le distribuzioni multi- tenant, ma ogni passo avanti della flessibilità aggiunge
10:59
Speaker 3: complessità e la complessità comporta sempre dei rischi nascosti. Anche
11:03
Speaker 3: gli amministratori esperti inciampano nel credere che i filtri siano
11:05
Speaker 3: sempre semplici. La forma effettiva della tua organizzazione cambia costantemente
11:09
Speaker 3: e i tuoi filtri DAX devono tenere il passo. Molti
11:13
Speaker 3: si interrompono perché non si rendono conto di come viene
11:15
Speaker 3: applicata la logica RLS, non durante il caricamento dei dati,
11:18
Speaker 3: ma ogni volta che un utente interagisce con il report.
11:21
Speaker 3: Dimentica questo e potresti aprire o bloccare accidentalmente intere sezioni
11:24
Speaker 3: del tuo modello di dati senza rendertene conto. In conclusione,
11:28
Speaker 3: se sbagli le basi, nient'altro di ciò che crei con
11:30
Speaker 3: RLS avrà importanza. Il modo in cui scrivi il tuo DAX,
11:35
Speaker 3: il tipo di filtri che usi e dove li applichi,
11:37
Speaker 3: questi elementi si sommano per definire la tua reale posizione
11:39
Speaker 3: di sicurezza. Se tralasci le sfumature, ti ritroverai con una
11:43
Speaker 3: configurazione che funziona in teoria ma perde nella pratica. Tutto
11:45
Speaker 3: questo accade prima ancora di arrivare alla mappatura degli utenti
11:48
Speaker 3: e ruoli, che si rivela essere il punto successivo in
11:49
Speaker 3: cui le cose vanno silenziosamente per il verso sbagliato. Mappatura
11:52
Speaker 3: dei ruoli agli utenti, la trappola dell'assegnazione. Quindi hai impostato
11:56
Speaker 3: i ruoli, creato i filtri, e le cose sembrano andare
11:58
Speaker 3: per il verso giusto dal punto di vista del modello.
12:00
Speaker 3: Passaggio successivo all'assegnazione degli utenti sembra una cosa ovvia, ma
12:03
Speaker 3: è qui che la maggior parte dei piani sicurezza a
12:04
Speaker 3: livello di ruolo inizia silenziosamente a inclinarsi. Questo è il
12:07
Speaker 3: bivio del pensiero ITE. La logica tecnica è a posto,
12:12
Speaker 3: ma ora stai scommettendo che a livello umano le assegnazioni
12:14
Speaker 3: di utenti e gruppi corrispondano effettivamente alla realtà del funzionamento
12:17
Speaker 3: della tua azienda. Sembra semplice perché c'è un campo gruppo
12:20
Speaker 3: e un elenco di ruoli, ma l'esperienza dice che è
12:22
Speaker 3: qui che gli errori tendono a nascondersi. Maginone, hai creato
12:26
Speaker 3: un ruolo di responsabile, hai inserito il filtro creato con
12:29
Speaker 3: cura su di esso e hai mappato il ruolo in
12:30
Speaker 3: Power BI o fabbrica un gruppo di Azure AD denominato responsabili.
12:36
Speaker 3: Fai un doppio controllo, magari fai anche controllare da un
12:37
Speaker 3: secondo paio di persone e lo distribuisci all'organizzazione. All'inizio sembra semplice.
12:42
Speaker 3: Questo è il problema perché la logica di gruppo, soprattutto
12:44
Speaker 3: nelle grandi organizzazioni, raramente rimane semplice a lungo. I team cambiano,
12:48
Speaker 3: i reparti si riorganizzano, i ruoli si evolvono, le persone
12:50
Speaker 3: lasciano un progetto e ne entrano a far parte in
12:52
Speaker 3: un altro. Cosa succede se qualcuno passa dalle vendite alle
12:55
Speaker 3: operazioni e nessuno elimina le vecchie appartenenze ai gruppi? Improvvisamente
12:58
Speaker 3: il tuo progetto RLS a prova di bomba ha un
13:00
Speaker 3: utente in due posti contemporaneamente. E c'è un rischio reale
13:04
Speaker 3: che ottenga l'accesso a dati che non gli appartengono più.
13:07
Speaker 3: È facile supporre che tutti in un determinato gruppo di
13:09
Speaker 3: Azure AD debbano avere lo stesso accesso, ma in realtà
13:12
Speaker 3: le appartenenze ai gruppi possono diventare obsolete. Qualcuno potrebbe trasferirsi
13:15
Speaker 3: in un'altra regione, ma il suo nome non esce mai
13:17
Speaker 3: dall'elenco originale del team. Anche se tu come amministratore sei
13:21
Speaker 3: piuttosto disciplinato nel ripulire, i proprietari dei gruppi raramente tengono
13:25
Speaker 3: il passo con ogni cambiamento, soprattutto durante un trimestre intenso.
13:29
Speaker 3: Ricorda che la sincronizzazione tra Azure AD e Power BI
13:31
Speaker 3: o Fabric non è sempre immediata. A volte è a
13:34
Speaker 3: ritardo di ore e questo è più che sufficiente perché
13:36
Speaker 3: qualcuno veda qualcosa che non dovrebbe dopo una modifica. Aspetta
13:40
Speaker 3: un batch notturno e un dipendente in partenza potrebbe andarsene
13:43
Speaker 3: con molto più contesto di quanto previsto. Le assegnazioni ombra
13:47
Speaker 3: potrebbero sembrare drammatiche ma sono quasi di routine. Nella maggior
13:50
Speaker 3: parte degli ambienti del mondo reale un singolo utente può
13:53
Speaker 3: facilmente finire in più gruppi, ognuno assegnato a diversi ruoli RLS.
13:56
Speaker 3: Il design è pensato per essere flessibile, il che è
13:58
Speaker 3: positivo in teoria. In pratica significa che devi destreggiarti in
14:01
Speaker 3: una rete di autorizzazioni ereditate. Non è sempre chiaro chi
14:03
Speaker 3: può vedere cosa, a meno che tu non lo insegua manualmente.
14:07
Speaker 3: Ad esempio, se Sara dal settore finanziario passa alle risorse
14:10
Speaker 3: umane e nessuno la toglie dal gruppo finanziario, ora indossa
14:12
Speaker 3: due cappelli, uno attuale e uno obsoleto. La maggior parte
14:15
Speaker 3: delle persone non se ne accorge nemmeno finché Sara stessa
14:17
Speaker 3: non prova ad accedere a un report destinato al settore
14:19
Speaker 3: finanziario e riesce comunque ad accedervi molto tempo dopo essere
14:21
Speaker 3: passata a un altro reparto. I team di sicurezza di
14:22
Speaker 3: Microsoft indicano gli errori di assegnazione dei ruoli. come la
14:28
Speaker 3: causa principale di esposizione accidentale dei dati negli ambienti di analisi.
14:32
Speaker 3: La matematica è semplice. Più gruppi e più utenti cambiano,
14:35
Speaker 3: più è facile trascurare chi è effettivamente associato a ciascun ruolo.
14:41
Speaker 3: Ciò che lo rende più subdolo è la mancanza di
14:42
Speaker 3: feedback evidenti. A differenza di altri errori di sicurezza non
14:45
Speaker 3: si riceve un messaggio di errore o un'interruzione in interfaccia
14:47
Speaker 3: o da internet. Di solito non ci sono avvisi automatici
14:51
Speaker 3: o revisioni forzate e una mappatura errata può rimanere nell'ombra
14:53
Speaker 3: per mesi, emergendo solo durante un audit o quando qualcuno
14:56
Speaker 3: si imbatte in dati che non avrebbe dovuto toccare. Anche
14:59
Speaker 3: le migliori intenzioni vengono vanificate dalla realtà quotidiana. La revisione
15:03
Speaker 3: dell'appartenenza ai gruppi è una buona norma che tutti consigliano,
15:06
Speaker 3: ma pochi team la seguono effettivamente con rigore. Dal punto
15:10
Speaker 3: di vista amministrativo è un lavoro noioso. Le revisioni manuali
15:13
Speaker 3: dei gruppi non sono esattamente una priorità assoluta, soprattutto se
15:16
Speaker 3: il team di analisi sta risolvendo altri problemi. e nella
15:20
Speaker 3: maggior parte delle realizzazioni non esiste un processo impostato per
15:22
Speaker 3: odi regolari perché si presume che le modifiche in ACRIT
15:25
Speaker 3: si diffonderanno, ma le ipotesi sono esattamente ciò che consente
15:28
Speaker 3: alle autorizzazioni di deviare all'accesso ombra di persistere. Il risultato
15:32
Speaker 3: nel tempo è che il modello RLS, indipendentemente da quanto
15:34
Speaker 3: sia preciso sulla carta, perde la sinfonizzazione con chi dovrebbe
15:37
Speaker 3: realmente vedere cosa. Gli strumenti di controllo automatizzati possono aiutare
15:41
Speaker 3: a individuare queste assegnazioni in sospeso, ma attivarle richiede impegno.
15:45
Speaker 3: devono connettere la zona D, contrassegnare le modifiche e magari
15:48
Speaker 3: anche attivare un flusso di lavoro quando le appartenenze ai
15:50
Speaker 3: gruppi di qualcuno non corrispondono più alla propria unità aziendale.
15:54
Speaker 3: Non tutti gli ambienti Power BI dispongono di questo tipo
15:56
Speaker 3: di controlli, in particolare le piccole aziende e i progetti
15:58
Speaker 3: con scadenze ravvicinate. Quindi la proliferazione dei gruppi diventa inevitabile.
16:02
Speaker 3: Più a lungo il sistema RLS rimane inattivo, più è
16:04
Speaker 3: probabile che le autorizzazioni diventino obsolete o peggio, che si
16:06
Speaker 3: riversino su livelli diversi che non stai nemmeno monitorando. Ciò
16:10
Speaker 3: che coglie davvero di sorpresa è che le assegnazioni non
16:12
Speaker 3: sono solo un segno di spugna. Sono il collegamento continuo
16:15
Speaker 3: che lega la logica di sicurezza a persone reali. Lasciale
16:19
Speaker 3: andare alla deriva e tutti i DAC intelligenti del mondo
16:20
Speaker 3: non ti salveranno. L'igiene dell'assegnazione è un processo attivo, non
16:24
Speaker 3: un'impostazione o una tantum. I sistemi evolvono, gli utenti si spostano,
16:27
Speaker 3: il tuo modello deve tenere traccia di tali modifiche o
16:29
Speaker 3: dovrai affidarti alla fortuna e la fortuna non ha una
16:31
Speaker 3: strategia di sicurezza. Ora, anche con i processi di assegnazione
16:34
Speaker 3: più rigidi si verifica un problema importante nel momento in
16:37
Speaker 3: cui si trasferisce la soluzione attentamente creata da Power BI
16:40
Speaker 3: Desktop al Fabric Fino a questo punto la maggior parte
16:44
Speaker 3: dei team testava la sandbox locale sul proprio computer con
16:47
Speaker 3: solo account di prova. Le cose sembravano prevedibili, ma passando
16:51
Speaker 3: a Fabric iniziano a emergere tutti i tipi di sottili
16:53
Speaker 3: differenze nel contesto utente, nella risoluzione dei gruppi e nei
16:56
Speaker 3: tempi di autenticazione. È qui che ci imbattiamo in stranezze
16:59
Speaker 3: che nessuno si aspetta e perché le assegnazioni che sembrano
17:01
Speaker 3: perfette in teoria possono rompersi in modo spettacolare in produzione.
17:05
Speaker 3: Da desktop a Fabric e cambiamenti nascosti nel comportamento RLS.
17:09
Speaker 3: Se sei mai stato convinto di avere la sicurezza a
17:11
Speaker 3: livello di riga completamente sotto controllo in Power BI Desktop,
17:14
Speaker 3: ma poi hai visto tutto sgretolarsi nel momento in cui
17:16
Speaker 3: pubblichi su Fabric e ti trovi in un territorio familiare.
17:19
Speaker 3: Questa è la parte di cui nessuno ti parla nei
17:20
Speaker 3: tutorial RLS. Il momento in cui tutta quella logica impeccabile
17:24
Speaker 3: di quale filtri si scontra a capofitto con la realtà
17:26
Speaker 3: del cloud. Hai controllato ogni filtro, mappato attentamente ogni gruppo
17:29
Speaker 3: e persino sistemato quelle assegnazioni di casi limite. Ma nel
17:34
Speaker 3: momento in cui passi al servizio Fabric, le cose cambiano
17:36
Speaker 3: in un modo che coglie di sorpresa anche gli amministratori
17:38
Speaker 3: più esperti. Iniziamo da ciò che vedi in desktop. L'anteprima
17:42
Speaker 3: funziona esattamente come ti aspettavo. Testi ruoli utente, passi da
17:45
Speaker 3: un'identità di esempio all'altra. Tutto è perfettamente allineato, i numeri
17:49
Speaker 3: corrispondono e per un momento sembra che tu abbia azzeccato
17:51
Speaker 3: un processo semplice. Ma non appena i tuoi compagni di
17:54
Speaker 3: team iniziano ad aprire lo stesso file di Power BI
17:57
Speaker 3: nel Cloud Store, iniziano ad arrivare. Qualcuno segnala di aver
18:01
Speaker 3: visto numeri al di fuori della propria regione o, peggio,
18:03
Speaker 3: qualcuno è bloccato fuori da un set di dati di
18:04
Speaker 3: cui ha assolutamente bisogno per svolgere il proprio lavoro. La
18:07
Speaker 3: frustrazione aumenta quando ti rendi conto che la stessa configurazione
18:10
Speaker 3: RLS che era prova di bomba sul tuo computer ora
18:11
Speaker 3: funziona più come un suggerimento che come una regola. Ma
18:14
Speaker 3: questa confusione si riduce a differenze che non puoi effettivamente
18:16
Speaker 3: vedere finché non pubblichi. L'ambiente cloud di Fabric opera in
18:20
Speaker 3: un mondo diverso quando si tratta di sicurezza, identità e
18:23
Speaker 3: contesto dei dati. Un classico problema colpisce dritto al cuore
18:26
Speaker 3: dei modelli RLS dinamici. In desktop una funzione DAX come
18:30
Speaker 3: username estrae il tuo login Windows locale. Semplice, prevedibile e
18:34
Speaker 3: rassicurantemente stabile all'interno del tuo ambiente. Ma su Fabric la
18:38
Speaker 3: stessa chiamata al nome utente cattura invece il tuo indirizzo
18:40
Speaker 3: email completo. Sembra una cosa da poco, ma se il
18:42
Speaker 3: tuo filtro o la tua ricerca fa riferimento a un
18:44
Speaker 3: nome di dominio, se la tua tabella di sicurezza esclude
18:46
Speaker 3: i formati brevi rispetto ai mail complete, l'intero sistema si
18:49
Speaker 3: blocca nel momento in cui gli utenti accedono al cloud e, inevitabilmente,
18:53
Speaker 3: inizia a ricevere reclami. Ecco cosa succede in ambienti reali.
18:57
Speaker 3: Un report mostra una suddivisione per paese sul desktop, ma
19:00
Speaker 3: dopo la pubblicazione, gli utenti vedono numeri globali. Forse il
19:03
Speaker 3: tuo modello si basava sul nome principale dell'utente perché tutte
19:06
Speaker 3: le tue chiavi di accesso sono indirizzi mail. Questa è
19:09
Speaker 3: una buona pratica per il cloud, ma se hai iniziato
19:11
Speaker 3: sul desktop e non sapevi che questo cambiamento avviene, stai
19:13
Speaker 3: eseguendo un debug di un problema che non esiste a
19:15
Speaker 3: livello locale e mai esplode su larga scale. La verità
19:18
Speaker 3: è che ciò che funziona sul tuo laptop è più
19:19
Speaker 3: un prototipo decente che una soluzione finita. La logica locale
19:24
Speaker 3: può nascondere una mina vagante che è solo l'autenticazione cloud attiva.
19:28
Speaker 3: Ci sono anche alcune leve invisibili che fabbricazione senza preavviso.
19:32
Speaker 3: Gli aggiornamenti dei dati, ad esempio, possono essere avviati con
19:34
Speaker 3: credenziali diverse o atterrare su un proprietario del modello diverso
19:36
Speaker 3: da quello previsto. Se il proprietario del set di dati
19:39
Speaker 3: pubblicato non è nel gruppo giusto, potrebbe finire per non
19:41
Speaker 3: vedere alcun dato o per ottenere accidentalmente l'accesso a tutto.
19:45
Speaker 3: La modifica della proprietà nel cloud non influisce solo sulle autorizzazioni.
19:48
Speaker 3: Può interrompere le connessioni gateway. o modificare il modo in
19:50
Speaker 3: cui le credenziali vengono valutate rispetto ai sistemi di origine.
19:54
Speaker 3: A volte le impostazioni del TENT nascondono comportamenti legacy o
19:57
Speaker 3: impostano come predefinite opzioni che sottoscrivono quanto impostato durante i
20:00
Speaker 3: test desktop. Per le organizzazioni con criteri tenant a più livelli,
20:04
Speaker 3: un'azione minima come l'attivazione e la disattivazione della condivisione esterna
20:07
Speaker 3: può modificare la logica di chi vede cosa da un
20:09
Speaker 3: giorno all'altro. Ciò che lascia perplessi è quanto siano sottili
20:11
Speaker 3: queste modifiche. Non gridano, ehi, ora la tua sicurezza delle
20:14
Speaker 3: reti non funziona più. Al contrario, le cose funzionano in
20:16
Speaker 3: modo silenzioso sbagliato. Una piccola modifica nell'autenticazione o nel modo
20:19
Speaker 3: in cui un modello risolve l'appartenenza al gruppo durante l'accesso
20:22
Speaker 3: modifica completamente il contesto di sicurezza. I forum di supporto
20:26
Speaker 3: Microsoft sono pieni di amministratori che si scambiano storie dell'orrore
20:29
Speaker 3: su report, che hanno superato tutti i test desktop Solo
20:32
Speaker 3: per poi crollare quando gli utenti hanno iniziato ad accedervi
20:35
Speaker 3: nel cloud. Si vede una thread in cui, dopo un'implementazione,
20:39
Speaker 3: i team si affannano per correggere e riprogettare tutti i
20:41
Speaker 3: ruoli RLS, non perché la logica fosse sbagliata, ma perché
20:45
Speaker 3: il passaggio a Fabric ha spostato il contesto di identità
20:47
Speaker 3: a tal punto da rendere tutto inaffidabile. Anche gli aggiornamenti
20:51
Speaker 3: cloud o gli aggiornamenti a livello di tenant possono spingere
20:54
Speaker 3: la sicurezza in nuove direzioni. A volte, dopo un aggiornamento,
20:57
Speaker 3: i mapping di gruppo gestiti da Azure AD vengono sincronizzati
20:59
Speaker 3: in modo leggermente diverso rispetto a prima per cui le
21:02
Speaker 3: assegnazioni Shadow hanno improvvisamente più priorità o determinate ricerche dinamiche
21:05
Speaker 3: riscontrano valori nulli laddove ci si aspettava una corrispondenza. Piccoli
21:09
Speaker 3: cambiamenti si sono. Una modifica in un componente dello stack
21:11
Speaker 3: si ripercuote sull'intera mesh di sicurezza e il modello più
21:14
Speaker 3: affidabile del trimestre precedente non regge più oggi. Ecco perché
21:18
Speaker 3: i team del mondo reale hanno iniziato a trattare i
21:19
Speaker 3: tester LS come un lavoro di produzione non solo come
21:22
Speaker 3: un controllo locale Non è sufficiente scorrere i ruoli sul
21:25
Speaker 3: proprio computer portatile. È necessario preparare il modello in Fabric,
21:29
Speaker 3: importare account utente reali e seguire il flusso di autorizzazione end- to- end.
21:35
Speaker 3: Solo in questo modo è possibile rilevare bug di autenticazione
21:38
Speaker 3: o disalimenti impercettibili tra le assegnazioni di gruppo e ciò
21:41
Speaker 3: che Power BI ritiene attuale in Azure AD. Alcune organizzazioni
21:44
Speaker 3: creano persino script per audit RLS periodici nel cloud solo
21:48
Speaker 3: per verificare la deriva tra la logica del modello di
21:50
Speaker 3: assegnazione e ciò che Fabric effettivamente applica. Se non si
21:55
Speaker 3: eseguono test con persone reali nell'ambiente in cui si trova
21:57
Speaker 3: realmente il report, l'RLS funziona sostanzialmente con speranza. Il cloud
22:03
Speaker 3: è l'arbitro finale e l'unico modo per vedere come filtri
22:05
Speaker 3: e ruoli interagiscono con le identità su larga scala è
22:08
Speaker 3: creare l'RLS tenendo a mente la produzione fin dall'inizio. Se
22:12
Speaker 3: si rimandano questi test a un secondo momento, si procede
22:14
Speaker 3: alla check, alle conseguenze, ovvero dati esposti, team frustrati o
22:17
Speaker 3: un attento lavoro di sicurezza annullato da un cambiamento nascosto,
22:20
Speaker 3: finiscono per costare molto di più da risolvere una volta
22:22
Speaker 3: che il report è in uso. Ora, di fronte a
22:25
Speaker 3: questo scenario, la grande domanda non è solo quella di
22:27
Speaker 3: correggere la relessa ogni volta che qualcosa cambia. Si tratta
22:31
Speaker 3: di stabilire se si dispone di un piano che funzioni
22:33
Speaker 3: man mano che la configurazione di Fabric diventa più complicata,
22:35
Speaker 3: i dati aumentano più complicata ed azienda aumenta.